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

[wesleyjohnson]

I rewrote the TRIG-TAG description.  The original description was done in a hurry and it included many wild ideas.

I expected that people would pick and choose which of the wild ideas they supported.

 

Comprehension has suffered.

 

TRIG-TAG V3 is a total rewrite, with the basic system presented more clearly, with any wild ideas pushed to the end.  Much of the concept has been reworked to simplify the logic.  How the action codes are used has been changed.  I changed some things to assuming that the modifier linedef system based on shared vertexes would be accepted.  Assuming that simplifies things, which shows why it is so important to deal with this now and stop trying to push it off.  Most every linedef design decision is dependent upon the modifier linedef and trigger linedef systems adopted.

 

There are only a few basic concepts that need to be accepted to implement TRIG-TAG.

Most of the description consists of examples of linedefs that would use the system.

There will also be some picking and choosing of the linedefs to implement (such as PUSH-PUSH switch) and the keyboard connected switch.

 

TRIG_TAG V3:  https://www.sendspace.com/file/17oii6

 

Right now, a new trigger linedef would have to use the Boom system with all the fields.  This eats up the linedef space.

TRIG-TAG provides a way to connect new triggers to action linedefs.

The sector-based-firing is like TRIG-TAG except that it lacks the additional parameters, and it requires a sector for each firing connection.

No other alternatives have been proposed.

 

This is a boom extension that is adding linedefs.  The most interesting things being discussed are the additions to linedefs.

Most such linedefs would require a system like TRIG-TAG due to code-space-exhaustion in the Boom system.

I cannot see how to put this decision off and accomplish anything with linedefs.

 

 

 

 

 

 

[wesleyjohnson]

I have been considering the sector-based-firing idea presented:

 

1. It is viable, but is not as capable as TRIG-TAG, as it leaves off the action coding.

2. It is not that different than TRIG-TAG, and that difference seems to be using a sector (so as to keep the TAG as a sector-TAG).   I keep feeling that this is a slight improvement in that there is only one TAG space, but it also the biggest hinderence.

3.  TRIG-TAG does not require sectors, can share linedefs with existing walls.

 

Consider a sequenced action.  A remote trigger starts everything.  The light around the door blinks red three times as the door slowly opens.  I picked an example with a sequence because that causes the most problems for the sector-based-firing.  This example does not show-off any action code usage of TRIG-TAG, the SECTOR-BASED-FIRING not having that capability.

 

TRIG-TAG:

  A pushbutton trigger linedef (TAG=3, ACTION=ON) starts everything.

  A sequencer linedef (TAG=3)  accepts the TRIG-TAG action and starts a sequencer.

  There are two linedef at vertex2, so the sequencer forks.

  One path consists of a chain of linedefs:

    red-light-on, delay, red-light-off, delay, red-light-on, delay, red-light-off, delay, red-light-on, delay, red-light-off.

  The other patch consists of a slow ceiling-raise operation (TAG=16, which is the door sector tag).  There is a modifier linedef that causes the ceiling to raise at 4x-slower than normal (to be more dramatic).  The modifier acts upon the ceiling-raise linedef, but is ignored by the sequencer.  (How and why it is ignored is one of those details that must be decided as there are several ways to get it to be ignored).

 

SECTOR-BASED-FIRING:

Sector-based-firing (only has sector tags), that uses delay linedef to fire another sector (to get a sequence).

  A pushbutton trigger linedef (TAG=3, ACTION=ON) starts everything.

  There is a sector with TAG=3, and it has the 4 linedef.

     - red-light-on

     - a ceiling raise linedef

     - a modifier linedef that makes the ceiling raise x4-slow

     - a delay linedef (TAG=4)

  There is a sector with TAG=4,

     - red-light-off

     - a delay linedef (TAG=5)

  There is a sector with TAG=5,

    - red-light-on

    - a delay linedef (TAG=6)

  There is a sector with TAG=6.

    - red-light-off

    - a delay linedef (TAG=7)

  There is a sector with TAG=7,

    - red-light-on

    - a delay linedef (TAG=8)

  There is a sector with TAG=8.

    - red-light-off

 

 

The TRIG-TAG bases solution has far less overhead (in sectors and extra linedefs).  The sequence of red lights on and off would be visible as a chain of action linedefs.

In the SECTOR-BASED-FIRING, the sequence of red-lights on and off is difficult to see, especially if it was on a level map.

 

[Shadow Hog]

You probably want to put that in the dedicated scripting thread at this point...

[BigDickBzzrak]

The TRIG_TAG-v3 spec in the spoiler (I know we all are lazy people :] )

 

 

***** Trigger tag system, Ver3

SECTOR_TAG namespace:
The SECTOR_TAG namespace is used by existing Boom linedefs.
An action linedef will have a SECTOR_TAG value that selects the
sectors where the action effect will be applied.

Some Boss Death actions also generate SECTOR_TAG actions using some
fixed sector TAG values (666, 667).

TRIG_TAG namespace:
The TRIG_TAG linedef tag value selects one or more action linedefs that have
a matching TAG value.
The selected action linedefs will be triggered, if they can accept the
TRIG_TAG action code.
Any tag value can be used for TRIG_TAG, except 0 is excluded.
- Any tag value organization is difficult to retrofit later.
- The internal TRIG_TAG structures must handle uint16_t TAG values.

