What small improvements from BOOM/MBF could be made in a new standard?

47 minutes ago, kb1 said:

For #1, yes the UMAPINFO could be used to say "act like MAP07", where tag 666/667 is triggered when all spiders and fatsos are killed, or "act like E1M8" when barons are killed, etc. Those are built in, hard-coded functions of Doom/Doom II, and there's no reason a different map could not use the same trigger. But the conditions, and the results are the same as in the original game.

I understand (and support) this as a UMAPINFO feature - to define the outcome/trigger of pre-existing functions. Just feels like an in-game dynamic lock table would afford a simple mechanism to provide more specific and repeatable "on death" events.

@Arctangent I am putting forward these suggestions as a full scripting implementation is not in the scope of this AFAIK. This is about adding some extras to the existing boom editing extensions that hopefully keeps the effort of implementation low enough that port authors may take it up. A lock table feature is (I naively think) not too complex providing it is isolated to a few specific linedef specials so the checks are now needed across the existing code base. They can then be used in conjunction with the existing boom-level linedef specials for conveyor scripts that already work in all boom-compatible ports.

But yep, it can be a fine line between what is a small, but super helpful, addition versus putting too much ask on port authors to standardise a whole new editing feature standard.

4 hours ago, Arctangent said:

while( ThingCount( T_NONE, 10 ) ) Delay( 1 );

Offtopic, but why do people insist on doing these kind of checks after every tic? Like, 35 times a second? In most circumstances it would be sufficient (plus have better performance) to check eg. every second instead.

5 hours ago, traversd said:

 

Does the intended UMAPINFO spec allow the below setups?

 

1. Locking a door special until the following monsters (specific ones, not just the last in a map) are all killed?

 

2 x arachnotrons

4 x barons

2 x cybers

 

What the current UMAPINFO allows is to assign a line special to any given monster type. That action can be anything. The only important thing is that the monster's death state is calling BossDeath. The 3 in your list do, but with Dehacked you can also use the zombies, imps and other smaller monsters.

9 minutes ago, Graf Zahl said:

What the current UMAPINFO allows is to assign a line special to any given monster type. That action can be anything. The only important thing is that the monster's death state is calling BossDeath. The 3 in your list do, but with Dehacked you can also use the zombies, imps and other smaller monsters.

 

Sorry,  I gave a poor example by using monsters that already have boss death triggers. Zombie/imps are better examples. The idea behind a lock list avoids needing to reference the boss death code pointer altogether. Plus if it stores any thing ID then you could use barrels, or pickups or a player and in coop or DM a script could trigger when a player dies. A DM arena where ammo appears/door opens when your opponent is killed for example.

6 hours ago, traversd said:

(specific ones, not just the last in a map)

How would you mark these specific monsters? If you have, like, ten barons, and you want the death of two of them to open a door, but the remaining eight barons are irrelevant, you need to mark these two specific barons.

Which basically means that you need to use a map format with thing IDs. So, you need to adopt one of the following map formats: Hexen, UDMF, or Doom 64 EX.

Alternatively, you need to add copies of all monsters, so you'll have "boss barons" and "non-boss barons", so in our example you'd use two boss barons and eight non-boss barons in the map. That's easier to imagine, but still...

Doesn't the engine itself track each thing by an ID? Same as used for attack targetting etc, but in this case add it to an internal data table with a sector/linedef tag number as well. That is what I mean by Thing ID - an internal engine reference to a specific thing instance at run-time; Not a map format level reference to a specific thing instance at the map authoring stage.

• The data gets loaded using a WR linedef special (and thing that crosses it gets added with the tag of the linedef).
• The data is removed in the death and pickup routines for monsters/items
• The data is checked/reference whenever one of the 4 suggested linedef specials is triggered
  • If the tag is not found in the list, the linedef special can proceed
  • If the tag is found, the linedef special does not proceed and displays a lock message to the player similar to the FAST doors linedef specials. "Object cannot be activated at this time" etc.

Would there be anything inherently wrong with making Exit functions use the sector tag to determine which map to warp to? This could allow setting up multiple exits to more than the next map and secret map.

- monsters shouldn't fall off ledges unless it is desired by the map author

- if i hold the shoot button, run out of ammo but manage to pick up more in time, the weapon should stay

