How to proceed with special linedefs without tag?

[fabian]

Hi there,

I am currently facing the problem that I have to decide how to further proceed with special linedefs without tag in Crispy Doom. The actual example in this case is linedef #2150 in 7sins.wad which has type 106 "WR Open and stay /fast" but no tag applied. Due to this, the linedef action is applied to all untagged sectors in the map once the line is crossed and thus the map is instantly wrecked and impossible to quit. Strictly speaking, this is a mapping error, sure, but I want my port to be robust against this and still maintain Vanilla compatibility as far as possible.

Currently, I see three alternatives how to deal with these linedefs:

1. Apply the linedef action to all untagged sectors. This is what Vanilla does, so it's authentic. On the other hand it will almost certainly wreck the map and is probably not what the map author intended.
   
2. Ignore the linedef. This is the safe choice, nothing will happen. On the other hand, if nothing happens, this is probably also not what the map author intended.
   
3. Apply the linedef action locally to the linedef's backsector. This probably comes closest to the map author's original intention. On the other hand this is still a mapping error and map authors will probably not get aware of their own mistake.
   

Are there any other alternatives that I am missing here? Or is it somehow possible to heuristically determine which alternative is the best choice in-game? I am not going to add a switch in the menus about it, that's for sure. ;)

Thanks,

Fabian

[Vorpal]

option #2 and #3 both result in unintended map behavior, especially 3. If the action is applied to the backsector, and we're talking about a closed door, then how does the player ever cross the linedef? Also what if there is a map out there that makes use of the 0 tag?

[Graf Zahl]

Vorpal said:

option #2 and #3 both result in unintended map behavior.

And option 1 is not? Show me even one map where affecting 90% of the map will actually create intended behavior.

I think the only good solution would be 2, unless you are willing to add an option to allow 3 for the rare map that needs it.

[Maes]

You do realize that the goals of "vanilla authenticity" (in the sense of demo/bug compatibility) and robustness/heuristics are often mutually exclusive, right? Especially when you modify things that affect the gameplay.

A good solution IMO would be to detect and report such anomalies upon map loading e.g. in the console and let the user decide if they want to apply a fix. Those include malformed BLOCKMAP and REJECT lumps.

[Vorpal]

Graf Zahl said:

And option 1 is not? Show me even one map where affecting 90% of the map will actually create intended behavior.

I think the only good solution would be 2, unless you are willing to add an option to allow 3 for the rare map that needs it.

Option 1 only results in unintended behavior if an author doesn't even bother to play their own map. It also makes the most logical sense in that tag 0 triggers should affect tag 0 sectors. It also is super super super obvious when you've edited a map improperly, and see the entire map shift from triggering the one linedef.

[fabian]

Maes said:

You do realize that the goals of "vanilla authenticity" (in the sense of demo/bug compatibility) and robustness/heuristics are often mutually exclusive, right? Especially when you modify things that affect the gameplay.

Yes, of course I know. But often, a certain compromise is possible and actually reasonable.

A good solution IMO would be to detect and report such anomalies upon map loading e.g. in the console and let the user decide if they want to apply a fix. Those include malformed BLOCKMAP and REJECT lumps.

I am going to report to stderr, but - honestly - who does actually read this?

Vorpal said:

Option 1 only results in unintended behavior if an author doesn't even bother to play their own map.

Probably not. Some ports already handle this mapping error gracefully. PrBoom+, for example, ignores these linedefs by default but offers an option to apply it locally. It only applies it to all untagged sectors in complevel 2 mode.

Edit: Not sure what other ports do, though. Does anyone know what e.g. ZDoom or Eternity do with untagged special linedefs?

[Memfis]

ZDoom applies zero-tagged S1/SR actions locally (i.e. to the attached sector), which is the only sane solution I think.

Applying them to everything obviously breaks the map. Disabling them at all in the worst case means that the player will be unable to leave the first room. Who the hell wants that?

If you're afraid of endorsing bad mapping practices, maybe you could display some sort of a warning message?

[TimeOfDeath]

Memfis said:

ZDoom applies zero-tagged S1/SR actions locally (i.e. to the attached sector), which is the only sane solution I think.

Sane, I'm not sure. ZDoom is the reason so many of these zero tag errors exist.

[Graf Zahl]

And considering that this never even was an intended feature...

It was just an unwanted byproduct of the original XLAT binary format being insufficient to do this properly.

[Maes]

fabian said:

I am going to report to stderr, but - honestly - who does actually read this?

IMO, in the case of potentially map-breaking fixes needing to be applied, the game should display a modal message to the user -warning him of the problem clearly before the map even starts, and perhaps forcing him to make a decision at that point.

[Gez]

Option 4: delete the wad, then quit to desktop.

[fabian]

Maes said:

IMO, in the case of potentially map-breaking fixes needing to be applied, the game should display a modal message to the user -warning him of the problem clearly before the map even starts, and perhaps forcing him to make a decision at that point.

