[Fixed] Small Boom incompatabilities

[larsboy]

ZDoom seems to have good Boom compatability, but there are some issues. I don't know how much priority will be given to fixing these, but I'll post what I find. Here's a couple that have to do with sector hights not changing, I experienced these with 2.0.56, and I test with PrBoom when possible to make sure it's ZDoom's fault. (Both wads can be found at http://www.doomworld.com/idgames)

Generalized linedef: Switch once, ceiling up to lowest adjacent ceiling (linedef type 16578) not working, this occures several places in strong.wad (this level also has the Passthru bug I already posted, but that's a different issue).

Linedef type 19: Floor lower to highest didn't affect a sector that had already been given a Boom scroll effect from a different line. This caused some monsters not to teleport into the level in ash2ash.wad. PrBoom crashed when I tried running this level, but the text file states that the level had been carefully testet.

[randi]

Generalized linedef: Switch once, ceiling up to lowest adjacent ceiling (linedef type 16578) not working,

Fixed.

Linedef type 19: Floor lower to highest didn't affect a sector that had already been given a Boom scroll effect from a different line.

This works fine; See the attached wad. You will have to look elsewhere for the cause of the problem.

[Cyb]

while we're on the subject of boom compat stuff, I was talking to Mordeth the other day and he noticed that doing nested transfer_ceilinglighting doesn't work (causes the flat to be drawn in black, which I think means it gets flipped over or something wacky, if I remember from the slopes bug a few months ago). Anyways, it works like this, map with three sectors, A, B and C. Give sector A light level of 128, B 160 and C 255. Now make one of the lines on sector A transfer ceiling light to B and one of the lines in B transfer ceiling light to C. Thus sector A's ceiling should remain 128, B should have a ceiling of 128, and C should have a ceiling of 160. But this is not the case, C's ceiling (at least in 2.0.53 which is what I think I tested it in) is all black.

If you swap transfer_ceilinglight for transfer_floorlight then this works as it does in prboom/eterenity, though I didn't test that out myself. I can't retest it right now either, since I'm at home on a linux machine (and versions after 47 give very fatal errors before loading, btw if you want the dump I can show you ; ) with wine), but I'm fairly certain this is the correct setup for the issue.

[Hirogen2]

However, somebody did a boomtricks.wad which used IIRC nested transfer_heights (Boom:242, Hexen:209) to make translucent water.

[larsboy]

Great, the first bug is fixed in 57
Don't know what that second thing is all about, it should work, it just doesn't, so forget about it.

However, the Boom passthru flag is still not working in 57, even though the log says it's fixed.

[Mordeth]

Ah, I see Cyb has already mentioned the bug I've discovered. Good. BTW Hirogen, we're talking about transfer LIGHTS properties (boom trigger 260/213), and not transfer HEIGHTS (boom trigger 242). In my setup, nested transfer ceiling lights results in all-black ceilings while nested transfer floor lights works like intended. This just screams 'bug'.

Some more Boom incompatabilities:

(1) Boom has a feature for Dx doors to have their light level adjusted to the level of the surrounding sector when moving up/down. But in ZDoom, the light level in sectors tagged the same as a Dx door is not adjusted when this door is raised or lowered. In fact, the light level of the door sector itself does not get raised / lowered.

(2) For my TC I've changed the teleport destination thing (tdt) to an un-solid all-cyan thing that can be manipulated in-game. Eg. you can place it on a conveyor and have it move around. In one set-up I move the tdt on a conveyor from a dummy location via a line-to-line teleport to an empty sector tagged by a teleport trigger line. Result in-game: a non-working teleport changes to a working teleport by flipping a switch. This does not work in ZDoom. Strangest thing though: the tdt IS transported to the correct tagged sector in ZDoom. It's also not a dehacked incompatability, as a standard teleport to a tdt still works. After testing a few 'clean' test levels I'm beginning to suspect that ZDoom determines teleport destinations prior to the start of a level..?

[Graf Zahl]

Some more Boom incompatabilities:

(1) Boom has a feature for Dx doors to have their light level adjusted to the level of the surrounding sector when moving up/down. But in ZDoom, the light level in sectors tagged the same as a Dx door is not adjusted when this door is raised or lowered. In fact, the light level of the door sector itself does not get raised / lowered.

Unfortunately this cannot be easily implemented with Hexen-style linedefs (which ZDoom even uses for Doom-style maps) This feature requires tags on normally zero-tagges lines. In Hexen-style zero tags are just a special case for standard linedefs (which use tags normally) and not separate types. In other words: Without some major rewriting of the map conversion code I don't see any change of achieving this.

(2) For my TC I've changed the teleport destination thing (tdt) to an un-solid all-cyan thing that can be manipulated in-game. Eg. you can place it on a conveyor and have it move around. In one set-up I move the tdt on a conveyor from a dummy location via a line-to-line teleport to an empty sector tagged by a teleport trigger line. Result in-game: a non-working teleport changes to a working teleport by flipping a switch. This does not work in ZDoom. Strangest thing though: the tdt IS transported to the correct tagged sector in ZDoom. It's also not a dehacked incompatability, as a standard teleport to a tdt still works. After testing a few 'clean' test levels I'm beginning to suspect that ZDoom determines teleport destinations prior to the start of a level..?

Again a Hexen-map compatibility issue. Hexen uses Tids for teleport destinations, not sector tags and ZDoom converts Doom maps accordingly. As a result a moving teleport destination will not work in ZDoom. The only solution here is to completely re-implement the old code (which, btw, I would have never removed exactly because of the stuff you are doing with it! )

[randi]

Fixed Cyb's bug. Mordeth bug (1) is already documented, and I probably won't try and support that Boom feature. For Mordeth bug (2), the Mordeth TC requires the Eternity engine anyway, so should I really fix it?

[Graf Zahl]

For Mordeth bug (2), the Mordeth TC requires the Eternity engine anyway, so should I really fix it?

Frankly, I have never seen a WAD that manipulates teleport destinations in this way but my first thought when I saw the way ZDoom handles this was 'What if somebody finds a way to abuse it?' Still, I don't really think this is worth much effort (unless it is really easy of course )

[randomlag]

For Mordeth bug (2), the Mordeth TC requires the Eternity engine anyway, so should I really fix it?

Yes. Sounds like an interesting twist to teleports. Seems it should be easy to "fix" - even easier than stock DOOM format.

[Cyb]

Fixed Cyb's bug. Mordeth bug (1) is already documented, and I probably won't try and support that Boom feature. For Mordeth bug (2), the Mordeth TC requires the Eternity engine anyway, so should I really fix it? :-)

perhaps mord is thinking of switching to zdoom? (dun dun dun)

though of course what his teleporters do is already possible in zdoom with a little scritping ;)

[Graf Zahl]

though of course what his teleporters do is already possible in zdoom with a little scritping

Of course. ZDoom's (Hexen's) teleport functionality is significantly better than Dooms because you can do so much more with it. But this isn't about new features but backwards compatibility. I agree that it's easy to fix (add an additional parameter to the teleport specials that activate the old destination selection method.) If there were actually any WADs that use it...

[randomlag]

Don't need to add any more parameters.

[Graf Zahl]

Why not? If the old behavior is implemented someone might want to use it in Hexen-style levels, don't you think?

As in

Teleport(tid,0) for Hexen-style

and

Teleport(tag,1) for Doom-style.

[randomlag]

IIRC, the original ? was about DOOM style levels, not Hexen format. I admit that's a little leap, but Eternity is stock DOOM format, so not unreasonable to assume this.

Besides, pretty sure a moving teleport is rare so even then not required. IOW what is there to be backward compatible with since it doesn't exist?

Remember KISS