"death1" animation sequence crashes program

#1 I have noticed this before and I think, now I said think, that the sequences used for the death animation calls are not run by that naming convention, since they are called by index number? Someone should please correct me...and I think, again just thinking, maybe using just the index number for a naming convention might work. This is something I've theorized about but never did the research to see if it's true, but yes; I have noticed the crashing too, with either the .dsq file name or the nameSpace one...

#2 Here's my theory...

The death animation sequence tries to conform the model to the ground... It does some raycasting to achieve this - and im assuming it requires particular dummy nodes/joints to find the limbs and set them accordingly for the most realistic portrayal of a limp dead body laying on the surface of un-even ground.

the problem is... i dont know what those nodes/joints are? Perhaps the entire bone/joint structure must be named exactly correct. (including case-sensitive names)

however - ive done some extensive search through the code and script but cannot find what the program needs from my model in order not to crash.

Ive added joints: eye, cam, unlink, mount0,mount1, ski0, ski1,dummy21,dummy11, etc.

It seems strange that no one knows what this is all about.

Thanks

#3 I've run into this before. Look here:

www.garagegames.com/mg/forums/result.thread.php?qt=9572

#4 Thanks for the reply kurtis - i have looked a pretty much all the links reguarding this topic - but it seems no one can solve this mystery.

I have made a work around too - however it seems weird the orginal model works fine - but new models dont - that means its something with the model files right?

Doesnt someone know what the model needs to work correctly?
Ive searched the code but cannot find what the code or script requires from the player.dts files to prevent the crash.

Thanks

#5 ...only a couple more thoughts on this: One; that you'll have to load the Ms3d Material List with the appropriate number of sequences;if in fact it is calling them by index number...??? For example; the first DeathAnimation is listed as:
sequence9 = "./player_diehead.dsq death1";. Now, when the shape is validated by the engine, it is creating a whole new object, something the engine is expecting to see...ie, a player object with 'all these Nodes' and 'all these sequences', if you haven't created an exact duplicate as possible, I can see how this would occur. The shape you're building wouldn't contain all the goods in the proper order, due to the Blend Animation Types not being accomplished within Ms3d and left out of the validation process...

Two: ...this bit[TorsoFrontFallForward = 1;] also is very interesing...I'm wondering if any of this information is of relevence...? Here it appears to be telling the engine that the index number for the first DeathAnimation[who's description is TorsoFrontFallForward..] Sequence is "1". I'm wondering if this NameSpace is pertinent? There doesn't seem to be many other variables for the sequence names...

I'd love to follow that link[I am a Curious George!], but I'm not a SDK owner...and, I would not hesitate to purchase, except the caveat: I'm not changing/working in SourceCode at all, and not sure how much better questions would be answered having 'ponied-up' a fee. Is the license fee for the SourceCode or for answering quesitions about scripting and shape validation?

Cheers!
Rex

#6 I was thinking about that too...

Ive looked at the source code to see if its looking for the sequence or sequence numbers - but i can only find where it looks for the "death" string and then adds a 1-11 at end.

I think it finds the "death1" sequence in my milkshape file and then tries to do some raycasting (and thats where it crashes) for ground conformation.

My "work around" disables this and doesnt allow it to do the ground conformation... and it works - of course it would be nice to have the body fall and conform properly.

Thanks.

#7 Thank you...any 'peek' at this workaround? I've wanted to do some bots thru Ms3d, but with this...not too sure if it'll work or not...I appreciate it. I've gotten Ms3d to do vehicles....:/??

Rex

#8 My work around consists of commenting out the string compare function...

void PlayerData::getGroundInfo(TSShapeInstance* si, TSThread* thread,ActionAnimation *dp)
{
//dp->death = !dStrnicmp(dp->name, "death", 5);
if (dp->death) {
.....
}

NOTE: this works fine in single player mode - but in multiplayer mode the server will crash if i kill "kork"

SO...ive been forced not to use this workaround anymore and have completely taken out the death animation from my milkshape model.

We really need to figure out the correct way of doing this rather than using any kind of work around... anyone know what to do? anyone? I cant believe this is such a mystery.

Thanks

#9 At the spot in the code where the crash happens (as documented by Kurtis), there are two sets of Transformations/Rotations, both relying on the 'frame' variable. The first one is inside an 'if' condition:

if (frame)
{
...
}

but the second is not. Simply adding this condition to the second set of trans/rots avoids the crash (or you could move the second set into the first conditional; same difference.)

As Kurtis also pondered in his older thread, this might just be preventative to make up for a lack of feature implementation or bug in the Milkshape exporter, since this problem apparently doesn't exist (at least not all the time) with 3DS exported animations. In any event, I'm happier with having animations minus whatever this routine is trying to accomplish than to not have them at all. :)

Luke

#10 If I recall, MS3D does not produce a ground transform so the engine ends up seg faulting at some point. You need to work around this by using your own renamed death anims, like:

dead0, dead1, etc.. You'll have to modify your scripts appropriately.

-Ed M.

#11 Ah that works superbly, and prevents the need for recompiling the code (although it does seem odd that the first transform is wrapped in the conditional and the second is not; this should be rectified in CVS if just to prevent total meltdowns for poor folks who don't trip across this thread.)

Just to lay it out for anyone reading this looking to solve the problem, the word 'death' as an animation name prefix is hard-coded in the engine causing extra code to execute.

By naming the animation(s) anything else in Milkshape and changing the script reference (found in the demo at starter.fps/server/scripts/player.cs around line 941) to match, it works great.

Thanks Ed!

Luke

#12 Wow, it took a while, but this helps to have the logic behind it, thanks.

#13 I've just hit this problem and already it looks like you guys have found a solution! I'll try this tonight when I get in.

#14 Fixed it first time. It woudl be great though if comments where placed in the native and script code to help future developers spot the problem. Or better still if the code was robust enough to handle not having the required transforms.

#15 I've just made another post regarding this issue in Maya. It seems that the only exporter currently exporting ground transform frames properly is the 3DS exporter. Both the Maya and Milkshape exporters supposedly support ground transforms, but it seems that when it comes to the death animation they fall a bit flat.

In the new Torque Show Tool Pro when I compare the death animation between the 3DS exported starter.fps orc's death animation and my Maya exported model's death animation, the only noticeable difference is that the orc has the number 59 in the GndFrm box in the sequence properties window while my model's sequence has 0 in that same box...

Does this mean that ground transforms are not being properly exported by the Maya exporter? This seems like a fairly serious bug... is the same issue happening with the Milkshape exported animations?

This topic has been discussed many, many, many, many, many, ...ugh..., many, many, many times... It seems that everyone agrees that it is an issue with the ground transforms, but it also seems that the two fixes are hacks. I think it would be very beneficial to the community if some sort of solution was implemented into HEAD so that we wouldn't have to continue to use hacks to get around this. I'll make sure to go back to all those posts and put up a reply when a solution has been implemented :)

I apologize in advance if I sound a bit annoyed... but, well, I sort of am. I love Torque, and I would probably not exist as an Indie developer without it and I do really appreciate all the hard work you guys are putting in... But wouldn't it make sense to fix some of the more serious issues with the existing engine before starting work on a spangly, shiny, new engine? Again, my apologies for the tone...

Stephane

#16 A question: when you alter your player script to edit the naming convention of the index of sequences, do you only edit the name "death" or do you also edit the index randomazation part, which defines the index list at 11 sequences??....and if this part of code isn't changed[to your number of sequences produced], when the engine hits one of these missing sequences....is this why things go bad??? Or is it that certain Nodes need to be included...ski0, and ski1 perhaps?? just inputing more observations....or the spinal column bones which are referenced with a few Bip01 names....pelvis to spine2??

...and in ShowTool Pro...I've noticed that number in Ground Transform frames too[I think, shame me for not rereading my manual], I wonder if that is the total number of ground transform 'frames', or if it the frame in which there is the gT data...???

#17 @Rex - I'm not sure exactly what the GndFrm value in Torque Show Tool Pro means... All I know is that with ground transforms being exported in Maya/Milkshape there is still no value in that box... While with the orc (which works for death animations) there is a value in that box...

I haven't edited my player script naming convention at all and I do have ski0 and ski1 in my model, but things are still going bad... Its always crashing at that one line that Kurtis Seebaldt talked about in this thread.

Again... it comes down to process of elimination and it is really just looking like the Maya exporter and the Milkshape exporter are not properly exporting ground transforms.

#18 Greetings!

From the TST Pro manual, page 67:

Quote:
GndFrm: The number of ground frames used in the sequence. Ground frames may be used to change the playback speed of an animation sequence based on distance travelled.

If that is showing up as 0 for your animation sequence in TST Pro, then it sounds like your ground transformations are not being exported at all.

You may want to ask in the MilkShape forum on how to accomplish this, or ask the author of the MilkShape exporter.

- LightWave Dave

#19 So then, David, the Death sequences of the default player, contain 59! frames of ground transform data; that would explain a bit; those death sequences certainly have the player flopping about quite a bit...I guess they're needed to keep track of the players' location in relation to the ground....

Side Note: I export thru Milkshape quite a bit, and nearly all my action sequences arrive with data in the GrdFrm field. My last 'run' attempt with 11 frames had 3 in this field.....might this be because I set a keyframe on my Root Node, BpelvisL?? Another observation, keen? skewed? let's find out, ;).........


GrndFrm in Milkshape3d

#20 @Rex - So does your death animation have '0' in the GndFrm field? If it doesn't have '0', does it work?

I have tried pretty much every setting in Maya to try and get a value other than '0' in the GndFrm field but to no avail. I am at a total loss...