Discrepancies in BOOM generalized linedefs

[Quasar]

While digging through Eternity's code in preparation for merging BOOM generalized lines into the new line special system I'm working on, I found some more discrepancies and errors in BOOM's generalized linedefs:

• Locked Doors - The cross-over versions of these will activate even if the tag is zero, so, the entire level may activate as a door. The cross-over and shoot versions seem to share a redundant check on trigger type which has no side-effects, but is not shared with use types.
  
• Lifts - Cross and use types check for zero tags, but shoot types do not, so again, the whole level might activate as a lift.
  
• Crushers - this problem is already known, but, walk-over crushers were entirely forgotten in BOOM and therefore do nothing.
  

[wesleyjohnson]

Personally, I think that any wad that uses a trigger on tag=0 ought to be shot along with its author, just to discourage that kind of thing.
Boom implementations were not perfect, so I would fix the omissions, just to discourage that kind of thing.

[Xaser]

wesleyjohnson said:

Personally, I think that any wad that uses a trigger on tag=0 ought to be shot along with its author, just to discourage that kind of thing.

*Checks current map*

*D1 Door Open Stay, Tag 0*

Well, shit.




Silliness aside, it's a legit construct in ZDoomland, just not the sort of thing that authors should get into the habit of trying to do in Boom as well.

[Graf Zahl]

If your concern is demo compatibility, I'd say 'screw it'.
I doubt there's maps out there that have such linedefs without being broken to start with.

This is precisely the kind of scenario that would necessitate hack upon hack upon hack to handle all those broken cases faithfully.

On the downside you end up with some hideous code that will haunt your nightmares.

Xaser said:

Silliness aside, it's a legit construct in ZDoomland, just not the sort of thing that authors should get into the habit of trying to do in Boom as well.

It's a legit construct in ZDoom because it's a legit construct in Hexen.

Which highlights another matter here: What's this supposed to be compatible with? If the answer is 'Boom at all costs' prepare for some sleepless nights.

[printz]

Graf Zahl said:

If your concern is demo compatibility, I'd say 'screw it'.
I doubt there's maps out there that have such linedefs without being broken to start with.

A more valid concern would be gameplay compatibility. Specifically, one that wouldn't require adding opaque per-file compatibility checks.

[Graf Zahl]

printz said:

A more valid concern would be gameplay compatibility. Specifically, one that wouldn't require adding opaque per-file compatibility checks.

I don't think it has to go into that territory.

There's 3 scenarios here what a map may contain:

- properly defined: No problem whatever is done
- ZDoomisms: Needs 0-tag to activate adjacent sector
- broken map with improper 0-tags: won't work anyway

The third one would be the deal breaker if there was a proper map containing such things. But there are none. Convention has always been that 0 means 'untagged'.

[esselfortium]

Yeah, the only circumstance I can imagine in which an actually functional map would feature 0-tagged specials is if the mapper used another tag as the default and had only the desired sectors tagged 0. But that'd be pretty idiotic and serve no purpose but to give source port authors a headache if they bother trying to support it.

[Belial]

I think Ogre Labs had a rogue linedef like that right next to a door or switch, which destroyed the map if used.

[Graf Zahl]

Belial said:

...which destroyed the map if used.

Reason enough to disable the 'feature'... :D

[RestlessRodent]

Graf Zahl said:

Reason enough to disable the 'feature'... :D

Now that ruins levels where that is intended!

[Graf Zahl]

What kind of level would that be?

Now let's be serious. This whole thing can only be exploited in one way: Screwing up the level by intent. Anyone doing such thing is an idiot.

Of course one can split hairs over the degree of compatibility a source port exhibits but I can't see a single realistic case where this would matter.

[Quasar]

Graf Zahl said:

Of course one can split hairs over the degree of compatibility a source port exhibits but I can't see a single realistic case where this would matter.

I suppose you could imagine a 2.02 demo where a speedrunner exploits a line that accidentally opens the whole map like a door in order to take a massive shortcut straight to the exit when it causes a normally impassible sector to become opened.

Kind of like that exit line that is accidentally on a door track in the first level of Chex Quest.

Either way, EE will continue to be BOOM compatible so, don't 0-tag your generalized lines unless you test in BOOM :P

[Graf Zahl]

How will you solve that dilemma when migrating the linedef system to Hexen style?

All those linedefs ZDoom defines for the generalized linedefs use tag 0 as 'trigger the other side of this line', i.e. Boom's 'Door' types.

So it's either breaking those or using an incompatible method.

[Quasar]

Graf Zahl said:

How will you solve that dilemma when migrating the linedef system to Hexen style?

All those linedefs ZDoom defines for the generalized linedefs use tag 0 as 'trigger the other side of this line', i.e. Boom's 'Door' types.

So it's either breaking those or using an incompatible method.

As mentioned before, we're not doing it the way ZDoom did it. Everything is *not* converted to Hexen semantics when playing in games that are not Hexen. That would be impossible. Instead I am separating prologue and denouement from the core action logic, so the core action logic can be invoked independently of the wrappings for a particular special.

In DOOM/BOOM, I need such compatibility logic, but if being invoked from a Hexen linedef special, it is *not* needed. So, ev_actiontype_t bears the 2 function pointers for pre-action and post-action callbacks, while ev_action_t holds a pointer to the actual action routine itself.

[RestlessRodent]

In ReMooD, I just have something I call "Upper Extended Line Types", which range from 0x10000 through 0xFFFFFFFF. Of all of them are generalized (you can see the current allocations and how they are setup in the WAD data and the source code). Of which, those types will be accesable in the future when/if UDMF is added.

For Hexen, the line special is just set to 0xFFFFFFFF which is then parsed by code which handles Hexen lines (since they take arguments, etc.).

[Quasar]

GhostlyDeath said:

In ReMooD, I just have something I call "Upper Extended Line Types", which range from 0x10000 through 0xFFFFFFFF. Of all of them are generalized (you can see the current allocations and how they are setup in the WAD data and the source code). Of which, those types will be accesable in the future when/if UDMF is added.

For Hexen, the line special is just set to 0xFFFFFFFF which is then parsed by code which handles Hexen lines (since they take arguments, etc.).

In the new line special system I am building, actions are dynamically bound to numeric slots to become the line specials we know from certain games. Except for BOOM generalized specials, because there are too many of them (more than 11000). This would weigh down the hash table too much. Instead, specials > GenFloorBase (0x2F80, IIRC) get filtered out first and all map to a BoomGenAction.

When the ZDoom means of invoking these in Hexen-format maps is added, those specials' prologues can extract the needed info from the line args and then call the same action routine, so there shouldn't be massive code duplication.