Defining a new enhanced source port standard (Boom+/MBF+)

Expanding or filling in the gaps to the boom linedefs / sectors set sounds a good place to start to me.

1 person likes this

Share this post


Link to post
7 minutes ago, Quasar said:

the point of this is that old school mappers who still can't envision moving to Hexen format would get new toys to play with, and, adding support for such to a PrBoom-Plus fork would certainly be faster - a lower hanging fruit - than the Hexen map format (methinks it forgotten just how much work adding that into the base Doom code is, w/o obliterating Doom format support in the process particularly).

 

Obviously adding new actions to Doom format will be easier, the main problem here clearly is that the amount of free specials is finite - do too much or something too specialized and the numbers will be gone in no time.

As for adding Hexen format support, I would do this by adding a second set of thinkers that is completely free of any backwards compatibility concerns. It's all those exceptions and special cases that make working with the code such a hassle. Even though this may sound like it is more work, I really don't think so. Such a parallel implementation is far easier to fix because unless there has been an actual release it can be tweaked until everything works. Of course that's stuff for the distant future.

 

 

Share this post


Link to post

Considering the nature of Chocolate Doom as a source port I probably don't have much to contribute here but I just wanted to chime in anyway and offer some advice.

 

The history of cross-port collaborations isn't particularly great, with the OGRE project being the most infamous failed initiative. That said, the more recent UDMF effort was successful, so the are by no means hopeless endeavors. My main suggestion would be to set some small, conservative goals and to avoid aiming for anything grandiose. Even talk about a "new enhanced source port standard" sounds too grandiose to me. Aim smaller and focus on features. 

 

For example, one thing to aim for might be to ask "what are the five things that MBF is missing that mappers really want?" (ie. what Liberation said above). If you can do that and get them implemented consistently in *ZDoom, PrBoom+ and Eternity then I think you've done well. Do a bunch of small things like this and people will make up their own name for your "standard" if they think it needs one.

 

The other is that I'm not sure you're guarding your discussions well enough. While you should certainly be listening to mappers, you can't do everything all at once and you need to be able to say "no" (you can always say "yes" later on). I also wonder if Doomworld is too open for these discussions to be productive - in the UMAPINFO thread I see non-programmers derailing the discussions for example. If that's a problem then maybe there needs to be a private mailing list or forum to discuss the purely technical details without them being interrupted.

1 person likes this

Share this post


Link to post

Here's a draft suggestion that would create a fairly comprehensive BOOM generalized lighting system

 

https://gist.github.com/haleyjd/aa2220e680389d7dce88410630e73abf

 

I couldn't quite squeeze functionality out of all the available bits though, so it's probably ripe for input. It would use up the low available range from 0x2000 to 0x2F7F that isn't otherwise used. BOOM also deigns to define any functionality for the top-most bit of a line special, presumably because "negative" line specials would crash the shitty old DOS level editors they were trying to support back then, meaning the entire unsigned short range from 32768 to 65535 does nothing and effectively doubles the available space for other types of effects as far as generalized specials would go. It makes me not that worried about using it up, given I am short on ideas other than making some Hexen action types available (like pillars, for example, which have no BOOM analogue).

Edited by Quasar
2 people like this

Posted (edited)

Share this post


Link to post

 @Fraggle:

 

I fully agree with everything you said, which is why instead of engaging into those discussions I just implemented the MAPINFO part, and I think for other ideas the same approach is advised. The Github project is there, so anyone who actually is capable of implementing something worthwile is free to send a PR. If it's well designed it will be added.

 

@Quasar:

 

I had a look but I have to admit that I haven't fullly understood what most of this is supposed to do.

 

Share this post


Link to post

It'd probably make a BIT more sense if I remembered that generalized lines need trigger bits... but anyway the gist is allowing light levels and effects to be triggered in a flexible way. Back to the drawing board to say the least. I didn't define the meanings of speeds against the various effect types because I'm effectively soliciting input on that kind of thing. Obviously they should be factors based on the base normal speed (ie., 0.25x, 0.5x, 1.0x, 2.0x, etc) like most other generalized types work.

 

EDIT: well I'm bummed out because there's definitely not enough bits to do a nice system like the one I had spelled out here when I have to spend 3 on the trigger type. Lighting would have to be done in the upper range if it could be extended in that direction (ie, with 0x8000 set). It'd be nice if you indicated if you're even interested in this kind of expansion before I waste any more time on it.

Edited by Quasar

Posted (edited)

Share this post


Link to post

I would rather not use up the number space.  It may look vast but it gets used up.  I have worked on another project that over the years got enhancements, until they got down to the last 4 codes.  I had to overlay an entire diagnostic command system into one command code number just to leave them 3, and then still had to laborously explain the consequences of using the last 3 codes.  They had a system to fetch extra command parameters that I overworked.   This Boom format does not have that.  Eventually you will just force someone else to kludge their extensions, or overlay their linedefs over yours, with some other way to mode switch, like a linedef that identifies linedef encoding

( linedef 5603 with a Boom, MBF, R9, BE2017, BE2019, STRIFE, etc,  identification code in the xoffset field )

 

This is why in my definition system I keep it to two or three linedefs used for a concept, with all parameters encoded into existing fields, or by using other means to add adjustments.   If I need generalized triggers, then I let a door action trigger the linedef.  Any door action that targets the side1 sector of these linedefs will be intercepted and applied to a linedef specific setting that controls the linedef action.   Then there is no need to duplicate the entire Boom generalized triggers for every concept.  The one existing set of door triggers can  be used to trigger dozens of new concepts, each which only cost two or three new linedefs.

 

The same thing can be done with TAG values, but that usually conflicts with trying to use the TAG to control another sector.

