Should source ports have a responsibility to fix bugs/issues from Vanila Doom?

[,,,]

I was going to play through Doom 2 (through GZDoom) when my playthrough was rudely interrupted by the double stair bug in MAP07: Dead Simple...:

It got me thinking... we've advanced so far in terms of source ports, and obviously vanilla-accurate ports like Chocolate Doom or DSDA-Doom shouldn't do this, but should source ports like GZDoom be fixing bugs and issues like this that were present in vanilla Doom that degrade the gameplay experience? This doesn't just apply to engine and general bugs, but also map/.WAD (design) issues like TNT MAP31 could be automatically detected and patched.

[dasho]

I think they have a 'responsibility' to implement what they see fit.

[Shepardus]

IDK about MAP07 (arguably not a problem since you can still straferun from one of the metal platforms to the exit, or in ZDoom just jump), but GZDoom does automatically fix TNT MAP31's missing key.

[sean-dude]

GZDOOM did fix this bug... It's called the jump button lol.

[StarTanned]

Personally, if there's enough interest, and if it wouldn't start legal or ethical wars, it would be interesting to see the community come up with pwads which just take the original episodes and fix these kinds of bugs (softlocks, mis-tagged secrets and stuff, etc) within reason. That way it would work across ports, and the ports wouldn't have to hack up their engine for it. But it honestly sounds quite marginal for the effort involved.

[,,,]

4 minutes ago, StarTanned said:

Personally, if there's enough interest, and if it wouldn't start legal or ethical wars, it would be interesting to see the community come up with pwads which just take the original episodes and fix these kinds of bugs (softlocks, mis-tagged secrets and stuff, etc) within reason. That way it would work across ports, and the ports wouldn't have to hack up their engine for it. But it honestly sounds quite marginal for the effort involved.

Double stairs bug can't easily be fixed in vanilla to my knowledge.

[StarTanned]

13 minutes ago, Individualised said:

Double stairs bug can't easily be fixed in vanilla to my knowledge. 

 

True, I'm not sure if it would actually work to add thin second stairs around the main ones, which rise up only half as high on 667 using a custom texture, but it might be doable (it would probably take several layers of "thin stairs" just in case the stairs rise up more than one extra time, but still: this is the kind of effort I was talking about).

[Biodegradable]

Were you playing on GZ's Vanilla compatibility (Doom Strict) setting or Default?

 

The presence of Doom's original engine quirks and bugs, as you're aware, very much depends on the intentions of each individual source port. Ports don't have the "responsibility" to do anything beyond what the programmer(s) wish to achieve with it, but you already knew that. If you're playing with GZDoom but want it to mimic vanilla gameplay to the best of its ability, well that includes Doom's bugs like the MAP07 example. If you don't want that to happen, then switch the compatibility back to Default.

 

However, if this happened with you playing on Default, then that's a completely different kettle of fish and you might need to send the ZDoom team a bug report.

[Devalaous]

Im pretty sure GZDoom already does automatically patch some IWAD levels. I know at one point the broken secrets were automatically removed from E4.

I also bound noclip to a key for bullshit like the OP's situation.

[,,,]

9 minutes ago, Biodegradable said:

Were you playing on GZ's Vanilla compatibility (Doom Strict) setting or Default?

 

The presence of Doom's original engine quirks and bugs, as you're aware, very much depends on the intentions of each individual source port. Ports don't have the "responsibility" to do anything beyond what the programmer(s) wish to achieve with it, but you already knew that. If you're playing with GZDoom but want it to mimic vanilla gameplay to the best of its ability, well that includes Doom's bugs like the MAP07 example. If you don't want that to happen, then switch the compatibility back to Default.

 

However, if this happened with you playing on Default, then that's a completely different kettle of fish and you might need to send the ZDoom team a bug report.

As far as I know, compatibility settings were default though I'm not certain.

[Biodegradable]

1 minute ago, Individualised said:

As far as I know, compatibility settings were default though I'm not certain.

 

How old is your version of GZ?

[,,,]

2 minutes ago, Biodegradable said:

 

How old is your version of GZ?

4.10.0 stable

[indigotyrian]

depends on the source port but generally speaking having the option to tweak and fix up bugs is always a good thing, as long as they can be turned off if desired. As far as "responsibility" I don't think source ports have any responsibility to do anything except not destroy your hardware or files.

 

