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

[Szymanski]

4 hours ago, scifista42 said:

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.

If only people could create a new standard, some sort of complevel where the logic is agreed upon

[Scotty]

• Multiple action linedefs (e.g. a switch can open a door and lower a floor at the same time)
• 'tuneable' lighting specials, e.g. the glowing light effect could have completely custom minimum/maximum brightness and cycle duration, and not be dependent on neighbouring sectors either

[Arctangent]

28 minutes ago, Szymanski said:

If only people could create a new standard, some sort of complevel where the logic is agreed upon

That seems incredibly relevant for ports that support Boom but don't have the concept of complevels, yes.

[Graf Zahl]

And seeing how different the code of various ports is, it's a hopeless undertaking to ask all of them to implement such stuff. You can bet that there will always be someone to just roughly add it to the existing code base to avoid redundancy.

[Szymanski]

I dont know all the compatibility issues are between the implementations, more importantly does using a script improve the scenario if the physics/collision/movement code all differ. 

 

 

[Arctangent]

... Yes. Very much so, because changes in physics wouldn't be able to throw off a way of doing complex actions that doesn't rely on the physics.

[Gez]

It does in so far as execution of the script itself will not be dependent on physics/collision/movement, contrarily to a voodoo doll "script".

[Szymanski]

But I couldn't script a physics effect (floor current, wind etc) and expect it to work the same? so its restricted to actions such as monster/item spawns, timers, sectors changes etc

[Arctangent]

That's scripting tied to the gamesim, which is completely irrelevant since there's no way that would be included into a Boom+ deal as that's just waaaaaaay too complicated. The scripting we're discussion is restricted only to complex actions on the map, such as opening a door when a certain set of monsters are killed or lowering several floors sequentially.

 

The latter of which could already be done through voodoo doll scripting, though it's liable to be affected by changes in physics as it is reliant on fake players being forced to move across action-triggering lines ... which is why this entire train of thought started in the first place.

[scifista42]

34 minutes ago, Szymanski said:

But I couldn't script a physics effect (floor current, wind etc) and expect it to work the same? so its restricted to actions such as monster/item spawns, timers, sectors changes etc

You managed to confuse 2 things:

1) How the script affects the map.

2) How the game physics affect the execution of the script.

 

Conveyor belt based scripts aren't theoretically any different from text based scripts in how they can affect the map. But they are very different in how the game physics affect their execution. In case of text based scripts, the game physics don't affect their execution at all, because the script runs in an environment that is separate from the space in the map where game physics take effect. In case of conveyor belt based scripts, the game physics are actually driving their execution and therefore obviously affect it.

[Mordeth]

On 17-5-2017 at 10:13 PM, Arctangent said:

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.

 

Sure, for some stuff you'll need immediate followup. But for opening a door after a certain group of monsters die? Your door would open even before a player would register that he just killed the last monster. Checking every second or so instead of every tic is plenty. And your player, between different playtroughs, is not going to notice that this door is now opening half a second earlier or later than in his previous session, because he would still be looking at his last victim's corpse falling to the floor.

 

Reason for me to mention is that I see this quite a lot when inpecting scripts. For example a countdown, and you want to do something on every second? Then why loop with increments of 1 tic, or worse: calculating the same amount of remaining seconds every tic, for 35 straight consecutive tics, and then printing that same number 35 times per second to the HUD?  The performance hit killed that encounter for me.

 

But yes, offtopic. Rant over; carry on :)

[Szymanski]

8 minutes ago, scifista42 said:

You managed to confuse 2 things:

 

Not really, what I want is to know which effects (scripted or linedef implemented such as instant death) that will work identically in this new Boom mode regardless of port, and its becoming clear that there will be still be effects that will never be fully safe. 

[traversd]

I'm confused. Are we saying that conveyor scripts, something that I thought are synonymous with Boom is by and large not working in other ports?

 

If that is the case, fair enough.

[Arctangent]

