Author Topic: Actions system test builds  (Read 1135 times)

0 Members and 1 Guest are viewing this topic.

Offline m!m

  • 211
Actions system test builds
My original idea for the content of this post was a drawing of one of the Blue Planet ships which showed it venting some kind of steam after firing a beam. Unfortunately, I cannot find that image anymore...
I guess the in-universe reason for that was venting of some cooling agent but I just thought it looked quite nice.

So, my obvious next question was, how do I make that possible in-engine for FSO?

The result was this:

I know it uses retail assets and it also doesn't look like steam but I am a coder, not an artist :p

In that video I set up the two effects with what I call the "Action System". That is a fancy name for a system which allows a modder to specify simple sequences of "actions" that are executed in-sequence by the engine to produce whatever effect a modder wants. I wanted this system to be as flexible as possible to allow maximum freedom for whatever things this might be useful for.

As an example, the effect in the video above was produced by this table:
Code: (actions-shp.tbm) [Select]

#Ship Classes

$Name:                          GTC Fenris
+nocreate
$Subsystem:                     turret02, 3, 5.0
$Default PBanks: ( "SGreen" )
; This demonstrates how this feature could be used for simulating an effect where a cooling system kicks in after a beam has been fired
; The visual appearance is not perfect since retail does not have a "vapor" effect built-in
$On Beam Warmdown: ; This defines a "program" to run once a beam weapon has finished firing
; Timing for effects is important so this allows to delay the execution of the remaining actions by 5 (in-mission) seconds
+Wait: 5

; Some actions simply update some internal data which can be used by later actions
; This data will be kept until it is set again and can be used by an unlimited number of actions
+Set Position: (8 0 0)
+Set Direction: (1 -1 1)

; All positions and directions are local to the attached subobject (turret02 in this case) and will respect animations

; These actions actually cause some external "thing" by using the previously set "local" data
+Start Particle Effect: Beam Warmdown Effect
+Play 3D Sound: 18

+Wait: 3

; Programs are attached to the object that triggered them so if the object dies before this can run then the sound will not be played
; The position is still (8, 0, 0) from the previous setting so no need to set it here again
+Play 3D Sound: 19 ; Actions can be used multiple times with different parameters
; Multiple independent programs on the same condition are also possible if necessary
; Both these programs will be triggered at the same time and run "concurrently"
$On Beam Warmdown:
+Wait: 5

+Set Position: (-8 0 0) ; Relative position to beam turret subobject
+Set Direction: (-1 -1 1) ; Direction for the particle effect
+Start Particle Effect: Beam Warmdown Effect
+Play 3D Sound: 18

+Wait: 3
+Set Position: (-8 0 0) ; Relative position to beam turret subobject
+Play 3D Sound: 19


#End

(I also attached a small mod with the relevant particle table and a test mission)

This contains all the actions that are currently supported. In case you are still reading and want to test this out for yourself, here are some test builds which support this feature:

Test Builds:
Windows 64-bit

Windows 32-bit

Linux

The code is in a state I would call "ready" but if you want to give some feedback now on the usability, I would be glad to hear it.

[attachment deleted by admin]

 

Offline EatThePath

  • 27
  • Laser Lich
Re: Actions system test builds
The first thought I have is that this is very cool, thanks for this!

My second thought is that for effects of this sort it is very very useful to be able to 'attach' the effects to different joints/subobjects. For instance if I have a modeled multi-apart beam turret, I might want a shower of sparks from the arm object, an immediate spray of steam or other particles from some part of the turret body, and/or another, less intense spray from some vent on the body of the ship itself.

EDIT: Further thinking about the events system in Homeworld 2 and Remastered, which accomplishes similar things in similar ways, if you're able to attach effects to arbitrary objects/points on the ship, it'd be useful to be able to add special named effect anchor points(with orientations) to pofs to be referenced here, and it'd further be useful to be able to specify a list of said points to pick randomly between when playing an effect.
« Last Edit: December 28, 2020, 04:07:33 pm by EatThePath »
"if disco is dead then I am the laser lich"
"...[Warmachine] keeps changing as fast as EatThePath can force the engine to do his dark bidding..."

 

Offline m!m

  • 211
