[r3010] Action Doom 2 Broken

[Scuba Steve]

There are a lot of severe things broken after 2.5.0 was introduced.

• The arbitrary change to the SAVE/LOAD/OPTIONS broke the illustrated menu options... and I'm sure this isn't the only project that relied on the old order that ZDoom had for years
• A significant change was made to the handling of Stacked sectors that ruined every level that contains one. ZDoom used to not require a stacked sector object in EVERY sector so long as you chose fsky as the flat and the surrounding sectors were all marked properly. With the change, now TONS of maps with stacks have floating ceiling/floor bits between the visible stacks This is most obvious in maps 06,09,10
• Another change in stacked sector handling broke the effect by the river in map08. Instead of correctly doubled sprites that were in both stacks (so they would properly stick out of the water and under it) it offsets them so they look weird
• In map06, the camera texture used for the video poker doesn't display properly anymore and the spacing on the slot machine wheels is much closer together than they used to be.
• Map10 has some script issues where punching the main boss and knocking him out the window while he is holding your daughter causes it to play 2 voices simultaneously and prevent you from doing anything after it. Same goes for a cutscene where your daughter shoots you in the same area.

http://action.mancubus.net/files/bugsaves.zip Includes saves for the river rocks that are broken as well as the final boss so you can test the 2 issues with map 10.

[Gez]

• The arbitrary change to the SAVE/LOAD/OPTIONS broke the illustrated menu options... and I'm sure this isn't the only project that relied on the old order that ZDoom had for years

It is not so arbitrary as the change from the Doom order to begin with... It was reverted because of single-patch vanilla mods like Hell Revealed II. Actually, an option had been added to restore the old ZDoom order, and it worked, but it was lost to copypasta when IWAD definitions were exported to iwadinfo.txt.

I've just fixed that in GZDoom by the way.

[Graf Zahl]

There are a lot of severe things broken after 2.5.0 was introduced.

[*]The arbitrary change to the SAVE/LOAD/OPTIONS broke the illustrated menu options... and I'm sure this isn't the only project that relied on the old order that ZDoom had for years

1. The change wasn't 'arbitrary'. It merely restored something that was wrong in ZDoom.
2. Handling for the other menu layout is present. It just got lost when the IWAD info was externalized.

[*]A significant change was made to the handling of Stacked sectors that ruined every level that contains one. ZDoom used to not require a stacked sector object in EVERY sector so long as you chose fsky as the flat and the surrounding sectors were all marked properly. With the change, now TONS of maps with stacks have floating ceiling/floor bits between the visible stacks This is most obvious in maps 06,09,10

Well, screw it. I'm done cleaning up this mess of code. The only way to fix it is to break old WADs and the only way to keep everything old working is to keep it broken. I thought I had set it up to let this case slip through. BTW, I had to add a special hack case for this in GZDoom but that requires GL nodes to work so I can't port it to the software renderer.

Why is it that such behavior doesn't raise an alarm in you telling, 'Wait a minute! This can't be right. Better file a bug report.' No, instead it gets abused to hell making any attempt to work with the code a futile endeavor.

[*]Another change in stacked sector handling broke the effect by the river in map08. Instead of correctly doubled sprites that were in both stacks (so they would properly stick out of the water and under it) it offsets them so they look weird

If it got broken there was nothing 'correct' about how you did it. Looking at that river I see no way this could have ever worked unless something in that code was not correct. The underwater area's floor is 10 map units lower than the normal one and that's precisely how the sprites look now.

Which specific places do you need saves for to help test?

Do you know when it was last working?

[Scuba Steve]

Why is it that such behavior doesn't raise an alarm in you telling, 'Wait a minute! This can't be right. Better file a bug report.' No, instead it gets abused to hell making any attempt to work with the code a futile endeavor.

Because for 3 years while I developed AD2, stacks stayed the same? This wasn't a "bug" so much as "The way you get the shitty stacks to work in ZDoom". Essel and I had a bunch of discussions over those years about making these things work properly and what tricks allowed them to function better. I'm sure he used this trick as well.