1 hour ago, Szymanski said:

Not really, what I want is to know which effects (scripted or linedef implemented such as instant death) that will work identically in this new Boom mode regardless of port, and its becoming clear that there will be still be effects that will never be fully safe. 

Well, yeah. Boom support means that Boom maps will run in the source port, not that they will run identically to how they'd run in Boom.

 

There are not a lot of ports interested in playing Boom stuff the same way Chocolate Doom plays vanilla Doom - considering Boom is one of the major predecessors to modern feature ports, that really shouldn't be too much of a surprise.

 

1 hour ago, Mordeth said:

 

Sure, for some stuff you'll need immediate followup. But for opening a door after a certain group of monsters die? Your door would open even before a player would register that he just killed the last monster.

That's why you set a Delay() after the loop. That way, the actual amount of time before door opens isn't effectively random - it's a very deliberate amount of time between the last monster's death and the door opening.

 

 

1 hour ago, Mordeth said:

And your player, between different playtroughs, is not going to notice that this door is now opening half a second earlier or later than in his previous session, because he would still be looking at his last victim's corpse falling to the floor.

I can tell you that that's 100% wrong due to a. actually being the antithesis to that. I notice those timing inconsistencies unless they're so insignificant that there's really no human noticeable clues to tip me off and b. other than me, speedrunners in general are going to notice that sort of stuff, especially if it's possibly the difference between a tic and a second.

 

9 minutes ago, traversd said:

I'm confused. Are we saying that conveyor scripts, something that I thought are synonymous with Boom is by and large not working in other ports?

 

If that is the case, fair enough.

Not exactly. The difference in physics would cause mostly timing issues, though some show-stopping ones could come up if some genius decided to, say, block a voodoo doll with a hanging corpse that it would be circuited to avoid if something altered the conveyor. In that case, the voodoo doll could easily slip under the corpse in a port without infinite height actors if no care was taken to make sure the ceiling was actually low enough for the corpse to block the doll.

[Gez]

Conveyor machines work in any Boom-supporting port, however small differences in physics can result in small difference. A "script" might run faster or slower for example. Some complex designs might also fail outright; I remember a case where there was a sort of "branching" introduced by having an obstacle lower and block the voodoo doll, pushing it to a side passage with a different conveyor belt. Except in ZDoom instead of being pushed to the side, the doll just ended stuck in place (the issue was eventually resolved, though).

[Graf Zahl]

The main issue here is that Boom's carrying implementation is rather hackish, in some cases seriously depending on side effects of processing order.

Enter a port which tries to make this a bit more well defined and maps that unknowingly depend on such a side effect and do not get tested properly on all target ports may break. Case in point: UAC Ultra MAP07 had one conveyor script that did not work in ZDoom because one tiny one-tic push that Boom still applied in a situation where it shouldn't have was skipped, leading to a stuck voodoo doll.

 

 

[kb1]

9 hours ago, traversd said:

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.

No, Graf's right here. Voodoo dolls are great, because that's all that's available, but they're by no means perfect. Adding a new thing and calling it a "dedicated voodoo doll" does not make the issues go away. The fact that they exist means that we have to do our best to keep them working as expected. But they are things, ,which means that they act and behave like all other things in a particular source port. We're discussing a spec for new stuff that can be added easily to ports. Linedefs come to mind. But demanding that ports handle a new thing using new trigger logic, new physics, etc, is too invasive. For example, you can demand that any car you buy is driveable, but you cannot expect each car to handle turns the same way.

 

And, with all the work required, that time could be spent building real scripting. Now, we could discuss some linedef/sector additions that could enhance voodoo doll scripting a bit. Linedefs are fairly isolated bits of code that affect the engine in a simple, predictable way.

 

5 hours ago, Szymanski said:

If only people could create a new standard, some sort of complevel where the logic is agreed upon