A few linedef actions do not use the TAG for sector identification.   If a door action linedef does a TAG action, then some linedefs can snoop on that TAG sector search, and activate the special linedef action.  There does not need to be any sector with the TAG value.   The door action linedef is used as a trigger to activate the special linedef action by TAG value.

 

Once this mechanism is provided for any linedef, it can easily be used for most of the new linedefs.  This saves redefining the Boom method of generalized triggers for every new linedef concept.

 

I would support one set of generalized triggers, that can be used as trigger linedefs for any number of other specialized linedefs.   The connection identification from the trigger linedef to the effect linedef is the only problem.   Allowing multiple effect linedefs to be triggered simultaneously from one generalized trigger linedef would solve that fanout problem that seems to arise at least once per level map.  The TAG value is one possibility, but conflicts with any effect linedef that needs it for affecting sectors.    If these linedefs can do without their xoffset field (and they probably can as they are not controlling textures) then the xoffset can be used as identification for these particular interacting linedefs.

Once such a system is implemented, it can be used for most special effect linedefs, leveraging the existing trigger linedefs.

 

One advantage of such a system is that the generalized trigger linedefs can then be expanded to more than the walkover, push, shoot, because there will only need to be one set of linedefs with such complex encoding, instead of duplicating the triggers for every new linedef concept.   It will also be much easier to use, the current Boom generalized linedefs are so difficult to calculate the linedef encoding, that I end up avoiding them if possible.  Having only one new set of generalized encodings would be better for usage.

 

It would even be better if a new generalized triggers linedef used some xoffset or yoffset fields for control instead, at least if as triggers they never get used as wall textures at the same time (like the walkover triggers).   But, the first thing that comes to mind is using a walkover trigger on a step, which needs the xoffset and yoffset for the step edge texture.

Repurposing fields is difficult for triggers because they have to be out where the player can see them.

 

Other specialized linedefs would only appear on special sectors off to the side, and their texture fields would be easy to use for extra settings.  The DoomLegacy Fog and colormap linedefs do this with encoding some fog settings in the texture names.

 

We should try to leverage one set of generalized triggers, and a system for reusing them to trigger all kinds of new concepts.  Each new linedef duplicating all this is not attractive to implement.

 

 

 

 

Share this post


Link to post

Another idea.   Let 4 bits of the generalized trigger be a TRIGGER_TAG.   Let new linedefs also be able to define TRIGGER_TAG using 4 bits of their linedef code.   This allows us to have trigger linedefs that fire the TRIGGER_TAG, and linedefs that are activated when a TRIGGER_TAG is fired.

This is much less codespace expensive than duplicating the Boom generalized method, and allows for better expansion.

It also separates the trigger linedef from the action linedef on the level map.  The trigger linedef needs to be where the player can activate it.  The action linedef often needs to be where the effect will take place.  Two separate linedefs are going to be involved anyway.

 

Trigger ideas, in addition to the existing Boom fields.
- additional key like a third key set recognition

- pressing an UP trigger key on the keyboard while in the sector adjacent to the trigger linedef (actual key can be redefined by user)

- pressing a DOWN trigger key on the keyboard while in the sector adjacent to the trigger linedef (actual key can be redefined by user)

- Presence of an object in the sector adjacent to the trigger sector.

Including any of these would just make duplicating the trigger conditions in every new linedef concept even that more painful.

Including any of these as isolated new trigger linedefs only limit them to only those linedefs that duplicated them.

With a TRIGGER_TAG system such additional triggers can easily be added, and can trigger any existing linedef that uses the TRIGGER_TAG system.

 

My only concern is if 4 bits for TRIGGER_TAG id is enough.  Would someone want to use more than 16 specialized triggers in one level?  If it is made larger then it gets expensive again in the linedef code space as every new linedef that uses TRIGGER_TAG would have to include it.

 

I know that this is why the UDMF text format is attractive, but that is not an enhancement of Boom, and DoomLegacy does not have it, nor does my Doom Editor.

It is easy to talk about fixing the Doom Editor that you use, but I am sure you won't be fixing yadex.  You will talking about why I should be using your Doom Editor now.

 

 

 

 

 

Edited by wesleyjohnson

Posted (edited)

Share this post


Link to post

This is the kind of thing I wanted.

ONE source port... that can do EVERYTHING.

 

Why should GLboom be able to run the 1million revanants mod with no lag yet GZdoom lags like crazy?

 

It's not like taking the (at least seemingly) unrelated lines of code and combining them all into one will somehow still be inherently incompatible, right?....

Share this post


Link to post

Let's cut this short: Doom format has very limited means to do stuff here because the line type encodes the trigger type, the action and all associated parameters. And with nothing else left, once it's used up, it's over.

 

Only two solutions:

 

- implement UDMF where the range of numbers can be upped to 32 bits, giving a lot more options.

- implement Hexen specials (which are only useful with UDMF if extensions are the goal because the one-byte types are nearly used up, too, and need to be handled conservatively)

 

Seeing that Hexen format is not that welcome, it seems like UDMF with Doom format special types remains the only option to get more types.

 

Share this post


Link to post
8 hours ago, Liberation said:

Expanding or filling in the gaps to the boom linedefs / sectors set sounds a good place to start to me.

This is a great place to start. More below.

 

6 hours ago, fraggle said:

Considering the nature of Chocolate Doom as a source port I probably don't have much to contribute here but I just wanted to chime in anyway and offer some advice.

 

The history of cross-port collaborations isn't particularly great, with the OGRE project being the most infamous failed initiative. That said, the more recent UDMF effort was successful, so the are by no means hopeless endeavors. My main suggestion would be to set some small, conservative goals and to avoid aiming for anything grandiose. Even talk about a "new enhanced source port standard" sounds too grandiose to me. Aim smaller and focus on features. 

 

