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.