Animations

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



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



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.



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



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:



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!

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



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

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!

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 but my logic has been known to be wrong before

Edit:- Curse this cross-posting mayhem

Cheers

GrumpyOldMan

[GrumpyOldMan]

Hi KE

@All

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



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.

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

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.



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

@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

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

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



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

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:



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.

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

[KnightErrant]

I think its progress... mixed with blowing off steam at finding a lot of
my mistakes. 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. 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 , it was so accurate it was scary .

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.

[SigniferOne]

Man you guys are amazing. GOM, just don't put a bucket on your head and start saying "I am your father" 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... 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!