For example, one thing to aim for might be to ask "what are the five things that MBF is missing that mappers really want?" (ie. what Liberation said above). If you can do that and get them implemented consistently in *ZDoom, PrBoom+ and Eternity then I think you've done well. Do a bunch of small things like this and people will make up their own name for your "standard" if they think it needs one.

 

The other is that I'm not sure you're guarding your discussions well enough. While you should certainly be listening to mappers, you can't do everything all at once and you need to be able to say "no" (you can always say "yes" later on). I also wonder if Doomworld is too open for these discussions to be productive - in the UMAPINFO thread I see non-programmers derailing the discussions for example. If that's a problem then maybe there needs to be a private mailing list or forum to discuss the purely technical details without them being interrupted.

Yes, please contribute! Totally agree with the "what 5 things do you need most?" types of discussions. Currently, we're just gathering ideas. The first spec draft will probably not specifically assign exact linedefs, or anything like that. It'll be more like: "Here's the ranges we can use". The specific additions can be honed from this thread, with forum-wide discussion and prioritization, in a specific thread. I did ask for general ideas in the OP.

 

6 hours ago, Quasar said:

Here's a draft suggestion that would create a fairly comprehensive BOOM generalized lighting system

 

https://gist.github.com/haleyjd/aa2220e680389d7dce88410630e73abf

 

I couldn't quite squeeze functionality out of all the available bits though, so it's probably ripe for input. It would use up the low available range from 0x2000 to 0x2F7F that isn't otherwise used. BOOM also deigns to define any functionality for the top-most bit of a line special, presumably because "negative" line specials would crash the shitty old DOS level editors they were trying to support back then, meaning the entire unsigned short range from 32768 to 65535 does nothing and effectively doubles the available space for other types of effects as far as generalized specials would go. It makes me not that worried about using it up, given I am short on ideas other than making some Hexen action types available (like pillars, for example, which have no BOOM analogue).

 

5 hours ago, Quasar said:

It'd probably make a BIT more sense if I remembered that generalized lines need trigger bits... but anyway the gist is allowing light levels and effects to be triggered in a flexible way. Back to the drawing board to say the least. I didn't define the meanings of speeds against the various effect types because I'm effectively soliciting input on that kind of thing. Obviously they should be factors based on the base normal speed (ie., 0.25x, 0.5x, 1.0x, 2.0x, etc) like most other generalized types work.

 

EDIT: well I'm bummed out because there's definitely not enough bits to do a nice system like the one I had spelled out here when I have to spend 3 on the trigger type. Lighting would have to be done in the upper range if it could be extended in that direction (ie, with 0x8000 set). It'd be nice if you indicated if you're even interested in this kind of expansion before I waste any more time on it.

I only briefly looked at your proposal, but long enough to see that it does provide some nice general functionality. It worries me, only a bit, at the number of linedefs it consumes, even without the "nice" system you describe. I don't think we can afford to use them up as liberally as Boom did - they ate nearly half of the available range! But, they did spread it out over most of Doom's and Boom's abilities pretty nicely. I would think that we also don't want to consume the entire remaining range, especially in Phase 1! But, you don't use THAT many, and the functionality they provide is probably worth it - it's the same thing Boom did - they used large ranges for each of Doom's linedef tricks.

 

There's no good reason to avoid the upper half that I can think of. We have nice modern map editors that can handle it. If we want to follow Boom's wisdom, we can put the most important stuff in the lower portion. We should probably leave a range free for custom port-specific linedefs as well. The spec should provide a way to not conflict with ports that do not implement the spec. And, there will always be port-specific stuff.

 

The think to remember is that we are discussing what can fit into the original format. UDMF (which is the ultimate universal format) can arbitrarily handle all manners of compliant customization, and I intend to include it in the spec (in a later phase), along with thing/frame definition stuff.

 

 

3 hours ago, wesleyjohnson said:

I would rather not use up the number space.  ...

This is why in my definition system I keep it to two or three linedefs used for a concept, with all parameters encoded into existing fields, or by using other means to add adjustments.   If I need generalized triggers, then I let a door action trigger the linedef.  Any door action that targets the side1 sector of these linedefs will be intercepted and applied to a linedef specific setting that controls the linedef action.   Then there is no need to duplicate the entire Boom generalized triggers for every concept.  The one existing set of door triggers can  be used to trigger dozens of new concepts, each which only cost two or three new linedefs. ...

We almost have to use a sizable chunk of the space - it's the only sensible option:

 

I'm not sure, but I think what you're describing is a system where you have linedef groups: One group handles general triggers (walkover, shoot, etc), and that linedef triggers an "Action" linedef group with a single linedef for a lift, another for a door, with another group controlling the speed, etc. It sounds pretty complex. I guess the motivation for building that is to reduce the number of linedef definitions, or maybe to support your code layout?

 

Man, it's just so different than the way the other ports handle stuff. If I understand correctly, it takes multiple linedefs to do an action. Finally, it's not as easy for mappers.

 

But, the biggest issue is that you are effectively asking to claim half of the range...for Legacy. Are there any downloadable maps that use this range? I want to use some of this range for universal mapping capabilities, for ports that aren't ready for UDMF, and I think other devs do also. It's the logical way to add new stuff, and we already have an efficient Boom model to go on.

 

To handle the discrepancy, we could try to implement the MapType/PortType setting I described in a few posts back. This would allow Legacy maps to define their linedefs as you see fit, if the map is defined as "Legacy". Otherwise, linedefs are interpreted as Doom, Boom, and "Boom+". This can be used to keep all ports happy, and still have standard extensions understood by all ports.

 

I am starting to think that the map-wide identifiers are going to be necessary down the road. Because, I want Legacy to adopt the standard as well, and, without this setting, it doesn't seem like it's going to happen. It's an easy thing to add (could be tricky to implement based on the port), and a great thing to have for a multitude of reasons. And, with proper implementation, it can be used to resolve conflicts. It can actually make conflicts go away from the mapper's perspective.

 

