Hard Light Productions Forums
Modding, Mission Design, and Coding => The Modding Workshop => Topic started by: Nautical Insanity on February 02, 2010, 03:00:10 pm
-
So I'm currently working on modeling a new Terran cruiser that eschews anti-capship beam cannons for long range (10-15 km) kinetic cannons. Basically these things are supposed to be Godzilla to the Maxim's lizard. I want them to feel huge. One of the effects I'd like to include is a recoil animation, where the barrels of the gun snap backwards every shot and slide forward to launch a new round. However, I haven't found much helpful documentation on how to implement it. Most animation text I've seen deals with rotating subsystems. If anyone with more experience at modding than I has any advice, a helpful previous thread, or even just an "Abandon all hope, ye who enter here," I'd greatly appreciate it.
-
If I recall correctly, there is no way to have a true sliding animation, the closest you can get is to make a point of rotation really far away.
-
I think "really far away" is a close enough approximation. I'll give that a try once I get further into the design process. Thanks, and great idea!
-
Nuke posted a way of doing this in the absence of a true "translation" function...
...I can't find it right now, but it involved using rotations about "actuators" connected together to something like a door, etc. Basically, the animation was composed of three sub-objects.
-
The parent subobject, the 'door', and two hinges. Each object rotates about the previous one, the hinges are invisible and only exist to give the other objects something to pivot around.
-
Nuke posted a way of doing this in the absence of a true "translation" function...
...I can't find it right now, but it involved using rotations about "actuators" connected together to something like a door, etc. Basically, the animation was composed of three sub-objects.
See here (http://www.hard-light.net/forums/index.php?topic=67769.msg1338775#msg1338775).
-
Great! That is a lot of help. Props to Nuke for that.
-
I honestly don't see how that is going to work properly for recoil.
Nautical Insanity if I were you I'd give up on the idea, as far as I know its just not possible to get this to work in the way you'd want it to. The current animation code is just too limited.
-
No, using that folder mechanism does not work for turret recoil. Firstly we don't have a working 'turret-fired' animation trigger (I have been working on one but I'm currently too busy to complete it :( ), AND the heirarchy depth is one level too deep to work correctly in-game. I did have some semi-successful test builds a while back where turret recoil worked, but there are still a few hiccups in the system, such as what happens if the weapon has a faster rate of fire than it takes for the turret barrel to reset, what happens with swarm or missile weapons, and whether it's possible to have individual barrels recoiling etc.
So in all no it's not possible now, but it isn't far off. :)
-
The "turret-fired" trigger and the hierarchy depth look like the deal-breakers on this for sure. That's good to know before starting to beat my head against a wall, thanks.
-
Haha, yeah that particular wall already has chunks of my hair and scalp on it from several different recoil testing sessions in the past. ;)
-
I just looked at the wall, touched it gently. Noticed the blood, hair and other organs stuck to it
and slowly backed away from it all
:warp:
-
my demo kinda works but there are collision issues (even when using the collada inporter). collisions work ok when the animation at rest. however once it starts moving the collision detection is totally wrong. the collada importer seems to have issues with bounding boxes when your object origin is not within it. i dont remember ever having these sorta issues when i was still importing scn files. in fact ive done several animated models which use origins not within the bounding box without issues. these models were created completely with truespace saved as scn and exported with pcs2 and not one has a messed up bounding box. so i think this is a bug with pcs2 (specifically the collada importer). we need more active development on the pcs2 collada importer. now i havent tested that door animation with a cob model, and it mike not have collision detection issues. collision detection sorta works like this:
checks if objects have overlapping radii
checks if objects have overlapping bbox
???
profit!
so really theres no reason for the bounding box to contain the origin, so long as the bounding box its completely within the radius.
No, using that folder mechanism does not work for turret recoil. Firstly we don't have a working 'turret-fired' animation trigger (I have been working on one but I'm currently too busy to complete it :( ), AND the heirarchy depth is one level too deep to work correctly in-game. I did have some semi-successful test builds a while back where turret recoil worked, but there are still a few hiccups in the system, such as what happens if the weapon has a faster rate of fire than it takes for the turret barrel to reset, what happens with swarm or missile weapons, and whether it's possible to have individual barrels recoiling etc.
So in all no it's not possible now, but it isn't far off. :)
thats not entirely accurate. i added a function to scripting some time ago that checks if a turret is fired, and if it returns true, trigger animation. the reason i implemented it is so i can have gatling turrets. those bypassed the animation system all together and just changed their position in lua. but for recoil, i dont think thats neccisary.
anyway i added a subsystem flag to ship.h, SSF_HAS_FIRED, which becomes true when a subsystem is fired successfully. i didnt really add any means to turn the flag off, so when i wrote the hasFired() function for lua (its in lua.cpp somewhere) it sets the flag to false after sending the value to lua. you could use the flag to set off your animation trigger, but you need to clear the flag once its been used or it will try to animate every frame. or better yet set the flag to zero in process_subobjects in ai_code.cpp. probibly be better to do it that way so that if you check the flag from anywhere it wont clear it. then just remove the "sso->ss->flags &= ~SSF_HAS_FIRED;" line from my lua function (should be around 5510).
-
Arrgh collision detection how I hate thee.
If it worked properly then combining your subsystem fired flag with a script that manually slid the barrel object back and forth along the turret arm axis would be a sorta reasonable, if quite difficult system to use for modders. By that I mean setup model wise would be easy because you'd only need a barrel subobject. Setup table wise though you'd need to delve somewhat heavily into scripting, which most modders are simply not willing to do, and of course, you would have fly-through barrels if not the whole ship.
Hmm, so that brings us to a system as you suggest where you use scripting to trigger an existing animation, again via the subsystem fired flag. How would this script work in terms of specific ships? Like, if you had just converted and tabled a new ship that was recoil-ready, would you have to edit the one script to allow your ships guns to work? By the sounds of it you almost certainly would, which would make turret recoil possible and with working collision detection, but still really really impractical for standard use due to the complexity of the setup.
Even the tests I did which linked directly into the animation system (meaning no scripting was necessary) are still horrible to set up in terms of turret hierarchy (ie, the folders) and then the animation sequence itself in the table which is like several paragraphs of instructions per turret.
So ideally, the finished 'turret-fired' animation trigger combined with propper animated subobject translation is what we want. :\
-
i dont think were getting translation any time soon, things are lacking in both the pof format and the engine itself. the pof file needs to keep a 4x4 matrix (which would store the complete transform for that object, translation + rotation). each subobject would have its own frame of reference essentially. the engine would have to use theese too. right now it only bothers with a 3x3 matrix to store orientation and a position to store translation. this is also more compatable with the opengl way of doing things.
really between the archaic model format and the archaic collision detection im supprised this engine still works. you may be able to get around the collision detection issues if you surround the barrel with an invisible subobject. this will be the actual barrel for the turret, and could even be a copy of the barrel but with an invisible texture. you would attach your actuator arm->actuator arm->fake barrel geometry to it (probibly disable their collisions for sanity/performance). you collide with invisible barrel before you can ever touch fake (but visible) barrel. the only time you will see this is if you try to fly through it while its animating and you hit the invisible wall. maybe some code that kills anything near the turret when it fires is in order.
i do kinda have a basic scripted animation system which is mainly used to animate cockpit interior, i dont see why it wouldnt work with turrets though. getting moders to work with even less than 10 lines of script is impossible. i think i had to edit my old lua railgun particle script for 6 different people who wanted it to work with their weapon and couldnt change the if statement to coraspond to the name of their weapon they wanted to use it on. this is kinda why i wrote this monster (http://www.hard-light.net/forums/index.php?topic=64606.0). hopefully that will make it easyer for modders to mod with scripts.
-
What we need is translation. Just having rotation is limited....