Yep, this would be the port that noone wants to play. Sorry, but no, a source port is supposed to do one thing right: Play Doom! And not confront the user with obscure technical decisions.

In this specific case, I think I will go with option 3 and print a warning to stderr. This way, at least *something* happens when the linedef is triggered. I know this is bending the concept of Vanilla compatibility quite a lot. But in this specific case, going strictly Vanilla means destroying the map. And demo recording/playback or network gaming with Vanilla will inevitably have to stop at this point anyway.

[Maes]

fabian said:

Yep, this would be the port that noone wants to play. Sorry, but no, a source port is supposed to do one thing right: Play Doom! And not confront the user with obscure technical decisions.

Ever tried to use Doomsday? ;)

[Graf Zahl]

Maes said:

Ever tried to use Doomsday? ;)

Does it do such stuff? I can't say because I haven't use a modern Doomsday version for ages.

[Maes]

Probably not, but it sure had the most complicated pre-game settings manu of them all. On a more practical side, the approach prBoom+ used for a similar issue (extended blockmap support) was hidden in a submenu somewhere with just a cryptic description such as "Fix blockmap errors in large maps". The user really had to know what to look for and when to apply it.

[andrewj]

I would choose option #2 and ignore the activation.

BTW, do you automatically fix the missing yellow key in TNT MAP31?

[Graf Zahl]

Maes said:

Probably not, but it sure had the most complicated pre-game settings manu of them all.

Yeah, definitely. I thought the old Doomsday 1.8 was fine, but when I was checking out a more recent version to investigate how Doomsday handles a render exploit that entire user interface completely lost me.

Looked to me like it was done in the most overcomplicated way imaginable. Maybe that appeals to 'modern' gaming geeks, but not to me. Then again, I do not play modern games and have no idea how their UIs look. But the inspiration for all that complicatedness has to come from somewhere...

I really appreciate how nearly all other ports have managed to keep that simple 1993 style for most of their UI - especially integrating the option menus in a more tasteful and appropriate manner that matches the overall style of the game.

[fabian]

andrewj said:

BTW, do you automatically fix the missing yellow key in TNT MAP31?

No, I don't do this (yet?).

[printz]

Limit-removed maps not tested in Doom+ should be denied from /idgames uploading.

More seriously: I think either Boom or MBF introduced tag 0 control, which denies such linedefs from having any effect. Maybe you should just ape what they did, with regards to compatibility.

[jeff-d]

andrewj said:

BTW, do you automatically fix the missing yellow key in TNT MAP31?

It's actually relatively straight forward to do.


In P_SpawnMapThing you currently have:

    // check for apropriate skill level
    if (!netgame && (mthing->options & 16) )
	return;

Which can be:

    // check for apropriate skill level
    if (!netgame && (mthing->options & 16))
    {
      if ((gamemode == commercial)		// TNT MAP 31 has a yellow
       && (gamemission == pack_tnt)		// key that is marked as multi
       && (gamemap == 31)			// player erroniously
       && (mthing -> type == 6))
      {
	mthing->options &= ~16;
	//printf ("Yellow key rescued! %X, %X\n",mthing->x, mthing->y);
      }
      else
      {
	return;
      }
    }

[andrewj]

fabian said:

No, I don't do this (yet?).

It is easy enough to do, and it seems you want to prevent or minimise users getting stuck in levels with mapping errors (which is a good thing when it is feasible).

[Graf Zahl]

Of course this can be patched in the code for each level. But if you really want to deal with such issues it may be better to do something like ZDoom's compatibility.txt which allows per-map settings where a map is defined by its MD5 checksum.

[chungy]

At least in the case of TNT MAP31, I would strongly argue against automatically fixing it in a port. There's several ways around it:

• With the original IWAD and no patch files, it can be worked around by abusing the map: http://classicdoom.com/tntdemos.htm#tnt31ex
  
• With TeamTNT's PWAD version of the fixed map
  
• With the id Anthology version of the IWAD, from either the Anthology or GOG.com release, or patching it (far more involved than just getting a fixed one in the first place...)
  

As for the originating reason of the thread, I'd kind of argue to leave it as-is, let the mapping error be exposed for all including the author. This would maintain full vanilla compatibility. Though, if this is undesirable, the PrBoom-Plus behavior is a good fallback.

[jeff-d]

chungy said:

At least in the case of TNT MAP31, I would strongly argue against automatically fixing it in a port. There's several ways around it:

No. All of these methods require the user to:

a) Know that she has a faulty map.
b) Know the above remedies.

Yes, WE know the above, but I'd suggest that the vast majority of players have little clue about it. There's no cost penalty in having the port fix it.

[Graf Zahl]

chungy said:

At least in the case of TNT MAP31, I would strongly argue against automatically fixing it in a port. There's several ways around it:

• With the original IWAD and no patch files, it can be worked around by abusing the map: http://classicdoom.com/tntdemos.htm#tnt31ex
  
• With TeamTNT's PWAD version of the fixed map
  
• With the id Anthology version of the IWAD, from either the Anthology or GOG.com release, or patching it (far more involved than just getting a fixed one in the first place...)
  

As for the originating reason of the thread, I'd kind of argue to leave it as-is, let the mapping error be exposed for all including the author. This would maintain full vanilla compatibility. Though, if this is undesirable, the PrBoom-Plus behavior is a good fallback.

That's the view on the problem from inside the box when the situation actually requires a view from outside the box. Which seems to be a fairly typical occurence here at Doomworld. You know this stuff, but as has been pointed out, most users do not.

The ultimate question has to be: What is more important? Satisfying the users of one's own port or the users of other ports which may be affected by such design decisions? It's clear that you favor the latter.

[Vermil]

Graf Zahl said:

I really appreciate how nearly all other ports have managed to keep that simple 1993 style for most of their UI - especially integrating the option menus in a more tasteful and appropriate manner that matches the overall style of the game.

Considering Dday's ambitions, why would the main UI resemble Doom?

[Bauul]

If this is still being debated, after some consideration I'd vote for Option 3.

My logic is this:

Options 1 and 2 will mostly likely fundamentally break the map. If you're happy to have the map unplayable, you might as well just refuse to load the map from the start. It's the same overall effect.

As TimeOfDeath pointed out, the likely reason untagged special linedefs exist in maps is because of the way other source ports (like ZDoom) apply the same logic to them Door Linedefs do (i.e., they affect the backside sector). Therefore, if you went with Option 3, at least there's a chance the map will work as intended.

At the end of the day, the purpose of a Source Port is to play Doom maps. IMO, deliberately breaking maps in the name of authenticity is rather throwing the baby out with the bathwater, so Option 3 is the only sensible way forward.

TL;DR: Option 1 and 2 *will* break the map, Option 3 only *might* break the map, so Option 3 (with an error message in the console for clarity) makes sense.

[kb1]

Bauul said:

If this is still being debated, after some consideration I'd vote for Option 3.

My logic is this:

Options 1 and 2 will mostly likely fundamentally break the map. If you're happy to have the map unplayable, you might as well just refuse to load the map from the start. It's the same overall effect.

As TimeOfDeath pointed out, the likely reason untagged special linedefs exist in maps is because of the way other source ports (like ZDoom) apply the same logic to them Door Linedefs do (i.e., they affect the backside sector). Therefore, if you went with Option 3, at least there's a chance the map will work as intended.

At the end of the day, the purpose of a Source Port is to play Doom maps. IMO, deliberately breaking maps in the name of authenticity is rather throwing the baby out with the bathwater, so Option 3 is the only sensible way forward.

TL;DR: Option 1 and 2 *will* break the map, Option 3 only *might* break the map, so Option 3 (with an error message in the console for clarity) makes sense.

Totally agree. Unless you have a port with strict vanilla-compatible options, whereas you have to do the vanilla thing. Otherwise render the map as the author intended (most likely) and go with option #3. The code can be found easily in PrBoom+.

[chungy]

One of the main problems I see with the thread is that it is about Crispy Doom specifically, which normally strives to maintain the same vanilla compatibility as Chocolate Doom.

That being said, if a map is uselessly unplayable in vanilla, and a fix can be applied *without* breaking any actual vanilla-compatible maps, it's not horrible to apply the fix.

jeff-d said:

No. All of these methods require the user to:

a) Know that she has a faulty map.
b) Know the above remedies.

Yes, WE know the above, but I'd suggest that the vast majority of players have little clue about it. There's no cost penalty in having the port fix it.

The last method listed doesn't, at least if the user obtained the IWAD pre-patched, such as from GOG ;)

[fabian]

Thanks a lot for all your replies!

In the end, I have decided to go with option 3, because I completely agree with Bauul's statement. However, in order to preserve network and demo compatibility with Choco, I only apply this fix for regular single-player games. Although this somehow feels like a foul compromise -- because in general I'd like to provide the same gaming experience whether in a single-player game or a network game or when recording a demo -- this seemed like the only possible solution.

Similarly, I also applied the fix to the yellow key in TNT MAP31 only in regular single-player games. I remembered that I already apply a similar fix when a Wolf SS is spawned on a map and the IWAD is from the BFG Edition which is missing the corresponding sprites. As andrewj stated, it is most important to prevent the player from getting stuck in a level with mapping errors. On the other hand, I totally agree with chungy and was strongly against implementing such a fix for Chocolate Doom. But while Choco tries to be both demo and bug compatible with Vanilla, I want Crispy to remain demo compatible but fix the most annoying bugs. And so I need to find a compromise whenever both goals seem to contradict each other.