[Fixed] Small Boom incompatabilities

Bugs that have been investigated and resolved somehow.

Moderator: GZDoom Developers

Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
larsboy
Posts: 12
Joined: Tue Nov 25, 2003 4:08 am

Small Boom incompatabilities

Post by 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.
User avatar
randi
Site Admin
Posts: 7746
Joined: Wed Jul 09, 2003 10:30 pm

Re: Small Boom incompatabilities

Post by randi »

larsboy wrote:Generalized linedef: Switch once, ceiling up to lowest adjacent ceiling (linedef type 16578) not working,
Fixed.
Larsboy wrote: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.
You do not have the required permissions to view the files attached to this post.
Cyb
Posts: 912
Joined: Tue Jul 15, 2003 5:12 pm

Post by 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.
User avatar
Hirogen2
Posts: 2033
Joined: Sat Jul 19, 2003 6:15 am
Graphics Processor: Intel with Vulkan/Metal Support
Location: Central Germany

Post by Hirogen2 »

However, somebody did a boomtricks.wad which used IIRC nested transfer_heights (Boom:242, Hexen:209) to make translucent water.
larsboy
Posts: 12
Joined: Tue Nov 25, 2003 4:08 am

Post by larsboy »

Great, the first bug is fixed in 57 :D
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
Posts: 20
Joined: Wed Dec 03, 2003 6:13 am

Post by 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..?
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49053
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Post by Graf Zahl »

Mordeth wrote: 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! ;) )
User avatar
randi
Site Admin
Posts: 7746
Joined: Wed Jul 09, 2003 10:30 pm

Post by 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? :-)
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49053
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Post by Graf Zahl »

randy wrote: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 ;) )
User avatar
randomlag
Posts: 405
Joined: Thu Jul 17, 2003 10:10 pm

Post by randomlag »

randy wrote: 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
Posts: 912
Joined: Tue Jul 15, 2003 5:12 pm

Post by Cyb »

randy wrote: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 ;)
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49053
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Post by Graf Zahl »

Cyb wrote: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...
User avatar
randomlag
Posts: 405
Joined: Thu Jul 17, 2003 10:10 pm

Post by randomlag »

Don't need to add any more parameters.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49053
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Post by 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.
User avatar
randomlag
Posts: 405
Joined: Thu Jul 17, 2003 10:10 pm

Post by 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

Return to “Closed Bugs [GZDoom]”