Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Test Builds => Topic started by: m!m on December 28, 2020, 03:38:25 pm
-
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:
#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
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 (https://porphyrion.feralhosting.com/datacorder/builds/test/actionSystem/test_actionSystem-builds-x64-SSE2.zip)
Windows 32-bit (https://porphyrion.feralhosting.com/datacorder/builds/test/actionSystem/test_actionSystem-builds-Win32-SSE2.zip)
Linux (https://porphyrion.feralhosting.com/datacorder/builds/test/actionSystem/test_actionSystem-builds-Linux.tar.gz)
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]
-
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.
-
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?
-
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.
-
This looks fantastic!
-
Amazing work you did there! :yes:
-
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:
#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 (https://porphyrion.feralhosting.com/datacorder/builds/test/actionSystem/test_actionSystem-builds-x64-SSE2.zip)
Windows 32-bit (https://porphyrion.feralhosting.com/datacorder/builds/test/actionSystem/test_actionSystem-builds-Win32-SSE2.zip)
Linux (https://porphyrion.feralhosting.com/datacorder/builds/test/actionSystem/test_actionSystem-builds-Linux.tar.gz)
-
I could see this used to show a brief atmosphere release as ships undock.
-
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:
$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 (https://porphyrion.feralhosting.com/datacorder/builds/test/actionSystem/test_actionSystem-builds-x64-SSE2.zip)
Windows 32-bit (https://porphyrion.feralhosting.com/datacorder/builds/test/actionSystem/test_actionSystem-builds-Win32-SSE2.zip)
Linux (https://porphyrion.feralhosting.com/datacorder/builds/test/actionSystem/test_actionSystem-builds-Linux.tar.gz)
-
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:
+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 ;)
-
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.
-
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.
-
These changes have now been integrated into the latest builds. You can find the documentation on the wiki (https://wiki.hard-light.net/index.php/Action_System).
-
Fantastic, thanks for all your work on this and the detailed wiki article!