There can be more than one trigger linedef with the same TAG value.
The trigger linedefs are not affected when another trigger linedef with the
same TAG value fires.  They are ignored during the TAG search.

A TRIG_TAG firing is always accompanied by an action code and
additional parameters.
The action generated is determined by the TRIG_TAG trigger linedef type.

There will be additional parameters carried by the TRIG_TAG firing.
1. The parameter structure will be complete enough to transfer all the
information encoded in any generalized linedef.
2. Any generalized linedef fields that appear in a TRIG_TAG trigger
linedef will set the corresponding parameters and be available to the
action linedef.
3. A TRIG_TAG linedef may supply parameters for speed and target height.

Advantages of the action code.
1. This allows some new linedef to respond to two different triggers,
such as up and down.
2. It allows a new push-push switch to alternate between OFF and ON.
3. It many cases the action linedef TAG value can be used for TRIG_TAG
and as a SECTOR_TAG.  This would be the easy way to use TRIG_TAG with
existing Boom action linedefs.  There may be multiple linedefs with the
same SECTOR_TAG, but only the ones that can respond to the action code
will be triggered.  This requires using TRIG_TAG that emit specific
actions, not the ones that emit ON (which triggers anything).

TRIG_TAG action list:
0: OFF
1: general trigger, ON
- push
- generalized, will fire any action linedef (but not trigger linedef)
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

Trigger Linedef:
- React to the some stimulus and generate a TRIG_TAG trigger.
- Only when a TRIG_TAG linedef fires can a TRIG_TAG trigger be initiated.

Action Linedef:
- A linedef can be affected only if it has a TAG that matches the TAG value
of some TRIG_TAG linedef.
- When a TRIG_TAG linedef fires, it will trigger any other linedef
with the same TAG value.


- When triggering linedefs that expect a TRIG_TAG LEVEL,
if the level parameter is not supplied a default value of 0 will be
passed.

- When triggering linedefs that expect a TRIG_TAG HEIGHT,
if the height parameter is not supplied a default value of  none   will be
passed.


****** Generalized Trigger linedefs
- Generalized trigger has Boom trigger fields
- There will be additional trigger linedefs that implement more
specialized triggers.

LINEDEF: TRIG_TAG player
- linedef code has embedded Boom style trigger field.
- linedef code has embedded TRIG_TAG action code

LINEDEF: TRIG_TAG player and monster
- linedef code has embedded Boom style trigger field.
- linedef code has embedded TRIG_TAG action code

When linedef code has embedded TRIG_TAG action code
0: OFF
1: ON
2: OPEN
3: CLOSE
4: UP
5: DOWN
6: LEVEL
 - the side1 light level is the level parameter
7: HEIGHT
 - the side1 floor height is the height parameter
- these parameter values may be overridden at the action linedef
  by modifier linedef, or ignored by the action linedef.

****** 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)
- this can be used for
  - elevator control up and down
  - floor control
  - ceiling control
  - light control


LINEDEF: TRIG_TAG monster-walkover-only
- triggered only by monster
- emits TRIG_TAG ON

LINEDEF: TRIG_TAG missile-hit
- triggered by impact that does 18 damage, or more.
  - by missile (20 damage)
  - or something that does at least missile damage (BFG)
  - fixed trigger level, not subject to BEX changes
- emits TRIG_TAG ON

LINEDEF: TRIG_TAG floor lower or equal
- triggered by side1 floor matching or lower level than side2 floor
- triggered once
- reset when side1 floor is higher than side2 floor
- emits TRIG_TAG ON

LINEDEF: TRIG_TAG floor higher or equal
- triggered by side1 floor matching or higher level than side2 floor
- triggered once
- reset when side1 floor is lower than side2 floor
- emits TRIG_TAG ON

LINEDEF: TRIG_TAG push-button current floor
- push button
- emit TRIG_TAG HEIGHT
- height parameter is the floor level of sector that triggering player
  (or monster) is in
  - floating players still would send the floor level
  - as in Boom elevator to current floor,
    except that it also works when the switch is inset into the wall
    - in Boom this would bring the elevator to the bottom of the switch


****** Existing Floor linedefs that are fired by TRIG_TAG
Most Doom and Boom linedefs that move floor.
- The action linedef is fired indenpendently of any trigger specification
in its linedef.
- This will require a specific list, and some Boom linedefs may be
excluded.
- The action linedef may also be modified by a modifier linedef.

- receive TRIG_TAG ON
  - execute their normal action

- receive TRIG_TAG UP
  - execute their normal action only if it is normally UP

- receive TRIG_TAG DOWN
  - execute their normal action only if it is normally DOWN

- receive TRIG_TAG HEIGHT
  - execute their normal action with the height parameter as the target height

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

LINEDEF: Move floor
- move the side1 sector floor
- default speed is normal speed
- receive TRIG_TAG OFF
  - ignored
- receive TRIG_TAG ON
  - ignored
- receive TRIG_TAG OPEN
  - floor level to highest adj floor
- receive TRIG_TAG CLOSE
  - floor level to lowest adj floor
- receive TRIG_TAG UP
  - floor level up according to TRIG_TAG speed and target parameters
  - if target height is not specified, it is nHf
- receive TRIG_TAG DOWN
  - floor level down according to TRIG_TAG speed and target parameters
  - if target height is not specified, it is nLf
- receive TRIG_TAG LEVEL
  - ignored
- receive TRIG_TAG HEIGHT
  - move floor to TRIG_TAG HEIGHT value, normal speed


