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

Linedef special use in different ports

Recommended Posts

For defining an advanced editing standard we still need to agree on the number ranges to be used.

What seems to be clear is that 32768-65535 should be reserved for extensions to the generalized types, i.e. for larger ranges of identical specials.

 

So for the rest we still need to find a range below 0x2f80 (= 12160) that is unused by all ports.

 

Here's what I know so far:

 

Boom: 1-269

MBF: 1-272

ZDoom: 1-439

Eternity: 1-500

EDGE/3DGE: 1-867, if lines.ddf is exhaustive.

Doom Legacy: 1-306

Vavoom: 1-347

Risen3D: 1-282 plus some numbers between 8000 and 8200, if the editor config is complete.

 

This means we may consider 1000-7999 and 9000-12000 free for use. Is this correct or did I miss something? I'd appreciate if someone could fill in the blanks if this is incomplete.

 

Share this post


Link to post

There might be some oddball ranges used by ports such as Carlos's cDoom, FWIW. I'll check some of the levels of this port in an editor and I'll report back.

Share this post


Link to post

There's always going to be oddball engines like cDoom, but is it worth concerning ourselves over irrelevant and dead ports? We should worry about the ports that, not to sound too arrogant, actually matter.

 

Besides, isn't Carlos the one who went bonkers trying to spam and harass everyone with some weird religious condemnation of us and the game we like?

Share this post


Link to post

cDoom is one of the ports that really do not matter as nobody uses them.

What also can be dismissed is ports which allow mods to define custom types - those should always take precedence.

 

 

Share this post


Link to post

Are we talking about the classic Doom map format? It's possible that we may add enough Doom/ExtraData specials in Eternity to go beyond 500.

Share this post


Link to post

Since EDGE already goes up to above 800 I intentionally considered 1-999 as occupied. That should be enough, right?

 

Share this post


Link to post
3 hours ago, Blastfrog said:

Besides, isn't Carlos the one who went bonkers trying to spam and harass everyone with some weird religious condemnation of us and the game we like?

Whoa, is that guy?

 

Anyway, I don't know about new linedefs usage for other ports like doomsday or other unknown ports... or other idtech1 based games like Heretic or Strife.

This is a interesting thread...

Share this post


Link to post

Yes, that's the same guy. I think the closest we've ever had to a Doom community terrorist does not have to be consulted.

Share this post


Link to post
10 hours ago, Maes said:

some oddball ranges used by ports such as Carlos's cDoom

CDoom used Edge (and Legacy) numbers for it's 3D sectors!

 

281,400 (solid 3d floors)
403 (liquid 3d floors)
404- breakable 3dfloor -perpetual breakable (get properties from adjacent sectors)
484,485 -teleport missiles: linetype 485 normal direction, 484 invert direction
486- breakable floor/wall
487- breakable ceiling/wall
488- breakable floor/ceiling -one time breakable (get properties from linedef frontsector)
490- breakable floor/ceiling/wall
494- guide line to start highest point of slope(floor slope)
495- guide line to start lowest point of slope(ceiling slope)
496- guide line to start lowest/highest point of slope(both ceiling floor)

 

Copied from CDoom205.txt (2004-04-11):

Spoiler

The new CDoom features are:
-new music system(CDoom uses a modified version of Muslib by Vladimir Arnost,
to get the original muslib go to:
http:\www.fee.vutbr.cz/~arnost/muslib/index.html)
-max demo v1.9 compatibility
-walk over/under things(true 3d gameplay)
-linedef types 281, 400(solid 3d floors), 403(liquid 3d floors)
-jump, fly
-new cheats
 JET: toggle fly mode on/off
 RES: respawn the player when the player dies
 INFINITE: infinite ammo
-detect missing blockmap lump and will auto generate the blockmap
-run under WIN NT, rewritten the video code to use _farnspokeb instead
 __djgpp_nearptr_enable(note that CDoom is slower than MBF due to this
 and the 3d floor rendering code)

