Animations

[alpaca]

Well just to let you guys know: I started looking into the animation files a bit.
I already wrote a python script that can extract them from the .idx/.dat file - it seems they aren't packed or anything since Verci's old cas importer was able to import them (well they didn't work properly, but it didn't crash, either).
So what I'm planning to do right now is to figure out how the .cas files are described by leeching a bit of know-how from the cas importer :P

As for the idx file (only pack.idx):
It has a header consisting of the string "ANIM.PACKV:|", then a long 9 and then a long with the number of entries.
Each entry then consists of:

BytesVariable typeExplanation
0-3longstrlen+10 of the tag (below)
4-7longbyte offset in pack.dat
8-11longbyte length in pack.dat
12-15floatUnclear so far, often 1.0 (first four additional bytes of the strlen+10)
16-25-These are the other 6 additional bytes in the strlen+10*
strlenStringtag (qualified path for the animation)


*They seem to be 0x3F**00140014 - 0014 is 5120 as a short which sounds probable. No idea about the first two bytes.

[SigniferOne]

Just briefly, yes the old Verci script works halfway. It can extract, if you replace the title string above with the RTW version, and the animations are half-way ok, but still not 100% good. Caliban wrote a post somewhere here that the reason is that in M2 bones are weighted, whereas in RTW they weren't.


Caliban, is it a secure fact that once the animations are extracted and work properly, they don't have to be put back into the packed files again, and work using that anim_db switch you once posted?

[KnightErrant]

The bones section at the top of the .dat file has
the idle pose of the standard skeleton in the first three
floats after the null terminated ASCII string. There's 19
floats in each data section between the bone strings,
3 are the idle pose offsets, 3 probably 0.0 rotations, and
who knows for the remaining 13 floats.

Edit: Sorry, not the first three. Skip the first float after the
bone string, then the next three floats are the idle pose offsets.

[alpaca]

KE: Are you talking about the skeletons.dat? I was looking at the pack.dat :laugh4:
I got the impression we could still extract the skeletons with xidx?

Edit: By the way, don't forget ICQ XD

[KnightErrant]

Oops, my mistake, wrong .dat.:laugh4:

Edit: What does ICQ XD mean?

[alpaca]

Well I don't really know how the skeletons work at any rate.
Do they just link the bones in the .cas/.mesh files to the anims?

[KnightErrant]

Don't know, the only .cas files I've worked through are the
_idle ones in animations/engine and they're short.
They just have the idle pose for rigging the skeletons.
I was digging for where the human animations were.

[GrumpyOldMan]

Hi KE et al


Don't know, the only .cas files I've worked through are the
_idle ones in animations/engine and they're short.
They just have the idle pose for rigging the skeletons.
I was digging for where the human animations were.

I've just about finished the CAS figure to Mikshape converter, and I've already got code to convert m2tw animations to Milkshape, including the quaternion to euler changes. It shouldn't take too long (famous last words?) to do the re-convert.

The main issue is that the way the figure cas' are set up it's easier to convert to Milkshape ascii.

Cheers

GrumpyOldMan

[KnightErrant]

Awww, no fair, does this mean the adventure doesn't continue
with animations?

@alpaca
Sorry for the hijack.

[GrumpyOldMan]

Hi KE


Awww, no fair, does this mean the adventure doesn't continue
with animations?

Yes, KE, there will be more adventures, we've only just begun to convert. I finally ironed out the conversion of RTW cas files into a milkshape file with a m2tw skeleton (I'll put up a pic in the mesh thread soon). You'll be happy to know that they work ok with vanilla m2tw animations. More adventures planned
- get the milkshape animations back into cas (pass me the 4 pound hammer :laugh4: )
- once we've done that, we can look at straight converting of RTW animations to m2tw
- there's always the bogey of adding new skeletons (once we get the skeleton stuff straight in our heads, it's doable because Caliban said they rebuilt the skeletons and animations on the fly so they're not hard coded)

Lots of stuff to do yet.


@alpaca
Sorry for the hijack.

Me too

Cheers

GrumpyOldMan

[alpaca]

Haha well if you already got it figured out :laugh4:
So you already extracted the pack.dat? Why didn't you say?

Anyways, I'll have a look at the skeletons then.

Edit: By the way, does anybody have any resources on bone weigthing?

[KnightErrant]

Well I have to start learning somewhere, so I wrote an extractor
to pull the cas's out of pack.dat using the offsets in the index file.
Pulled out 30 to look at. The first 5 bytes are the header where
the first short is the number of anim frames. The other 3 bytes are
14 00 14 hex or 20 0 20. The only question is what comes first,
quaternions or pose data. I saw some 0.0 0.0 0.0 1.0 values so that
answered two things: quats come first and CA uses the {q1, q2, q3, q4}
convention where q4 is the special one. I transformed them to Euler
angle using the 321 convention and got this for the first anim frame
for CR_spear_charge.cas:


Number of animation frames: 11
Remaining header: 20 0 20
Quaternion data and maybe Euler angles (using 321)?
q1 q2 q3 q4 sum of squares yaw (deg) pitch (deg) roll (deg)
============ anim quaternion frame 0 ============
+0.2538955510 +0.1681092978 -0.0226481762 +0.9522412419 sum squs = +1.0000000095 +2.5657103993 +19.3696683429 +30.2967888994
-0.3953365684 -0.0070954142 +0.1987117827 +0.8967565298 sum squs = +0.9999999935 +21.4590405866 +8.3019773363 -46.0049588155
+0.1825654358 +0.0634186864 +0.0113932779 +0.9810800552 sum squs = +0.9999999497 +2.6276101260 +6.9081227284 +21.2413852449
+0.0005502258 +0.0181907974 -0.2293124646 +0.9731827378 sum squs = +1.0000000555 -26.5251008404 +2.0435025817 -0.4169129706
+0.0379701219 +0.0379873700 -0.0190575924 +0.9983747005 sum squs = +1.0000000050 -2.0214710134 +4.4332999853 +4.2777858328
+0.1421776563 +0.1788186878 +0.0416587740 +0.9726633430 sum squs = +1.0000000412 +8.0495681889 +19.6342635762 +18.0275697089
-0.2416000813 -0.3342688680 +0.0259645525 +0.9106149077 sum squs = +0.9999999436 +15.0756420060 -36.6006764153 -34.7298720077
+0.0000000000 +0.0000000000 +0.0000000000 +1.0000000000 sum squs = +1.0000000000 +0.0000000000 +0.0000000000 +0.0000000000
+0.0000000000 +0.0000000000 +0.0000000000 +1.0000000000 sum squs = +1.0000000000 +0.0000000000 +0.0000000000 +0.0000000000
-0.0013705824 -0.0047476389 -0.0055176513 +0.9999725819 sum squs = +1.0000000275 -0.6315546125 -0.5448992324 -0.1540581944
-0.0002179843 -0.0194163416 -0.3695584238 +0.9290046096 sum squs = +1.0000000350 -43.3998593387 -2.0766736500 +0.7995938917
-0.0381897017 -0.6430811286 -0.0234443955 +0.7644858360 sum squs = +1.0000000244 +4.4177386253 -80.0780864235 -9.4322343545
+0.0172815081 +0.1676424295 -0.1667936444 +0.9714819789 sum squs = +0.9999999898 -19.7157479464 +19.3591213839 -1.3571896291
-0.0011378765 +0.0047027008 +0.0202233475 +0.9997837543 sum squs = +0.9999999494 +2.3170456268 +0.5414182810 -0.1194701201
-0.2264718562 -0.1660457850 +0.4406757355 +0.8526102304 sum squs = +1.0000000133 +56.0534307300 -4.7922679610 -32.3030476656
-0.0418538116 +0.8028841019 +0.0247014631 +0.5941508412 sum squs = +1.0000000070 +7.4251721953 +72.9670051832 +1.9701113044
+0.0022718122 +0.0688987225 +0.0323999561 +0.9970948100 sum squs = +1.0000000124 +3.7581457004 +7.8887411361 +0.5203097663
-0.3605583012 -0.4344316721 -0.1733115017 +0.8069881797 sum squs = +0.9999999651 +3.4140766971 -55.7042659859 -49.9541032693
+0.2243260294 +0.1274575591 +0.0513146892 +0.9647793770 sum squs = +1.0000000404 +9.2202763455 +12.8802680946 +27.2221190368
-0.0548719205 -0.0131644774 +0.1631041616 +0.9849938154 sum squs = +1.0000000151 +18.8304236382 -0.4603295875 -6.4533948925
============ anim quaternion frame 1 ============


The next block should be the position or pose data so its done as
triples:


Pose data:
================== anim pose frame 0 ============
+0.0000000000 +0.0000000000 +0.0000000000
+0.0952388272 +0.0007522855 -0.0000000016
+0.0225613043 -0.4644488990 +0.0143959904
+0.0241626762 -0.3995066285 -0.0316338763
-0.0000000072 +0.2124620080 +0.0000000010
-0.0002945314 +0.2115578204 +0.0000000317
-0.0000617032 +0.2349731475 +0.0000000667
+0.0003562687 +0.0108105456 -0.0034470414
+0.0016836965 +0.1178482845 -0.0744606182
+0.0132546313 +0.1300114095 -0.0273839347
+0.1653589308 -0.0517836995 +0.0034832763
+0.3022064567 +0.0111386590 -0.0137692019
+0.2838370204 -0.0030556649 +0.0263375491
-0.0102220755 +0.1300113946 -0.0273839198
-0.1678023189 -0.0517838039 +0.0034833569
-0.3021733761 +0.0111954454 -0.0144314468
-0.2838012874 -0.0032004488 +0.0267044865
-0.0952387974 +0.0007523632 +0.0000000220
-0.0216093566 -0.4641438425 +0.0230784863
-0.0250774939 -0.3986378312 -0.0406115353
================== anim pose frame 1 ============


This looks right because it matches the standard skeleton:


0.0 , 0.0 , 0.0
-0.095239 , 0.007520 , 0.0
-0.022561 , -0.464449 , 0.014396
-0.024163 , -0.399507 , -0.031634
0.0 , 0.212462 , 0.0
0.000295 , 0.211558 , 0.0
0.000062 , 0.234973 , 0.0
-0.000356 , 0.010810 , -0.003447
-0.001684 , 0.117848 , -0.074461
-0.013255 , 0.130011 , -0.027384
-0.165359 , -0.051784 , 0.003483
-0.302206 , 0.011139 , -0.013769
-0.283837 , -0.003056 , 0.026338
0.010222 , 0.130011 , -0.027384
0.167802 , -0.051784 , 0.003483
0.302173 , 0.011195 , -0.014431
0.283801 , -0.003200 , 0.026704
0.095239 , 0.000752 , 0.0
0.021609 , -0.464144 , 0.023078
0.025077 , -0.398638 , -0.040612

(Don't worry about the signs on the x values, The standard skeleton
was made to work with Milkshape so there's always to x -> -x transform
for that.)

So far, so good. The problem is I still have 76 floats left over that look like
this:


What the heck are these data:
We have 76 leftover floats
+0.0000000000 +0.0000000000 +0.0000000000
+0.0000000000 +0.0000000000 +0.0000000000
+0.0000000000 +0.0000000000 +0.0000000000
+0.0000000000 +0.0000000000 +0.0000000000
+0.0000000000 +0.0000000000 +0.0000000000
+0.0000000000 +0.0000000000 +0.0000000000
+0.0000000000 +0.0000000000 +0.0000000000
+0.0000000000 +0.0000000000 +0.0000000000
+0.0000000000 +0.0000000000 +0.0000000000
+0.0000000000 +0.0000000000 +0.0000000000
+0.0000000000 +0.0000000000 +0.0000000000
+0.0000000000 +0.0000000000 +0.0000000000
+0.0145724751 +0.0491957590 +0.0002147975
+0.0301976539 +0.1019454375 +0.0004450644
+0.0437174141 +0.1475874335 +0.0006442972
+0.0519736372 +0.1754599810 +0.0007659923
+0.0510471202 +0.1819434315 +0.0005802182
+0.0442738384 +0.1494659334 +0.0006524611
+0.0348668732 +0.0312059894 +0.0020629363
+0.0234865602 -0.0744927898 +0.0031001847
+0.0119119827 -0.0558995418 +0.0018968056
+0.0000000000 +0.0000000000 +0.0000000001
+0.5000000000 +0.0000000000 +0.0000000000
+0.0000000000 +0.0000000001 +0.0000000000
+0.0000000000 +0.0000000000 +0.0000000000
+0.0000000000


For a big 4.5 second animation like CR_spear_die_galloping.cas it's
worse, I have 556 floats left over, mostly zeroes or repeating values
but no idea what they are. The pose data on the last anim frame
still looks ok, I don't think I've slipped data by miscalculating the
frame offsets.

Another GrumpyOldMan question is this:

If I have my rotation matrix parametrized by the quaternions as



_ _
| |
| q1^2 - q2^2 - q3^2 + q4^2 2 * ( q1*q2 + q3*q4 ) 2 * ( q1*q3 - q2*q4 ) |
| |
| 2 * ( q1*q2 - q3*q4 ) -q1^2 + q2^2 - q3^2 + q4^2 2 * ( q2*q3 + q1*q4 ) |
R = | |
| 2 * ( q1*a3 + a2*q4 ) 2 * ( q2*q3 - q1*q4 ) -q1^2 - q2^2 + q3^2 + q4^2 |
| |
|_ _|



and similarly for Euler's


_ _
| |
| cos(psi) cos(theta) sin(psi) cos(theta) -sin(theta) |
| |
R = | - - cos(theta) sin(phi) |
| |
| - - cos(theta) cos(phi) |
|_ _|


is that Mete's convention or is it one of the other 11 sets?

[GrumpyOldMan]

Hi KE

I didn't quote your reply, so I hope I get everything clear for you.

The next lot of floats after the skeleton are global position vectors for the bones, so number of frames by number of bones by x, y, z. (I get a lot more than 76 floats here :dizzy2: are you sure you just haven't printed off the first three float values of each frame's worth??). Although the local positon value hasn't changed, you have to remember this is preprocesed to plug into the engine. The only significant one to worry about is the y value for the first bone this give the movement perpendicular to the ground plane.

Next there is number of frames by x and z 'incremental' movement for the first bone (pelvis). This shows you how much the figure moves parallel to the ground plane each frame.

Below is the function I'm using for Quat to Euler conversion :-



QuatToEuler(a4,a1,a2,a3);data read in from original file - a1,a2,a3,a4


Function QuatToEuler(w#,x#,y#,z#)
Local sint#, cost#, sinv#, cosv#, sinf#, cosf#
Local cost_temp#

sint = (2 * w * y) - (2 * x *z)
cost_temp = 1.0 - (sint * sint)

If Abs(cost_temp) > QuatToEulerAccuracy
cost = Sqr(cost_temp)
Else
cost = 0
EndIf

If Abs(cost) > QuatToEulerAccuracy
sinv = ((2 * y * z) + (2 * w * x)) / cost
cosv = (1 - (2 * x * x) - (2 * y * y)) / cost
sinf = ((2 * x * y) + (2 * w * z)) / cost
cosf = (1 - (2 * y * y) - (2 * z * z)) / cost
Else
sinv = (2 * w * x) - (2 * y * z)
cosv = 1 - (2 * x * x) - (2 * z * z)
sinf = 0
cosf = 1
EndIf

; Generate the output rotation
roll# = -ATan2(sinv, cosv) ; inverted due to change in handedness of coordinate system
pitch# = ATan2(sint, cost)
yaw# = ATan2(sinf, cosf)
End Function

Don't worry about the QuatToEulerAccuracy, I thought it was a bit fancy-shmancy, so I just deleted the constant but haven't updated the function yet. Read it as '0'.

I wrote this code a while ago and it exports the animation but facing in the -z direction. Shouldn't take much to fix but the Menu/Tools/Mirror All fixes the orientation.

Now the results come out as calculated roll equalling pitch, calculated pitch equalling yaw and calculated yaw equalling negative roll. I've never got around to cleaning it up as long as I was getting the right numbers out:embarassed: :embarassed: .

If you want to take the language for a shareware ride I can pass the code onto you.

Cheers

GrumpyOldMan

[GrumpyOldMan]

Hi alpaca



Edit: By the way, does anybody have any resources on bone weigthing?

You could have a look at

http://www.chumba.ch/chumbalum-soft/forum/showpost.php?p=128784&postcount=1

which is Mete from Milkshape's very basic instruction on using the bone weight editors. Have a look through the forum, I seem to remember there being other posts (by Wes H??) on working with bone weights on Sims2 figures.

Cheers

GrumpyOldMan

[Ashdnazg]

I couldn't see if this was seen earlier, so I post this anyway.
I had a wee look in Verc's script, and the second short in the header is the number of bones.
About the fifth byte, I think he actually skipped it.

[KnightErrant]

@GOM
Python is being unkind to me tonight and I can't find
my bug yet, but I still wanted to clarify two things:

(1) Went through the quaternion to yaw, pitch, and roll
and I think I'm following the same conventions. Meaning I
followed my quat vs euler matrices and worked through your
QuatToEuler function and I arrive at the same ATan2
relations for the angles. So I think
your code for rotations x, y, z -> roll, pitch, yaw is right
without having to interchange roll->pitch, pitch->yaw, and
yaw->roll. Does Milkshape really require this (excluding the roll
minus sign)?

(2) Byte counts: My example last night was for the CR_spear_charge.cas
which is a small one (7 KB) . If I count bytes this way


5 - header
nframes*NBONES*4*4 - quaternion block
nframes*NBONES*4*3 - pose block
nframes*4*3 - global block (only bone_pelvis)
nframes*4*3 - relative block (only bone_pelvis)
40 final bytes, or 10 float - leftovers


Last 8 bytes always seem to be FF FF 0F 00 00 00 00 00, so maybe a
terminating signature.

This seems to square with the bytelength in the index file so I think
this is ok. For 11 anim frames I get 33+33+10=76 floats that I had last
night. So the global block and the relative block track the movement
of the single bone_pelvis to give the overall traversal of the model, and
the quaternions give the relative animation?

The game then seems to be, merge a .cas with a .ms3d and write the
anim stuff to the joint section, suitably merging the global and relative to
the pose data, since Milkshape doesn't have extra places for this, and
put the transformed quats into the rotation angles part. Reverse process
is separate the global and relative from the position vectors, reconvert
angles back to quaternions and write out a new .cas.

Is the jerky nature of the unpacked .cas files simply that the number of
bones in the standard skeleton for M2TW is different from RTW so the anim
frames aren't coming out right? Caliban has hinted that someone could
simply (simply?) change the MaxScript script to fix this but no one has
stepped to the plate.:dizzy2:

Back to fighting Python, I can see the data I want in xvi32 put it won't print
out for me. This is finally the end for me, it's easier to simply read the data
in hex than it is to try to print it out.

[GrumpyOldMan]

@KE

I've just got to close down for a while before I throw the mouse through the monitor, getting very sick of looking at hex for RTW cas files.

It's terrible to see two old addicts in the clutches of their vice, isn't it?:laugh4: :laugh4: :laugh4: :laugh4:

The jerky movement is indeed just a matter of trying to cram RTW rotations onto a m2tw skeleton, it just requires a simple renumbering operation I imagine within the plugin/script - disregarding the cloak bones and taking into account the clavicles, jawbone and eyebrow.

Cheers

GrumpyOldMan

[KnightErrant]

I know the feeling... I think I'll slow down on anims and finish
writing instead. Hate leaving loose strings about. Thanks for
the info re jerky animations, that's what I thought from Caliban's
comments.

[SigniferOne]

By the way, Verc's animation script, though fantastic, was buggy at least in two respects:

1) it produced flickering animations for certain skeletons, wherein a bone would very quickly rotate 180 degrees back and forth. Sometimes hoplites would flicker their shields, and sometimes horses would flicker with their legs.

2) it could not modify most turn animations. The actual turn often proceeded in-game smooth enough, but the soldier would instantly turn back to his original position, and then turn back to his new direction again, and then back, etc etc. He couldn't complete turning back and forth, and you would have to order the entire unit to go elsewhere, upon which he'd stop and run with the rest of his unit. It's almost as if the script didn't register that the angle of the soldier's orientation was changed to the desired angle, and the engine kept trying to turn him; or it could be something else.

[alpaca]

C'mon guys, no turning back now:whip:

[KnightErrant]

Naw, not turning back, just finishing up things before the plunge.
Found out a little more today. The 8 floats before the final 8 signature
bytes follow this form:

first is the length of time of the animation, e.g. an 11 frame animation
is 0.5 seconds (1/20 of a second per frame, first frame starts at 0.0), a
91 frame animation is 4.5 seconds, etc.

second SEEMS to be the maximum excursion of all the entries in the relative
block or, same thing, the maximum excursion of bone_pelvis.

third, fourth, and fifth are just the last frame of the relative positions,
sort of like a registration position.

sixth, seventh, and eighth: no clue. They're not the same as any other
entry when they're non-zero. For the stationary animations (non walking,
running) they're usually zeros.

Anyway, just finishing up a little utility to convert binary .cas files to an
editable text form that can be converted back to .cas by the same
converter. Not the way I would want to do it, but it might be fun for
people to play with until the Milkshape stuff is sorted out. Just need to
add a script to turn Euler angles into quaternions that people can use
to change entries.

[GrumpyOldMan]

Hi KE

Here is some more code to work with quats and eulers:-


; Change these constants if you notice slips in accuracy
Const QuatToEulerAccuracy# = 0.001
Const QuatSlerpAccuracy# = 0.0001

;convert a Rotation to a Quat
Function EulerToQuat(pitch#,yaw#,roll#)
;NB roll is inverted due to change in handedness of coordinate systems
Local cr# = Cos(-roll/2)
Local cp# = Cos(pitch/2)
Local cy# = Cos(yaw/2)
Local sr# = Sin(-roll/2)
Local sp# = Sin(pitch/2)
Local sy# = Sin(yaw/2)
;These variables are only here to cut down on the number of multiplications
Local cpcy# = cp * cy
Local spsy# = sp * sy
Local spcy# = sp * cy
Local cpsy# = cp * sy
;Generate the output quat
w# = cr * cpcy + sr * spsy
vectorx = sr * cpcy - cr * spsy
vectory = cr * spcy + sr * cpsy
vectorz = cr * cpsy - sr * spcy
End Function

; convert a Quat to a Rotation
Function QuatToEuler(quatx#,quaty#,quatz#,quatw#)
Local sint#, cost#, sinv#, cosv#, sinf#, cosf#
Local cost_temp#
sint = (2 * quatw * quaty) - (2 * quatx * quatz)
cost_temp = 1.0 - (sint * sint)
If Abs(cost_temp) > QuatToEulerAccuracy
cost = Sqr(cost_temp)
Else
cost = 0
EndIf
If Abs(cost) > QuatToEulerAccuracy
sinv = ((2 * quaty * quatz) + (2 * quatw * quatx)) / cost
cosv = (1 - (2 * quatx * quatx) - (2 * quaty * quaty)) / cost
sinf = ((2 * quatx * quaty) + (2 * quatw * quatz)) / cost
cosf = (1 - (2 * quaty * quaty) - (2 * quatz * quatz)) / cost
Else
sinv = (2 * quatw * quatx) - (2 * quaty * quatz)
cosv = 1 - (2 * quatx * quatx) - (2 * quatz * quatz)
sinf = 0
cosf = 1
EndIf
;Generate the output rotation
vectorx = -ATan2(sinv, cosv) ; inverted due to change in handedness of coordinate system
vectory = ATan2(sint, cost)
vectorz = ATan2(sinf, cosf)
End Function

;use this to interpolate between quaternions
Function QuatSlerp(Ax#,Ay#,Az#,Aw#,Bx#,By#,Bz#,Bw#,t#)
Local scaler_w#, scaler_x#, scaler_y#, scaler_z#
Local omega#, cosom#, sinom#, scale0#, scale1#
cosom = Ax * Bx + Ay * By + Az * Bz + Aw * Bw
If cosom <= 0.0
cosom = -cosom
scaler_w = -Bw
scaler_x = -Bx
scaler_y = -By
scaler_z = -Bz
Else
scaler_w = Bw
scaler_x = Bx
scaler_y = By
scaler_z = Bz
EndIf
If (1 - cosom) > QuatSlerpAccuracy
omega = ACos(cosom)
sinom = Sin(omega)
scale0 = Sin((1 - t) * omega) / sinom
scale1 = Sin(t * omega) / sinom
Else
;Angle too small: use linear interpolation instead
scale0 = 1 - t
scale1 = t
EndIf
vectorx# = scale0 * start\x + scale1 * scaler_x
vectory# = scale0 * start\y + scale1 * scaler_y
vectorz# = scale0 * start\z + scale1 * scaler_z
w# = scale0 * start\w + scale1 * scaler_w
Return w#
End Function

; result will be the same rotation as doing q1 then q2 (order matters!)
Function MultiplyQuat#(Ax#,Ay#,Az#,Aw#,Bx#,By#,Bz#,Bw#)
Local a#, b#, c#, d#, e#, f#, g#, h#
a = (Aw + Ax) * (Bw + Bx)
b = (Az - Ay) * (By - Bz)
c = (Aw - Ax) * (By + Bz)
d = (Ay + Az) * (Bw - Bx)
e = (Ax + Az) * (Bx + By)
f = (Ax - Az) * (Bx - By)
g = (Aw + Ay) * (Bw - Bz)
h = (Aw - Ay) * (Bw + Bz)
w# = b + (-e - f + g + h) / 2
vectorx# = a - ( e + f + g + h) / 2
vectory# = c + ( e - f + g - h) / 2
vectorz# = d + ( e - f - g + h) / 2
Return w#
End Function

Should be enough to fill in your weekend :laugh4: :laugh4:

edit :- If you haven't looked already

http://www.gamasutra.com/features/19980703/quaternions_01.htm ,

most of the code is based on this.

Cheers

GrumpyOldMan

[KnightErrant]

Many thanks for the references, most of the quaternion stuff I've
got is from memos at work. There's a group that uses them for attitude
control for reentry vehicles in simulations which doesn't really
translate easily to moving bones around. Oh, it did hit me yesterday about
the cyclic permutation for the yaw, pitch, and roll, of course Mete's
convention has the y-axis as the vertical. D'oh!

Edit: Went and joined, lots of refs on quaternions in gaming. Even a few
physics ones!

[KnightErrant]

Well, I tested unpacking all the cas files and found examples
violating almost all of the rules from a couple posts back.
The first of the last eight floats is the animation time in
seconds. The header in descr_skeletons.dat say there will always
be an odd number of frames so this number will always be a multiple
of a tenth of a second. Otherwise the remaining seven floats I have
no rules for.

The header bytes aren't always 20 0 20 (14 00 14 hex), they have lots
of variations especially for the stratmap anims. The final 8 bytes aren't
always FF FF 0F 00 00 00 00 00 they have lots of variations too.
Here's a chunk with some stratmap examples from the extraction log:


31 20 20 data/animations/MTW2_Swordsman/MTW2_Swordsman_at_mid_c_stab_v1_s1_slashrl_fail.cas 39586546 18149 255 255 15 0 0 0 0 0
47 20 20 data/animations/MTW2_Swordsman/MTW2_Swordsman_at_mid_c_stab_v1_s1_slashrl_success.cas 39604695 27493 255 255 15 0 0 0 0 0
23 20 20 data/animations/MTW2_Swordsman/MTW2_Swordsman_at_overhead_c_stab_fail.cas 39632188 13477 255 255 15 0 0 0 0 0
29 20 20 data/animations/MTW2_Swordsman/MTW2_Swordsman_at_overhead_c_stab_success.cas 39645665 16981 255 255 15 0 0 0 0 0
55 20 1 data/animations/MTW2_Swordsman/MTW2_Swordsman_basepose.cas 39662646 19625 1 0 0 0 0 0 0 0
41 20 20 data/animations/MTW2_Swordsman/MTW2_Swordsman_charge_jump_attack.cas 39682271 23989 255 255 15 0 0 0 0 0
99 20 1 data/animations/New_Crew/Crew_Stand_to_Wide_Push.CAS 39706260 35289 1 0 0 0 0 0 0 0
25 20 1 data/animations/New_Crew/Crew_Wide_Push.CAS 39741549 8945 1 0 0 0 0 0 0 0
39 20 1 data/animations/New_Crew/Crew_Wide_Push_to_Crew_Stand.CAS 39750494 13929 1 0 0 0 0 0 0 0
67 2 1 data/animations/New_Swordman/Weapon/Sword_Default.CAS 39764423 4601 1 0 0 0 0 0 0 0
59 19 1 data/animations/SM_D01 Diplomat unselected idle 01.cas 39769024 20105 1 0 0 0 0 0 0 0
51 19 1 data/animations/SM_D01 Diplomat unselected idle 02.cas 39789129 17385 1 0 0 0 0 0 0 0
45 19 1 data/animations/SM_D01 Diplomat unselected idle 03.cas 39806514 15345 1 0 0 0 0 0 0 0
21 19 1 data/animations/SM_D03 Diplomat selected idle.cas 39821859 7185 1 0 0 0 0 0 0 0
25 19 1 data/animations/SM_D06 Diplomat walk loop.cas 39829044 8545 1 0 0 0 0 0 0 0
35 19 1 data/animations/SM_D11 Diplomat standing to stepping backwards.cas 39837589 11945 1 0 0 0 0 0 0 0
35 19 1 data/animations/SM_D12 Diplomat stepping backwards loop.cas 39849534 11945 1 0 0 0 0 0 0 0
25 19 1 data/animations/SM_D13 Diplomat stepping backwards to stand.cas 39861479 8545 1 0 0 0 0 0 0 0
23 19 1 data/animations/STRAT LID_08_Stand 2 90 right.cas 39870024 7865 1 0 0 0 0 0 0 0
23 19 1 data/animations/STRAT LID_09_Stand 2 90 left.cas 39877889 7865 1 0 0 0 0 0 0 0
107 19 19 data/animations/Stratmap_Assassin/Strat_Assassin_assassinate.cas 39885754 59537 255 255 7 0 0 0 0 0
25 19 1 data/animations/Stratmap_Assassin/Strat_Assassin_basepose.cas 39945291 8545 1 0 0 0 0 0 0 0
39 19 19 data/animations/Stratmap_Assassin/Strat_Assassin_die_backward_1.cas 39953836 21729 255 255 7 0 0 0 0 0
83 19 19 data/animations/Stratmap_Assassin/Strat_Assassin_die_forward_1.cas 39975565 46193 255 255 7 0 0 0 0 0
41 19 19 data/animations/Stratmap_Assassin/Strat_Assassin_no_mp_idle.cas 40021758 22841 255 255 7 0 0 0 0 0
15 19 19 data/animations/Stratmap_Assassin/Strat_Assassin_no_mp_to_stand_A.cas 40044599 8385 255 255 7 0 0 0 0 0
131 19 19 data/animations/Stratmap_Assassin/Strat_Assassin_sabotage.cas 40052984 72881 255 255 7 0 0 0 0 0
33 19 19 data/animations/Stratmap_Assassin/Strat_Assassin_selected.cas 40125865 18393 255 255 7 0 0 0 0 0
41 19 19 data/animations/Stratmap_Assassin/Strat_Assassin_stand_A_idle.cas 40144258 22841 255 255 7 0 0 0 0 0
11 19 19 data/animations/Stratmap_Assassin/Strat_Assassin_stand_A_idle_selected.cas 40167099 6161 255 255 7 0 0 0 0 0
111 19 19 data/animations/Stratmap_Assassin/Strat_Assassin_stand_A_lf_idle_1.cas 40173260 61761 255 255 7 0 0 0 0 0
81 19 19 data/animations/Stratmap_Assassin/Strat_Assassin_stand_A_lf_idle_2.cas 40235021 45081 255 255 7 0 0 0 0 0
85 19 19 data/animations/Stratmap_Assassin/Strat_Assassin_stand_A_lf_idle_3.cas 40280102 47305 255 255 7 0 0 0 0 0
29 19 19 data/animations/Stratmap_Assassin/Strat_Assassin_stand_A_to_no_mp.cas 40327407 16169 255 255 7 0 0 0 0 0
25 19 19 data/animations/Stratmap_Assassin/Strat_Assassin_stand_A_to_walk.cas 40343576 13945 255 255 7 0 0 0 0 0
59 19 19 data/animations/Stratmap_Assassin/Strat_Assassin_stand_A_to_walk_backward.cas 40357521 32849 255 255 7 0 0 0 0 0
33 19 19 data/animations/Stratmap_Assassin/Strat_Assassin_stand_A_turn_90_ccw.cas 40390370 18393 255 255 7 0 0 0 0 0
33 19 19 data/animations/Stratmap_Assassin/Strat_Assassin_stand_A_turn_90_cw.cas 40408763 18393 255 255 7 0 0 0 0 0
35 19 19 data/animations/Stratmap_Assassin/Strat_Assassin_unselected.cas 40427156 19505 255 255 7 0 0 0 0 0
33 19 19 data/animations/Stratmap_Assassin/Strat_Assassin_walk.cas 40446661 18393 255 255 7 0 0 0 0 0
27 19 19 data/animations/Stratmap_Assassin/Strat_Assassin_walk_backward.cas 40465054 15057 255 255 7 0 0 0 0 0
29 19 19 data/animations/Stratmap_Assassin/Strat_Assassin_walk_backward_to_stand_A.cas 40480111 16169 255 255 7 0 0 0 0 0
25 19 19 data/animations/Stratmap_Assassin/Strat_Assassin_walk_to_stand_A.cas 40496280 13945 255 255 7 0 0 0 0 0
55 19 19 data/animations/Stratmap_Diplomat/Strat_Diplomat_backward_1.cas 40510225 30625 255 255 7 0 0 0 0 0
21 19 1 data/animations/Stratmap_Diplomat/Strat_Diplomat_basepose.cas 40540850 7185 1 0 0 0 0 0 0 0
105 19 19 data/animations/Stratmap_Diplomat/Strat_Diplomat_conduct_diplomacy.cas 40548035 58425 255 255 7 0 0 0 0 0
67 19 19 data/animations/Stratmap_Diplomat/Strat_Diplomat_forward_1.cas 40606460 37297 255 255 7 0 0 0 0 0
41 19 19 data/animations/Stratmap_Diplomat/Strat_Diplomat_no_mp_idle.cas 40643757 22841 255 255 7 0 0 0 0 0


The header and trailers are in decimal and I'm showing the three header
bytes as a short and a byte so 20 0 20 is shown as 20 20.

I modified two .cas files for MTW2_Spear and tried putting them in game
using the no_animdb=1 and no_animdb=true under [util] in my cfg file
under the assumption it was like the io_filefirst switch, i.e. only put in
modified files under /data/animations. No joy. Thinking it might be an
all or nothing I put the whole unpacked animations directory and
renamed pack.dat and pack.idx. This just crashed. That's all the experiments
so far.

Edit: The .evt event files referred to in descr_skeleton.txt aren't in pack.dat
so is it crashing because they're not there? Couldn't find them by hexing through
events.dat, that's related to other sound events.

[SigniferOne]

Erf, the .evt files caused a major problem in RTW also, and ultimately led to downfall of all attempts by CA helpers to allow us to keep animations unpacked. They always had to be packed back into the files, or else the game would crash. (Editing the animations and then stuffing them back into pack files was only way of modding them.) Maybe Caliban can help us there.

[KnightErrant]

Ahh, thanks for that info. Reading zxiang1983's thread has me thinking
re-packing is the only way to get this to work too. Kind of ugly if that's
the only way, though.:no:

[KnightErrant]

OK, documentation is out of the way. Back to the fun stuff.
Wrote an animmerge script to combine a stock ms3d mesh with
a cas file. Here's the walk animation in Milkshape:

https://img248.imageshack.us/img248/7657/moddedaniminmilshapeap1.th.jpg (https://img248.imageshack.us/my.php?image=moddedaniminmilshapeap1.jpg)

EDIT: Forgot the significant part, the shields held up is done by changing the animations in Milkshape.

and also the celebration .cas in Milkshape:

https://img248.imageshack.us/img248/3282/celebrateit1.th.jpg (https://img248.imageshack.us/my.php?image=celebrateit1.jpg)


From here you use the animextract utility to extract to a .cas to put in
game as:

https://img441.imageshack.us/img441/739/animexperimentbz4.th.jpg (https://img441.imageshack.us/my.php?image=animexperimentbz4.jpg)

EDIT: These are the shields held up in-game.

NOTE This ain't right, everybody has become left-handed. Not that I mind, I'm
left-handed myself.

Unresolved Problems:

(1) Does no_animdb=1 work? PM into Caliban hasn't been answered.
Can't unpack skeleton.dat into the /animations directory because OS constraints don't allow a file without an extension to have the same
name as a directory. (Repeating xziang1983 here, been down this road.)

(2) Unpack in a higher directory? Maybe, haven't tried this.

(3) Unpack in a lower directory? Same answer, try later.

(4) Repacking the pack isn't that bad. Live with it.

(5) Maybe the TYPE files have an implied extension we just don't know
about. This would be nice but we need information.

(6) What the heck is the global data? I just saved it in the materials comment
section but need to know what it really is. Also the mystery 8 floats at
the end, also written into the materials comment section.

(7) Outside the bounds, but the TYPE files (using the language of
descr_skeleton.txt) have bone info in them, can these be modded
to change the sizes of units re Bwian's question in the mesh thread?

[alpaca]

Haha those sergeants are really screwed :laugh4:
The arms look weird... hmm, maybe the game saves some bone positions you didn't export correctly?

[KnightErrant]

I just don't know how to use Milkshape. The verts didn't
move with the joints when I edited the keyframes. Anyway,
just an experiment for repacking and putting modded cas's
back in game.

Got a reply from Caliban. He showed me a .jpg of his /animations
directory. Could not see from that if the type files were unpacked
there or not but the .evt files are definately there so they need to
be found and unpacked.

I asked for two experiments: try searching for navy_strat*.* and
fs_camel*.*. If these don't turn up any files then skeletons.dat
isn't meant to be unpacked and the question should be settled.

I've been looking at the data at the top of the type files
before it gets to the animation families and the standard skeleton rig is
in there. These could probably be modded to make custom
animations for re-rigged figures, i.e. like dwarves etc., if the engine
will accept more entries in skeletons.dat and skeletons.idx.

[Casuir]

Search in the skeleton.dat? Not sure if I follow you right here but if your looking for animations in there with this as part of the filename you wont find them, however the animations in the descr_skeletons file under the fs_camel and strat_navy all reference cas's are in the dat. Sorry if I'm not with you here, having trouble following this

About the evt files, looking at one of the ones that's not packed theres reference to anim_cannon_creak or similar, events.dat has the same text followed by paths for relevant sounds. Looking around a bit in there theres stuff like anim_archer_aim which in turn corresponds to text in the skeleton.dat at the archers animations. Possible they're packed in here?

[GrumpyOldMan]

Hi KE et al




https://img441.imageshack.us/img441/739/animexperimentbz4.th.jpg (https://img441.imageshack.us/my.php?image=animexperimentbz4.jpg)

EDIT: These are the shields held up in-game.

NOTE This ain't right, everybody has become left-handed. Not that I mind, I'm
left-handed myself.

Ahh, you're a firm but cruel drill sergeant, making your men dislocate their shoulders just so they reverse their arms and pretend to be The Queens Own Left Handed Regiment :laugh4: :laugh4: - specialists in guarding the left flank!!:laugh4: :laugh4: . My guess is that you've misplaced the axes conversion x*-1 somewhere.


Unresolved Problems:

(1) Does no_animdb=1 work? PM into Caliban hasn't been answered.
Can't unpack skeleton.dat into the /animations directory because OS constraints don't allow a file without an extension to have the same
name as a directory. (Repeating xziang1983 here, been down this road.)

Nope, been playing with this, no_animdb is not available in the retail version so we'll have to pack. With the skel name and folder conflicts, my thoughts are that the skeleton names are just handles so if we modify them by the additon of "_skl" and consistently use this across all the relevant files (modeldb,etc) it should take away this bugbear


(2) Unpack in a higher directory? Maybe, haven't tried this.

(3) Unpack in a lower directory? Same answer, try later.

The retail game seems to just run off the idx/dat files, unless the file name and folder conflicts are causing the game to crash


(4) Repacking the pack isn't that bad. Live with it.

Agreed, it's not too much of a price to pay


(5) Maybe the TYPE files have an implied extension we just don't know
about. This would be nice but we need information.

If you have a look at the calls to the skeletons in modeldb just the normal name is used, if they were it would have to be hardcoded but it doesn't help us with name and folder conflicts.


(6) What the heck is the global data? I just saved it in the materials comment
section but need to know what it really is. Also the mystery 8 floats at
the end, also written into the materials comment section.

Once I lash myself into a frenzy of documentation completion (hardest part for me) for the RTW CAS to M2TW converter, I'll go back and have another look at the animation files and tie down the loose ends.


(7) Outside the bounds, but the TYPE files (using the language of
descr_skeleton.txt) have bone info in them, can these be modded
to change the sizes of units re Bwian's question in the mesh thread?

I'm pretty sure that we can modify skeletons adding, moving and rescaling bones as long as we remember tha the engine is looking for various flags for animation ie bone_Rhand, saddle, etc

Cheers

GrumpyOldMan

[KnightErrant]

Yep, it was a missed x -> -x in the animextract that did the
parity inversion on my guys. I was so careful to take these
OUT of the animmerge. I'll do some surveying on the cas's
to see how the globals and final floats vary. It is an addiction,
good times! :laugh4:

Edit: Read up a little on animating, better example of raised shields
with the MTW2_Spear_walk.cas.

https://img184.imageshack.us/img184/5917/myarmoredspearanimby2.th.jpg (https://img184.imageshack.us/my.php?image=myarmoredspearanimby2.jpg)

[GrumpyOldMan]

Hi KE


Yep, it was a missed x -> -x in the animextract that did the
parity inversion on my guys. I was so careful to take these
OUT of the animmerge. I'll do some surveying on the cas's
to see how the globals and final floats vary. It is an addiction,
good times! :laugh4:

Edit: Read up a little on animating, better example of raised shields
with the MTW2_Spear_walk.cas.

https://img184.imageshack.us/img184/5917/myarmoredspearanimby2.th.jpg (https://img184.imageshack.us/my.php?image=myarmoredspearanimby2.jpg)

Aw shucks, I kinda miss those sinister left handers :laugh4: :laugh4:

I've gone back and revisited the anim files and this is what I've dug out so far


Cas Anim format

Short - Num_Frame

short - Num_bone

num_frame * num_bone * float*4 (Quaternion rotations)

num_frame * num_bone * float*3 (local positon data - Pelvis in relation to Root Node ie height off ground, others unchanged from rest positions)

num_frame * float*2 (x and incremental z movement for Root Node)

2 * float (0?)

num_frame * float (approximate absolute z position of Root Node but in reverse order compared to animation ??)

num_frame * float *3 (absolute position of root node and pelvis height)


I'll have a look at the rest later.

Cheers

GrumpyOldMan

[KnightErrant]

Aargh, of course, missed that completely. ~:doh: I guess I don't
think in hex after all. So the 14 00 14 in the header after the initial short
count of frames is the bone count for what gets animated.
The variants I saw must have been strat map units which don't
have 20 animated bones... Got a better clue for looking at things
now, many thanks.:fortune:

[Ashdnazg]

I couldn't see if this was seen earlier, so I post this anyway.
I had a wee look in Verc's script, and the second short in the header is the number of bones.
About the fifth byte, I think he actually skipped it.


Aargh, of course, missed that completely. I guess I don't
think in hex after all. So the 14 00 14 in the header after the initial short
count of frames is the bone count for what gets animated.
The variants I saw must have been strat map units which don't
have 20 animated bones... Got a better clue for looking at things
now, many thanks.

Thank you for ignoring my posts :D

[KnightErrant]

@Ashdnazg
You're absolutely right, I apologize. Went back and looked at
your post and there's the information staring me in the face.:embarassed:
I was so focused on fixing my script then my brain just wasn't
accepting new inputs. Please post any info you have; I promise
I'll pay better attention next time.

@GrumpyOldMan
Ok, got a reply from Caliban. He did the two experiments and none
of those "type files" or "skel files" exist with his unpacked setup.
So I think skeleton.dat/idx is supposed to stay packed and those
names are just look-up handles like you said. Looking at events.dat/idx
right now since Caliban had them unpacked. There's no names in
the index file so I think events and pack have to be unpacked together
since the .evt always matches the .cas path and filename. However,
the mapping is onto but not 1-1, not every cas file has a corresponding
evt file. If I'm seeing the header right, there's 1000 evt files for 2400
cas files.

[Casuir]

evt files look to be sound files so logically there wouldnt be one for every animation, a lot of the entrys in the skeleton.dat look to be just unit_march

[KnightErrant]

I think you're right, the data in events.dat seems to be file names for .wav
and .mp3 files in the sounds directory (although really in sounds.dat).
Looking at descr_skeleton.txt which seems to have much of the real
data in skeletons.dat shows the _basepose.cas, a lot of the _idle .cas's,
and the weapons entries with _Primary don't have evt associations.
I guess weapons and soldiers not doing anything don't need to make sounds.~:)

[Casuir]

Aye and a lot of them would make the same sounds, looking at the engine evts a few of them are blank, if the game requires the evt files to run then theoretically you could get away with copying these and renaming to the required names. I do think they're packed in the skeleton.dat file sans headers, theres definitely stuff in there that matchs up with bits in the events.dat

[Casuir]

Mkay, just been reading some of the old threads on rtw animations problem and hoping someone can explain this a bit better to me, .evt files are missing and the game wont run with the animations extracted because of this? Looking at this post by Jerome it seems the evt files are in the skeleton.dat and this has been known for some time. Vercs extractor doesnt extract them though so I'm wondering if this is an oversight or theres some other problem.
https://forums.totalwar.org/vb/showpost.php?p=709720&postcount=13

Heres the relevant part of skeleton.dat
https://img264.imageshack.us/img264/8997/evtvi7.th.png (https://img264.imageshack.us/my.php?image=evtvi7.png)
First byte in yellow is the number of entrys, next byte in purple is the sound catagory, I've identified 01 for SOUND, 02 for SOUND_BANK, 04 for SOUND_VOICE, 05 for SOUND_AMBIENT and 03 must be shockwave, doesnt seem to be any of those types in it though. Next bit in green are the start and end frames in green, followed by the lookup tag. Theres an 00 01 after some entries here which isnt always present, Im guessing this is used to identify the sound as random? Theres also a looping tag in some of the evt files in the effect_evt folder

[KnightErrant]

@Casuir
I've unpacked the cas's in pack.dat and the game won't run
with these alone using the no_animdb = true switch that Caliban
told us about. The jpg of his unpacked /animations directory showed
evt files present so I'm wondering if this is required but I don't know
this. We know that skeleton.dat ISN'T unpacked on his system because
he didn't find any of the type names present for any file extension.

Not really a big problem because its easy to repack the cas's after
modifying them, it's more of a "if it can be done then try doing it" thing.
GrumpyOldMan suspects that the no_animdb switch may not be present
in the retail version and that could very likely be the case.

Missed your post re strat_navy and fs_camel. These are the handles
or type names for different groups of animations. They extract out of
skeleton.dat just like the cas's come out of the pack but they don't
seemed to be used that way. That's why I asked for the experiment
to be done, to see if they were really filenames or just handles like
GrumpyOldMan thought. (I picked those two because the corresponding
cas's aren't named that way, so we could avoid a bunch of false hits
to have to sort through.)

Thanks for digging up the old post by Jerome, there's some food for
thought there. I'll to dig again with this new info.

[Casuir]

The problem here is vercs script doesnt properly extract from skeleton.dat, it just does a binary dump of the different entries taking the name from skeleton.idx. The actual file itself is compiled by the game from descr_skeleton, if it was extracting correctly it should be outputting that and the evt files at the very least. I think GOM is right about the type files being handles, I dont see anything suggesting they are files, am I missing something here? As for Calibans jpg, if hes got the evt's extracted then he's definitely got the skeleton.dat unpacked, becase jerome clearly says they're in there and if we look, we can find data matching their structure.

[GrumpyOldMan]

Hi KE



@GrumpyOldMan
Ok, got a reply from Caliban. He did the two experiments and none
of those "type files" or "skel files" exist with his unpacked setup.
So I think skeleton.dat/idx is supposed to stay packed and those
names are just look-up handles like you said. Looking at events.dat/idx
right now since Caliban had them unpacked. There's no names in
the index file so I think events and pack have to be unpacked together
since the .evt always matches the .cas path and filename. However,
the mapping is onto but not 1-1, not every cas file has a corresponding
evt file. If I'm seeing the header right, there's 1000 evt files for 2400
cas files.

What we really need to see are a few examples of unpacked .evt files. The .evt files look like this in the skel .dat files :-

short - num of variations
short - 0
int - code for 'sound' type??
short - start frame
short - end frame
0 termed string - description/look up table entry??(some different cas use same event - explains number discrepancy)
then usually 10 bytes with 32 00 sometimes appearing and sometimes the start and end frame reappearing.

If we could get a hold of the evt files for one figure we could make a fist of decoding because the 'no_animdb' is sure not working without them. I'll ask Caliban and see if he can help.

I believe now that the two idx and dat files are made up from the folders within animation and that the skeletons we've been so intent on don't really exist. This is bad news for the fantasy people because this means that the skeleton positions are hardcoded and are added in at compiling those idx and dat files.

Cheers

GrumpyOldMan

[SigniferOne]

Guys, Jerome provided all of the .evt files for RTW 1.5, but putting them into the extracted animations folder, so they'd match up with their corresponding animation files, still didn't work, and still crashed. So, Caliban will really have to babywalk us through here, because Jerome spent a lot of time trying to get it happen for us in RTW, and it didn't work, in large part because I think the TW engine is not so successful at loading animations when extracted. It works wonderfully for other files, which don't have to be in packs, but seems to still be a buggy process with animations, and they have to be packed, unless Caliban's animdb switch was truly made to work this time.

Just briefly, if animations have to be repacked, does this mean descr_skeleton.txt is still pretty irrelevant as a file? The one inestimable advantage of getting unpacked anims working is that descr_skeleton.txt would become important, and then we could do a lot of stuff with animations that couldn't be done otherwise.

[GrumpyOldMan]

Hi SigniferOne


Guys, Jerome provided all of the .evt files for RTW 1.5, but putting them into the extracted animations folder, so they'd match up with their corresponding animation files, still didn't work, and still crashed. So, Caliban will really have to babywalk us through here, because Jerome spent a lot of time trying to get it happen for us in RTW, and it didn't work, in large part because I think the TW engine is not so successful at loading animations when extracted. It works wonderfully for other files, which don't have to be in packs, but seems to still be a buggy process with animations, and they have to be packed, unless Caliban's animdb switch was truly made to work this time.

From what Caliban is saying it seems that if no_animdb switch works (and we won't know that until we have the .evt files in place) the skeleton and pack idx and dat files are rebuilt on start from the descr_skeleton.txt file, and then the engine uses those repacked files.


Just briefly, if animations have to be repacked, does this mean descr_skeleton.txt is still pretty irrelevant as a file? The one inestimable advantage of getting unpacked anims working is that descr_skeleton.txt would become important, and then we could do a lot of stuff with animations that couldn't be done otherwise.

I don't think from what Caliban says that we'll be able to work with unpacked files, we'll just use them to create new idx and dat files. It was possible in RTW to get new skeletons and animations in and I think that eventually we'll be able to do the same, but in the meantime its fun to play with it :beam:

Cheers

GrumpyOldMan

[Casuir]

Guys, Jerome provided all of the .evt files for RTW 1.5, but putting them into the extracted animations folder, so they'd match up with their corresponding animation files, still didn't work, and still crashed. So, Caliban will really have to babywalk us through here, because Jerome spent a lot of time trying to get it happen for us in RTW, and it didn't work, in large part because I think the TW engine is not so successful at loading animations when extracted. It works wonderfully for other files, which don't have to be in packs, but seems to still be a buggy process with animations, and they have to be packed, unless Caliban's animdb switch was truly made to work this time.

If you re-read what the man said at the time the problem actually lies with vercs .cas extractor. He got it working perfectly with the original files and a retail version of the game, so the problems on our end, not theirs. Verc missed the ball on extracting the evt files from the dat, so its not implausible that something else is getting borked.
https://forums.totalwar.org/vb/showthread.php?t=44433&highlight=bones

@gom, theres evt files in the animations/engines folder, not the exact same as the ones missing but you should be able to get the header and file structure from them.

This thread might be of interest as regards the skeletons
https://forums.totalwar.org/vb/showthread.php?t=53763
Be nice to if caliban could confirm that the skeletons are hardcoded, how does the engine know which one to use for a camel and for a man?

[SigniferOne]

Hi SigniferOne



From what Caliban is saying it seems that if no_animdb switch works (and we won't know that until we have the .evt files in place) the skeleton and pack idx and dat files are rebuilt on start from the descr_skeleton.txt file, and then the engine uses those repacked files.



I don't think from what Caliban says that we'll be able to work with unpacked files, we'll just use them to create new idx and dat files. It was possible in RTW to get new skeletons and animations in and I think that eventually we'll be able to do the same, but in the meantime its fun to play with it :beam:

Cheers

GrumpyOldMan
Ah right, if the game recreates the packed files is fine, as long as it reads from descr_skeleton.txt and lays my fears to rest :P

[Casuir]

Looking at verc's extracted .cas's they seem to differ a bit from the engine animations and some cas's in unit_models/weapon_testing which look to be animation files. I think whats happening is the .dat has compressed cas's, verc's extractor is extracting them in a format readable by his max script but not by the game, which causes it to crap out. Any chance Caliban could provide an animation thats actually in the pack?

[GrumpyOldMan]

Hi Casuir


Looking at verc's extracted .cas's they seem to differ a bit from the engine animations and some cas's in unit_models/weapon_testing which look to be animation files. I think whats happening is the .dat has compressed cas's, verc's extractor is extracting them in a format readable by his max script but not by the game, which causes it to crap out. Any chance Caliban could provide an animation thats actually in the pack?

The animations are fine, just in a bit of a different format from RTW ( which is why they're apparently appearing a bit wonky in Max - I think the Maxscript is hardwired to the RTW skelton). I can already convert them over to Mikshape format, etc. The main issue is to get the translations from the binary to the text .evt files so we can see if the engine rebuilds the skel and pack idx and dat files or whether we have to repack them ourselves.

Cheers

GrumpyOldMan

[Casuir]

Hmm, well, it looked to me like all the other .cas have bone info at the top of the file. I thought maybe the engine was discarding it or storing it elsewhere when it packed the files. You know more about this than I do so if you say they're ok then I guess they must be.

[GrumpyOldMan]

Hi Casuir


Hmm, well, it looked to me like all the other .cas have bone info at the top of the file. I thought maybe the engine was discarding it or storing it elsewhere when it packed the files. You know more about this than I do so if you say they're ok then I guess they must be.

The change in format that I spoke about was between RTW and M2TW, where the bone info has changed and some of the other information has changed within the file. The main reason that the animations looks wonky is that (I understand) you can only load the animation on top of a figure and since you can only load a RTW figure when you load the anim rotations they go to different bones ie change of skeleton between the programs.

Cheers

GrumpyOldMan

[Casuir]

I'm not talking about differences in format between the games I mean differences in formats between verc's extracted .cas's and CA's original ones. What looks to me is happening here is verc's extractor is taking a binary dump from the pack and saving it as a .cas which his script can read and his tool can repack. The actual game itself when it tries to recompile the files parses the descr_skeleton and writes the idxs and dats. If we look at the skeleton.dat the first thing in there is bones, presumably the basepose? It has to be getting these from somewhere and the .cas's left unpacked all have them at the start of the file. Verc's dont so when the game tries to run without the dats or repack them it craps put. I think the exporter CA uses exports from max with bones in the file then the game discards them on packing as it already has the skeleton in skeletons.dat.

Dunno if this confirms or debunks this


On a side note, the skeleton base pose (Vercinge's bone positions) is normally taken from the first animation which is added to a skeleton, so it's not necessary to supply this information seperately. It is important to make sure that the transforms in an animation are all relative to the same basepose - we did this by making sure that in Max the animations all contain a single frame at the front of the animation which contains the model basepose.

[GrumpyOldMan]

Hi Casuir


I'm not talking about differences in format between the games I mean differences in formats between verc's extracted .cas's and CA's original ones. What looks to me is happening here is verc's extractor is taking a binary dump from the pack and saving it as a .cas which his script can read and his tool can repack. The actual game itself when it tries to recompile the files parses the descr_skeleton and writes the idxs and dats. If we look at the skeleton.dat the first thing in there is bones, presumably the basepose? It has to be getting these from somewhere and the .cas's left unpacked all have them at the start of the file.

Agreed but if you have a look at the basepose cas files they are basically empty data, all quat values are 0,0,0,1 and all bone positions are 0,0,0, the values at the start of the unextracted cas files are the quat rotations. What's really telling now is that the cas files in m2tw don't have the bone names included, so the idx and dat files must be getting them from somewhere, the question is where? I've written to Caliban along these lines and we'll see if we can get any answers. I've seen some values right at the end of the basepose, but there are figures that have no basepose cas and use a normal cas for their default pose:dizzy2: . At the moment, I could extract bone positions from a normal cas file but there is nothing I've seen that includes bone names or flags that indicate which skeleton should be used. If the no_animdb works and creates a new skeleton idx and dat then that information must be stored somewhere, hopefully somewhere accessible.


Verc's dont so when the game tries to run without the dats or repack them it craps put. I think the exporter CA uses exports from max with bones in the file then the game discards them on packing as it already has the skeleton in skeletons.dat.

Dunno if this confirms or debunks this

We have to find out where the bone names and positions are being stored, or which flags are used to notify the system to use a paticular skeleton.

Cheers

GrumpyOldMan

[Casuir]

So its not in skeletons.dat then?

Edit: Converted some of the floats in there by hand and it looks to me like the bone positions and heirarchy are there. I'm 100% certain on whats happening GOM, what the extractor is taking out of the pack.dat arent actual cas files, look at any of the unpacked cas files and you'll see they all have bones at the start of the file, strat models, engine animations, missiles. Stands to reason that anything else exported would have the same format. If you look at it the way the game does it makes sense, the game gets the animation name from modeldb, checks that against the skeleton.idx, gets the bone positions, animations and evt files from the dat, then checks the pack index for the animation positions in the dat file and applies the bone data from skeleton.dat to the anims. No need for excess info in the pack.dat, whole point of packing them up is to save space or optimise the process, either way theres no need for them. Quickest way to confirm this would be for one of the CA guys to open up an unpacked animation in notepad or similar and see if theres bone info in the file, so if any of you guys are reading this :)

[KnightErrant]

@Casuir
I think I see what you're saying. If we just unpack the cas files
blindly from pack.dat we just get animation floats. But looking at
siege engines they have their bone sections up front. So should we
be making cas files that are a combination of the bone data from
skeleton.dat and the anim data from pack.dat?

The .evt files that Caliban posted do look like ASCII RTW ones so they should
be easy to extract from the unpacked skeleton files. I'll take a stab
at it at lunch today.

[Bwian]

This is starting to get interesting, nad hopefully will bear some fruit! Now, I am no expert when it comes to hex reading, but I do know a reasonable amount about actually trying to use the old tools..... and they were clearly not extracting data in a reliable fashion. Casuir's explanation would certainly go some way to explaining it.

From what I recall, the process that we were missing before was centred around the skeleton.dat.

We could edit this through a batch file which seemed to be able to change certain human readable parts of the DAT file to change animations. We were not...in actual fact...changing things properly. There was a clear problem actually creating a new skeleton with revised bone positions. We could scale and rename, but no more than that. I asked a lot of questions on this front, but never actually got a clear answer. The CAS file had a skeleton in it, but this was just a reference point for animation. The DAT file had the starting positions in it, but we couldn't re-write them. Never worked out why! I don't hink Vercingetorix ever did either!

The other issue I ran across so many times was the limit to the extreme rotation of parts without corrupting the file. If, as I was lead to believe, the animation files were a series of rotations applied ot the root positions held in the DAT file, there should not be a problem with the amount of rotation. In Metal Mayhem, I bent things REALLY out of shape...so I know how easy it was to break things! Casuir's assertion that we were not playing with real CAS files was again a point worth considering. We have no way of knowing for sure, since the whole pipeline was geared to getting something out of the IDX file that Max could read in to re-position the skeleton he had built up in his max importer. Working from a clean sheet of paper ( as we are for this project ) give us the chance to put aside what went before, and to think it through from first principles.

We need to understand the Skeleton.dat file first, since it holds the key to the starting points. When we can re-locate these points and build a base skeleton, we can then look to work out how the IDX files are changing the thing around. Personally, I prefer them packed...even if we could run with them out of a pack... since it is just a lot neater!

I just wish I could actually understand a bit more of the technical stuff, but I was not designed to think in hexadecimal!

[Bwian]

Anyway..after pausing to rest my fingers...I have a question :whip:

please slap me if I am wrrong... but the structure of the skeleton.dat file seems to go like this:

a definition of the starting skeleton
a load of animation links for each of the animation sets stored in the IDX file
a definition of the next skeleton
a load of animations for that

and so on.

Can we change the starting points of the bone positions ( which must be in the bits of data between the bone names in the DAT file ) and actually see the change in game ?

I am assuming that the rotational changes form the IDX file will still be applied ...just to a new starting position...

I have no idea how the various hex numbers actually translate into real co-ordinates in a modelling program...but then I am just a humble polygon pusher :inquisitive:

[KnightErrant]

Some success and frustration, bleepin' granny strings again.

I've managed to extract about 15 evt files from the subskeleton
MTW2_Spear. But in the 42 bytes following the null terminated
cas file name is a control int at the sixth int. It seems to control
whether a unit cas entry is terminated "normally" by int 0, short x32
or whether there are more 0 bytes after x32 x00. For instance,
x16=22 has 3 extra zero bytes, x0D=13 has 7 extra zero bytes,
x13=19 has 4 extra zero bytes,
x10=16 has 34 extra zero bytes, and it goes on. I'm just crunching
through and adding elif statements to handle all the different granny
control bytes until I get to end of this subskeleton. Then I'll see
if I can process all the other MTW2_ subskeletons. After that
are the stratmap ones and the fs_ mounts. Fortunately, the
fs_test_ stuff and the _pole entries don't seem to have evt
files.

[KnightErrant]

Well, scratch that controlcode stuff, found counter examples.
Now just gobble zero bytes after the x32 x00 short and then push
back the last byte when a non-zero one is encountered. Managed
to process 6 subskeleton files before bombing, about 243 evt files.
Getting there slowly.

[GrumpyOldMan]

Hi KE et al

@@@@@KE

I've just done a reinstall and update to 1.1 and now my m2tw falls over just as we get into a battle. I had a few cleansing ales last night (nothing to do with why my m2tw won't work incidentally) and woke up at 4.30 this morning with an aha!!! - eureka!!! moment. The cas files haven't drastically changed their format!!, it's just the way they're storing them in the dat files. Instead of each cas file in the dat file having it's own bone names and position information, this is stripped out and stored once only in the skeleton dat file and the rest of the files is then stored in the pack.dat. Edit:- This explains why the basepose files are just empty shells when they're extracted from the .dat files, the bone name and positions have already beem stripped out.

Since I can't get my m2tw to run any more :furious3: :furious3: :furious3: how'd you like to volunteer as an intrepid test pilot. If yes, hide your real skeletons.dat away somewhere safe and then open a copy in hex XVI32 and go to Menu/Search/Replace and replace all instance of 'A4 8F 59 3E' with '00 00 80 3F' and save in the Animations folder. If I'm right this will move all the bone_abs bones from ~.2 to 1 above the bone_pelvis.

Edit2 :-

:oops: :oops: Don't listen to me, especially if I've had a few cleansing ales the night before. I was just able to get the program to run and then I realised what was wrong with my experiment. Even though the new skeleton would be stored and loaded, the .cas files also store the global final positons of the bones which is what would be used to calculate the vertex vector/rotation matrix positions, so even though the new skeleton is there you won't see anything until we get a whole new series of cas animations.

Cheers

GrumpyOldMan

[Casuir]

Well thats what I was trying to point out GOM, sorry if I wasnt clearer. Eidting the basepose isnt going to work though is it? because we never actually see it, we only see the bone positions for the animations?

Forgot to say, tried what you said didnt work, didnt earlier with a higher value either. Interestingly though search and replace only got 49 entries, though theres 112 entries I think.

And what the heel does this mean:

no_deltas ; Horse rider animations aren't locomotion, so should not have translation deltas calculated. All riders should have this!

[GrumpyOldMan]

Hi KE


Well, scratch that controlcode stuff, found counter examples.
Now just gobble zero bytes after the x32 x00 short and then push
back the last byte when a non-zero one is encountered. Managed
to process 6 subskeleton files before bombing, about 243 evt files.
Getting there slowly.

Caliban sent me some text .evt files which might act as a Roseta Stone for translation:-

MTW2_Swordsman_at_mid_c_slashrl_s0_fatality.evt :-


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; Animation event file
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

event SOUND ANIM_SWOOSH 0 0
event SOUND ANIM_SWOOSH 14 14
event SOUND ANIM_SCRAPE 16 16
event SOUND_VOICE Individual_Attack_Scream 28 28
event SOUND ANIM_SWOOSH 40 40
event SOUND ANIM_STAB 44 44
event SOUND ANIM_SCRAPE 44 44
event SOUND ANIM_SWOOSH 54 54
event SOUND ANIM_KICK 85 85
event SOUND_VOICE Individual_Attack_Grunt 86 86
event SOUND ANIM_SWOOSH 95 95
event SOUND ANIM_STAB 98 98
event SOUND ANIM_SCRAPE 98 98
event SOUND ANIM_SWOOSH 121 121
event SOUND_BANK unit_march 144 144


MTW2_Swordsman_at_mid_c_slashrl_s2_stab_success.evt :-


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; Animation event file
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

event SOUND_VOICE Individual_Attack_Grunt 9 10 RANDOM
event SOUND ANIM_SWOOSH 12 12
event SOUND ANIM_SCRAPE 14 14 RANDOM
event SOUND ANIM_SWOOSH 22 22

fs_fast_horse_run.evt :-


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; Animation event file
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

event SOUND_BANK animal_footstep_run 6 7
event SOUND_BANK animal_footstep_run 7 8
event SOUND_BANK animal_footstep_run 9 10
event SOUND_BANK animal_footstep_run 11 12

fs_horse_charge.evt :-


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; Animation event file
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

event SOUND_BANK animal_footstep_run 5 5
event SOUND_BANK animal_footstep_run 6 6
event SOUND_BANK animal_footstep_run 8 8
event SOUND_BANK animal_footstep_run 9 9


This should help a lot with translation.

Cheers

GrumpyOldMan

[Casuir]

Well looks like bone positions are hardcoded, if you look at the descr_skeleton you'll see this entry: locomotion_table soldier
I think theres some hard coded stuff here, if we look at the xmls used for unit creation caliban provided theres reference to a soldier bonemap xml. Thats the bad news. The good news is that only a few entrys have this. When I tried it out with one that doesnt this was the result:
http://www.imagehosting.com/out.php/t560632_camel.png (http://www.imagehosting.com/out.php/i560632_camel.png)

[GrumpyOldMan]

Hi Casuir


Well thats what I was trying to point out GOM, sorry if I wasnt clearer.

No it's me that's sorry I wasn't understanding better :beam:


Eidting the basepose isnt going to work though is it? because we never actually see it, we only see the bone positions for the animations?

That's quite right, although the base poses are set, the cas files also record the global position of each bone for every frame, so even if we alter the base position of the bone, the global position in the cas overrides it with what amounts to local translation to the old bone position. We need to set a new base position and then record the new global positions for every frame in the cas to see any effect on the screen.


And what the heel does this mean:

no_deltas ; Horse rider animations aren't locomotion, so should not have translation deltas calculated. All riders should have this!

This means that a rider figure's animation has no translation movement as such (unlike foot figures which record movement in the 'x' and 'z' directions in the cas) and is set up as a 'child' attached to the bone_saddle of the horse. What happens is that when the horse moves the move is imposed on the rider figure because of its attachment - ie the rider figure has no movement by itself as such, it inherits it's movement from the horse. In more teknikal terms the translation and rotations matrices of the bone_saddle are applied to the rider and then the rider's own animations multiply those values so that the rider animates while staying 'in the saddle'. Sorry if I repeated myself there but I wanted to make sure it was clear for everybody.

Cheers

GrumpyOldMan

[KnightErrant]

Finally success, almost. I've got 1856 evt files extracted.
Still bombing in the MTW2_ section of the subskeletons.
But close to 2400 so maybe tomorrow. Mostly four lines or
so per entry but haven't been looking at them closely.
Tedious coding around the pathologicals but you only have
to get it to work once. Probably it gets weirder once I hit the fs_
mounts and the stratmap subskeletons. (Sorry, I'm working
on the unpacked type files, you know the ones that don't really
exist, so I'm calling them subskeletons since they come out of skeleton.dat.)

[GrumpyOldMan]

Hi Casuir


Well looks like bone positions are hardcoded, if you look at the descr_skeleton you'll see this entry: locomotion_table soldier
I think theres some hard coded stuff here, if we look at the xmls used for unit creation caliban provided theres reference to a soldier bonemap xml. Thats the bad news. The good news is that only a few entrys have this. When I tried it out with one that doesnt this was the result:
http://www.imagehosting.com/out.php/t560632_camel.png (http://www.imagehosting.com/out.php/i560632_camel.png)

I've noticed that none of the rider figures have the locomotion_table soldier, they have the no deltas instead. Have you tried altering the bones of any of the rider figures to see if this works with them? I'll have a closer look at camel cas anim files too in case there's any differences from other anim files.

Cheers

GrumpyOldMan

[Casuir]

Well, I tried the mtw2_bowmen, which had locomotion_type commented out. No effect ingame. Changed another value in the same skeleton just to be sure and hit quick battle instead of custom. Said I'd play through the battle just for the crack, even though neither of the two sides had camels or bowmen and noticed this:
http://www.imagehosting.com/out.php/t560885_crew.png (http://www.imagehosting.com/out.php/i560885_crew.png)
http://www.imagehosting.com/out.php/t560892_crew2.png (http://www.imagehosting.com/out.php/i560892_crew2.png)
Its the MTW2_Crew_Bombard skeleton with the earlier changes you suggested. You can see quite clearly from the second pic though that the changes arent affecting every soldier so I'm not so sure if my earlier comments were correct, the changes might be there, we just might not be seeing them.

Btw if you unpacked the files after you reinstalled the game make sure the descr_geographys are deleted, easy to forget.

[GrumpyOldMan]

Hi Casuir


Well, I tried the mtw2_bowmen, which had locomotion_type commented out. No effect ingame. Changed another value in the same skeleton just to be sure and hit quick battle instead of custom. Said I'd play through the battle just for the crack, even though neither of the two sides had camels or bowmen and noticed this:
http://www.imagehosting.com/out.php/t560885_crew.png (http://www.imagehosting.com/out.php/i560885_crew.png)
http://www.imagehosting.com/out.php/t560892_crew2.png (http://www.imagehosting.com/out.php/i560892_crew2.png)
Its the MTW2_Crew_Bombard skeleton with the earlier changes you suggested. You can see quite clearly from the second pic though that the changes arent affecting every soldier so I'm not so sure if my earlier comments were correct, the changes might be there, we just might not be seeing them.

Are you getting smooth motion from the figures that are affected? I'm getting something similar but the changes are popping in and out for the figures, the only smooth motions seem to be crew specific animations, the others are popping.


Btw if you unpacked the files after you reinstalled the game make sure the descr_geographys are deleted, easy to forget.

Yes I know, there's goes my credibility when I rant about RTFM :oops: :oops:

Cheers

GrumpyOldMan

[Casuir]

I've seen some values right at the end of the basepose, but there are figures that have no basepose cas and use a normal cas for their default pose:

This be of any relevance? I havent been able to look at anything since but I'll get stuck in tonight and make changes to all the skeletons and see what does have an effect. If its popping in and out it might be because the game is switching animaitions.

[KnightErrant]

The evt files are unpacked, finally. If I don't create one for cas entries
that have 0 event records I get 1628 files in 49 folders. However, the
navy ones and many others have evt entries in descr_skeleton.txt so maybe
these are just empty ones. Probably safer to create empty evts than have
the game not find what it wants. If I do that I get 2177 files in 50 folders.
This is still less than the 2397 cas files in 67 folders that you get from
unpacking pack.dat so the counts seem consistant.

One anomalous entry occured:

MTW2_Crossbow/MTW2_Crossbow_stand_A_to_ready.cas

had an event record with a type of 6 which is outside the range of
{SOUND, SOUND_BANK, SHOCKWAVE, SOUND_VOICE, SOUND_AMBIENT}
My entry for it looks like this (using UNKNOWN as a placeholder):

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; Animation event file
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

event UNKNOWN bone_Lelbow 10 10
event SOUND_AMBIENT human_cloth 14 14
event SOUND_AMBIENT human_armour_clink 14 14
event SOUND_BANK unit_march 15 15

Yes, bone_Lelbow does occur as the sound string at this point.
I have a question in to Caliban to see what's on his system to clear
this up.

Anyway, just about ready to test if no_animdb = true really works,
just have to get home.

[alpaca]

It's pretty likely that the bone_Lelbow thing is no sound event entry :laugh4:
Maybe it's the sound source?

[GrumpyOldMan]

Hi KE


The evt files are unpacked, finally. If I don't create one for cas entries
that have 0 event records I get 1628 files in 49 folders. However, the
navy ones and many others have evt entries in descr_skeleton.txt so maybe
these are just empty ones. Probably safer to create empty evts than have
the game not find what it wants. If I do that I get 2177 files in 50 folders.
This is still less than the 2397 cas files in 67 folders that you get from
unpacking pack.dat so the counts seem consistant.


Great stuff!! Excellent work. Just because I can't let you have all the fun I thought I'd poke around in the skeleton.dat too :beam: :beam: . I started with the thought that since the engine will run quite happily without the descr_skeleton.txt that it must be able to recreate the info internally. I started with the '-fr' and none '-fr' types and it looks like 26 bytes after the 0 termed cas name these anims are indicated by not having the four bytes '1C 07 4A 7F', having ~'-mintd'*182 in the first two bytes and ~'-maxtd'*182 in the last two bytes. '1C 07 4A 7F' therefore equates to 10 and 180 under this formula. Also at 20 bytes after the 0 termed cas name is the '-if' (impact frame) value, still looking at this one because cas' without a listed impact frame still have values there.

Now to go and look for the anim_name codes and impact deltas (pretty sure they are 3 floats 2 bytes after 0 termed cas name, but want to check), this is all great fun for the addicted :laugh4: :laugh4: :laugh4:

Cheers

GrumpyOldMan

[KnightErrant]

No joy on running with unpacked animations and evt files.
Crashed with unspecified error and nothing in the logs.
Haven't heard anything on the problem evt file so maybe
that's part of it. Hard to diagnose without a log file fussing
about something.

[GrumpyOldMan]

Hi KE


No joy on running with unpacked animations and evt files.
Crashed with unspecified error and nothing in the logs.
Haven't heard anything on the problem evt file so maybe
that's part of it. Hard to diagnose without a log file fussing
about something.

You know what KE (he said, with a mad gleam in his eye), I think that now we've just about torn it all apart, we should try to put it all back together again :laugh4: :laugh4: , but with changes. We're probably at a crossroads here, we'll have to decide whether we go with CA's no_animdb and try to recreate all their files exactly or we decide to build our own idx and dat files. This also impacts on how we extract, convert and record the cas anim files as well. If we go with rolling our own files then we can call the shots on what is an acceptable file for inclusion in the idx and dat files. Something to think about. There's always more than one way to get where you want.

Cheers

GrumpyOldMan

[KnightErrant]

Absolutely, the unpacked option was interesting and still maybe not dead.
But what you and Casuir have pursued is also a possibility. Work on
skeleton parts, maybe unpacked into type families, mod them, repack
and run that way. If skeleton.dat/idx never gets recreated then the skeletons
are perhaps free to work with. Haven't made a repacker for the skeleton
type families or a text converter to look at the data. Maybe that would be
useful. Early days yet, lots to explore here.:study:

Edit: Just tried changing UNKNOWN to SOUND_BANK to see if a known
string would work. Still crashed with unspecified error.

[GrumpyOldMan]

Hi KE


Absolutely, the unpacked option was interesting and still maybe not dead.
But what you and Casuir have pursued is also a possibility. Work on
skeleton parts, maybe unpacked into type families, mod them, repack
and run that way. If skeleton.dat/idx never gets recreated then the skeletons
are perhaps free to work with. Haven't made a repacker for the skeleton
type families or a text converter to look at the data. Maybe that would be
useful. Early days yet, lots to explore here.:study:

Edit: Just tried changing UNKNOWN to SOUND_BANK to see if a known
string would work. Still crashed with unspecified error.

Just had a thought about the files. Have you tacked the skeleton parts back onto the front of the cas anim files? - remember it's stripped out in the packing process. This is why the basepose cas files are basically empty shells with no names or positon data.

Cheers

GrumpyOldMan

[GrumpyOldMan]

Hi Casuir


This be of any relevance? I havent been able to look at anything since but I'll get stuck in tonight and make changes to all the skeletons and see what does have an effect. If its popping in and out it might be because the game is switching animaitions.

I don't get any effect unless I change values in the pack.dat file. Because it doesn't matter where I position the bone in the skeleton.dat, the cas anim file records a local translation position for each frame that relates back to the original skeleton - in effect sliding the bone back to where it was. I did some more looking and I found that when I did a global replace for that float I got about 10000 occurences. If there are 1000 cas files (conservative estimate) using that skeleton position that only leaves an average of 10 frames per anim - very low. I went back and looked into the file and there were some values that didn't exactly match the float but were still translating as the original bone position to 6 decimal places. I think what's happening is that the values are being taken from a procedurally based process and the values don't match up exactly, so only some of the bone_abs positions were being replaced and this led to popping , even within a single animation.

The short answer is that we can alter the positon of bones.

Cheers

GrumpyOldMan

[KnightErrant]

So if I understand, working just with skeleton.dat we can make
joint modifications that play in-game? Then we need a skeleton.dat
extractor so we can play with the anim bone data easily. Huzzah! fun for
everybody. Dumping no_animda = true until further information, this
seems like it could be fun.

[GrumpyOldMan]

Hi KE


So if I understand, working just with skeleton.dat we can make
joint modifications that play in-game? Then we need a skeleton.dat
extractor so we can play with the anim bone data easily. Huzzah! fun for
everybody. Dumping no_animda = true until further information, this
seems like it could be fun.

No, we need a pack.dat extractor/editor because each cas anim has position * frame info that effects the rendering of the tris. Might be easier to extract a cas anim, rework it without any change in byte size and sneak it back in :beam:

This what I've dragged out of the cas anim we've extracted up to now:-


Cas Anim format

Short - Num_Frame

short - Num_bone

num_frame * num_bone * float*4 (Quaternion rotations)

num_frame * num_bone * float*3 (local positon data - Pelvis in relation to Root Node ie height off ground, others unchanged from rest positions)

num_frame * float*2 (x and incremental z movement for Root Node)

2 * float (0?)

num_frame * float (approximate absolute z position of Root Node but in reverse order compared to animation ??)

num_frame * float *3 (absolute position of root node and pelvis height)


The red part is what needs to be altered for bone position changes.

Cheers

GrumpyOldMan

[Casuir]

Well thats just the best news I've heard in a while. I presume if the skeletons arent hard-coded then its going to be possible to make new ones?

[KnightErrant]

Answering a couple of posts here.
The cas files I unpacked are just what is in pack.dat, I didn't prepend
any bone data to them because I have no spec for that. I know
siege engines have the bone info included in their cas's.
Caliban showed us what his evt files looked like, maybe we should
ask about his unpacked cas's?

For doing animations, animmerge takes the data in the unpacked cas's
and merges it with a converted .ms3d figure and puts the quaternion
data converted to Mete's 123 Eulers in the rotation keyframes, it takes
the bone_pelvis position data, the relative floats, and puts that
in the joint 0 position keyframes but it doesn't use any of the
other pose data for the other bones (just writes 0.0 floats).
(Did do it that way the first time and all the animated figures were
stretched out to twice their height.) The local position data for all the
joints does get the pose data from the .ms3d file. After modding the
animation keyframes animextract pulls it all back out. There's the minus
sign for the x-component that I keep forgetting going both ways.

The down side is I have to write the header bytes, end bytes, global
floats, and the last 8 floats into comments because there's no where else
to put it and I don't know the rules to recreate it. This does keep the
cas in the same format as the unpacked cas's and you can use
packdotdat_casrepacker.py
to repack all the cas's into new pack.dat/idx files and it will play in-game.

[KnightErrant]

I'm going to try and summarize where I think we're at at the moment.
Totally ignore running unpacked for this. Assume everything gets repacked.


(1) First is .cas file format. This is what GOM posted:


Cas Anim format

Short - Num_Frame

short - Num_bone

num_frame * num_bone * float*4 (Quaternion rotations)

num_frame * num_bone * float*3 (local positon data - Pelvis in relation to Root Node ie height off ground, others unchanged from rest positions)

num_frame * float*2 (x and incremental z movement for Root Node)

2 * float (0?)

num_frame * float (approximate absolute z position of Root Node but in reverse order compared to animation ??)

num_frame * float *3 (absolute position of root node and pelvis height)


What works for me in doing animations in Milkshape is the following slightly different format:
Let FLOATBYTES = 4



5 byte header
short - num_frame
short - num_bone
byte - num_bone

quats:
num_frame * num_bone * 4 * FLOATBYTES

pose data:
num_frame * num_bone * 3 * FLOATBYTES

[Except for the bone_pelvis the data just repeats the skeleton pose over and over
for each frame. Isn't this the skeleton information, we don't need anything from
skeleton.dat to augment the cas files.]

global data:
num_frame * 3 * FLOATBYTES

[Don't know what this is for.]

relative data:
num_frame * 3 * FLOATBYTES

[This moves the guy forward in the z direction, i.e. out of the screen when
animating in Milkshape. I'll show a snippet in a moment.]

8 mystery floats data:
8 * FLOATBYTES

[The first entry is 0.05 * (num_frames-1), the animation time length in seconds.
Other seven floats I don't know.]

8 end bytes:
8

[These end the file, usually with the signature 255 255 15 0 0 0 0 0
or in hex FF FF 0F 00 00 00 00 00. This changes when the header bytes
change but that's for other anims like stratmap, legion_pole, etc.
Ignore other types of animation for right now and just do regular units.]




I use the utility casconverter.py to convert binary .cas files to a nice
ASCII format. Here's the relative data section for MTW2_Spear_run_to_charge.cas



+0.042779121548 +0.896650791168 +0.098638139665
+0.047644473612 +0.889466941357 +0.294535070658
+0.050987910479 +0.860747575760 +0.501587986946
+0.056217838079 +0.848554611206 +0.638711512089
+0.056164205074 +0.854174494743 +0.813530683517
+0.040740031749 +0.880190908909 +1.022136569023
+0.013633596711 +0.912660479546 +1.232632160187
-0.006605490111 +0.932232141495 +1.441531062126
-0.015281273983 +0.917331397533 +1.674659252167
-0.015948355198 +0.892094254494 +1.860179424286
-0.013512277976 +0.877519905567 +2.033008575439
-0.010928579606 +0.880254864693 +2.241550683975
-0.008396276273 +0.890842974186 +2.443597793579
-0.005408636294 +0.901573657990 +2.646682977676
-0.002154623857 +0.905263364315 +2.854587554932
+0.003916638903 +0.902066648006 +3.076904058456
+0.015629388392 +0.900002896786 +3.317394733429
+0.029411721975 +0.898095548153 +3.564741373062
+0.042934946716 +0.896170377731 +3.811233997345

Note how the z-component moves the animation forward out of the screen.

That's what I think the .cas format is. The animations work beautifully
in Milkshape using the quats converted to Mete's x, y, z euler rotations,
and the relative data put into bone_pelvis's position animation frames and
zeros for all the other bones.



(2) .skel file format
If you use skeletons.idx with its offset and length values you can
unpack skeletons.dat into 112 files. I put the .skel extension on
just to assign an editor to that extension. I hated having to use
open with on files with no extension.

Each one of these files defines the animation name, like
MTW2_Spear.skel is the definition for MTW2_Spear that you use
in the modeldb file.

I wrote a skelconverter.py just like the casconverter.py to pull this data
out and format it to understand what's there. These are sorta big files
so let's do this in sections. First is the header and bone data.
I'll show MTW2_Spear.skel converted to MTW2_Spear.txt.
The header is always a float 1.0 followed in this case by 20, the
number of bones, a byte 0, and a byte 63.

Each bone has 19 floats or ints defining it before the bone name occurs.
The second, third, and fourth entries are the bone pose data, the same
as in the .cas files. Remember the bone name FOLLOWS the data.



1.0 20 0 63
9 0.0 0.0 0.0 -1 9.63913977252e-036 -1
1.0 0 0 0.0
0 1.0 0 0.0
0 0 1.0 0.0
bone_pelvis
0 0.0952388122678 0.000752284366172 -7.68995533917e-009 0 0.0 -1
1.0 0 0 -0.0952388122678
0 1.0 0 -0.000752284366172
0 0 1.0 7.68995533917e-009
bone_RThigh
0 0.0225613098592 -0.464448839426 0.0143959810957 1 0.0 -1
1.0 0 0 -0.11780012399
0 1.0 0 0.463696569204
0 0 1.0 -0.0143959736452
bone_Rlowerleg
0 0.0241626594216 -0.399506568909 -0.0316339097917 2 0.0 -1
1.0 0 0 -0.141962781549
0 1.0 0 0.863203167915
0 0 1.0 0.0172379352152
bone_Rfoot
8 -6.93664681251e-009 0.212462007999 7.65448815443e-010 0 3.58732406867e-043 0
1.0 0 0 6.93664681251e-009
0 1.0 0 -0.212462007999
0 0 1.0 -7.65448815443e-010
bone_abs
7 -0.000294532976113 0.211557745934 2.989176906e-008 4 3.58732406867e-043 1
1.0 0 0 0.000294539902825
0 1.0 0 -0.424019753933
0 0 1.0 -3.06572189857e-008
bone_torso
6 -6.17081896053e-005 0.234973058105 6.67517667807e-008 5 0.0 2
1.0 0 0 0.000356248085154
0 1.0 0 -0.658992826939
0 0 1.0 -9.74089857664e-008
bone_head
0 0.000356251257472 0.0108101442456 -0.00344702485017 6 0.0 -1
1.0 0 0 -3.17231751978e-009
0 1.0 0 -0.669802963734
0 0 1.0 0.00344692752697
bone_jaw
0 0.0016836974537 0.117848232388 -0.0744606256485 6 0.0 -1
1.0 0 0 -0.00132744933944
0 1.0 0 -0.776841044426
0 0 1.0 0.074460528791
bone_eyebrow
0 0.0132546443492 0.130011349916 -0.0273839179426 5 0.0 -1
1.0 0 0 -0.0129601042718
0 1.0 0 -0.554031133652
0 0 1.0 0.0273838881403
bone_Rclavical
0 0.165358901024 -0.0517836585641 0.0034832842648 9 0.0 -1
1.0 0 0 -0.178319007158
0 1.0 0 -0.502247452736
0 0 1.0 0.0239006038755
bone_Rupperarm
0 0.302206397057 0.0111386608332 -0.0137691963464 10 0.0 -1
1.0 0 0 -0.480525404215
0 1.0 0 -0.513386130333
0 0 1.0 0.0376698002219
bone_Relbow
5 0.283836990595 -0.00305567588657 0.0263375118375 11 0.0 -1
1.0 0 0 -0.76436239481
0 1.0 0 -0.510330438614
0 0 1.0 0.0113322883844
bone_Rhand
0 -0.0102220894769 0.130011349916 -0.0273839179426 5 0.0 -1
1.0 0 0 0.0105166295543
0 1.0 0 -0.554031133652
0 0 1.0 0.0273838881403
bone_Lclavical
0 -0.167802318931 -0.0517838038504 0.00348335830495 13 0.0 -1
1.0 0 0 0.178318947554
0 1.0 0 -0.502247333527
0 0 1.0 0.0239005293697
bone_Lupperarm
0 -0.302173316479 0.0111954407766 -0.0144314421341 14 0.0 -1
1.0 0 0 0.480492264032
0 1.0 0 -0.513442754745
0 0 1.0 0.0383319705725
bone_Lelbow
4 -0.283801227808 -0.00320043438114 0.0267044473439 15 0.0 -1
1.0 0 0 0.76429349184
0 1.0 0 -0.510242342949
0 0 1.0 0.0116275232285
bone_Lhand
0 -0.0952387824655 0.000752363703214 2.19979003901e-008 0 0.0 -1
1.0 0 0 0.0952387824655
0 1.0 0 -0.000752363703214
0 0 1.0 -2.19979003901e-008
bone_LThigh
0 -0.0216093510389 -0.464143753052 0.0230784993619 17 0.0 -1
1.0 0 0 0.116848133504
0 1.0 0 0.463391393423
0 0 1.0 -0.0230785217136
bone_Llowerleg
0 -0.0250775031745 -0.398637682199 -0.0406115166843 18 0.0 -1
1.0 0 0 0.141925632954
0 1.0 0 0.862029075623
0 0 1.0 0.0175329949707
bone_Lfoot

Looks like an identity matrix with an augmented column for part of this,
rotation and translation?

After the bone data comes the cas file names and the sound event records that you
can use to extract the evt files if desired. This is pretty big, I'll only post
the first 20 entries. There's actually like 180 entries in all. I don't think
there's any information here at all other than the sound records for the
evt files. There's one int that changes from .cas to .cas file but I don't
know what it means.



data/animations/MTW2_Spear/MTW2_Spear_Stand_A_idle.cas
0 0 0 1.60000002384 0 0 20 0 2.68540969134e+038 0 0 1.0
1
SOUND_AMBIENT 0 0 human_whistle 0
data/animations/MTW2_Spear/MTW2_Spear_walk.cas
0 0 0 1.60000002384 0 0 9 0 2.68540969134e+038 0 0 1.0
4
SOUND_AMBIENT 5 7 human_armour_walk 0
SOUND_BANK 5 7 unit_march 0
SOUND_AMBIENT 15 17 human_armour_walk 0
SOUND_BANK 15 17 unit_march 0
data/animations/MTW2_Spear/MTW2_Spear_walk_to_stand_A.cas
0 0 0 1.60000002384 0 0 22 0 2.68540969134e+038 0 0 1.0
4
SOUND_BANK 7 9 unit_march 0
SOUND_BANK 19 21 unit_march 0
SOUND_BANK 31 33 unit_march 0
SOUND_BANK 40 42 unit_march 0
data/animations/MTW2_Spear/MTW2_Spear_stealthy_walk.cas
0 0 0 1.60000002384 0 0 20 0 2.68540969134e+038 0 0 1.0
0
data/animations/MTW2_Spear/MTW2_Spear_stealthy_walk_to_stand_A.cas
0 0 0 1.60000002384 0 0 12 0 2.68540969134e+038 0 0 1.0
1
SOUND_BANK 20 22 unit_march 0
data/animations/MTW2_Spear/MTW2_Spear_stealthy_walk_to_hide.cas
0 0 0 1.60000002384 0 0 20 0 2.68540969134e+038 0 0 1.0
0
data/animations/MTW2_Spear/MTW2_Spear_stealthy_walk_to_walk.cas
0 0 0 1.60000002384 0 0 17 0 2.68540969134e+038 0 0 1.0
1
SOUND_BANK 34 34 unit_march 0
data/animations/MTW2_Spear/MTW2_Spear_run.cas
0 0 0 1.60000002384 0 0 7 0 2.68540969134e+038 0 0 1.0
4
SOUND_AMBIENT 2 4 human_armour_run 0
SOUND_BANK 2 4 unit_run 0
SOUND_AMBIENT 10 12 human_armour_run 0
SOUND_BANK 10 12 unit_run 0
data/animations/MTW2_Spear/MTW2_Spear_run_to_stand_A.cas
0 0 0 1.60000002384 0 0 17 0 2.68540969134e+038 0 0 1.0
4
SOUND_BANK 2 3 unit_march 0
SOUND_BANK 10 11 unit_march 0
SOUND_BANK 17 18 unit_march 0
SOUND_BANK 29 30 unit_march 0
data/animations/MTW2_Spear/MTW2_Spear_run_to_walk.cas
0 0 0 1.60000002384 0 0 13 0 2.68540969134e+038 0 0 1.0
3
SOUND_BANK 2 4 unit_march 0
SOUND_BANK 13 15 unit_march 0
SOUND_BANK 22 24 unit_march 0
data/animations/MTW2_Spear/MTW2_Spear_walk_to_run.cas
0 0 0 1.60000002384 0 0 8 0 2.68540969134e+038 0 0 1.0
1
SOUND_BANK 8 10 unit_march 0
data/animations/MTW2_Spear/MTW2_Spear_ready_to_stand_A.cas
0 0 0 1.60000002384 0 0 12 0 2.68540969134e+038 0 0 1.0
1
SOUND_BANK 18 20 unit_march 0
data/animations/MTW2_Spear/MTW2_Spear_ready_idle.cas
0 0 0 1.60000002384 0 0 14 0 2.68540969134e+038 0 0 1.0
1
SOUND 0 0 ANIM_Human_ready 0
data/animations/MTW2_Spear/MTW2_Spear_ready_hf_idle_1.cas
0 0 0 1.60000002384 0 0 15 0 2.68540969134e+038 0 0 1.0
0
data/animations/MTW2_Spear/MTW2_Spear_ready_hf_idle_2.cas
0 0 0 1.60000002384 0 0 22 0 2.68540969134e+038 0 0 1.0
1
SOUND_BANK 30 30 unit_march 0

EDIT: There's some more stuff at the bottom of the file.
Don't know what it is.

This is what we know so far.



(3) Thought experiment of making a dwarf unit.

Decide on a reduced skeleton but still with the 20 bones. Make a
.skems3d file for my mesh converter or a similar binary one for GOM's
converter. Take an 2HAxe unit mesh and convert to Milkshape using
the new skeleton. Do that modeller magic to make a dwarf out of it
and convert back and call it dwarfwarrior_lod0.mesh and the higher lods.

Hard part. Since a dwarf they have to be 2H Axe guys so copy
the unpacked cas files in MTW2_2H_Axe into a new directory
MTW2_2H_Dwarf and then rename the animations in some automated way.
Write a script to edit each cas file and replace the pose data
for each frame with the new skeleton values. Ok, cas's are done.

Unpack skeleton.dat and copy MTW2_2H_Axe.skel to MTW2_2H_Dwarf.skel.
Convert it to ASCII using skelconverter.py and change the skeleton
data at the top to the new bones.
Big question here is what are those other floats used for.

(Good thing this is only a thought experiment.)

Convert MTW2_2H_Dwarf.txt back to binary MTW2_2H_Dwarf.skel.
Add it to the repackingdata.txt file to append it to the end
of skeletons.dat. Now repack skeletons.dat.

Also repack pack.dat again adding the units to the repacking list
for this. (Just copy the MTW2_2H_Axe section and put Dwarf on them.)

Put it in EDU and modeldb, unit cards, all that stuff. The animation
name at the end of the modeldb entry would be MTW2_2H_Dwarf.

Voila! MAYBE this would work.


So my question is: is this what we are trying to do or have I missed
the point completely?

[GrumpyOldMan]

Hi KE


So my question is: is this what we are trying to do or have I missed
the point completely?

Lots of great stuff there KE. If we modify the animation translation entries in the truncated cas anim files and include this in the pack.dat file then we don't really have to worry about the position info in the skeleton.dat because the translation info will overpower the initial position entries. However there are a lot of other entries we have to worry about - the entries that show the height of the pelvis off the ground, if we have shorter legs then we have to alter the length of movement over the ground or we'll get a skating effect, etc. It's probably better to export the truncated anim data into a 3d modeller/animation program, get new movement information and then convert back into truncated cas anim format for pasting back into the pack.dat.

Cheers

GrumpyOldMan

[Casuir]

You guys sure this is the right way to go about this, personally I'd have thought trying to rebuild the cas files would be the safest way to go about this. You guys do know we have an official CA exporter which should give us the correct format for the unpacked .cas right?

Edit from the documentation:


Exporting Animation: To access the exporter menu, go to File -> Export from the top left drop down menu. Click the ‘Save as Type’ drop-down and change it to ‘CA Max Exporter’ .

Point the directory to your destination folder where you want the .CAS file to live, name the file and hit save. This will open the ‘CA exporter’ dialog window. From here you can select the options you want for your .CAS format. *Remember, both animation and mesh formats are named with the .CAS extension! Please note that your first frame of animation should be the base pose of the model (no animation, just rigged). The Static output section on the exporter defines where this ‘base pose’ is drawn from. Animation output section can be toggled to export ‘All Keys’ or a selected key range of the animation.
Below is a screenshot of standard animation exporting options

[GrumpyOldMan]

Hi Casuir


You guys sure this is the right way to go about this, personally I'd have thought trying to rebuild the cas files would be the safest way to go about this. You guys do know we have an official CA exporter which should give us the correct format for the unpacked .cas right?

Edit from the documentation:

Ahh.., now there's the rub, neither KE or myself have 3DS Max, so we can't get access to the exporter :beam: . Caliban has kindly sent me some examples and it confirms what I thought. The anim cas' exported by Verc's extracter are raw info without the bone hierarchy, names or positions. This is why all the attempts by RTW modders to get the anim stuff happening fell over. When the pack.dat is made the relevant bone stuff is stripped out of the cas files to save space (it's the same for every anim for each figure) and stored in the skeleton.dat. The only way that raw data can be used is if you work directly on the pack.dat. This is how mods like Napoleon TW got new figures and anims into mods.

Cheers

GrumpyOldMan

[Casuir]

Aye well it makes sense if you look at it from a packing rather than an extracting angle. I have 3dsmax, dont have it installed at the minute though. I can install and re-export an animation but I think given the problems mentioned with vercs old script it might be better to work off what Caliban sent you. Good news though, we now have all the pieces of the puzzle :2thumbsup:

[Ashdnazg]

No one I know of has managed to export a CAS model with CA's exporter,
So I'm not surprised animations weren't even tried.

And AFAIK, NTW2 used verc's scripts/tools to produce the new animations.
Never knew of anyone that worked on the pack.dat directly.

Lord Hokomoko

[Casuir]

Verc's tool doesnt actually unpack .cas files so any animations made using the exporter arent going to be compatible with it. Why couldnt nobody you know export units, I'm guessing its got something to do with the skeleton but more info on specific errors would be nice.

[Ashdnazg]

https://forums.totalwar.org/vb/showthread.php?t=75161
wlesmana's post.
I think the reason why it doesn't work is that verc's script doesn't import the CAS files in the way they need to be in order to export them.

[KnightErrant]

Yep, we got examples of Caliban's unpacked .cas files and they
do have the bone information headers just like GrumpyOldMan
was thinking. Looks like some header stuff, then time ticks for the
animation frames in seconds: 0.0, 0.05, 0.1, 0.15 etc. Then the
bone info starting with Scene_Root through all the bones, and then
the raw .cas data starts at offset 1106 (sans the 5 byte header).
So this should be what is needed to run unpacked along with the
.evt files.

Also got the answer for ntype = 6. The string is DETACH so the sound
string enumeration is
1 - SOUND
2 - SOUND_BANK
3 - SHOCKWAVE
4 - SOUND_VOICE
5 - SOUND_AMBIENT
6 - DETACH

My unpacked MTW2_Crossbow_stand_A_to_ready.evt file read as


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; Animation event file
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

event UNKNOWN bone_Lelbow 10 10
event SOUND_AMBIENT human_cloth 14 14
event SOUND_AMBIENT human_armour_clink 14 14
event SOUND_BANK unit_march 15 15

whereas Caliban's evt file for MTW2_Crossbow_stand_A_to_ready.evt is


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; Animation event file
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

event DETACH bone_Lelbow 10 10
event SOUND_AMBIENT human_armour_clink 14 14
event SOUND_AMBIENT human_cloth 14 14
event SOUND_BANK unit_march 15 15

This was the only one that had ntype = 6 so just have to change
UNKNOWN to DETACH. Don't know why _cloth and _clink are switched
in skeletons.dat.

[Bwian]

GOM ... it was perfectly possible to get new animations into RTW using Vercingetorix's tools. I put loads in for Metal Mayhem. There were bugs, and excessive rotations brought issues ... as did modding certain animations of certain models.

Bizarrest was the horse animations. Import them..change them..export them ...work fine. Import them again, and the root bone had moved up for no apparent reason.

Anyway....looking at what has been done....

What are we going to be able to mod when it comes to skeletons?

[GrumpyOldMan]

Hi Bwian


GOM ... it was perfectly possible to get new animations into RTW using Vercingetorix's tools. I put loads in for Metal Mayhem. There were bugs, and excessive rotations brought issues ... as did modding certain animations of certain models.

Bizarrest was the horse animations. Import them..change them..export them ...work fine. Import them again, and the root bone had moved up for no apparent reason.

Anyway....looking at what has been done....

What are we going to be able to mod when it comes to skeletons?

In case you miss it Caliban has released all the anim cas files at https://forums.totalwar.org/vb/showpost.php?p=1528239&postcount=568 . What happens now is that the dat and idx files are rebuilt from the descr_skeleton.txt and the source files. We've tried the no_animdb = true option but it doesn't seem to be available in the retail version.

I'm pretty sure that now we know that nothing apart from significant bones (have a look at my post https://forums.totalwar.org/vb/showpost.php?p=1528281&postcount=570) is hardcoded we can put new skeletons in, along with their animations.

Cheers

GrumpyOldMan

[KnightErrant]

Looking at the new format for .cas files with the header info etc.
I think I must have been talking past you re .cas formats. I was
posting info about the raw format and your posts must have been
about .cas files with headers. Running through it today it looks like
Caliban's unpacked or non-raw .cas files have a corner-turn in the data
organization. Instead of being organized by frames with all the bones
per frame they are organized by bones with all the frames per bone.
My take on this is:

Header and version info:
The floats are the time in seconds for the animation frames. This is for
MTW2_Spear_stand_A_to_ready.cas


3.21000003815 38 9 0 1.20000004768 1 0 0 0
1 0 102 0.00648193340749 0 0 1
21
0 0 1 2 3 1 5 6 7 7 6 10 11 12 6 14 15 16 1 18 19
25
+0.0000 +0.0500 +0.1000 +0.1500 +0.2000 +0.2500 +0.3000 +0.3500 +0.4000 +0.4500 +0.5000 +0.5500 +0.6000 +0.6500 +0.7000 +0.7500 +0.8000 +0.8500 +0.9000 +0.9500 +1.0000 +1.0500 +1.1000 +1.1500 +1.2000


Bone Section:


Scene Root
0 0 0 8000 0 1 0
bone_pelvis
25 25 0 8000 0 1 0
bone_RThigh
25 25 400 8300 0 1 0
bone_Rlowerleg
25 25 800 8600 0 1 0
bone_Rfoot
25 25 1200 8900 0 1 0
bone_abs
25 25 1600 9200 0 1 0
bone_torso
25 25 2000 9500 0 1 0
bone_head
25 25 2400 9800 0 1 0
bone_jaw
25 25 2800 10100 0 1 0
bone_eyebrow
25 25 3200 10400 0 1 0
bone_Rclavical
25 25 3600 10700 0 1 0
bone_Rupperarm
25 25 4000 11000 0 1 0
bone_Relbow
25 25 4400 11300 0 1 0
bone_Rhand
25 25 4800 11600 0 1 0
bone_Lclavical
25 25 5200 11900 0 1 0
bone_Lupperarm
25 25 5600 12200 0 1 0
bone_Lelbow
25 25 6000 12500 0 1 0
bone_Lhand
25 25 6400 12800 0 1 0
bone_LThigh
25 25 6800 13100 0 1 0
bone_Llowerleg
25 25 7200 13400 0 1 0
bone_Lfoot
25 25 7600 13700 0 1 0


Too much stuff to post but the quats are by bones now
with all frame information in one block. Much better for conversion
to Milkshape because that's Mete's exact layout. This is bone_pelvis
entry:


-0.108608551323 -0.007828859612 -0.000920463295 +0.994053363800
-0.084384687245 +0.022708337754 -0.011063469574 +0.996113002300
-0.058044090867 +0.053880218416 -0.021976348013 +0.996616721153
-0.030463287607 +0.085392631590 -0.033235911280 +0.995326817036
-0.007472235244 +0.115757785738 -0.047936283052 +0.992091953754
+0.028245884925 +0.166402772069 -0.072737179697 +0.982965707779
+0.043766327202 +0.193626761436 -0.084212407470 +0.976473987103
+0.057122029364 +0.221825778484 -0.094888709486 +0.968775808811
+0.066032424569 +0.247784942389 -0.103079698980 +0.961049914360
+0.070230528712 +0.272408127785 -0.108502551913 +0.953461408615
+0.070291444659 +0.297054886818 -0.111331865191 +0.945739269257
+0.067297339439 +0.320091962814 -0.111844815314 +0.938351154327
+0.059432417154 +0.348196655512 -0.109153442085 +0.929146051407
+0.049886766821 +0.368794888258 -0.103129789233 +0.922423899174
+0.043417390436 +0.376555502415 -0.097042590380 +0.920273661613
+0.037343896925 +0.377277672291 -0.089149504900 +0.921042561531
+0.029859540984 +0.368926137686 -0.078202642500 +0.925681531429
+0.020579544827 +0.353258907795 -0.064406000078 +0.933079063892
+0.011515665799 +0.333706319332 -0.049672160298 +0.941297054291
+0.004295732826 +0.315065413713 -0.036236159503 +0.948368191719
+0.003431262448 +0.283683806658 -0.022887952626 +0.958638548851
+0.005944626406 +0.273603349924 -0.016878437251 +0.961676120758
+0.008991812356 +0.267771750689 -0.011048658751 +0.963377058506
+0.011831115931 +0.264247536659 -0.005632948596 +0.964365839958
+0.013679862022 +0.261084914207 -0.000808692246 +0.965218544006


This corner-turn is perfect to write into the rotation keyframes for
Milkshape.

Position data follows but only the first bone block for bone_pelvis
matters. The rest are very small deltas. This is like the relative
floats of the raw format. Note the z-component to move the animation
forward.


-0.000002666947 +0.972795665264 +0.000162427896
-0.022701801732 +0.968579053879 -0.019661828876
-0.047594968230 +0.965409278870 -0.039041973650
-0.073586426675 +0.962764978409 -0.058199759573
-0.099584691226 +0.965991497040 -0.071735151112
-0.143026933074 +0.971794426441 -0.092757597566
-0.161704316735 +0.973607599735 -0.105233184993
-0.178335353732 +0.973865330219 -0.119232922792
-0.189656645060 +0.971897959709 -0.133856356144
-0.194005906582 +0.965716838837 -0.150296986103
-0.191132619977 +0.953903973103 -0.169709458947
-0.182952329516 +0.938509345055 -0.190593883395
-0.165881812572 +0.913662731647 -0.220546051860
-0.146148547530 +0.890212774277 -0.248966440558
-0.132748499513 +0.877652108669 -0.266761720181
-0.120905637741 +0.869793772697 -0.281699597836
-0.109561815858 +0.867194533348 -0.293205916882
-0.097663201392 +0.868378937244 -0.302077472210
-0.086146891117 +0.872312545776 -0.308713793755
-0.075999587774 +0.876713454723 -0.314233064651
-0.065458685160 +0.895100176334 -0.310706079006
-0.060107916594 +0.901992797852 -0.309674441814
-0.054997127503 +0.906326234341 -0.309960007668
-0.050200626254 +0.909838914871 -0.310802549124
-0.045792661607 +0.914269447327 -0.311441510916

Finally, the skeleton pose data follows with NBONES=21 because
Scene_Root is in there. First two lines are Scene_Root and
bone_pelvis.


+0.000000000000 +0.000000000000 +0.000000000000
+0.000000000000 +0.000000000000 +0.000000000000
+0.095238812268 +0.000752284715 -0.000000007690
+0.022561285645 -0.464448839426 +0.014395990409
+0.024162683636 -0.399506568909 -0.031633902341
-0.000000006937 +0.212462007999 +0.000000000765
-0.000294532976 +0.211557894945 +0.000000029888
-0.000061708190 +0.234973102808 +0.000000066748
+0.000356251665 +0.010810676962 -0.003447051859
+0.001683695358 +0.117848567665 -0.074460588396
+0.013254644349 +0.130011290312 -0.027383917943
+0.165358901024 -0.051783658564 +0.003483306849
+0.302206397057 +0.011138660833 -0.013769198209
+0.283836990595 -0.003055675887 +0.026337502524
-0.010222089477 +0.130011290312 -0.027383917943
-0.167802318931 -0.051783755422 +0.003483355278
-0.302173316479 +0.011195489205 -0.014431442134
-0.283801048994 -0.003200337524 +0.026704434305
-0.095238782465 +0.000752363936 +0.000000021998
-0.021609351039 -0.464143663645 +0.023078495637
-0.025077503175 -0.398637473583 -0.040611520410


Last is some footer stuff I haven't sorted out.

This is really exciting because we don't have to deal with the mess
in skeletons.dat anymore (although I could kick myself for all the utilities
I made to deal with this). So a basic animmerge/animextract with the
new format should be cake but dealing with new skeletons will take
some thought. Wish it was a 3-day weekend coming up.:smash:

[GrumpyOldMan]

Hi KE

Hail!! Fellow master of the Scourge and Scalpel.


Looking at the new format for .cas files with the header info etc.
I think I must have been talking past you re .cas formats. I was
posting info about the raw format and your posts must have been
about .cas files with headers. Running through it today it looks like
Caliban's unpacked or non-raw .cas files have a corner-turn in the data
organization. Instead of being organized by frames with all the bones
per frame they are organized by bones with all the frames per bone.


Yes we can all breath easier now that we have the source cas files to slap onto the dissection table :beam:


My take on this is:

Header and version info:
The floats are the time in seconds for the animation frames. This is for
MTW2_Spear_stand_A_to_ready.cas


3.21000003815 38 9 0 1.20000004768 1 0 0 0
1 0 102 0.00648193340749 0 0 1
21
0 0 1 2 3 1 5 6 7 7 6 10 11 12 6 14 15 16 1 18 19
25
+0.0000 +0.0500 +0.1000 +0.1500 +0.2000 +0.2500 +0.3000 +0.3500 +0.4000 +0.4500 +0.5000 +0.5500 +0.6000 +0.6500 +0.7000 +0.7500 +0.8000 +0.8500 +0.9000 +0.9500 +1.0000 +1.0500 +1.1000 +1.1500 +1.2000


Bone Section:


Scene Root
0 0 0 8000 0 1 0
bone_pelvis
25 25 0 8000 0 1 0
bone_RThigh
25 25 400 8300 0 1 0
bone_Rlowerleg
25 25 800 8600 0 1 0
bone_Rfoot
25 25 1200 8900 0 1 0
bone_abs
25 25 1600 9200 0 1 0
bone_torso
25 25 2000 9500 0 1 0
bone_head
25 25 2400 9800 0 1 0
bone_jaw
25 25 2800 10100 0 1 0
bone_eyebrow
25 25 3200 10400 0 1 0
bone_Rclavical
25 25 3600 10700 0 1 0
bone_Rupperarm
25 25 4000 11000 0 1 0
bone_Relbow
25 25 4400 11300 0 1 0
bone_Rhand
25 25 4800 11600 0 1 0
bone_Lclavical
25 25 5200 11900 0 1 0
bone_Lupperarm
25 25 5600 12200 0 1 0
bone_Lelbow
25 25 6000 12500 0 1 0
bone_Lhand
25 25 6400 12800 0 1 0
bone_LThigh
25 25 6800 13100 0 1 0
bone_Llowerleg
25 25 7200 13400 0 1 0
bone_Lfoot
25 25 7600 13700 0 1 0


Too much stuff to post but the quats are by bones now
with all frame information in one block. Much better for conversion
to Milkshape because that's Mete's exact layout. This is bone_pelvis
entry:


-0.108608551323 -0.007828859612 -0.000920463295 +0.994053363800
-0.084384687245 +0.022708337754 -0.011063469574 +0.996113002300
-0.058044090867 +0.053880218416 -0.021976348013 +0.996616721153
-0.030463287607 +0.085392631590 -0.033235911280 +0.995326817036
-0.007472235244 +0.115757785738 -0.047936283052 +0.992091953754
+0.028245884925 +0.166402772069 -0.072737179697 +0.982965707779
+0.043766327202 +0.193626761436 -0.084212407470 +0.976473987103
+0.057122029364 +0.221825778484 -0.094888709486 +0.968775808811
+0.066032424569 +0.247784942389 -0.103079698980 +0.961049914360
+0.070230528712 +0.272408127785 -0.108502551913 +0.953461408615
+0.070291444659 +0.297054886818 -0.111331865191 +0.945739269257
+0.067297339439 +0.320091962814 -0.111844815314 +0.938351154327
+0.059432417154 +0.348196655512 -0.109153442085 +0.929146051407
+0.049886766821 +0.368794888258 -0.103129789233 +0.922423899174
+0.043417390436 +0.376555502415 -0.097042590380 +0.920273661613
+0.037343896925 +0.377277672291 -0.089149504900 +0.921042561531
+0.029859540984 +0.368926137686 -0.078202642500 +0.925681531429
+0.020579544827 +0.353258907795 -0.064406000078 +0.933079063892
+0.011515665799 +0.333706319332 -0.049672160298 +0.941297054291
+0.004295732826 +0.315065413713 -0.036236159503 +0.948368191719
+0.003431262448 +0.283683806658 -0.022887952626 +0.958638548851
+0.005944626406 +0.273603349924 -0.016878437251 +0.961676120758
+0.008991812356 +0.267771750689 -0.011048658751 +0.963377058506
+0.011831115931 +0.264247536659 -0.005632948596 +0.964365839958
+0.013679862022 +0.261084914207 -0.000808692246 +0.965218544006


This corner-turn is perfect to write into the rotation keyframes for
Milkshape.

Position data follows but only the first bone block for bone_pelvis
matters. The rest are very small deltas. This is like the relative
floats of the raw format. Note the z-component to move the animation
forward.


-0.000002666947 +0.972795665264 +0.000162427896
-0.022701801732 +0.968579053879 -0.019661828876
-0.047594968230 +0.965409278870 -0.039041973650
-0.073586426675 +0.962764978409 -0.058199759573
-0.099584691226 +0.965991497040 -0.071735151112
-0.143026933074 +0.971794426441 -0.092757597566
-0.161704316735 +0.973607599735 -0.105233184993
-0.178335353732 +0.973865330219 -0.119232922792
-0.189656645060 +0.971897959709 -0.133856356144
-0.194005906582 +0.965716838837 -0.150296986103
-0.191132619977 +0.953903973103 -0.169709458947
-0.182952329516 +0.938509345055 -0.190593883395
-0.165881812572 +0.913662731647 -0.220546051860
-0.146148547530 +0.890212774277 -0.248966440558
-0.132748499513 +0.877652108669 -0.266761720181
-0.120905637741 +0.869793772697 -0.281699597836
-0.109561815858 +0.867194533348 -0.293205916882
-0.097663201392 +0.868378937244 -0.302077472210
-0.086146891117 +0.872312545776 -0.308713793755
-0.075999587774 +0.876713454723 -0.314233064651
-0.065458685160 +0.895100176334 -0.310706079006
-0.060107916594 +0.901992797852 -0.309674441814
-0.054997127503 +0.906326234341 -0.309960007668
-0.050200626254 +0.909838914871 -0.310802549124
-0.045792661607 +0.914269447327 -0.311441510916

Finally, the skeleton pose data follows with NBONES=21 because
Scene_Root is in there. First two lines are Scene_Root and
bone_pelvis.


+0.000000000000 +0.000000000000 +0.000000000000
+0.000000000000 +0.000000000000 +0.000000000000
+0.095238812268 +0.000752284715 -0.000000007690
+0.022561285645 -0.464448839426 +0.014395990409
+0.024162683636 -0.399506568909 -0.031633902341
-0.000000006937 +0.212462007999 +0.000000000765
-0.000294532976 +0.211557894945 +0.000000029888
-0.000061708190 +0.234973102808 +0.000000066748
+0.000356251665 +0.010810676962 -0.003447051859
+0.001683695358 +0.117848567665 -0.074460588396
+0.013254644349 +0.130011290312 -0.027383917943
+0.165358901024 -0.051783658564 +0.003483306849
+0.302206397057 +0.011138660833 -0.013769198209
+0.283836990595 -0.003055675887 +0.026337502524
-0.010222089477 +0.130011290312 -0.027383917943
-0.167802318931 -0.051783755422 +0.003483355278
-0.302173316479 +0.011195489205 -0.014431442134
-0.283801048994 -0.003200337524 +0.026704434305
-0.095238782465 +0.000752363936 +0.000000021998
-0.021609351039 -0.464143663645 +0.023078495637
-0.025077503175 -0.398637473583 -0.040611520410


Last is some footer stuff I haven't sorted out.

This is really exciting because we don't have to deal with the mess
in skeletons.dat anymore (although I could kick myself for all the utilities
I made to deal with this). So a basic animmerge/animextract with the
new format should be cake but dealing with new skeletons will take
some thought. Wish it was a 3-day weekend coming up.:smash:

Never mind about the programming practice, it all comes in handy. Of course I knew you were looking at the files, that's why I came up with a cunning plan to start looking at the end of the files. There are references to CaozSceneCustomAttrib etc. The base poses show Node01 and Node02, the run of the mill only show CaozSceneCustomAttribNode. The only cas files I have found without them are the knifeman swimming (used by all figures) and die_flailing_cycle files. This makes me think that 1. figures don't hold weapons while swimming and 2. the die_flailing_cycle files are meant to merge in with other die type anims - the Caoz node is an identifier for the weapon/shield bones being used, or in the case of horses an attachment point for a rider. The last 192 bytes for normal cas files is the same. I'll keep on looking for any other anomalies.

Cheers

GrumpyOldMan

[KnightErrant]

Progress on animations. We've received the unpacked versions
of the .cas and .evt files from Caliban and it is possible to run
unpacked. You have to put the entry
[util]
no_animdb = true
in your mod .cfg file but put the unpacked files in the base animations
directory. The pack.dat, pack.idx, skeletons.dat, and skeletons.idx files
will then be regenerated in your mod animations directory. This means
descr_skeletons.txt needs to be present in your base /data directory.

Caliban said the files should be posted here at the guild but I haven't seen
them yet but I don't know my way around the downloads section here too well.
If anyone sees them, please post the location.

Some extremely alpha merge and extract Python utilities should be ready soon
for people to play with. No, you won't be able to have custom skeletons
(dwarfs, orcs) with these. Down the road a bit for that. These will just
be for modding existing anims.

[Casuir]

http://www.mediafire.com/?7ydzbziijmy
There ya go, not sure if they're 1.1 or 1.2 files though

[alpaca]

Yeah the download section isn't too well cared for I fear. I'll have to chat to Tosa about it some time.

[KnightErrant]

I've uploaded some very alpha animation utilities here:

http://www.twcenter.net/forums/downl...o=file&id=1341

The three files are a filechooser, listdir.py, and a merge utility,
fullanimmerge.py, and an extract utility, fullanimextract.py. These work
with regular units in .ms3d format, either by GrumpyOldMan's converter,
or my meshconverter, and with the full format .cas and .evt files provided
by Caliban. Casuir's post above has the link to these.

When you start the game it will take about a minute to regenerate new
pack.dat, pack.idx, skeletons.dat, and skeletons.idx files in your
mod folder's /data/animations directory.

To merge a .ms3d file format unit with an animation, double click on
fullanimmerge.py and a filechooser will come up. Choose a spear unit
to work with spear animations, sword for sword anims, etc.
Then a second file chooser will come up looking for an animation .cas
file. Work over to the /data/animations directory and choose the .cas
file you want to work with. A new .ms3d file will be created where you
chose the unit with the string "_animated" added to the original name.
This file can be opened in Milkshape and the animation run using the keyframer.

To extract a modified animation double click fullanimextract.py and choose
your animated file. A full format .cas file named extractedanimation.cas
will then be created. Rename it appropriately and put back in the
animations directory (backing up the original of course).

Remember these are alpha utilities so let the buyer beware, you're testers
as well as users. :laugh4:

[KnightErrant]

I did an experiment on making new animation families.
I copied MTW2_2H_Axe directory under /data/animations
to MTW2_Dwarf_2H_Axe. I didn't change any of the .cas
files names under here. I then copied the MTW2_2H_Axe
section in descr_skeletons.txt and pasted it after that entry
and changed the animation family name to MTW2_Dwarf_2H_Axe.
I also changed the additional entries at the bottom of the section
for weapons: MTW2_Dwarf_2H_Axe_primary and the fast and slow
entries to: MTW2_Dwarf_Fast_2H_Axe, MTW2_Dwarf_Slow_2H_Axe
as well as their parent names to MTW2_Dwarf_2H_Axe.
I also changed all the paths to point to the new directory name.

Deleted the pack.dat/idx, skeletons.dat/idx in my mod animations
folder and started the game. Took a minute to process but I got
to a custom battle. Quit and I now had larger packs and skeleton
files. In the idx files there are now entries for the new animation Dwarf name.
I think this is the easy half of the battle for non-standard skeleton units.~:)

[SigniferOne]

I've uploaded some very alpha animation utilities here:

http://www.twcenter.net/forums/downl...o=file&id=1341

Nice, thanks. I'll check it out soon within a few days.

[GrumpyOldMan]

Hi KE et al


I did an experiment on making new animation families.
I copied MTW2_2H_Axe directory under /data/animations
to MTW2_Dwarf_2H_Axe. I didn't change any of the .cas
files names under here. I then copied the MTW2_2H_Axe
section in descr_skeletons.txt and pasted it after that entry
and changed the animation family name to MTW2_Dwarf_2H_Axe.
I also changed the additional entries at the bottom of the section
for weapons: MTW2_Dwarf_2H_Axe_primary and the fast and slow
entries to: MTW2_Dwarf_Fast_2H_Axe, MTW2_Dwarf_Slow_2H_Axe
as well as their parent names to MTW2_Dwarf_2H_Axe.
I also changed all the paths to point to the new directory name.

Deleted the pack.dat/idx, skeletons.dat/idx in my mod animations
folder and started the game. Took a minute to process but I got
to a custom battle. Quit and I now had larger packs and skeleton
files. In the idx files there are now entries for the new animation Dwarf name.
I think this is the easy half of the battle for non-standard skeleton units.~:)

I did a bit of experimenting and deleted the dat and idx files after the initial loading of the game. Played a whole battle without them and they weren't there after I'd finished. What this means is that the dat and idx files are read into memory at the start and retained throughout, so don't expect to make 100's of new skeletons and associated animations and only have the ones you use stored in memory - they are ALL read in and stored. Keep new skeletons and animations to a minimum and consider culling any unused (in your mod) skeletons and animations.

Cheers

GrumpyOldMan

[GrumpyOldMan]

Hi All

I've been playing around with scaling and here is the result :-

https://i150.photobucket.com/albums/s104/grumpyoldman2007/th_sherwood_hobbits.jpg (https://i150.photobucket.com/albums/s104/grumpyoldman2007/sherwood_hobbits.jpg)

As you can see I've shrunk the Sherwood Archers down to 67%. It requires three main procedures :-

1. Shrink the mesh down by the required size in Milkshape (in Menu/Tools there is Scale All which allows you to do it in one step - don't worry about the size of the skeleton, this is handled by the other changes.

2. In the battle_models.modeldb make the following changes


23 hobbit_sherwood_archers
0.67 4
70 unit_models/_Units/EN_Peasant_Padded/hobbit_sherwood_archers_lod0.mesh 121
70 unit_models/_Units/EN_Peasant_Padded/hobbit_sherwood_archers_lod1.mesh 900
70 unit_models/_Units/EN_Peasant_Padded/hobbit_sherwood_archers_lod2.mesh 2500
70 unit_models/_Units/EN_Peasant_Padded/hobbit_sherwood_archers_lod3.mesh 6400
1


This is the scale control here.

3. In the descr_skeletons.txt file copy the areas required (ie mtw2_bowman) with all the anims, paste and make some changes


type MTW2_Hobbit_Bowman
scale 0.67

You have to come up with a new 'type' name and also set the scale to match all the other entries. You can leave the anims as they are. You'll also have to make similar changes to any associated skeleton/anims such as weapon and fast/slow etc. If you have a secondary weapon you'll have to make similar changes for these skeleton/anims as well.

Edit - Once you've established these, delete the dat and idx files so they are rebuilt next start up and alter the entries in the modeldb file to point to the new skeletons.

As you can see with just one scaled skeleton, across a range of weapons, could lead to a hefty increase in anim data stored in memory. Planning your skeletons and anims is pretty advisable.

Cheers

GrumpyOldMan

[KnightErrant]

@GrumpyOldMan
I have a research question and I think only you might be able to answer
it. You know the post where I reported you can copy a directory to a new
name and the game will repacked pack.dat and skeletons.dat and have the
new name in it? I was trying to get Bwian's dwarfs in-game and as an
experiment I simply tried to give a new animation name to an already in-game
unit. I mean, no change to _units, no new meshes, simply change the
animation name for a 2H_Axe unit to the new directory name in modeldb file
and see if everything works. Is doesn't even though I have a new block
in the descr_skeletons.txt file that mirrors everything in the original entry.

Say that again because it isn't clear. Copy a 2H_Axe directory from
Caliban's animations directory and call it MTW2_Dwarf_2H_Axe. That should
be the new animation family name. Copy the relevant block in
descr_skeletons.txt to the new name and change to MTW2_Dwarf_ etc.
Delete pack.dat/idx and skeletons.dat/idx in your mod folder. Edit
modeldb file to point a 2H_Axe unit to the new animation: MTW2_Dwarf_2H_Axe.
(Notice not trying to add a new unit, just trying to point an existing unit
to a copy of the exact same data.) Now start the game to rebuild the
pack and skeletons files. I die every time. So maybe you can't add
a new animation name (naw, can't be.). I got new packs and skeletons
before if I didn't have a unit that uses the new animation name but never
did this experiment. Late for me, but thought I would post to see if
anyone running unpacked could try this as well.

I'm still at patch 1.1 if anyone is wondering if that is the problem. Enough
variables in this as it is.

[GrumpyOldMan]

Hi KE


@GrumpyOldMan
I have a research question and I think only you might be able to answer
it. You know the post where I reported you can copy a directory to a new
name and the game will repacked pack.dat and skeletons.dat and have the
new name in it? I was trying to get Bwian's dwarfs in-game and as an
experiment I simply tried to give a new animation name to an already in-game
unit. I mean, no change to _units, no new meshes, simply change the
animation name for a 2H_Axe unit to the new directory name in modeldb file
and see if everything works. Is doesn't even though I have a new block
in the descr_skeletons.txt file that mirrors everything in the original entry.

Say that again because it isn't clear. Copy a 2H_Axe directory from
Caliban's animations directory and call it MTW2_Dwarf_2H_Axe. That should
be the new animation family name. Copy the relevant block in
descr_skeletons.txt to the new name and change to MTW2_Dwarf_ etc.
Delete pack.dat/idx and skeletons.dat/idx in your mod folder. Edit
modeldb file to point a 2H_Axe unit to the new animation: MTW2_Dwarf_2H_Axe.
(Notice not trying to add a new unit, just trying to point an existing unit
to a copy of the exact same data.) Now start the game to rebuild the
pack and skeletons files. I die every time. So maybe you can't add
a new animation name (naw, can't be.). I got new packs and skeletons
before if I didn't have a unit that uses the new animation name but never
did this experiment. Late for me, but thought I would post to see if
anyone running unpacked could try this as well.

I'm still at patch 1.1 if anyone is wondering if that is the problem. Enough
variables in this as it is.

No, you can get a new anim etc into the game the hobbit archers are running on new skeleton names and anims. At what point are you crashing, on start up or when you get into a battle? If it's start up, it could be something wrong with the modeldb file, it probably makes sense for the engine to remake the idx and dat files before it starts parsing the information from the modeldb which relies on the dat and idx info. Let me know at what point you are crashing, most of mine were sausage-fingered, hamfisted attempts at editing the modeldb file :beam: .

Cheers

GrumpyOldMan

[Bwian]

Check also that there isn't something wrong with the Dwarf model I sent you...it was untested in game, and I cannot be 100% sure that there isn't a hitch with the rigging.

I know from past experience that a crash will occur on a model with bad rigging. If the crash happens on the custom battle startup, with the progress bar just ove ra third along, this could be the cause.

If you swap modeldb back to a standard mesh, and th eproblem goes away...then it's 'Mr Stumpy' at fault!

[KnightErrant]

@Bwian and GOM
Yeah, this is what got me to trying a unit already in. The bones
in the dwarf are placed using angles and position offsets instead
of just offsets so the bone positions are swapped all around. The
angles are like pi/2 and so forth. So I knew I couldn't test animations
in Milkshape (or probably couldn't). The mesh should still be ok
in game because all the joint info is tossed in the back conversion,
only the anims carry that.

So I went back and just changed a Norse_Axeman to use the copied
MTW2_Dwarf_2H_Axe animation. It crashes after the splash screen
which almost always means the modeldb file checks out syntax-wise.
(Still doesn't rule out texture errors etc because it doesn't check that
on initial load.) It wasn't rebuilding pack.dat or skeletons.dat because
I didn't delete them (hadn't put anything new in).

This was pretty late at night so I'll just do it all again tonight and
maybe I'll spot what I'm doing wrong. I have gotten all the anims
converted to what I think is the new skeleton. What I did is just take
the offset data in dwarf.ms3d and just force them into the correct
x, y, z slots based on the standard skeleton with x->-x like always.
They look right, basically lowerleg and foot offsets are about 75%
of the standard skel, and shoulders look a little heftier otherwise
mostly the same.

[GrumpyOldMan]

Hi KE


@Bwian and GOM
Yeah, this is what got me to trying a unit already in. The bones
in the dwarf are placed using angles and position offsets instead
of just offsets so the bone positions are swapped all around. The
angles are like pi/2 and so forth. So I knew I couldn't test animations
in Milkshape (or probably couldn't). The mesh should still be ok
in game because all the joint info is tossed in the back conversion,
only the anims carry that.

In Milkshape there is a tool under Menu/Tools - Zero Joints thats sets all the joint rotations to 0, this may be useful here. You could try to test animations but it would mean a bit of cutting and pasting from Milkshape ascii exports of the figure and the animation (ie figure positions from the figure ascii and translations and rotations from the anim ascii) and reexporting the amalgamated results to smd so you can load it on the figure.


So I went back and just changed a Norse_Axeman to use the copied
MTW2_Dwarf_2H_Axe animation. It crashes after the splash screen
which almost always means the modeldb file checks out syntax-wise.
(Still doesn't rule out texture errors etc because it doesn't check that
on initial load.) It wasn't rebuilding pack.dat or skeletons.dat because
I didn't delete them (hadn't put anything new in).

This was pretty late at night so I'll just do it all again tonight and
maybe I'll spot what I'm doing wrong. I have gotten all the anims
converted to what I think is the new skeleton. What I did is just take
the offset data in dwarf.ms3d and just force them into the correct
x, y, z slots based on the standard skeleton with x->-x like always.
They look right, basically lowerleg and foot offsets are about 75%
of the standard skel, and shoulders look a little heftier otherwise
mostly the same.

Let us know how you go, if you're still having problems post up all your changes so we can apply the scourge and scalpel :beam:

Cheers

GrumpyOldMan

[Casuir]

I did a bit of experimenting and deleted the dat and idx files after the initial loading of the game. Played a whole battle without them and they weren't there after I'd finished. What this means is that the dat and idx files are read into memory at the start and retained throughout, so don't expect to make 100's of new skeletons and associated animations and only have the ones you use stored in memory - they are ALL read in and stored. Keep new skeletons and animations to a minimum and consider culling any unused (in your mod) skeletons and animations.

Are you sure about this grumpy? the game wont let me do anything with these files while its running, says they're being used by another program.

[GrumpyOldMan]

Hi Casuir


Are you sure about this grumpy? the game wont let me do anything with these files while its running, says they're being used by another program.

Yes, I just tried it again, and changed the mtw2_bowman folder name to ~mtw2_bowman as well (the folder storing the animations for the figures I had in battle) in case it was running off the unpacked files, and the game ran without a hiccup. I deleted the files after choosing the single player option but before making any choices at the single player screen.

I just checked my cfg file in case I've got anything funny in there but it matches vanilla.

Cheers

GrumpyOldMan

[KnightErrant]

Mea culpa, as usual. I think I have an 11th commandmant:

Thou shalt not touch the modeldb file after 11:00 PM.

I got my computer modified animations to work in-game with
Norse Axemen. Here's a picture of the darling little babies:

https://img157.imageshack.us/img157/2070/ittybittynorsementm7.th.jpg (https://img157.imageshack.us/my.php?image=ittybittynorsementm7.jpg)

Unfortunately, the animations are terrible so just scaling isn't going to
do it. I know these are full-sized meshes, but I couldn't even get them
to walk, they just sort of wander around and bob in place.
Also, there must be some other defaults in place because they sometimes
pop up to full size indicating just changing the anims in a copied directory
isn't enough, there's other anims that they use. Haven't tried the dwarf yet,
just happy to see these working, but this approach isn't going to be a piece
of cake.

Edit: Just tried the dwarf and got a crash with unspecified error. Only changes
are the modeldb and EDU. Copied Norse Axeman entry and left textures the
same. EDU is a copy of Norse Axemen as well. Only have the lod0 mesh so I
used a single mesh (prefaced by 1 1) with 6400 as its unit squared radius.

Edit2: Definitely a mesh problem. Replaced dwarf_lod0.mesh in modeldb by the
Norse_Axemen_lod0.mesh but left them called baruk_khazad in modeldb and EDU and
it worked. Looking at the dwarf.ms3d file now to see what could be bad.

[Bwian]

I'll have a look at the Dwarf tonight, and send you a fixed version! I suspect the rigging to be at fault. That will crash the game every time.

Since this, I have taken to assigning every vertex to the ABS bone first, then starting to rig. this way, I know all the vertices have an assignemnt, and the model will always work. Not necessarily as expected ... but they will work!

[Casuir]

@GOM, v strange, mine wont and I've tried a good few times, are you running the animations from a mod folder or the stock one?

@KE Nice work, mighnt hurt to make them a bit bigger though, they'll get lost in the grass.

[KnightErrant]

@Casuir
Aye, I've scaled them too small but I've grown fond of the wee
axe-wielding devils. I'll make a new modeldb entry for them:
meadow_demons.:laugh4:

[GrumpyOldMan]

Hi Casuir


@GOM, v strange, mine wont and I've tried a good few times, are you running the animations from a mod folder or the stock one?

I did a fresh install, updated with 1.1 and 1.2, I'm running it from the main folder (I don't have any mod folders set up). I even took away any renamed copies I had of dat and idx files from anywhere near the mtw2 folder.


Don't know why I can do it and you can't. You're making me paranoid now :dizzy2: :dizzy2:

Cheers

GrumpyOldMan

[GrumpyOldMan]

Hi KE


@Casuir
Aye, I've scaled them too small but I've grown fond of the wee
axe-wielding devils. I'll make a new modeldb entry for them:
meadow_demons.:laugh4:

The mind boggles with all sort of naming possibilities:-

The RugRat Rangers of Aragon
The Ankle Biting Huscarls of Benelong
The Ninja Kneecappers of Narnia

Etc, etc. :laugh4: :laugh4: :laugh4:

Cheers

GrumpyOldMan

[Casuir]

I'm more nervous, if you can delete them and I cant what program is using my files? Be nice if someone else tests this and see what results they get.

[KnightErrant]

Bwian, your ms3d file was fine. Converted to .mesh and
well, most of the way there:

https://img299.imageshack.us/img299/8794/dwarfsalmostthereqp6.th.jpg (https://img299.imageshack.us/my.php?image=dwarfsalmostthereqp6.jpg)

I'll have to check my animations because they still won't walk forward.
And they pop up to full size and back randomly as they use some other
animations. I'd better do this one step at a time to see what I'm messing
up

[GrumpyOldMan]

Hi KE


Bwian, your ms3d file was fine. Converted to .mesh and
well, most of the way there:


I'll have to check my animations because they still won't walk forward.
And they pop up to full size and back randomly as they use some other
animations. I'd better do this one step at a time to see what I'm messing
up

I had the popping effect when I was doing a search and replace on float values, because sometimes the floats won't be exactly the same but will be the same decimally to 6 decimal places. With the walking are you taking the position keys from bone_pelvis or the Scene Root? I'm having another look at Mete's specs on anim and time to see what we are doing.

Cheers

GrumpyOldMan

[KnightErrant]

Hi GrumpyOldMan,

Haven't done anything more today, out in the heat working on
the garden. What I had thought was that there were more animations
in descr_skeletons.txt that weren't in MTW2_2H_Axe and that these
were what I was popping into. There are others, but they are like swim
and crew animations so I don't think these are it.

My understanding of the full format cas file data is that it is,
ignoring all the header, time ticks, hierarchy, and bone data:

Section 1:
quats for all the bones but not Scene_Root. These follow the bone
section.

Section 2:
For want of a better word or definition, anim data but only for bone_pelvis
even though this is followed by bone chunks with frame animations but
these are only deltas. I thought scaling these to match the reduced
skeleton would make the animations "sort of ok but not perfect".

Section 3:
After the anim data is the basic pose data for all bones plus Scene_Root
but Scene_Root and bone_pelvis mostly seem to be float zeros. This is
where I'm putting Bwian's new skeleton.

What I think I should try is (1) Try the dwarf with regular animations. This
isn't right but what does it look like? Probably too big a figure.
(2) Change only skeletons, the third section of data, but leave quats and
anim data with default values. Figures should be smaller but anims
might move too much laterally and the y values might stretch the figure
like playing with the bounding sphere did.. (3) Scale section 2,
the anim data, this is what I already did hoping for a brass ring but this
doesn't seem to work but I haven't hexed through to see if my script is
actually making the changes I think it is.

Now that you describe what you see with changing float values, I'm wondering
if something else is going on but I can't imagine what. I haven't tried
just checking anims by merging them in Milkshape because my fullanimmerge
script bombed on the old dwarf .ms3d file. The new one works in game
so it should be ok now. This would be a good check, just haven't tried it
yet. Curse summer! I got more done in February....:laugh4:

[GrumpyOldMan]

Hi KE


Hi GrumpyOldMan,

Haven't done anything more today, out in the heat working on
the garden.

Good to see somebody working to even up the scales for us loafers :beam: :beam: . Finally got some cooler weather here but had to stand in drizzle watching the eldest play today.


What I had thought was that there were more animations
in descr_skeletons.txt that weren't in MTW2_2H_Axe and that these
were what I was popping into. There are others, but they are like swim
and crew animations so I don't think these are it.

My understanding of the full format cas file data is that it is,
ignoring all the header, time ticks, hierarchy, and bone data:

Did you catch Caliban's post in the other thread https://forums.totalwar.org/vb/showpost.php?p=1535732&postcount=589 about the makeup of basepose and normal cas anims files?


Section 1:
quats for all the bones but not Scene_Root. These follow the bone
section.

Section 2:
For want of a better word or definition, anim data but only for bone_pelvis
even though this is followed by bone chunks with frame animations but
these are only deltas. I thought scaling these to match the reduced
skeleton would make the animations "sort of ok but not perfect".

I think this is the translation area for the frames and if you're not able to move properly forward this may be where you are having problems with the z movement of the pelvis and its values.


Section 3:
After the anim data is the basic pose data for all bones plus Scene_Root
but Scene_Root and bone_pelvis mostly seem to be float zeros. This is
where I'm putting Bwian's new skeleton.

What I think I should try is (1) Try the dwarf with regular animations. This
isn't right but what does it look like? Probably too big a figure.
(2) Change only skeletons, the third section of data, but leave quats and
anim data with default values. Figures should be smaller but anims
might move too much laterally and the y values might stretch the figure
like playing with the bounding sphere did.. (3) Scale section 2,
the anim data, this is what I already did hoping for a brass ring but this
doesn't seem to work but I haven't hexed through to see if my script is
actually making the changes I think it is.

Now that you describe what you see with changing float values, I'm wondering
if something else is going on but I can't imagine what. I haven't tried
just checking anims by merging them in Milkshape because my fullanimmerge
script bombed on the old dwarf .ms3d file. The new one works in game
so it should be ok now. This would be a good check, just haven't tried it
yet. Curse summer! I got more done in February....:laugh4:

I think we may have to revisit the anim formats and get definitive values for everything again to make sure that we are translating and retranslating everything ok.

I looked again at the anims you're producing and Mete's specs and output from ascii and binary formats. I'm pretty sure now that the time mentioned in the ms3d formats deals with frames rather than actual times. The frame rate and therefore the time elapsed is controlled through the FPS rate in the menu/file/preferences window. We may have to look at a calculation to move between the two formats.

Off to put my boots in front of the fire and commiserate with my sportsman (the team lost rather badly today).

Cheers

GrumpyOldMan

[KnightErrant]

Still kickin', just don't have much tonight. Here's the dwarf with
just regular animations, in a modded folder but nothing changed.
These guys will walk forward.

https://img504.imageshack.us/img504/1658/dwarfsreducedskeletonswh0.th.jpg (https://img504.imageshack.us/my.php?image=dwarfsreducedskeletonswh0.jpg)

The next is just changing the third section of the anims file or .cas file,
all I did was change to a new skeleton:

https://img299.imageshack.us/img299/8794/dwarfsalmostthereqp6.th.jpg (https://img299.imageshack.us/my.php?image=dwarfsalmostthereqp6.jpg)

The little guys are little but they don't obey a movement order, they just pop
up and down to full size. At least this removes animations, the game doesn't
like non-standard skeletons, maybe, what do we need to do to get this to work?

Ok, I did something this weekend, apologies to Bwian who worked on the
dwarf. I thought I would get to test more. Remember, this is 1.1, I haven't tried
the 1.2 patch until this is resolved. (I know it isn't textured, don't know much
about this part, I thought they were silver if the texture paths were wrong.)
Modeldb for this:


16 -0.090000004 0 0 -0.34999999 0.80000001 0.60000002
12 baruk_khazad
1 1
56 unit_models/_Units/EN_Lmail_Hmail/baruk_khazad_lod0.mesh 6400
1
7 denmark
56 unit_models/_Units/EN_Lmail_Hmail/textures/dwarf.texture
63 unit_models/_Units/EN_Lmail_Hmail/textures/dwarf_normal.texture
44 unit_sprites/denmark_Norse_Axemen_sprite.spr
0
1
4 None
17 MTW2_Dwarf_2H_Axe 0
2
25 MTW2_Dwarf_2H_Axe_primary
14 fs_test_shield 0
16 -0.090000004 0 0 -0.34999999 0.80000001 0.60000002


The anims names are in place, don't know what else to try at the moment.

[GrumpyOldMan]

Hi KE


Still kickin', just don't have much tonight. Here's the dwarf with
just regular animations, in a modded folder but nothing changed.
These guys will walk forward.

https://img504.imageshack.us/img504/1658/dwarfsreducedskeletonswh0.th.jpg (https://img504.imageshack.us/my.php?image=dwarfsreducedskeletonswh0.jpg)

The next is just changing the third section of the anims file or .cas file,
all I did was change to a new skeleton:

https://img299.imageshack.us/img299/8794/dwarfsalmostthereqp6.th.jpg (https://img299.imageshack.us/my.php?image=dwarfsalmostthereqp6.jpg)

The little guys are little but they don't obey a movement order, they just pop
up and down to full size. At least this removes animations, the game doesn't
like non-standard skeletons, maybe, what do we need to do to get this to work?

I'll go back tomorrow and have a look at cas anim format again and your previous post to see what's been going on. Did you set up the basepose cas as per their format, rather than the normal anim format?


Ok, I did something this weekend, apologies to Bwian who worked on the
dwarf. I thought I would get to test more. Remember, this is 1.1, I haven't tried
the 1.2 patch until this is resolved. (I know it isn't textured, don't know much
about this part, I thought they were silver if the texture paths were wrong.)
Modeldb for this:


16 -0.090000004 0 0 -0.34999999 0.80000001 0.60000002
12 baruk_khazad
1 1
56 unit_models/_Units/EN_Lmail_Hmail/baruk_khazad_lod0.mesh 6400
1
7 denmark
56 unit_models/_Units/EN_Lmail_Hmail/textures/dwarf.texture
63 unit_models/_Units/EN_Lmail_Hmail/textures/dwarf_normal.texture
44 unit_sprites/denmark_Norse_Axemen_sprite.spr
0
1
4 None
17 MTW2_Dwarf_2H_Axe 0
2
25 MTW2_Dwarf_2H_Axe_primary
14 fs_test_shield 0
16 -0.090000004 0 0 -0.34999999 0.80000001 0.60000002


The anims names are in place, don't know what else to try at the moment.

When I've been working with one texture figures, I still take a copy and place it in the attachmentsets and refer to it in the modeldb in case this makes it fallover/act strange. I did notice that even if I still put in a reference to an attachment set texture but used the same texture file as the figure texture I got a similar glowing white effect on the weapons, etc. Try it with copies of the texture in attachmentsets and a reference to an attachmentset texture in the modeldb and see if that clears up the 'shinies'.

I'll report back on what I find later.

Cheers

GrumpyOldMan

[Bwian]

Likewise with the second texture ... I have had some VERY odd effects from not using it. Parts of the model not appearing ( even though they used another texture ) and so forth. The game seems to assume that it will find a second texture, and act on that assumption.

Most of the models I have put in game so far have only required a single texture. I have not got enough need for basic variations to require a second texture...but I always assign the material to something and put in a second texture. Too many bizarre failoures when I didn't!

[Casuir]

The mesh format is set up to use two textures, usng a copy of the first one is the same as using a completely different texture and pretty wasteful, far better to split the textures for two models over two textures and minimise resource usage. In our case bwian we can work out what goes where when all the units are done for a faction, like i said on the warhammer forum I'm concerned that its an area thats going to cause problems.

[KnightErrant]

@All,
Many thanks on the suggestions, I'll put in an attachment sets
entry tonight and see what happens. For skeletons I think I'll
try just varying the bones of the standard skeleton slightly
smaller and see how far I can push it until I get funny behavior.

[Bwian]

Casuir ... I am not using a copy of the texture .... it's the same texture. The 2 references are both pointing to the identical texture. For some reason, the thing just seems to want 2 entires in modeldb to satisfy itself.

[Casuir]

Aye but I'm wondering does the game recognise it as the same texture or does it just load the same one twice? Its set up for two textures so it might just treat the two entries as two different files. If theres some conflict there when it goes to render the texture it could cause glitchs in the model, not sure what else would cause it, or if that would for that matter. Could be the game has a problem when its recalculating and applying the uv co-ords, the two textures are treated as one for that purpose in the .mesh, could be having prob's applying both sets to the same texture. Splitting the texture into 2 1024*512 pieces should get around it too, I think all meshs of the same type have to be on the same tex though.

[KnightErrant]

I thought I knew modeldb if anything, but had to start all over
from a backup copy to get to here:

https://img512.imageshack.us/img512/1508/textureddwarfsft0.th.jpg (https://img512.imageshack.us/my.php?image=textureddwarfsft0.jpg)

Finally have textured dwarfs with regular skeletons. Now to try making smaller
skeletons. I put the same textures for attachment sets as I did for the bodies
and that seems to work. Many thanks for the help! :shakehands:

[GrumpyOldMan]

Hi KE et al

I've revisited the cas anim format for my own curiosity and to get it clarified in my own head.

The first 42 bytes are generic header that are the same for all files.

Next we have the size of the file less the total of 42 bytes from the header and either 223 bytes for the generic basepose.cas footer or 192 bytes of the generic 'normal' cas footer.

Then there is a long integer '0' and then a long integer for number of bones (including the 'Scene Root') - num_bones.

Next we have an hierarchy table num_bones * long integer starting at 'Scene Root'. For this table both Scene Root and bone_pelvis are treated as animation bases (??). The hierarchy table is constructed as follow:-

Bone index for bone set by position in table - index of parent bone (a parent of '0' indicates an animation base)

Now we have a long integer showing number of frames of animation - num_frames

Next is the timing in long integers - 0 to num_frames-1 * .05 (length of time to show a frame at 20 fps).

Now we have two more chunks, a bone header chunk and the animation data chunk.

Bone header chunk

Each bone sub-chunk within the bone header chunk contains as follows:-

long integer - number of characters in '0' terminated name

string - '0' terminated name

long integer - number of rotation frames for bone

long integer - number of translation frames for bone

long integer - starting position in bytes of first rotation data within animation data chunk

long integer - starting position in bytes of first translation data within animation data chunk

long integer - '0'

long integer - '1'

byte - '0'

Animation Data Chunk

Rotation values - Quaternion values (4 * float) * num_frames * num_bones - 1 (the Scene Root has no animation values)
Translation values - XYZ (3 * float) * num_frames * num_bones-1 (the Scene Root has no animation values)

Next comes the default position of the bones - num_bones * XYZ (3 * floats) - Scene Root is included, this must be the default frame that Caliban has mentioned.

Finally we have the generic footer for either human basepose or 'normal' human anim. NB Mounts use different footers to humans, the basepose is similar to 'normal' human anims but the 'normal' mount anims have more detail but still appears generic within horses anyway. Camels are a bit all over the place, I've counted 4 different cas versions so far, elephants seem pretty straightforward.

I feel a bit better now that I've revisited the format and understand it better. Hope you guys find it handy.

Cheers

GrumpyOldMan

[KnightErrant]

@GrumpyOldMan,

I was doing a Powerpoint file format block diagram for this!!!! Got me!!!
Sort of like those things in the mesh documentation. Anyway,
this is good. The basepose and the flailing ones have variants
where the quats and pose numbers are different but they can
be traced through. The bone section tells you how many frames
are included for each, the flailing ones are sometimes missing frames
for some bones but the info is there to tell you how many bytes to
process.

@All

Got it to work!!!!!!!!! Dwarfs with shortened legs only.:jumping:

https://img508.imageshack.us/img508/8513/dwarfsingameag0.th.jpg (https://img508.imageshack.us/my.php?image=dwarfsingameag0.jpg)

The anims work but are a little funny. I didn't scale them, only changed
the skeleton data in the third data block of GOMs exposition. So the dwarfs
float slightly above the ground and they walk and run funny; sort of an
inverse moonwalking where they "skate" too fast for what their legs are
doing. This at least is what I thought they should do. Now to try scaling
back the x and z traversal numbers in section 2 where the animation movements
live along with the delta values.

[GrumpyOldMan]

Hi KE


I thought I knew modeldb if anything, but had to start all over
from a backup copy to get to here:

Who knows what evil lurks in the hearts and minds of modeldb files, only the Shadow knows..... :creep: :laugh4: :laugh4:


https://img512.imageshack.us/img512/1508/textureddwarfsft0.th.jpg (https://img512.imageshack.us/my.php?image=textureddwarfsft0.jpg)

Finally have textured dwarfs with regular skeletons. Now to try making smaller
skeletons. I put the same textures for attachment sets as I did for the bodies
and that seems to work. Many thanks for the help! :shakehands:

I've gone through the cas files again for my own clarification and if you set up the basepose cas files with the new skeleton positons, and modify the translation values by the same ratio you shrunk the skeleton and modify the skeleton positions within each cas file, logic says that it should run :logic: but my logic has been known to be wrong before :beam:

Edit:- Curse this cross-posting mayhem :laugh4: :laugh4:

Cheers

GrumpyOldMan

[GrumpyOldMan]

Hi KE



@All

Got it to work!!!!!!!!! Dwarfs with shortened legs only.:jumping:

https://img508.imageshack.us/img508/8513/dwarfsingameag0.th.jpg (https://img508.imageshack.us/my.php?image=dwarfsingameag0.jpg)

The anims work but are a little funny. I didn't scale them, only changed
the skeleton data in the third data block of GOMs exposition. So the dwarfs
float slightly above the ground and they walk and run funny; sort of an
inverse moonwalking where they "skate" too fast for what their legs are
doing. This at least is what I thought they should do. Now to try scaling
back the x and z traversal numbers in section 2 where the animation movements
live along with the delta values.

Huzzah!!, Huzzah!!, great strides indeed. :cheerleader: :cheerleader:

I'm just off to finish all the anims for the dragon mount and see if mtw2 works without descr_mount.txt :beam: :beam:

Cheers

GrumpyOldMan

[KnightErrant]

Cross posting indeed,.best of luck with the dragon mounts. I know
what you mean about logic, thought this was a slam dunk days ago,
now I'm worried that any new change has me back with the wee silver
guys hiding in the meadow and biting ankles. Damn the modeldb!
full speed ahead!

[KnightErrant]

Last post for the evening. Calculated the reduced limb size for the
dwarves. Got a value of 0.6946655 for the reduced limb size and
used this to scale x, y, and z for the animations and put Bwian's
skeleton in with increased shoulder breadth as well as smaller leg
limb size. Anims still work. Ok, realistically, I can still tell the walk
and run anims aren't quite right and someone would have to hand
tune them. The fight anims look good so maybe this is good enough for
prototyping and maybe someone with patience could tune the scaling
values to be better. I know a still frame can't convey anim stuff
but, for Bwian, here's your Dwarves kicking the snot out of some upstart
armored sergeants.

https://img518.imageshack.us/img518/9958/fulldwarfsfn4.th.jpg (https://img518.imageshack.us/my.php?image=fulldwarfsfn4.jpg)

I'll play with scaling values some more tomorrow and clean up the code
a bit so its not so hard-coded and can be used for other units. Might as well
go the other way and try some giant units next to see if the other end of
the scale holds any suprises.

[Caliban]

Awesome! The dwarves look very cool :)

[Casuir]

Nice work KE

[Bwian]

Barak Khazad! Khazad aimenu!

[KnightErrant]

Just a quick update. Got fullanimmerge to work with
the dwarf.ms3d. (Kept bombing because no group comments so
coded around that.) Its very easy to see what's going on with
the basic animations in Milkshape like ...walk.cas and ...run.cas.
The anims still looked funny because the dwarves were still floating
a quarter foot or so above the y=0 plane. Can even detect a little
overstriding too so I think by scaling and using Milkshape for checking,
this might be automated better than I had thought.

@Bwian
Just want to clean up the code a little and test some more, then write
up the procedure to get dwarves in-game and iterate on the scaling
values. I'm MIA tomorrow night (wife's birthday) so maybe Thursday I
can zip everything up and send it on.

[GrumpyOldMan]

Hi KE


Just a quick update. Got fullanimmerge to work with
the dwarf.ms3d. (Kept bombing because no group comments so
coded around that.) Its very easy to see what's going on with
the basic animations in Milkshape like ...walk.cas and ...run.cas.
The anims still looked funny because the dwarves were still floating
a quarter foot or so above the y=0 plane. Can even detect a little
overstriding too so I think by scaling and using Milkshape for checking,
this might be automated better than I had thought.

Good to see that you've got it working. With the floating, did you scale the 'y' value for the pelvis translation values? You'd think that would solve the floating issue. I've been in touch with Mete and I got confirmation that the 'time' he mentions in the specs is actually 'timing' ie which frame rather than time elapsed. I've made the following changes to the 'Joints Section' :-


for jj in range( nframes ) :
frameoffset = 3 * jj
newframe = jj + 1
idx = boneoffset + frameoffset
xang = eulers[idx+0]
yang = eulers[idx+1]
zang = eulers[idx+2]
putfloat( newframe, fidms3d )
putfloat( xang, fidms3d )
putfloat( yang, fidms3d )
putfloat( zang, fidms3d )
time = time + 0.5
time = 0.0
for jj in range( nframes ) :
frameoffset = 3 * jj
newframe = jj + 1
idx = boneoffset + frameoffset
putfloat( newframe, fidms3d )
putfloat(-posefloats[idx+0], fidms3d )
putfloat( posefloats[idx+1], fidms3d )
putfloat( posefloats[idx+2], fidms3d )
time = time + 0.5

This puts the correct timing in and lets the animations run in Milkshape. Forgive me for playing with your code, but I couldn't help myself :beam:



@Bwian
Just want to clean up the code a little and test some more, then write
up the procedure to get dwarves in-game and iterate on the scaling
values. I'm MIA tomorrow night (wife's birthday) so maybe Thursday I
can zip everything up and send it on.

Wish your wife a happy birthday, don't expect to hear from you - nobody said this was a suicide mission here :beam: :beam:

Cheers

GrumpyOldMan

[Bwian]

Definitely a big 'hoorah' for the animators ... and a happy birthday to 'Mrs Errant'

Never EVER neglect a wife on her Birthday....Couches are not comfortable places to sleep....and it's virtually impossible to find someone else willing to do the laundry for such reasonable rates :clown:

[KnightErrant]

Definitely, if Mrs. Errant isn't happy, no one is happy.

I'll make the changes from time steps to frame numbers to be
consistant. The anims seem to use the FPS number for timing.
I've got it set at 0.5 and that makes them slow enough to see
each frame. Now that fullanimmerge works on files without
group comments I was able to change the y scale factor from
my calculated 0.6946655 to 0.64 and got this:

https://img400.imageshack.us/img400/6012/walkanimfa5.th.jpg (https://img400.imageshack.us/my.php?image=walkanimfa5.jpg)

The left viewport, upper right corner, is the one being animated.
Got the feet right on the y=0 plane so they shouldn't have the floating
look anymore.

[Bwian]

That looks absolutely spot on :beam:

Great work!

[Dogman55]

Hah that looked pretty complicated... all that coding and stuff. But it's good to hear your making progress! Can't wait!

[KnightErrant]

Still working on utilities: Both of GrumpyOldMan's infos/corrections are
absolutely invaluable: (1) menu/tools/zero rotations is vital to getting
anims to work if the skeleton was rigged with rotations (2) the time
field for anims actually being framenumber now lets me single step
through the anims. Before the anims would play alright but single-stepping
would freeze halfway through.

Found multiple errors in fullanimmerge related to uv coords. Cutting and
pasting from the meshconverter.py code was responsible for most of these
since the data gets reformatted to go back to the mesh. Refactored all
the code into a library and started redoing all the utilities from scratch.
animmerge now at least can do textures like this:

https://img523.imageshack.us/img523/1696/newanimmergeresultsed3.th.jpg (https://img523.imageshack.us/my.php?image=newanimmergeresultsed3.jpg)

but the run anim isn't scaled right. At least this is easier to work with
rather than doing each utility as a standalone. I'll just package them all
together with one GUI with buttons to run what the user wants.
As usual, everything takes twice as long to do as one thinks. :wall:

For now I'm going to ignore the variants for animmerge but not for the
skeletonexporter. The variants so far seem to be the basepose and
the flailing anims (and mount animations, not even considering these yet).
The six ints and the zero byte after the bone names are just what
GrumpyOldMan said: quatframes, animframes, quatoffset, animoffset, zero,
and the 1 int seems to indicate the pose data since Scene_Root has it
but no other frames. The basepose anim goes like this for 2H_Axe:

no quatframes, no animframes, only the 21 (nbones plus Scene_Root) skeleton
data with a nonstandard footer containing
CaozSceneCustomAttribNode01, CaozSceneCustomAttribNode02
but the rest is regular. The int value after the pose data is 135 and not
104 so maybe this signals that.

The flailing ones are complicated:
MTW2_die_flailing_cycle.cas doesn't have a footer and this may be signaled
by the signature bytes at offsets 28, 29, and 30 which are hex 9A 9A 9A
or 154 154 154 in decimal. In normal .cas files these bytes are zero.
The other signature bytes are at offsets 39, 40, and 41, right before the
file size sans header/footers int. These are hex 3F 3F 3F (decimal 63 63 63)
which are normally hex 66 66 66 (decimal 102 102 102). And it gets
worse, bone_RClavical doesn't have quatfloat frames or animfloats frames
and neither does bone_LClavicla. You have to add the frame numbers for
each bone separately to get the right number to export a skeleton.
(This file is in descr_skeleton.txt so you have no choice but to deal with it.)
Trying to get anims into Milkshape with bones left out is a problem I'll
leave for later.

MTW2_die_flailing_cycle_to_land.cas also doesn't have a footer but its
signature bytes are zero at offsets 28, 29, 30 and at offsets 39, 40, and 41
they are zero which is non-standard. Basically, I can deal with these
variants by looking for 102 102 102 at offsets 39, 40, and 41.
The right and left clavicals are also missing quatframes and animframes
so they also would be harder to program to merge animations.

Going to ignore the variants in regards to merging for now and just
make sure the export skeleton function can handle them to be able to do
non-standard skeleton units. This will take a bit of time.

[Bwian]

That sounds like really good progress .... er ..I think! After I filtered out the bits I didn't understand, ther ewere lots of gaps, but there were also lots of bits about bug fixing and the GUI and dealing with the last few animations that don't follow the pattern of the bulk of them. They look, if I were a cynic, as though CA took a few short-cuts with the animations that you don't really see close up or regularly :inquisitive:

[KnightErrant]

I think its progress... mixed with blowing off steam at finding a lot of
my mistakes.:embarassed: I think there's rhyme to the reason with the
differing cas formats, I'm just missing the RTW experience with the .cas
file format. The exporting skeletons bit is ok I just want to move it to the
new library functions which is why I'm stuck on getting animmerge right,
it seems to be best way to check if the scaling is ok or not. Looking
at animations in game is too hard, no grids to look at to see if the
y-offsets are right or not.

I'm hoping for rain tomorrow, can't be sent out of the house to do yard
stuff.:laugh4: Seriously, thought I'd be done this weekend, but looks like
a couple more days. This is what looks like it would be useful:

animmerge - take a .cas animation and merge with a unit to look at animations
in Milkshape for final tweaking, either in Milkshape for a single
animation or to change scaling values to do a whole family of
animations. This is almost right, I'm just working out a rational
naming scheme: seems the best way to keep track of what
one is doing is to combine the base unit .ms3d name with the
animation .cas file name a la

armored_sergeants_lod0_animby_MTW2_Spear_walk.ms3d

This way the user can know just by looking at the new file name
what he was doing. Also might be useful for animextract to
know what to name the extracted animation, maybe with
"_modified" so it doesn't overwrite something.

animextract- less important, but needed if people want to tweak a few really
important common animations like walk, run, run_to_charge, etc.
Pulls the new animation frames out and makes a new .cas file.

exportskeleton - final name for writing non-standard skeleton to all the .cas
files in a directory and scaling the animation floats. This works
already, just want to use the new library functions.

extractskeleton - little utility for pulling a skeleton out of a .ms3d file after
a modeler has rigged a new skeleton. Already done with the new
library functions, sort of comes for free with the general
.cas reader.

castotxtconverter - Don't know if this is needed but its been helpful to
survey animations. Reads a cas file and converts all the fields
to ASCII and writes out the equivalent file in ASCII. This is done
already.

txttocasconverter - Probably not necessary. Users will probably only modify
animations in Milkshape and not change rotations or animation
translations by hand. If this seemed useful to someone it
could be done but I'll rank it last for now.

[GrumpyOldMan]

Hi KE et al

It sounds like you're doing really well, don't worry about the completion date - when I used to look at IT specs and estimates, I always multiplied the estimated time by 1.5 and the estimated money by 2.5 :beam: :beam: , it was so accurate it was scary :laugh4: :laugh4: .

Just to add some more angst to your deliberations, I've been looking at the rider figures and they have some variations that don't play ball with your current animmerge either. They seem to have been exported using two different variations on the export screen that Caliban posted a picture of. Some have been saved with full rotation and translation values but others have been saved without any translation frames apart from the pelvis (which is all zeroes anyway). Amongst both these variations some have frames for clavicles and some don't. Also some have two extra bytes in the footer because they have 'CustomAttribNode 1' rather than 'CustomAttribNode'. I shudder to think what we'll find when we look carefully at the camels, I saw one that had 4 'CustomAttribNode' entries.

On an up note, Milkshape will take anims that have different numbers of frames across bones, so if you export an anim with 61 frames for everything except the clavicles which have one 0 frame each, this is still a valid anim. The only point to watch is that you have the same number of keyframes for rotation and translation for each individual bone - ie if you have 61 frames of rotations then you need 61 frames of translations (even if they are all 0 entries).

I've been looking at what has to be done to update the mesh converter so it will work in with new skeletons. I'll have to go to a template system. The converter, currently, is using a vanilla mtw2 human template. I'll have to write a process so that the converter can extract a template from a ms3d file and write the bits and ms3d parts that are required. This way people will have to select which template to use when converting a mesh to ms3d or vice versa. So if you wanted to extract the Hospitaller knight with Bwians Dwarf skeleton and rework the mesh to fit the skeleton it could be done. We'll have to look at adding bones and where they should go ie before or after the weapon/shield bones in the mesh. I did an experiment and extracted these bones from meshes but it crashes the engine. I suspect that any new bones will have to go after these bones because of bone index numbers (I hope not) but this will make writing interactions between mesh and anim processes a bit more difficult.

Cheers

GrumpyOldMan

[KnightErrant]

Yikes, this is getting complicated... but if looked at correctly that means
fun. Good advice, one thing at a time. Leaving camels and others aside,
at least some of the stratmap anims look normal, meaning like the battlemap
ones. I've tried to make the library cas reader read every field since there's
no knowing what field actually means anything until all the variations are seen.
I do remember you saying the adventure would continue, prescience can be
scary.~:)

I never get anything done on weekends anymore. Just another push this week
and maybe things come together. I think you're right about the mesh converter;
only a template system seems to make sense to deal with the variations already
in game and those that people with mods would want to work with. I think
the system for this can't be done with little utils here and there, someone is
going to have to pull it together to make a standard interface for meshes and
anims since they are so closely tied together. (I nominate you of course and
volunteer for research assistant.) I have read the e-mails re
chariots and testudo anims and did not realize just how rich this could be.
Really got me thinking now, animations could be so much more interesting
than I thought when I started.:2thumbsup:

[SigniferOne]

Man you guys are amazing. GOM, just don't put a bucket on your head and start saying "I am your father" :laugh4: You two rock.

[Bwian]

Mk 1 Guinea Pig takes the plunge!

Step 1 .... Animation folder copied and renamed ...check. Didn' rename any files in the folder...just the folder itself.

Step 2 .... Renamed the two 'bad' files that are not in the descr_skeleton

Step 3 .... bottled this one, and used the supplied skeleton! Will try to extract my own when I have this working with yours.

Step 4 .... hit the export skeleton button ( using your skeleton ) and I get exactly what you said I would. A sub directory 'convertedfiles' with a copy of all the animations in it. No evt files. feeling comfy so far.

Step 5 .... run the anim-merge and got an MS3D file OK. Ran it in MS3D onthe keyframer, and the model animated correctly. I noticed that the 'floor' was not where the guy walked... but I wasn't overly worried at this stage. What I could clearly see, though, was thet the bones were in the correct place for my model, and not the stock one. Also, the movement was correct and the mesh was not deforming in any unexpected way. So..I press on!

Step 6 .... skipped the convert to txt effort ....wasn't sure I would know what I was looking at, so I pressed on. I will come back to these steps if I have a failure, or feel I need to understand a bit more about this!

Step 7 .... Converted Dwarf ( used the one I had previousely zeroed...seemed to work fine. On comfortable ground here, done this bit many times!

Step 8 .... Slotted the mesh into my Warhammer mod directory ( made sure, while I was at it that I had removed my current animation files so it would generate a fresh one ) and updated the modelsdb and unit files. Again...on safe ground here!

Step 9 .... pasted in the chunk of animation from your file, rather than just use yours. Getting brave now!

Step 10 .... RUN THE GAME! Ahhh...it fails. Despair. Then....shame... :embarassed: I had forgotten to put the textures in the mod folder. CA...I curse your 'unspecified error' .

Step 11 .... run the game again with the files in the right place! All goes well, and a custom battle is created with Dwarf v Skeleton. Loads fine ....

But there is a snag. The Dwarfs have learnt to levitate. When I loaded the animerge product in Milkshape, I noted that the model was not sitting ON the baseline lile I expected it to. It looked like it was higher....and that is exactly how it has come out in game.

On the plus side, every step worked smoothly, and exactly as predicted. Nothing crashed, failed or screwed up. No nasty errors. The only thing that has not worked correctly is the vertical position. This has not altered.

Did I miss something?

Superb stuff otherwise, and easier to use than I had expected!

[Bwian]

to help out a bit ... here's a picture of the thing in animerge:

https://img57.imageshack.us/img57/7624/animth9.jpg

[KnightErrant]

Excellent news! :2thumbsup: No, I don't think you missed anything. I may not
have set the exact scaling values I used to get them on the y=0
plane. Open up animationutilities.py in your favorite editor and search
for SCALEY. This should be at the top of the function exportskeleton.
I thought 0.64 put them on the plane, but try making this smaller,
save, then do the exportskeleton step again. Rather than copy the
files and run the game, just do an animmerge with like the walk animation
in convertedfiles and see how it looks. Might have to iterate just a
couple of times to nail it, but it shouldn't take too long.

When it looks good in Milkshape, then copy the cas files to your
dwarf animations directory, and, (silent prayer) they should look allright
in game.

Edit: Leaving from work, I'll check back when I get home.

[Bwian]

SCALEY was indeed set to 0.64. Tried changing it to 0.14 .... which should have a noticable difference. Ran the steps through, but the animerge file still showed the animation in EXACTLY the same place as before. Too high. I was expecting it to be wrong, but not the same. I will give it another shot with some different values in there tomorrow. Right now, it's 23:30 UK time, and I need to get some shut-eye! It's a 6am wakeup on work days.

Soon as I get in tomorrow, I'll do some more testing to see what I can change with different values in there. I'll post back to let you know how I get on.

I am running in 1.2 ( if that makes any difference, I don't know ) so this is valuable test data whether I succeed or fail here. Main thing is, the process steps all did pretty much what theywere expected to do. Just seems hung up on the y axis positioning.

Biggest worry for me was that the model seemed to end up stuck to the origin. I had exactly the same issue when I tried to scale animations......hope it's just coincidence. Will know more tomorrow.

[KnightErrant]

Hey Bwian, I am so embarrased.:embarassed: I just checked
and the scaling isn't even in the new stuff. Too late at night to help
you but give me a moment and I'll update the def and check it
and send you a new one. Software too fast is software with bugs.

Apologies,

KE

[KnightErrant]

Proof of the pudding for rewriting all the Python code
into a library. Took all of 2 minutes to make the change
and check it. Here's the human skeleton's walk animation,
the one in MTW2_2H_Axe:


0 bone_pelvis animation data and deltas
+0.0000122126 +0.9590483308 -0.0000000000
+0.0017991858 +0.9512157440 +0.0901285559
+0.0026300352 +0.9396055937 +0.1802604198
+0.0000594494 +0.9203369617 +0.2704085112
-0.0063111591 +0.9033862948 +0.3605716527
-0.0137326801 +0.9005295038 +0.4507446289
-0.0189423133 +0.9042277336 +0.5409182310
-0.0211101491 +0.9193583131 +0.6310883760
-0.0210416745 +0.9396334291 +0.7212522626
-0.0201377589 +0.9517263174 +0.8114059567
-0.0226440672 +0.9510992169 +0.9015470743
-0.0249393098 +0.9356126189 +0.9916793704
-0.0272242893 +0.9162625670 +1.0818185806
-0.0254939552 +0.8969492912 +1.1719760895
-0.0179745089 +0.8883986473 +1.2621510029
-0.0077288523 +0.8950952291 +1.3523342609
-0.0011719284 +0.9107339382 +1.4425106049
+0.0010084946 +0.9343801737 +1.5326695442
+0.0000120707 +0.9590483308 +1.6228270531


You can see the y-value is roughly 0.91 and the z-value moves the
human from 0.0 to 1.622 in 19 frames.

Here's the scaled dwarf anim for the same section
after I ACTUALLY DO THE SCALING!:dizzy2:


0 bone_pelvis animation data and deltas
+0.0000084836 +0.6137909293 -0.0000000000
+0.0012498223 +0.6087780595 +0.0626087040
+0.0018269803 +0.6013475657 +0.1252197027
+0.0000412971 +0.5890156627 +0.1878419816
-0.0043841098 +0.5781672001 +0.2504746914
-0.0095395437 +0.5763388872 +0.3131142557
-0.0131584676 +0.5787057281 +0.3757542670
-0.0146643762 +0.5883893371 +0.4383918643
-0.0146168098 +0.6013653874 +0.5010250807
-0.0139888953 +0.6091048717 +0.5636512637
-0.0157299284 +0.6087034941 +0.6262686849
-0.0173243415 +0.5987920761 +0.6888799667
-0.0189116243 +0.5864080191 +0.7514960766
-0.0177096315 +0.5740475655 +0.8141248822
-0.0124861719 +0.5685751438 +0.8767657876
-0.0053689247 +0.5728609562 +0.9394125342
-0.0008140918 +0.5828697085 +1.0020544529
+0.0007005609 +0.5980033278 +1.0646842718
+0.0000083850 +0.6137909293 +1.1273130178


This should actually put the dwarf on the ground and
reduce his x and z traversals as he walks.

Am e-mailing an updated animationutilities.py to you.
I made a new interface for the scaling values at lunch.
It now pops up a three entry edit box to put in your
scaling values. For now just accept the default values
I put in there, they should be correct for the dwarf.
Hit the OK button and you should see file names scrolling
in the DOS box.

Again, apologies for my bad.

KE

[Bwian]

Considering it was an Alpha, and worked faultlessly with me as a novice user...I think one little omission is pretty damn good! I am looking forward to running through this again when I get in from work! Sneaking a quick 5 minutes before the Auditors come in now .... but I had to check in to see.

This should be a breeze tonight :beam:

Wonder if anyone would notice if I nipped off early from work :2thumbsup:

[Bwian]

Ran it with the updated python script, and left the scaling factors as the default ones. This ...I guessed...was going to be pretty right, and there was no point in messing with it.

Checked the animmerge, and the dwarf was sitting just where he should in Milkshape.

Deleted the packs....copied all the 'converted' anims into the Dwarf anim folder, and held my breath.

Fired up a custom battle, and .......

Grumpy, Sneezy, Bashful and his mates all stomped properly across the ground uttering their fearful battlecry ... Hi Ho !!! and off to work they went!

Faultless! Apart from some slightly dodgy rigging that isn't ideal ... but then I did lash the Dwarf model up as a test. The real shorties will be a whole lot better, and worth putting hte time in now I know we CAN DO THIS!

Three...no make that four ..oh what the heck..five.... cheers for KnightErrant!:2thumbsup:

[KnightErrant]

Awesome! :2thumbsup: Many thanks for the cheers. :beam: The rigging
may be my skeleton's fault. I pulled out the leg bones
and clavicles by hand from the .ms3d dwarf a while back
so some of the joints are still human skeleton. Try extractskeleton
on your model, you should get a better skeleton if that's the
problem.

Just a note, GrumpyOldMan has spotted a rotation problem on
an animation with extreme arm movements, so my quats to eulers
conversion seems to be off when some angles go bigger than 90
degrees. We'll get that sorted out and I'll send an update for the
animationlibrary file.

Look out Moria! Khazad ai menu!

[Casuir]

Nice work lads

[GrumpyOldMan]

Hi KE et al

I've roused myself from my navel lint gazing and tried a few experiments. Chariots crash the engine as an 'unknown mount type' and testudo crashes the engine as an 'unknown formation type'.

So for mounts this means, unless anybody can find how we add mounts to the engine, that we are restricted to only three mounts - horse, camel and elephant. We can do contructive things within those restrictions (class my reptor as a horse :beam: ) but mounts and their effects on others will be governed by the three valid mounts. If I do make my raptor as a horse it will be scared of camels and elephants, etc. If we make a chariot an 'elephant' type mount, the same restrictions will apply and we'll have to include the horse skeletons as part of the chariot skeleton, etc. We may have to wait until we try additional bones before we know whether this is feasible.

I was working on converting RTW anims over to mtw2 skeletons but I don't know whether it's worthwhile now that the need for specialised anims for testudo, etc can't be used.

Sorry for the bad news for the ancient and fantasy modders out there but it's best you know now rather than put in a lot of effort for nothing.

Cheers

GrumpyOldMan

[GrumpyOldMan]

Hi KE et al

I feel better now. Just did an experiment to make sure that the mtw2 engine was running off string recognition for anim purposes rather than bone indices.

I manually added three new bones to the Dismounted Feudal Knight (bone_cloak1, bone_cloak2 and bone_cloak3) at the end of the bones section of the mesh files. I left all the anims alone. I ran the program and the figures animated without a problem in the world - this means that :-

1. As long as all the bones that are required are present in the mesh it doesn't care if there are any more. If the skeleton and anims provide anim information for those bones they will be animated as well.

2. Anim is definitely done by string recognition, I was half expecting to have to move the new bones from the end of the section to the middle so as not to interfere with the weapon and shield bones. Not necessary, which is good news for mesh designers, might mean a bit more work for converting anims though.

The poor old Dismounted Feudal Knight has taken a pounding during all my experimentation, I'm thinking of mentioning him in dispatches :beam:

Cheers

GrumpyOldMan

[Bwian]

Started some more wholesale conversion of anims for the mod yesterday. Found a few more anims that don't conform and were not convertable with the tools. These seemed to be mostly 'swim' anims and the extended reload anim for the musket skeleton. These anims were in the descr_skeleton, so I could not just comment them out. I renamed them to run the converter tool, but had to convert them back to allow the anim packs to biuld correctly. If these do not work or cause major issues in game, I will have to edit them manually.

Not a big issue really ...I converted over the mace set, the crossbow set and the musket set with no issues. Reading through the skeleton text file, I noticed that the game is sharing a lot of animations from other sets. In this case, the Knifeman set and crew sets. This, unfortunately, meant I had to convert those over as well to get working dwarfs with all the weapons I wanted.

I will have to do Orcs with Knifeman and archer anims only ... I have currently added about 10Mb to the size of the animation archives, and I don;t want to add more if I can help it! Scaling seems to add nothing .... but whole new sets are a different matter entirely.

I need the musket anims for the thunderers .. but I might, at a push, try and modify and re-use the crossbow anims if I can avoid the unwanted reload animations. That would save a few Mb's

[KnightErrant]

@GOM
That is definitely good news about adding new bones
and animating them.

@Bwian
I've started automated surveying the directories to find
which ones are all "normal" and which ones have variants.
As soon as I've had a chance to collate the results I'll try
to generalize the casreader to handle them as well. That
should take care of the exportskeleton function as well so
I wouldn't try to do too much by hand right now.

I know it fails on mounts but I'm going to concentrate on the
MTW2_ infantry units first and then the HR_ and CR_ riders.
The stratmap witch also has some unusual ones but that is
down on the list.

[KnightErrant]

Thought this would be helpful. Its Memorial Day weekend in the US
so very few supervisors were at work today. Thought I could
finish it completely but getting tired so here's part of it.

--------------------------
descr_skeleton.txt synopsis
---------------------------

Just trying to count the animation families, animation types, and animation
'.cas files. This doesn't have it all, got tired near the end.



type desigination subdirectory of /animations

----------------------------------------------------
Stratmap animation families
----------------------------------------------------


fs_test_primary_weapon test_weapon
fs_test_secondary_weapon test_weapon
fs_test_shield test_weapon
fs_test_primary_bow test_weapon
fs_test_secondary_bow test_weapon
fs_test_primary_smallround_shield test_weapon

strat_named_with_army Stratmap_General
strat_spy Stratmap_Spy
strat_assassin Stratmap_Assassin
strat_diplomat Stratmap_Diplomat
start_merchant Stratmap_Merchant

start_navy (Special, all in root animations directory)

strat_priest Stratmap_Preist (Yes, that is the spelling.)
strat_princess Stratmap_Princess

witch (Special, some in root animations dir, and /DIP directory.)


----------------------------------------------------
Battlemap infantry animation families
----------------------------------------------------

MTW2_Knifeman_Crew MTW2_Knifeman and MTW2_Crew
MTW2_Knifeman MTW2_Knifeman (MTW2_Crew for crew requirements.)
MTW2_Knife_Primary MTW2_Knifeman/Weapon (2 anims)
MTW2_Fast_Knifeman MTW2_Knifeman (2 anims)

MTW2_Mace MTW2_Mace (MTW2_Crew for crew, MTW2_Knifeman for swim)
MTW2_Mace_Primary MTW2_Mace/Weapon (2 anims)
MTW2_Fast_Mace MTW2_Mace (2 anims)
MTW2_Slow_Mace MTW2_Mace (2 anims)

MTW2_Swordsman MTW2_Swordsman and MTW2_Mace
MTW2_Sword_Primary New_Swordman/Weapon (2 anims)
MTW2_Fast_Swordsman MTW2_Mace (2 anims)
MTW2_Slow_Swordsman MTW2_Mace (2 anims)
MTW2_Non_Shield MTW2_Swordsman and MTW2_Knifeman
MTW2_Non_Shield_Fast MTW2_Swordsman and MTW2_Mace (2 anims)
MTW2_Non_Shield_Slow MTW2_Swordsman and MTW2_Mace (2 anims)

MTW2_2HSwordsman MTW2_2HSwordsman (MTW2_Crew for crew, MTW2_Knifeman for swim)
MTW2_2HSwordsman_Primary MTW2_2HSwordsman/Weapon (2 anims)
MTW2_Slow_2HSwordsman MTW2_2HSwordsman (2 anims)

MTW2_2H_Axe MTW2_2H_Axe (MTW2_Crew for crew, MTW2_Knifeman for swim)
MTW2_2H_Axe_Primary MTW2_2H_Axe/weapon (2 anims)
MTW2_Fast_2H_Axe MTW2_2H_Axe (2 anims)
MTW2_Slow_2H_Axe MTW2_2H_Axe (2 anims)

MTW2_Spear MTW2_Spear (MTW2_Crew for crew, MTW2_Knifeman for swim)
MTW2_Spear_Primary New_Swordsman/weapon (2 anims)
MTW2_Fast_Spear MTW2_Spear (2 anims)

MTW2_Javelin MTW2_Javelin
MTW2_Javelin_primary MTW2_Javelin and MTW2_Knifeman(11 anims)
MTW2_Fast_Javelin MTW2_Spear (2 anims)

MTW2_Pike MTW2_Pike (MTW2_Crew for crew, MTW2_Knifeman for swim)
MTW2_Pike_primary MTW2_Pike/weapon (2 anims)
MTW2_Slow_Pike MTW2_Pike (2 anims)

NOTE THE FOLLOWING: Uppercase Primary for soldier, lowercase primary for weapon.

MTW2_Halberd_Primary MTW2_Halberd (MTW2_Crew for crew, MTW2_Knifeman for swim)
MTW2_Halberd_primary MTW2_Halberd/weapon (2 anims)

MTW2_Halberd_Secondary MTW2_Halberd and MTW2_2HSwordsman

MTW2_Musket MTW2_Musket (MTW2_Crew for crew, MTW2_Knifeman for swim)
MTW2_Musket_Primary MTW2_Musket/weapon (11 anims)
MTW2_Fast_Musket MTW2_Musket (2 anims)

MTW2_Arquebus MTW2_Musket
MTW2_Arquebus_Primary MTW2_Musket/weapon (11 anims)
MTW2_Fast_Arquebus MTW2_Musket (3 anims)

MTW2_Handgun MTW2_Handgun
MTW2_Handgun_Primary MTW2_Musket/weapon (11 anims)

MTW2_Bowman MTW2_Bowman (MTW2_Crew for crew, MTW2_Knifeman for swim)
MTW2_Bowman_Primary MTW2_Bowman/weapon (5 anims)
MTW2_Fast_Bowman MTW2_Bowman (2 anims)
MTW2_Slow_Bowman MTW2_Bowman (2 anims)

MTW2_Crossbow MTW2_Crossbow (MTW2_Crew for crew, MTW2_Knifeman for swim)
MTW2_Crossbow_Primary MTW2_Crossbow/weapon (8 anims)
MTW2_Fast_Crossbow MTW2_Crossbow (2 anims)

MTW2_Pavise_Crossbow MTW2_Crossbow (2 anims)



----------------------------------------------------
Battlemap siege engine crew animation families
----------------------------------------------------

MTW2_Crew_Culverin siege_crew
MTW2_Crew_Basilisk siege_crew
MTW2_Crew_Serpentine siege_crew
MTW2_Crew_Cannon siege_crew
MTW2_Crew_Bombard siege_crew
MTW2_Crew_Huge_Bombard siege_crew
MTW2_Crew_Mortar siege_crew
MTW2_Crew_Catapult siege_crew
MTW2_Crew_Trebuchet siege_crew
MTW2_Ballista siege_crew
MTW2_Crew_Ribault siege_crew and new_crew
MTW2_Crew_Monster_Ribault siege_crew and new_crew



----------------------------------------------------
Battlemap HR (horse rider) animation families
----------------------------------------------------

MTW2_HR_Lance HR_lance
MTW2_HR_Mace HR_Mace
MTW2_HR_Sword HR_Sword
[/CODE]

I'll work on finishing it tomorrow. My idea is to lay out what is there
in Caliban's unpacked directory. Obviously, some things are CAs developement
ideas that are not in the retail version and can be ignored. Where I'm going
is to process all the directories that have something to do with the game and
find out what files matter (i.e. are in descr_skeleton.txt) and what files don't.

Then we know what we have to read with a .cas reader and what we don't.
Since its a research wiki if this doesn't help, then nobody is harmed.
Just wanted to write it somewhere so I can access it again.

[master of the puppets]

:dizzy2: i'm just going to walk away and NEVER return to this thread. *shiver*

[KnightErrant]

Well I have to chuckle on that one. :laugh4: I don't know if the
<<shiver>> is for the technical content or why anyone would be so interested
in such boring stuff. No further dissection of the descr_skeleton.txt file this
weekend. I'm compelled to sacrifice pieces of red meat on an altar composed
of brickettes and lighter fluid; this is called memorial day. Hope to finish this off
along with the survey tomorrow. Then the offending animations can be
identified and read

Have a happy summer.:smash: .

[KnightErrant]

Backing up a little because I got HR_stuff wrong.



----------------------------------------------------
Battlemap HR (horse rider) animation families
----------------------------------------------------

MTW2_HR_Lance HR_lance

(Messed this one up last night, there is no HR_Mace.)
MTW2_HR_Mace HR_Sword
MTW2_HR_Sword HR_Sword
MTW2_HR_Spear HR_Spear
MTW2_HR_Javelin HR_Spear
also uses subdirectory HR_Javelin
MTW2_HR_Bow HR_Bow
MTW2_HR_Bow_Primary HR_bow/Weapon (5 anims)
MTW2_HR_Crossbow HR_Crossbow
MTW2_HR_Crossbow_Primary MTW2_Crossbow/Weapon (8 anims)
MTW2_HR_Pistol HR_Pistol
MTW2_HR_Pistol_Primary HR_Pistol/weapon (6 anims)
MTW2_HR_Arquebus HR_Arquebus
MTW2_HR_Arquebus_Primary HR_Arquebus/weapon (6 anims)


----------------------------------------------------
Battlemap CR (camel rider) animation families
----------------------------------------------------

MTW2_CR_Spear CR_Spear
MTW2_CR_spear_Primary HR_spear/weapons (2 anims)
MTW2_CR_Sword CR_Sword
MTW2_CR_Bow CR_Bow
MTW2_CR_Arquebus CR_Arquebus


---------------------------------------------------
Battlemap ER (elephant rider) animation families
----------------------------------------------------

MTW2_Elephant_Rockett_Crew elephant_cavalry
Elephant_Artillery_Crew elephant_cavalry/Elephant_Crew
MTW2_Elephant_Crew elephant_cavalry/elephant_rider


----------------------------------------------------
Battlemap HR (horse rider) animation families
----------------------------------------------------

fs_horse fs_horse
fs_heavy_horse fs_horse

fs_african_elephant med_elephant
fs_camel camel

legion_pole \animations
standard_legion_pole
general_legion_pole
cavalry_legion_pole \animations\banners
cavalry_mini_pole \animations\banners
cavalry_main_pole \animations\banners




Allright, that's what's in descr_skeletons.txt. Haven't collated it or added it up
but this is what we have to work with and not everything in Caliban's
directory. (Have to look at the witch a bit more.) I'll post the survey of
units tomorrow. Know I can't do mounts but if the only problem infantry
units turn out to be the short footer ones then these can be dealt with.

[KnightErrant]

Just to note about the previous posts: there are 108 named types
or families of animations.

Here's the survey results. Not complete because some more
questions were raised by the survey but this will do for now.
First here's list of the directories surveyed in roughly the order encountered
in descr_skeleton.txt. Note that we ignore /weapon subdirectories etc.,
we just do the main directories with human or mount animations.
Our requirement was not to do what was in Caliban's directory, but only
do what is actually used in descr_skeleton. There's a lot of new_...
directories NOT used; maybe we'll see these in the future?



----------------------------------------------------------------
Summary of Summary: Directories in descr_skeleton.txt
----------------------------------------------------------------

root directory of /animations for:
navy
witch
legion_pole
standard_legion_pole
general_legion_pole

test_weapon

Stratmap_General
Stratmap_Spy
Stratmap_Assassin
Stratmap_Diplomat
Stratmap_Merchant
Stratmap_Preist
Stratmap_Princess

MTW2_Crew
MTW2_Knifeman
MTW2_Mace
MTW2_Swordsman
New_Swordman/Weapon (2 anims)
MTW2_2HSwordsman
MTW2_2H_Axe
MTW2_Spear
MTW2_Javelin
MTW2_Pike
MTW2_Halberd
MTW2_Musket
MTW2_Handgun
MTW2_Bowman
MTW2_Crossbow

siege_crew
new_crew

HR_lance
HR_Sword
HR_Sword
HR_Spear
HR_Spear
HR_Bow
HR_Crossbow
HR_Pistol
HR_Arquebus

CR_Spear
CR_Sword
CR_Bow
CR_Arquebus

elephant_cavalry/Elephant_Crew
elephant_cavalry/elephant_rider

fs_horse
med_elephant
camel

banners



The test_weapon survey:


test_weapon: 34 Processed .cas files.

All missing footers. No quats or anim data, only pose data.
Signature bytes: 154 154 154 63 63 63 Version: 3.20 (16 of these)
0 0 0 63 63 63 3.21 ( 8 of these)
0 0 0 0 0 0 3.21 ( 8 of these)
89 89 89 74 74 74 3.20 ( 2 of these)

Only 12 of them used in descr_skeleton.txt.


Ignoring navy and the witch, the stratmap animations follow this:


Stratmap_Assassin: 23 Processed .cas files. All regular version: 3.21 Signature: 0 0 0 102 102 102
Stratmap_Diplomat: 22 Processed .cas files. All regular version: 3.21 Signature: 0 0 0 102 102 102
Stratmap_General: 41 Processed .cas files. All regular version: 3.21 Signature: 0 0 0 102 102 102
Stratmap_Merchant: 23 Processed .cas files. All regular version: 3.21 Signature: 0 0 0 102 102 102
Stratmap_Preist: 41 Processed .cas files. All regular version: 3.21 Signature: 0 0 0 102 102 102
Stratmap_Princess: 23 Processed .cas files. All regular version: 3.21 Signature: 0 0 0 102 102 102
Stratmap_Spy: 25 Processed .cas files. All regular version: 3.21 Signature: 0 0 0 102 102 102

The MTW2 infantry units go like this:


MTW2_2HSwordsman: 185 Processed .cas files.

2 Variant files: No footers.
MTW2_2HSwordsman_die_flailing_cycle.cas 154 154 154 63 63 63 These variant files are in
MTW2_2HSwordsman_die_flailing_cycle_end.cas 0 0 0 0 0 0 descr_skeleton.txt


MTW2_2H_Axe: 215 Processed .cas files.

2 Anomalous files: No footers.
MTW2_2H_Axe_attack_centre_Hi_Stab_Fail.cas 0 0 0 102 102 102 These anomolous files are
MTW2_2H_Axe_attack_centre_Hi_Stab_Success.cas 0 0 0 102 102 102 NOT in descr_skeleton.txt

2 Variant files: No footers.
MTW2_die_flailing_cycle.cas 154 154 154 63 63 63 These variant files are in
MTW2_die_flailing_cycle_to_land.cas 0 0 0 0 0 0 descr_skeleton.txt


MTW2_Bowman: 125 Processed .cas files.

2 Variant files: No footers.
MTW2_Bowman_die_flailing_cycle.cas 154 154 154 63 63 63 These variant files are in
MTW2_Bowman_die_flailing_cycle_end.cas 0 0 0 0 0 0 descr_skeleton.txt


MTW2_Crossbow: 127 Processed .cas files.

2 Variant files: No footers.
MTW2_Crossbow_die_flailing_cycle.cas 154 154 154 63 63 63 These variant files are in
MTW2_Crossbow_die_flailing_cycle_end.cas 0 0 0 0 0 0 descr_skeleton.txt


MTW2_Halberd: 205 Processed .cas files.

2 Variant files: No footers.
MTW2_Halberd_die_flailing_cycle.cas 154 154 154 63 63 63 These variant files are in
MTW2_Halberd_die_flailing_cycle_end.cas 0 0 0 0 0 0 descr_skeleton.txt


MTW2_Handgun: 30 Processed .cas files. All regular version: 3.21 Signature: 0 0 0 102 102 102

MTW2_Javelin: 6 Processed .cas files. All regular version: 3.21 Signature: 0 0 0 102 102 102


MTW2_Knifeman: 188 Processed .cas files.

13 Variant files: No footers.
MTW2_Knifeman_die_flailing_cycle.cas 154 154 154 63 63 63
MTW2_Knifeman_die_flailing_cycle_end.cas 0 0 0 0 0 0


MTW2_Knifeman_swim.cas 154 154 154 102 102 102 Passes our 102 test!!!!!!!

MTW2_Knifeman_swim_attack1.cas 154 154 154 63 63 63
MTW2_Knifeman_swim_attack2.cas 154 154 154 63 63 63
MTW2_Knifeman_swim_idle.cas 154 154 154 63 63 63

MTW2_Knifeman_swim_idle_to_swim.cas 154 154 154 102 102 102 Passes our 102 test!!!!!!!

MTW2_Knifeman_swim_shuffle_backward.cas 154 154 154 63 63 63
MTW2_Knifeman_swim_shuffle_forward.cas 154 154 154 63 63 63
MTW2_Knifeman_swim_shuffle_left.cas 154 154 154 63 63 63
MTW2_Knifeman_swim_shuffle_right.cas 154 154 154 63 63 63

MTW2_Knifeman_swim_to_Stand_A.cas 154 154 154 102 102 102 Passes our 102 test!!!!!!!

MTW2_Knifeman_swim_to_Swim_Idle.cas 154 154 154 102 102 102 Passes our 102 test!!!!!!!


MTW2_Mace: 185 Processed .cas files.

2 Variant files: No footers.
MTW2_Mace_die_flailing_cycle.cas 154 154 154 63 63 63
MTW2_Mace_die_flailing_cycle_end.cas 0 0 0 0 0 0


MTW2_Musket: 132 Processed .cas files.

1 Anomalous files: No footers.
MTW2_Musket_attack_missile_reload_extended.cas 0 0 0 102 102 102 TRUE ANOMALY. This file NOT in descr_skeleton.txt.

2 Variant files: No footers.
MTW2_Musket_die_flailing_cycle.cas 154 154 154 63 63 63 These variant files are in
MTW2_Musket_die_flailing_cycle_end.cas 0 0 0 0 0 0 descr_skeleton.txt


MTW2_Pike: 182 Processed .cas files.

2 Variant files: No footers.
MTW2_Pike_die_flailing_cycle.cas 154 154 154 63 63 63 These variant files are in
MTW2_Pike_die_flailing_cycle_end.cas 0 0 0 0 0 0 descr_skeleton.txt


MTW2_Spear: 153 Processed .cas files.

2 Variant files: No footers.
MTW2_Spear_die_flailing_cycle.cas 154 154 154 63 63 63 These variant files are in
MTW2_Spear_flailing_cycle_to_land.cas 0 0 0 0 0 0 descr_skeleton.txt


MTW2_Swordsman: 16 Processed .cas files. All regular version: 3.21 Signature: 0 0 0 102 102 102


MTW2_Crew: 19 Processed .cas files. All regular version: 3.21 Signature: 0 0 0 102 102 102



We omit new_Swordman since it is used in only 4 places in descr_skeleton.txt and
only for its \weapon subdirectory for use with weapons.


The flailing ones are all variants that are in the game but can be
recognized by their signature bytes. The anomalous ones like
in MTW2_2H_Axe and MTW2_Musket aren't in game. A lot of the
MTW2_Knifeman ones had a second signature byte group of 102 102 102
so they would pass my test for that but they have a first signature
byte group of 154 154 154 so could be recognized by this.


The crew ones are very problematic as noted:


Siege_crew: 108 Processed .cas files.

Very problematic. Every file is a variant or anomalous. The anomalies ARE in descr_skeleton.txt.
(1) 154 154 154 102 102 102 variants with no footers.
(2) 0 0 0 102 102 102 anomalies with no footers.
(3) 154 154 154 102 102 102 variants WITH footers but the footers are bad because missing 12 bytes
or the last three ints 12 12 0.


Looking at some of them, they have quat data as indicated by the first int after the bone name
but DON'T have anim data looking at the second int. The ones without footers end with pose
data.


new_crew: 23 Processed .cas files.

Very problematic as well. Many are variants of type 154 154 154 102 102 102 with no footers
but some are variants of type 154 154 154 102 102 102 with perfectly formed footers.
Also one 154 154 154 63 63 63 variant with no footer.

(Only three .cas files from this directory are used in descr_skeleton.txt:
Crew_Stand_to_Wide_Push.CAS
Crew_Wide_Push.CAS
Crew_Wide_Push_to_Crew_Stand.CAS
and only for the ribault and monster_ribault.)




Horse rider animations:


HR_Arquebus: 5 Processed .cas files. All regular version: 3.21 Signature: 0 0 0 102 102 102


HR_bow: 9 Processed .cas files. All regular version: 3.21 Signature: 0 0 0 102 102 102
Node name for these is CaozSceneCustomAttribNode 1. First footer int is 106 not 104.


HR_crossbow: 9 Processed .cas files. All regular version: 3.21 Signature: 0 0 0 102 102 102


HR_lance: 26 Processed .cas files.

HR_lance_basepose.CAS 0 0 0 117 117 117 Bad footer, missing 12 bytes.
Version 3.20, but IS in
descr_skeleton.txt as default anim
command pair.

HR_lance_fs_horse_taunt.cas 0 0 0 102 102 102 Bad footer, missing 12 bytes.
NOT in descr_skeleton.txt

NOTE: The node name for these is CaozSceneCustomAttribNode 1. (That's SPACE 1 for the end of the name.)


HR_Pistol: 4 Processed .cas files. All regular version: 3.21 Signature: 0 0 0 102 102 102
Node name for these is CaozSceneCustomAttribNode 1. First footer int is 106 not 104.


HR_Spear: 30 Processed .cas files. All regular version: 3.21 Signature: 0 0 0 102 102 102
Node name for these is CaozSceneCustomAttribNode 1. First footer int is 106 not 104.


HR_Sword: 67 Processed .cas files.

18 anomalous files with 12 bytes missing from the footer. All have regular 0 0 0 102 102 102 signatures.

HR_Sword_Defend_LOW_slashLR.cas None of these files are in descr_skeleton.txt
HR_Sword_Defend_LOW_slash_RL.cas
HR_Sword_Defend_OVERHEAD_slashLR.cas
HR_Sword_Defend_OVERHEAD_slash_RL.cas
HR_Sword_Defend_slashLR.cas
HR_Sword_Defend_slash_RL.cas
HR_Sword_Left_low_SlashRL_fail.cas
HR_Sword_Left_low_SlashRL_success.cas
HR_Sword_Left_MID_SlashRL_fail.cas
HR_Sword_Left_MID_SlashRL_success.cas
HR_Sword_Left_OVERHEAD_SlashRL_fail.cas
HR_Sword_Left_OVERHEAD_SlashRL_success.cas
HR_Sword_Right_MID_C_slashLR_fail.cas
HR_Sword_Right_MID_C_slashLR_success.cas
HR_Sword_Right_OVERHEAD_C_slashLR_fail.cas
HR_Sword_Right_OVERHEAD_C_slashLR_success.cas
HR_Sword_right_slashLR_low_fail.cas
HR_Sword_right_slashLR_low_success.cas


HR_Swordman: 25 Processed .cas files. All regular version: 3.21 Signature: 0 0 0 102 102 102



Camel rider animations:


CR_Arquebus: 26 Processed .cas files. All regular version: 3.21 Signature: 0 0 0 102 102 102
NOTE: The die_galloping and die_standing files have these two node names and first footer int value:
135 1 1 CaozSceneCustomAttribNode01, CaozSceneCustomAttribNode02

Others are regular node name.


CR_Bow: 26 Processed .cas files. All regular version: 3.21 Signature: 0 0 0 102 102 102
NOTE: Here only the die_standing has the following node names and first footer int value:
135 1 1 CaozSceneCustomAttribNode01, CaozSceneCustomAttribNode02

Others are regular node name.


CR_Spear: 26 Processed .cas files. All regular version: 3.21 Signature: 0 0 0 102 102 102
CR_Sword: 26 Processed .cas files. All regular version: 3.21 Signature: 0 0 0 102 102 102



Elephant riders:


elephant_cavalry/Elephant_Crew 8 Processed .cas files.

All anomalous with no footers but regular signature bytes 0 0 0 102 102 102


elephant_cavalry/elephant_rider 12 Processed .cas files.

All have 5 nodes, instead of 104 to start the footer these start with 222.
Footer indicates that what I've been calling ints are really floats for the footers.
Regular signature bytes 0 0 0 102 102 102

Here's an example with a footer:

Cas file: HR_elephant_rider_stand_a_to_walk.cas
+3.210 38 9 0 +1.200 1 0 0 0 0 1 0 102 102 102
15316 0
21 bones in hierarchy tree
25 time ticks
222 1 1 CaozSceneCustomAttribNode 2, CaozSceneCustomAttribNode 3, CaozSceneCustomAttribNode 4, CaozSceneCustomAttribNode 5, CaozSceneCustomAttribNode 1
1 0 1 0 3989597952 2147483814 3149737919 178 +0.00 0 0 0 0 0 -1 0 0
1 16 2 0 0 16 3 0 0 16 8 0 0 16 10 0 0 12 5 0 12 12 0

Those big ints seem to be the floats:
-1.650059e-15 -1.0000000 -2.1855696e-08 7.5497901e-08

Other examples have floats in other places. This might force me to redo the footers and make
these fields floats. Here's regular footer of that same line:

1 0 1 0 0 0 0 0 +1.00 0 0 0 0 0 -1 0 0
_ _ _ _ _ _ _ _ _

The underlined zeroes could all be float zeroes.


This directory is worth coming back to for further study of the footers.



Last stuff, mounts and banners:


fs_horse: 38 Processed .cas files.

footers again indicate what I've called ints could well be floats.
Can't tell actually, footer is much longer than a normal one. Another variant.
Signature is regular 0 0 0 102 102 102.
The int starting the footer is 170 and not 104.

Must revisit this one. The extra floats seem to be preceded by int counts
so maybe this is an example of a more general format that we only see in this
case?



med_elephant: 29 Processed .cas files. All regular but the signature is: 104 104 104 104 104 104


camel: 29 Processed .cas files. Signature is : 0 0 0 10 10 10

Seem to have normal footers. (My trap on second signature byte means it didn't print out.)



banners: footer looks odd but this is an odd file anyway. Only one file of the two used in
descr_skeleton.txt


That's the survey. Definitely need to revisit this to be sure how to process
these generally. The problem that's nagging me is animmerge and animextract.
If I animmerge a variant into a .ms3d file, how much info do I have to put
into a .ms3d comment so I can reconstruct it in animextract? We've seen
missing footers with odd signature bytes. That makes sense. We've seen
missing footers with regular signature bytes. Uh oh. We've seen footers
that are missing 12 bytes (three ints 12 12 0). Long footers with lots of
extra floats for fs_horse. etc. etc.

[GrumpyOldMan]

Hi KE

What a great job you've done on the anim survey :2thumbsup: :2thumbsup: :2thumbsup: .

I'll have a look at the horse anims and see if I can make any sense out of the longer footer.

As far as the crew anims are concerned I don't think we have to worry too much about them since we now have anims to take us up to the 1860's if required.

One thing that did strike me with the mtw2 human anims was that 102 102 102 were basically transitions and the 63 63 63 were looping animations (of course the MTW2_Knifeman_swim.cas sticks out as an anomaly - can't have too many anomalies :beam: - maybe it transitions as well, even with itself?). This would also make sense of flailing_cycle (63 63 63 - looping) and flailing_cycle_end (00 00 00 - hit the ground - nothing more going on from here :beam:)

Cheers

GrumpyOldMan

[KnightErrant]

Here's some numerology for you (and if you believe this, tell me your
sign and I'll predict your future). The footers describe themselves in
byte number sections. Let's do a regular one and then a fs_horse one.

Regular unit anim: MTW2_Spear_run.cas

In decimal layout we have:


104 1 1 CaozSceneCustomAttribNode 1 0 1 0 0 0 0 0 +1.00 0 0 0 0 0 -1 0 0 1
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
12 12 0
----------
192


I've broken the footer so what I'm calling the byte numbers are in the
left-most column. They sum to 192, the standard footer size.

Now do a horsy. This is fs_fast_horse_run.cas:


170 1 1 CaozSceneCustomAttribNode 1 0 1 0 0 0 0 0 +1.00 0 0 0 0 0 -1 0 6 plane 1 0b 1 0 0b -0.707 0.0 0.0 +0.707 2.4304 -4.7682 -7.8706 0 0 0 0 2
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
73 5 1 0 0.8381 0.612 0.612 1.0 0.2000 0.2000 0.2000 0 0 0 0 0 0 0 1b
12 12 0
---------
319

and 319 bytes is the size of this horse footer.


This still doesn't match the file size sans header/footer at offset 42
for pulling something out of thin air, but it's interesting.


Edit: fs_horse_default.cas footer is only 180 bytes i.e. standard 192 - 12.
It's missing the last three 12 12 0 ints like lots of other files. All the others
that I've checked have the 319 byte footer. fs_horse_default.cas is version 3.20
while the others are version 3.21. fs_horse_default.cas IS used in descr_skeleton.txt.

[zxiang1983]

Hi, all.
I don't understand most of the things here but I'm playing with CA source animation files and I think questions could be post here, right? :P

There are a lot of good stuff in these source files, some of which are not used by vanilla game. The one get my interest is the new_2h_axe_halberd folder. And I immediately realize it must contain the jump-attack animation which can be seen in CA trailer long before M2TW was released. Then I edited descr_skeleton.txt and I'm lucky enough to make the jump-attack animation into the game! However, there's something worng with it. This is what I got:

https://img240.imageshack.us/img240/7374/0077et2.jpg (https://imageshack.us)
https://img240.imageshack.us/img240/2336/0078ro0.jpg (https://imageshack.us)
https://img240.imageshack.us/img240/4712/0079of4.jpg (https://imageshack.us)
https://img117.imageshack.us/img117/1419/0080hf5.jpg (https://imageshack.us)
https://img501.imageshack.us/img501/2239/0081va6.jpg (https://imageshack.us)

The problem is they start jumping when enemy is far away and then fall on the ground. Then they jump again, agian, and again until they meet the enemy. :sweatdrop: :laugh4: Also when charging their models have some glitches in their faces.

This is my entry in descr_skeleton.txt

;;; charge
anim charge data/animations/new_2h_axe_halberd/2h_axe_charge_attack.cas -fr -evt:data/animations/MTW2_2H_Axe/2h_axe_charge_attack.evt
anim charge_to_ready data/animations/new_2h_axe_halberd/2h_axe_charge_to_ready.cas -fr -evt:data/animations/new_2h_axe_halberd/2h_axe_charge_to_ready.evt
anim charge_attack data/animations/new_2h_axe_halberd/2h_axe_charge_attack.cas -fr -evt:data/animations/new_2h_axe_halberd/2h_axe_charge_attack.evt

I think the problem must lie in those id, if stats but I don't understand what's the meaning of them. Could someone explain it to me, please? Or is there some tutorial? Thanks a lot your replies:2thumbsup:

[KnightErrant]

Nice work zxiang1983!
I think the problem is you tied the charge_attack.cas to
the anim command charge. Try switching the anim charge
line to use the charge.cas from the same directory. See if
that keeps them from trying to attack until they close on the
enemy. I don't have the right unit with me to try it out in
Milkshape first but I think this might be the problem. Please
post back your results. It would be great to find new animations
to throw in the game.

[Bwian]

When I was messing with the RTW animations, I built up a table of animations that linked the 'action' to the animation. As KE suggested, the 'charge' action should be a running animation. This is what the game will trigger when the troops are told to attack at a run. The charge attack is what they will do when they get to the end of the charge and attack.

[zxiang1983]

Hi, KE. Thanks for pointing out the mistakes! I corrected them all and this is my entry now:

;;; charge
anim charge data/animations/new_2h_axe_halberd/2h_axe_charge.cas -fr -evt:data/animations/new_2h_axe_halberd/2h_axe_charge.evt
anim charge_to_ready data/animations/new_2h_axe_halberd/2h_axe_charge_to_ready.cas -fr -evt:data/animations/new_2h_axe_halberd/2h_axe_charge_to_ready.evt
anim charge_attack data/animations/new_2h_axe_halberd/2h_axe_charge_attack.cas -fr -evt:data/animations/new_2h_axe_halberd/2h_axe_charge_attack.evt

Again I'm lucky. The charging animation works well now. They raise their halberd and then jump-attack. But still one problem. The model still have glitches in their face. I'm using vanilla Janissary heavy infantry. Its model is fine unitl they start to charge. So the problem must be the animation. Here are the screenshots of what's going on:

https://img502.imageshack.us/img502/9158/0087br3.jpg (https://imageshack.us)
https://img70.imageshack.us/img70/8008/0088st0.jpg (https://imageshack.us)
https://img502.imageshack.us/img502/1415/0089ye7.jpg (https://imageshack.us)
https://img509.imageshack.us/img509/232/0090tb8.jpg (https://imageshack.us)
https://img509.imageshack.us/img509/1572/0091zl8.jpg (https://imageshack.us)


Well, I have to have some sleep now. Continue tomorrow. Thank you for all your help!:2thumbsup:

[KnightErrant]

That's great work, good job!
I guess I'm not familiar enough with this
unit to see the glitches. The screenshots
look ok to me, does anybody else who knows this
unit see what the problem is?

[GrumpyOldMan]

Hi KE and Zxiang


That's great work, good job!
I guess I'm not familiar enough with this
unit to see the glitches. The screenshots
look ok to me, does anybody else who knows this
unit see what the problem is?

Looking at the screen shots it looks like the eyebrows are the problem, pulling the top of the face down to the chin - possibly these anims use a different rotation than 0,0,0 for the initial eyebrow hence the anim is out of kilter with a 0,0,0 eyebrow bone. Or the jaw and eyebrow have been switched? Could possibly be fixed with zero joints?

Cheers

GrumpyOldMan

[KnightErrant]

Ahhh, thanks GrumpyOldMan. I thought I
was looking at pigsnout helms so they seemed
ok but with really tiny eye slits.:laugh4:

[GrumpyOldMan]

Hi KE


Ahhh, thanks GrumpyOldMan. I thought I
was looking at pigsnout helms so they seemed
ok but with really tiny eye slits.:laugh4:

If you look at them that way, I suppose they do :laugh4: :laugh4: . The quick way to fix this without taking the 4 pound hammer to the anim files is to convert the meshes and reassign all the head type vertices just to the head, of course you lose all facial expresions then - but I did say it was quick, nothing about aesthetics :laugh4: :laugh4: . (my guess is that the eyebrow bone is rotated at 90 degrees from zero, hard to tell but the jaws look a bit strange too - could be the same reason).

Cheers

GrumpyOldMan

[zxiang1983]

The quick way to fix this without taking the 4 pound hammer to the anim files is to convert the meshes and reassign all the head type vertices just to the head, of course you lose all facial expresions then - but I did say it was quick, nothing about aesthetics .

Ya, the problem is some part of the helmet is pulled down to his chin.

Thank you, GOM! I'll give it a try.

And what about the complicated way? What shall I do if I don't want to re-assign all head vertices? I don't understand the "90 degree" thing. Could you explain it a little more? Is it about those id, if stats? Thanks in advance!

[GrumpyOldMan]

Hi Zxiang


Ya, the problem is some part of the helmet is pulled down to his chin.

Thank you, GOM! I'll give it a try.

And what about the complicated way? What shall I do if I don't want to re-assign all head vertices? I don't understand the "90 degree" thing. Could you explain it a little more? Is it about those id, if stats? Thanks in advance!

The 90 degree thing is about the actual data in the anim files, I tried to open the files but they weren't opening with my current version of KE's utilities. The only place to be sure about the errors and repair them is in Milkshape once we get the files extracted. In the meantime, the only way to use the anims is to reassign any head vertices from any figures that might be using the anims.

Cheers

GrumpyOldMan

[KnightErrant]

Ok, sorry to be so pedantic but I'm returning to the survey.
Now I've got everything automated so my button for doing a
directory survey is about to be obsolete. Unfortunately, doing the
survey means I can't look at zxiang1983's anim until I refix my
cas to txt converter back to where it was.

Anyway: Let's look at elephant_cavalry/elephant_rider
because this gave me the best guess for what are floats in the footer.


HR_elephant_rider_celebrate_1.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +1.000 1 0 0 0 0 1 0 102 102 102
222 1 1 CaozSceneCustomAttribNode 2, CaozSceneCustomAttribNode 3, CaozSceneCustomAttribNode 4, CaozSceneCustomAttribNode 5, CaozSceneCustomAttribNode 1 1 0 1 0 0
-0.00000 -1.00000 -0.00000 +0.00000 +0.00000 +0.30000 +0.00000 0 0 -1 0 0 1
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
12 12 0
-------
310

HR_elephant_rider_dying.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +1.600 1 0 0 0 0 1 0 102 102 102
222 1 1 CaozSceneCustomAttribNode 2, CaozSceneCustomAttribNode 3, CaozSceneCustomAttribNode 4, CaozSceneCustomAttribNode 5, CaozSceneCustomAttribNode 1 1 0 1 0 0
-0.00000 -1.00000 -0.00000 +0.00000 +0.00000 +0.00000 +0.00000 0 0 -1 0 0 1
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
12 12 0
-------
310

HR_elephant_rider_kill_mount.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +1.400 1 0 0 0 0 1 0 102 102 102
222 1 1 CaozSceneCustomAttribNode 2, CaozSceneCustomAttribNode 3, CaozSceneCustomAttribNode 4, CaozSceneCustomAttribNode 5, CaozSceneCustomAttribNode 1 1 0 1 0 0
-0.00000 -1.00000 -0.00000 +0.00000 +0.00000 +0.30000 +0.00000 0 0 -1 0 0 1
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
12 12 0
-------
310

HR_elephant_rider_run_to_stand_a.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +1.800 1 0 0 0 0 1 0 102 102 102
222 1 1 CaozSceneCustomAttribNode 2, CaozSceneCustomAttribNode 3, CaozSceneCustomAttribNode 4, CaozSceneCustomAttribNode 5, CaozSceneCustomAttribNode 1 1 0 1 0 0
-0.00000 -1.00000 -0.00000 +0.00000 +0.00000 +0.00000 +0.00000 0 0 -1 0 0 1
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
12 12 0
-------
310

HR_elephant_rider_stand_a_hf_idle_1.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +2.400 1 0 0 0 0 1 0 102 102 102
222 1 1 CaozSceneCustomAttribNode 2, CaozSceneCustomAttribNode 3, CaozSceneCustomAttribNode 4, CaozSceneCustomAttribNode 5, CaozSceneCustomAttribNode 1 1 0 1 0 0
-0.00000 -1.00000 -0.00000 +0.00000 +0.00000 +0.30000 +0.00000 0 0 -1 0 0 1
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
12 12 0
-------
310

HR_elephant_rider_stand_a_hf_idle_2.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +2.000 1 0 0 0 0 1 0 102 102 102
222 1 1 CaozSceneCustomAttribNode 2, CaozSceneCustomAttribNode 3, CaozSceneCustomAttribNode 4, CaozSceneCustomAttribNode 5, CaozSceneCustomAttribNode 1 1 0 1 0 0
-0.00000 -1.00000 -0.00000 +0.00000 +0.00000 +0.30000 +0.00000 0 0 -1 0 0 1
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
12 12 0
-------
310

HR_elephant_rider_stand_a_hf_idle_3.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +2.000 1 0 0 0 0 1 0 102 102 102
222 1 1 CaozSceneCustomAttribNode 2, CaozSceneCustomAttribNode 3, CaozSceneCustomAttribNode 4, CaozSceneCustomAttribNode 5, CaozSceneCustomAttribNode 1 1 0 1 0 0
-0.00000 -1.00000 -0.00000 +0.00000 +0.00000 +0.30000 +0.00000 0 0 -1 0 0 1
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
12 12 0
-------
310

HR_elephant_rider_stand_a_idle.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +1.000 1 0 0 0 0 1 0 102 102 102
222 1 1 CaozSceneCustomAttribNode 2, CaozSceneCustomAttribNode 3, CaozSceneCustomAttribNode 4, CaozSceneCustomAttribNode 5, CaozSceneCustomAttribNode 1 1 0 1 0 0
-0.00000 -1.00000 -0.00000 +0.00000 +0.00000 +0.30000 +0.00000 0 0 -1 0 0 1
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
12 12 0
-------
310

HR_elephant_rider_stand_a_to_run.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +0.900 1 0 0 0 0 1 0 102 102 102
222 1 1 CaozSceneCustomAttribNode 2, CaozSceneCustomAttribNode 3, CaozSceneCustomAttribNode 4, CaozSceneCustomAttribNode 5, CaozSceneCustomAttribNode 1 1 0 1 0 0
-0.00000 -1.00000 -0.00000 +0.00000 +0.00000 +0.00000 +0.00000 0 0 -1 0 0 1
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
12 12 0
-------
310

HR_elephant_rider_stand_a_to_walk.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +1.200 1 0 0 0 0 1 0 102 102 102
222 1 1 CaozSceneCustomAttribNode 2, CaozSceneCustomAttribNode 3, CaozSceneCustomAttribNode 4, CaozSceneCustomAttribNode 5, CaozSceneCustomAttribNode 1 1 0 1 0 0
-0.00000 -1.00000 -0.00000 +0.00000 +0.00000 +0.00000 +0.00000 0 0 -1 0 0 1
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
12 12 0
-------
310

HR_elephant_rider_taunt_1.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +1.000 1 0 0 0 0 1 0 102 102 102
222 1 1 CaozSceneCustomAttribNode 2, CaozSceneCustomAttribNode 3, CaozSceneCustomAttribNode 4, CaozSceneCustomAttribNode 5, CaozSceneCustomAttribNode 1 1 0 1 0 0
-0.00000 -1.00000 -0.00000 +0.00000 +0.00000 +0.30000 +0.00000 0 0 -1 0 0 1
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
12 12 0
-------
310

HR_elephant_rider_walk_to_stand_a.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +1.100 1 0 0 0 0 1 0 102 102 102
222 1 1 CaozSceneCustomAttribNode 2, CaozSceneCustomAttribNode 3, CaozSceneCustomAttribNode 4, CaozSceneCustomAttribNode 5, CaozSceneCustomAttribNode 1 1 0 1 0 0
-0.00000 -1.00000 -0.00000 +0.00000 +0.00000 +0.00000 +0.00000 0 0 -1 0 0 1
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
12 12 0
-------
310

Processed 12 in this directory...

HR_elephant_rider_celebrate_1.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +1.000 1 0 0 0 0 1 0 102 102 102
222 1 1 CaozSceneCustomAttribNode 2, CaozSceneCustomAttribNode 3, CaozSceneCustomAttribNode 4, CaozSceneCustomAttribNode 5, CaozSceneCustomAttribNode 1 1 0 1 0 0
-0.00000 -1.00000 -0.00000 +0.00000 +0.00000 +0.30000 +0.00000 0 0 -1 0 0 1
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
12 12 0
-------
310

HR_elephant_rider_dying.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +1.600 1 0 0 0 0 1 0 102 102 102
222 1 1 CaozSceneCustomAttribNode 2, CaozSceneCustomAttribNode 3, CaozSceneCustomAttribNode 4, CaozSceneCustomAttribNode 5, CaozSceneCustomAttribNode 1 1 0 1 0 0
-0.00000 -1.00000 -0.00000 +0.00000 +0.00000 +0.00000 +0.00000 0 0 -1 0 0 1
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
12 12 0
-------
310

HR_elephant_rider_kill_mount.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +1.400 1 0 0 0 0 1 0 102 102 102
222 1 1 CaozSceneCustomAttribNode 2, CaozSceneCustomAttribNode 3, CaozSceneCustomAttribNode 4, CaozSceneCustomAttribNode 5, CaozSceneCustomAttribNode 1 1 0 1 0 0
-0.00000 -1.00000 -0.00000 +0.00000 +0.00000 +0.30000 +0.00000 0 0 -1 0 0 1
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
12 12 0
-------
310

HR_elephant_rider_run_to_stand_a.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +1.800 1 0 0 0 0 1 0 102 102 102
222 1 1 CaozSceneCustomAttribNode 2, CaozSceneCustomAttribNode 3, CaozSceneCustomAttribNode 4, CaozSceneCustomAttribNode 5, CaozSceneCustomAttribNode 1 1 0 1 0 0
-0.00000 -1.00000 -0.00000 +0.00000 +0.00000 +0.00000 +0.00000 0 0 -1 0 0 1
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
12 12 0
-------
310

HR_elephant_rider_stand_a_hf_idle_1.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +2.400 1 0 0 0 0 1 0 102 102 102
222 1 1 CaozSceneCustomAttribNode 2, CaozSceneCustomAttribNode 3, CaozSceneCustomAttribNode 4, CaozSceneCustomAttribNode 5, CaozSceneCustomAttribNode 1 1 0 1 0 0
-0.00000 -1.00000 -0.00000 +0.00000 +0.00000 +0.30000 +0.00000 0 0 -1 0 0 1
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
12 12 0
-------
310

HR_elephant_rider_stand_a_hf_idle_2.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +2.000 1 0 0 0 0 1 0 102 102 102
222 1 1 CaozSceneCustomAttribNode 2, CaozSceneCustomAttribNode 3, CaozSceneCustomAttribNode 4, CaozSceneCustomAttribNode 5, CaozSceneCustomAttribNode 1 1 0 1 0 0
-0.00000 -1.00000 -0.00000 +0.00000 +0.00000 +0.30000 +0.00000 0 0 -1 0 0 1
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
12 12 0
-------
310

HR_elephant_rider_stand_a_hf_idle_3.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +2.000 1 0 0 0 0 1 0 102 102 102
222 1 1 CaozSceneCustomAttribNode 2, CaozSceneCustomAttribNode 3, CaozSceneCustomAttribNode 4, CaozSceneCustomAttribNode 5, CaozSceneCustomAttribNode 1 1 0 1 0 0
-0.00000 -1.00000 -0.00000 +0.00000 +0.00000 +0.30000 +0.00000 0 0 -1 0 0 1
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
12 12 0
-------
310

HR_elephant_rider_stand_a_idle.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +1.000 1 0 0 0 0 1 0 102 102 102
222 1 1 CaozSceneCustomAttribNode 2, CaozSceneCustomAttribNode 3, CaozSceneCustomAttribNode 4, CaozSceneCustomAttribNode 5, CaozSceneCustomAttribNode 1 1 0 1 0 0
-0.00000 -1.00000 -0.00000 +0.00000 +0.00000 +0.30000 +0.00000 0 0 -1 0 0 1
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
12 12 0
-------
310

HR_elephant_rider_stand_a_to_run.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +0.900 1 0 0 0 0 1 0 102 102 102
222 1 1 CaozSceneCustomAttribNode 2, CaozSceneCustomAttribNode 3, CaozSceneCustomAttribNode 4, CaozSceneCustomAttribNode 5, CaozSceneCustomAttribNode 1 1 0 1 0 0
-0.00000 -1.00000 -0.00000 +0.00000 +0.00000 +0.00000 +0.00000 0 0 -1 0 0 1
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
12 12 0
-------
310

HR_elephant_rider_stand_a_to_walk.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +1.200 1 0 0 0 0 1 0 102 102 102
222 1 1 CaozSceneCustomAttribNode 2, CaozSceneCustomAttribNode 3, CaozSceneCustomAttribNode 4, CaozSceneCustomAttribNode 5, CaozSceneCustomAttribNode 1 1 0 1 0 0
-0.00000 -1.00000 -0.00000 +0.00000 +0.00000 +0.00000 +0.00000 0 0 -1 0 0 1
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
12 12 0
-------
310

HR_elephant_rider_taunt_1.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +1.000 1 0 0 0 0 1 0 102 102 102
222 1 1 CaozSceneCustomAttribNode 2, CaozSceneCustomAttribNode 3, CaozSceneCustomAttribNode 4, CaozSceneCustomAttribNode 5, CaozSceneCustomAttribNode 1 1 0 1 0 0
-0.00000 -1.00000 -0.00000 +0.00000 +0.00000 +0.30000 +0.00000 0 0 -1 0 0 1
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
12 12 0
-------
310

HR_elephant_rider_walk_to_stand_a.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +1.100 1 0 0 0 0 1 0 102 102 102
222 1 1 CaozSceneCustomAttribNode 2, CaozSceneCustomAttribNode 3, CaozSceneCustomAttribNode 4, CaozSceneCustomAttribNode 5, CaozSceneCustomAttribNode 1 1 0 1 0 0
-0.00000 -1.00000 -0.00000 +0.00000 +0.00000 +0.00000 +0.00000 0 0 -1 0 0 1
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
12 12 0
-------
310

Processed 12 in this directory...


If I follow this I can do other directories with the floats done the same
way. I leave anything that this directory doesn't tell me is a float as an
int.

Camels next: They're funny. New footer here for many of them.
Distinguished by hex 12 or decimal 18 for the lead int to the footer.
I'm breaking the footer up following my numerology excursion:




Camel_die.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +4.500 1 0 0 0 0 1 0 10 10 10
104 1 1 CaozSceneCustomAttribNode 1 0 1 0 0
-0.50000 -0.50000 -0.50000 +0.50000 +0.00000 +0.00000 +0.00000 0 0 -1 0 0 1
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
12 12 0
-------
192

Camel_die_galloping.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +4.500 1 0 0 0 0 1 0 10 10 10
104 1 1 CaozSceneCustomAttribNode 1 0 1 0 0
+0.00000 +0.00000 +0.00000 +1.00000 +0.00000 +0.00000 +0.00000 0 0 -1 0 0 1
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
12 12 0
-------
192

Camel_Gallop.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.020 38 9 0 +0.500 1 0 0 0 0 1 0 10 10 10
18 1 0 0 0
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
-------
94

Camel_Idle.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +4.900 1 0 0 0 0 1 0 10 10 10
104 1 1 CaozSceneCustomAttribNode 1 0 1 0 0
-0.50000 -0.50000 -0.50000 +0.50000 +0.00000 +0.00000 +0.00000 0 0 -1 0 0 1
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
12 12 0
-------
192

Camel_R2G.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.020 38 9 0 +0.500 1 0 0 0 0 1 0 10 10 10
18 1 0 0 0
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
-------
94

Camel_R2S.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.180 38 9 0 +1.600 1 0 0 0 0 1 0 10 10 10
18 1 0 0 0
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
-------
94

Camel_R2W.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.180 38 9 0 +0.700 1 0 0 0 0 1 0 10 10 10
18 1 0 0 0
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
-------
94

Camel_run.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.180 38 9 0 +0.700 1 0 0 0 0 1 0 10 10 10
18 1 0 0 0
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
-------
94

Camel_S2G.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.020 38 9 0 +1.000 1 0 0 0 0 1 0 10 10 10
18 1 0 0 0
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
-------
94

Camel_S2R.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.020 38 9 0 +1.100 1 0 0 0 0 1 0 10 10 10
18 1 0 0 0
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
-------
94

Camel_S2W.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.020 38 9 0 +1.000 1 0 0 0 0 1 0 10 10 10
18 1 0 0 0
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
-------
94

Camel_shuffle backwards.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.020 38 9 0 +1.400 1 0 0 0 0 1 0 10 10 10
18 1 0 0 0
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
-------
94

Camel_shuffle forwards.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.020 38 9 0 +1.400 1 0 0 0 0 1 0 10 10 10
18 1 0 0 0
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
-------
94

camel_shuffle_left.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +1.400 1 0 0 0 0 1 0 10 10 10
104 1 1 CaozSceneCustomAttribNode 1 0 1 0 0
-0.50000 -0.50000 -0.50000 +0.50000 +0.00000 +0.00000 +0.00000 0 0 -1 0 0 1
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
12 12 0
-------
192

camel_shuffle_right.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +1.400 1 0 0 0 0 1 0 10 10 10
191 1 1 CaozSceneCustomAttribNode, CaozSceneCustomAttribNode01, CaozSceneCustomAttribNode02, CaozSceneCustomAttribNode03 1 0 1 0 0
-0.50000 -0.50000 -0.50000 +0.50000 +0.00000 +0.00000 +0.00000 0 0 -1 0 0 1
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
12 12 0
-------
279

camel_STAND2SWIM.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.200 38 9 0 +0.500 1 0 0 0 0 1 0 10 10 10
18 1 0 0 0
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
-------
94

camel_stand_a_hf_idle_1.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +0.800 1 0 0 0 0 1 0 10 10 10
104 1 1 CaozSceneCustomAttribNode 1 0 1 0 0
-0.50000 -0.50000 -0.50000 +0.50000 +0.00000 +0.00000 +0.00000 0 0 -1 0 0 1
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
12 12 0
-------
192

camel_stand_a_hf_idle_2.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +1.600 1 0 0 0 0 1 0 10 10 10
104 1 1 CaozSceneCustomAttribNode 1 0 1 0 0
+0.00000 +0.00000 +0.00000 +1.00000 +0.00000 +0.00000 +0.00000 0 0 -1 0 0 1
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
12 12 0
-------
192

camel_stand_a_hf_idle_3.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +0.800 1 0 0 0 0 1 0 10 10 10
104 1 1 CaozSceneCustomAttribNode 1 0 1 0 0
-0.50000 -0.50000 -0.50000 +0.50000 +0.00000 +0.00000 +0.00000 0 0 -1 0 0 1
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
12 12 0
-------
192

camel_swim.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.200 38 9 0 +1.000 1 0 0 0 0 1 0 10 10 10
18 1 0 0 0
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
-------
94

camel_SWIM2STAND.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.200 38 9 0 +0.500 1 0 0 0 0 1 0 10 10 10
18 1 0 0 0
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
-------
94

camel_swim_shuffle_backward.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.200 38 9 0 +1.000 1 0 0 0 0 1 0 10 10 10
18 1 0 0 0
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
-------
94

camel_swim_shuffle_forward.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.200 38 9 0 +1.000 1 0 0 0 0 1 0 10 10 10
18 1 0 0 0
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
-------
94

camel_swim_shuffle_left.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.200 38 9 0 +1.000 1 0 0 0 0 1 0 10 10 10
18 1 0 0 0
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
-------
94

camel_swim_shuffle_right.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.200 38 9 0 +1.000 1 0 0 0 0 1 0 10 10 10
18 1 0 0 0
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
-------
94

camel_swim_treadwater.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.200 38 9 0 +1.000 1 0 0 0 0 1 0 10 10 10
18 1 0 0 0
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
-------
94

Camel_turn left.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.020 38 9 0 +0.700 1 0 0 0 0 1 0 0 0 0
18 1 0 0 0
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
-------
94

Camel_turn right.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.020 38 9 0 +0.700 1 0 0 0 0 1 0 0 0 0
18 1 0 0 0
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
-------
94

Camel_W2R.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.020 38 9 0 +0.600 1 0 0 0 0 1 0 10 10 10
18 1 0 0 0
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
-------
94

Camel_W2S.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.020 38 9 0 +1.200 1 0 0 0 0 1 0 10 10 10
18 1 0 0 0
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
-------
94

Camel_walk.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.170 38 9 0 +1.000 1 0 0 0 0 1 0 10 10 10
18 1 0 0 0
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0
-------
94

Processed 31 in this directory...

Horsies next: These are fun, lots of extra data here, don't understand
it but its here....



fs_fast_horse_charge.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +0.500 1 0 0 0 0 1 0 102 102 102
170 1 2 CaozSceneCustomAttribNode 1 0 1 0 0
+0.00000 +0.00000 +0.00000 +1.00000 +0.00000 +0.00000 +0.00000 0 0 -1 0 Plane 1 0 1 0 0
-0.70711 +0.00000 +0.00000 +0.70711 +2.43048 -4.76820 -7.87057 0 0 0 0 2
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
73 5 1 0 +0.838 +0.612 +0.612 +1.000 +0.200 +0.200 +0.200 0 0 0 0 0 0 0 1
12 12 0
-------
319

fs_fast_horse_run.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +0.600 1 0 0 0 0 1 0 102 102 102
170 1 2 CaozSceneCustomAttribNode 1 0 1 0 0
+0.00000 +0.00000 +0.00000 +1.00000 +0.00000 +0.00000 +0.00000 0 0 -1 0 Plane 1 0 1 0 0
-0.70711 +0.00000 +0.00000 +0.70711 +2.43048 -4.76820 -7.87057 0 0 0 0 2
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
73 5 1 0 +0.838 +0.612 +0.612 +1.000 +0.200 +0.200 +0.200 0 0 0 0 0 0 0 1
12 12 0
-------
319

fs_heavy_horse_charge.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +0.500 1 0 0 0 0 1 0 102 102 102
170 1 2 CaozSceneCustomAttribNode 1 0 1 0 0
+0.00000 +0.00000 +0.00000 +1.00000 +0.00000 +0.00000 +0.00000 0 0 -1 0 Plane 1 0 1 0 0
-0.70711 +0.00000 +0.00000 +0.70711 +2.43048 -4.76820 -7.87057 0 0 0 0 2
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
73 5 1 0 +0.838 +0.612 +0.612 +1.000 +0.200 +0.200 +0.200 0 0 0 0 0 0 0 1
12 12 0
-------
319

fs_heavy_horse_run.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +0.600 1 0 0 0 0 1 0 102 102 102
170 1 2 CaozSceneCustomAttribNode 1 0 1 0 0
+0.00000 +0.00000 +0.00000 +1.00000 +0.00000 +0.00000 +0.00000 0 0 -1 0 Plane 1 0 1 0 0
-0.70711 +0.00000 +0.00000 +0.70711 +2.43048 -4.76820 -7.87057 0 0 0 0 2
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
73 5 1 0 +0.838 +0.612 +0.612 +1.000 +0.200 +0.200 +0.200 0 0 0 0 0 0 0 1
12 12 0
-------
319

fs_heavy_horse_stand_a_to_run.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +3.000 1 0 0 0 0 1 0 102 102 102
170 1 2 CaozSceneCustomAttribNode 1 0 1 0 0
+0.00000 +0.00000 +0.00000 +1.00000 +0.00000 +0.00000 +0.00000 0 0 -1 0 Plane 1 0 1 0 0
-0.70711 +0.00000 +0.00000 +0.70711 +2.43048 -4.76820 -7.87057 0 0 0 0 2
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
73 5 1 0 +0.838 +0.612 +0.612 +1.000 +0.200 +0.200 +0.200 0 0 0 0 0 0 0 1
12 12 0
-------
319

fs_heavy_horse_walk_to_run.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +2.400 1 0 0 0 0 1 0 102 102 102
170 1 2 CaozSceneCustomAttribNode 1 0 1 0 0
+0.00000 +0.00000 +0.00000 +1.00000 +0.00000 +0.00000 +0.00000 0 0 -1 0 Plane 1 0 1 0 0
-0.70711 +0.00000 +0.00000 +0.70711 +2.43048 -4.76820 -7.87057 0 0 0 0 2
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
73 5 1 0 +0.838 +0.612 +0.612 +1.000 +0.200 +0.200 +0.200 0 0 0 0 0 0 0 1
12 12 0
-------
319

fs_horse_attack_mid_centre_1.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +3.000 1 0 0 0 0 1 0 102 102 102
170 1 2 CaozSceneCustomAttribNode 1 0 1 0 0
+0.00000 +0.00000 +0.00000 +1.00000 +0.00000 +0.00000 +0.00000 0 0 -1 0 Plane 1 0 1 0 0
-0.70711 +0.00000 +0.00000 +0.70711 +2.43048 -4.76820 -7.87057 0 0 0 0 2
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
73 5 1 0 +0.838 +0.612 +0.612 +1.000 +0.200 +0.200 +0.200 0 0 0 0 0 0 0 1
12 12 0
-------
319

fs_horse_charge.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +0.500 1 0 0 0 0 1 0 102 102 102
170 1 2 CaozSceneCustomAttribNode 1 0 1 0 0
+0.00000 +0.00000 +0.00000 +1.00000 +0.00000 +0.00000 +0.00000 0 0 -1 0 Plane 1 0 1 0 0
-0.70711 +0.00000 +0.00000 +0.70711 +2.43048 -4.76820 -7.87057 0 0 0 0 2
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
73 5 1 0 +0.838 +0.612 +0.612 +1.000 +0.200 +0.200 +0.200 0 0 0 0 0 0 0 1
12 12 0
-------
319

fs_horse_default.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.200 38 9 0 +0.150 1 0 0 0 0 1 0 102 102 102
104 1 1 CaozSceneCustomAttribNode 1 0 1 0 0
+0.00000 +0.00000 +0.00000 +1.00000 +0.00000 +0.00000 +0.00000 0 0 -1 0 ANOMALOUS CAS FILE DETECTED: BAD FOOTER DATA...MISSING 12 BYTES, THE INTS 12 12 0
0 1
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
12 5 0

-------
180

fs_horse_die_backward_1.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +4.500 1 0 0 0 0 1 0 102 102 102
170 1 2 CaozSceneCustomAttribNode 1 0 1 0 0
+0.00000 +0.00000 +0.00000 +1.00000 +0.00000 +0.00000 +0.00000 0 0 -1 0 Plane 1 0 1 0 0
-0.70711 +0.00000 +0.00000 +0.70711 +2.43048 -4.76820 -7.87057 0 0 0 0 2
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
73 5 1 0 +0.838 +0.612 +0.612 +1.000 +0.200 +0.200 +0.200 0 0 0 0 0 0 0 1
12 12 0
-------
319

fs_horse_die_backward_2.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +4.500 1 0 0 0 0 1 0 102 102 102
170 1 2 CaozSceneCustomAttribNode 1 0 1 0 0
+0.00000 +0.00000 +0.00000 +1.00000 +0.00000 +0.00000 +0.00000 0 0 -1 0 Plane 1 0 1 0 0
-0.70711 +0.00000 +0.00000 +0.70711 +2.43048 -4.76820 -7.87057 0 0 0 0 2
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
73 5 1 0 +0.838 +0.612 +0.612 +1.000 +0.200 +0.200 +0.200 0 0 0 0 0 0 0 1
12 12 0
-------
319

fs_horse_die_forward_1.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +4.500 1 0 0 0 0 1 0 102 102 102
170 1 2 CaozSceneCustomAttribNode 1 0 1 0 0
+0.00000 +0.00000 +0.00000 +1.00000 +0.00000 +0.00000 +0.00000 0 0 -1 0 Plane 1 0 1 0 0
-0.70711 +0.00000 +0.00000 +0.70711 +2.43048 -4.76820 -7.87057 0 0 0 0 2
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
73 5 1 0 +0.838 +0.612 +0.612 +1.000 +0.200 +0.200 +0.200 0 0 0 0 0 0 0 1
12 12 0
-------
319

fs_horse_die_forward_2.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +4.500 1 0 0 0 0 1 0 102 102 102
170 1 2 CaozSceneCustomAttribNode 1 0 1 0 0
+0.00000 +0.00000 +0.00000 +1.00000 +0.00000 +0.00000 +0.00000 0 0 -1 0 Plane 1 0 1 0 0
-0.70711 +0.00000 +0.00000 +0.70711 +2.43048 -4.76820 -7.87057 0 0 0 0 2
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
73 5 1 0 +0.838 +0.612 +0.612 +1.000 +0.200 +0.200 +0.200 0 0 0 0 0 0 0 1
12 12 0
-------
319

fs_horse_die_galloping.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +4.500 1 0 0 0 0 1 0 102 102 102
170 1 2 CaozSceneCustomAttribNode 1 0 1 0 0
+0.00000 +0.00000 +0.00000 +1.00000 +0.00000 +0.00000 +0.00000 0 0 -1 0 Plane 1 0 1 0 0
-0.70711 +0.00000 +0.00000 +0.70711 +2.43048 -4.76820 -7.87057 0 0 0 0 2
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
73 5 1 0 +0.838 +0.612 +0.612 +1.000 +0.200 +0.200 +0.200 0 0 0 0 0 0 0 1
12 12 0
-------
319

fs_horse_die_refusing.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +4.500 1 0 0 0 0 1 0 102 102 102
170 1 2 CaozSceneCustomAttribNode 1 0 1 0 0
+0.00000 +0.00000 +0.00000 +1.00000 +0.00000 +0.00000 +0.00000 0 0 -1 0 Plane 1 0 1 0 0
-0.70711 +0.00000 +0.00000 +0.70711 +2.43048 -4.76820 -7.87057 0 0 0 0 2
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
73 5 1 0 +0.838 +0.612 +0.612 +1.000 +0.200 +0.200 +0.200 0 0 0 0 0 0 0 1
12 12 0
-------
319

fs_horse_jump.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +2.400 1 0 0 0 0 1 0 102 102 102
170 1 2 CaozSceneCustomAttribNode 1 0 1 0 0
+0.00000 +0.00000 +0.00000 +1.00000 +0.00000 +0.00000 +0.00000 0 0 -1 0 Plane 1 0 1 0 0
-0.70711 +0.00000 +0.00000 +0.70711 +2.43048 -4.76820 -7.87057 0 0 0 0 2
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
73 5 1 0 +0.838 +0.612 +0.612 +1.000 +0.200 +0.200 +0.200 0 0 0 0 0 0 0 1
12 12 0
-------
319

fs_horse_refuse.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +2.200 1 0 0 0 0 1 0 102 102 102
170 1 2 CaozSceneCustomAttribNode 1 0 1 0 0
+0.00000 +0.00000 +0.00000 +1.00000 +0.00000 +0.00000 +0.00000 0 0 -1 0 Plane 1 0 1 0 0
-0.70711 +0.00000 +0.00000 +0.70711 +2.43048 -4.76820 -7.87057 0 0 0 0 2
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
73 5 1 0 +0.838 +0.612 +0.612 +1.000 +0.200 +0.200 +0.200 0 0 0 0 0 0 0 1
12 12 0
-------
319

fs_horse_run.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +0.600 1 0 0 0 0 1 0 102 102 102
170 1 2 CaozSceneCustomAttribNode 1 0 1 0 0
+0.00000 +0.00000 +0.00000 +1.00000 +0.00000 +0.00000 +0.00000 0 0 -1 0 Plane 1 0 1 0 0
-0.70711 +0.00000 +0.00000 +0.70711 +2.43048 -4.76820 -7.87057 0 0 0 0 2
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
73 5 1 0 +0.838 +0.612 +0.612 +1.000 +0.200 +0.200 +0.200 0 0 0 0 0 0 0 1
12 12 0
-------
319

fs_horse_run_to_charge.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +0.600 1 0 0 0 0 1 0 102 102 102
170 1 2 CaozSceneCustomAttribNode 1 0 1 0 0
+0.00000 +0.00000 +0.00000 +1.00000 +0.00000 +0.00000 +0.00000 0 0 -1 0 Plane 1 0 1 0 0
-0.70711 +0.00000 +0.00000 +0.70711 +2.43048 -4.76820 -7.87057 0 0 0 0 2
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
73 5 1 0 +0.838 +0.612 +0.612 +1.000 +0.200 +0.200 +0.200 0 0 0 0 0 0 0 1
12 12 0
-------
319

fs_horse_run_to_stand_a.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +2.500 1 0 0 0 0 1 0 102 102 102
170 1 2 CaozSceneCustomAttribNode 1 0 1 0 0
+0.00000 +0.00000 +0.00000 +1.00000 +0.00000 +0.00000 +0.00000 0 0 -1 0 Plane 1 0 1 0 0
-0.70711 +0.00000 +0.00000 +0.70711 +2.43048 -4.76820 -7.87057 0 0 0 0 2
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
73 5 1 0 +0.838 +0.612 +0.612 +1.000 +0.200 +0.200 +0.200 0 0 0 0 0 0 0 1
12 12 0
-------
319

fs_horse_run_to_walk.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +1.500 1 0 0 0 0 1 0 102 102 102
170 1 2 CaozSceneCustomAttribNode 1 0 1 0 0
+0.00000 +0.00000 +0.00000 +1.00000 +0.00000 +0.00000 +0.00000 0 0 -1 0 Plane 1 0 1 0 0
-0.70711 +0.00000 +0.00000 +0.70711 +2.43048 -4.76820 -7.87057 0 0 0 0 2
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
73 5 1 0 +0.838 +0.612 +0.612 +1.000 +0.200 +0.200 +0.200 0 0 0 0 0 0 0 1
12 12 0
-------
319

fs_horse_shuffle_backward.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +1.500 1 0 0 0 0 1 0 102 102 102
170 1 2 CaozSceneCustomAttribNode 1 0 1 0 0
+0.00000 +0.00000 +0.00000 +1.00000 +0.00000 +0.00000 +0.00000 0 0 -1 0 Plane 1 0 1 0 0
-0.70711 +0.00000 +0.00000 +0.70711 +2.43048 -4.76820 -7.87057 0 0 0 0 2
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
73 5 1 0 +0.838 +0.612 +0.612 +1.000 +0.200 +0.200 +0.200 0 0 0 0 0 0 0 1
12 12 0
-------
319

fs_horse_shuffle_forward.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +1.500 1 0 0 0 0 1 0 102 102 102
170 1 2 CaozSceneCustomAttribNode 1 0 1 0 0
+0.00000 +0.00000 +0.00000 +1.00000 +0.00000 +0.00000 +0.00000 0 0 -1 0 Plane 1 0 1 0 0
-0.70711 +0.00000 +0.00000 +0.70711 +2.43048 -4.76820 -7.87057 0 0 0 0 2
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
73 5 1 0 +0.838 +0.612 +0.612 +1.000 +0.200 +0.200 +0.200 0 0 0 0 0 0 0 1
12 12 0
-------
319

fs_horse_shuffle_left.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +1.500 1 0 0 0 0 1 0 102 102 102
170 1 2 CaozSceneCustomAttribNode 1 0 1 0 0
+0.00000 +0.00000 +0.00000 +1.00000 +0.00000 +0.00000 +0.00000 0 0 -1 0 Plane 1 0 1 0 0
-0.70711 +0.00000 +0.00000 +0.70711 +2.43048 -4.76820 -7.87057 0 0 0 0 2
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
73 5 1 0 +0.838 +0.612 +0.612 +1.000 +0.200 +0.200 +0.200 0 0 0 0 0 0 0 1
12 12 0
-------
319

fs_horse_shuffle_right.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +1.500 1 0 0 0 0 1 0 102 102 102
170 1 2 CaozSceneCustomAttribNode 1 0 1 0 0
+0.00000 +0.00000 +0.00000 +1.00000 +0.00000 +0.00000 +0.00000 0 0 -1 0 Plane 1 0 1 0 0
-0.70711 +0.00000 +0.00000 +0.70711 +2.43048 -4.76820 -7.87057 0 0 0 0 2
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
73 5 1 0 +0.838 +0.612 +0.612 +1.000 +0.200 +0.200 +0.200 0 0 0 0 0 0 0 1
12 12 0
-------
319

fs_horse_stand_a_hf_idle_1.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +1.500 1 0 0 0 0 1 0 102 102 102
170 1 2 CaozSceneCustomAttribNode 1 0 1 0 0
+0.00000 +0.00000 +0.00000 +1.00000 +0.00000 +0.00000 +0.00000 0 0 -1 0 Plane 1 0 1 0 0
-0.70711 +0.00000 +0.00000 +0.70711 +2.43048 -4.76820 -7.87057 0 0 0 0 2
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
73 5 1 0 +0.838 +0.612 +0.612 +1.000 +0.200 +0.200 +0.200 0 0 0 0 0 0 0 1
12 12 0
-------
319

fs_horse_stand_a_hf_idle_2.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +2.100 1 0 0 0 0 1 0 102 102 102
170 1 2 CaozSceneCustomAttribNode 1 0 1 0 0
+0.00000 +0.00000 +0.00000 +1.00000 +0.00000 +0.00000 +0.00000 0 0 -1 0 Plane 1 0 1 0 0
-0.70711 +0.00000 +0.00000 +0.70711 +2.43048 -4.76820 -7.87057 0 0 0 0 2
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
73 5 1 0 +0.838 +0.612 +0.612 +1.000 +0.200 +0.200 +0.200 0 0 0 0 0 0 0 1
12 12 0
-------
319

fs_horse_stand_a_hf_idle_3.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +2.500 1 0 0 0 0 1 0 102 102 102
170 1 2 CaozSceneCustomAttribNode 1 0 1 0 0
+0.00000 +0.00000 +0.00000 +1.00000 +0.00000 +0.00000 +0.00000 0 0 -1 0 Plane 1 0 1 0 0
-0.70711 +0.00000 +0.00000 +0.70711 +2.43048 -4.76820 -7.87057 0 0 0 0 2
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
73 5 1 0 +0.838 +0.612 +0.612 +1.000 +0.200 +0.200 +0.200 0 0 0 0 0 0 0 1
12 12 0
-------
319

fs_horse_stand_a_idle.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +1.500 1 0 0 0 0 1 0 102 102 102
170 1 2 CaozSceneCustomAttribNode 1 0 1 0 0
+0.00000 +0.00000 +0.00000 +1.00000 +0.00000 +0.00000 +0.00000 0 0 -1 0 Plane 1 0 1 0 0
-0.70711 +0.00000 +0.00000 +0.70711 +2.43048 -4.76820 -7.87057 0 0 0 0 2
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
73 5 1 0 +0.838 +0.612 +0.612 +1.000 +0.200 +0.200 +0.200 0 0 0 0 0 0 0 1
12 12 0
-------
319

fs_horse_stand_a_lf_idle_1.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +2.400 1 0 0 0 0 1 0 102 102 102
170 1 2 CaozSceneCustomAttribNode 1 0 1 0 0
+0.00000 +0.00000 +0.00000 +1.00000 +0.00000 +0.00000 +0.00000 0 0 -1 0 Plane 1 0 1 0 0
-0.70711 +0.00000 +0.00000 +0.70711 +2.43048 -4.76820 -7.87057 0 0 0 0 2
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
73 5 1 0 +0.838 +0.612 +0.612 +1.000 +0.200 +0.200 +0.200 0 0 0 0 0 0 0 1
12 12 0
-------
319

fs_horse_stand_a_to_charge.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +2.200 1 0 0 0 0 1 0 102 102 102
170 1 2 CaozSceneCustomAttribNode 1 0 1 0 0
+0.00000 +0.00000 +0.00000 +1.00000 +0.00000 +0.00000 +0.00000 0 0 -1 0 Plane 1 0 1 0 0
-0.70711 +0.00000 +0.00000 +0.70711 +2.43048 -4.76820 -7.87057 0 0 0 0 2
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
73 5 1 0 +0.838 +0.612 +0.612 +1.000 +0.200 +0.200 +0.200 0 0 0 0 0 0 0 1
12 12 0
-------
319

fs_horse_stand_a_to_run.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +3.000 1 0 0 0 0 1 0 102 102 102
170 1 2 CaozSceneCustomAttribNode 1 0 1 0 0
+0.00000 +0.00000 +0.00000 +1.00000 +0.00000 +0.00000 +0.00000 0 0 -1 0 Plane 1 0 1 0 0
-0.70711 +0.00000 +0.00000 +0.70711 +2.43048 -4.76820 -7.87057 0 0 0 0 2
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
73 5 1 0 +0.838 +0.612 +0.612 +1.000 +0.200 +0.200 +0.200 0 0 0 0 0 0 0 1
12 12 0
-------
319

fs_horse_stand_a_to_walk.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +2.600 1 0 0 0 0 1 0 102 102 102
170 1 2 CaozSceneCustomAttribNode 1 0 1 0 0
+0.00000 +0.00000 +0.00000 +1.00000 +0.00000 +0.00000 +0.00000 0 0 -1 0 Plane 1 0 1 0 0
-0.70711 +0.00000 +0.00000 +0.70711 +2.43048 -4.76820 -7.87057 0 0 0 0 2
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
73 5 1 0 +0.838 +0.612 +0.612 +1.000 +0.200 +0.200 +0.200 0 0 0 0 0 0 0 1
12 12 0
-------
319

fs_horse_stand_a_turn_90_ccw_1.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +2.200 1 0 0 0 0 1 0 102 102 102
170 1 2 CaozSceneCustomAttribNode 1 0 1 0 0
+0.00000 +0.00000 +0.00000 +1.00000 +0.00000 +0.00000 +0.00000 0 0 -1 0 Plane 1 0 1 0 0
-0.70711 +0.00000 +0.00000 +0.70711 +2.43048 -4.76820 -7.87057 0 0 0 0 2
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
73 5 1 0 +0.838 +0.612 +0.612 +1.000 +0.200 +0.200 +0.200 0 0 0 0 0 0 0 1
12 12 0
-------
319

fs_horse_stand_a_turn_90_cw_1.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +2.200 1 0 0 0 0 1 0 102 102 102
170 1 2 CaozSceneCustomAttribNode 1 0 1 0 0
+0.00000 +0.00000 +0.00000 +1.00000 +0.00000 +0.00000 +0.00000 0 0 -1 0 Plane 1 0 1 0 0
-0.70711 +0.00000 +0.00000 +0.70711 +2.43048 -4.76820 -7.87057 0 0 0 0 2
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
73 5 1 0 +0.838 +0.612 +0.612 +1.000 +0.200 +0.200 +0.200 0 0 0 0 0 0 0 1
12 12 0
-------
319

fs_horse_walk.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +1.000 1 0 0 0 0 1 0 102 102 102
170 1 2 CaozSceneCustomAttribNode 1 0 1 0 0
+0.00000 +0.00000 +0.00000 +1.00000 +0.00000 +0.00000 +0.00000 0 0 -1 0 Plane 1 0 1 0 0
-0.70711 +0.00000 +0.00000 +0.70711 +2.43048 -4.76820 -7.87057 0 0 0 0 2
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
73 5 1 0 +0.838 +0.612 +0.612 +1.000 +0.200 +0.200 +0.200 0 0 0 0 0 0 0 1
12 12 0
-------
319

fs_horse_walk_to_run.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +1.800 1 0 0 0 0 1 0 102 102 102
170 1 2 CaozSceneCustomAttribNode 1 0 1 0 0
+0.00000 +0.00000 +0.00000 +1.00000 +0.00000 +0.00000 +0.00000 0 0 -1 0 Plane 1 0 1 0 0
-0.70711 +0.00000 +0.00000 +0.70711 +2.43048 -4.76820 -7.87057 0 0 0 0 2
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
73 5 1 0 +0.838 +0.612 +0.612 +1.000 +0.200 +0.200 +0.200 0 0 0 0 0 0 0 1
12 12 0
-------
319

fs_horse_walk_to_stand_a.cas TRUE TRUE TRUE IS in descr_skeleton.txt
+3.210 38 9 0 +1.600 1 0 0 0 0 1 0 102 102 102
170 1 2 CaozSceneCustomAttribNode 1 0 1 0 0
+0.00000 +0.00000 +0.00000 +1.00000 +0.00000 +0.00000 +0.00000 0 0 -1 0 Plane 1 0 1 0 0
-0.70711 +0.00000 +0.00000 +0.70711 +2.43048 -4.76820 -7.87057 0 0 0 0 2
16 2 0 0
16 3 0 0
16 8 0 0
16 10 0 0
73 5 1 0 +0.838 +0.612 +0.612 +1.000 +0.200 +0.200 +0.200 0 0 0 0 0 0 0 1
12 12 0
-------
319

Processed 38 in this directory...





Too much information for this type of posting. I've also done
siege_crew but maybe I should distill it down before posting more
stuff. Basically, I've automated to the point I can process everything,
run through descr_skeleton.txt and check if a file is referenced there,
and put out a summary like the above to give header and footer info
with the hope that these can be categorized. The short summary at
this point is:

(1) Regular .cas files: 0 0 0 102 102 102 headers, 192 byte footers.
Most files are this way.

(2) Horsies have long footers. Distinguished by the first int being 170.
Deal with it.

(3) Camels have short footers. Not all but many have the first int being 18.
Again, deal with it.

(3) Some anims have NO footers. Many of these have signature bytes to
tell you this; some don't.

(4) Some anims look normal but are lacking the last three ints or last twelve
bytes: 12 12 0. No signatures for these, some are not in the game, some are.

(5) Camels have signatures 0 0 0 10 10 10

And there's more, I think med_elephants are normal but have a different
signature structure, etc. Hopefully this will all be collated into a file format
spec at some point.

Will play with this a little more to finish it off, but frankly this is boring me
just as much as it is probably boring everyone else. Bring on more animation
experiments, those are cool!

Catch everyone tomorrow.~:)

[KnightErrant]

@zxiang1983
Got my program put back together to convert a single .cas file
to its text representation. The anims in new_2H_axe_halberd
have the jaw and eyebrow bones switched in position. The bone
section for a retail unit anim like MTW2_Spear_charge_attack.cas
looks like this:


Scene Root 0 0 0 10560 0 1 0
bone_pelvis 33 33 0 10560 0 1 0
bone_RThigh 33 33 528 10956 0 1 0
bone_Rlowerleg 33 33 1056 11352 0 1 0
bone_Rfoot 33 33 1584 11748 0 1 0
bone_abs 33 33 2112 12144 0 1 0
bone_torso 33 33 2640 12540 0 1 0
bone_head 33 33 3168 12936 0 1 0
bone_jaw 33 33 3696 13332 0 1 0
bone_eyebrow 33 33 4224 13728 0 1 0
bone_Rclavical 33 33 4752 14124 0 1 0
bone_Rupperarm 33 33 5280 14520 0 1 0
bone_Relbow 33 33 5808 14916 0 1 0
bone_Rhand 33 33 6336 15312 0 1 0
bone_Lclavical 33 33 6864 15708 0 1 0
bone_Lupperarm 33 33 7392 16104 0 1 0
bone_Lelbow 33 33 7920 16500 0 1 0
bone_Lhand 33 33 8448 16896 0 1 0
bone_LThigh 33 33 8976 17292 0 1 0
bone_Llowerleg 33 33 9504 17688 0 1 0
bone_Lfoot 33 33 10032 18084 0 1 0


while the 2H_axe_charge_attack.cas goes like this:


Scene Root 0 0 0 16960 0 1 0
bone_pelvis 53 53 0 16960 0 1 0
bone_RThigh 53 53 848 17596 0 1 0
bone_Rlowerleg 53 53 1696 18232 0 1 0
bone_Rfoot 53 53 2544 18868 0 1 0
bone_abs 53 53 3392 19504 0 1 0
bone_torso 53 53 4240 20140 0 1 0
bone_head 53 53 5088 20776 0 1 0
bone_eyebrow 53 53 5936 21412 0 1 0
bone_jaw 53 53 6784 22048 0 1 0
bone_Rclavical 53 53 7632 22684 0 1 0
bone_Rupperarm 53 53 8480 23320 0 1 0
bone_Relbow 53 53 9328 23956 0 1 0
bone_Rhand 53 53 10176 24592 0 1 0
bone_Lclavical 53 53 11024 25228 0 1 0
bone_Lupperarm 53 53 11872 25864 0 1 0
bone_Lelbow 53 53 12720 26500 0 1 0
bone_Lhand 53 53 13568 27136 0 1 0
bone_LThigh 53 53 14416 27772 0 1 0
bone_Llowerleg 53 53 15264 28408 0 1 0
bone_Lfoot 53 53 16112 29044 0 1 0

It's easy to cut and paste the jaw part and move it in front of the
eyebrow bone. The hierarchy doesn't have to change because they're
both children of the head. This looks like all you have to change to
get them to look ok.

I posted an edited version of 2h_axe_charge.cas here:

http://www.twcenter.net/forums/downloads.php?do=file&id=1420

Give it a try and see if the faces are ok when charging (not attacking).

Edit: Never mind, post in haste, regret in leisure. The problem seems to be bad data
now that I've looked more carefully. Here's the pose frames for a retail unit for
bone_jaw then bone_eyebrow

+0.0003562549 +0.0108105317 -0.0034470237
+0.0016836975 +0.1178485230 -0.0744605586

Pose frames for 2h_axe_charge for reversed bone_eyebrow then bone_jaw

-0.0015659166 +0.1178485230 -0.0744630992
+0.0002055481 +0.0108106285 -0.0034593095

The red number for the x-component of bone_eyebrow looks opposite compared
to the other set.

[KnightErrant]

@zxiang1983
Didn't mean to leave you hanging.
I've looked at the pose skeleton for
2H_Swordsman which is the parent animation
for Janissary_heavy_infantry and the skeleton
pose data definitely seems to be the problem for
using these animations. Here's a solution in two parts:

(1) I'll edit the files using a hexeditor and change the pose
data on the two bones to what is used for the MTW2_2H_Swordsman
anim. This is charge, charge_to_ready, and charge_attack.
If these look ok, then problem is understood.

(2) I can reexport a new skeleton to all the anims in
new_2H_Axe_halberd so you can use any of them with the
new skeleton pose data. (If this function stll works, I've been
messing with everything to do the survey stuff.)

I'm at the end of my day here so I don't want to hexedit floats
right now.:dizzy2: Let me try this tomorrow and post updated anim
files for these three anims. If this is ok we try the next step.

[zxiang1983]

Hi, KE!
Thank you! You are so warmhearted. Just take your time:)

and BTW, I've already done what GOM said, assigned the face vertexes all to head bone and now the problem is "solved". I can use them until you guys find a more perfect way.:)



I've also imported the idle, stand, walk, run, ready, run to charge animation(all animation except attack and defence) for janissary heavy infantry. All works fine. Just pay attention that 2h_axe_walk.cas and 2h_axe_run.cas are broken. Use 2HAxe_Run.cas and 2HAxe_walk.cas instead.

The latest report on my front is that the new charge animation is good-looking but effectiveless. They kill very little enemy during this charge.

[KnightErrant]

Hi zxiang1983,

Try these two files in the .zip file here:

https://forums.totalwar.org/vb/forumdisplay.php?f=150

I just did the 2h_axe_charge.cas and 2h_axe_charge_attack.cas files.
Should be enough for a test.

All I changed was the x-component of the bone_eyebrow from the negative
value back to the value in the standard skeleton, 0.0016836975. If this
does the trick it will take a little more work to export it to all the animations
in the directory. The problem is that with the bones out of standard order,
the data is also out of order compared to a Milkshape .ms3d file so I can't
just blindly merge the two. I'll need to write a resorting function to reorder the
.cas quats, anim, and pose data to line up with what Milkshape will be
expecting. I think I'll leave the animextractor alone since this means a
converted animation, one that animmerge and then animextract are run on,
will then turn out to be in standard order after processing.

Too bad about the animation not being very effective. It looks cool! I wonder
if messing about with the -fr frame option and -id impact delta option could
tweak this better somehow. Pure speculation, I've never tried doing anything
with those options.

Thank you for the testing, best way to find out what tools are needed!~:)

[zxiang1983]

Hi, KE!

The link is probably wrong but never mind I've found it on TWC, lol. It's bonechange.zip, right?

I put your files in new_2h_axe_halberd folder and edited descr_skeleton.txt, using 2h_axe_charge_attack_bonechange.cas and 2h_axe_charge_bonechange.cas. Then let them reproduce the idx/dat files.

Unfortunately, in my test their faces are still twisted. Actually I see no difference with before... :P

https://img129.imageshack.us/img129/9049/0093nz7.jpg (https://imageshack.us)

Hope this helps.

Oh, and BTW, their walk_to_run, run_to_charge animation, etc have exactly the same problem. But, 2HAxe_Run.cas and 2HAxe_walk.cas are fine! Maybe you could look into these two files and compare them with others.

[KnightErrant]

Well, I had hoped that would solve the problem.
But, no matter, this is getting interesting. I'll
take your advice and look at the good files versus
the bad files and see if that narrows down the problem.

Many thanks for running the tests. Have a good weekend.
I'll report back if I find anything interesting to try. ~:wave:

[zxiang1983]

You are welcome!

After all testing is not so hard as researching :laugh4:

[Bwian]

Aaarrrghhhh .... was what I said when I spotted this.

I have made a brand new model for the Dwarf, but am using the same skeleton as the previous one. I rigged it..and put it in game..but noticed I had an issue with levitation again.... but not the same as before.

The body is in the right place, and the bulk of th eDwarf is fine...just the feet are wrong. They have been dragged upwards and compressed into the bottom of the legs. It looks like everything else is OK...just the feet aren't.

I put the old model back in...and it did the same thing. I am sure it didn't do this before.... but I am worried it might have and I just missed it.

When, however, I run Animerge, and play the animation in MS3D, the feet are perfectly planted. When we had the problem with an incorrect centre before, the Animerge result was clearly not in the right place...but you were able to fix that. Any thoughts as to what might be causing this?

I am going to remove all the extra anims and re-run the process in case something is messed up. I'll post back if this cures it.

EDIT: Nope ... it doesn't cure it. I am wondering if this is an error that came in with a later version of hte tool?

[KnightErrant]

@Bwian
I've been updating the tool but I haven't sent out anything new since we
fixed the problem a couple of weeks ago. I had left out the scaling but when
that was actually put in you got the old dwarves to hit the y=0 plane
with the scaling values I used. So this must be something new.

Meshes only have bone name strings in them which is how they are
animated but they don't have any other skeleton information such
as pose data so the problem would seem to be with the animations,
except, the animations work in Milkshape!

I haven't done anything to my dwarves since we got this working
so (1) I'll check the in-game feet very carefully just to make sure I'm
not seeing this as well and just missed it a while back. If I don't
see it then the only thing I can think to do is check the dwarf .ms3d
file against the one I've got and to check the walk .cas files against
the one I've got to see if anything is different that could account for this.

Edit: Well, shoot! I think I see it too in my old dwarves stuff. I'll post
a pic but it's really easier to see as they move that they float a bit and the feet
seem "crumpled" if that's the right word.

https://img393.imageshack.us/img393/6803/curleddwarvesut5.th.jpg (https://img393.imageshack.us/my.php?image=curleddwarvesut5.jpg)

No inspiration is striking at the moment; I'll compare the skeleton I exported
to what is in .ms3d file but since Milkshape animations look ok I can't see how
that could be it.

[KnightErrant]

@Bwian
Ok, inspiration IS striking. Just checked some dates on an e-mail
from GrumpyOldMan. 5-22-2007 he says we need to check rotations.
I find a problem with my quats to euler and euler to quats conversions.
I update my utility and voila! the feudal knight slashing animation is ok
now. Problem is, the dwarf animation .cas files I have are dated 5-21-2007
so I never applied the updated transformations to any of the cas files.

Your copy of my utility must also be outdated. This shouldn't make a difference
for small angles but maybe it is affecting the foot bone and lower leg for
animations. I've been updating my stuff all along to deal with the new
header/footers in Caliban's directory so I don't know how to backtrack
on this. Could you check the creation date on your copy of
animationlibrary.py and see if it is about 5-21-2007? Might help to narrow
down the culprit here. We can compare the algorithm in the function
computeeulers to be sure. Hope this might be it.:oops: Would make life
easier except I've got animmerge torn apart at the moment trying to
deal with the animations in new_2h_axe_halberd which have bones out
of order.

[Bwian]

The squashed feet thing is exactly what I am seeing. It is as if the lower bones have been compressed upwards. The bones are to blame...
To test, I assigned ALL the feet bones to lower leg. This let the feet show correctly, but the knee joint was wrong. It also allowed the feet to touch the ground. This confirms that the Y scaling is hitting the target OK. Assign all the verts to 'Thigh' bones, and the legs appear OK...but he walks like a scarecrow :inquisitive:

The file has a date on it of 24/5/07 as last modified, so I am guessing this is when you mailed it over.


# -----------------------------------------------------------------------------------
# Computes Euler angles from quaternions. |
# -----------------------------------------------------------------------------------
def computeeulers( quatfloats ) :

nfloats = len( quatfloats )
nvecs = nfloats / 4
eulers = array.array( 'f' )

for ivec in range( nvecs ) :
idx = ivec * 4
q1 = quatfloats[idx+0]
q2 = quatfloats[idx+1]
q3 = quatfloats[idx+2]
q4 = quatfloats[idx+3]

Q11 = 1 - 2 * ( q2*q2 + q3*q3 )
Q12 = 2 * ( q1*q2 - q3*q4 )
Q13 = 2 * ( q1*q3 + q2*q4 )
Q21 = 2 * ( q1*q2 + q3*q4 )
Q22 = 1 - 2 * ( q1*q1 + q3*q3 )
Q23 = 2 * ( q2*q3 - q1*q4 )
Q31 = 2 * ( q1*q3 - q2*q4 )
Q32 = 2 * ( q2*q3 + q1*q4 )
Q33 = 1 - 2 * ( q1*q1 + q2*q2 )

# # 231 method.
# spsi = Q21
# cpsi = ( 1 - spsi*spsi )**0.5
# stheta = -Q31 / cpsi
# ctheta = +Q11 / cpsi
# sphi = -Q23 / cpsi
# cphi = +Q22 / cpsi
#
# phi_rad = math.atan2( sphi, cphi )
# theta_rad = math.atan2( stheta, ctheta )
# psi_rad = math.atan2( spsi, cpsi )
#
# # Try.
# eulers.append( phi_rad )
# eulers.append( -theta_rad )
# eulers.append( -psi_rad )
#
# # Hey! this way works!

# GrumpyOldMan's code.
sint = 2 * ( q2 * q4 - q1 * q3 )
cost_tmp = 1.0 - sint*sint
if abs( cost_tmp ) > 0.0001 :
cost = cost_tmp**0.5
else :
cost = 0.0

if abs( cost ) > 0.01 :
sinv = 2 * ( q2 * q3 + q1 * q4 ) / cost
cosv = ( 1 - 2 * ( q1*q1 + q2*q2 ) ) / cost
sinf = 2 * ( q1 * q2 + q3 * q4 ) / cost
cosf = ( 1 - 2 * ( q2*q2 + q3*q3 ) ) / cost
else:
sinv = 2 * ( q1 * q4 - q2 * q3 )
cosv = 1 - 2 * ( q1*q1 + q3*q3 )
sinf = 0.0
cosf = 1.0

roll = math.atan2( sinv, cosv )
pitch = math.atan2( sint, cost )
yaw = math.atan2( sinf, cosf )

eulers.append( roll )
eulers.append(-pitch )
eulers.append(-yaw )

return eulers


# -----------------------------------------------------------------------------------
# Computes quaternions from Milkshape's x, y, z Euler angles. |
# -----------------------------------------------------------------------------------
def computequats( eulers ) :

nfloats = len( eulers )
nvecs = nfloats / 3
quatfloats = array.array( 'f' )

for ivec in range( nvecs ) :
idx = ivec * 3
phi_rad = +eulers[idx+0] # NOTE: These are the signs that worked in animmerge.py
theta_rad = -eulers[idx+1]
psi_rad = -eulers[idx+2]

sphi = math.sin( phi_rad )
cphi = math.cos( phi_rad )
stheta = math.sin( theta_rad )
ctheta = math.cos( theta_rad )
spsi = math.sin( psi_rad )
cpsi = math.cos( psi_rad )

# # 231 method (or 132 if you follow that naming convention).
# R11 = ctheta * cpsi
# R12 = -ctheta * spsi * cphi + stheta * sphi
# R13 = ctheta * spsi * sphi + stheta * cphi
# R21 = spsi
# R22 = cpsi * cphi
# R23 = -cpsi * sphi
# R31 = -stheta * cpsi
# R32 = stheta * spsi * cphi + ctheta * sphi
# R33 = -stheta * spsi * sphi + ctheta * cphi

# 321 method (or 123 if you follow that naming convention).
R11 = cpsi * ctheta
R12 = cpsi * stheta * sphi - spsi * cphi
R13 = cpsi * stheta * cphi + spsi * sphi
R21 = spsi * ctheta
R22 = spsi * stheta * sphi + cpsi * cphi
R23 = spsi * stheta * cphi - cpsi * sphi
R31 = -stheta
R32 = ctheta * sphi
R33 = ctheta * cphi

q4 = 0.5 * ( 1 + R11 + R22 + R33 )**0.5
q1 = 0.25 * ( R32 - R23 ) / q4
q2 = 0.25 * ( R13 - R31 ) / q4
q3 = 0.25 * ( R21 - R12 ) / q4

quatfloats.append( q1 )
quatfloats.append( q2 )
quatfloats.append( q3 )
quatfloats.append( q4 )

return quatfloats

I am guessing this is the bit you wanted from the code :sweatdrop:

The animation library has a created date of 16th May in the header...but I guess if youare like me with this sort of thing, that's not necessarily when you last changed it! The e-mail you sent me confirmed that this was the version you did AFTER you had changed the calcs for the extreme rotations to GOM's version. The version you sent me on the 22nd had the scaling function added.

As a last test, I will remove all the tools and bits and pieces, and make 100% I have only the correct versions in place, and double check. At each stage, I will run a test on the model to see if the legs are correct. This should help to pin down if it's an error that was always there, or something that crept in when a feature was added. I will PM you later on when I have some more data for you to work with :2thumbsup:

[Bwian]

Update:

Ran the original version of the files you sent over, and the crunched legs are there from the outset. In order to test it, I put my modified mesh in with all the leg verts assigned to the thigh bones. This showed that, as expected, the feet did not reach the ground.

I ran version 2, which had the added 'input' function to re-scale the root position. This did put the feet on the ground. The crunched legs are still present when the correct model is put back in again.

Ran version 3. Exactly the same effect as version 2. The legs are crunched, but the location of the mesh is still spot on confirmed by the modified model with all verts on the thigh bones. I figured this was the best way to confirm exactly where to look.

Conclusion:

The length of the leg bones is being incorrectly read by the game engine. The upper part of the unit is fine, and behaves as expected ..so it must be something that is unique to the lower half.

The root position of the model is fine. This is confirmed by making the legs 'rigid' and seeing that they hit the ground just right.

When the feet are also assigned to the lower leg, the knee joint is compressed and out of position. This confirms that it is not just the feet ... the pivot points on the lower half are being incorrectly scaled. The knee pivot had moved up ...but did not appear to be as far removed from correct as the feet. This would imply that the error is compunded as each set of calcs is done. I assume all the calculations start at the root, and are worked out from there....so a 10% error in the calculations would move the knee up 10% and the feet would be 20% ...if you see what I mean.

Hope this helps

[Csatadi]

Horse archers have their quivers on their back in vanilla. It can replaced to the right place to the belt right side. Ok.
But is it also possible with animations bringing out arrows from there?

[GrumpyOldMan]

Hi KE and Bwian


@Bwian
Ok, inspiration IS striking. Just checked some dates on an e-mail
from GrumpyOldMan. 5-22-2007 he says we need to check rotations.
I find a problem with my quats to euler and euler to quats conversions.
I update my utility and voila! the feudal knight slashing animation is ok
now. Problem is, the dwarf animation .cas files I have are dated 5-21-2007
so I never applied the updated transformations to any of the cas files.

Your copy of my utility must also be outdated. This shouldn't make a difference
for small angles but maybe it is affecting the foot bone and lower leg for
animations. I've been updating my stuff all along to deal with the new
header/footers in Caliban's directory so I don't know how to backtrack
on this. Could you check the creation date on your copy of
animationlibrary.py and see if it is about 5-21-2007? Might help to narrow
down the culprit here. We can compare the algorithm in the function
computeeulers to be sure. Hope this might be it.:oops: Would make life
easier except I've got animmerge torn apart at the moment trying to
deal with the animations in new_2h_axe_halberd which have bones out
of order.

If you'd like a fresh (relatively speaking :beam: ) set of eyes to look over the anims, you could send me the basepose and one of the affected anims and I can run my multifocals over them.

With the new_2h_axe_halberd anim would you like me to extract it and do a cut and paste to get the anim working correctly? It's probably easier to do in milkshape ascii rather than try to get your converter working with a few rogue anims.

Just while I've got your attention, I've been chewing on the end of my pencil to get an overall view of how the template system will work. Basically I was going to set up the converter to extract and write templates from Milkshape files. How I was going to deal with those templates probably requires some user input. Converting from mesh to ms3d is fairly straightforward, after you select a mesh to convert you're then asked what template you'd like to apply. How we deal with the other conversions/mergers requires some thought though. One of my original ideas was to record the template as a fifth line in the model comments so that after the initial conversion everything was then automatic. I've had second thoughts now (but not after doing some extensive recoding - curses) and my inclination now is that the user specifies at merger or conversion to mesh what template they'd like to apply. This is a more flexible system because you won't be stuck with what was recorded at the initial conversion. Any input guys?

Cheers

GrumpyOldMan

[GrumpyOldMan]

Hi Csatadi


Horse archers have their quivers on their back in vanilla. It can replaced to the right place to the belt right side. Ok.
But is it also possible with animations bringing out arrows from there?

With KE's utilities you will be able to change the loading anims so that they get their arrows from the hip quiver but there will be one problem. The horse archers have an ability to turn toward their targets independent of the horse. This means that the bones of the upper body are turned but the lower body is stationary (compared to the horse). The right arm is part of the upper body and the hip quiver is assigned to the lower body. This means that with the new anims, unless the target is straight ahead, the hand will either be dipping into space before or behind the quiver. If you can live with this, then yes you can move the quiver and change the anims. I suspect that this is why they placed the quivers on the figures' backs in the first place. You could try attaching the quiver to an upper body bone but I'm not sure what the resultant rotation would look like, and it may have strange side effects with other animations.

Cheers

GrumpyOldMan

[KnightErrant]

@GrumpyOldMan
I'd love another pair of eyes on this one. I'll e-mail the
basepose and walk anim from my game directory tonight.

@Bwian
Thanks, that was a very detailed examination of the problem.
I've converted the stock walk anim and the converted anim
to text and here's the bone_pelvis anim blocks side by side:



0 bone_pelvis animation data and deltas 0 bone_pelvis animation data and deltas
+0.0000122126 +0.9590483308 -0.0000000000 +0.0000084836 +0.6137909293 -0.0000000000
+0.0017991858 +0.9512157440 +0.0901285559 +0.0012498223 +0.6087780595 +0.0626087040
+0.0026300352 +0.9396055937 +0.1802604198 +0.0018269803 +0.6013475657 +0.1252197027
+0.0000594494 +0.9203369617 +0.2704085112 +0.0000412971 +0.5890156627 +0.1878419816
-0.0063111591 +0.9033862948 +0.3605716527 -0.0043841098 +0.5781672001 +0.2504746914
-0.0137326801 +0.9005295038 +0.4507446289 -0.0095395437 +0.5763388872 +0.3131142557
-0.0189423133 +0.9042277336 +0.5409182310 -0.0131584676 +0.5787057281 +0.3757542670
-0.0211101491 +0.9193583131 +0.6310883760 -0.0146643762 +0.5883893371 +0.4383918643
-0.0210416745 +0.9396334291 +0.7212522626 -0.0146168098 +0.6013653874 +0.5010250807
-0.0201377589 +0.9517263174 +0.8114059567 -0.0139888953 +0.6091048717 +0.5636512637
-0.0226440672 +0.9510992169 +0.9015470743 -0.0157299284 +0.6087034941 +0.6262686849
-0.0249393098 +0.9356126189 +0.9916793704 -0.0173243415 +0.5987920761 +0.6888799667
-0.0272242893 +0.9162625670 +1.0818185806 -0.0189116243 +0.5864080191 +0.7514960766
-0.0254939552 +0.8969492912 +1.1719760895 -0.0177096315 +0.5740475655 +0.8141248822
-0.0179745089 +0.8883986473 +1.2621510029 -0.0124861719 +0.5685751438 +0.8767657876
-0.0077288523 +0.8950952291 +1.3523342609 -0.0053689247 +0.5728609562 +0.9394125342
-0.0011719284 +0.9107339382 +1.4425106049 -0.0008140918 +0.5828697085 +1.0020544529
+0.0010084946 +0.9343801737 +1.5326695442 +0.0007005609 +0.5980033278 +1.0646842718
+0.0000120707 +0.9590483308 +1.6228270531 +0.0000083850 +0.6137909293 +1.1273130178

and the stock and new skeleton pose block side by side:


0 skeleton pose data, all bones including Scene_Root 0 skeleton pose data, all bones including Scene_Root
+0.0000000000 +0.0000000000 +0.0000000000 +0.0000000000 +0.0000000000 +0.0000000000
+0.0000000000 +0.0000000000 +0.0000000000 +0.0000000000 +0.0000000000 +0.0000000000
+0.0952388048 +0.0007522844 -0.0000000837 +0.0952389985 +0.0007520000 +0.0000000000
+0.0225614067 -0.4644486308 +0.0143960081 +0.0225610007 -0.3418302238 +0.0143959997
+0.0241625141 -0.3995063901 -0.0316344053 +0.0241630003 -0.2538871169 -0.0316339992
-0.0000000065 +0.2124619335 +0.0000000110 +0.0000000000 +0.2124619931 +0.0000000000
-0.0002945312 +0.2115576267 +0.0000000300 -0.0002950000 +0.2115579993 +0.0000000000
-0.0000617070 +0.2349729538 +0.0000000693 -0.0000620000 +0.2349729985 +0.0000000000
+0.0003562541 +0.0108104832 -0.0034470418 +0.0003560000 +0.0108099999 -0.0034469999
+0.0016836945 +0.1178485677 -0.0744605809 +0.0016840000 +0.1178480014 -0.0744609982
+0.0132546537 +0.1300112009 -0.0273842514 +0.0132550001 +0.1300110072 -0.0273839999
+0.1653587520 -0.0517836586 +0.0034831662 +0.1762007326 -0.0517840013 +0.0034830000
+0.3022065163 +0.0111386608 -0.0137688387 +0.3022060096 +0.0111389998 -0.0137689998
+0.2838369310 -0.0030556275 +0.0263377447 +0.2853106558 -0.0030560000 +0.0263379999
-0.0102220690 +0.1300112009 -0.0273842178 -0.0102220001 +0.1300110072 -0.0273839999
-0.1678021550 -0.0517837554 +0.0034834931 -0.1762007326 -0.0517840013 +0.0034830000
-0.3021733165 +0.0111956345 -0.0144309197 -0.3021729887 +0.0111950003 -0.0144309998
-0.2838011682 -0.0031999985 +0.0267028809 -0.2853106558 -0.0031999999 +0.0267040003
-0.0952387750 +0.0007523637 +0.0000000981 -0.0952389985 +0.0007520000 +0.0000000000
-0.0216095932 -0.4641435742 +0.0230794586 -0.0216090009 -0.3414067626 +0.0230780002
-0.0250772368 -0.3986372054 -0.0406128988 -0.0250770003 -0.2543957829 -0.0406120010

And that's all we're trying to do. Shorten the legs and scale the anims
to match. From your experiments the game is doing something very odd
with the new leg data and frankly I'm stumped as to what it is.:embarassed:

I've checked the quat data and of course it's exactly the same so nothing
going on there.

[Bwian]

The pelvis location is spot on, and from the experiments I have done, is spot on. The problem seems to be the relative calculation of the child bones on the lower half of the model. It is almost as if the scaling effect has been applied to the relative translation of the bones in game....but not when animerge creates a file for Milkshape.

The overall effect has been there since the start though...so it is not related to the position of hte model in terms of pelvic location. This was wrong to start with, and was fixed by putting in an extra scale factor.

I think whatever the problem is, it must be in something that is bone specific....or else is a + or - thing. The bones in a positive translation from the pelvis ( or UP as I like to call it ) are fine, and show no evidence of issues. If they were wrong, then distortion of the joints at head, torso and abs would be evident. They aren't. Where the trouble starts is when we go DOWN from the pelvis.

If th epelvis is a 'zero' point for working out the bone locations before the rotational values are applied. This...I guess...is the basepose. Thats how it looks to me anyway! The actual rotatons seem to be fine, and the walking movement is definitely walking.

What also makes me think this is hte fact that the MS3D animerge output works fine. This would take it's basepose position from the MS3D containing the model I had used to build the 'skeleton' that was applied to the anims. An untouched version of this. If the calculation of the basepose that was put into the animation exporter was flawed, then it could put an error into the animations....but animerge would use the MS3D model unconverted. One less step. The rotations are then applied in MS3D from correct start points. In game, though, the startpoints are wrong, and when the correct rotations are applied, the movement is right....but the look is worng.

Of course...this is just mental gymnastics from someone who knows nothing of what he is talking about.... but I am pretty sure what I am seeing, and I just get that 'feeling' that says this might be an explanation for what I have seen. ~Might not help ... but I feel I am at least contriuting!

[KnightErrant]

Following is just speculation on my part too. I did the scaling based
on putting the feet on y=0 in Milkshape but that was just
a predjudice on my part. Did I force the dwarf too low
and some other mechanism of the game won't let feet go
below ground level and that is causing the distortion, like
it's "reflecting" the lower limbs upward. Consistent with it
only affecting the linked bones below the pelvis but it may
not square with your experiments of tying all the vertices
to the thigh bone. Can't do any tests until I get home to run
a battle with a different scaling exported to the animations,
like 0.8 which isn't small enough so they should float, but are
the legs normal otherwise? Then work downwards towards 0.61
to see when the effect occurs.

[Bwian]

The vertex thing just confirmed that the pelvis was in the correct place for the scaling. The bones may be affected...but the mesh is just 'hung' on the bones.

[Csatadi]

GrumpyOldMan:
Thanks! I'm not familiar with modelling and animations so I cannot test it. I was only curios what is possible.

[KnightErrant]

To all,
I've just been trying to fudge things by messing with the skeleton
I export, longer thigh bones etc. then the scaling. I can get it to
look ok, a little bit of floating, but then when the dwarves taunt the
foe the feet distort a bit. Also they seem to "scoot" a bit when walking
etc. so this is no solution. Here's a pic of something not too bad.

https://img230.imageshack.us/img230/773/dwarfexperimentkq2.th.jpg (https://img230.imageshack.us/my.php?image=dwarfexperimentkq2.jpg)

So no closer to a resolution on this one. I'll send out my latest utilities
but don't delete the old ones. The new ones will do:
animmerge - tries to handle zxiang1983's new_2H_axe_halberd but not
finished yet.
animextract - probably ok
convert cas to txt - been using this a lot
exportskeleton - used all the time to change scalings and skeletons
extractskeleton - haven't used for a while but probably ok.
convertcasdirectory - used to do the surveys. Writes a summary of a moused
to directory. Uses check boxes to decide what data to
include.

animmerge now has a dialog to choose the FPS desired. 2 seems to be good
for really looking at anims. 20 is game speed but this is too fast for me.

If anybody else wants to experiment please PM an e-mail and I'll send out
the utilities and a brief description of what we're working on. If Bwian
has no objections, you can have the dwarf .ms3d file to use for experimenting
with exporting skeletons and scalings.

[KnightErrant]

Hi all,

GrumpyOldMan found the problem! Bwian check your copy
of descr_skeleton.txt. Look for the basepose.cas file entry
in the MTW2_Dwarf_2H_Axe. If you copied my stuff it's pointing
to the wrong directory. Make sure it's pointing to the Dwarf
directory's copy of the basepose file then everything works out
fine. This is exactly what you were saying, the skeleton isn't
right. Mind you, GOM never saw a copy of my descr_skeleton.txt
file and HE STILL CAUGHT THIS!!! After this is working we must
conquer a Kingdom so he can rule it. Agreed?:laugh4:

KE

[Bwian]

ah.... that would be this bit :


type MTW2_Dwarf_2H_Axe
strike_distances 1.15 1.8 2.8 3.5 4.0
locomotion_table soldier
anim default data/animations/MTW2_2H_Axe/MTW2_2H_Axe_basepose.cas

I have changed this line to data/animations/MTW2_Dwarf_2H_Axe, which should now pick up the basepose that the animation tools had edited :beam:

I run a baseline test with the old animations ( well alright....I forgot to delete them!) and I confirm that I have the correct Dwarf model in with the vertices in the right places and correctly assigned, not my 'modded' one.

Then, I delete the animation packs, and rerun. I correct my typo ( What is a Dawrf anyway .... ) and IT WORKS!

Choose your kingdom, and I'll start planning the take over :D

Three cheers for King GrumpyOldMan, and Imperial Wizard KnightErrant! This is the greatest bit of TW modding yet to happen....the Holy Grail that eluded us in RTW, and the thing that will make Warhammer TotalWar a thing of utter beauty!

Gentlemen .... I salute you :2thumbsup:

[KnightErrant]

Excellent!:smash: It works, it works, it really, really works!:balloon2:

If you get a chance, see if the new stuff works on the directories
where the other one bombed. The utilities should be able to handle
more of the weird cas formats.

I'm going to look at zxiang1983's problem with the anims in
new_2h_axe_halberd which have the jaw and eyebrow bones switched.
After that, maybe units with extra bones?

[KnightErrant]

@zxiang1983,

Trying to recreate your animation results. I've modified my
descr_skeletons.txt to look like this:



anim charge data/animations/new_2h_axe_halberd/2h_axe_charge.cas -fr -evt:data/animations/MTW2_Halberd/MTW2_Halberd_charge.evt
anim charge_to_ready data/animations/new_2h_axe_halberd/2h_axe_charge_to_ready.cas -fr -evt:data/animations/MTW2_Halberd/MTW2_Halberd_charge_to_ready.evt
anim charge_attack data/animations/new_2h_axe_halberd/2h_axe_charge_attack.cas -fr -if:17 -evt:data/animations/MTW2_Halberd/MTW2_Halberd_charge_attack.evt


to bring in the new_2h_axe_halberd anims that had the face messed
up but I'm not seeing it. Right now I can't convince ImageShack that I've
really upladed an image. Did I miss anything in trying to get the anims in
game?

[GrumpyOldMan]

Hi KE


@zxiang1983,

Trying to recreate your animation results. I've modified my
descr_skeletons.txt to look like this:



anim charge data/animations/new_2h_axe_halberd/2h_axe_charge.cas -fr -evt:data/animations/MTW2_Halberd/MTW2_Halberd_charge.evt
anim charge_to_ready data/animations/new_2h_axe_halberd/2h_axe_charge_to_ready.cas -fr -evt:data/animations/MTW2_Halberd/MTW2_Halberd_charge_to_ready.evt
anim charge_attack data/animations/new_2h_axe_halberd/2h_axe_charge_attack.cas -fr -if:17 -evt:data/animations/MTW2_Halberd/MTW2_Halberd_charge_attack.evt


to bring in the new_2h_axe_halberd anims that had the face messed
up but I'm not seeing it. Right now I can't convince ImageShack that I've
really upladed an image. Did I miss anything in trying to get the anims in
game?

Did you refresh the dat and idx files?

On another note there is another file that could be relevant and that is descr_ik_controller_db.txt file in the data folder. This controls the IK parameters for soldiers. If you're doing any scaling or complete new skeletons you'd have to have an entry here to control the IK - especially if it's based on the 2h_sword. This also shows that there are significant bones required when building a new skeleton from scratch - you have to retain the pelvis - abs - torso - head hierarchy. Also from a weapon wielding point of view you must have the bone_Rhand and bone_Lhand included because that is where the weapon skeletons are attached.

Cheers

GrumpyOldMan

[zxiang1983]

Hi, KE. I'm not sure what's wrong. Here's what I did.

I copied the whole MTW2_Halberd_Secondary anim type and pasted it at the end of descr_skeleton.txt. Then renamed the anim type to MTW2_Halberd_Secondary_zxiang. And then replace those charge related anim with the new ones. I didn't touch descr_ik_controller_db.txt.

Then I deleted pack.dat/idx and skeleton.dat/idx and put in CA source anim. Then run the game. It will generate new pack.dat/idx and skeleton.dat/idx files.

Then let janissary heavy infantry use MTW2_Halberd_Secondary_zxiang as his anim in battle_models.modeldb.

That's all. hope it helps.

[KnightErrant]

Thanks GrumpyOldMan and zxiang1983,

I checked the time stamps just to be sure because its
easy to forget to delete the packs. Seems right but going to try it again.
What is different is I am modifying the animation family
directly, not making a new one. I'll retest what I'm doing
just to be sure and if I don't see the distortion I'll do it
zxiang1983's way and make a new family.

Oops, wait a minute. Re-read the post more carefully. zxiang1983
says he copied MTW2_Halberd_Secondary which doesn't have
a charge entry or a charge_attack or a charge_to_ready anim
command. It inherits? (sorry, OOP terminology) its parent anim
is the MTW2_2HSwordsman so is he overriding those commands?

Still, useful information, I'll try it my way. Then the other way.
If I see a problem maybe its an interplay between MTW2_2HSwordsman.

[KnightErrant]

Well, that was dumb of me. :embarassed:
Check the battle_models.modeldb file to find out
the animations to use. Ok, sorry, now I'm on the same
page here. Making a new MTW2_Halberd_Seondary_sandy anim
family to do this right.

Edit: Got the distortion on the face now. Thanks for the
help in recreating this.

[KnightErrant]

Already tried this above but here's the basepose for
MTW2_2HSwordsman which the secondary anim should inherit:


0 skeleton pose data, all bones including Scene_Root
+0.0000000000 +0.0000000000 +0.0000000000
+0.0000000000 +0.0000000000 +0.0000000000
+0.0952388123 +0.0007522844 -0.0000000077
+0.0225613099 -0.4644488394 +0.0143959811
+0.0241626594 -0.3995065689 -0.0316339098
-0.0000000069 +0.2124620080 +0.0000000008
-0.0002945330 +0.2115577459 +0.0000000299
-0.0000617082 +0.2349730581 +0.0000000668
+0.0003562513 +0.0108101442 -0.0034470249
+0.0016836975 +0.1178482324 -0.0744606256
+0.0132546443 +0.1300113499 -0.0273839179
+0.1653589010 -0.0517836586 +0.0034832843
+0.3022063971 +0.0111386608 -0.0137691963
+0.2838369906 -0.0030556759 +0.0263375118
-0.0102220895 +0.1300113499 -0.0273839179
-0.1678023189 -0.0517838039 +0.0034833583
-0.3021733165 +0.0111954408 -0.0144314421
-0.2838012278 -0.0032004344 +0.0267044473
-0.0952387825 +0.0007523637 +0.0000000220
-0.0216093510 -0.4641437531 +0.0230784994
-0.0250775032 -0.3986376822 -0.0406115167

and here's the pose data from the charge anim from new_2h_axe_halberd:



0 skeleton pose data, all bones including Scene_Root
+0.0000000000 +0.0000000000 +0.0000000000
-0.0000000000 +0.0000000969 -0.0000000000
+0.0952388048 +0.0007522567 -0.0000001105
+0.0225616489 -0.4644486904 +0.0143948821
+0.0241624303 -0.3995064199 -0.0316330455
-0.0000000002 +0.2124619335 +0.0000000074
-0.0002945446 +0.2115576714 +0.0000000356
-0.0000617125 +0.2349729091 +0.0000000648
-0.0015659207 +0.1178484261 -0.0744630992
+0.0002055460 +0.0108106285 -0.0034593104
+0.0132546341 +0.1300111562 -0.0273842439
+0.1653588265 -0.0517836101 +0.0034830223
+0.3022063673 +0.0111382734 -0.0137693156
+0.2838367820 -0.0030559180 +0.0263374485
-0.0102220811 +0.1300111562 -0.0273842085
-0.1678022444 -0.0517838039 +0.0034836400
-0.3021732569 +0.0111951502 -0.0144293746
-0.2838010490 -0.0031997561 +0.0267024450
-0.0952387676 +0.0007523138 +0.0000001374
-0.0216093212 -0.4641436040 +0.0230773669
-0.0250774790 -0.3986373842 -0.0406104438


The red lines are switched but that's ok, I think, because
the bone names are switched and GOM has established that
anims are done by the bone strings. So is this another
basepose conflict? :dizzy2: Will try changing the pose data for
bone_jaw and bone_eyebrow to EXACTLY match the basepose
bones as a first try.

(I know: to a man who has a hammer, every problem is a nail.
Give that man some duct tape, and FILL IN JOKE HERE.)

[KnightErrant]

No joy, it was really funny, though. On the charge the
janissaries changed into a bunch of butterflies (really, that's what it
looked like) until they switched into charge_attack. Too late for
more experiments, try again tomorrow.

[zxiang1983]

Oops, wait a minute. Re-read the post more carefully. zxiang1983
says he copied MTW2_Halberd_Secondary which doesn't have
a charge entry or a charge_attack or a charge_to_ready anim
command. It inherits? (sorry, OOP terminology) its parent anim
is the MTW2_2HSwordsman so is he overriding those commands?




Ya, it seems so. I just added those three charge related entry in my MTW2_Halberd_Secondary_zxiang anim type and it works:2thumbsup: Actually adding or changing walking, running, attacking, etc all work well.



On the charge the janissaries changed into a bunch of butterflies (really, that's what it
looked like) until they switched into charge_attack.


Really? Generally speaking, I think the animation is very much like those 2H axe units' charging(raising the halberd over their shoulders)

[KnightErrant]

@zxiang1983
Finally got some time to work on this. Too hard to see the
charge anim so I looked at the walk anim which is also nonstandard
and has missing data for eyebrow and jaw bones. Here's the pic
for the walk anim inserted into MTW2_Halberd_Secondary_sandy
(my anim family name):

https://img245.imageshack.us/img245/4994/pigsnoutwalkgr1.th.jpg (https://img245.imageshack.us/my.php?image=pigsnoutwalkgr1.jpg)

Same "pigsnout helm" problem as the charge anim.
I then ran then .cas file through my newest animmerge to reorder the
data and to fill in the missing animation frames and then ran animextract
to recreate the .cas file in standard order with all the data filled in. Here's
a pic of the new anim:

https://img245.imageshack.us/img245/7681/walkingnormalpc7.th.jpg (https://img245.imageshack.us/my.php?image=walkingnormalpc7.jpg)

"Pigsnout helm" problem gone. I'll convert over the three anims you are using
doing the animmerge/animextract procedure and check them to be sure that
they are alright then post them at twcenter. If this truly solves the problem
I can automate the process to correct all the .cas files in
new_2h_axe_halberd so they will be usable.

Thanks for the test case, this one was fun to track down. :2thumbsup:

[GrumpyOldMan]

Hi KE, Zxiang et al

While we're working on the animations it might be useful for us to go over the logic and the flow of meshes and animations.

This is my understanding of it:-

The mesh is loaded and this sets the global positions of the vertices, sets up a partial hierarchy of bones in a bone table (just the names and indices, no parent/child relationships) and then attaches vertices to bones.

The basepose is loaded and this completes the hierarchy (parent/child relationships) and the global position of the bones. Once we have the global positions of the bones we can then establish the local position of vertices to their assigned bones - this is used for the matrix manipulation during animation.

During the game, various animations are called. The engine checks the base bone positions (by index!!!) in the anim cas against the basepose and makes any adjustments (hence the movement of vertices in Zxiang's discovered anims) and then applies translations and rotations to the vertices based on bone index.

So when we look at anims we have to make a coodinated whole with the mesh, the basepose and the anims, particularly hierarchy and indices. There is string text matching but this is used for attachment of weapons. A sword uses it's default basepose anim to attach itself to bone_Rhand, a bow to bone_Lhand, etc. But for the purposes of animation the hierarchy indices are basically set by the mesh. This is why the animations found by Zxiang can't be used 'as is' because of the clash with the mesh and the basepose, they have to be altered to fit into the overall hirearchy. This means altering the position of the jaw and eyebrow bones (together with any translations/rotations) data into the correct hierarchy slots. A clash between basepose and anims is also why there were all the problems with Bwian's dwarf. The base pose was setting long legs (and setting local vertex/bone values) , the anims were shortening them and scrunching up the attached vertices.

This is just my understanding of it, I have been known to be wrong before so don't hesitate to correct me if you do see any flaws, I promise to only sob quietly :beam: .

Edit:- KE, this is getting spooky, the number of times we cross post :scared: :scared:

Cheers

GrumpyOldMan:scared:

[KnightErrant]

Took a bit, charge_attack broke my script. Try these here:

http://www.twcenter.net/forums/downloads.php?do=file&id=1439

These should fix the "pigsnout helm" anim problem like the walk anim.
Let me know how it goes. This could be generalized.

[KnightErrant]

Hi GrumpyOldMan,

I think I've resolved zxiang1983's anim problem so this is a good
time to consolidate knowledge. We understand the data in the
meshes: vertices, triangles, and bones. We understand the data
in .cas files: rotations, animations, and pose or skeletons. We don't
know what the bounding sphere is exactly; is it a fight anim thing
or a spacing thing, or a projectile impact thing. My spider-archer
experiment from a couple of months ago didn't really elucidate things.
I guess if I has to put forth questions mine would be:

(1) What is the bounding sphere?

(2) How do we add extra bones? Your research indicates we add them
after the weapons/shields bones, I haven't modified my animmerge and
animextract for this, but I've studied it and it shouldn't be hard. Just
need to "continue" over bones containing "weapon" or "shield".

(3) Templates: Not sure if I'm thinking the same thing, but I see this
as bones, hierarchy data, and bone names for insertion into an animation
directory. (MTW2_Spear_tailsthatwag for instance). Or flying anim
families where wing bones are animated but are tied to an existing
mount. walk and run etc. become flying anims. If the game is truly
2D this is probably a non-starter.

(4) Are siege engines so different? Haven't looked at the anims.

There has been lots of good ideas on this but I haven't kept good notes
about it all. I would like to at least write up the .cas file format while I've
got the variations sort of in my mind. Vacation coming up so I'm under a
constraint there, good constraint that is. :laugh4:

Was bad, (or good), and spent my lunch hour writing help info buttons
for animationutilities. If I can get create_image to work like the
documentation says, I might even have an about box.

[zxiang1983]

Hi, KE. Just tested those charge anim file. They are perfect, great work:2thumbsup: !

And BTW, about their walking anim, I suppose you were using 2h_axe_walk.cas. That file is broken. Not only the face is twisted but the anim itself is just incontinuous. But obviously CA realized that problem so there's another file called 2HAxe_walk.cas which is as perfect as your charge anim:laugh4:

Thank you for your kindness.

[KnightErrant]

@zxiang1983
Glad to hear that. This means we should be
able to fix up other interesting animations even
if they're out of kilter with the regular ones. Now that
I've seen GrumpyOldMan's explanation of how the anims
work, I understand why the data had to be reordered since
it isn't just string look-ups. This is getting more and more
interesting!:beam:

[GrumpyOldMan]

Hi KE


Hi GrumpyOldMan,

I think I've resolved zxiang1983's anim problem so this is a good
time to consolidate knowledge. We understand the data in the
meshes: vertices, triangles, and bones. We understand the data
in .cas files: rotations, animations, and pose or skeletons. We don't
know what the bounding sphere is exactly; is it a fight anim thing
or a spacing thing, or a projectile impact thing. My spider-archer
experiment from a couple of months ago didn't really elucidate things.
I guess if I has to put forth questions mine would be:

(1) What is the bounding sphere?

I'm not really sure but the differences in radius(?) values between various weapon types seem to indicate something to do with fighting. I think until we know more about it, we should make any new figures human size and then use scaling to change size so we have examples of valid bounding spheres to use.


(2) How do we add extra bones? Your research indicates we add them
after the weapons/shields bones, I haven't modified my animmerge and
animextract for this, but I've studied it and it shouldn't be hard. Just
need to "continue" over bones containing "weapon" or "shield".

I've sat down and had a think about this and we'll have to site the weapon bones at the end of the figures, otherwise there will be a clash between bone index values in the mesh and anims. The anims will have a hole in the run of bone indices if we take the weapon bones out of the middle of a figure, this would lead to catastrophic if not amusing results. I'm not sure the engine can take it (I sound like Scotty in Star Trek :beam: ). I've had to put in an option for template creation from an ms3d to add weapon bones if not already included, the template creation from a basepose or anim cas has this done automatically. So weapon/shield bones will have to go at the end of any new meshes or else the bone hierarchy gets out of sync between the mesh and anims.


(3) Templates: Not sure if I'm thinking the same thing, but I see this
as bones, hierarchy data, and bone names for insertion into an animation
directory. (MTW2_Spear_tailsthatwag for instance). Or flying anim
families where wing bones are animated but are tied to an existing
mount. walk and run etc. become flying anims. If the game is truly
2D this is probably a non-starter.

Making a template for the meshes is fairly straightforward, basically extracting bone hierarchy, names and positions for making plug in bits for ms3d and mesh files. For the animation process it may be a bit more difficult if bones have been inserted into (or deleted from) a vanilla hierarchy. For example if you do have a lizardman that has tail bones inserted after the head type bones, you'll have to rely on string recognition to make sure that you're transferring the right translations/rotations to the right bone. You may have to come up with a convention that new bones can only be added at the end of vanilla hierarchy if you're going to be transferring existing anims to new skeletons. If bones have been deleted you'll have to rely on string recognition. The same would apply to flying skeletons if they are viable. Unfortunately we can't tie animated attachments or weapons with separate animations to skeletons with the current engine. I went over this with Caliban when I was working on the standard bearer and if we want to add any new animations they have to included in the overall anim cas. So wings would have to attached to the mesh and anim hierarchy, and animated to fit in with the separate anims. With the standard bearer I've had to retime the flag anim for cas' with frames from 11 to 217 frames. I'm about half way through at the moment.


(4) Are siege engines so different? Haven't looked at the anims.

I think the main difference for siege engines is that they have two sets of anims, one for normal and one for destroyed. Lots more adventures to go, KE.


There has been lots of good ideas on this but I haven't kept good notes
about it all. I would like to at least write up the .cas file format while I've
got the variations sort of in my mind. Vacation coming up so I'm under a
constraint there, good constraint that is. :laugh4:

Was bad, (or good), and spent my lunch hour writing help info buttons
for animationutilities. If I can get create_image to work like the
documentation says, I might even have an about box.

Sounds like a worthy way to spend your vacation, if you're working on the mtw2 stuff, try to not look as if you're enjoying yourself and moan and complain a lot, otherwise you'll be snatched away to work on something else. This is what usually happens to me :laugh4: :laugh4:

Cheers

GrumpyOldMan

[KnightErrant]

Ok, some success with adding extra bones to make a tailed unit.
Wrote a utility to reorder bones and put the weapon/shield bones at
the end with the new bones in front of them. Another utility exports
the new skeleton file and hierarchy tree to all the .cas files in a directory
putting in 0.0 0.0 0.0 1.0 quats for the new bone rotations and
0.0 0.0 0.0 for the new bone animations deltas and puts the new bones
in the pose data. Then used animmerge to pull the animation into the
.ms3d file and opened in Milkshape with the walk animation. Then animated
bone_tail1 in the keyframer. Here's the result:

https://img479.imageshack.us/img479/600/tailedarmoredsergeantszm4.th.jpg (https://img479.imageshack.us/my.php?image=tailedarmoredsergeantszm4.jpg)

I just assigned some vertices to bone_tail2 to make a fake tail using
the existing vertices in armored_sergeants. The red circle is bone_tail1
and the green is bone_tail2. The animation just wags the tail for 19 frames.

The problem is back converting. GrumpyOldMan's didn't work for me so I
tried the Python meshconverter which just uses the bones that are in
the .ms3d file. The only modification is the node numbers. I'm guessing they
should go like this:


bone_pelvis 0
bone_rthigh 1
bone_rlowerleg 2
bone_rfoot 3
bone_abs 4
bone_torso 5
bone_head 6
bone_jaw 7
bone_eyebrow 8
bone_rclavical 9
bone_rupperarm 10
bone_relbow 11
bone_rhand 12
bone_lclavical 13
bone_lupperarm 14
bone_lelbow 15
bone_lhand 16
bone_lthigh 17
bone_llowerleg 18
bone_lfoot 19
bone_tail1 20
bone_tail2 21
bone_weapon01 22
bone_weapon 22
bone_weapon02 23
bone_weapon03 24
bone_shield01 24
bone_shield 24


Will try to make a new animation family and put it in descr_skeleton.txt
and see if the extra bones work in the game this weekend.

[GrumpyOldMan]

Hi KE




The problem is back converting. GrumpyOldMan's didn't work for me so I
tried the Python meshconverter which just uses the bones that are in
the .ms3d file. The only modification is the node numbers. I'm guessing they
should go like this:

Will try to make a new animation family and put it in descr_skeleton.txt
and see if the extra bones work in the game this weekend.

You're quite right, until I can get my a*** into gear and finish the template version of the converter, you won't be able to use the converter for anything else than vanilla skeletons. The reason I'm going with a template system is so that people can convert from one skeleton to another ie if you wanted dwarf dismounted templars, you'd convert the mesh using a dwarf template and adjust the vertices to fit, or standard bearer, etc. The merge groups function would also use the templates. I may be able to face a long, long, long scroll of source code again soon :beam: :beam: but haven't had the chance to do so lately. Wish me luck as I battle with the GUI.

Cheers

GrumpyOldMan

[KnightErrant]

I do wish you luck with the GUI. Its always the most tedious part,
at least in Python it's been. There isn't a whole lot of documentation,
and usually that's wrong as well.:laugh4:

[KnightErrant]

GOT IT, GOT IT, GOT IT! Extra bones in game for
units with weapons/shield bones.

https://img201.imageshack.us/img201/9796/mutantsingamehu1.th.jpg (https://img201.imageshack.us/my.php?image=mutantsingamehu1.jpg)

All the English armored_sergeants_mutants are wagging their tails
underneath their tunics as they execute the walk anim.~:cheers:
Blowing the froth off a cold one must have done the trick!
Couldn't be more chuffed at the moment...love that word!

[Casuir]

Nice work

[alpaca]

Great work :medievalcheers:

[Lusted]

Bet Bwain goes mad when he hears this! Great work KE!

[SigniferOne]

KE, wow that's butt kicking! I mean tail kicking! I mean, er, you know what I mean!

[KnightErrant]

Many thanks guys, never knew animations was
going to be so fun.:beam:

[LorDBulA]

You guys are doing amazing work. :2thumbsup:

[Bwian]

Go mad...ALREADY MAD!

But mad and happy now...thinking thoughts of Lizardmen with tails and skaven waving their backsides around like proper rats.

This is really a bit of a landmark breakthrough. If we can add bones and animate them, then we can make ANYTHING for MTW that fits with the overall game mechanics. Any size...any shape....anywhere!

We now have just about all the barriers that limited RTW modding overcome.

Wonder...in all this...if there is now a way to actually make a chariot!

[KnightErrant]

Yes, this is very encouraging. Many thanks to GrumpyOldMan
for all the investigations into what can and can't be done with
bones. I got cc'd on some e-mails between Caliban and GOM
and I know that chariots were a big interest item. I think the
answer was that chariot anims are NOT in MTW2 BUT one could
make an ersatz one by deriving a anim family from the horse.
Take a horse and add extra bones like bone_left_rail, bone_right_rail,
bone_chariot_body, bone_left_wheel, bone_right_wheel, you get
the picture. Now you have to deal with what anims the horse has.
Here's what I got from my surveys for horse, camel, and elephants
as far as their anim commands are concerned:




fs_horse fs_african_elephant fs_camel

default default default

stand_a_idle stand_a_idle stand_a_idle
stand_a_to_walk stand_a_to_walk stand_a_to_walk
stand_a_to_run stand_a_to_run stand_a_to_run
stand_a_to_charge stand_a_to_charge

stand_a_turn_90_cw_1 stand_a_turn_45_cw_1 stand_a_turn_90_cw_1
stand_a_turn_90_cw_2 stand_a_turn_45_ccw_1 stand_a_turn_90_cw_2
stand_a_turn_90_ccw_1 stand_a_turn_90_cw_1 stand_a_turn_90_ccw_1
stand_a_turn_90_ccw_2 stand_a_turn_90_ccw_1 stand_a_turn_90_ccw_2

stand_a_hf_idle_1 stand_a_lf_idle_1 stand_a_hf_idle_1
stand_a_hf_idle_2 stand_a_lf_idle_2 stand_a_hf_idle_2
stand_a_hf_idle_3 stand_a_lf_idle_3 stand_a_hf_idle_3
stand_a_lf_idle_1 stand_a_lf_idle_1

shuffle_forward shuffle_forward
shuffle_backward shuffle_backward
shuffle_left shuffle_left
shuffle_right shuffle_right

walk walk walk
walk_to_run walk_to_run walk_to_run
walk_to_stand_a walk_to_stand_a walk_to_stand_a

run run run
run_to_walk run_to_walk run_to_walk
run_to_stand_a run_to_stand_a run_to_stand_a
run_to_charge run_to_charge

charge charge charge
jump charge_attack stand_a_to_charge
refuse attack_mid_low_1 run_to_charge
attack_mid_centre_1 attack_mid_centre_1
attack_mid_high_1

die_forward_1 die_forward_1 die_forward_1
die_backward_1 die_backward_1 die_backward_1
die_forward_2 die_to_back_right_1
die_backward_2 die_falling_cycle
die_to_back_right_1 die_falling_end
die_to_back_right_2 die_galloping
die_to_back_left_1 die_refusing
die_to_back_left_2
die_falling_cycle
die_falling_end
die_refusing
die_galloping

idle_to_swim idle_to_swim idle_to_swim
swim_to_idle swim_to_idle swim_to_idle
swim_idle swim_idle swim_idle
swim swim swim
swim_shuffle_forward swim_attack swim_shuffle_forward
swim_shuffle_backward swim_shuffle_backward
swim_shuffle_left swim_shuffle_left
swim_shuffle_right swim_shuffle_right


The horse is, of course, the most complex. But if these could all be
suitably modified maybe a chariot would work.

My interest for July when I get back from vacation is to try a flying mount.
GOM has already warned me that the success/failure for this or maybe
game interest for this depends on if the game is fundamentally 2D or 3D.

Suppose you make a Nazgul flying reptile based on the horse. It has the
usual horse bones only changed to make it reptilian. Now you add wing
bones which we know should work, it's just a new type of "horse". Change
the stand_a_to_walk animation to be a rather long standing on the ground
to actual flight animation with the mount 20 meters up in the air.
Also change the repeatable walk, run, charge, etc. animations to be airbourne.
How would this interact with units? If the bounding sphere really is just a
collision detection mechanism and it accepts the y values as true then
maybe flying over another unit doesn't trigger a fight anim. The main problem
GOM saw was interacting with walls. Maybe an airborne unit can't overfly
a settlement until the gate is breached and then can only fly over the gate.
This is the whole 2D/3D question. Don't know how to settle it until we
give it a go. Anyway, my two cents on the thing.:2cents:

Have to try this smilie too, just noticed it in the list...:wizard:

[Casuir]

Elephant would probably be a better base for trials, think the rider position is hardcoded to a certain bone on the horse and it mightnt be possible to have multiple passengers on a horse.

[GrumpyOldMan]

Hi KE and Casuir


Elephant would probably be a better base for trials, think the rider position is hardcoded to a certain bone on the horse and it mightnt be possible to have multiple passengers on a horse.

The mounts we are restricted to in mtw2 are horse, camel and elephant. I've been thinking about chariots and how we can fudge them. Both horse and camel are restricted to one rider each, only elephant can have more than one rider. By the way this is all controlled in descr_mount.txt in the data folder. There's ways of getting around this for horse and camel by making the driver part of the mount instead of a separate rider. The other thing to bear in mind is that some mounts have adverse effects on opponents, ie camel against horses. Sitting around chewing my pencil about this, I'd think that for a light chariot maybe a camel based chariot would be best and for a heavy 4 horse chariot maybe an elephant based model would be best.


My interest for July when I get back from vacation is to try a flying mount. GOM has already warned me that the success/failure for this or maybe game interest for this depends on if the game is fundamentally 2D or 3D.

Fast way to check, add 15 to the y value of the pelvis movement for the run and/or charge anims for a particular figure. The figure will leap upward when you charge them at a unit in the back row. If they drop out of the sky to fight intervening troops then the collision system is 2D, otherwise 3D. Incidentally the descr_mount.txt also records the height of the root node bone above the ground.

Cheers

GrumpyOldMan

[Casuir]

Mount advantages and disadvantages against each other are specified by unit in the edu, according to the comments this can be set by mount class or by specific type so thats not really an issue. I'd go with basing both on elephants, I dont think horses and camels are capable of having their own attacks which would be neccessary for scythed chariots and the like.

[KnightErrant]

Thanks GrumpyOldMan and Casuir,

I'll try the adding offset to y values tonight.
That sounds like a fun experiment.

[Bwian]

If we are looking at how this would all fit together, then the Elephant is hte logical staret point. The 'mahoot' unit would have the driver animations, and there could be multiple passengers on the chariot. You also do not have jump type animations or overly animated death routines. We would just have to have a 'pole' bone that linked the actual horse part to the chariot part. It wouldn't do much... but it would ensure continuityu of hte skeleton. Then you would have to have a 'wheel' bone to allow hte axle to rotate.

I was going to re-site the tail bones to do this on a skeleton that had been re-shaped to match the horse one as soon as KE's animation script was able to handle non-human units. This would be easy enough to do. You could also add an extra bone for 4-wheeled chariots!

The worst aspect of this would be the fact that we would only have a single set of bones for a horse. The extra horses would be east to do...just parallel meshes rigged to the same bones... but the horses would always move in step. This might look odd.

On the subject of looking 'odd' I think I have found a hitch with version 4 of the animation modifier tool. When I made osme units based on teh mace base for single handed weapons, the weapon bone did not seem to go with the hand bone anymore! The weapon was floating in space away from the hand, despite being correct in ~MS3D. It's easy to work around, and no big issue....since I just assigned the weapon to the hand bone to cure it. Not sure what the cause was. It worked fine on the 2-handed animation before!

[KnightErrant]

@Bwian
Don't know what the issue is with the weapon bone;
I don't ever do anything with weapon/shield bones in
the meshconverter or the animation utilities. I just put
them in .ms3d with zero offsets and read them back out
on the back conversion with the meshconverter. For the
animation utilities they just sort of occupy space but don't
ever get any data associated with them. I'll have to have a look
when I get back from vacation.

@All
Tried GOM's experiment: Here's the flying dwarves.

https://img389.imageshack.us/img389/2396/flyingdwarvespd2.th.jpg (https://img389.imageshack.us/my.php?image=flyingdwarvespd2.jpg)

For some reason they are flailing a lot when they should just be walking
on air. Finally found a good use for convertcastotxt and converttxttocas.
Converted the walk anim to ASCII and just modified the bone_pelvis y values
and then converted back to binary .cas format and rebuilt the packs.

Anyway, long story short. The captain stayed on the ground and the
moment the lines met the dwarves descended and started fighting. Not
definative because of the captain issue but it appears the game is 2D
in collision detection; not 3D. Haven't tried the same thing against
a city wall but maybe tomorrow.

Will try to post a version 1.1 of the animationutilities before I take off.
User's Guide and Tutorial is done, just need to make some neat graphics of
the dwarves and tailed armored_sergeants for cover art and the gee whiz
factor.:laugh4:

[KnightErrant]

Ok, posted the latest version of the animationutilities here:

http://www.twcenter.net/forums/showthread.php?t=105527

Bug reports are ok, but let me know what you think of the
all-pervasive dragon theme in the User's Guide and the about
box of the Python script.:laugh4:

[zxiang1983]

haha, that means we can make a superman, lol? Wish they could attack ground targets.

[GrumpyOldMan]

Hi KE




@All
Tried GOM's experiment: Here's the flying dwarves.

For some reason they are flailing a lot when they should just be walking
on air. Finally found a good use for convertcastotxt and converttxttocas.
Converted the walk anim to ASCII and just modified the bone_pelvis y values
and then converted back to binary .cas format and rebuilt the packs.

Could this be a clash with the bounding spheres, does it look anything like the infamous spider archers :beam: ? I banged the side of the animation utilities and gave it a stern talking to but the convert text to cas option stubbornly remains grayed out.


Anyway, long story short. The captain stayed on the ground and the moment the lines met the dwarves descended and started fighting. Not definative because of the captain issue but it appears the game is 2D in collision detection; not 3D. Haven't tried the same thing against
a city wall but maybe tomorrow.

Another way to tell is if they zig and zag while passing over a friendly unit, ie if the collision system is finding a path through a ground unit even though the other unit is above it.


Will try to post a version 1.1 of the animationutilities before I take off. User's Guide and Tutorial is done, just need to make some neat graphics of the dwarves and tailed armored_sergeants for cover art and the gee whiz factor.:laugh4:

As always, will look forward to your documentation.

Thoughts on 2d flying units - having the units as 2d takes care of one problem - what to do about mid air collisions and fighting, not realistic for two dragons to meet in mid air and immediately go to ground to fight. There is only one fight sequence available. Disadvantages, can not fly over an unfriendly unit, can not fly over city walls. Advantages - faster than normal mounts, useful on flanks or rear.

Suggestions - have all flying anims at a standard height, bit higher than an elephant so that air to ground and air to air combat will look realistic. Don't have the flying units land, just hover in 'idle', other wise when the mount goes into default it will land and wait while the riders duke it out, and then take off again, will also take care of any collision issues with large wings?

Just a few rambling thoughts.

Edit - @@@@KE - downloaded your latest utilities package but I got the following error when I tried to convert text to cas -

https://i150.photobucket.com/albums/s104/grumpyoldman2007/th_error.jpg (https://i150.photobucket.com/albums/s104/grumpyoldman2007/error.jpg)

Edit2 - got it working, wouldn't convert text made by an earlier version

Just repeated the flying leap running experiment and yes the collision system is definitely 2d, flying creatures can't overfly enemy units, the collisions happen at ground level. Interesting what happens to the anims though, may play around with the bounding sphere and see what happens.

Cheers

GrumpyOldMan

[Bwian]

This pretty much mirrors what the situation was with RTW in terms of collision. The units there were 2D, and had no awareness of how high up they were. They reacted to walls in the same was as ground troops, and could only walk through open gates.

Combat animations were triggered when the units ran into each other, and whichever animation routines were normal for the unit would being.

I am not sure how M2TW would react if you fired arrows at a model translated up that way .... but if it uses the bounding sphere for that, then it may not actually be possible to hit the airborne unit at all... I suspect the bounding sphere has not gone 'up' with the model! Whilst the game may be able to cope with hills .... I think only the terrain is used to modify the height of the unit.

[zxiang1983]

Is it possible now to bring wagon fort to life? Is there any hardcode limit to prevent people doing so?

I think using this wagon fort may be relatively a little easier:
https://img182.imageshack.us/img182/1213/14600836da7.jpg (https://imageshack.us)

Let the crossbowmen push this wagon as a ram. When using this wagon in battle, first let crossbwmen step on to it--this must be the most difficult part.
After that, they can use the normal crossbowmen animation.

About the stepping_onto_wagon animation, maybe we can use the climbing ladders animation? Also we need a stepping_off_wagon animation.

[Bwian]

I don't hink mounting and dismounting would be possible. They are outside the scope of the game mechanics when it comes to anything other than siege equipment.

You could make the unit move as a 'mount' with a crew on board. The elephant, for example, could probably be replaced by the cart mesh, and the descr_skeleton entries replaced with animations from the cart to make it roll if movement were needed. The 'crew' would be the elephant riders.

The crew would have a nasty tendancy to shoot through the wood of the wall... which is a bit naughty but unavoidable... and the AI behaviour of the unit would be a little 'bizarre' but there is no reason something couldn't be done.

[zxiang1983]

Thank you, Bwian!

So I suppose it would be better to make the wagon fort unmovable? because otherwise we need additional units to push it, which would be difficult to implement. And some thing more is that when in battle, we need to roll the wagon by 90 degrees to let its side face the enemy, which would be difficult as well.

[GrumpyOldMan]

Hi Zxiang


Thank you, Bwian!

So I suppose it would be better to make the wagon fort unmovable? because otherwise we need additional units to push it, which would be difficult to implement. And some thing more is that when in battle, we need to roll the wagon by 90 degrees to let its side face the enemy, which would be difficult as well.

No it wouldn't be feasible to have this sort of setup but I do remember that somebody here or at twcenter had got the warwagons in game using another siege engines skeletons.

Edit:- Have a look at http://www.twcenter.net/forums/showthread.php?t=82549 now we have the mesh converters and more information on skeletons and anims we may be able to come up with a more stable fix.

Because I'm interested in eastern European warfare, I've been looking at a horse drawn warwagon as an elephant. Still early days yet.

Cheers

GrumpyOldMan

[KnightErrant]

Hi Guys,

Nothing to post, just wanted to say hi.
Intercepted a quadraillion photons, worked
on my melanomas, ate in restaurants I've never been
to before, in short, a wonderful vacation. I know MT2W
isn't 3D so we can't do the Nazgul and Eagles and other
cool stuff but is there a way to half-assedly (hope I don't
barred for that) try to do flying units? If we make them
just archers can they just do a cantabrian sort of thing and
keep them from interacting with units?

Just wanted to post, I'm really interested.

Back from the wilds of Florida, go Perdido Key! (As if
they had a football team.)

KE

[GrumpyOldMan]

Hi KE


Hi Guys,

Nothing to post, just wanted to say hi.
Intercepted a quadraillion photons, worked
on my melanomas, ate in restaurants I've never been
to before, in short, a wonderful vacation. I know MT2W
isn't 3D so we can't do the Nazgul and Eagles and other
cool stuff but is there a way to half-assedly (hope I don't
barred for that) try to do flying units? If we make them
just archers can they just do a cantabrian sort of thing and
keep them from interacting with units?

Just wanted to post, I'm really interested.

Back from the wilds of Florida, go Perdido Key! (As if
they had a football team.)

KE

Welcome back from your vacation, hope you had a great time.

As regards the flying stuff, look at my post up above where I put in a few rambling thoughts. The main problem is going to be interaction with stuff on the ground, enemies or friends, and how to treat combat, air based or ground based? If you want flying based combatants then I think the low flying option is the best. Or you could come with me and look at programming languages to make a 3d based combat engine :laugh4: :laugh4: .

I saw on the Milkshape forum http://www.chumba.ch/chumbalum-soft/forum/showpost.php?p=129784&postcount=1 where somebody has posted a Python plugin for Milkshape. Haven't looked at it yet but it might be useful for you.

Just off to look at dx9 hlsl mesh skinning and see what language/engine supports it :beam: .

Cheers

GrumpyOldMan

[KnightErrant]

@GOM,

Well I am interested in the Python plug-in; have to
check that out. Read up some good stuff on Python a bit on the
vacation (hid the book behind a novel so it looked like
I wasn't having fun). Other book was on 3D modeling
with the Torque engine. I don't know, pseudo-C++ scripting
language? Blitz3D looks better to me, Got to get the animals
back from the kennels and settle back in, then back to
the joying of messin' with stuff.:laugh4:

[Bwian]

I made some very low-flying units for RTW for my 'Metal Mayhem' mod. I made a new animation set that had a rotating set of rotor blades, then hung a small droid thing underneath the rotors. The blades were both the 'flight' mechanism and the weapon :2thumbsup:

They flew just about head height, so the enemy attacks looked natural. Anything higher, and the attacking melee weapons are aimed in the wrong place. I kept them small, so that the creatures did not look out of place hovering at that height. Make the thing big..like...say...a Pegasus.. and at that height they do not look like they have bothered to fly! Make them small...like a small imp or devil, and they look much better. Presumably, increasing the horizontal component of the animation would help too. Make them move faster than a galloping horse and you also increase the illusion of flight. I did that too for my hovering drones.

You also need to be careful with the death animations as well :beam: You need to make sure they actually hit the ground properly!