The following specialized floor linedefs could be implemented
in a more general way using modifier linedefs on the action linedef.
Or else these could be viewed as an action linedef with an inherent modifier.

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
- better done using a specific delay linedef (see sequencer)

LINEDEF: Floor HEIGHT send
- 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
- may also be triggered by TRIG_TAG tag match, a delay or sequential linedef.
- limited to once per tic, to prevent looping
- requires a Move floor linedef on the sector, with a matching tag.


****** 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

This can also be achieved by a modifier linedef that locks the floor and
ceiling movement together (making an elevator).

****** 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
  - if invoked multiple times in a tic, the last will overwrite any previous
    values
  - keep current light level in the sector, do not know the original
    light level
- receive TRIG_TAG OFF
  - light level to 20
- 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 UP
  - light level + 40
- receive TRIG_TAG DOWN
  - light level - 40
- recieve TRIG_TAG LEVEL
  - light level to level value


LINEDEF: TRIG_TAG Sector light send
- receives TRIG_TAG ON
- emits TRIG_TAG LEVEL
- the level value is the light level of the side1 sector
- may also be triggered by TRIG_TAG tag match, a delay or sequential linedef.
- requires a Light control linedef on the sector, with a matching tag.

LINEDEF: TRIG_TAG Sector light repeat
- triggers whenever the light level of the side1 sector changes, and at start
- emits TRIG_TAG LEVEL
- the level value is the light level of the side1 sector
- limited to once per tic, to prevent looping
- requires a Light control linedef, or wall light



****** Sector lighting

LINEDEF: Sector-TAG light send
- copies the side1 light level to all sectors with same sector-TAG
- the TAG value is a SECTOR_TAG
- triggers whenever the light level of the side1 sector changes, and at start
- may also be triggered by TRIG_TAG tag match, a delay or sequential linedef.
- limited to once per tic, to prevent looping

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



****** Universal receiver
Connects a trigger to a firing, in the general case, avoiding TAG conflicts.

LINEDEF: Fire vertex2
- receive  TRIG_TAG  any-kind
- when triggered it immediately triggers any linedefs that share its
vertex2.
- This allows using a different tag code for the trigger and the
sector-TAG.
- This adapts any trigger type to fire any action type.
- as it only requires the type field, often an adjacent linedef to
the action linedef will be freely available.
- being adjacent to the action linedef makes the association easy to see.


****** Delays and Gates
These can be triggered directly, or in sequenctial linedef.
- When triggered directly
  - by a TRIG_TAG trigger linedef with the same TAG value
  - they DO NOT start a sequencer
  - they will only trigger the immediately adjacent linedefs on vertex2
  - when a gate is closed, the trigger dies
- When encountered by a sequencer
  - the sequencer does any delay, and then the sequencer proceeds
  - the sequencer will be stalled by a gate condition


LINEDEF: Delay seconds vertex2
- receive  TRIG_TAG  any-kind
- when triggered it delays for the selected time,
then triggers any linedefs that share its vertex2.
- the number of seconds to delay is in the light level field of the
side1 sector.
- may also be used in sequential linedef.

LINEDEF: Delay length vertex2
- receive  TRIG_TAG  any-kind
- when triggered it delays for the selected time,
then triggers any linedefs that share its vertex2.
- The delay is determined by line length.
- This is the same linedef as in Sequential linedefs.

LINEDEF: Line length delay
- can receive  TRIG_TAG  any-kind
- no action, just delay
- to shut up level editors that do not like illegal value in type field
- if triggered directly it will not start a sequencer
  - in this case it will only trigger the linedefs directly sharing
    its vertex2.


****** Sequencer
- Voodoo doll replacement

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 - 4) * 1/2 second
  length = (delay * 4) + 2
A length less than 4 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 be given 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.
- The sequencer can only proceed from vertex1 to vertex2. It cannot go
backwards up an alternative join branch because of the line directionality.
- Joins of sequence branches are allowed.  If two branches join and
both have active sequencers, then both will continue after the join,
and both will fire the linedefs after the join.  They may even fire
the same linedefs at the same time.  Most often you will want your
joined branches to be mutually exclusive.
- Loops are allowed, as long as there are gates or delays.
- 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.

Trigger parameters:
- The trigger action and parameters such as level and height,
will be passed on by the sequencer until they are used by an action
linedef.
- Modifier linedefs and some TRIG_TAG linedefs may modify the action and
parameters before reaching an action linedef.  This can be done before
any action linedef.
- An action linedef may be modified directly by a modifier linedef.
This overrides the corresponding specific trigger action or parameter,
without affecting other trigger parameters.
- The original trigger action and parameters are cleared by the
sequencer when it fires an action linedef.
  - The action code used by the sequencer will default to ON.

Sequencer linedef system advantages:
- provides delayed actions and timing.
- the sequence of linedefs can appear in a dedicated sector
  - can be arranged in a ladder-diagram on the level map.
  - easy to visualize the sequence of actions
- the sequence of linedefs can be any convienent wall linedefs
  - most do not interfere with any sidedefs or sectors
- 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.


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 stall gate
- sequencer only
- initialized with gate closed
- when gate is closed
  - a sequencer will stall at this linedef until the gate is open
- received TRIG_TAG changes the gate status
  - does not test the gate
  - does not trigger linedef after the gate
- receive TRIG_TAG OFF
  - gate close, stay closed
- 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 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 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.