Ports are supposed to handle Boom conveyor belts the same way. If not, the port may have a bug. But, again, when you start affecting thing physics, ports may tend to disagree, which is unfortunate, but beyond the scope of this spec. We can't fix everything, especially on the first pass.

 

30 minutes ago, Graf Zahl said:

The main issue here is that Boom's carrying implementation is rather hackish, in some cases seriously depending on side effects of processing order.

Enter a port which tries to make this a bit more well defined and maps that unknowingly depend on such a side effect and do not get tested properly on all target ports may break. Case in point: UAC Ultra MAP07 had one conveyor script that did not work in ZDoom because one tiny one-tic push that Boom still applied in a situation where it shouldn't have was skipped, leading to a stuck voodoo doll.

This is a perfect example. Ports are going to handle these off-by-one physics things a bit differently. Using this technology for scripting will always be a less-than-certain situation. Mappers need to test their setup in multiple ports to try to reduce this possibility, but there will always be a small risk.

 

I would like to see a comprehensive list of all of the possible uses for voodoo dolls. Maybe there is actually a simple way to provide a lot of what voodoo dolls offer, with a few generic linedefs/sector types, and/or static things. For example, the discussed insta-death linedefs, or Wesley's generic triggering linedefs, or maybe a trigger that occurs when a lift hits bottom. Those could replace some voodoo doll setups. I wish I knew more about what was possible. Can anyone describe some more things voodoo dolls can do, and maybe even provide some ideas on how to get the same functionality with lines/sectors/static things?

 

[traversd]

Ok. So defining a new thing sounds outside the range of acceptance for implementing. That is fine. Maybe instead making a new thing that has logic to activate all known linedef specials, we could perhaps look at making sure any new linedef special has an appropriate monster activated version?

 

Sorry my query to Graf wasn't about right/wrong. I get that all ports would be slightly different in implementation of Boom extensions, and have aspects of their own features that may cause conflict or quirks in the way things operate in-game. All good there, I was just wondering if my understanding of that the majority of "boom-compatible" ports can handle voodoo scripts in maps. Because yes, I would not expect ports where they don't work to make them work unless that is something they want to do.

 

PS. just to diffuse any feelings of being pushy - I am only putting stuff here as suggestions/proposals and would like to think all the commentary I have added has not implied any demand of sorts to port authors. The viewpoint I have in putting forward anything is keeping the barrier of implementation low enough that port authors might want to take it up. Not set out something and demand they do it. That is not fun and Doom is about fun.

 

 

[Rayziik]

2 hours ago, traversd said:

Ok. So defining a new thing sounds outside the range of acceptance for implementing. That is fine. Maybe instead making a new thing that has logic to activate all known linedef specials, we could perhaps look at making sure any new linedef special has an appropriate monster activated version?

MBF has a codepointer called "LineEffect", which does exactly what you think it does. In your earlier example of having groups of monsters and stuff be killed to cause something to happen in the map, if there were lots of extra things/frames added you could duplicate monsters and give them a unique starting death frame with a LineEffect of your choice. You could then tie all these LineEffect triggers into a voodoo doll setup in the map and then once all the duplicate monsters are dead the voodoo will trigger.

At least, that's how I would go about utilizing extra things/frames.

[Arctangent]

ZDoom actually has something similar, where Decorate actors can call Hexen-style line actions. Though this is more useful for calling ACS scripts ( which is done via line actions ) or doing something like an actor that always ends the level no matter what, as anything else is done far better through thing actions ( line actions that are tied to a specific thing on the map, called when the thing is killed or picked up ) or ACS scripts. Since, y'know, you don't have to define a hundred different versions of the same exact actor but with different Death states that way.

[Gez]

Hexen has thing specials, and so ZDoom does to. They're mightily convenient. For the purpose of compatibility with MBF dehacked, ZDoom also has A_LineEffect even though people are encouraged not to use it in DECORATE/ZScript code (hence the scary-looking deprecation notice).

 

