[Fixed] Small Boom incompatabilities
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.
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.
-
- Posts: 12
- Joined: Tue Nov 25, 2003 4:08 am
Small Boom incompatabilities
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.
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.
-
- Site Admin
- Posts: 7749
- Joined: Wed Jul 09, 2003 10:30 pm
Re: Small Boom incompatabilities
Fixed.larsboy wrote:Generalized linedef: Switch once, ceiling up to lowest adjacent ceiling (linedef type 16578) not working,
This works fine; See the attached wad. You will have to look elsewhere for the cause of the problem.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.
You do not have the required permissions to view the files attached to this post.
-
- Posts: 912
- Joined: Tue Jul 15, 2003 5:12 pm
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.
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.
-
- Posts: 2033
- Joined: Sat Jul 19, 2003 6:15 am
- Operating System Version (Optional): Tumbleweed x64
- Graphics Processor: Intel with Vulkan/Metal Support
- Location: Central Germany
-
- Posts: 12
- Joined: Tue Nov 25, 2003 4:08 am
-
- Posts: 20
- Joined: Wed Dec 03, 2003 6:13 am
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..?
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..?
-
- Lead GZDoom+Raze Developer
- Posts: 49141
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
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.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.
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! )(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..?
-
- Site Admin
- Posts: 7749
- Joined: Wed Jul 09, 2003 10:30 pm
-
- Lead GZDoom+Raze Developer
- Posts: 49141
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
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 )
-
- Posts: 405
- Joined: Thu Jul 17, 2003 10:10 pm
-
- Posts: 912
- Joined: Tue Jul 15, 2003 5:12 pm
perhaps mord is thinking of switching to zdoom? (dun dun dun)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? :-)
though of course what his teleporters do is already possible in zdoom with a little scritping ;)
-
- Lead GZDoom+Raze Developer
- Posts: 49141
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
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...
-
- Lead GZDoom+Raze Developer
- Posts: 49141
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
-
- Posts: 405
- Joined: Thu Jul 17, 2003 10:10 pm
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
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