[Galemp]

Right, theoretically we have everything we need to make things happen like docking claws opening, turret recoil and wings opening. It's all softcoded in the tables right now, and it can be difficult for modders like myself to use.

What I'd like to formally request is more hardcoded, integrated, comprehensive support for animations like these. We can define a certain set of animation actions (dock, weapon, door, afterburner, turret, scripted) then create default actions that are used when that function is activated.

This ought to be as accessible as possible, with only the highly variable aspects accessible to the table modder. If you want to know what I mean, take a look at the Afterburner code.

Code: [Select]

$Afterburner:           YES
+Aburn Max Vel: 0.0, 0.0, 110.0
+Aburn For accel:       0.7
+Aburn Fuel:            300.0
+Aburn Burn Rate:       50.0
+Aburn Rec Rate:        25.0


That's it. There's no need for the modder to define how large the resulting engine glow is, which engine glows to use, how much or how long to shake the cockpit view, or what sound to play; the player hits a button, the afterburner performs as expected, and that's it. Likewise we should be able to tie a whole set of functions related to specific animations together in the hardcode and then give the tabler the minimum of specifics necessary.

So, coders, here's your challenge: define a toggle for S-Foils, open and closed. Native S-Foil support should:

• Define a set of subobjects as being part of an animation set. These subobjects are untargetable, indestructable and carry over full damage; for all intents and purposes they are part of the hull.
• Be activated with a keyboard command specifiable in the controller configuration, independant of any other command.
• On toggle, rotate animation subobjects, with their children, by a specified relative angle. They all rotate simultaneously at the same angle offset, accelleration, velocity, deceleration, delay, time, and sound effect. They all rotate around their own subobject pivot points and in their own direction (positive or negative rotation.) Toggling them again rotates them by these same values but reverses the direction. Tables should define which subobjects, angle offset, total animation time, and sound effect to play when initiated. Rotation axis and direction and pivot points are specified in the subobject data of the POF. The rotation speed should be hardcoded to be calculated based on the length of the animation and the angle delta.
• On toggle, use a table value to specify whether to disable the ship's afterburner.
• On toggle, use a table value to specify what primary and/or secondary weapon banks to lock, if any. They should not unlock until the animation is finished (so the model's gun lines up with the firing point.) For models that have firepoints on the moving parts, this eliminates the need to associate player firing points with subobjects, avoiding model format retooling. This also avoids the hideously painful and totally unneccesary 'when-button-pressed lock-weapon-bank' SEXPs currently required.
• On toggle, temporarily reallocate all energy from weapons and/or engine depending on whether weapons and/or afterburners are locked, as if the player had adjusted their ETS. Energy levels on the ETS should not be changed--the game should not reallocate energy for the player--but rather the game should redistribute allocated energy from the unused systems to the used systems temporarily. Thus the code can be used for a boost in speed and shielding, as if folding into a 'cruise' or 'recon' configuration; for weapons and shielding, as if extending an armored shell for a bombing assault; or with a single keypress shunting your ship into Total Defense mode while rearming.
• Be linked into AI behaviour so AI will shift into different modes depending on their current goals. For example, the AI might prefer to shut off their weapons when evading or when there are no hostiles present, while they would prefer to shut off their engines when waiting for support or within range of a capital ship they are attacking.
  

Later on, it would be preferable to have it be set with an Initial Status flag in FRED, so ships in a mission can start in a specified mode, or even as a toggle in the wing loadout screen; but these require FRED and GUI work and aren't necessary to the actual functionality.

Again, I have to stress that all these features need to be tied together into one system so that they all activate with the single keypress. Pretty much everything here can already be done, with extensive time and effort on the part of the FREDder, but wrapping this all into one system allows it to be activated natively, with any mod, in any mission, for every ship, player-controlled or not.

This is a tall order, I know. All the code is already there, but it needs to be organized into one package. Is anyone up for it?

[WMCoolmon]

Starfox mod could probably use something like this, as long as it wasn't totally Star Wars-centered.

I'll toss out the idea of animation templates, or subsystem templates, but I'm not gonna have the time to code this.

[Backslash]

The subsystem/device template idea is awesome, and something I've been thinking about for a while.  I doubt I have the time OR skill to do it myself, but I'm definitely willing to help if we can find other interested coders.  I think EVERY mod could use this in some form or another, except perhaps 'pure' FS2 mods that don't want to shake the canon boat too much

Think of it inside-out -- the animation doesn't trigger the characteristics... instead, a 'device'/subsystem with these characteristics triggers the animation.  Imagine this system as a new table.  A device has 3 'phases'.  Phase 1 is the 'warm up', phase 2 is the 'active', and phase 3 is the 'warm down'.  The table sets what each phase does.
Phase 1 triggers the animation, plays a sound, disables afterburners and weapons, and waits X seconds.
Phase 2 re-enables afterburners, reallocates energy and maybe changes flight characteristics.
Phase 3 triggers the animation in reverse, plays a sound, disables afterburners and waits X seconds.
After this we're put back in 'normal' mode, putting energy allocation, weapons, and afterburners back to default.

Phase 2 can be customized in the table to either be infinite (until the player turns it off with a key press), last a certain amount of time, or until some sort of 'ammo' runs out.

Interesting how similar this is to the concept of a cloaking device:
Phase 1 triggers the animation (granted, more of a texture change than a moving subsystem, but still...), plays a sound, disables afterburners, shields, and weapons, and waits X seconds.
Phase 2 reallocates energy and maybe changes flight and sensor characteristics.  Oh and there's the little detail of making the ship invisible too, yeah
Phase 3 triggers the animation in reverse, plays a sound, and waits X seconds.

See what I'm getting at?  The possibilities are awesome.  The problem is getting started.  Once the beginning framework is in place, it'll be easy to add things one by one... "oh yeah, how about let's add a radar range change" -- Stuff like that, I can do.

[DaBrain]

Starfox mod could probably use something like this, as long as it wasn't totally Star Wars-centered.

Yeah, that might be a nice useful feature for a lot of stuff.

I'd like to expand that request to not only play a sound effect when the animtion is triggered, but also place an effect (EFF) at the pivot postition of the animated subsystem.

[Galemp]

I see what you're getting at, Backslash-- a universal system of changing flight and model properties with a keypress, that can be universally applied. I like it, a lot. It is indeed a radical new way of doing things but the possibilities are amazing.

If you want to know where to start, why not try afterburners? Write a new system with the effects of an afterburner (i.e. what activates it, what flight effect it has, what visual effect it has, whether its toggled or has to be held down, etc.) then we'll see how we can expand it.

Even 'Pure' FS mods could use this to a certain extent. Imagine the fins on an Ares folding flush with the hull for that extra shielding boost...

[Vasudan Admiral]

Ok, I must say I don't like the idea of a separate animation system that uses hard coded values. One that assigns reasonable default values if that data is not present is no problem though.

As for the implementation of such a system, I would recommend using a separate "ActionScript" tbm for each ship. The point of separating it from the ships table would be just to keep the ships table entry clean and also keep the ActionScript sequence neatly separate and managable.

You would specify an ActionScript for a subobject on a triton like this:

Code: [Select]

$Subsystem: DockingClaw1, 0, 1.0
$Flags: ( "untargetable" )
$ActionScriptSet: DockingClaw1
Where "DockingClaw1" would be name of a set of ActionScripts in that ships ActionScript tbm. The tbm itself might be named "GTFr Triton-AS.tbm" (Ie, "<ship name>-AS.tbm")
The idea of this new system would be to reorganise the existing system into a far more useful, intuitive and flexible format of ActionScripts.

The contents of the ActionScript tbm might look like this:

============

#GTFr Triton                                            ;;Name of the ship these apply to

$ActionScriptSet: DockingClaw1              ;;This is the name of the collection of scripts that are all applied to the subobject that references this set
        $ActionScript: MyDockingScript        ;;This is the name of the individual script, so it can be called by SEXP or scripting.
                $Trigger: Docking                    ;;This trigger works in the same way as the current ones, but there is only one for each action script
                  +DockPath: 5                        ;;Number of the path (ie, so multidocking works correctly - this is currently 'sub-type' in the current system)
                $Action: Glowpoints                ;;For each script there is a number of individual actions that are stepped through in the order they appear
                  +delay: 0                              ;;All or most actions should have this field - it specifies how long to wait after the previous action fired
                  +glow bank: 2                       ;;This action will control the second glowbank of the pof overriding default values
                  +on time: 0.5
                  +off time: 0.5                        ;;Yay blinking docking lights!
                $Action: Submodel   ;;For each script there is a number of individual actions that are stepped through in the order they appear
                  +delay: 0
                  +relative_angle: 0,0,30
                  +velocity: 0,0,10
                  +acceleration: 0,0,5
                  +time: 2000                           ;;This whole bit would open the docking arms by rotating the subobject in some way - same as existing code
        $ActionScript: MyDockedScript         ;;Now for what happens once it actually docks
                $Trigger: Docked                    ;;This trigger works in the same way as the current ones, but there is only one for each action script
                  +dock path: 5                        ;;Number of the path (ie, so multidocking works correctly - this is currently 'sub-type' in the current system
                $Action: Glowpoints                ;;For each script there is a number of individual actions that are stepped through in the order they appear
                  +delay: 200
                  +glow bank: 2
                  +on time: 0
                  +off time: 0                        ;;Turn blinking docking lights on permanently now it's docked
                $Action: Submodel
                  +delay: 0
                  +relative_angle: 0,0,-30              ;;Rotate back to the original position now it's docked
                  +velocity: 0,0,10
                  +acceleration: 0,0,5
                  +time: 2000   

#End

===============

So, an action script for an Xwing might be:

===============
#X-Wing

$ActionScriptSet: SFoils1And3               ;;SFoils 1 and 3 would specify this in the ships table "$ActionScriptSet:" field
        $ActionScript: OpenOrClose
                $Trigger: KeyToggle
                  +key: "G"
                $Action: Submodel
                  +delay: 0
                  +relative_angle: 0,0,15
                  +velocity: 0,0,10
                  +acceleration: 0,0,5
                  +time: 2000   

$ActionScriptSet: SFoils2And4               ;;SFoils 2 and 4 would specify this in the ships table "$ActionScriptSet:" field
        $ActionScript: OpenOrClose
                $Trigger: KeyToggle
                  +key: "G"
                $Action: Submodel
                  +delay: 0
                  +relative_angle: 0,0,-15      ;;These two Sfoils rotate the opposite direction
                  +velocity: 0,0,10
                  +acceleration: 0,0,5
                  +time: 2000   

#End

===============

There would be a number of types of Triggers and a number of types of Actions, which might include:

Triggers

• KeyToggle                            ;;This would step through the actions when toggled on, and undo them when toggled off.
    +key: "<key>"
• KeyPressed                          ;;This would run the script each time the key is pressed with a delay
    +key: "<key>"
    +delay: <ms>
• AIBehaviourToggle               ;;This would run the script when a specified behaviour is engaged, and undone when disengaged
    +behaviour: <type>

          ;;No idea what would be needed here - there should be internal code flags to look for somewhere

• Initial                                    ;;Same as current implementation

Actions

• Submodel                   ;;Reorganised version of the current submodel animation code with all the current + fields
• Glowpoint                   ;;Overrides the values of any fields in the specified glow bank in the pof
    +glow bank: <glowbank # in pof>
    +displacement time:
    +on time:
    +off time:
    +properties: "property stuff in pof"
• Afterburner                  ;;Enables or disables the afterburner
    +enabled: <YES/NO>
• GunBanks                    ;;Locks the specified bank # as it appears in the pof - can take multiple +lock: fields
    +lock:
• ETS                              ;;Sets the engine/shields/weapons power. I have no idea what this would need to change

That's most of the functionality talked about in this thread, but when I have time I'll see about writing up the existing triggers in this format.

[Solatar]

I always thought those things on the bottom of the Apollo (that hold the missiles) should have been able to retract when not in use...

[Swifty]

To play devil's advocate, why can't LUA scripting be used for these type of animations? I'd argue that scripting is flexible enough and powerful enough to execute these sorts of actions without having to resort to table hardcoding this stuff in the executable.

[Vasudan Admiral]

You could only do some of this via LUA, and it would be much more difficult for others to understand and edit, let alone create in the first place. AFAIK there is currently no way to properly replicate submodel animation particularly in LUA at all since you can only set subobject positions - which breaks collision detection. It's also infinitely easier to specify a rotation angle, velocity and acceleration than it is to come up with an equation that will perform the same task.

For example to trigger a subobject animation via keypress you would currently need to set it all up in the ships table and then write a script that acted as a go-between for the key pressed trigger. I have no idea what the script for that would look like but in an actionscript system it's fairly obvious because it's kinda in a block and hierarchy arrangement. Ie, if you want to animate glowpoints you would put a glowpoint $Action block in and specify the parameters for its operation. With the delay fields you could set up very complex sequences relatively easily, such as having a 'living' ship completely change appearance depending on what it was doing, docking sequences with blinking lights and cargo clamps, X-wing Sfoils with locking weapons and everything else described here, hidden turrets activating and being uncovered when a ship comes under attack - the list goes on.

Most things that this system can do could be done one way or another somewhere else, but the idea here is that it just brings everything neatly together and makes it really really easy to use and connect with other aspects. Ie, currently you can't neatly link glowpoint behaviour to sound effects, or SEXPs to submodel animations, or custom special effects (like the sathanas star buster effect) to glowmap animations.


In fact, it may well be that you could integrate some existing SEXPs into this - stuff like glowbank on/off functionality, shields on/off, turret lock etc already exists in there.

[Galemp]

Right you are, VA. This is a great way to bring all these new features under one roof, as it were.

I think you're absolutely right, we should have a seperate table with ActionScripts identified... but let's not make it a TBM for each. Let's instead have a new actions.TBL that any ship in ships.tbl can reference.

So, instead of having GTFr Triton-AS.tbm with #GTFr Triton ... #End and X-Wing-AS.tbm with #X-Wing ... #end, we simply have actions.tbl that defines all ActionScript sets.

Hence ships with similar animations can use the same actions. Extending the activation parameters, we can possibly have a 'crippled' action script that disables glowpoints and randomly blinks glowmaps that can be set to activate when the ship is at 10% hull strength. Then all that needs to be done is to add the $ActionScriptSet: Crippled to the table entry.

[Nuke]

ive mostly been doing my animations in scripting where i get more control over it all.

[Backslash]

I like the way you guys think.  You don't just ask for the moon, you outline a plausible step by plan by which to invade and take the moon.

Seriously though, I'm biting off way more than I can chew here unless we can find someone else willing to help with this.  Otherwise it'll be a very long term project, say a year or two or more.

The SEXP idea is a good one... perhaps part of the ActionScript table could be made to accept SEXPs.  Granted, only ones that affect that ship.

If you want to know where to start, why not try afterburners? Write a new system with the effects of an afterburner (i.e. what activates it, what flight effect it has, what visual effect it has, whether its toggled or has to be held down, etc.) then we'll see how we can expand it.

In fact that is where I was looking  My first goal is to as a proof of concept, make a mockup secondary 'weapon' that doesn't 'fire' a projectile but instead behaves much like a beam, with a 'warmup', 'life', and 'warmdown'.  Later, make it so during the 'life' it runs the 'booster' (of which there is skeleton code already in there I can harness).  Eventually, of course, change all that to a new tertiary class, with appropriate tables, controls, timestamps, sounds, and HUD options.

I don't know if you've played Tachyon: The Fringe, but it has a system I would love to be able to imitate someday... where tertiary devices are customizable in the loadout screen.  Scanners, ecm, countermeasures, lateral thrusters... Even the afterburner is optional.  Even the lead indicator!

[chief1983]

I concur, I have a feeling that other features would get more use if they were developed in such an open manner.

[Galemp]

Seriously though, I'm biting off way more than I can chew here...

...a system I would love to be able to imitate someday... where tertiary devices are customizable in the loadout screen.  Scanners, ecm, countermeasures, lateral thrusters... Even the afterburner is optional. Even the lead indicator!

  I know you're just fantasising but let's take this one step at a time. More than one great idea has been shut down by loading so much crap onto it that it hasn't gotten off the ground.

Proof of concept is a superb idea. If someone outlines a framework, then others can expand and add to it--the trouble is making the transition from 'my feature that I put in' to 'partially implemented system everyone needs to help improve.' I agree that this is more than any one person should be working on but someone has to start by creating the code infrastructure.

I think Bobboau's glowpoints are a good example of collaborative expansion. They're one of the oldest SCP enhancements and they've been accepted and embraced by the community. They've been expanded with animations, submodel associations, and types. They're fully supported now in new models, modeling tools, media VPs, and SEXPs. I really want to see a big project like this as fully embraced as that.

[Vasudan Admiral]

I think you're absolutely right, we should have a seperate table with ActionScripts identified... but let's not make it a TBM for each. Let's instead have a new actions.TBL that any ship in ships.tbl can reference.

So, instead of having GTFr Triton-AS.tbm with #GTFr Triton ... #End and X-Wing-AS.tbm with #X-Wing ... #end, we simply have actions.tbl that defines all ActionScript sets.

Hence ships with similar animations can use the same actions. Extending the activation parameters, we can possibly have a 'crippled' action script that disables glowpoints and randomly blinks glowmaps that can be set to activate when the ship is at 10% hull strength. Then all that needs to be done is to add the $ActionScriptSet: Crippled to the table entry.

Didn't think of that, exactly that 'ActionScript library' kind of usage would be a very good idea.
Heh, it would also be helpful for things like turret initial angles now that I think about it, and if subobject translation eventually appears you could give ships a default fire-recoil animation (heck, complete with sound effects and stuff too) in that same set.

Seriously though, I'm biting off way more than I can chew here unless we can find someone else willing to help with this.  Otherwise it'll be a very long term project, say a year or two or more.

Well something that might help there is how modular it could be code wise. Once the table format is established, each trigger and action would be pretty much self contained, so they could be added in much the same way SEXPs have been currently.

Ie, once the new material system is complete, I think this system would be a great way to combine that power and flexability the materials table will entail with all the other aspects of the game. Ie, you might have Actions that change maps on the fly, modify colour values, turn shaders on and off whenever needed or whatever else the materials system will allow. All kinds of cloaking would be possible as well, which would rock.

perhaps part of the ActionScript table could be made to accept SEXPs.  Granted, only ones that affect that ship.

Yeah that would definitely be cool, though I would think probably a fair bit harder to implement than most of the other stuff. Unless I'm wrong there, maybe something for further down the track?

[Nuke]

i dont see why sfiols cant be done now. set up a key in fred, and when its down do a script eval and can call a function to set a bool. be sure to reset the key in the next event. then you go into scripting, write a toggle sfoil function to orient the wings or call other functions, like ones to disable or re-enable weapons, or tweak engine performance. then write another function to check the state of the sfoils which returns a string or number. you then call it with the script eval number or string. this can be used to enable or disable weapons or apply other effects defined by fred.

[Wanderer]

Except that only plain script eval works... number or string do not - well at least they didnt work the last time i tried to make them work with karajorma. You would probably need to go via sexp variables.

[Galemp]

The point is that non-programmers shouldn't have to. I'd like to have control over S-Foils using the knowledge and experience of table modding and FREDding. LUA is powerful, but unless it's made accessible its power won't be used except by a very few.

[Nuke]

this is for star wars right, im sure you would have no problem finding coders in the sw community, if you dont wish to try it your self. well the new vutlure assuming i ever finish the beast will have every kind of foil under the sun, and proper implementation of all. it has over 30 moving parts. so when i finish it and its necessary animation script, il be sure to post it or something.

lua is a very easy language, an order of magnitude simpler than the c thats used in freespace (no pointer hell). id go as far as saying its the easiest programming language ive ever used.

[chief1983]

It was planned for Star Wars, but as has been shown already, there's a significant interest from all over the modding community, not just us.  Now I'm not saying I agree one way or the other, but I do understand that there's a definite stigmatism that most people tend to associate with something like Lua scripting, since it's essentially a whole programming language of its own.  It sounds like it'd be a significant amount of work either way, hardcording or making a lua script for it, but what might work is to use Lua scripting, if possible, to create some sort of template, that would be just as easily edited as the table would be.  If that can't be done, then it's going to be hard to convince the non-programming inclined that using Lua scripting is a better solution.  It would also be harder to convince me then because I'd rather see a solution that eliminates a lot of duplicating effort, if every mod has to independently come up with a solution, that's a lot of time, but if soemone comes up with something generic, be it in the code or scripting, I'm sold either way.