[Gez]

Why is it that such behavior doesn't raise an alarm in you telling, 'Wait a minute! This can't be right. Better file a bug report.' No, instead it gets abused to hell making any attempt to work with the code a futile endeavor.

Honestly, this is consistent with the behavior for faked deep water/hidden pits, and the vanilla sky hack, so I don't really see it as an abuse.

[Graf Zahl]

What's consistent here? A sector not having a portal set but still getting one transferred to it by some strange voodoo sounds horrendously wrong to me. And the deep water analogy makes no sense whatsoever.

The problem is, the portal code was essentially broken all the time. Don't forget that Randy quickly threw this together without any refinement - and one of the things that got missed was to check for some stuff when processing sectors with identical neighboring textures. So portals essentially bleed into neighboring sectors which they never should have done. It was a complete fluke and at no time documented behavior.

This whole 'it does what I want regardless if it doesn't make sense to do it this way' attitude of Doom mapping is an utter nightmare for an engine developer. Here some half-finished feature got release, never properly documented and once you go back at it people have picked it apart, found all the loopholes in it and abused them. No chance to fix the feature anymore.

To make a long story short, the only way I see to fix these maps is to undo each and every portal change I made in the last year - because I have no idea how to address it in that mess of code that is the software renderer. That would mean dropping Sector_SetPortal because the changes I made were all to make that function work.

[Scuba Steve]

This is the ultimate bitch of making maps for ZDoom... how do I know what is a feature, a quirk, or a bug? What things will stop working in the next version? for 3 years of AD2's development, the portal code didn't change for stacked sectors. There was really no documentation or anything... we went with what worked and learned to make them function.

Of course I want to see stacked sectors improve, they were absolute shit to work with. But I used the tools at hand to make the engine do what I wanted... but apparently it was a "bug"... that went unfixed for almost 5 years. You really can't blame me for my implementation of a feature that stayed broken for the entire time I was developing the project. Same for the Rocks in the river. Stacks cut off sprites so I needed a way to display things coming OUT of the water. Placing double objects in the same exact place in 2 stacks worked... but something changed after 5 years that broke it.

[Graf Zahl]

This is the ultimate bitch of making maps for ZDoom... how do I know what is a feature, a quirk, or a bug? What things will stop working in the next version? for 3 years of AD2's development, the portal code didn't change for stacked sectors. There was really no documentation or anything... we went with what worked and learned to make them function.

Honestly, from looking at your WAD I more get the feeling that you tinkered around with the feature until it produced something that you wanted to see. I have never seen portals being abused like this before.

The reason portals didn't change in the last 3 years was - well - nobody was working on the code. However, earlier this year I implemented a much better portal definition feature when it got problematic. Let's face it: The thing based portals are a godawful hack that should have never made it into production code as it was. It wasn't thought through to the end, just some quick test case to see if it works, that was abandoned when it turned out that it didn't fully work.

And then - people started using it anyway - most in a sane and logical manner - a few mildly abusing the quirks it exhibited based on piggybacking on the sky code - and of course there had to be one person who wasn't satisfied with this and pushed the incomplete feature almost to the breaking point. And - big surprise - this got broken first the moment the code was cleaned up a bit to make it more usable.

Well, there's one thing I think I can do to address at least the issue with the floating bits - but it will require to make portals completely static because I have to analyze these things at map start and set up the portals as proper data structures. It will also have a few other implications. Right now the portals are just two stackpoint things linked together with no real definition backing it up. For a preliminary testing case perfectly fine but again something that should never have gotten into production code to begin with.
But for the record: This portal bleeding was never a feature, only a glitch. As such I'd prefer to make it abundantly clear that it should no longer be used as an editing feature. More precisely, the portal things should be considered deprecated in favor of the [wiki]Sector_SetPortal{/wiki] line special.

