Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
fabian

How to proceed with special linedefs without tag?

Recommended Posts

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

Share this post


Link to post

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?

Share this post


Link to post
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.

Share this post


Link to post

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.

Share this post


Link to post
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.

Share this post


Link to post
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?

Share this post


Link to post

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?

Share this post


Link to post
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.

Share this post


Link to post

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.

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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? ;)

Share this post


Link to post
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.

Share this post


Link to post

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.

Share this post


Link to post

I would choose option #2 and ignore the activation.

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

Share this post


Link to post
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.

Share this post


Link to post
andrewj said:

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

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

Share this post


Link to post

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.

Share this post


Link to post
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;
      }
    }

Share this post


Link to post
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).

Share this post


Link to post

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.

Share this post


Link to post

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:

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.

Share this post


Link to post
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.

Share this post


Link to post
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:

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.

Share this post


Link to post
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?

Share this post


Link to post

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.

Share this post


Link to post
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+.

Share this post


Link to post

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 ;)

Share this post


Link to post

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.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×