Really what you gotta fix is that gamma man

[Biodegradable]

Just now, Individualised said:

4.10.0

 

Weird. You should definitely double-check by testing MAP07 on both Doom Strict and Default and see which one replicates that bug. If it's the former, then it's fine. If it's the latter, then send a bug report.

[,,,]

Just now, segfault said:

depends on the source port but generally speaking having the option to tweak and fix up bugs is always a good thing, as long as they can be turned off if desired. As far as "responsibility" I don't think source ports have any responsibility to do anything except not destroy your hardware or files.

 

Really what you gotta fix is that gamma man

"Responsibility" was definitely not the word I was looking for. Something more like being expected to fix something. All source ports of course have their own goals.

 

(I'm often playing with my screen brightness at almost Gameboy Advance levels of darkness so I up the gamma to compensate; and now I'm just used to how it looks)

[OpenRift]

I think the "responsible" way of handling them would be to maintain them if vanilla complevels are set, which is what most source ports do (except for ZDoom-derivative ports).

[Edward850]

The issue with fixing the MAP07 "bug" is no component about it is actually broken, everything is doing what it's supposed to do correctly, but the logic used is itself is incorrect. The stair raises twice because Arachnotrons call the function at the end of their death animation rather than at the start, and the function checks if all enemies are dead so it can be triggered twice due to the timing gap.

 

So if everything did their task correctly, what are you changing to fix it, and is this going to break another mod? You can't change the raise function used, that is guaranteed to break another map. You can't change the frames of enemies as this changes the expected codepointer frames dehacked expects. You also can't even force the death trigger to only fire once, because reviving a monster to fire the trigger again is entirely a valid condition for a particularly creative custom map (either with Archviles or for nightmare). You can't just go changing specific things as it can all have a knock-on effect from what people expect to work elsewhere.

 

GZDoom ends up being a really good example of this, it has pages of map compatibility fixes just to handle its own moving standards.

[Fiber Wire]

No, but it is their responsibility to fix bugs they induce from version to version of the source port that were not in the original game.

[Sneezy McGlassFace]

It's fine for source ports to alter the behaviour as they see fit, as long as they're very clear about that. 

For example (G)zdoom changed a whole lot of things, which is great but that also means it's not compatible with other ports. Fixing the collision and blockmap and stuff is great, it makes the general purpose engine objectively better. But if I'm making a vanilla or boom map, I won't test in (g)zdoom much as a result. If, on the other hand I'm making a hexen-format map, the changes (g)zoom made are very much appreciated. 

[Sneezy McGlassFace]

Imagine if dsda fixed the blockmap. 

[prfunky]

Wow.

Just wow.

I'm with the responding poster, @StarTanned as far as way-diminished return for the effort

involved.

 

I'm grateful for the ports of DooM I use. It doesn't seem that way sometimes when I complain

about lack of documentation or features I'd like to see enhanced and/or fixed in some way. But

I really don't have anything to complain about. A soon to be thirty year old game has given me

about 25 years of entertainment in my life. That's a helluva track record! Most DooM annoyances

don't even come close to the hell Microsoft, Google and Facebook put me through. That stuff

just sucks!

 

So I'm just going to use the rest of this response to be thankful for the things I have; in no

particular order:

Doom; for coming into existance.

Doom II; for numerically sensical level jumping instead of Chapter X, verse Y.

iD; for being open with their tools from day ONE.

iD again; for opening up the source code later.

ZDoom; for expanding the capabilities.

ZDoom again; for begetting ZDaemon and Skulltag.

Skulltag; for the basis of Zandronum.

DECORATE; because it's SO KICK A$$!!

Doomworld; for even more entertainment

 

[GarrettChan]

22 minutes ago, Sneezy McGlassFace said:

Imagine if dsda fixed the blockmap. 

That's the day I'll stop using DSDA-Doom

[Shepardus]

30 minutes ago, Sneezy McGlassFace said:

Imagine if dsda fixed the blockmap. 

Woof has an option for it.

[Professor Hastig]

10 minutes ago, GarrettChan said:

That's the day I'll stop using DSDA-Doom

 