Doom 64 also has a similar feature, though it's a bit more complicated to use. Doom 64 things have a TID, and they have two spawn flags (0x40 and 0x80) that make them activate the line with the same tag when they are picked up (0x40) or killed (0x80). Lines similarly have a flag for trigger by dead thing (0x1000), though trigger by picked up things doesn't seem to require a flag.

 

So for example, that's exactly how the Hectic secret works. All barrels on the level have TID 8, the secret exit teleporter is blocked by a door with tag 8, and the line that opens it has the "trigger by dead things" flag and tag 8. Once you kill the last thing with TID 8, the line with tag 8 opens the sector with tag 8.

[mouldy]

I havent read through the whole thread, so someone might have suggested these already, but here are a few ideas..

 

Timed actions: have it so you can set a time delay on any action, just to save a bit of voodoo doll faffing.

 

Auto-active monster flag: so that monsters are automatically awake without having to be woken by the player.

 

Linedef flag that blocks players but not monsters. Or alternatively that blocks everything except flying monsters, so cacos can fly over midtex railings.

 

More lighting options: ability to change brightness of tagged sectors by a specific amount, up or down.

 

Some way of joining sectors that have different texture/brightness/height, so that they all move by the same amount and if one stops they all stop. So lifts made of multiple sectors dont mess up when player hits the ceiling.

 

Monsters can activate floor/ceiling actions

 

"Scroll wall using sidedef offsets" means you can't align adjacent textures properly, so some way of doing that would be nice. Also, can there be a way to scroll midtextures vertically where they repeat in the same way that horizontal scrolling does?

 

Fix the crushers I guess.

 

[scifista42]

14 minutes ago, mouldy said:

Monsters can activate floor/ceiling actions

 

[mouldy]

19 minutes ago, scifista42 said:

 

Cool. Is there any reason doom builder doesn't just have an option for monsters to activate?

[kb1]

10 hours ago, mouldy said:

I havent read through the whole thread, so someone might have suggested these already, but here are a few ideas..

 

Timed actions: have it so you can set a time delay on any action, just to save a bit of voodoo doll faffing.

 

Auto-active monster flag: so that monsters are automatically awake without having to be woken by the player.

 

Linedef flag that blocks players but not monsters. Or alternatively that blocks everything except flying monsters, so cacos can fly over midtex railings.

 

More lighting options: ability to change brightness of tagged sectors by a specific amount, up or down.

 

Some way of joining sectors that have different texture/brightness/height, so that they all move by the same amount and if one stops they all stop. So lifts made of multiple sectors dont mess up when player hits the ceiling.

 

Monsters can activate floor/ceiling actions

 

"Scroll wall using sidedef offsets" means you can't align adjacent textures properly, so some way of doing that would be nice. Also, can there be a way to scroll midtextures vertically where they repeat in the same way that horizontal scrolling does?

 

Fix the crushers I guess.

 

Yes, a few of these are on the list already (which is cool). Regarding the timed actions, I was thinking a lift that triggers another linedef when it hits bottom would make a nice delayed action.

 

Linedef flags are somewhat controversial, simply because they are used differently by different ports, and they are a rare resource. Most port devs have created multiple sets of these flags (each of which holds 32 boolean values), so, it may not be a huge issue.

 

@traversd It's all good. If you don't mind some of the ideas being rejected for being too tricky to implement, I don't mind you pushing more ideas. Keep 'em coming!

 

[traversd]

On 19/05/2017 at 2:47 PM, Rayziik said:

MBF has a codepointer called "LineEffect", which does exactly what you think it does. In your earlier example of having groups of monsters and stuff be killed to cause something to happen in the map, if there were lots of extra things/frames added you could duplicate monsters and give them a unique starting death frame with a LineEffect of your choice. You could then tie all these LineEffect triggers into a voodoo doll setup in the map and then once all the duplicate monsters are dead the voodoo will trigger.

At least, that's how I would go about utilizing extra things/frames.