***** TRIG_TAG 0
OPTIONAL IDEA
An additional way to connect to the action linedef.

When the TRIG_TAG value is 0, and there is an action linedef that
shares vertex2, then a trigger of the TRIG_TAG linedef will
trigger that action linedef.  There is never a search of linedefs that
match a TRIG_TAG value of 0.

The action linedef needs to have a type that cannot be triggered in
that usage.  A walkover (WR) linedef that is in a wall is usually a
good choice.  Push and Gun triggers are bad choices as the player
could trigger them, bypassing the TRIG_TAG trigger linedef.

Another method is to have the action linedef outside the area that the
player can reach, such as a small attached sector.

There can be multiple action linedef sharing vertex2, and all of them
will be triggered.

Advantages:
1. Easy visual association of the trigger linedef to the action linedef.
They are adjacent in the level map.
2. The action linedef can use a sector-TAG without any conflict from
the TRIG_TAG linedef.

***** Expansion of TAG usage
OPTIONAL IDEA, NOT RECOMMENDED
The TAG field has enough width that there are far more values than
are needed for most level maps.
Hardly more than 30 tag values are used in a large level map.

TAG value ranges (namespaces) are not a necessity, just a consideration.
There may be some reason later that requires identifying a sector-TAG
from a TRIG-TAG, and using specific TAG value ranges would be one method.
If an Ad-Hoc TAG values are allowed (no TAG value restrictions) then
this would be difficult to retrofit later.

Tag Values:
     0 .. 0x0FFF : sector-TAG
0x1000 .. 0x1FFF : TRIG-TAG
0x2000 .. 0x2FFF : Action-TAG


TRIG_TAG and Action-TAG may be converted to their own namespace.
Within that namespace, the value 0, is no-action, no-trigger.
This also excludes effects using sector-TAG of 0.

The value 0 may at some time be used for some other effect.

***** Interface with existing triggers.
OPTIONAL IDEA, NOT RECOMMENDED
Using existing Doom and Boom trigger linedefs to initiate a
TRIG_TAG triggering.
With the basic proposal this is not possible.

The easiest and simplest solution is to use the set of TRIG_TAG linedefs
that duplicate those triggers.

Alternative Idea using range translation:
Using TAG range identification and translation, it would be possible
to have a Boom linedef trigger a TRIG_TAG action.
This would intercept SECTOR_TAG values that are in the range 0xFF00 to 0xFFFF.
They would be converted to the TRIG_TAG namespace range 0x00..0xFF,
and would not be used as SECTOR_TAG values.
This allows all existing generalized linedefs that use TAG to also be used
as generalized triggers.

 

[Graf Zahl]

Re: Trig-Tag:

 

First, it was a pain reading through that verbose spec. It's far too much text to swallow.

Second, while I had difficulty comprehending the whole thing due to its size, what I did understand sounds like a major turn-off for any port willing to implement a common standard. As the length of that spec already hints, it's a major piece of work. And it all boils down to some very unattractive 'scripting with no scripting' solution.

 

Sorry, but try to peddle this to other as long as you like, the chance of this ever going to be adopted is precisely - ZERO.

What we need here is a list of SIMPLE features, or at most simple to port features, not writing a major piece of logic code that at worst doesn't mix well with how more advanced ports work and at best will be a major investment of resources.

 

 

 

[Jon]

OK just to pick on a single, relatively simple suggestion that was made: insta-death sector (floor) type.

Zdoom has a type 115 which is an insta-death on touch of sector floor, currently for hexen format maps only. It does not wait for the damaging floor tic to take effect, it only takes effect when the actor is touching the floor and is considered "in" the sector (so: if you set it on a traditional-style teleport sector, it's possible to edge up onto the teleport such that you have not crossed the lines, and thus would not have teleported, but your viewpoint/height has raised, but you aren't dead yet). The death tyep is instant to 0 health but does not (appear) to be a gibbing.

(This is apparently from Strife.)

Does that cover everyone's use cases? In the context of this proposal, if we defined exactly this behaviour (and tentatively pencilled in type 115 , too, although I think this conflicts with Boom?), is that good enough?

 

At risk of overdesigning here, but would an additional variant for void style situations be useful? perhaps one that involved a fade-to-black, or deleted the things from the sector (perhaps: things should appear to travel through the floor, as if it was fake, never to return, non-ressurectable etc.)

 

[Altazimuth]

I think we need to collate a list of things that are and aren't happening, to stop suggestions of things already asked for that certain ports can't do e.g. specific sector special ranges, or the extra DeHackEd frames from crispy/retro. Team Eternity has explained why some stuff is not doable for us but a few pages later people just request it again.

 

This continued unabated barrage of feature requests will only end up with something slipping through that one port isn't capable of for whatever reason and then the whole idea of the standard fails at its purpose of providing more cross-port features to modders.

 

And then there's the issue of lack of transparency in development from kb1. If we knew what was being worked on or coming up soon on the development chopping block then we'd be able to stop something that ends up wrecking the standard before it happens.

 

I don't expect people to look at every port's documentation on its features before requesting something, but this seems currently unmanageable and unsustainable.

[Quasar]

3 hours ago, Jon said:

OK just to pick on a single, relatively simple suggestion that was made: insta-death sector (floor) type.