- SR lift raise wait lower

12 hours ago, Mordeth said:

 

Offtopic, but why do people insist on doing these kind of checks after every tic? Like, 35 times a second? In most circumstances it would be sufficient (plus have better performance) to check eg. every second instead.

Consistency, mostly. A single tic delay means that the following code would occur immediately after the last monster dies. Delay( 35 ), on the other hand, could take anywhere between a single tic to a whole second before the following code is ran, which is a lot more noticeable than you might think.

Of course, waiting 2 or even 5 tics between checks isn't really noticeable in the same way, and it's ultimately irrelevant if the scripted action won't cause something that the player can see or if you want a random amount of time to pass anyway. Main reason I stick to 1 is that I'm mostly used to doing ACS stuff that should run every tic, such as stuff dependent on player input.

14 hours ago, traversd said:

Doesn't the engine itself track each thing by an ID? Same as used for attack targetting etc, but in this case add it to an internal data table with a sector/linedef tag number as well. That is what I mean by Thing ID - an internal engine reference to a specific thing instance at run-time; Not a map format level reference to a specific thing instance at the map authoring stage.

What are you trying to accomplish with this setup? What *is* the setup, and what are the linedefs supposed to do? Maybe a couple descriptions of examples might help...?

14 hours ago, rf` said:

Would there be anything inherently wrong with making Exit functions use the sector tag to determine which map to warp to? This could allow setting up multiple exits to more than the next map and secret map.

That is basically the same idea as having an exit linedef type where the tag field defines a specific map to exit to.

2 hours ago, kb1 said:

What are you trying to accomplish with this setup? What *is* the setup, and what are the linedefs supposed to do? Maybe a couple descriptions of examples might help...?

This is what I put in my earlier post on page 2 with some alterations as it seems to be percieved as something to be configured/populated when editing the map - which is not the exactly the case; though the map author would have control over what things can populate the table and when as they would normally prevent a thing from crossing a particular linedef:

“Boss Death” Thing lock table

A new internal (run-time, not map format) data table that stores a ThingID Thing pointer? (column1) and a sector/linedef tag (column2) for the purpose of creating “upon death” or “upon pickup” actions for 1 or more specific ThingIDs Thing pointers in a map (without needing .EXE BossDeath alterations, additional things or pre-defined thing lists in the map format). The table is populated by ThingIDs Thing pointers of any Thing that crosses a new WR linedef special coded to do nothing but add Thing pointers and the tag the linedef has to the internal lock table.

This function would allow:

• In-map defined “on death” actions triggered upon the death of a single or group of monsters (and they need not be the same type, nor the requirement to be the last instance of that type in a map)
• In-map defined “on pickup” actions triggered upon the pick up of a single or group of items (and they need not be the same type)
• Using this multiple times a map author could implement “waves” with actions triggering after completion of each wave.
• "On death" actions triggered in multiplayer when a (specific) player dies (see example 1 below)
• Combinations of locks based on items+monsters and a Thing pointer could be in the table multiple times referencing different tags (see example 2 below)

Proposed implementation:

• 1 x WR - Add to thing lock table. Adds the Thing pointer of the thing that just crossed the linedef, and linedef tag as a new row to the lock table providing the same combination of the Thing pointer and tag do not already exist as a row in the table
• Inside on death/pickup routines - When a monster is killed or item picked up, any rows in the lock table containing the Thing pointer are removed from the lock table
• New linedef specials (x4)(x6)
  • D1 - Door open fast *if* tag is not present in lock table (column2). If present in table display "This object cannot be activated yet" to activator
  • S1 - Door open fast *if* tag is not present in lock table (column2). If present in table display "This object cannot be activated yet" to activator
  • W1 - Door open fast *if* tag is not present in lock table (column2). If present in table display "This object cannot be activated yet" to activator
  • DR - Door open, wait, close fast *if* tag is not present in lock table (column2). If present in table display "This object cannot be activated yet" to activator
  • SR - Door open, wait, close fast *if* tag is not present in lock table (column2). If present in table display "This object cannot be activated yet" to activator
  • WR - Door open, wait, close fast *if* tag is not present in lock table (column2). If present in table display "This object cannot be activated yet" to activator

Examples:

1. A coop game where at the start of the map each player crosses their own copy of the WR linedef special adding them and a unique tag to the lock table. Each time they die in the coop game a generic floor lower (by 32units) occurs effectively making a counter of number of deaths. This cycle can repeat continiously through the game and the map author can make an action occur after N deaths of any or all players - example might be providing more ammo/health, a shortcut or whatever they want as already available in the Boom editing extensions.
2. A map author configures the keys in their map to cross 2 x WR add to lock table linedefs such that they can make different actions occur depending on the order of key collection - ie: red & yellow key go into lock table with tag 1 (the defined action might make getting the blue key harder), red & blue key go into the lack table with tag 2 (the define action might make getting the yellow key harder) etc..

17 hours ago, traversd said:

Doesn't the engine itself track each thing by an ID?

No, this is a ZDoom-ism.  Generally you only need it for ACS, although it's useful for C/S netcode too.

Boom/MBF/etc. keep all the things in a linked list and just traverse it a lot.  They also keep track of references to other things like a monster's target, etc.

Looking things up by ID isn't the fastest thing (for computer-science-y reasons) so most engines, especially older ones, have other ways of dealing with all the things.

1 hour ago, Ladna said:

No, this is a ZDoom-ism.  Generally you only need it for ACS, although it's useful for C/S netcode too.

Those are TIDs. What traversd is trying to get at, I imagine, is some internal id that an actor has even if it doesn't have an assigned TID ... which I don't think ZDoom has, either.

I think he got the idea from map editors, though I'm pretty sure that number is just the actor's position on the thing table, so I'm not surprised it doesn't actually exist in-game.

Ah okies. So a table of the thing index # or pointer would be too difficult/out of the question?

The reference to "thing id" is purely from thinking the engine must know about each individual thing somehow for targeting, chasing etc. 

I have not mapped for ZDoom but since this setup is already achievable in some way figured the ZDoom family of ports could replicate it easily enough.

On 15/05/2017 at 1:05 PM, traversd said:

 

 

“Voodoo Doll” replacement v1 (stationary thing) - prompted by @esselfortium in the source ports thread

A new thing type that can activate all D(oor)/W(alkover)/S(witch)/G(unshot) linedef specials. It cannot be killed and can teleport using any/all teleport specials (ie: is considered both a player and a monster). Visually in an editor we could use a gold coloured player sprite so it still emphasises linedef activation but stands apart from normal player starts. A thing like this would better allow skill settings and MP specific actions by accessing the standard thing flags that player starts do not utilise.

 

It occurred to me that a dedicated Voodoo Doll, would be especially useful if it was effected by difficulty settings. In Quake some of the maps have different geometry depending on the difficulty, making some jumps easier to transverse, and some areas blocked off entirely. I recall trying to implement that once in a Boom map, but the voodoo doll seemed to exist regardless of it's difficulty flag.

A dedicated voodoo doll thing would get filtered like every other things. Players are the only exception.

Theoretically, you can block a voodoo doll with a thing obstacle if you don't want a certain "script" to be executed on a certain skill level. I'm saying "theoretically" because I haven't tried that yet, but I fail to see what can go wrong with such a setup.

3 minutes ago, Gez said:

A dedicated voodoo doll thing would get filtered like every other things. Players are the only exception.

Nvm then.

5 hours ago, traversd said:

Ah okies. So a table of the thing index # or pointer would be too difficult/out of the question?

It should be doable just fine. The new definition lump/table would need to reference things in the map by their indexes in the THINGS lump, then these indexes would be converted to thing pointers at the same time as the referenced things will be spawned at map startup (where they lose information about their indexes but gain permanent thing pointers in return), so the references will still unambiguously refer to the things they were supposed to.

21 minutes ago, Urthar said:

 

It occurred to me that a dedicated Voodoo Doll, would be especially useful if it was effected by difficulty settings. In Quake some of the maps have different geometry depending on the difficulty, making some jumps easier to transverse, and some areas blocked off entirely. I recall trying to implement that once in a Boom map, but the voodoo doll seemed to exist regardless of it's difficulty flag.

This is possible using a decoration thing and Boom generic linedef specials. It even allows script to occur only in either DM or Coop. The current limitation is that using a decoration is limited to the generic types (walk over options) and a few monster enabled walk over linedef specials.

Blocking a voodoo doll with a hanging body also works AFAIK.

10 minutes ago, traversd said:

This is possible using a decoration thing and Boom generic linedef specials. It even allows script to occur only in either DM or Coop. The current limitation is that using a decoration is limited to the generic types (walk over options) and a few monster enabled walk over linedef specials.

Worse yet, generalized types in categories "floor" and "ceiling" don't have the "monsters yes/no" option, so that they can't possibly be activated by non-player/non-voodoo-doll things, which forces mappers to use voodoo-dolls anyway if they want to make scripts involving floor/ceiling movement other than door/lift.

All generic types can be used by decorations. The only ones that can't are the locked doors? and crushers (but no one can use those). The limitation of the floor/ceiling generic types is you cannot use property transfer or numeric model.

If at basic level a Boom++ had a generic type for lighting, property transfers and some exit specials that monsters(and decorations) could activate that'd be sweet. The "thing lock" would be icing on the cake :)

16 minutes ago, traversd said:

All generic types can be used by decorations. The only ones that can't are the crushers (heh but no one can use those). The limitation of the floor/ceiling generic types is you cannot use property transfer or numeric model.

But...

1 hour ago, scifista42 said:

It should be doable just fine. The new definition lump/table would need to reference things in the map by their indexes in the THINGS lump, then these indexes would be converted to thing pointers at the same time as the referenced things will be spawned at map startup (where they lose information about their indexes but gain permanent thing pointers in return), so the references will still unambiguously refer to the things they were supposed to.

Thanks, hopefully the first part can be avoided as I'm not proposing a new lump or any pre-gameplay data like what has been discussed further back re:ZDoom's ACS+TID implementation. Just the use of the linedef special and a temporary data table of the thing pointers that trigger the linedef special. This kind of implementation would avoid needing any changes to editors beyond defining the new linedef special number.

What concerns me here is that some people have no concept of what 'simple' constitutes.

The discussion about voodoo dolls is the most ridiculous actually and just the worst approach imaginable. All this will necessitate a lot of work on the engine side just to avoid having some simple scripting. To be honest, it would probably be simpler to fix and strip down the FraggleScript code to a manageable subset (e.g. remove string variable support and some of the more advanced features primarily made for cutscenes) and use that in place of voodoo conveyors. While I can understand that some people would prefer voodoo conveyors, making sure that they behave 100% identical on the various engines out there is a major undertaking and as an official feature they are not really attractive and will certainly see some resistance by the engine developers.

In the boom specs, if model is 1 (numeric) and change is 0 (no change) that doubles and "monsters can activate"

Holy shit, it works! Why don't today's map editors make this clear?

5 minutes ago, Graf Zahl said:

What concerns me here is that some people have no concept of what 'simple' constitutes.

 

The discussion about voodoo dolls is the most ridiculous actually and just the worst approach imaginable. All this will necessitate a lot of work on the engine side just to avoid having some simple scripting. To be honest, it would probably be simpler to fix and strip down the FraggleScript code to a manageable subset (e.g. remove string variable support and some of the more advanced features primarily made for cutscenes) and use that in place of voodoo conveyors. While I can understand that some people would prefer voodoo conveyors, making sure that they behave 100% identical on the various engines out there is a major undertaking and as an official feature they are not really attractive and will certainly see some resistance by the engine developers.

 

Wouldn't the ports considered "boom-compatible" have covered voodoo conveyors already and not need major undertaking? If a port is not "boom-compat" and wants to be, then it needs to implement conveyors and voodoo dolls anyway before considering the additional linedef specials being discussed correct? Asking all the existing boom-compat ports to include a new scripting language feels a bigger ask of them.

3 minutes ago, scifista42 said:

Holy shit, it works! Why don't today's map editors make this clear?

Ito be fair, it isn't super obvious in the specs they way it has been described/detailed.

Unfortunately, different Boom-compatible ports already handle conveyor belts differently, in regards to how does the effect of multiple control linedefs affecting the same sectors add up, or how does the effect of multiple conveyor belts touching the same thing add up.

And then there's the fact that physics may have been altered for the sake of, say, allowing 3D actor-on-actor collisions, which could throw off voodoo doll conveyors.

A proper scripting language would just end up doing so much in the long run, anyway, especially in avoiding overcomplicated solutions to issues that one could easily solve.