Re: Actions system test builds
Interesting use case. Subobject attachment is already a thing in the system (the positions in the table above are relative to the beam turret).

How would you expect attaching to different sub-objects to work?

I could very simply implement actions that basically say "set the current subobject to the parent subobject", or "set the current subobject to child subobject <name>".

Would that already be sufficient?

 

Offline m!m

  • 211
Re: Actions system test builds
Ah, saw the anchor point edit too late.

That will probably require some changes to the model reading code but we could probably reuse the glowpoint functionality for that. We would only need to have a name for a glow point bank and an option to turn off rendering to make them invisible.

Once that is done, the actions system would only need to go to the right glow bank, pick a point and that is it.

 

Offline wookieejedi

  • 29
  • Intensify Forward Firepower
Re: Actions system test builds
This looks fantastic!

 
Re: Actions system test builds
Amazing work you did there! :yes:

 

Offline m!m

  • 211
Re: Actions system test builds
I implemented some requested based on the feedback in this post and on Discord.

I added the "+Move Subobject" action which will set the current subobject of the program to the one with the specified name. If the special value "<parent>" is specified then it will move to the parent subobject instead.

I also added random range support for the wait duration. Supporting that for the positions is not that easy though since it would require more involved changes to the way parsing vectors works.

Here is an example which demonstrates the new features:
Code: (actions-shp.tbm) [Select]
#Ship Classes

$Name:                          GTC Fenris
+nocreate
$Subsystem:                     turret02, 3, 5.0
$Default PBanks: ( "SGreen" )
; This demonstrates how this feature could be used for simulating an effect where a cooling system kicks in after a beam has been fired
; The visual appearance is not perfect since retail does not have a "vapor" effect built-in
$On Beam Warmdown: ; This defines a "program" to run once a beam weapon has finished firing
; Timing for effects is important so this allows to delay the execution of the remaining actions by 5 (in-mission) seconds
+Wait: (3 6)

; Some actions simply update some internal data which can be used by later actions
; This data will be kept until it is set again and can be used by an unlimited number of actions
+Set Position: (8 0 0)
+Set Direction: (1 -1 1)

; All positions and directions are local to the attached subobject (turret02 in this case) and will respect animations

; These actions actually cause some external "thing" by using the previously set "local" data
+Start Particle Effect: Beam Warmdown Effect
+Play 3D Sound: 18

+Wait: 3

; Programs are attached to the object that triggered them so if the object dies before this can run then the sound will not be played
; The position is still (8, 0, 0) from the previous setting so no need to set it here again
+Play 3D Sound: 19 ; Actions can be used multiple times with different parameters
; Multiple independent programs on the same condition are also possible if necessary
; Both these programs will be triggered at the same time and run "concurrently"
$On Beam Warmdown:
+Wait: (3 6)

+Set Position: (-8 0 0) ; Relative position to beam turret subobject
+Set Direction: (-1 -1 1) ; Direction for the particle effect
+Start Particle Effect: Beam Warmdown Effect
+Play 3D Sound: 18

+Wait: 3
+Set Position: (-8 0 0) ; Relative position to beam turret subobject
+Play 3D Sound: 19
$On Beam Warmdown:
+Wait: (3 6)

+Move Subobject: turret03

+Set Position: (0 0 0) ; Relative position to beam turret subobject
+Set Direction: (1 1 0) ; Direction for the particle effect
+Start Particle Effect: Beam Warmdown Effect
$On Beam Warmdown:
+Wait: (3 6)

+Move Subobject: <parent>

+Set Position: (60 0 0) ; Relative position to beam turret subobject
+Set Direction: (1 1 0) ; Direction for the particle effect
+Start Particle Effect: Beam Warmdown Effect


#End

The links from the first builds are still valid but here they are again just in case:

Test Builds:
Windows 64-bit

Windows 32-bit

Linux

 

Offline Trivial Psychic

  • 212
  • Snoop Junkie
Re: Actions system test builds
I could see this used to show a brief atmosphere release as ships undock.
The Trivial Psychic Strikes Again!

 

Offline m!m

  • 211
Re: Actions system test builds
I added a "$On Create" hook for weapons. This will start a program when a weapon is created. It works for laser and missile style weapons.

