Animations

[Ashdnazg]

I couldn't see if this was seen earlier, so I post this anyway.
I had a wee look in Verc's script, and the second short in the header is the number of bones.
About the fifth byte, I think he actually skipped it.

Aargh, of course, missed that completely. I guess I don't
think in hex after all. So the 14 00 14 in the header after the initial short
count of frames is the bone count for what gets animated.
The variants I saw must have been strat map units which don't
have 20 animated bones... Got a better clue for looking at things
now, many thanks.

Thank you for ignoring my posts :D

[KnightErrant]

@Ashdnazg
You're absolutely right, I apologize. Went back and looked at
your post and there's the information staring me in the face.
I was so focused on fixing my script then my brain just wasn't
accepting new inputs. Please post any info you have; I promise
I'll pay better attention next time.

@GrumpyOldMan
Ok, got a reply from Caliban. He did the two experiments and none
of those "type files" or "skel files" exist with his unpacked setup.
So I think skeleton.dat/idx is supposed to stay packed and those
names are just look-up handles like you said. Looking at events.dat/idx
right now since Caliban had them unpacked. There's no names in
the index file so I think events and pack have to be unpacked together
since the .evt always matches the .cas path and filename. However,
the mapping is onto but not 1-1, not every cas file has a corresponding
evt file. If I'm seeing the header right, there's 1000 evt files for 2400
cas files.

[Casuir]

evt files look to be sound files so logically there wouldnt be one for every animation, a lot of the entrys in the skeleton.dat look to be just unit_march

[KnightErrant]

I think you're right, the data in events.dat seems to be file names for .wav
and .mp3 files in the sounds directory (although really in sounds.dat).
Looking at descr_skeleton.txt which seems to have much of the real
data in skeletons.dat shows the _basepose.cas, a lot of the _idle .cas's,
and the weapons entries with _Primary don't have evt associations.
I guess weapons and soldiers not doing anything don't need to make sounds.

[Casuir]

Aye and a lot of them would make the same sounds, looking at the engine evts a few of them are blank, if the game requires the evt files to run then theoretically you could get away with copying these and renaming to the required names. I do think they're packed in the skeleton.dat file sans headers, theres definitely stuff in there that matchs up with bits in the events.dat

[Casuir]

Mkay, just been reading some of the old threads on rtw animations problem and hoping someone can explain this a bit better to me, .evt files are missing and the game wont run with the animations extracted because of this? Looking at this post by Jerome it seems the evt files are in the skeleton.dat and this has been known for some time. Vercs extractor doesnt extract them though so I'm wondering if this is an oversight or theres some other problem.
https://forums.totalwar.org/vb/showp...0&postcount=13

Heres the relevant part of skeleton.dat

First byte in yellow is the number of entrys, next byte in purple is the sound catagory, I've identified 01 for SOUND, 02 for SOUND_BANK, 04 for SOUND_VOICE, 05 for SOUND_AMBIENT and 03 must be shockwave, doesnt seem to be any of those types in it though. Next bit in green are the start and end frames in green, followed by the lookup tag. Theres an 00 01 after some entries here which isnt always present, Im guessing this is used to identify the sound as random? Theres also a looping tag in some of the evt files in the effect_evt folder

[KnightErrant]

@Casuir
I've unpacked the cas's in pack.dat and the game won't run
with these alone using the no_animdb = true switch that Caliban
told us about. The jpg of his unpacked /animations directory showed
evt files present so I'm wondering if this is required but I don't know
this. We know that skeleton.dat ISN'T unpacked on his system because
he didn't find any of the type names present for any file extension.

Not really a big problem because its easy to repack the cas's after
modifying them, it's more of a "if it can be done then try doing it" thing.
GrumpyOldMan suspects that the no_animdb switch may not be present
in the retail version and that could very likely be the case.

Missed your post re strat_navy and fs_camel. These are the handles
or type names for different groups of animations. They extract out of
skeleton.dat just like the cas's come out of the pack but they don't
seemed to be used that way. That's why I asked for the experiment
to be done, to see if they were really filenames or just handles like
GrumpyOldMan thought. (I picked those two because the corresponding
cas's aren't named that way, so we could avoid a bunch of false hits
to have to sort through.)

Thanks for digging up the old post by Jerome, there's some food for
thought there. I'll to dig again with this new info.

[GrumpyOldMan]

Hi KE

@GrumpyOldMan
Ok, got a reply from Caliban. He did the two experiments and none
of those "type files" or "skel files" exist with his unpacked setup.
So I think skeleton.dat/idx is supposed to stay packed and those
names are just look-up handles like you said. Looking at events.dat/idx
right now since Caliban had them unpacked. There's no names in
the index file so I think events and pack have to be unpacked together
since the .evt always matches the .cas path and filename. However,
the mapping is onto but not 1-1, not every cas file has a corresponding
evt file. If I'm seeing the header right, there's 1000 evt files for 2400
cas files.

What we really need to see are a few examples of unpacked .evt files. The .evt files look like this in the skel .dat files :-

