death animation and corpses.
Moderator: Moderators
death animation and corpses.
Here is a video of my new commander death:
http://cs.selu.edu/~ssmith/BB/files/gawdies_111.wmv
As you can see it looks good... large arcraft translates to ground then booms.. but it is the part afterwards and durring that bothers me.
you see, the commanders corpse pop up un the air.
2 things..
I can ONLY translate the base part.. I cannot translate my gp origon part. This means that the units are still firing at the spot the commander used to be.. this does suck very much as it makes the translation obvious. Also the unit is DEAD... it should no longer be a target.
Secondly the corpse spawns where the commander still *is*.. this means that it looks really akward.
If there is a solution please let me know... if there is not... then could someone correct this for the next version of spring?
http://cs.selu.edu/~ssmith/BB/files/gawdies_111.wmv
As you can see it looks good... large arcraft translates to ground then booms.. but it is the part afterwards and durring that bothers me.
you see, the commanders corpse pop up un the air.
2 things..
I can ONLY translate the base part.. I cannot translate my gp origon part. This means that the units are still firing at the spot the commander used to be.. this does suck very much as it makes the translation obvious. Also the unit is DEAD... it should no longer be a target.
Secondly the corpse spawns where the commander still *is*.. this means that it looks really akward.
If there is a solution please let me know... if there is not... then could someone correct this for the next version of spring?
Last edited by smoth on 14 Mar 2007, 09:51, edited 1 time in total.
Hmm I was thinking about death animations lately... What about land units? Is it possible to make them stay areound a few sec after death for some mesh-falling-over action? Like in the FBI:
deathdelay=10;
Then you can animate it like usual in the BOS/COB. That would own so much.
And also would be nice if remaining a target was also set in the FBI so the modder can choose rather then hard coded.
deathdelay=10;
Then you can animate it like usual in the BOS/COB. That would own so much.
And also would be nice if remaining a target was also set in the FBI so the modder can choose rather then hard coded.
As for the corpse appearing in the air: does somebody know what factors (it any) determine its fall speed? I tried to make some planes with corpses and they seem to fall way too slow... One possible workaround is to make the units explode completely in death animation (probably upon reaching ground) and leave no corpse, which even makes some sence for aircraft falling from great heights.
smoth:
I've already got this feature in the synced LUA scripts, I should have
it setup for COB scripts by the time I commit. Here's a format I'm
considering (the names are in flux, etc...) What's important to consider
is whether or not the packed coordinates format is desired.
The rotations are done in the following order: Z, X, Y.
P.S. Note that the PhysicsOverride() calls would have to be defined in
the COB script, even though its contents are not used (the same trick
as for the lua_XXX() calls). It could be setup to use a single call, and use
the number of parameters to determine the mode.
P.P.S. That's preliminary... I might want to swap out the 1 param toggle
version for a only-change-heading version depending on whether or not
a single call is used.
I've already got this feature in the synced LUA scripts, I should have
it setup for COB scripts by the time I commit. Here's a format I'm
considering (the names are in flux, etc...) What's important to consider
is whether or not the packed coordinates format is desired.
Code: Select all
// 1: use 1 parameter to enable/disable the override
call-script PhysicsOverride(enabled)
// 7: all parameters (the next position is used for extrapolation)
call-script PhysicsOverridePosAng(XZ, Y, nextXZ, nextY, rotX, rotY, rotZ)
// 5: translation and heading
call-script PhysicsOverridePosHeading(XZ, Y, nextXZ, nextY, heading)
// 4: translation, no angular adjustment
call-script PhysicsOverridePos(XZ, Y, nextXZ, nextY)
// 3: angular displacement, no translation
call-script PhysicsOverrideAng(rotX, rotY, rotZ)
P.S. Note that the PhysicsOverride() calls would have to be defined in
the COB script, even though its contents are not used (the same trick
as for the lua_XXX() calls). It could be setup to use a single call, and use
the number of parameters to determine the mode.
P.P.S. That's preliminary... I might want to swap out the 1 param toggle
version for a only-change-heading version depending on whether or not
a single call is used.
I'll probably also want to set it up so that the inital PhysicsOverride(value)
setting determines whether or not the engine increments the position based
on the speed. Would probably want to rename the nextXZ/Y params to
speeds in that case.
Something like:
0: override disabled
1: override enabled, extrapolate positions
2: override enabled, fixed position (faster if only rotating)
I'll decide when I've got a clearer head, and after I've "refactor"ed
a little to setup a fake moveType rather then forcing values
setting determines whether or not the engine increments the position based
on the speed. Would probably want to rename the nextXZ/Y params to
speeds in that case.
Something like:
0: override disabled
1: override enabled, extrapolate positions
2: override enabled, fixed position (faster if only rotating)
I'll decide when I've got a clearer head, and after I've "refactor"ed
a little to setup a fake moveType rather then forcing values

Wait, is it possible with the current engine or are you talking about how it should be? I always tought the killed() only lets you choose explosions. I agree with this cleaner implementation.KDR_11k wrote:No tags, you just put the animation into Killed() and the unit will disappear when Killed() returns. The unit will remain a target while Killed() is running, though.
It applies to units, and it isn't just for death animations (ex: it makes
teleporters relatively easy to create). I have separate calls (in lua),
for controlling feature positions, health, resurrections, etc...
Test screenshot (before I setup the midPos):
http://trepan.bzflag.bz/spring/override.jpg
teleporters relatively easy to create). I have separate calls (in lua),
for controlling feature positions, health, resurrections, etc...
Test screenshot (before I setup the midPos):
http://trepan.bzflag.bz/spring/override.jpg
-
- Posts: 854
- Joined: 28 Jan 2005, 18:15
anyone else think trepan is the man...
clearly trepan is descended from SJ himself, taught to always make awesome lua widgets, taught never to surrender.. that to make spring awesome is the greatest glory a dev can achieve.. Trepan, the greatest dev the world has ever known....
That or the 1000 lua widgets of the trepan empire descend upon you... Their feature list shall blot out the sun...
clearly trepan is descended from SJ himself, taught to always make awesome lua widgets, taught never to surrender.. that to make spring awesome is the greatest glory a dev can achieve.. Trepan, the greatest dev the world has ever known....
That or the 1000 lua widgets of the trepan empire descend upon you... Their feature list shall blot out the sun...
-
- Posts: 854
- Joined: 28 Jan 2005, 18:15