Example:
Code: (actions-wep.tbm) [Select]
$Name: Subach HL-7
+nocreate
$On Create:
+Wait: 0.5
+Set Direction: (1 1 0)
+Start Particle Effect: Beam Warmdown Effect

+Set Direction: (1 -1 0)
+Start Particle Effect: Beam Warmdown Effect

+Set Direction: (-1 1 0)
+Start Particle Effect: Beam Warmdown Effect

+Set Direction: (-1 -1 0)
+Start Particle Effect: Beam Warmdown Effect


Test Builds:
Windows 64-bit

Windows 32-bit

Linux

 

Offline m!m

  • 211
Re: Actions system test builds
Another update of the test builds from the last post. This might not look like much but I have reworked the entire way the values for the actions are computed. Instead of being constant values for everything, it is now possible to use mathematical expressions such as this:
Code: [Select]
+Set Position: (~(8.0 13.0) + 5.0 3.0 8.0 + -5.0)
This might look not very useful (except for the ~(...) part which is a uniform random range generating values between those two) since the resulting values could just as easily be hard-coded.

I added this since the next big step for this system is the ability to define custom actions which can be parametrized. For that I need to evaluate the same expression in different contexts which is where these expressions come in. The parameters will then be usable within the expressions for action values to make them "dynamic".

Another small detail I would like to highlight is that this expressions system is separated from the actions system itself which only uses it. This would allow the integration of these expressions into other parts of the engine such as the ship table where it may be used for dynamically calculating values of a ship on the fly or building some kind of template system. However, that is of course not automatic and will need to be developed separately ;)

 

Offline AdmiralRalwood

  • 211
  • The Cthulhu programmer himself!
    • Skype
    • Steam
    • Twitter
Re: Actions system test builds
Another small detail I would like to highlight is that this expressions system is separated from the actions system itself which only uses it. This would allow the integration of these expressions into other parts of the engine such as the ship table where it may be used for dynamically calculating values of a ship on the fly or building some kind of template system. However, that is of course not automatic and will need to be developed separately ;)
Oh good, I won't have to implement that from scratch for Variants.
Ph'nglui mglw'nafh Codethulhu GitHub wgah'nagl fhtagn.

schrödinbug (noun) - a bug that manifests itself in running software after a programmer notices that the code should never have worked in the first place.

When you gaze long into BMPMAN, BMPMAN also gazes into you.

"I am one of the best FREDders on Earth" -General Battuta

<Aesaar> literary criticism is vladimir putin

<MageKing17> "There's probably a reason the code is the way it is" is a very dangerous line of thought. :P
<MageKing17> Because the "reason" often turns out to be "nobody noticed it was wrong".
(the very next day)
<MageKing17> this ****ing code did it to me again
<MageKing17> "That doesn't really make sense to me, but I'll assume it was being done for a reason."
<MageKing17> **** ME
<MageKing17> THE REASON IS PEOPLE ARE STUPID
<MageKing17> ESPECIALLY ME

<MageKing17> God damn, I do not understand how this is breaking.
<MageKing17> Everything points to "this should work fine", and yet it's clearly not working.
<MjnMixael> 2 hours later... "God damn, how did this ever work at all?!"
(...)
<MageKing17> so
<MageKing17> more than two hours
<MageKing17> but once again we have reached the inevitable conclusion
<MageKing17> How did this code ever work in the first place!?

<@The_E> Welcome to OpenGL, where standards compliance is optional, and error reporting inconsistent

<MageKing17> It was all working perfectly until I actually tried it on an actual mission.

<IronWorks> I am useful for FSO stuff again. This is a red-letter day!
* z64555 erases "Thursday" and rewrites it in red ink

<MageKing17> TIL the entire homing code is held up by shoestrings and duct tape, basically.

 

Offline m!m

  • 211
Re: Actions system test builds
That was one of my possible use cases. I'm currently working on getting parametrized actions to work which will be useful for variants as well where you could define a list of parameters for a template and then use that in expressions inside the template to compute the final values.

 

Offline m!m

  • 211
Re: Actions system test builds
These changes have now been integrated into the latest builds. You can find the documentation on the wiki.

  

Offline wookieejedi

  • 29
  • Intensify Forward Firepower
Re: Actions system test builds
Fantastic, thanks for all your work on this and the detailed wiki article!