short - num of variations
short - 0
int - code for 'sound' type??
short - start frame
short - end frame
0 termed string - description/look up table entry??(some different cas use same event - explains number discrepancy)
then usually 10 bytes with 32 00 sometimes appearing and sometimes the start and end frame reappearing.

If we could get a hold of the evt files for one figure we could make a fist of decoding because the 'no_animdb' is sure not working without them. I'll ask Caliban and see if he can help.

I believe now that the two idx and dat files are made up from the folders within animation and that the skeletons we've been so intent on don't really exist. This is bad news for the fantasy people because this means that the skeleton positions are hardcoded and are added in at compiling those idx and dat files.

Cheers

GrumpyOldMan

[SigniferOne]

Guys, Jerome provided all of the .evt files for RTW 1.5, but putting them into the extracted animations folder, so they'd match up with their corresponding animation files, still didn't work, and still crashed. So, Caliban will really have to babywalk us through here, because Jerome spent a lot of time trying to get it happen for us in RTW, and it didn't work, in large part because I think the TW engine is not so successful at loading animations when extracted. It works wonderfully for other files, which don't have to be in packs, but seems to still be a buggy process with animations, and they have to be packed, unless Caliban's animdb switch was truly made to work this time.

Just briefly, if animations have to be repacked, does this mean descr_skeleton.txt is still pretty irrelevant as a file? The one inestimable advantage of getting unpacked anims working is that descr_skeleton.txt would become important, and then we could do a lot of stuff with animations that couldn't be done otherwise.

[GrumpyOldMan]

Hi SigniferOne

Guys, Jerome provided all of the .evt files for RTW 1.5, but putting them into the extracted animations folder, so they'd match up with their corresponding animation files, still didn't work, and still crashed. So, Caliban will really have to babywalk us through here, because Jerome spent a lot of time trying to get it happen for us in RTW, and it didn't work, in large part because I think the TW engine is not so successful at loading animations when extracted. It works wonderfully for other files, which don't have to be in packs, but seems to still be a buggy process with animations, and they have to be packed, unless Caliban's animdb switch was truly made to work this time.

From what Caliban is saying it seems that if no_animdb switch works (and we won't know that until we have the .evt files in place) the skeleton and pack idx and dat files are rebuilt on start from the descr_skeleton.txt file, and then the engine uses those repacked files.

Just briefly, if animations have to be repacked, does this mean descr_skeleton.txt is still pretty irrelevant as a file? The one inestimable advantage of getting unpacked anims working is that descr_skeleton.txt would become important, and then we could do a lot of stuff with animations that couldn't be done otherwise.

I don't think from what Caliban says that we'll be able to work with unpacked files, we'll just use them to create new idx and dat files. It was possible in RTW to get new skeletons and animations in and I think that eventually we'll be able to do the same, but in the meantime its fun to play with it

Cheers

GrumpyOldMan

[SigniferOne]

Hi SigniferOne



From what Caliban is saying it seems that if no_animdb switch works (and we won't know that until we have the .evt files in place) the skeleton and pack idx and dat files are rebuilt on start from the descr_skeleton.txt file, and then the engine uses those repacked files.



I don't think from what Caliban says that we'll be able to work with unpacked files, we'll just use them to create new idx and dat files. It was possible in RTW to get new skeletons and animations in and I think that eventually we'll be able to do the same, but in the meantime its fun to play with it

Cheers

GrumpyOldMan

Ah right, if the game recreates the packed files is fine, as long as it reads from descr_skeleton.txt and lays my fears to rest :P

[Casuir]

Looking at verc's extracted .cas's they seem to differ a bit from the engine animations and some cas's in unit_models/weapon_testing which look to be animation files. I think whats happening is the .dat has compressed cas's, verc's extractor is extracting them in a format readable by his max script but not by the game, which causes it to crap out. Any chance Caliban could provide an animation thats actually in the pack?

[Casuir]

Guys, Jerome provided all of the .evt files for RTW 1.5, but putting them into the extracted animations folder, so they'd match up with their corresponding animation files, still didn't work, and still crashed. So, Caliban will really have to babywalk us through here, because Jerome spent a lot of time trying to get it happen for us in RTW, and it didn't work, in large part because I think the TW engine is not so successful at loading animations when extracted. It works wonderfully for other files, which don't have to be in packs, but seems to still be a buggy process with animations, and they have to be packed, unless Caliban's animdb switch was truly made to work this time.

If you re-read what the man said at the time the problem actually lies with vercs .cas extractor. He got it working perfectly with the original files and a retail version of the game, so the problems on our end, not theirs. Verc missed the ball on extracting the evt files from the dat, so its not implausible that something else is getting borked.
https://forums.totalwar.org/vb/showt...ighlight=bones

@gom, theres evt files in the animations/engines folder, not the exact same as the ones missing but you should be able to get the header and file structure from them.

This thread might be of interest as regards the skeletons
https://forums.totalwar.org/vb/showthread.php?t=53763
Be nice to if caliban could confirm that the skeletons are hardcoded, how does the engine know which one to use for a camel and for a man?