Modding Rundown: Animations

[thetommyboy2002]

Another bit of lateral thinking:
I can export an animation file with 20 or 50 animations in it, but the game thinks they are all one, and just plays them all, one after another.
Is there any way in the powerset (or anywhere else) to specify what part of an animation plays?
Can you say "play from half way through?" or "only play the last 2 seconds"?
If we could specify this its simple to get a list of the length of the animations in the mega-animation file, and then if we want "power22" we say "play 1 minute 32 seconds to 1 minute 34 seconds", and get the animation we want.
Am I making sense?
So my animation goes:
Time                      Name
0-4seconds      menu_idle
6-15 sec           pain
20-33 sec         run
36-39 sec         attack_light1
43-47 sec        power2
and then we tell the powerset (or a custom script maybe)  for "eapower2" play 43-47seconds from 01_tom.igb....somehow.
I haven't got a clear concept of how, but I've done similar in another game and it worked there, though it's very far from ideal...

And thinking about it and looking at a powerstyle file, it's not a great idea, unless we want to rewrite the way animations are handled in the game more or less from scratch..

[BLaw]

You just define 01_flash in the packages and the herostat. The game will load that file.. and every other file that has 01_flash hexed in it. If you wanna play safe, define the other flush flesh etc in the packages too. Won't work for the herostat though. I think ><'

This is the same with skins. That's why there's a skinswap conflict on custom models if you do not give it internal numbers but you did swap it for an existing one. The game relies on the identifier numbers which can be found with a hexeditor.

That's the reason why I had the idea.

[thetommyboy2002]

You just define 01_flash in the packages and the herostat. The game will load that file.. and every other file that has 01_flash hexed in it. If you wanna play safe, define the other flush flesh etc in the packages too. Won't work for the herostat though. I think ><'

This is the same with skins. That's why there's a skinswap conflict on custom models if you do not give it internal numbers but you did swap it for an existing one. The game relies on the identifier numbers which can be found with a hexeditor.

That's the reason why I had the idea.

OK walk me through as though I'm an idiot, one step at a time.
We are exporting one animation at a time, exporting to files called "01_flush.igb" "01_flesh.igb" etc.?
A different animation in each one, with a different animation name;"power_2", "idle" etc. put in the "animation name" field in "actor editor" each time, yes?
So what in the file has the "01_flash" part?
It can't be the animation name, can it?
Would a dummy part named "01_flash" be enough, or does it somehow have to be linked to an animation DB?

I just exported 3 files, each with the "main" animation named differently (menu_idle, menu_goodbye and run).
In each there is a second actor called "01_flash"linked to a second biped, and it's animation name is "01_flash".
So there should be an "01_flashDB" and an "01_flash", plus at least one "01_flash" object (the actor named 01_flash).
I named each 01_flush 01_flesh etc., copied into actors, and only the original menu_idle one, (which worked anyway and is named 01_flash) worked.
If I renamed 01_flash to 01_flosh it doesn't work.

Am I missing something obvious here?
They all have "01_flash" and "01_flashDB" entries if opened in a hex editor. Not that that means much, as we know, but I'm just mentioning it.

[thetommyboy2002]

What I thought a bout your idea is this:
Each powerstyle power entry could look like this:

Code Select Expand



   FightMove {
   animenum = ea_power7 ;
   icon = 10 ;
   is_power = true ;
   lockangles = true ;
   name = power7 ;
   priority = 5 ;
      require {
      cat = skill ;
      item = flash_p7 ;
      level = 1 ;
      }

      trigger {
      name = runscript ;
      script = common/swap_in_power7_anim_file.py ;
      time = 0 ;
      }


The lengthily named script could copy an "01_flash.igb" from a subdirectory, overwriting the one in "actors".
This version of 01_flash would just have one animation, called "power_7", and the animation would play when called (I hope).
The next power used might be power 6, that runs a script to copy in the "power_6" version of 01_flash, and so on.
Whatever animation is required by a power, the script copies in the version of 01_flash which contains that power.
It's pretty simple, and worked for models in the mandarin script. I think it might work for powers.
I'll try a proof of concept test tomorrow.
In fact, this could be used for existing animation sets too. You could just overwrite 01_flash with a renamed 07_captainamerica or 01_wolverine or whatever had the animation you wanted.
If it does in fact work. Big if.

[BLaw]

Big if.

OK walk me through as though I'm an idiot, one step at a time.
We are exporting one animation at a time, exporting to files called "01_flush.igb" "01_flesh.igb" etc.? - YES
A different animation in each one, with a different animation name;"power_2", "idle" etc. put in the "animation name" field in "actor editor" each time, yes?YES

The filename has to be found in each skeleton aswell. In this case, we have for example three skeletons:

- 01_flash
- 01_flesh
- 01_flush

Flash is the name of the character. So you'd have to hexedit the three files and insert "01_flash" because THAT is the file that we normally want to contain multiple animations but the exporter does not allow it (as stated in the alchemy documents).

Fortunately, the game depends on internal numbering and internal names. Short story: we give each file that we named differently the same internal name.

HOWEVER, the problem is: what in the world do we need to change into the internal name???

For skins it's "igActor01Appearance". For animations, I do not know. It might be "igActor01AnimationDB", but it ain't "igActor01Animation"  because it's the name of our animation.

[thetommyboy2002]

Quick check of my script idea reveals two hurdles:
1. the mandarin code used "setskin" not copying.
2. I think you have to restart to load a new set of anims.

Maybe editing the herostat on the fly to look for different anims would work better?

[thetommyboy2002]

Back to your idea, I've looked in a hex editor at Blades anim files.
Each has "01_blade" or "01_blade_4_combat" entries, as you'd expect.
They also have "01_blade_skel" or "01_blade_4_combat_skel".
Now, looking in one of my "only one anim works" exports in the finalizer we find "igActor01Skeleton", and this is actually a name, so in the file where I named an actor "01_flash" theres an "01_flashSkeleton".

Also potentially interesting, under the "animationList: igAnimationList" section in finalizer, we have "_tracklist:igAnimationTracklist".
And elsewhere I see "igAnimationCombiner" which is what our plug-in doesn't do, but maybe the exporter can, if the plug-in script were altered?

Anyway, sleep now..

[thetommyboy2002]

Fun with Finalizer, part one.
So, I export an 01_flash.igb.
It contains 4 bipeds, linked to igActors 1-4, each with its own animation name (menu_idle, menu_goodbye, walk run).
It also contains a 5th igActor called 01_flash, which has an animation name of 01_flash. No particular reason for this in this experiment, but it is in there, anyway.
The export only plays menu_idle in-game.

Now, if I open up 01_flash.igb in the finalizer, this is what I see (expanded view to the right, with arrows to show what I've expanded):

We can see our 5 actors(igActor01 to 04 and 01_flash), and our 5 animation databases ("menu_idleDB", etc).
The expanded view on the right looks at whats in one of our 5 actors and one of our 5 animDBs.
Note the structures present in Actorinfo, and after the "=" my comments and ideas:
name= self evident
_actorList= again seems pretty obvious
_animation database= seems to link directly to the "igAnimationDatabase" entry, as you might expect. More on this presently..
_combinerList:igAnimationCombinerList(1 object) = Ooo! Interesting. This is what our plug in in Max cannot do. Note for later...
_appearanceList = I think this is to do with textures and lighting effects. I don't think it pertains to animations at all.

Now the structures of IgAnimationDatabase, AKA the good stuff. Again my comments and ideas follow the "=" :
_name= self evident
_resolve State:true= no idea
_skeletonList= links/leads to "igActor04Skeleton" which in turn has a list of all the biped bones in that skeleton.
_animationList:igAnimationList(1 object): that 1 object is of course "menu_idle". If you right click on this and select "edit object fields" you can see "igDataList::_count" with "1" in the field,
and "igDataList::_Capacity" with "1" in the field. I've edited the "capacity" to "10" and it doesnt seem to mind. Editing the "count" gets you a crash to desktop, so maybe dont do that for now.. I've saved the "capcity=10" version and it plays exactly the same in game, so now I have an anim file with an animation list with a larger capacity. My goal is to get those other animations in the file into that list, somehow.
_skinList= dunno links/leads to the actor, then the biped and light linked to the actor. No idea if its significant to us.
_appearanceList= dunno again
_combinerList:igAnimationCombinerList(0 object)= Ooo! again. A right click>edit fields on this can get you a "capacity" of 10 if you like, but dont edit the "count" unless you want a ctd at this point.

So, lots of exciting and intriguing stuff there, though I dont really understand much of it.
Now lets divert our attention to the other view available in finalizer, a kind of "schematic" view, if you will:

In this pic we can see our scene root and all our actors, with a couple having their views expanded to show the nodes beneath.
Following the chain down gets you to the biped bones which are linked to each actor, which is of little interest to me presently.
One thing I thought might be worth trying is right-click on the igTransforms them selves and you get a menu, one of choices therein is "move item to new parent".
I did this for all the igTransforms making the 01_flash one the "parent" of them all, then saved, hoping this might get the anims of each to be read as part of the animationList of 01_flash. It did not work.
But maybe something like this will. Or editing one of the fields in this view or the pictured first "tree view" can get us to somehow link our other animations with the one working one.
Or figuring out the "combineList", if that is what we need.
The point is, with the finalizer we/I can fiddle about with the file till we get one of those other animations to work too, and its a bit easier to see what we are doing than hex-editing, and a bit easier to understand than random blind trials in Max.

Not that I'm dismissing your other idea of 01_flesh etc, but have had no luck there and thought maybe looking at the file would reveal where we can put the "01_flash" label you think we require to get the anims read by the game. The big advantage of doing that in the finalizer is unlike a hex editor, you can alter the length of names without it ruining the file.

More when I have more...

[BLaw]

Well 01_flash is shorter than any entry. The problem still remains: what do we have to change into 01_flash. And will it work or not.

[thetommyboy2002]

OK this IS interesting.
I do my standard "menu_idle" works export.
It works in-game, and I see the menu_idle animation, etc.
I then open up the 01_flash.igb in the finalizer and edit the "igActorInfo("igActor04") > "_animationDatabase:igAnimationDatabase("menu_idleDB") sub-entry to read "runDB" instead.
I save and run the game.
He's still doing menu_idle, not run.
So I open the file up again and edit the sub-entry "igActorInfo("igActor04") >"_animationDatabase:igAnimationDatabase("menu_idleDB") > "_animationList:igAnimationList(1 object)" > "igAnimation("menu_idle")" to read "run", and save.
This time he does the animation as a run not a menu idle.
So this tells us the "whateverDB" entry is not used by the game to figure out when to play the animation, the "igAnimation("whatever") is the one that does that.

So since the "_animationDatabase:igAnimationDatabase("menu_idleDB") is not doing anything, maybe there is our "01_flash" point.
EDIT: nope, either that's the wrong spot, or the concept is flawed.
Well, theres a few other places to try it, so I will, as I fiddle about trying to understand the inner workings..

And a bit more light is shed:
if in the "schematic" view, I delete "igTransform:igActor04" and all it's descendents entirely, the menu_idle still plays. So that view seems to largely deal with the "scenegraph", I think, ie the actual objects and textures in the scene.
In the "tree view", the "igTransform:igActor04" and sub-entries is now gone from the "igSceneInfo("Scene Graph")" entry, as you might expect.
Worth knowing that although connected in some ways, the "schematic view" seems to not affect the "igAnimationDatabase" stuff we want to play with.

[thetommyboy2002]

Oh, and if I make no changes at all in Max, just export the igb, all the "object pointer" numbers (the 0x0115a444 type numbers at the end of entries) change, and change every time, as far as I can see.
Heres two exported without change about 30 seconds apart:

Bear in mind thats the exact same 01_flash.igb.
Now whether the changes are because system memory shifts and changes on my pc as programmes run and do stuff, or maybe the exporter just randomly jumbles stuff up. I dunno.
Here's two identical exports in the hex editor:


So that explains perhaps why so often examining files in a hex editor it seems really difficult to find similarities.

[thetommyboy2002]

Well, you can't say I haven't made a start:

It's effectively non-functional at the moment, but I'm learning as I go, so maybe in the next few days.....

[thetommyboy2002]

Still working on the actor editor script. I've now got to a point where I can create an actor from an selected object which does not appear in the actor rollout. Unfortunately it doesnt yet appear in my "actor2" rollout either. It also has no animation attached to it and has different properties in the finalizer. But it's still a sort of half-step forwards.
Anyway, I'm not here to post about just that:

I stripped my default export down to just 2 bipeds and 2 actors to keep it as simple as possible for when I'm trawling through the export in finalizer or a hex editor.
No geometry or lights, just 2 actors, 2 bipeds, exporting 2 animations only one of which the game plays.
Anyway, the default playing animation remains that of "menu_idle".
But today I find that by editing "igActorInfo("igActor04") > "_combinerList;igAnimationCombinerList(1 object)" > "igAnimationCombiner("combiner_igActor04")" and change "igActor04" to "igActor03" it now plays the 03 anim, the "run" during "menu_idle" anims!.
To clarify, the "combinerList" seems to assign the actual actor whose animations get played, the "animationList" assigns the in-game animation name.
So if I set "animationList" = menu_idle and "combinerList" = actor04(which is the "menu_idle" anim in my export) then in-game my "menu_idle" anim plays in the menus
If I set "animationList" = run and "combinerList" = actor04(which is the "menu_idle" anim in my export) then in-game my "menu_idle" anim plays when running
If I set "animationList" = menu_idle and "combinerList" = actor03(which is the "run" anim in my export) then in-game my "run" anim plays in the menus
If I set "animationList" = run and "combinerList" = actor03(which is the "run" anim in my export) then in-game my "run" anim plays when running

And bear in mind the "combinerList" appears under "igActorInfo" where it has "1 object", and is not the same as the "combinerList" which appears under "igAnimationDatabase".
The one under "igAnimationDatabase" has "0 object", which is possibly something we want to change, though as yet I'm not sure how. Simply editing the fields available in finalizer allows only altering "capacity" which seems to do little, or "count" which continues to CTD the finalizer.

God, how I wish I could open up just one of the games animations in the finalizer, it would clarify the structure so much..
True, it's still only one anim playing, but I'm starting to figure out what does what, and be able to list it all.

[thetommyboy2002]

Trying a parallel, slightly different approach to the actor editor script:


The other one I'm trying tries to add a second Actor to the rollout in the hopes that it too gets exported along with the original one. Somehow. But I'm not sure that approach makes much sense. We are already exporting other actors and their animations, but they just aren't "seen" by the game.

So I started thinking about maybe only one actor but it has multiple animations attached. Somehow.
Getting the extra fields for the other 2 anims is relatively easy, and as you can see above, you can enter animation names all you like, but only the top one gets exported, theres no sign of the other 2 in the export. So far.
More when I know more...
Edit: although the second and third animation names seen in the above pic make no appearance in the finalizer (that i've found so far), they ARE in the igb, visible in a hex editor. So that's something...


I should add that it does occur to me that it's maybe a limitation of the igb exporter DLL (or dlu or dle) rather than the scripts, but that's even more of a black box. I mean, I can disassemble it easily enough, but reading raw assembly code is a wee bit beyond me, I'm afraid..

[thetommyboy2002]

OK, I found my added "animation names" in the finalizer.
They are under a "igHashedUserInfo("igActor01") entry/node/thing, in the scenegraph info, pretty far away from where I want them.

Now with my other Actor Editor attempt at adding a second actor, the weird actors I could create also showed up as "igHashedUserInfo" something or others, rather than the standard "igActors".
What this means, I'm not sure yet.
It's good news in the sense that I'm actively adding new stuff to exports via my edited Actor editors, and that stuff shows up in the finalizer and hex editor.
It's slightly less good news in that my additions dont seem to be in a "proper" format, and don't alter how the animations work in-game at all.
If I actually knew what I was doing here, I might be able to do this more quickly or know if it even can be done. But we are where we are.