Zdoom has a type 115 which is an insta-death on touch of sector floor, currently for hexen format maps only. It does not wait for the damaging floor tic to take effect, it only takes effect when the actor is touching the floor and is considered "in" the sector (so: if you set it on a traditional-style teleport sector, it's possible to edge up onto the teleport such that you have not crossed the lines, and thus would not have teleported, but your viewpoint/height has raised, but you aren't dead yet). The death tyep is instant to 0 health but does not (appear) to be a gibbing.

(This is apparently from Strife.)

If that's how ZDoom implemented it, it's not actually being Strife compatible. Strife sector type 15 does a finite 999 damage per tic, and it will indeed cause gibbing to occur.

[Xaser]

@Altazimuth The whole point of this thread was to be a loose brainstorming suggestion where people can chuck feature ideas into a bucket. It's just about hit the point where the bucket's full and needs sifted by the actual port devs (ideally, in relative privacy, to filter out the noise), but that won't happen in this thread (nor was it meant to).

 

The Usual Fear: It seems like folks are getting in a thumb-twiddle deadlock and getting frustrated about things not happening before they've even started. We're still in the pre-game show, and everyone seems hesitant to hike the ball.

 

[Note that as a non-port-dev, I can't take action myself, hence the relative irony here x:]

 

Jon's kindly provided a starting point; somebody take the ball and start running for the end zone already:

On 6/28/2017 at 10:02 AM, Jon said:

I've read through the entire thread (please god shoot me now) and I've tried to flesh out an example only wiki page demonstrating how I would imagine a summary-style draft page of features to include would look like. It's rough, it's not intended to be me taking over editor ship of this, just an illustration, and I didn't bother to flesh out some of the proposals with technical details (implementation notes, type numbers, etc.) I also missed a lot of stuff out due to the meandering arguments that make up 90% of this thread. Feedback appreciated. https://doomwiki.org/wiki/User:Jdowland/boom%2B%2B#Specification

 

["ask me about football"]

[kb1]

9 hours ago, Jon said:

OK just to pick on a single, relatively simple suggestion that was made: insta-death sector (floor) type.

Zdoom has a type 115 which is an insta-death on touch of sector floor, currently for hexen format maps only. It does not wait for the damaging floor tic to take effect, it only takes effect when the actor is touching the floor and is considered "in" the sector (so: if you set it on a traditional-style teleport sector, it's possible to edge up onto the teleport such that you have not crossed the lines, and thus would not have teleported, but your viewpoint/height has raised, but you aren't dead yet). The death tyep is instant to 0 health but does not (appear) to be a gibbing.

(This is apparently from Strife.)

Does that cover everyone's use cases? In the context of this proposal, if we defined exactly this behaviour (and tentatively pencilled in type 115 , too, although I think this conflicts with Boom?), is that good enough?

 

At risk of overdesigning here, but would an additional variant for void style situations be useful? perhaps one that involved a fade-to-black, or deleted the things from the sector (perhaps: things should appear to travel through the floor, as if it was fake, never to return, non-ressurectable etc.)

 

Regardining over-designing: As ideas, they are welcome here. Of course, a ZDoom/Strife type 115 cannot be used as-is. Part of the design is to allow a remapping of non-Doom linedefs to a higher range, to provide a possible upgrade path to Doom-only ports to eventually be able to support other idTech1 games, or multi-game linedef usage in the same map. Please read below for more comments about this.

 

8 hours ago, Altazimuth said:

I think we need to collate a list of things that are and aren't happening, to stop suggestions of things already asked for that certain ports can't do e.g. specific sector special ranges, or the extra DeHackEd frames from crispy/retro. Team Eternity has explained why some stuff is not doable for us but a few pages later people just request it again.

 

This continued unabated barrage of feature requests will only end up with something slipping through that one port isn't capable of for whatever reason and then the whole idea of the standard fails at its purpose of providing more cross-port features to modders.

 

And then there's the issue of lack of transparency in development from kb1. If we knew what was being worked on or coming up soon on the development chopping block then we'd be able to stop something that ends up wrecking the standard before it happens.

 

I don't expect people to look at every port's documentation on its features before requesting something, but this seems currently unmanageable and unsustainable.

Altazimuth: If there is a "lack of transparency in development", that's because you are requesting that I make transparent the very first development: The spec. This must be done by someone looking at all aspects of all ports simultaneously, and being involved and responsible for all of it. That's what I have committed to do. The transparency comes naturally as soon as I present the first draft. I cannot produce draft "one-half". (Yeah, I could, but here's the thing: I can manage this stated first task. I cannot manage another 15-page debate on every aspect of the development of the first draft, without having the first draft to refer people to. We need to have something to look at, as a whole, because a spec of this size requires a global view of how each decision affects the whole, and I have no intention of trying to reactively defend every micro-decision, while those decisons are subject to change on a daily basis.)

 

You do know what's being developed - there's no secrets here. This thread is an idea thread. I am working on trying to get it to the next step, and suddenly I need to produce this next step as if it was a full-time paying job. Doom is working well for everyone currently. This is an enhancement, born from an idea I had about getting some more compatibility across ports. I need time to do so, and I will not rush the job. No one should want me to.

 

5 hours ago, Quasar said:

If that's how ZDoom implemented it, it's not actually being Strife compatible. Strife sector type 15 does a finite 999 damage per tic, and it will indeed cause gibbing to occur.

Good to know.

 

4 hours ago, Xaser said:

@Altazimuth The whole point of this thread was to be a loose brainstorming suggestion where people can chuck feature ideas into a bucket. It's just about hit the point where the bucket's full and needs sifted by the actual port devs (ideally, in relative privacy, to filter out the noise), but that won't happen in this thread (nor was it meant to).

 

The Usual Fear: It seems like folks are getting in a thumb-twiddle deadlock and getting frustrated about things not happening before they've even started. We're still in the pre-game show, and everyone seems hesitant to hike the ball.

 

[Note that as a non-port-dev, I can't take action myself, hence the relative irony here x:]

 

Jon's kindly provided a starting point; somebody take the ball and start running for the end zone already:

 

["ask me about football"]

Thanks, Xaser, for stating this so eloquently, including the bucket being full. I don't want to explicitly say that I'm full-up on ideas at the moment, but I am getting overwhelmed with it. Yet, I can handle what's here so far. I already have sorted lists of ideas. I must state that the ideas come after the compatibility-related protocols and methods. If I can get a select few of these ideas in for phase 1, that'll sweeten the pot. I do want to. But, yeah, everyone, again, please stay calm and exercise some patience - I am but a man, after all. I do appreciate the enthusiasm. It will not get dropped: it's too important to fail.

[kb1]

Please let me re-iterate. I do appreciate, and am thrilled with the enthusiasm, and offers of support. Believe me, when the time comes, I will need a lot of extra helping hands, and eyes upon the spec.

 

@Jon I especially appreciate your efforts in initiating the wiki page, and your continued desire to set it up. I am concerned about one aspect: Initially, I want the wiki to follow my spec, not the other way around. I have to establish a baseline spec for us to reference, otherwise this thread is the only other reference, and that's not good :)

 

In the other thread, I was suggesting that we create a private path of communication when the time is right. When I am nearly done with the first rough draft, I'd like to privately send it to you for translation to wiki format, if you're have the time, and you are willing to do it.

 

But, please also do continue to brainstorm: That's what I really need at this point.

 

@Altazimuth You're right - this thread is a mess, and there is a very real danger that I miss something, or duplicate something, or design something that has incompatibilities with a port. We will be able to catch these things post-release of the first rough draft. That is what I'm doing 'behind-the-scenes': writing a first rough draft. At that stage, everything becomes public for all to see, and scrutinize as necessary. And, after everyone voices their opinions and concerns, I will go back and revise the draft again, myself, incorporating the discussed changes to the spec. Then I'll re-release it with an updated version number. No big deal. Rinse and repeat. Those new drafts will go a lot faster, but I am taking my time on the first one.

 

There's no secret work here - we're all in the same boat we were in when I created this thread, yet, now, we have a pool of mix-and-match ideas. By accepting the challenge of writing such a spec myself, I also accept the responsibility of doing a good, thorough job with as few mistakes as possible. The ball is rolling, and it has a great distance to cover.

 

List of Ideas:

In regards to compiling a list of ideas: I have compiled a messy, yet complete list of ideas, from this thread, the other Boom+ "simple" idea thread, UMAPINFO thread, DeHacked extra states threads, a couple of threads I made years ago, as well as Quasar's enhanced lights, Wesley's TRIG-TAG v3, and Traversd's multi-trigger (fan-out) linedef ideas, and more.

 

I simply saved all of these pages to disk, and stepped through each page, cutting and pasting each post related to an idea, into a text file, while trying to preserve whose idea it was. Then I moved each item into categories. It's not very pretty at the moment, but it's currently complete up to about page 11 or so on the big thread, and all pages of the other threads.

 

If a leader were to step up, willing to take responsibility, in a separate thread, for managing a team that is researching the usefulness, and compatibility of each of these requests, in a way that jives with both the concepts I am developing for the spec, and the capabilities of each port, I would entertain the plan of splitting out my responsibility for managing these ideas to this team. But I would not want to completely relinquish my duties: I would want to oversee the thread, for example, and steer it in the right direction. This new thread would not accept new ideas - it would be a research thread only, hopefully devoid of silly arguments that derail the research. This team would have to give equal consideration to all ideas without bias. I have been telling everyone that their ideas will be given ample consideration, so I would not accept anything less.

 

I am not trying to sound like a dictator here. It's just that this is my project, and these are the restrictions I impose upon myself. These are the only terms that leave me feeling comfortable enough that I can trust the findings of others, to be well thought out and accurate, without having done all the work myself. I would love for this to happen, as I am quite overwhelmed with tasks at the moment. But my nature is to have unrealistically high expectations of any code or spec that I release, which might disturb and/or discourage some people. I am that way, because I want this project to be a huge success, be very powerful, easy to implement, easy to use...a joy to use.

 

I would need everyone to understand that, if this new team's efforts are not working out, I will have to salvage what I can from it, but re-assume the responsibility for completing the task myself. And, that may include simply pushing back the new idea stuff for a later phase, and concentrating on the core Boom+ compatibility/expansion stuff. In fact, I had not planned on adding any more than, maybe, a small handful of new linedef types, for the first spec.

 

This team would need a good people-person for a leader. Also needed is a mapper, proficient in, at least, Boom mapping. And, a programmer knowledgeable in the Doom, Boom source, as well as, maybe Legacy, Eternity, ZDoom, and others.

 

Ideas would be accepted in a hierarchy:

• Programmers and mappers would have to sign off that it's a valuable need that is clean, easy-to-use/implement, etc.
• The Team Leader would make sure it fits nicely within the project as a whole, and that the research is sound and presented logically.
• I need to make sure it fits within my spec, and I'd need to add it to the spec concisely and accurately.
• The port devs and map editor devs need to sign off on every idea in my spec, once it has been discussed, tweaked, revised, as needed.

So, no one should cling too tightly to any one idea, because the acceptance process is considerable.

 

So, any takers for Lead Manager of the Boom+ Idea Research Team? (makes it sound official, doesn't it? :)

 

Note that, if it doesn't work out, I'll get to all of it eventually, it'll just take more time. Either way, it will be months before code ever makes it into a port, which is why I keep asking for patience. Thanks.

 

 

 

[Urthar]

I'll gladly help with the mapping stuff.

[Jon]

Hey @kb1,  this is your baby, so we'll do it your way. I think I'm not alone in wishing/hoping the process was more open/transparent, but you've got to work in the way you are comfortable. I am happy to comment on drafts if you want to PM me and happy to help with wiki formatting. In the mean time let the brainstorming continue.

 

On the subject of the insta-death floor:
 

@Quasar  Ithink zdoom's implementation is exactly the same as Strife: I was testing it in a hurry with nosound so I wouldn't have been able to determine if it gibbed or not.

 

For this spec (which does not have to match strife after all, we can't reuse that special number in a boom context anyway):

 

What do people think of whether or not it should affect monsters? I can think of some interesting uses of it were monsters also affected, in particular if it was transferred into a sector (imagine a room and you hit a switch and insta gib all the monsters inside). Except that raises the question of what to do about flying monsters.

[NEANDERTHAL]

Flying monsters should be affected, unless we implememt damaging lines.

[Jon]

59 minutes ago, NEANDERTHAL said:

Flying monsters should be affected, unless we implememt damaging lines.

 

I think that would mean airborne players would be affected, too, so that would make this less useful for e.g. VOID floor situations since you couldn't leap over a gap through such a sector without being gibbed. Perhaps a second sector type for +affects air?

[esselfortium]

I think it's best to stick with the standard behavior of only taking effect when actually touching the ground. Other uses would probably best be served by an instakill walkover line.

[kb1]

@JonI apologize for my process looking closed. It would be more obviously open if I had adequate time to get it done. I am so completely bogged down ATM that it's moving along at a snail's pace. Once the first draft is released, subsequent drafts will come much faster. It's the kind of thing that needs to be done right (or very close) the first time, if possible, you know?

Thanks for the offer of comments and formatting. I'll be sure to take you up on those soon!

[Jon]

On 7/14/2017 at 9:53 PM, esselfortium said:

I think it's best to stick with the standard behavior of only taking effect when actually touching the ground. Other uses would probably best be served by an instakill walkover line.

OK! So, let's talk out an instakill walkover line special!

• WR ? Or do we want W1 variants?
• affects monsters?
  • should monsters be aware of them / avoid them?
• "always on" or toggleable?

 Anything else?

[Graf Zahl]

7 minutes ago, Jon said:

OK! So, let's talk out an instakill walkover line special!

• WR ? Or do we want W1 variants?

All trigger types?

 

7 minutes ago, Jon said:

• affects monsters?
  • should monsters be aware of them / avoid them?
• "always on" or toggleable?

 Anything else?

 

How would you toggle it without scripting?

Monster handling could be parameterized. For this type of special the tag could be used as a bit mask of options.

 

[Da Werecat]

1 hour ago, Graf Zahl said:

All trigger types?

"Chuz ur feit" amateur Hexen traps: now in Doom!

 

1 hour ago, Graf Zahl said:

How would you toggle it without scripting?

Action 1: dormant insta-kill linedef.

Action 2: active insta-kill linedef.

Action 3: find insta-kill actions on linedefs with the same tag, toggle them.

 

Clunky, I know. Especially if you want to duplicate actions for additional activation methods.

[Jon]

 

Last night, out of personal curiosity, I implemented the insta-gib floor in prboom. I used sector special 4096 (afaik the first free number after the boom and SMMU flag bits) and copied the implementation from chocolate-strife, but I extended it to impact monsters too. That was an eye-opener to me, most of those areas of the doom code I've not touched before. Anyway I could put the PROOF OF CONCEPT ONLY NOT A CONCRETE SUGGESTION FOR BEHAVIOUR NOR SECTOR SPECIAL NUMBER code and test WAD (generated using WadC, naturally) up somewhere.

 

I'd actually like to cook up a simple proof of concept for every (sensible) suggestion. Maybe improved type-242 next.

 

edit:

• https://github.com/jmtd/prboom-plus/tree/jmtd-instakill-sector
  • https://github.com/jmtd/prboom-plus/commit/c7c4b2e31eeeedad07c021ee6c170e60416e91b7 (prerequisite)
  • https://github.com/jmtd/prboom-plus/commit/e81c447b1006eb9db8ffb6896ab94a8c8eab2021 (implementation)
  • https://jmtd.net/tmp/4096.wad (test, skill 1 for imp, skill 3 for cacodemon)

 

On 7/17/2017 at 0:07 PM, Graf Zahl said:

All trigger types?

 

I'm torn between thinking there's no value in implementing all trigger types for every special we cook up, and leaving my mind open to be surprised by the innovation of mappers. But I lean towards the latter now (e.g. I thought "why would you want a G1 instadeath line? but now I can envisage some interesting use cases)

Edited July 18, 2017 by Jon : +links to prototype

[kb1]

3 hours ago, Jon said:

 

Last night, out of personal curiosity, I implemented the insta-gib floor in prboom. I used sector special 4096 (afaik the first free number after the boom and SMMU flag bits) and copied the implementation from chocolate-strife, but I extended it to impact monsters too. That was an eye-opener to me, most of those areas of the doom code I've not touched before. Anyway I could put the PROOF OF CONCEPT ONLY NOT A CONCRETE SUGGESTION FOR BEHAVIOUR NOR SECTOR SPECIAL NUMBER code and test WAD (generated using WadC, naturally) up somewhere.

 

I'd actually like to cook up a simple proof of concept for every (sensible) suggestion. Maybe improved type-242 next.

 

edit:

• https://github.com/jmtd/prboom-plus/tree/jmtd-instakill-sector
  • https://github.com/jmtd/prboom-plus/commit/c7c4b2e31eeeedad07c021ee6c170e60416e91b7 (prerequisite)
  • https://github.com/jmtd/prboom-plus/commit/e81c447b1006eb9db8ffb6896ab94a8c8eab2021 (implementation)
  • https://jmtd.net/tmp/4096.wad (test, skill 1 for imp, skill 3 for cacodemon)

 

 

I'm torn between thinking there's no value in implementing all trigger types for every special we cook up, and leaving my mind open to be surprised by the innovation of mappers. But I lean towards the latter now (e.g. I thought "why would you want a G1 instadeath line? but now I can envisage some interesting use cases)

Wow, I forgot you were a quite capable coder...excellent! This is immensely helpful! Part of my pre-spec process involves a built proof of concept. Therefore, any proof of concept you build makes one less proof of concept I have to build. This, of course, helps me out a lot. And, of course, if it's sensible, it'll most likely make it in. If I can, please let me state a few obvious guidelines:

 

1. Exact linedef/sector type numbers are subject to, and will change, so anything more than a silly test map will be broken later.

2. Small, efficient, well commented code stands a much better chance of being used, of course.

3. As much as possible, try to bunch all code in the same place, preferrably in a "drop-in" Boom module that was, most likely, dropped into source ports untouched. I am hoping that the new specs can all be contained, and therefore easily dropped in to the bulk of ports with minimal modification.

4. Use common sense, and avoid any special that requires "new systems" to be built.

5. One of Boom's claim-to-fame is that it did not discriminate between action types - Boom implemented them all. If you don't want add all of them, I can do it later. After all, you never know what crazy contraptions mappers will want to make.

 

Thanks again for this!

 

[esselfortium]

If it's possible to include multiple trigger types for new specials, it would make sense to do so.

 

With that said, at the least, including walkovers for everything means that a voodoo doll script should be able to approximate any more esoteric uses that were left out.

[Jon]

3 hours ago, kb1 said:

Wow, I forgot you were a quite capable coder...excellent!

 

Thanks, my ego loves to hear that :)

 

3 hours ago, kb1 said:

 

This is immensely helpful! Part of my pre-spec process involves a built proof of concept. Therefore, any proof of concept you build makes one less proof of concept I have to build. This, of course, helps me out a lot. And, of course, if it's sensible, it'll most likely make it in.

 

Great. I enjoy building prototypes, it helps me to think through the practical issues.

 

3 hours ago, kb1 said:

If I can, please let me state a few obvious guidelines:

 

I agree with all of these.

 

[kb1]

3 hours ago, Jon said:

 

Thanks, my ego loves to hear that :)

Heh, no problem. Compliments are few and far between in this business, huh? Anyway, here's more: What you linked looks

 

3 hours ago, Jon said:

Great. I enjoy building prototypes, it helps me to think through the practical issues.

Me too. Actually, thinking about it, they're all prototypes - can't remember when I actually finished a project...

 

3 hours ago, Jon said:

I agree with all of these.

Yeah, I figured we were on the same page there. I like the gen. sector mask. So, you forked from Graf's UMAPINFO version. This was his very latest and greatest, right? Seems like there was another slight change in there, if I recall. It had to do with changing SR-50 to be off by default. entryway changed it on May 18th, I think. I imagine that change isn't in Graf's fork, and therefore your fork. But, maybe I'm not giving GitHub enough credit for it's ability to merge code (always makes me a bit nervous).

 

The last thing I want to do, while working on compatibility, is to create an incompatibility, you know? :)

 

[Jon]

Yeah I worked from graf's fork, master branch, so it's a little behind e6y and it has graf's umapinfo stuff, but my patches don't touch those areas at all so I'm confident they'd lift out without a problem.

[Jon]

Maybe a trigger linedef that woke up any monsters in tagged sectors, useful for monster closets and the like.

[Jon]

Here's another: a new thing type (or family) point source light to go with a sector special, set light level based on proximity of point source lights, using an additive scheme.

[kb1]

11 hours ago, Jon said:

Maybe a trigger linedef that woke up any monsters in tagged sectors, useful for monster closets and the like.

I suppose you could emulate a sound propagating to the tagged sector.

 

9 hours ago, Jon said:

Here's another: a new thing type (or family) point source light to go with a sector special, set light level based on proximity of point source lights, using an additive scheme.

I'm having trouble getting my head around what you're describing - can you elaborate?

[BigDickBzzrak]

7 hours ago, kb1 said:

I suppose you could emulate a sound propagating to the tagged sector.

Hey, how about a linedef that plays a sound when activated? 

 

...I can dream, right?