CDoom207.txt (2013-10-03):

Spoiler

 

[snip]

-sectormassacre parm to break all floors
-earthquakes
-slopes
 line 494- guide line to start highest point of slope(floor slope)
 line 495- guide line to start lowest point of slope(ceiling slope)
 line 496- guide line to start lowest/highest point of slope(both ceiling floor)
first side of line must be pointed to sector to be sloped

For slopes independing of adjacent sector:
add a tag to guide line and this tag to one sector outside to transfer
ceiling/floor heights to slope
Support dynamic slopes and fast slope renderer

-chasecam(F5 key)
-look up down(PAGEUP, PAGEDOWN keys, HOME to center view)
 autolook up down in slopes(F1 key to toggle)

-breakable floors, walls, ceilings, line activated by missiles with earthquake
 line 404- breakable 3dfloor
-perpetual breakable (get properties from adjacent sectors)
 line 486- breakable floor/wall
 line 487- breakable ceiling/wall
 line 488- breakable floor/ceiling
-one time breakable (get properties from linedef frontsector)
 line 490- breakable floor/ceiling/wall

-swimmable sectors (added to linetype 403)
-teleport missiles: linetype 485 normal direction, 484 invert direction
-destroy monster corpses
-crouching(END key)
-cheat ALL
-thing types spawned above 3dfloors: add 4000 to thing type. Then thing type 1(player)
+ 4000 = 4001(player spawned above lowest 3dfloor): + 4000 =
8001(player spawned above second lowest 3dfloor)
thing type 16(cyberdemon) + 4000 = 4016(cyberdemon spawned above lowest 3dfloor)
+ 4000 = 8016(cyberdemon spawned above second lowest 3dfloor)

 

But no clue how to do teleport missiles or launch quakes.

Share this post


Link to post

DelphiDoom uses 1-282 plus 386-391 for slopes (same as Eternity).

Share this post


Link to post
On 5/25/2017 at 4:36 AM, Graf Zahl said:

For defining an advanced editing standard we still need to agree on the number ranges to be used.

What seems to be clear is that 32768-65535 should be reserved for extensions to the generalized types, i.e. for larger ranges of identical specials.

 

So for the rest we still need to find a range below 0x2f80 (= 12160) that is unused by all ports.

 

Here's what I know so far:

 

Boom: 1-269

MBF: 1-272

ZDoom: 1-439

Eternity: 1-500

EDGE/3DGE: 1-867, if lines.ddf is exhaustive.

Doom Legacy: 1-306

Vavoom: 1-347

Risen3D: 1-282 plus some numbers between 8000 and 8200, if the editor config is complete.

 

This means we may consider 1000-7999 and 9000-12000 free for use. Is this correct or did I miss something? I'd appreciate if someone could fill in the blanks if this is incomplete.

 

It would be better for the spec I'm designing if ports restricted their use to 1000-2047, and left 2048-7999, 9000-12159, and, of course 32768-65535 free if possible. Otherwise, this matches what I've found.

 

How about thing numbers? I don't imagine this will be quite as easy, but some standards have found themselves, like extra player starts, for example, and the infamous camera thing placed by MapBuilder.

Share this post


Link to post

Eternity reserves DoomEd numbers >= 20000 for use by EDF mods, so that they're guaranteed to never conflict with anything (an exception was made for detecting the DB Camera object since that was determined w/o anybody's input).

 

I had really hoped the range from 8192 to the first BOOM genspec was universally unused since it makes no sense really for the BOOM genspecs to start where they do (not on a binary boundary). Too bad I guess >_>

Share this post


Link to post
On 27.5.2017 at 5:35 PM, Quasar said:

 since it makes no sense really for the BOOM genspecs to start where they do (not on a binary boundary). Too bad I guess >_>

