search

chocolate-doom / chocolate-doom

Chocolate Doom is a Doom source port that is minimalist and historically accurate.
https://www.chocolate-doom.org/
GNU General Public License v2.0
1.95k stars 572 forks source link

auto-detect tnt31.wad when using unpatched TNT IWAD #763

Open jmtd opened 8 years ago

jmtd commented 8 years ago

The following feature request was sent to me via PM on the Doomworld Forums. Forwarding here...

"If tnt.wad is chosen as the game the user wants to play and tnt31.wad are both in chocolate doom's root directory, have Chocolate Doom auto load tnt31.wad alongside tnt.wad, since this fixes the yellow key card glitch for the Egypt level (MAP31).

That should be fairly trivial to implement.

If you decide to do the above, the chocolate doom readme might also want to point to https://www.doomworld.com/idgames/t...aldoom/tnt31fix , as well."

fragglet commented 8 years ago

Sounds like a good idea. This is conceptually similar to the chex.deh autoloading.

chungy commented 8 years ago

Like chex.deh, I think tnt31.wad would be best found in the same IWAD search path. We also should have a way to disable loading it, like Strife has with -novoice. Otherwise, it can introduce demo incompatibility.

I'm split on whether this is a good idea. It's not vanilla behavior, but it does fix a game play feature. I'm not entirely fond of adding another switch to Doom, either. Since an officially-fixed IWAD does exist, I might even say to just leave it entirely like vanilla, use -file tnt31.wad or patch your IWAD with one of the unofficial patches, or even just buy the fixed IWAD via GOG.com.

fragglet commented 8 years ago

Yes, same directory as IWAD seems like the most sensible option.

jmtd commented 8 years ago

Like chex.deh, I think tnt31.wad would be best found in the same IWAD search path.

+1

We also should have a way to disable loading it, like Strife has with -novoice. Otherwise, it can introduce demo incompatibility...I.'m not entirely fond of adding another switch to Doom

This is a niche enough problem that the solution to that could be "user moves tnt31.wad out of the IWAD search path". IIRC the only change is MAP31 so the only desync we're talking about would be a demo recorded on the unwinnable level. And I think it would only desync if the player had recorded a sequence of actions on the unwinnable level that resulted in them picking up the key and opening the key door on the patched one.

finnw commented 8 years ago

And I think it would only desync if the player had recorded a sequence of actions on the unwinnable level that resulted in them picking up the key and opening the key door on the patched one.

There are non-trivial differences between the NODES of the two versions, and this has been known to cause desyncs.

nodesview_from_tnt_iwad nodesview_from_tnt31_pwad

Gaerzi commented 8 years ago

Should not be loaded if the TNT.wad in question is the fixed anthology/GOG version.

jmtd commented 8 years ago

There are non-trivial differences between the NODES of the two versions, and this has been known to cause desyncs.

I think the importance of this is overstated, since the old map is unwinnable without the patch, I can't see the point of recording/playing demos on it. However, the auto-load behaviour could be disabled when -playdemo is selected.

Should not be loaded if the TNT.wad in question is the fixed anthology/GOG version.

Absolutely, although it would be harmless would it not, since the PWAD and the IWAD MAP31 would be identical.

chungy commented 8 years ago

I think the importance of this is overstated, since the old map is unwinnable without the patch, I can't see the point of recording/playing demos on it.

Not entirely. There's a well-known workaround for the missing key, and full IWAD runs are likely to employ it.

Gaerzi commented 8 years ago

Absolutely, although it would be harmless would it not, since the PWAD and the IWAD MAP31 would be identical.

Not sure about that... Here are the ZDoom mapchecksum results for all three versions of the map. 4BB9FB803878B133CE5D683B09F33751 // tnt31fix.zip:tnt31.wad map31 A53AE580A4AF2B5D0B0893F86914781E // Final Doom/Steam TNT.WAD map31 55192065F7FAA7D161767145DA008293 // Anthology/GOG tnt.wad map31

jmtd commented 8 years ago

Hmm ok, thanks!

fragglet commented 8 years ago

Should not be loaded if the TNT.wad in question is the fixed anthology/GOG version.

Not worth the added complexity IMO. We'd only load tnt31.wad if it was present in the same directory as the IWAD (ie. the user put it there). If you have the fixed version, just don't put it there. Even if you do, it's a no-op patch.

Okay, reading the latest comments I see it's far more complicated and not a no-op patch after all. But I still think that "if you have the Final Doom/Steam version then don't put tnt31.wad next to your IWAD" is pretty reasonable.

Gaerzi commented 8 years ago

It's the GOG version that doesn't need it. ;)

fabiangreffrath commented 8 years ago

Sorry for the late complaint. But why should we implement a non-Vanilla feature in Choco and then invent another command line switch to disable it?

If the plan is to have tnt31fix.wad in the IWAD directory, then loading the fix is as easy as adding -fie tnt31fix.wad to the command line anyway. This leaves full control to the user about which WAD the MAP31 gets loaded from (think of demo and netgame compatibility) and also maintains the principle of least surprise.

In general, I don't think it's the source port's job to add additional PWADs at all. In Debian, we have a nice tool called "game-data-packager" which creates .DEB packages from WAD files and automatically adds tnt31fix.wad to tnt.wad. It gets loaded along the IWAD if started from the desktop environment by means of a tnt-wad.desktop file:

https://anonscm.debian.org/cgit/pkg-games/game-data-packager.git/tree/data/final-doom.yaml#n39

haleyjd commented 8 years ago

Besides the nodes I'll note that just spawning an extra mobj_t is enough to desync a demo, due to the P_Random() call that is invoked to modify the first spawnstate's tics.