[Bobboau]

to SUPPLEMENT the current triggered animation system, I have implemented a scripted animation system useing WMC's scripting system.

all you need to do on the model side is set it up like you would any normal subsystem subobject. in the table is were most of the work will be done.
in the ships table, start off by filling in a normal subsystem entree, then you add the $animation: tag and as the type instead of triggered as you would normaly do for a triggered animation you type in script.
then in [] brackets, you put in a lua script, Self is the ship the model is being rendered for, use the name of the subsystem to access it ($name of subsystem$.Orientation is probly going to be of a lot of use to you)

an example:

Code: [Select]

$Subsystem:                     gearighta,                        10,0.0
$animation:script
[
Angs = gearighta.Orientation
d = -Self.RotationalVelocity.x
if(Angs.p < d)then
Angs.p = Angs.p + Self.RotDamp * ba.getFrametime()
elseif(Angs.p > d)then
Angs.p = Angs.p - Self.RotDamp * ba.getFrametime()
end
gearighta.Orientation = Angs
]

that will tilt the subobject named gearighta around the x axis as the ship pitches up and down, sort of like thrust vectoring or a gimble mounted engine.

oh, yeah, and on top of that I made it so that engine glows assosiated with subsystem subobjects will rotate properly, set them up normaly, and just do the normal subsystem assosiation thing and done.

http://freespace.volitionwatch.com/blackwater/fs2_open_Bobboau_12-8-06.zip

[Flipside]

Looks very useful indeed, just need to learn more about the scripting before I can use any of this stuff. I'll have a go with the Gimble stuff you posted this week and see if I can get it to work.

Thanks Bobboau

[Nuke]

i like the way you implemented this bob, good work!
i dont have to clutter up my scripting.tbl with a bunch of code for each ship class's animations, and i dont have to make special versions of scripting.tbl if somone wants to use just one ship. as usual bob kicks ass!!!

[Bobboau]

holy **** nuke, that was my exact, and I mean _exact_ argument when WMC said he was trying to keep everything in the scripting table, I mean that's like spooky, I mean did you get access to the internal or something? sort of creepy

[karajorma]

This is cool. And unlike the other animation stuff since it's handled from the tables and the scripting system it should work in multiplayer without the need for new/edited packets too

[Nuke]

holy **** nuke, that was my exact, and I mean _exact_ argument when WMC said he was trying to keep everything in the scripting table, I mean that's like spooky, I mean did you get access to the internal or something? sort of creepy

well my idea was that modders arent usually good programmers. we really have no clue as to how to keep large amounts of code organized. while we might know how to define an animation through script, we lack the skills to create large scripts that are easy to read/work with/modify. this means i dont have to come up with the 100 or so lines of code that simply try to figure out what ship i want to animate, and gather variables, sticking it right int the table means i can get right down to the dirty part without too much support code.

[Axem]

I think you could do that with WMC's new scripting system anyway. There were specific hooks that you could use to make it work selectively (per ship, per class, per mission). Additionally the new scripting stuff had support for modular tables so it would just be another small table to include.

Still very cool Bob.

[Bobboau]

you couldn't do this already, there was no access to it.

I expect functiopns to be defined in the scripting table and the scripts in the ships table to be minimal, if anything complex is done, it should be partitioned off to a function.

[Nuke]

do theese entries share the same memory space as the other scripting locations, i mean if i define a variable in one animation, can i see that variable from scripting.tbl or another animation or hook?

[Bobboau]

it should.

[WMCoolmon]

With scripting.tbl and the code I've got sitting on my hard drive:

Code: [Select]

#Global Hooks
$Simulation: [
--Iterate through all ships
num_ships = #mn.Ships
for i=1, num_ships
ship = mn.Ships[i]
--Only apply the rotation to ships with the right class
if ship.Class == "GTF Blah" then
gearighta = ship['gearighta']
--#####BEGIN BOBB'S CODE#####
Angs = gearighta.Orientation
d = -ship.Physics.RotationalVelocity.x
if(Angs.p < d)then
Angs.p = Angs.p + ship.Physics.RotationalVelocityDamping * ba.getFrametime()
elseif(Angs.p > d)then
Angs.p = Angs.p - ship.Physics.RotationalVelocityDamping * ba.getFrametime()
end
gearighta.Orientation = Angs
--#####END BOBB'S CODE#####
end
end
]
#End
Or with conditional hooks, if an "On Physics" hook were implemented for conditional scripting. You could also use an On Render hook, but On Physics would be more proper since the subsystem is actually _moving_:

Code: [Select]

#Conditional Hooks
$Ship class: GTF Blah
$On Physics: [
gearighta = sv.Ship['gearighta']
--#####BEGIN BOBB'S CODE#####
Angs = gearighta.Orientation
d = -sv.Ship.Physics.RotationalVelocity.x
if(Angs.p < d)then
Angs.p = Angs.p + sv.Ship.Physics.RotationalVelocityDamping * ba.getFrametime()
elseif(Angs.p > d)then
Angs.p = Angs.p - sv.Ship.Physics.RotationalVelocityDamping * ba.getFrametime()
end
gearighta.Orientation = Angs
--#####END BOBB'S CODE#####
]
#End
So the first chunk should actually work with the axem build in my latest build thread, but the latter will not work; the only thing the build lacks is a hook for when the calculations are done for the ship for physics, or for when it's rendered, or any other hook that is executed every frame rather than when a specific condtion being met.

