Actions System FR: Desired trigger conditions

[Kestrellius]

The following is an off-the-top-of-my-head list of circumstances under which it might be useful to be able to trigger actions.

Ships table:

• Activation/deactivation of afterburners.
• Afterburners currently active.
• On shield quadrant depletion.
• On death. (I've looked at the death explosion mechanics enough to see that they look very limited, and I'm hoping the action system might be able to replace the retail system.)
• On 'vaporize' death.
• On non-vaporize death.

Weapons table:

• On weapon firing. (This would provide some of the functionality requested here.)
• On beam/projectile impact.
• On projectile detonation.
• On beam warmup.
• On beam firing.
• While in flight, while in homed flight, while in unhomed flight, while in freeflight, on ignition.

[asarium]

A big part of the actions system is to which object and submodel a program instance is attached. Could you also specify what your expectations would be here?

For example, for the afterburner case, I would guess that the instance should be attached to the ship object (obviously) but to which submodel? Should there be only one instance running or several for each thruster bank?

For the weapons it is getting more involved. Since programs are always attached to objects at the moment things like "on weapon detonate" are not really possible.

For your "while" cases what exactly do you mean? Should a program be triggered for every frame or only when a state transition takes place?

[EatThePath]

for my own part, I would think the 'while' would be a case where you'd specify a rate in the program and the programmed action would happen every so often while in that state. Both "on" transitions and "while" constants should be useful for different ends.

[Baezon]

The particle system can already deal with continuous generation, as long as its attached to the object there shouldn't be any need to 'retrigger' after some time or anything like that.

The 'on weapon state' should trigger only once on transition, if the associated particles duration is "one time" then it happens once but if it is "always" then the particles continue at the rate you specified until the state changes.

[asarium]

This has nothing to do with the particle effects since the two are completely separate.

The question is how many times a program of the actions system should be triggered for conditions while they are active. I like the idea of requiring a specification of the interval between triggers since that gives the most flexibility to users of the system and is relatively easy to implement.

[Baezon]

This system explicitly calls the existing particle effect system though? I'm just not sure what sort of timing information could be provided that isn't already covered by the existing system of particle effects (aside from wait, which wasn't possible in the existing system).

[asarium]

I still don't know what the particle system has to do with this. A particle effect is created if the +Start Particle Effect: action is called and nothing more.

[Baezon]

I guess I assumed this system was primarily designed to trigger particle effects in particular from your example. Looking at the specification again, I see now that it also does sounds at least, which makes a more general purpose timing system make more sense I suppose. What other sorts of actions are you looking at?

[asarium]

The code for the system is already in this repo in a branch so you can take a look at the available actions here: https://github.com/scp-fs2open/fs2open.github.com/tree/test/actionSystem/code/actions/types

[Kestrellius]

Re: 'while' cases: ETP's description is exactly what I was thinking of.

Re: which submodels: For the afterburner case, I would usually want to perform the action at each of the thruster points, though in some situations I might want to trigger a certain effect only at at certain thruster points. (If a ship has primary and secondary thrusters, for example.)

Looking at the example case, it doesn't appear that this should be a problem since it looks like submodel and trigger can be defined independently. You define the submodel where the action will happen, and then you say when it should happen. So for afterburners, I would put together the desired action attached to one thruster point, set to trigger on afterburner activation or whatever, and then I'd make copies of it for each of the other thruster points. Right?

For something like the shield depletion case...it's a little more complicated. I don't know if shield quadrants exist as submodels per se. Still, I don't think it would be a real problem -- I could just set up an action to occur on depletion of the starboard shield quadrant, attach it to a random submodel, and then use position offset to put the particle effect where it needs to go.

Re: weapons and detonations: Is it a problem that a laser has no submodels? I was thinking that if you were defining an action attached to a laser, it would essentially have one submodel, that being the center point of the projectile.

For detonations, I think I understand the issue. The action has to be attached to an object, and after the projectile has detonated there's no object. Still, one of the biggest things I was hoping to do with this system is create complex weapon detonation/impact effects.

I can think of at least one slightly hacky way to handle this, assuming it's possible. Could the action be attached to a particle? Then you have the detonation spawn an invisible dummy particle to mark the location, and the action runs attached to that.

Re: relationship between actions and particle effects: The action system has functionality which doesn't exist in the particle system (the ability to do things like play sounds and possibly create lights if that's added, but most prominently the arbitrary location and direction control). As such, I'd very much like to be able to trigger actions under any circumstances where particle effects can be spawned, so that I can take advantage of these extra features instead of being limited to just what the particle system can do.

A further thought: would it be possible for an action to be triggered by interactions between different objects? For example, if I was going to use this for muzzle flashes, I would want to be triggering effects at the location of firing points -- but only when the specific weapon the flash was designed for was fired. Can something like this be done? Maybe a trigger condition of "on firing of [weapon name]"?

Similarly, I might want to be able to cause an action to happen only when a specific ship is hit by a specific weapon -- for example, an electricity effect tailored to the shape of the craft's hull, played when it's struck by a particular disruptor weapon. Possible?

Thanks for the consideration, in any case. This is a fantastic system with enormous potential.