Animations

[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/showp...&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/showp...&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.

[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

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.

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.

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



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 .

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

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:



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.

[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

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.

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.

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:



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

[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 . 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/showp...&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....

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