Nobody can "fix the blockmap" without adding an option to toggle it. The fix is arguably needed for new non-Doom content but can have a profound impact on the original game. On the other hand, isn't it cool being able to blast a Spider Mastermind with a single BFG shot...? :)

 

3 hours ago, Edward850 said:

GZDoom ends up being a really good example of this, it has pages of map compatibility fixes just to handle its own moving standards.

 

It does, but if you look closer you will also see that a very large portion is not to address engine incompatibilities but simply to fix mapping bugs like unclosed sectors, missing textures or even some badly tagged sectors which can soft-lock a map.

[Sneezy McGlassFace]

1 hour ago, Shepardus said:

Woof has an option for it.

Interesting. I assume it's opt-in. That's a good way to do it. 

[Stupid Bunny]

Certain bugs, in particular the resurrected ghost monsters, the weird zombie player bug, and the fast rising donut sector bug, are exploitable enough that fixing them can actually break some map tricks that require them (I speak from experience).  Modern source ports thankfully tend to include compatibility settings to address some of these, but they don’t always work as intended. Doom’s code is pretty janky a lot of the time and a lot of behaviors like the MAP07 rising stairs were designed on the fly for a single use case as opposed to be robust and neatly applicable to 30 years of mapping content. Because a lot of these oddities are also exploitable—I can imagine ways to exploit this one right now—it’s nice to have sourceports that make no attempt to regularize these bugs, and as @Edward850 points out, a lot of times there is no way to do so that won’t introduce new problems of its own, backwards compatibility aside.

[zokum]

The blockmap bug goes both ways. You can miss monsters, and they can miss you. Since monsters move about randomly and a player can align to the block boundaries to increase the chance of misses, it should benefit the player more. And since it is a gradual improvement, pixel perfect positioning isn't needed. For each 128 wide block there are 32 pixel wide strips with decreasing damage taken along each axis. Most damage is avoided at exactly in the middle here.

In short, certain routes in maps will make you take less damage. This has been known for a long time, and has been used in nightmare running where taking less damage is very important. I verified this with a well known runner last year.

Doom 2 Map02 becomes a LOT harder if all the gunfire from enemies are unaffected by this blockmap bug.

Max kills where landing more damage on monsters is important, it will most likely benefit the player more.

When I updated the blockmap code in ZokumBSP the player would sometimes die in encounters it previously survived on nm runs due to taking more damage when the offsets were moved and block boundaries were different. One such area is the outdoor area on map02.

[Kinsie]

8 hours ago, Devalaous said:

Im pretty sure GZDoom already does automatically patch some IWAD levels. I know at one point the broken secrets were automatically removed from E4.

There are a lot of automatic fixes GZDoom silently applies as needed to ensure IWAD and classic maps work as expected, as well as fixing various original bugs, applying missing textures, and marking certain decorative/unreachable actors as not counting towards 100% kills/items. To see this for yourself, open gzdoom.pk3 and check compatibility.txt to see what maps get auto-applied compatibility flags (for example, enabling ghost monsters on HR1 MAP26) and zscript/level_compatibility.zs to see actual changes to level data and such (for example, unflagging some secret sectors in Hell to Pay MAP14 that can't be reached without jumping and crouching).

 

If you're feeling zesty, you can write your own compatibility patches (or... alterations to fit your mod's needs...) by creating a ZScript actor that inherits from LevelPostProcessor. One day I'll write up an article about some of the tricks you can pull with this...

[StarTanned]

I'd say it would be more interesting to make the blockmap bug a reliable gameplay mechanic somehow, rather than a whoopsie. But of course doing so in a way that still feels like classic Doom and doesn't ruin the gameplay balance is tricky, and you'll likely end up making a new game by the time you're done. So I'd say it's one of those bugs that's best to leave up to the mappers and players, not the engine. But still, it's fun to picture playing classic Doom with a simple intimidation or surprise tactic which leaves enemies a bit more vulnerable in a consistent way, and if you push it too far enemies get aggressive back and go all ghosts or something.

[Wagi]

The problem is for virtually every bug you can fix, there is some map that depends on that bug in order to function properly. There could be some map, for example, that might rely on this behavior for a secret ("Kill these Arachnotrons fast enough for this BFG and Megasphere to be reachable") and then it's suddenly up to the player to know ahead of time to turn on a compatibility flag before playing the level. You have to be careful what you do and don't fix.