Severed bunny head
Register | User Profile | Member List | F.A.Q | Privacy Policy | New Blog | Search Forums | Forums Home
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 16:44. Post New Thread    Post A Reply
Quasar
Moderator


Posts: 6037
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.

Old Post 12-01-12 15:19 #
Quasar is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
wesleyjohnson
Senior Member


Posts: 1009
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.

Old Post 12-03-12 19:19 #
wesleyjohnson is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
Xaser
Forum Staple


Posts: 2617
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.

Old Post 12-03-12 20:16 #
Xaser is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Graf Zahl
Why don't I have a custom title by now?!


Posts: 7734
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.

Old Post 12-03-12 20:19 #
Graf Zahl is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
printz
CRAZY DUMB ZEALOT


Posts: 8849
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.

__________________
Automatic Wolfenstein - Version 1.0 - also on Android

Old Post 12-03-12 20:40 #
printz is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Graf Zahl
Why don't I have a custom title by now?!


Posts: 7734
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'.

Old Post 12-03-12 21:08 #
Graf Zahl is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
esselfortium
A Major Doomworld Concern


Posts: 6569
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.

Old Post 12-03-12 23:01 #
esselfortium is online now Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Belial
Senior Member


Posts: 2321
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.

Old Post 12-04-12 08:56 #
Belial is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
Graf Zahl
Why don't I have a custom title by now?!


Posts: 7734
Registered: 01-03



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



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

Old Post 12-04-12 09:01 #
Graf Zahl is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
GhostlyDeath
Forum Retard


Posts: 1027
Registered: 08-05



Graf Zahl said:



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



Now that ruins levels where that is intended!

Old Post 12-04-12 18:00 #
GhostlyDeath is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Graf Zahl
Why don't I have a custom title by now?!


Posts: 7734
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.

Old Post 12-04-12 18:32 #
Graf Zahl is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
Quasar
Moderator


Posts: 6037
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

Old Post 12-05-12 14:55 #
Quasar is offline 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: 7734
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.

Old Post 12-05-12 15:06 #
Graf Zahl is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
Quasar
Moderator


Posts: 6037
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.

Old Post 12-05-12 18:48 #
Quasar is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
GhostlyDeath
Forum Retard


Posts: 1027
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.).

Old Post 12-05-12 19:36 #
GhostlyDeath is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Quasar
Moderator


Posts: 6037
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.

Old Post 12-05-12 20:48 #
Quasar is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
All times are GMT. The time now is 16:44. Post New Thread    Post A Reply
 
Doomworld Forums : Powered by vBulletin version 2.2.5 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 >

Powered by: vBulletin Version 2.2.5
Copyright ©2000, 2001, Jelsoft Enterprises Limited.