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

[Professor Hastig]

From my understanding there is no way to make the blockmap bug reliable. It is just that if an actor is on a block boundary some things won't work. But the block boundary is undefined - it depends on the blockmap generator being used where precisely it is. No tool is capable of customizing it.

 

[GarrettChan]

7 hours ago, Professor Hastig said:

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...? :)

Obviously I know this, but I've never use it anyway.

 

Funnily, when talking about bug fixing, why nobody wants SR40 to be fixed. It's a bug!

[Nine Inch Heels]

The only responsibility source ports should have as far as I'm concerned is to inform their supposed users - in no uncertain terms - what the respective source port does instead of claiming to be accurate, or "strict".

 

Other than that, no source port should have any responsibility to fix anybody else's mistakes or oversights - no matter how severe the mistake, no matter who is at fault - because at the end of the day it's not the source port's fault that a mapper messed something up. Besides, placing the burden on the source port developer to fix however many issues, in however many maps, created over the course of however many years... is a stupid idea.

[Murdoch]

19 hours ago, dasho said:

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

 

This. I don't understand the original post at all. Like why would a source port author do anything other than what they want? Does the OP want some kind of governing body established?

[Individualised]

45 minutes ago, Murdoch said:

 

This. I don't understand the original post at all. Like why would a source port author do anything other than what they want? Does the OP want some kind of governing body established?

I used the wrong word as I explained in another post.

[Mr. Alexander]

As far as expectations for bug fixes in the iwads go, it depends on the source port and its stated goals. I would expect Chocolate Doom to emulate the very most annoying bugs of the original Doom executables, and would consider it a scandal if it failed to do so without an excellent reason, because its creators intended it as a way to preserve the original experience of the game for posterity, as well as to check modern "vanilla" maps for true vanilla compatibility. GZDoom fails to do this, but I don't mind that, because GZDoom's creators intended it to run fancy maps and mods with interesting feature sets far beyond what the original executables could have done. It sacrifices demo compatibility for the ability to create strikingly modern-looking video game levels.

 

If GZDoom went out of its way to fix weird little issues in specific iwads, it wouldn't bother me much, because it doesn't exist for purists, but if DSDA-Doom or Chocolate Doom, which do set out to serve purism of various kinds, did that, it would disturb me.

 

Generally speaking, I don't expect any source port to fix specific bugs in the iwads' maps rather than general issues arising from the way the original executables were programmed. If a source port fixed the blockmap bug, that would be fine, but I would think it was a little odd if it fixed an untextured wall in TNT or something.

[BigBoy91]

It all depends on the scope of the port.

[Individualised]

17 hours ago, Edward850 said:

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.

There's probably a reason why this couldn't be done otherwise you would have probably mentioned it, but couldn't they just do a compatibility patch so that the trigger only fires once if Doom 2 IWAD MAP07 is being played, without affecting maps that might actually take advantage of the bug? GZDoom already has similar compatibility patches for other IWAD levels and even detects some PWADs too.

14 hours ago, prfunky said:

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

 

Don't take my post as if I'm ungrateful for all of the amazing work done in the Doom community on source ports. Rest assured, I'm grateful for ZDoom and GZDoom in particular, I would go as far to say as it is one of the most positively impactful on my life entertainment-related programs that I've used.

Edited March 14, 2023 by Individualised

[Gez]

8 minutes ago, Individualised said:

There's probably a reason why this couldn't be done otherwise you would have probably mentioned it, but couldn't they just do a compatibility patch so that the trigger only fires once if Doom 2 IWAD MAP07 is being played, without affecting maps that might actually take advantage of the bug?

This would require adding more level flags and more special-casing code and introduce a counter to the BossDeath function. I don't see that happening, the bug is rare enough (you need to get the timing just right for the deaths of the last two arachnotrons) that the additional code weight will not be worth the trouble.

[Professor Hastig]

There's another gotcha here: Where to stop? I think that 99% of all MAP07 clones intend the sector raise to occur only once, not just the original.

So who decides which ones need it and which ones do not? What parameters define what decision is being made?

 

In all my years of playing Doom I never managed to trigger this. There is a very small window where this happens. If the time gap between those two deaths is too large the first Arachnotron will not register the second one's death and if it is too small the active movement will block the second action.

 

[zokum]

On 3/14/2023 at 2:50 PM, StarTanned said:

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.

It is reliable. It will happen in the exact same areas in a map every time you play it. The Doomwiki unfortunately doesn't explains it very well, especially on a per map basis. I've tried to correct it, but my edits got reverted. Some of the listings are fairly non-sensical, plain wrong and they are almost all too inaccurate to be of any help.

From the article https://doomwiki.org/wiki/E1M6:_Central_Processing_(Doom)
 

The following actions can trigger the blockmap bug:

* Firing eastward or westward at the north edge of the slime walkway in the first room.