Nice. There is even a "face" and a "turn" code pointer. In terms of the "on death" setups, outside of scripting provided in an advanced port it seems the options are all still limited to modifying data outside of the map - and I'm thinking in terms of feature advancements that can be managed when editing the map, hence the linedef proposal.

 

I looked up the "LineEffect" code in the prboom source. It seems to copy/create a new player object and then use that to call the special line routines (P_CrossSpecialLine/P_UseSpecialLine). I'm sure there is some major drawback to calling it often - but if it also took Line as an arg that defaulted as zero/null(?) for the DEH code pointer calls, calling it at the start of P_CrossSpecialLine/P_UseSpecialLine for just that hardcoded script thing and then skipping the rest of the function might allow it to activate all walkover/switch specials?

[kb1]

On 5/21/2017 at 6:30 AM, traversd said:

...

I looked up the "LineEffect" code in the prboom source. It seems to copy/create a new player object and then use that to call the special line routines (P_CrossSpecialLine/P_UseSpecialLine). I'm sure there is some major drawback to calling it often - but if it also took Line as an arg that defaulted as zero/null(?) for the DEH code pointer calls, calling it at the start of P_CrossSpecialLine/P_UseSpecialLine for just that hardcoded script thing and then skipping the rest of the function might allow it to activate all walkover/switch specials?

This is for custom monster deaths? It sounds like what you want is a set a generic, RandomJump codepointers. For example, you could have a RandomJump4 codepointer that randomly changed the current frame to frame+1, frame+2, frame+3, or frame+4. In those frames, you could show the first custom death state, and then jump to any other frame to complete the death sequence.

 

This is a much cleaner approach, and it's easy to program. That's what I'm looking for: Generic, simple codepointers that have a wide range of uses, and allow you do things that are simple, yet nearly impossible to do within the Boom format.

 

There could even be only a RandomJump2, where Misc1 and Misc2 define which frames to go to (does this already exist in MBF? It sounds familiar). This codepointer could point to another frame that also has a RandomJump2 code pointer, to allow for 4 possibilities, 8, etc, all using just 1 codepointer.

 

Try to think: Wide-usage, simple, and generic (works on any thing).

By the way, there's no problem with using LineEffect often in 99% of cases - it's plenty fast).

[Da Werecat]

The existing RandomJump in MBF uses one field for the alternative state to jump to, and another for the probability of the jump.

[traversd]

I seem to really struggle with articulating things sorry!

 

I'm suggesting that the code in "lineeffect" be modified or duplicated to allow passing the linedef and then that new/modified code is called from within P_CrossSpecialLine (and maybe P_UseSpecialLine) when the thing type triggering the special is the proposed "Voodoo script" thing.

 

That would address voodoo scripts that can activate all normal player walkover specials without needing duplicate player starts.

[kb1]

23 hours ago, Da Werecat said:

The existing RandomJump in MBF uses one field for the alternative state to jump to, and another for the probability of the jump.

Ah, well, that's enough power to be able to get the job done, maybe with a bit of stress!

23 hours ago, traversd said:

I seem to really struggle with articulating things sorry!

 

I'm suggesting that the code in "lineeffect" be modified or duplicated to allow passing the linedef and then that new/modified code is called from within P_CrossSpecialLine (and maybe P_UseSpecialLine) when the thing type triggering the special is the proposed "Voodoo script" thing.

 

That would address voodoo scripts that can activate all normal player walkover specials without needing duplicate player starts.

I guess I still don't get it, so let me try a different approach by asking these questions:

1. What is the exact result you are trying to achieve? Or, what is the thing you are trying to accomplish that cannot currently be accomplished with the existing combination of lines/actions/things?
2. Please avoid the technical methods you would employ to make it work, and instead explain what you are trying to make happen in the first place! :)
3. Are you stating that voodoo dolls cannot trigger all of the walkover lines that player can? If that's true, I wasn't aware of it.