Animations

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

Code:

---

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:

Code:

---

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

---

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

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

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.

Quote:

---

Originally Posted by KnightErrant

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

---

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

Quote:

---

Originally Posted by KnightErrant

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)

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

https://img245.imageshack.us/img245/...walkgr1.th.jpg

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

https://img245.imageshack.us/img245/...rmalpc7.th.jpg

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

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

Hi KE, Zxiang et al

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

This is my understanding of it:-

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

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

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

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

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

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

Cheers

GrumpyOldMan:scared:

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.

Hi GrumpyOldMan,

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

(1) What is the bounding sphere?

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

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

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

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

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

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

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

Thank you for your kindness.

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

Hi KE

Quote:

---

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

---

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.

Quote:

---

Originally Posted by KnightErrant

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

---

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

Quote:

---

Originally Posted by KnightErrant

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

Quote:

---

Originally Posted by KnightErrant

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

Quote:

---

Originally Posted by KnightErrant

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

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

---

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

Cheers

GrumpyOldMan

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

https://img479.imageshack.us/img479/...antszm4.th.jpg

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

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

Code:

---

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.

Hi KE

Quote:

---

Originally Posted by KnightErrant

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

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

---

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

Cheers

GrumpyOldMan

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

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

https://img201.imageshack.us/img201/...gamehu1.th.jpg

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

Nice work

Great work :medievalcheers:

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

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

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

You guys are doing amazing work. :2thumbsup:

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!

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:

Code:

---

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

---

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

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

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

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

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.

Hi KE and Casuir

Quote:

---

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

Quote:

---

Originally Posted by KnightErrant

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

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.

Thanks GrumpyOldMan and Casuir,

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

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!

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

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

https://img389.imageshack.us/img389/...rvespd2.th.jpg

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

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

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

Ok, posted the latest version of the animationutilities here:

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

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

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