@wesleyjohnson I do see merit in your system, if I understand correctly. But I think I need to follow fraggle's wisdom and say "no", or at least "probably not a good idea", for the simple reason that I don't think you'll get "universal" support from port devs.

 

But, with the PortType identificator, or something similar, Legacy could support your linedef system AND the new Boom+ standard (but not in the same map). Don't forget that, for UDMF maps, any issues with your linedef system, or Boom+, go away, because of its infinite extensibility. Again, I don't know if I understand what you're describing...and that's part of the problem. Boom+ should not require a lot of source code to support, and it should fit nearly seamlessly into all of them

 

3 hours ago, StalkerZHS said:

This is the kind of thing I wanted.

ONE source port... that can do EVERYTHING.

 

Why should GLboom be able to run the 1million revanants mod with no lag yet GZdoom lags like crazy?

 

It's not like taking the (at least seemingly) unrelated lines of code and combining them all into one will somehow still be inherently incompatible, right?....

There will always be port-specific features and port-specific maps. The spec is not trying to "genericise" ports. Instead, there are a lot of simple features that most all ports could comfortably adopt, and many already have, in their own way. We want to define some of these features, and provide a rigorous specification for how they work, in a way that allows all Boom ports to provide the same new features in the same way.

 

Yes, more maps with extended features will be able to run in multiple ports, which is great. But, we are not trying to eliminate the need for the various source ports, not at all. The fact that we have so many wonderful ports provides a template for what is possible, and it allows some great maps! But all ports should be able to, for example, set the brightness of a wall, without having to use a script. That's the idea.

 

 

2 hours ago, Graf Zahl said:

Let's cut this short: Doom format has very limited means to do stuff here because the line type encodes the trigger type, the action and all associated parameters. And with nothing else left, once it's used up, it's over.

 

Only two solutions:

 

- implement UDMF where the range of numbers can be upped to 32 bits, giving a lot more options.

- implement Hexen specials (which are only useful with UDMF if extensions are the goal because the one-byte types are nearly used up, too, and need to be handled conservatively)

 

Seeing that Hexen format is not that welcome, it seems like UDMF with Doom format special types remains the only option to get more types.

 

Those are the 2 complete, "proper" solutions. But, again, I think some new Doom specials are worth pursuing. Here's why:

  • Some mappers are "old-school". It's not that difficult, so why not give them a few new tricks.
  • I see UDMF as having great importance. However, not all ports are ready for UDMF.
  • Some ports will probably not implement UDMF, and, therefore, only part of the Phase X spec.
  • Because of the above, adding some Doom specials provides some incentive to port devs, who went to the trouble to add Boom support, to also add some Boom+ support, even if they don't implement all of it right away, or ever.

The conflicts of interest can be solved quite cleanly - I am sure of it. Wesley can use his multi-linedef-trigger system, and we can provide a smallish set of new types, and get everything we can out of the original format. It would almost be irresponsible, or, at least, neglectful not to.

 

I've committed myself to creating the first draft of the spec. Please keep an open mind, give me some time, and please reserve judgement until I can deliver that first rough draft. I am sure we can solve these and more issues in fairly non-kludgey ways.

 

***EDIT:***

Holy shit, guys - I have to stop writing these books, and actually get some work done! Unfortunately, my current workload is slowing me way down, so I'll need some time, and I'm taking a break from the big replies on this subject. But, it's in progress, and, hopefully, I'll return with a rough draft.

Edited by kb1
2 people like this

Posted (edited)

Share this post


Link to post
19 hours ago, esselfortium said:

If an extended Boom feature set is developed, please consider making sane versions of the line scrollers. The ones Boom comes with are truly baffling, and all but useless in most situations. The line-vector scrollers are based on relative angle, so it's literally impossible to synchronize scrolling of different-angled lines, and the offset-based scroller can't be controlled via a tagged line, so it's impossible to use texture alignment with it.

I think special 254 allows scrolling all tagged walls, but uses a scrolling floor as the reference. One linedef's offsets scrolling all tagged linedef does feel more intuitive ;0)

 

Seems like a good sit down and review of the existing types is needed. New generalised specials would be great but even looking at what I posted earlier WRT a lighting range there is effectively duplicates of existing specials/sector types that might be able to be avoided to leave more room for other stuff.

Share this post


Link to post

Regarding scrollers, I think the most important ones are replicas of the 4 Hexen types that scroll in one cardinal direction with different speed options, and it would make sense to use 256 or 512 numbers here to have maximum flexibility - maybe even duplicate the numbers to have diagonal scrollers as well.

 

 

Share this post


Link to post
On 4/25/2017 at 9:36 AM, Xaser said:

"KaBoom"

Please, please actually name it this. It's too good to pass up.

 

On another note, I've always hated how Boom false floors worked, and the very limited way they behaved gameplay-wise. The following suggestions are more of an advanced kind of thing, and is not to be taken seriously at this stage, I'm just throwing ideas out there.

 

First of all, the way sector heights and floor/ceiling textures are set up frankly sucks. The only thing the existing standard does right is that the floor height in the actual playable area is set to the bottom of the pit. But then why do I have to use the false floor's texture as the floor texture of the main sector, and use the dummy sector to set the real floor's texture? Shouldn't the false floor's floor texture be set in the dummy sector and the real floor's floor texture be set in the main sector? Lastly, why do the dummy sector's floor and ceiling heights cover the area above the false floor and not below? I'd prefer to set the dummy sector's floor height to that of the main sector, and the dummy sector's ceiling to that of the false floor's height.

 