And I'm not exactly sure why you would clutter up your scripting table when you could just as easily make modular scripting tables.

And yes, Nuke, _all_ defined variables are by default global scope. This is why I recommended that you use the local keyword and prefix all other variables with g_* in one of the docs I wrote for scripting, I believe it's the one in the wiki, because otherwise you'll get commonly-named variables modified randomly.

Bobb is right that what he has implemented wasn't possible with current CVS, though.

[Bobboau]

ahh...
oh.....

this is why you should keep CVS up to date.
(like I should talk)

[WMCoolmon]

Well I'm very happy to see that somebody's (ie a coder) expressing interest in the scripting system. Most of the fundamental Lua function definition process has been left the same, and the global definition stuff is virtually identical. The main differences are that a number of the functions have been renamed to "ade_", the term for the new FS2_Open Lua API, rather than "lua_", (eg most notably lua_set_args->ade_set_args, lua_get_args->ade_get_args), sub-libraries are possible, and there's a hell of a lot more flexibility when it comes to the lowlevel code.

I've attached the current scripting.html as scripting.txt, IIRC the very last thing I did to the file was to add the conditional hooks listing, so it should be up-to-date with all the current code.

If you know for sure that you're going to do something with the code, I can probably upload it tomorrow. I need to understand what exactly is required; I have a todo list of things that I wanted to get done, but I was slowly realizing weren't really required. And I'd feel a lot more comfortable having everything re-synced to CVS, if only to increase the number of backups for the code.

[attachment deleted by admin]

[Bobboau]

after sleeping on it I think there may still be one advantage to how I did this, that would be it calls the script after the normal rotation code is done, so the angles of all the other subobjects are up to date.

even though it seems this isn't totally necessary, I think I'm going to leave it in, cause it makes things a bit more convenient, and there is some stuff with having the subobject flaged as getting rotated by a script, and there will probly be some collision tweaks that will need to know about that.

[Nuke]

i finally got a model i can test this on. was putting working controls in the sepulture. pretty soon i should have them working.

*edit*

its giving me of messages like this

Code: [Select]

Warning: Use of deprecated subsystem syntax. Please use $Flags: field for subsystem flags.
File:I:\FSO\fs2_open\code\ship\Ship.cpp
Line: 4279
[This filename points to the location of a file on the computer that built this executable]

Call stack:
------------------------------------------------------------------
    parse_shiptbl()    parse_modular_table()    ship_init()    game_init()    game_main()    WinMain()    WinMainCRTStartup()    kernel32.dll 7c816fd7()
------------------------------------------------------------------


im getting like 43 of them. there all pretty much the same. gets old seeing it 43 times. i cant find proper info on the correct tabe syntax to make it stop complaining.

waiting for many other messages about missing bmps to go by, probly media vp related, only to have it crash on mission load. debug builds are annoying it finally died with:

Code: [Select]

Assert: sip->subsystems[j].model_num == sip->modelnum
File: I:\FSO\fs2_open\code\ship\Ship.cpp
Line: 14646
[This filename points to the location of a file on the computer that built this executable]

Call stack:
------------------------------------------------------------------
    level_page_in()    freespace_mission_load_stuff()    game_post_level_init()    game_start_mission()    game_enter_state()    gameseq_set_state()    game_process_event()    gameseq_process_events()    game_main()    WinMain()    WinMainCRTStartup()    kernel32.dll 7c816fd7()
------------------------------------------------------------------

*edit again*

after some messing around i inally got it to work, while the effects are cool, it makes the game very fond of crashing. might just be my models, this max plugin might be to blame.

[WMCoolmon]

+untargetable and the other subsystem flags can be specified now with $Flags: ("untargetable") and so on, just like the other ship flags. It cleans up the table and means that if/when there are more subsystem flags, you don't have to scroll through 11 short lines, just one long one.

[Nuke]

i think my problems were with pof exporters shield export. it just cant export a stable shield mesh worth crap. so i just imported the one from the old version of the fighter which was a scn file converted through pcs. so its working fine now. i notice some slowdowns, not framerate drops, that stays at 120 but it seems like the physics of the game are getting bogged down by the scripting interface.

[WMCoolmon]

There's not enough information in that post to even make a wild guess about whether that's true or not. Seriously, I don't even know what build you're using - it might as well be the first build that used Python. I don't know if you're using any scripts at all, for that matter, or if the ones you're using are at all related to physics. Just because you're not making a bug report via mantis doesn't mean that I need any less information than if you were.

[Nuke]

i only noticed it in bobs last 2 or 3 builds. its probibly not a problem with the scripting, thats just me jumping to dumb conclusions. i moved all script development to its own mod directory, so as to keep nukemod more stable. i noticed the problem testing the animation script build. but i remember seeing something similar in nthe pistons build as well.

*edit*

woohoo i got the controls in the sepulture working. gotta reconfigure some pivots but otherwise it works well. now i gotta do the same on all the other ships i have that have cockpits. with all this animation stuff though, id like a flag that omits a subsystem from recieving damage. just so that running into a stelleto doesnt blow up my flight yoke

[WMCoolmon]

http://www.hard-light.net/forums/index.php/topic,44021.0.html