* Entering the first room from the south (via secret #2).

* After leaving the first maze room to the east, turning right to face the first imp (ITYTD and HNTR) or the first two imps (HMP, UV, and NM).

* Leaving the dark computer room by the west door, passing the column at the top of the stairs, then firing eastward.

All of this is more or less pointless and confusing. Especially the second point makes little sense. It's mostly just people writing down random locations they noticed the bug. A map like e1m6 has hundreds, if not thousands, of 'areas' where you can be affected by this bug.

In nightmare it most likely benefits you more than it hinders you. Monsters that fire instant weapons are often the most lethal since their damage cannot be dodged. By running 'on' or near block boundaries you lower the incoming damage.

A simplified explanation would be: In certain areas, for every 128 pixels in both directions, the boundary box of objects become smaller. It is at it's smallest (half the size) at 0, 128, 256, 384 etc. When not quite a these magic values the hit box gets gradually bigger. The blockmap bug is when projectiles should hit, but are instead passing through that area where the boundary box is cut short.

The bug happening to a single bullet is something binary, it happens or it doesn't. The change in size of the hit box is gradual.

The name is also fairly bad, as there are several known bugs in the blockmap code in Doom 2. Blockmap (block) boundary bug would be more precise.

[StarTanned]

@zokum of course, but it's only reliable in the sense that it's repeatable in contrived and unintended ways. It's not at all reliable as a gameplay mechanic which players and mappers are intended to be able to use to their advantage. It scarcely matters in the end, but I feel fixing it or making it a proper, expected gameplay feature is the way to go, unless aiming to make a strictly demo-compatible port. I'm happy to be wrong though :)

[zokum]

18 hours ago, StarTanned said:

@zokum of course, but it's only reliable in the sense that it's repeatable in contrived and unintended ways. It's not at all reliable as a gameplay mechanic which players and mappers are intended to be able to use to their advantage. It scarcely matters in the end, but I feel fixing it or making it a proper, expected gameplay feature is the way to go, unless aiming to make a strictly demo-compatible port. I'm happy to be wrong though :)

That's where you're wrong. It's fairly easy to use this as a player. I asked one of the best compet-n players about this a while ago, and he confirmed that they did plan their routes to cross areas in certain locations in order to increase survivability. The exact term he used isn't easy to translate correctly into English, but it can be translated as 'using and finding good lines'. Finding good lines to run is a combination of line of sight and hit box reductions. It might be something as simple as running at the right side down a tunnel will make you take less damage than running at the left side. What the people I talk about here didn't do was to find the sweet spots (areas really) by looking it up and then planning the route based on that. By reducing the trial and error aspect, one could perhaps increase the odds of beating maps without taking excess damage.

Another player told me about a sweet spot on Dwango 5 map01 where you could 'camp' and still be quite hard to hit. An ideal spot would be a location where the vulnerable part of the hit box would be mostly hidden by a column. Shots would either hit the column or pass right through. In essence the player becomes only a few pixels wide. In this case it was explained that it was very hard to hit the player with bfg tracers and ssg shots. On the other hand this didn't affect that player's opportunities to shoot opponents. Thus it was a good camping spot.

I did add the ability to set different offsets, and therefor manipulate this, in ZokumBSP. I could probably cook up a map to show how this can be used.

[Gez]

"Fairly easy to use as a player" and "technique learned by the best speedrunners" are not things that fit together that well.

 

Most players will not do so many runs through the same level that they bother to seek "the good lines".

[zokum]

As far as techniques go, it is easy to do it, but there's not that much to gain from them in casual play. It's a bit like SR50 and wall running. Rather easy to do, but not something most players use or need. Knowing where the boundaries are could also help in high-end deathmatch. All you do is go from A to B, along a straight line, axis-aligned.

The nice thing about this is that the reduction is gradual. If your player has a 32 pixel wide hit box, you can "remove" about 16 pixels of that if you're doing it perfectly. However if you're 8 pixels off the line, then your hit box is reduced by 8 pixels. It works on both sides, so you basically have strips of 32 pixels, where the effect is highest in the middle. So out of every 128 pixels of floor texture, 32 of those have reduced hit box to some degree.

So even if you weave back and forth across the lines, you can still get some effect. Since a lot of textures are axis aligned and this effect is axis aligned, you generally only have to know that in a room on every other repetition of the floor texture, that is where the perfect line is. Hard to do on 'grass' but fairly easy to do on tiles-style flats.

If you used a port that had support for 128x128 floor textures, you could change the flats to one that displays this as a color coded area. Then it wouldn't be hard to plan routes or learn where to run. You could also use idmypos if you knew the blockmap data block offset in order to compute if you are in a good position.

Doom has loads of things that are easy to do, but can improve your game in marginal situations. Since the two first shots from a chain gun are always dead center, shooting in bursts of two shots to avoid the spread can be a way to increase accuracy when doing long range shooting. Strafe running is another popular technique. Makes it harder to navigate, but you do get a higher effective top speed.

Edited May 23, 2023 by zokum

[zokum]

On 5/23/2023 at 10:21 AM, Gez said:

"Fairly easy to use as a player" and "technique learned by the best speedrunners" are not things that fit together that well.

 

Most players will not do so many runs through the same level that they bother to seek "the good lines".

You're moving the goal post here. It's still a reliable and easy to implement strategy, if you need it or want it. The percentage of players using it actively isn't relevant at all.

The original statement was: "I'd say it would be more interesting to make the blockmap bug a reliable gameplay mechanic somehow, rather than a whoopsie."

And my point is that it is a reliable gameplay mechanic, but not all that useful in most cases. For some corner cases like nightmare speed running it can be quite helpful. Since monsters tend to move around quite randomly, it isn't all that useful to check out where it affects them, but in corner cases like narrow passages it can be quite important. For players, it can be used fairly easily, if you need it.

From what I can remember when testing code related to this, it can make the maps harder if they have a lot of hitscan enemies. You normally have a reduced chance of taking damage in about 25% of the map. It goes from next to no reduction to half the size of the hit box. There are other complications at play here as well, like your hit box being square, making it harder to hit things depending on the angle of the shot.

What I like about this is the tradeoff aspect. By positioning more carefully, you spend slightly more time, but gain survivability.