It makes sense when you think about it ending at that number. The Boom stuff was clearly done backwards starting with 07fff and going down.

 

Share this post


Link to post
On 5/27/2017 at 11:35 AM, Quasar said:

Eternity reserves DoomEd numbers >= 20000 for use by EDF mods, so that they're guaranteed to never conflict with anything (an exception was made for detecting the DB Camera object since that was determined w/o anybody's input).

 

I had really hoped the range from 8192 to the first BOOM genspec was universally unused since it makes no sense really for the BOOM genspecs to start where they do (not on a binary boundary). Too bad I guess >_>

Yeah, it's a bit strange. I think Graf's right about them being added backwards. It's actually a bit cleaner than I was first expecting.

Share this post


Link to post

I would like to reserve lindef specials from 1000 to 1299 for ZokumBSP. And yes, I have legitimate ideas and usage scenarios. These won't be used in game, they will be used as directives from the editor / tools to the node builder, reject builder and blockmap generator.

A list of what these numbers will be used for will be available in the documentation on github. If it turns out we're  not using all those numbers, I would be happy to release them to other ports if need be and we've run out of ranges.

Share this post


Link to post
3 hours ago, zokum said:

I would like to reserve lindef specials from 1000 to 1299 for ZokumBSP. And yes, I have legitimate ideas and usage scenarios. These won't be used in game, they will be used as directives from the editor / tools to the node builder, reject builder and blockmap generator.

A list of what these numbers will be used for will be available in the documentation on github. If it turns out we're  not using all those numbers, I would be happy to release them to other ports if need be and we've run out of ranges.