As for gameplay behavior, having to use unaltered physics kinda sucks. Why not some optional water physics behavior? Perhaps use the dummy sector's action special and flags for when you're under the false floor in general, so you could make being below it secret and/or damaging, etc. There could be an option to act as a completely solid (albeit flat) surface, like a limited 3D floor of sorts. Maybe even one way travel (can fall in but not jump out, or vice versa). Perhaps there could be "false ceilings" as well that act as an inverse of false floors (false surface jutting out from the top of the sector instead of the bottom of it).

Edited by Blastfrog
1 person likes this

Posted (edited)

Share this post


Link to post

Most of that stuff can be taken from ZDoom when the time comes. That goes both for better texture use and for water physics.

 

Share this post


Link to post

I worked this up in a hurry overnight.  Mostly because if did not someone would spend a alot of time doing the very thing that I was trying hard to avoid.  This system has the great advantage that it manages to leverage all the existing triggers and linedefs for new purposes.  It allows two linedefs to be combined (trigger + action) which means you do not have to encode all possible triggers into every new linedef concept.  I have alot of strange linedef types I want to play with.  Even those linedefs that do not make it into any standard can still use this mechanism.   The linedef code space that is saved is shared by everyone that tries to avoid stepping on existing linedefs.

 

Being able to use any of the existing Boom generatlized linedefs to trigger new actions, and being able to add new kinds of triggers and button types cannot be done from having more generalized linedefs.  Using TRIG_TAG to connect a trigger linedef to an action linedef relieves the need to have every action linedef also have to deal with every possible trigger.

Adding a new trigger is no longer a problem and it can be used to fire existing actions.  Adding a new action is no longer a problem as it does not need to deal with the triggers.

 

Remember, I worked this up overnight so it is not polished yet.  There are some rough spots I think I could improve, but still it is much more powerful than individual generalized linedefs alone.

 

***** Trigger tag system
The TAG field has enough width that it can be split into several namespaces.
Hardly more than 30 tag values are used in a large level map.

SECTOR_TAG namespace:
The SECTOR_TAG namespace is the existing default.
Linedefs have SECTOR_TAG values that are compared to TAG values in the
sectors.
Some Boss Death actions generate SECTOR_TAG actions.

TRIG_TAG namespace:
Namespace for passing triggers to other action providers such as other
linedefs.
TRIG_TAG values are 1..255, 0 is excluded as no trigger.

A TRIG_TAG is always accompanied by a action from a limited list.
The action generated is determined by the linedef type.
This allows some new linedef to respond to two different triggers,
such as up and down.  It also allows a new push-push switch to alternate
between OFF and ON.
TRIG_TAG action list:
0: OFF
1: general trigger, ON
- push
2: OPEN
- any door open
- is accompanied by parameter for speed
3: CLOSE
- any door close
- is accompanied by parameter for speed
4: UP
- any lift up, or floor up, or increase
- is accompanied by parameters for speed and target selection
5: DOWN
- any lift down, or floor down, or decrease
- is accompanied by parameters for speed and target selection
6: LEVEL
- is accompanied by a value 0..255
7: HEIGHT
- is accompanied by a floor height

Generalized linedef fields will be used to set parameters for speed
and target. They will be complete enough to transfer all the needed
information encoded in the generalized linedef fields.

ACTION namespace:
Namespace for other uses.
Keep as a possibility and a use will be found.
ACTION_TAG values are 1..255, 0 is excluded as no action.

Trigger Linedef:
- React to the some stimulus and generate a TRIG_TAG namespace trigger.

Action Linedef:
- Be triggered from the TRIG_TAG namespace, by a matching TRIG_TAG value.

Range translation:
The SECTOR_TAG values that are in 0xFF00 to 0xFFFF are
automatically transfered to the TRIG_TAG namespace range 0x00..0xFF,
and are not used as SECTOR_TAG values.
This allows all existing generalized linedefs that use TAG to also be used
as generalized triggers.

Dual TRIG_TAG values:
- There is enough room in TAG for two TRIG_TAG, one in the upper half
and one in the lower half.
- The specific use of dual TRIG_TAG is defined by the individual linedef type.
- Some linedef can emit both TRIG_TAG values.
- Some linedef can be activated by one TRIG_TAG value, and emit another.
- Some linedef can be activated by either TRIG_TAG value.

Linedef translation:
- It is possbile to have a linedef that when triggered by a TRIG_TAG
emits a SECTOR_TAG (range 1..255) that can activate any of the existing
sector actions.  However, an action will also be needed.


** Existing linedefs, and Generalized linedefs
- emit into TRIG_TAG namespace when tag is in range 0xFF00..0xFFFF
  TRIG_TAG = TAG & 0x00FF
- door open linedefs, emit OPEN
- door close linedefs, emit CLOSE

****** Generalized Trigger linedefs
- generalized trigger has Boom trigger fields
- can have additional enhanced triggers in additional linedefs
- have dual emitting TRIG_TAG
  - emit both the upper and lower TRIG_TAG
  - usually the upper half will be 0
Examples
- WR-player, emits ON
- WR-monster, emits ON
- PUSH, emits ON

Use of the existing Generalized Trigger linedefs with 0xFFxx tags
serves the same need, leverages existing linedefs, and has wide coverage.
Except for a few triggers to serve specialized needs.

****** New Trigger linedefs

LINEDEF: PUSH-PUSH button
- emits TRIG_TAG  ON, OFF
- alternates the OFF ON actions
- when emit ON, change to on texture
- when emit OFF, change to off texture

LINEDEF: UP-DOWN control
- emits  TRIG_TAG  UP, DOWN
- when player is within pushing distance of the linedef,
presses of the UP key will emit the TRIG_TAG UP,
and presses of the DOWN key will emit the TRIG_TAG DOWN.
(UP and DOWN keys are redefinable by user,
but may be PAGE-UP PAGE-DOWN)


****** New sequencer linedefs

