Discrepancies in BOOM generalized linedefs

Doomworld Forums : Powered by vBulletin version 2.2.5

Doomworld Forums > Classic Doom > Source Ports > Discrepancies in BOOM generalized linedefs

Author

All times are GMT. The time now is 11:05.

Quasar
Moderator

Posts: 5152
Registered: 08-00

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.

12-01-12 15:19 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

wesleyjohnson
Forum Regular

Posts: 675
Registered: 04-09

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.

12-03-12 19:19 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Xaser
Forum Staple

Posts: 2121
Registered: 07-03

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.

12-03-12 20:16 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Graf Zahl
Why don't I have a custom title by now?!

Posts: 7451
Registered: 01-03

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.

12-03-12 20:19 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

printz
CRAZY DUMB ZEALOT

Posts: 8144
Registered: 06-06

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.

__________________
Available for download: Automatic Wolfen s tein - Wolfenstein 3D bot
MBF configuration for WHackEd2

12-03-12 20:40 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Graf Zahl
Why don't I have a custom title by now?!

Posts: 7451
Registered: 01-03

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'.

12-03-12 21:08 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

esselfortium
Cumulonimbus Antagonistic Posting

Posts: 5969
Registered: 01-02

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.

12-03-12 23:01 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Belial
Senior Member

Posts: 2008
Registered: 09-05

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

12-04-12 08:56 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Graf Zahl
Why don't I have a custom title by now?!

Posts: 7451
Registered: 01-03

Belial said:
...which destroyed the map if used.

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

12-04-12 09:01 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

GhostlyDeath
Forum Retard

Posts: 1008
Registered: 08-05

Graf Zahl said:

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

Now that ruins levels where that is intended!

12-04-12 18:00 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Graf Zahl
Why don't I have a custom title by now?!

Posts: 7451
Registered: 01-03

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.

12-04-12 18:32 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Quasar
Moderator

Posts: 5152
Registered: 08-00

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

12-05-12 14:55 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Graf Zahl
Why don't I have a custom title by now?!

Posts: 7451
Registered: 01-03

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.

12-05-12 15:06 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Quasar
Moderator

Posts: 5152
Registered: 08-00

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.

12-05-12 18:48 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

GhostlyDeath
Forum Retard

Posts: 1008
Registered: 08-05

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

12-05-12 19:36 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Quasar
Moderator

Posts: 5152
Registered: 08-00

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.

12-05-12 20:48 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

All times are GMT. The time now is 11:05.

Doomworld Forums > Classic Doom > Source Ports > Discrepancies in BOOM generalized linedefs

Show Printable Version |

Email this Page |

Subscribe to this Thread

Forum Rules:

You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

HTML code is OFF
vB code is ON
Smilies are OFF
[IMG] code is ON

< Contact Us - Doomworld >