Should be ok. But, 300 of them? Will that always be enough? And, can you provide an idea of a definition for them, before you add the GitHub documentation? (Right now, I'm just wanting to get an idea of what different usages you envision.)

 

Another question: If they're not to be used in game, can't you convert them back into normal numbers after the builder tools have run? (I guess maps that use those ranges could disturb tools expecting to use linedefs in that range for node/reject/blockmap effects. I guess I don't understand your usages). But, yeah, no reason those numbers cannot be reserved, but I'd like to know what to call that range, specifically. "ZokumBSP effects"?

 

Share this post


Link to post

The idea was to have like the first 100 or so 'hardcoded' as part of the tool, and the remaining 200 to be user configurable. And yes, there is the possibility for changing them to 0 or a known special once the map has been processed. This however makes the building of a map much more of a one-way operation. I would prefer to preserve as much data as possible in the map. Most of the toolchains today assume output.wad is the same as input.wad. Personally, I think that is a bad idea. Id's original toolchain was editor -> dwd -> doombsp -> wad, with a clear distinction between input and output.

When it comes to a user-configurable range, maybe we should have that globally anyway? If all ports agree on not using a specific range, and instead let it be used to run scripts or whatever else chosen by the mapper, to by run by the engine. What if 2000 to 2500 were reserved for user / wad / map specific specials?

The name could be ZokumBSP linedef specials.

Share this post


Link to post

What's your ideas about this? What features are you planning to implement?

Keep in mind that several of the hardware accelerated ports completely ditch the original nodes so either these features need to be defined in a way that other node builders or ports can replicate or we risk that maps cannot be played universally on all ports anymore.

 

Share this post


Link to post

Ok, I might as well explain it, since the code is up on the repo already. We have added 4 linedef specials to adjust the BAM of a seg. This can be used to make walls that look 'rotated'. It's a bit like BSPs tag 999 which uses the X-alignment for rotation.

Numeric Effect
1080    Rotate the rendered wall N degrees, where degrees is taken from tag.
1081    Set the wall rotation to a hardcoded degree, degree taken from tag.
1082    Rotate the rendered wall N BAMs, BAMs taken from tag.
1083    Set the wall rotation to a hardoced BAM, taken from tag.

 

All the rotations are clockwise.


All of these 4 really do the same, but BAMS are pretty complicated for most people to use, hence the degree version. As for the additive nature of 1080 and 1082, this makes it much easier to apply the same rotation to a multitude of walls without having to do a lot of manual calculations.

I have loads more stuff planned, things that aren't based on BSP hacks like this, this is just a neat way to make secret doors etc. This kind of functionality can also be done with .zen file support, but this makes it a lot harder to edit with a map editor since one also has to update external txt files.

Edited by zokum

Share this post


Link to post

I had planned to put together a relational DB w/ a web front end (a quick thing) to collect together all various uses of sector type numbers, linedef type numbers, etc., with a quick and easy query process as well as various pre-canned export routines to auto populate doom wiki pages.

 

I had another idea of a relational DB importing all /idgames WADs to answer questions like "which wads used sector type XYZ?" no doubt some random PWADs have random formerly-unused types on sectors due to fuck ups, corruption, bizarre editors...

Share this post


Link to post

@zokum: Of course, a range can be reserved for non-specific port use, but you have to understand that this flies in the face of compatibility. Also, the rotated wall effect you mention will not work across all ports, as I understand, because some ports don't use those values for rendering - another stab at compatibility. Don't these types of walls have blockmap issues, where the player bumps into nothing, or can pass through portions of wall? Or, does the builder take this in account?

 

I have to ask: What advantage does this give the mapper, that cannot be accomplished by simply drawing the wall at the intended angle in the first place? (Please understand - I am not trying to discredit the functionality, I just don't understand what's being accomplished. My goal is to be able to document what each linedef type does, as Jon suggests.

 

@Jon: This is a great idea. I'd love to see it support all idTech1 games. I've been fiddling with a much less useful version of this for a while now.

Share this post


Link to post

That is the kind of stuff it enables. You set type to 1080 and tag to 180. It doesn't look good from all angles, there are probably some bugs and things we need to work out, but in theory it should do exactly what BSP does.

Share this post


Link to post
13 hours ago, zokum said:

That is the kind of stuff it enables. You set type to 1080 and tag to 180. It doesn't look good from all angles, there are probably some bugs and things we need to work out, but in theory it should do exactly what BSP does.

Ok, so 1000-1299, or 2000-2500, or both? Not trying to dictate - it's just that, pretty soon, we may be eating into the remaining range of linedef types pretty heavily, so we need to be a bit stingy with their use, cause, when they're gone, they're gone, so to speak :)

Share this post


Link to post

Well, i can get by with 300, easily. As for the custom range what I envision is to let map authors write their own custom scripts for whatever engine(s) they target. They can then assign a custom special to the local range and safely know that no port will ever use that special for something else. One might even have different scripts for different engines all tied to the same numeric to perform similar actions.

I seriously dislike the generic system Boom added. It doesn't cover a lot of use cases and is very wasteful. For instance, what if we instead made it like this. We define a numeric, say 2000 for our map, and that is linked to a wad lump that describes what numeric 2000 does. Numeric 2000 could be defined such: 2000,S4,red,yellow, stop crushing_ceiling. So this would be a linedef special that stops a crushing ceiling, but only up to 4 times, and you must have the red or yellow key to activate this switch.

It would not be that hard to code this behaviour into an editor, allowing for near endless possibilities for really esoteric switches that do exactly the job you need them to. Who haven't at times wanted a lift that goes up 384 units, waits 10 seconds then goes down again: 2001 SR, nokey, lift_raise=384,wait=10s. The syntax could be different, but the Boom idea of expressing all kinds of actions by using a bit flag isn't very elegant. If someone wants a gun-activated teleport that only works if you have a red keycard, let them have that.
 

Save the map as e1m1 and the numerics go into e1m1cust or something along those lines. Even without a gui in the editor, one could probably just copy and paste from a mapping web site some good switches and tweak them if need be, and use em in a map. It'd be a bit like importing textures.

Basically, what I suggest is the linedef special equivalent of 192.168.* :)

Share this post


Link to post

Ok, 300...but, what about 100? Doom II didn't use 300. You've only defined 4. Again, I'm not dictating, but "I can get by" is not much of a compelling argument :) Ports have to, essentially "throw away" this range, so it's somewhat important.

 

The Boom method was not inelegant. When conceived, Doom used < 150 of the 65535 range. The Boom team wanted to offer a largely flexible set of features without requiring any changes to editors, so they used an untapped resource in a way that maximized customization within those confines, with virtually no side-effects or down-sides. And, they left over half of the range empty.

 

Conversely, you are proposing, essentially, the creation of a textual script language/parser/virtual machine for linedefs, complete with user-definable byte code that requires an optional map lump, which, in turn requires a way to point to the lump (since custom map lump names exist), for exotic line effects that cannot be accomplished with the current Doom/Boom spread. A generalized script language can handle this and so much more. It's like driving up to the local bar, in your bathrobe, in a Sherman tank :)

 

I do appreciate the possibilities. But, wow, it seems like a massive undertaking, and, yet, I wonder how many of these exotic linedefs one might need in a map. How good can a switch be, that you'd want to import it from a downloaded switch script library? (I'm sure there are some use cases.)

 

In all fairness, yes, Boom did use a lot of the range. In fairness to Boom, that range was completely untapped, and I imagine they built everything they could think of, thinking that they were covering every possible need till the end of time :)

 

