Animations

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!

Hi KE

Quote:

---

Originally Posted by 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.

---

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 :-

Code:

---

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; 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 :-

Code:

---

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; 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 :-

Code:

---

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; 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 :-

Code:

---

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; 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

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

Hi Casuir

Quote:

---

Originally Posted by 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:

Quote:

---

Originally Posted by Casuir

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.

Quote:

---

Originally Posted by Casuir

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

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.)

Hi Casuir

Quote:

---

Originally Posted by 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

---

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

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/t560892_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.

Hi Casuir

Quote:

---

Originally Posted by 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/t560892_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.

Quote:

---

Originally Posted by Casuir

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

Quote:

---

Originally Posted by GrumpyOldMan

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.

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.

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

Hi KE

Quote:

---

Originally Posted by 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.

---

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

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.

Hi KE

Quote:

---

Originally Posted by 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.

---

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

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.

Hi KE

Quote:

---

Originally Posted by 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.

---

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

Hi Casuir

Quote:

---

Originally Posted by 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

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.

Hi KE

Quote:

---

Originally Posted by 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.

---

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:-

Code:

---

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

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?

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.

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:

Code:

---

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

Code:

---

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

Code:

---

+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.

Code:

---

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.

Code:

---

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?

Hi KE

Quote:

---

Originally Posted by KnightErrant

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

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:

Quote:

---

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

---

Hi Casuir

Quote:

---

Originally Posted by 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

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:

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

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.

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.

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

Code:

---

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; 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

Code:

---

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; 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.