Animations

[KnightErrant]

Already tried this above but here's the basepose for
MTW2_2HSwordsman which the secondary anim should inherit:

0    skeleton pose data, all bones including Scene_Root
+0.0000000000 +0.0000000000 +0.0000000000
+0.0000000000 +0.0000000000 +0.0000000000
+0.0952388123 +0.0007522844 -0.0000000077
+0.0225613099 -0.4644488394 +0.0143959811
+0.0241626594 -0.3995065689 -0.0316339098
-0.0000000069 +0.2124620080 +0.0000000008
-0.0002945330 +0.2115577459 +0.0000000299
-0.0000617082 +0.2349730581 +0.0000000668
+0.0003562513 +0.0108101442 -0.0034470249
+0.0016836975 +0.1178482324 -0.0744606256
+0.0132546443 +0.1300113499 -0.0273839179
+0.1653589010 -0.0517836586 +0.0034832843
+0.3022063971 +0.0111386608 -0.0137691963
+0.2838369906 -0.0030556759 +0.0263375118
-0.0102220895 +0.1300113499 -0.0273839179
-0.1678023189 -0.0517838039 +0.0034833583
-0.3021733165 +0.0111954408 -0.0144314421
-0.2838012278 -0.0032004344 +0.0267044473
-0.0952387825 +0.0007523637 +0.0000000220
-0.0216093510 -0.4641437531 +0.0230784994
-0.0250775032 -0.3986376822 -0.0406115167

and here's the pose data from the charge anim from new_2h_axe_halberd:

0    skeleton pose data, all bones including Scene_Root
+0.0000000000 +0.0000000000 +0.0000000000
-0.0000000000 +0.0000000969 -0.0000000000
+0.0952388048 +0.0007522567 -0.0000001105
+0.0225616489 -0.4644486904 +0.0143948821
+0.0241624303 -0.3995064199 -0.0316330455
-0.0000000002 +0.2124619335 +0.0000000074
-0.0002945446 +0.2115576714 +0.0000000356
-0.0000617125 +0.2349729091 +0.0000000648
-0.0015659207 +0.1178484261 -0.0744630992
+0.0002055460 +0.0108106285 -0.0034593104
+0.0132546341 +0.1300111562 -0.0273842439
+0.1653588265 -0.0517836101 +0.0034830223
+0.3022063673 +0.0111382734 -0.0137693156
+0.2838367820 -0.0030559180 +0.0263374485
-0.0102220811 +0.1300111562 -0.0273842085
-0.1678022444 -0.0517838039 +0.0034836400
-0.3021732569 +0.0111951502 -0.0144293746
-0.2838010490 -0.0031997561 +0.0267024450
-0.0952387676 +0.0007523138 +0.0000001374
-0.0216093212 -0.4641436040 +0.0230773669
-0.0250774790 -0.3986373842 -0.0406104438

The red lines are switched but that's ok, I think, because
the bone names are switched and GOM has established that
anims are done by the bone strings. So is this another
basepose conflict? Will try changing the pose data for
bone_jaw and bone_eyebrow to EXACTLY match the basepose
bones as a first try.

(I know: to a man who has a hammer, every problem is a nail.
Give that man some duct tape, and FILL IN JOKE HERE.)

[KnightErrant]

No joy, it was really funny, though. On the charge the
janissaries changed into a bunch of butterflies (really, that's what it
looked like) until they switched into charge_attack. Too late for
more experiments, try again tomorrow.

[zxiang1983]

Oops, wait a minute. Re-read the post more carefully. zxiang1983
says he copied MTW2_Halberd_Secondary which doesn't have
a charge entry or a charge_attack or a charge_to_ready anim
command. It inherits? (sorry, OOP terminology) its parent anim
is the MTW2_2HSwordsman so is he overriding those commands?

Ya, it seems so. I just added those three charge related entry in my MTW2_Halberd_Secondary_zxiang anim type and it works Actually adding or changing walking, running, attacking, etc all work well.

On the charge the janissaries changed into a bunch of butterflies (really, that's what it
looked like) until they switched into charge_attack.

Really? Generally speaking, I think the animation is very much like those 2H axe units' charging(raising the halberd over their shoulders)

[KnightErrant]

@zxiang1983
Finally got some time to work on this. Too hard to see the
charge anim so I looked at the walk anim which is also nonstandard
and has missing data for eyebrow and jaw bones. Here's the pic
for the walk anim inserted into MTW2_Halberd_Secondary_sandy
(my anim family name):