LINEDEF: Sequencer
- receive  TRIG_TAG  any-kind
- when triggered it starts a sequencer thinker that steps down a chain
of linedefs, firing each in turn, until it reaches only linedefs with type 0.
- Sequencer delay
The sequencer delays at each linedef according to the length of the linedef.
The length is in fixed point, converting to a delay in tics.
  delay = (length - 2) * 1/2 second
  length = (delay * 2) + 2
A length less than 2 means to immediately proceed to the next linedef
in this tic.
- Sequential firing
After the delay the sequencer looks at the linedefs that share vertex2.
It triggers each one that has a non-zero type.  It does not matter
what kind of linedef it is.  If the linedef type is not recognized,
the linedef becomes a plain delay.
- If there is more than one linedef sharing vertex2, then all of them
will have independent sequencers.  All the linedefs sharing vertex2
will fire in the same tic.
- This allows TRIG_TAG to fire any kind of linedef action,
irregardless of its trigger.  This allows use of all the existing
linedef actions with the TRIG_TAG system, without using any additional
TAG values.
- If the sequencer reaches a linedef it has already fired in this tic,
it must stop. This is to block loops from hanging the engine,
not a design feature to be used.
- Joins of sequence branches are allowed.
- The sequencer can only proceed from vertex1 to vertex2. It cannot go
backwards up an alternative join branch because of the line directionality.
- Loops are allowed, as long as there are gates or delays.
- It provides delayed actions and timing.
- It provides a ladder-diagram style appearance on the level map.
- It provides fanout.
- Cheaper than voodoo dolls on a conveyor, and does not have problems
  with linedefs that are too close together.
- There are no actions that can change the firing order or lengths,
  so the most vertex search and delay calculations can be done at level
  load-time.
- When used to trigger linedefs that expect a TRIG_TAG LEVEL,
  if the sequencer was triggered by a TRIG_TAG LEVEL, it will be passed on.
  Otherwise a default value of 128 will be passed.
- When used to trigger linedefs that expect a TRIG_TAG HEIGHT,
  if the sequencer was triggered by a TRIG_TAG HEIGHT, it will be passed on.
  Otherwise a default height of 128 will be passed.


LINEDEF: Sequencer delay
- does not receive  TRIG_TAG
- no action except delay
- to shut up level editors that do not like illegal value in type field

LINEDEF: Sequencer gate
- receive  TRIG_TAG  any-kind
- initialized with gate closed
- when gate is closed the sequencer will stall at this linedef until
the gate is open
- receive TRIG_TAG ON
  - gate open, stay open
- receive TRIG_TAG OPEN
  - gate open, close after door delay
- receive TRIG_TAG CLOSE
  - gate close, stay closed
- receive TRIG_TAG OFF
  - gate close, stay closed
- receive TRIG_TAG UP
  - gate open, stay open
- receive TRIG_TAG DOWN
  - gate close, stay closed
- does linedef length delay after testing gate or opening gate

LINEDEF: Sequencer skill level gate
- does not receive  TRIG_TAG
- TAG value has skill levels
  TAG value =  (max_skill_level_allowed << 4) + min_skill_level_allowed;
  - TAG upper bits are reserved for expansion
- when max_skill_level_allowed is 0, then is equality test on
  min_skill_level_allowed.  Makes it easier to read.
- max_skill_level_allowed can be 0xF, which causes max test to accept anything
- min_skill_level_allowed can be 0, which causes min test to accept anything
- blocks and kills sequencer when skill level is not within TAG range
- does linedef length delay after testing gate
- skill level settings
  0 - unused
  1 - easy
  2 - 
  3 - 
  4 - hurt 
  5 - nightmare

  8 - coop
  9 - team
  A - deathmatch

  F - anything


LINEDEF: Sequencer no delay connector
- does not receive  TRIG_TAG
- propagates sequencer with no delay, length has no effect
- allows connecting sections of sequence without having to move vertexes.


****** New Floor linedefs that use the TRIG_TAG

LINEDEF: Move floor
- move the side1 sector floor
- default speed is normal speed
- receive TRIG_TAG ON
  - floor level to floor level of sector with TAG=0xFE01, else 256.
- receive TRIG_TAG OPEN
  - floor level to highest adj floor
- receive TRIG_TAG CLOSE
  - floor level to lowest adj floor
- receive TRIG_TAG OFF
  - floor level to floor level of sector with TAG=0xFE0F, else 0.
- receive TRIG_TAG UP
  - floor level up according to TRIG_TAG speed and target parameters
- receive TRIG_TAG DOWN
  - floor level down according to TRIG_TAG speed and target parameters
- receive TRIG_TAG LEVEL
  - move floor to TRIG_TAG LEVEL value, converted to FIXED and used as a height
- receive TRIG_TAG HEIGHT
  - move floor to TRIG_TAG HEIGHT value, normal speed


LINEDEF: Move floor fast
- move the side1 sector floor, at fast speed
- same as LINEDEF move floor, except that the speed is always fast.

LINEDEF: Move floor slow
- move the side1 sector floor, at slow speed
- same as LINEDEF move floor, except that the speed is always slow.

LINEDEF: Move floor creaky
- move the side1 sector floor, at creaky speed
- same as LINEDEF move floor, except that the speed is always creaky.
- creaky speed
  - speed changes during movement
  - initial speed is 1/4 normal speed
  - max is 3/4 normal speed
  - min is 1/8 normal speed, does not quite stop
  - max speed change per tic is 1/8 normal speed
- reference
  - execute every 1/4 second
  if( floor->surge != 0 )
  {
    if( floor->surge > 0 )
    {
       floor->surge --;
       speed += 1/8;
    }
    else
    {
       floor->surge ++;
       speed -= 1/8;
    }
    goto check;
  }
  else
  {
    c = P_Random(0..127);
    if( c < 50 )
    {
      if( c < 28 ) speed -= 1/8;
      else  speed += 1/8;
      goto check;
    }
    else if( c < 90 )
    {
      if( c < 72 ) floor->surge = -(c&0x3) - 1;
      else floor->surge = (c&0x3) + 1;
    }
    else if( c < 99 )
    {
      floor->surge = 5;
    }
  }
  return;  // no change
  