Back to your idea, there have been some talks presented in these recent threads, in regards to building an exotic or highly-specialized line action up by splitting up the components of, say, a Boom gen-linedef, into linedef categories. For example, you could have a handful of linedefs that specify speed. Another group defines the action (lift, door, etc). A linedef for crush. (See TRIG-TAG). These might be tied together via line tag, or common sector, or even along a link of vertices. But, this has its own issues, like program complexity. Mapper complexity. Linedef count. Maybe not so bad for simple custom actions, but unwieldy for multiple delayed events.

 

You'd also need a way to maintain state during a complex action. Across the network. Surviving a game save/load. All of these issues are handled when you bite the bullet and add a scripting engine. The Boom method is the sweet spot between Doom, and full-blown scripting, and, it's what we have to work with. I, for one, am not comfortable building another stage inbetween these extremes. It just doesn't seem that beneficial vs. the "cost". Does that make sense?

Share this post


Link to post
9 hours ago, zokum said:

I seriously dislike the generic system Boom added. It doesn't cover a lot of use cases and is very wasteful. For instance, what if we instead made it like this. We define a numeric, say 2000 for our map, and that is linked to a wad lump that describes what numeric 2000 does. Numeric 2000 could be defined such: 2000,S4,red,yellow, stop crushing_ceiling. So this would be a linedef special that stops a crushing ceiling, but only up to 4 times, and you must have the red or yellow key to activate this switch.


This is basically ZDoom's XLAT system. Or Doomsday's XG system. Or 3DGE's LINES.DDF. Or...

 

9 hours ago, zokum said:

It would not be that hard to code this behaviour into an editor, allowing for near endless possibilities for really esoteric switches that do exactly the job you need them to. Who haven't at times wanted a lift that goes up 384 units, waits 10 seconds then goes down again: 2001 SR, nokey, lift_raise=384,wait=10s. The syntax could be different, but the Boom idea of expressing all kinds of actions by using a bit flag isn't very elegant. If someone wants a gun-activated teleport that only works if you have a red keycard, let them have that.

This is basically Hexen's parameterized actions.

Share this post


Link to post
15 minutes ago, Gez said:

This is basically Hexen's parameterized actions.

... which obviously has been deemed out of scope for a first revision of an extended standard.

The main issue is that Doom only has one 16 bit value at its disposal to encode all information of what a certain action will do. There's not much that can be done, especially if nobody wants to move beyond the binary Doom map format.

 

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
×