Same "pigsnout helm" problem as the charge anim.
I then ran then .cas file through my newest animmerge to reorder the
data and to fill in the missing animation frames and then ran animextract
to recreate the .cas file in standard order with all the data filled in. Here's
a pic of the new anim:



"Pigsnout helm" problem gone. I'll convert over the three anims you are using
doing the animmerge/animextract procedure and check them to be sure that
they are alright then post them at twcenter. If this truly solves the problem
I can automate the process to correct all the .cas files in
new_2h_axe_halberd so they will be usable.

Thanks for the test case, this one was fun to track down.

[GrumpyOldMan]

Hi KE, Zxiang et al

While we're working on the animations it might be useful for us to go over the logic and the flow of meshes and animations.

This is my understanding of it:-

The mesh is loaded and this sets the global positions of the vertices, sets up a partial hierarchy of bones in a bone table (just the names and indices, no parent/child relationships) and then attaches vertices to bones.

The basepose is loaded and this completes the hierarchy (parent/child relationships) and the global position of the bones. Once we have the global positions of the bones we can then establish the local position of vertices to their assigned bones - this is used for the matrix manipulation during animation.

During the game, various animations are called. The engine checks the base bone positions (by index!!!) in the anim cas against the basepose and makes any adjustments (hence the movement of vertices in Zxiang's discovered anims) and then applies translations and rotations to the vertices based on bone index.

So when we look at anims we have to make a coodinated whole with the mesh, the basepose and the anims, particularly hierarchy and indices. There is string text matching but this is used for attachment of weapons. A sword uses it's default basepose anim to attach itself to bone_Rhand, a bow to bone_Lhand, etc. But for the purposes of animation the hierarchy indices are basically set by the mesh. This is why the animations found by Zxiang can't be used 'as is' because of the clash with the mesh and the basepose, they have to be altered to fit into the overall hirearchy. This means altering the position of the jaw and eyebrow bones (together with any translations/rotations) data into the correct hierarchy slots. A clash between basepose and anims is also why there were all the problems with Bwian's dwarf. The base pose was setting long legs (and setting local vertex/bone values) , the anims were shortening them and scrunching up the attached vertices.

This is just my understanding of it, I have been known to be wrong before so don't hesitate to correct me if you do see any flaws, I promise to only sob quietly .

Edit:- KE, this is getting spooky, the number of times we cross post

Cheers

GrumpyOldMan

[KnightErrant]

Took a bit, charge_attack broke my script. Try these here:

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

These should fix the "pigsnout helm" anim problem like the walk anim.
Let me know how it goes. This could be generalized.

[KnightErrant]

Hi GrumpyOldMan,

I think I've resolved zxiang1983's anim problem so this is a good
time to consolidate knowledge. We understand the data in the
meshes: vertices, triangles, and bones. We understand the data
in .cas files: rotations, animations, and pose or skeletons. We don't
know what the bounding sphere is exactly; is it a fight anim thing
or a spacing thing, or a projectile impact thing. My spider-archer
experiment from a couple of months ago didn't really elucidate things.
I guess if I has to put forth questions mine would be:

(1) What is the bounding sphere?

(2) How do we add extra bones? Your research indicates we add them
after the weapons/shields bones, I haven't modified my animmerge and
animextract for this, but I've studied it and it shouldn't be hard. Just
need to "continue" over bones containing "weapon" or "shield".

(3) Templates: Not sure if I'm thinking the same thing, but I see this
as bones, hierarchy data, and bone names for insertion into an animation
directory. (MTW2_Spear_tailsthatwag for instance). Or flying anim
families where wing bones are animated but are tied to an existing
mount. walk and run etc. become flying anims. If the game is truly
2D this is probably a non-starter.

(4) Are siege engines so different? Haven't looked at the anims.

There has been lots of good ideas on this but I haven't kept good notes
about it all. I would like to at least write up the .cas file format while I've
got the variations sort of in my mind. Vacation coming up so I'm under a
constraint there, good constraint that is.

Was bad, (or good), and spent my lunch hour writing help info buttons
for animationutilities. If I can get create_image to work like the
documentation says, I might even have an about box.

[zxiang1983]

Hi, KE. Just tested those charge anim file. They are perfect, great work !

And BTW, about their walking anim, I suppose you were using 2h_axe_walk.cas. That file is broken. Not only the face is twisted but the anim itself is just incontinuous. But obviously CA realized that problem so there's another file called 2HAxe_walk.cas which is as perfect as your charge anim

Thank you for your kindness.

[KnightErrant]

@zxiang1983
Glad to hear that. This means we should be
able to fix up other interesting animations even
if they're out of kilter with the regular ones. Now that
I've seen GrumpyOldMan's explanation of how the anims
work, I understand why the data had to be reordered since
it isn't just string look-ups. This is getting more and more
interesting!

[GrumpyOldMan]

Hi KE

Hi GrumpyOldMan,

I think I've resolved zxiang1983's anim problem so this is a good
time to consolidate knowledge. We understand the data in the
meshes: vertices, triangles, and bones. We understand the data
in .cas files: rotations, animations, and pose or skeletons. We don't
know what the bounding sphere is exactly; is it a fight anim thing
or a spacing thing, or a projectile impact thing. My spider-archer
experiment from a couple of months ago didn't really elucidate things.
I guess if I has to put forth questions mine would be:

(1) What is the bounding sphere?

I'm not really sure but the differences in radius(?) values between various weapon types seem to indicate something to do with fighting. I think until we know more about it, we should make any new figures human size and then use scaling to change size so we have examples of valid bounding spheres to use.

(2) How do we add extra bones? Your research indicates we add them
after the weapons/shields bones, I haven't modified my animmerge and
animextract for this, but I've studied it and it shouldn't be hard. Just
need to "continue" over bones containing "weapon" or "shield".

I've sat down and had a think about this and we'll have to site the weapon bones at the end of the figures, otherwise there will be a clash between bone index values in the mesh and anims. The anims will have a hole in the run of bone indices if we take the weapon bones out of the middle of a figure, this would lead to catastrophic if not amusing results. I'm not sure the engine can take it (I sound like Scotty in Star Trek ). I've had to put in an option for template creation from an ms3d to add weapon bones if not already included, the template creation from a basepose or anim cas has this done automatically. So weapon/shield bones will have to go at the end of any new meshes or else the bone hierarchy gets out of sync between the mesh and anims.

(3) Templates: Not sure if I'm thinking the same thing, but I see this
as bones, hierarchy data, and bone names for insertion into an animation
directory. (MTW2_Spear_tailsthatwag for instance). Or flying anim
families where wing bones are animated but are tied to an existing
mount. walk and run etc. become flying anims. If the game is truly
2D this is probably a non-starter.

Making a template for the meshes is fairly straightforward, basically extracting bone hierarchy, names and positions for making plug in bits for ms3d and mesh files. For the animation process it may be a bit more difficult if bones have been inserted into (or deleted from) a vanilla hierarchy. For example if you do have a lizardman that has tail bones inserted after the head type bones, you'll have to rely on string recognition to make sure that you're transferring the right translations/rotations to the right bone. You may have to come up with a convention that new bones can only be added at the end of vanilla hierarchy if you're going to be transferring existing anims to new skeletons. If bones have been deleted you'll have to rely on string recognition. The same would apply to flying skeletons if they are viable. Unfortunately we can't tie animated attachments or weapons with separate animations to skeletons with the current engine. I went over this with Caliban when I was working on the standard bearer and if we want to add any new animations they have to included in the overall anim cas. So wings would have to attached to the mesh and anim hierarchy, and animated to fit in with the separate anims. With the standard bearer I've had to retime the flag anim for cas' with frames from 11 to 217 frames. I'm about half way through at the moment.

(4) Are siege engines so different? Haven't looked at the anims.

I think the main difference for siege engines is that they have two sets of anims, one for normal and one for destroyed. Lots more adventures to go, KE.

There has been lots of good ideas on this but I haven't kept good notes
about it all. I would like to at least write up the .cas file format while I've
got the variations sort of in my mind. Vacation coming up so I'm under a
constraint there, good constraint that is.

Was bad, (or good), and spent my lunch hour writing help info buttons
for animationutilities. If I can get create_image to work like the
documentation says, I might even have an about box.

Sounds like a worthy way to spend your vacation, if you're working on the mtw2 stuff, try to not look as if you're enjoying yourself and moan and complain a lot, otherwise you'll be snatched away to work on something else. This is what usually happens to me

Cheers

GrumpyOldMan

[KnightErrant]

Ok, some success with adding extra bones to make a tailed unit.
Wrote a utility to reorder bones and put the weapon/shield bones at
the end with the new bones in front of them. Another utility exports
the new skeleton file and hierarchy tree to all the .cas files in a directory
putting in 0.0 0.0 0.0 1.0 quats for the new bone rotations and
0.0 0.0 0.0 for the new bone animations deltas and puts the new bones
in the pose data. Then used animmerge to pull the animation into the
.ms3d file and opened in Milkshape with the walk animation. Then animated
bone_tail1 in the keyframer. Here's the result:



I just assigned some vertices to bone_tail2 to make a fake tail using
the existing vertices in armored_sergeants. The red circle is bone_tail1
and the green is bone_tail2. The animation just wags the tail for 19 frames.

The problem is back converting. GrumpyOldMan's didn't work for me so I
tried the Python meshconverter which just uses the bones that are in
the .ms3d file. The only modification is the node numbers. I'm guessing they
should go like this:

bone_pelvis       0
bone_rthigh       1
bone_rlowerleg    2 
bone_rfoot        3 
bone_abs          4
bone_torso        5
bone_head         6
bone_jaw          7
bone_eyebrow      8
bone_rclavical    9
bone_rupperarm    10 
bone_relbow       11
bone_rhand        12
bone_lclavical    13
bone_lupperarm    14
bone_lelbow       15
bone_lhand        16
bone_lthigh       17
bone_llowerleg    18
bone_lfoot        19
bone_tail1        20
bone_tail2        21
bone_weapon01     22
bone_weapon       22
bone_weapon02     23
bone_weapon03     24
bone_shield01     24
bone_shield       24

Will try to make a new animation family and put it in descr_skeleton.txt
and see if the extra bones work in the game this weekend.

[GrumpyOldMan]

Hi KE

The problem is back converting. GrumpyOldMan's didn't work for me so I
tried the Python meshconverter which just uses the bones that are in
the .ms3d file. The only modification is the node numbers. I'm guessing they
should go like this:

Will try to make a new animation family and put it in descr_skeleton.txt
and see if the extra bones work in the game this weekend.

You're quite right, until I can get my a*** into gear and finish the template version of the converter, you won't be able to use the converter for anything else than vanilla skeletons. The reason I'm going with a template system is so that people can convert from one skeleton to another ie if you wanted dwarf dismounted templars, you'd convert the mesh using a dwarf template and adjust the vertices to fit, or standard bearer, etc. The merge groups function would also use the templates. I may be able to face a long, long, long scroll of source code again soon but haven't had the chance to do so lately. Wish me luck as I battle with the GUI.

Cheers

GrumpyOldMan

[KnightErrant]

I do wish you luck with the GUI. Its always the most tedious part,
at least in Python it's been. There isn't a whole lot of documentation,
and usually that's wrong as well.

[KnightErrant]

GOT IT, GOT IT, GOT IT! Extra bones in game for
units with weapons/shield bones.



All the English armored_sergeants_mutants are wagging their tails
underneath their tunics as they execute the walk anim.
Blowing the froth off a cold one must have done the trick!
Couldn't be more chuffed at the moment...love that word!

[Casuir]

Nice work

[alpaca]

Great work

[Lusted]

Bet Bwain goes mad when he hears this! Great work KE!

[SigniferOne]

KE, wow that's butt kicking! I mean tail kicking! I mean, er, you know what I mean!

[KnightErrant]

Many thanks guys, never knew animations was
going to be so fun.

[LorDBulA]

You guys are doing amazing work.

[Bwian]

Go mad...ALREADY MAD!

But mad and happy now...thinking thoughts of Lizardmen with tails and skaven waving their backsides around like proper rats.

This is really a bit of a landmark breakthrough. If we can add bones and animate them, then we can make ANYTHING for MTW that fits with the overall game mechanics. Any size...any shape....anywhere!

We now have just about all the barriers that limited RTW modding overcome.

Wonder...in all this...if there is now a way to actually make a chariot!

[KnightErrant]

Yes, this is very encouraging. Many thanks to GrumpyOldMan
for all the investigations into what can and can't be done with
bones. I got cc'd on some e-mails between Caliban and GOM
and I know that chariots were a big interest item. I think the
answer was that chariot anims are NOT in MTW2 BUT one could
make an ersatz one by deriving a anim family from the horse.
Take a horse and add extra bones like bone_left_rail, bone_right_rail,
bone_chariot_body, bone_left_wheel, bone_right_wheel, you get
the picture. Now you have to deal with what anims the horse has.
Here's what I got from my surveys for horse, camel, and elephants
as far as their anim commands are concerned:

fs_horse                 fs_african_elephant     fs_camel                       
                                                                                
default                  default                 default                        
                                                                                
stand_a_idle             stand_a_idle            stand_a_idle                   
stand_a_to_walk          stand_a_to_walk         stand_a_to_walk                
stand_a_to_run           stand_a_to_run          stand_a_to_run                 
stand_a_to_charge        stand_a_to_charge                                      
                                                                                
stand_a_turn_90_cw_1     stand_a_turn_45_cw_1    stand_a_turn_90_cw_1           
stand_a_turn_90_cw_2     stand_a_turn_45_ccw_1   stand_a_turn_90_cw_2           
stand_a_turn_90_ccw_1    stand_a_turn_90_cw_1    stand_a_turn_90_ccw_1          
stand_a_turn_90_ccw_2    stand_a_turn_90_ccw_1   stand_a_turn_90_ccw_2          
                                                                                
stand_a_hf_idle_1        stand_a_lf_idle_1       stand_a_hf_idle_1              
stand_a_hf_idle_2        stand_a_lf_idle_2       stand_a_hf_idle_2              
stand_a_hf_idle_3        stand_a_lf_idle_3       stand_a_hf_idle_3              
stand_a_lf_idle_1        stand_a_lf_idle_1                                      
                                                                                
shuffle_forward                                  shuffle_forward                
shuffle_backward                                 shuffle_backward               
shuffle_left                                     shuffle_left                   
shuffle_right                                    shuffle_right                  
                                                                                
walk                     walk                    walk                           
walk_to_run              walk_to_run             walk_to_run                    
walk_to_stand_a          walk_to_stand_a         walk_to_stand_a                
                                                                                
run                      run                     run                            
run_to_walk              run_to_walk             run_to_walk                    
run_to_stand_a           run_to_stand_a          run_to_stand_a                 
run_to_charge            run_to_charge                                          
                                                                                
charge                   charge                  charge                         
jump                     charge_attack           stand_a_to_charge              
refuse                   attack_mid_low_1        run_to_charge                  
attack_mid_centre_1      attack_mid_centre_1                                    
                         attack_mid_high_1                                      
                                                                                
die_forward_1            die_forward_1           die_forward_1                  
die_backward_1           die_backward_1          die_backward_1                 
die_forward_2                                    die_to_back_right_1            
die_backward_2                                   die_falling_cycle              
die_to_back_right_1                              die_falling_end                
die_to_back_right_2                              die_galloping                  
die_to_back_left_1                               die_refusing                   
die_to_back_left_2                                                              
die_falling_cycle                                                               
die_falling_end                                                                 
die_refusing                                                                    
die_galloping                                                                   
                                                                                
idle_to_swim             idle_to_swim            idle_to_swim                   
swim_to_idle             swim_to_idle            swim_to_idle                   
swim_idle                swim_idle               swim_idle                      
swim                     swim                    swim                           
swim_shuffle_forward     swim_attack             swim_shuffle_forward           
swim_shuffle_backward                            swim_shuffle_backward          
swim_shuffle_left                                swim_shuffle_left              
swim_shuffle_right                               swim_shuffle_right

The horse is, of course, the most complex. But if these could all be
suitably modified maybe a chariot would work.

My interest for July when I get back from vacation is to try a flying mount.
GOM has already warned me that the success/failure for this or maybe
game interest for this depends on if the game is fundamentally 2D or 3D.

Suppose you make a Nazgul flying reptile based on the horse. It has the
usual horse bones only changed to make it reptilian. Now you add wing
bones which we know should work, it's just a new type of "horse". Change
the stand_a_to_walk animation to be a rather long standing on the ground
to actual flight animation with the mount 20 meters up in the air.
Also change the repeatable walk, run, charge, etc. animations to be airbourne.
How would this interact with units? If the bounding sphere really is just a
collision detection mechanism and it accepts the y values as true then
maybe flying over another unit doesn't trigger a fight anim. The main problem
GOM saw was interacting with walls. Maybe an airborne unit can't overfly
a settlement until the gate is breached and then can only fly over the gate.
This is the whole 2D/3D question. Don't know how to settle it until we
give it a go. Anyway, my two cents on the thing.

Have to try this smilie too, just noticed it in the list...

[Casuir]

Elephant would probably be a better base for trials, think the rider position is hardcoded to a certain bone on the horse and it mightnt be possible to have multiple passengers on a horse.

[GrumpyOldMan]

Hi KE and Casuir

Elephant would probably be a better base for trials, think the rider position is hardcoded to a certain bone on the horse and it mightnt be possible to have multiple passengers on a horse.

The mounts we are restricted to in mtw2 are horse, camel and elephant. I've been thinking about chariots and how we can fudge them. Both horse and camel are restricted to one rider each, only elephant can have more than one rider. By the way this is all controlled in descr_mount.txt in the data folder. There's ways of getting around this for horse and camel by making the driver part of the mount instead of a separate rider. The other thing to bear in mind is that some mounts have adverse effects on opponents, ie camel against horses. Sitting around chewing my pencil about this, I'd think that for a light chariot maybe a camel based chariot would be best and for a heavy 4 horse chariot maybe an elephant based model would be best.

My interest for July when I get back from vacation is to try a flying mount. GOM has already warned me that the success/failure for this or maybe game interest for this depends on if the game is fundamentally 2D or 3D.

Fast way to check, add 15 to the y value of the pelvis movement for the run and/or charge anims for a particular figure. The figure will leap upward when you charge them at a unit in the back row. If they drop out of the sky to fight intervening troops then the collision system is 2D, otherwise 3D. Incidentally the descr_mount.txt also records the height of the root node bone above the ground.

Cheers

GrumpyOldMan

[Casuir]

Mount advantages and disadvantages against each other are specified by unit in the edu, according to the comments this can be set by mount class or by specific type so thats not really an issue. I'd go with basing both on elephants, I dont think horses and camels are capable of having their own attacks which would be neccessary for scythed chariots and the like.

[KnightErrant]

Thanks GrumpyOldMan and Casuir,

I'll try the adding offset to y values tonight.
That sounds like a fun experiment.

[Bwian]

If we are looking at how this would all fit together, then the Elephant is hte logical staret point. The 'mahoot' unit would have the driver animations, and there could be multiple passengers on the chariot. You also do not have jump type animations or overly animated death routines. We would just have to have a 'pole' bone that linked the actual horse part to the chariot part. It wouldn't do much... but it would ensure continuityu of hte skeleton. Then you would have to have a 'wheel' bone to allow hte axle to rotate.

I was going to re-site the tail bones to do this on a skeleton that had been re-shaped to match the horse one as soon as KE's animation script was able to handle non-human units. This would be easy enough to do. You could also add an extra bone for 4-wheeled chariots!

The worst aspect of this would be the fact that we would only have a single set of bones for a horse. The extra horses would be east to do...just parallel meshes rigged to the same bones... but the horses would always move in step. This might look odd.

On the subject of looking 'odd' I think I have found a hitch with version 4 of the animation modifier tool. When I made osme units based on teh mace base for single handed weapons, the weapon bone did not seem to go with the hand bone anymore! The weapon was floating in space away from the hand, despite being correct in ~MS3D. It's easy to work around, and no big issue....since I just assigned the weapon to the hand bone to cure it. Not sure what the cause was. It worked fine on the 2-handed animation before!

[KnightErrant]

@Bwian
Don't know what the issue is with the weapon bone;
I don't ever do anything with weapon/shield bones in
the meshconverter or the animation utilities. I just put
them in .ms3d with zero offsets and read them back out
on the back conversion with the meshconverter. For the
animation utilities they just sort of occupy space but don't
ever get any data associated with them. I'll have to have a look
when I get back from vacation.

@All
Tried GOM's experiment: Here's the flying dwarves.



For some reason they are flailing a lot when they should just be walking
on air. Finally found a good use for convertcastotxt and converttxttocas.
Converted the walk anim to ASCII and just modified the bone_pelvis y values
and then converted back to binary .cas format and rebuilt the packs.

Anyway, long story short. The captain stayed on the ground and the
moment the lines met the dwarves descended and started fighting. Not
definative because of the captain issue but it appears the game is 2D
in collision detection; not 3D. Haven't tried the same thing against
a city wall but maybe tomorrow.

Will try to post a version 1.1 of the animationutilities before I take off.
User's Guide and Tutorial is done, just need to make some neat graphics of
the dwarves and tailed armored_sergeants for cover art and the gee whiz
factor.

[KnightErrant]

Ok, posted the latest version of the animationutilities here:

http://www.twcenter.net/forums/showthread.php?t=105527

Bug reports are ok, but let me know what you think of the
all-pervasive dragon theme in the User's Guide and the about
box of the Python script.

[zxiang1983]

haha, that means we can make a superman, lol? Wish they could attack ground targets.