check:
  if( speed > 3/4 )  speed = 3/4;
  if( speed < 1/8 )  speed = 1/8;
  return;
  
  

LINEDEF: Move floor delayed
- move the side1 sector floor
- same as LINEDEF move floor, except that the movement is delayed
- Delay by the number of seconds in the TAG field upper half, 0x01..0xFF.
  The lower half is the TRIG_TAG receive value.
- Delay by the number of seconds in the side2 xoffset field.
  This is for users that hate putting the delay in the TAG field, or who
  want to modify it using scripts.
- Default. If there is no side2, and TAG field upper is 0,
  then delay by 1/2 second.

LINEDEF: Send floor HEIGHT
- emit TRIG_TAG HEIGHT
- send the floor HEIGHT of the side1 sector.
- triggers whenever the floor level of the side1 sector changes, and at start
- limited to once per tic, to prevent looping


****** New Ceiling linedefs that use the TRIG_TAG
- ceiling versions of move floor

****** New Elevator linedefs that use the TRIG_TAG
- elevator versions of move floor

****** New Light linedefs that use the TRIG_TAG

LINEDEF: Light control
- the side1 sector has the light level modified by the linedef
- there may be multiple controls that modify the light level of the sector
  - assume that only one is actived on any tic
  - keep current light level in the sector, do not know the original
    light level
- receive TRIG_TAG ON
  - light level to 244
- receive TRIG_TAG OPEN
  - light level to 180
- receive TRIG_TAG CLOSE
  - light level to 80
- receive TRIG_TAG OFF
  - light level to 20
- receive TRIG_TAG UP
  - light level + 40
- receive TRIG_TAG DOWN
  - light level - 40


LINEDEF: Sector light send
- emits TRIG_TAG LEVEL
- the level value is the light level of the side1 sector
- triggers whenever the light level of the side1 sector changes, and at start
- limited to once per tic, to prevent looping

LINEDEF: Sector light receive
- receive TRIG_TAG LEVEL
  - the level value is the light level to apply to the side1 sector
- also responds to the other TRIG_TAG types as in LINEDEF Light Control.
- sets the side1 sector light level
- if there are multiple per tic, the last will overwrite any previous values
- connect to indirect actions with no max, no averaging

****** Sector lighting

LINEDEF: Sector light sector max
- receive none
- set the light level of the side1 sector
- the TAG value is a SECTOR_TAG
- the sector light is the max light level of all the sectors found
with that SECTOR_TAG
- follows blinking sector caused by sector type
- does not follow lights that are added to the sector light level
- the order of processing linedefs may affect the results if
those sectors are also being modified


****** Wall lighting

LINEDEF: Wall light receive
- receive TRIG_TAG LEVEL
  - the level value is the light level to apply to the side1 sector wall
- also responds to the other TRIG_TAG types as in LINEDEF Light Control.
- Displays the last received level, even if there are multiple per tic.
- connect to indirect actions with no max, no averaging

LINEDEF: Wall light static
- receive none
- the TAG value is a SECTOR_TAG
- the wall light is the light level of the first sector found
with that SECTOR_TAG, copied at level load-time, and never updated
after that.

LINEDEF: Wall light sector link
- receive none
- the TAG value is a SECTOR_TAG
- the wall light follows the light level of the first sector found
with that SECTOR_TAG
- follows blinking sector caused by sector type
- does not follow lights that are added to the sector light level

LINEDEF: Wall light sector max
- receive none
- the TAG value is a SECTOR_TAG
- the wall light is the max light level of all the sectors found
with that SECTOR_TAG
- follows blinking sector caused by sector type
- does not follow lights that are added to the sector light level
- the order of processing linedefs may affect the results if
those sectors are also being modified

 

Share this post


Link to post

Way too complicated, if you ask me.

 

The more complex stuff is being considered the more this just asks for implementing Hexen format specials which allows doing all this without those ugly hacks.

Seriously, what do we want here? Is keeping these numbers really worth all the mess being proposed?

The sole advantage of keeping this in Doom format is that people can use the line special numbers they remember. Once that part becomes secondary the entire format loses its appeal, because every other change in Hexen format just adds new options but doesn't really change anything (that is, execpt for adding 64 to the sector specials, but that's something the editors should handle well enough to not become a problem.)

 

If mappers cannot adapt to different numbers to gain more flexibility, they also won't adapt to this mess because it's even less intuitive.

 

Share this post


Link to post

The things I most wanted to do, I cannot do just using more generalized linedefs.  Trying to encode every trigger into the linedef of every new action gets to be too much.  And creating  a new trigger like PUSH-PUSH button, and UP/DOWN keys, cannot be used by existing generalized linedefs because it is not encoded into their triggers.  A mechanism that lets me use existing Open Door linedef as a trigger for new things solves my problems.   A mechanism that lets me attach a new trigger type to start existing linedef actions also solve my problems.    I am not using up half the linedef code space, I am trying to avoid using chunks of linedef code space.  I think there should be one set of generalized triggers, that can be connected to new and future specialized action linedefs.  There is no connection mechanism now except TAG, and as in the UDMF discussion, there a multiple problems with trying to leverage them for new purposes.   The TRIG_TAG system is one way to do the connecting, and seems to be the best one I have invented yet.

 

I have been working on these extensions for a few years.   I have always had to invent something similar every time.

So, I don't think I will be able to contribute much without such a mechanism.

 