The bottom line here is: If you use a documented feature in a way that's part of the documentation you are safe. If you use side effects that are not mentioned in the documentation there's always a slight risk that it might break. But if you use a poorly documented feature and exploit traits that aren't mentioned anywhere you are on very, very shaky ground. Even more so if the feature you are using had been abandoned.

[InsanityBringer]

well, goodbye hpack h1m0 then...

edit: or maybe not, despite the fact that I heavily use portals with skies.

[Scuba Steve]

Honestly, from looking at your WAD I more get the feeling that you tinkered around with the feature until it produced something that you wanted to see. I have never seen portals being abused like this before.

Which was pretty much what we all did with portals for the first 3 years. Documentation was scarce and what we did have was broken with little hope for being improved. I may have used portals "creatively" but it was well in line with the requirements to make it work at the time. ZDoom is always in a state of flux and how are we, as modders, supposed to know what is broken, quirky or unfinished. We work with what we have... there were never warnings or suggestions "Don't use them this way, it's broken"... they were always this way and we, as developers, had to implement them as they were. How could we know that, 5 years later, they would cease functioning as they had for the entire development period.

That aside, I want to get AD2 working with the latest exe because I have an add on level I want to use, but I don't want it to break the exe that came with the wad or have to rebuild every level. I can make minor changes... but fixing every portal error is too much work.

[Scuba Steve]

well, goodbye hpack h1m0 then...edit: or maybe not, despite the fact that I heavily use portals with skies.

Yeah, portals with skies seems to work... but I had several cases where I used standard flats instead of fsky because it would interfere with a skybox if used as a portal, too.

[Graf Zahl]

Honestly, from looking at your WAD I more get the feeling that you tinkered around with the feature until it produced something that you wanted to see. I have never seen portals being abused like this before.

Which was pretty much what we all did with portals for the first 3 years. Documentation was scarce and what we did have was broken with little hope for being improved. I may have used portals "creatively" but it was well in line with the requirements to make it work at the time

The rule of thumb should be: Does this make sense?
Does it make sense that a portal shows in a sector where none is defined? The answer to any logically thinking person should be a clear and resounding 'no'! After all skies also don't show in sectors where none is set.

I sadly spotted this issue far too late to fix it. Too many maps abusing it were already out. I tried to preserve the effect with my latest changes but apparently I missed something in that code. But since this is "ZDoom's Software Renderer (tm)" we are talking about code that does not want to be fixed. It doesn't even want to be changed or it spits back at you. I currently have no idea what to do with this other than tearing the portal code even further apart in the hope that I can piece something together again that preserves the old hacks while being more stable.

For newly made maps my strong advice is to use Sector_SetPortal instead of the portal things. It's much more robust and well defined and doesn't require to depend on engine glitches to fill in the holes.

[Gez]

Well, there's one thing I think I can do to address at least the issue with the floating bits - but it will require to make portals completely static because I have to analyze these things at map start and set up the portals as proper data structures. It will also have a few other implications.

Can't it be made as a compatibility mode then? It'd avoid preventing further extension if the need for staticity is limited to maps with a compat option on.

[Graf Zahl]

Not really. The portal code suffers from a complete lack of definition. Once you add that definition in the old stuff won't fully work anymore and as long as the old stuff is left in the linedef based portals won't work and the whole feature will remain in an unstable state. And the way portals are handled are different enough so that these can be kept in the code at the same time. It's either or.

In GZDoom portals with non-static components will break completely anyway (because I do not use the stackpoints for anything but calculating the initial displacement for the portal) and I haven't seen a map yet that uses some. Due to portal merging most of this is no longer possible anyway (fortunately) and I'd rather plug this hole for good before anyone cooks up something crazy that will ruin this feature's future forever.

[Xaser]

Hmm, I probably need to give Zen Map04 another look. Knowing myself, there are probably similar errors all over the place, considering how hacky everything in that wad is. Not that it doesn't need an update already, of course.