The TRIG_TAG mechanisms is specifically designed to work within the existing Boom format.   It is an extension to the Boom format.  UDMF is another system entirely, that would not have the same limitations, and probably can easily allow triggers to be combined with new actions.  But DoomLegacy does not have UDMF and it would 4 to 5 years before I could even get around to adding such a thing, and it does not give me anything of immediate value except that DoomLegacy could play UDMF level maps.  I can get what I want more simply and faster by extending Boom format with a system like TRIG_TAG.

 

TRIG_TAG should be easy to implement.  Mostly it copies the generalized linedef parameters, finds the action linedef that was triggered, and passes an action code and the parameters to the action linedef.  Can you think of a way to connect an UP/DOWN switch to make an elevator go UP/DOWN with just generalized linedef?   And then also use the UP/DOWN switch to control a light level, a machine speed, floor level, and something else that I may invent next year?

 

Share this post


Link to post

The problem I see here that this basically reinvents the wheel. Take Hexen line specials plus ACS and we are nearly there feature wise.

One thing I am dead set against is a scripting system encoded into map data and a large part of your proposal looks exactly like that.

 

Not only because it makes the maps a mess to figure out but also because of the effort to implement this stuff. In the time to get it working I may just backport a large portion from ZDoom to implement a mostly complete Hexen format, including basic ACS support. And that's proven code from which I know that it works as advertised.

 

Share this post


Link to post

As codeveloper of a map editor, hacking the tag value to mean completely different things sounds like a headache to handle.

Share this post


Link to post
8 hours ago, Graf Zahl said:

Regarding scrollers, I think the most important ones are replicas of the 4 Hexen types that scroll in one cardinal direction with different speed options, and it would make sense to use 256 or 512 numbers here to have maximum flexibility - maybe even duplicate the numbers to have diagonal scrollers as well.

 

 

If I'm understanding @esselfortium correctly I think we just need to add some additional specials (extended type, not via generalised type) that set scroll vector based on front sidedef offsets? There are 16-(17?) scrolling specials at present so it might be that amount of specials needed at most? Additionally (perhaps as part of a property transfer gen-type?) being able to transfer effect/behaviour from one sector to the next might afford on/off scrolling state.

 

I think any set of new types will need to be rationalised somewhat down to what make good building blocks for basic actions and then flexible enough for use in conveyor setups like is done now.

 

@Graf Zahl What you have described AFAIK is already possible with the existing Boom extended types using the linedef to set vector.

Share this post


Link to post

The 'linedef to set vector' type is really not that nice to use. In Hexen you got 4 specials, for each direction one, and just set a speed value between 1 and 255.

 

Share this post


Link to post

Though I technically second @esselfortium's suggestion (Boom's scrollers are abysmal), I'm quite confident that a handful of "scroll texture down" specials would cover about 95% of use cases.

Share this post


Link to post

What does that cover @Xaser? Waterfalls is all I can think of - I'm one of the more simple mappers though ;)

Share this post


Link to post

2 more? (Edit: these would allow texture alignment of upper/lower separate to mid tex)

 

  • (static) Apply front sidedef offsets to tagged sector/linedef upper tex
  • (static) Apply front sidedef offsets to tagged sector/linedef lower tex
Edited by traversd
Context!

Posted (edited)

Share this post


Link to post
5 hours ago, traversd said:

2 more? (Edit: these would allow texture alignment of upper/lower separate to mid tex)

 

  • (static) Apply front sidedef offsets to tagged sector/linedef upper tex
  • (static) Apply front sidedef offsets to tagged sector/linedef lower tex

I can still remember how much of a hassle it was to implement that in ZDoom - although I didn't bother with transfer types. Should be doable, though.

 

 

Share this post


Link to post
15 minutes ago, Graf Zahl said:

I can still remember how much of a hassle it was to implement that in ZDoom - although I didn't bother with transfer types. Should be doable, though.

 

 

Yeh, I did think "this is probably a massive PITA to implement" oh well, put it up and if it can cool. if not... no biggie :)

Share this post


Link to post
14 hours ago, traversd said:

What does that cover @Xaser? Waterfalls is all I can think of - I'm one of the more simple mappers though ;)

Waterfalls alone are precisely what I had in mind. I suppose the pluralization on "use cases" is up for debate then. :P

Share this post


Link to post
20 hours ago, wesleyjohnson said:

(a proposed linedef method)

 

If nothing else, the PortType indicator I described a few times will allow you to implement this as a port-specific addition, for maps with "PortType = Legacy". Other ports can choose to support this standard, or otherwise show an error message "Cannot load Legacy-format maps.". In Legacy, "PortType = Legacy" informs your port to interpret line specials using the Legacy method. And, for non "Legacy" maps, you can still use the extended Boom+ specials, even if they use the upper range. It's a win-win, that allows us to move forward, while simultaneously allowing Legacy to adopt the new standard as well.

 

In fact, maybe the PortType indicator only applies to a subset of the range. However it's done, it's easy, and efficient to implement in a port and in editors. I think it'll be in the proposal, unless someone presents a really good reason not to.

Share this post


Link to post

Just kind of personally weighing in a little:

 

- C++: no

- DECORATE: no

- thing/frame definition stuff: no (there's no general agreement on how to do this yet)

- HeXeN: no

- ACS: no

- PortType/MapType: no - see below

- UDMF: yes

- UMAPINFO: if it ends up being an INI file, yes

- Versioning: yes (integers only please)

 

Re: PortType/MapType/linedefs:

 

The right way to handle linedef collisions is port-specific configuration.  That port can use heuristics or a database to configure itself, or it can use command-line options, or whatever, but what's done is done.  I deeply dislike the idea of encoding port information in binary map data, which is what it seems like this does (using a mask on linedefs), or using lump files to configure ports on the fly.  These features would only entrench the incompatibility, which should be staunched now.

 

There should be some coordination when using new linedefs to avoid problems like this.  Maybe a linedef registry, I don't know, but something.

 

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