AoP / CoAS animations in PoTC

[Grey Roger]

So, the new model worked well enough when used for a player character. He didn't work so well when I played my "Ardent" storyline, boarded his ship and went to duel him - the display went berserk as usual for a faulty animation. I tried putting commands into "console.c" to spawn him near me and make him attack me so I could try to fix the problem, except that there was no problem here - he appeared correctly and duelled properly. The problem only seemed to appear during the actual boarding.

The "Devlin" model in "initModels.c" has the attribute 'model.status = "C_III";'. That attribute is checked in boolean function "StraifCharacter", defined in "PROGRAM\seadogs.c". "StraifCharacter" is used to check if a character has the animation for a sidestep, and if so, to use it. It's also used in function "Character_PostInit", defined in "PROGRAM\Characters\characters.c":

    if(!CheckAttribute(rCharacter,"model.animation") || rCharacter.model.animation == "")
   {
// changed by MAXIMUS [for AOP models] -->
       if(rCharacter.sex == "woman")
       {
           if(StraifCharacter(rCharacter)) rCharacter.model.animation = "new_woman";
           else rCharacter.model.animation = "towngirl";
// KK -->
           rCharacter.model.height = WOMAN_HEIGHT;
           rCharacter.capacity.max = WOMAN_CAPACITY;
// <-- KK
       }
       else
       {
           if(StraifCharacter(rCharacter)) rCharacter.model.animation = "new_man";
           else rCharacter.model.animation = "man";
// KK -->
           rCharacter.model.height = MAN_HEIGHT;
           rCharacter.capacity.max = MAN_CAPACITY;
// <-- KK
       }
// changed by MAXIMUS [for AOP models] <--
   }

It's checking the character, not the model, for the "model.animation" attribute, and if that doesn't exist, it assigns one by default - not necessarily the correct one for that character's model. For one thing, I'll probably want to replace "towngirl" with "woman_sit" as that is the animation now used for almost all female models. As for the admiral, the quickest fix is to add a "model.animation" attribute to his character definition. For a quick'n'dirty fix for the game in progress, I added it to his character with a console command. And now:

Success!

To check that I've understood this correctly, I looked at a few other models with non-standard animations. Several have the 'model.status = "C_III";' attribute set, but those use either the "Blaze" or "new_man" animations, and they're identical, which means characters using those models will be fine when "Character_PostInit" assigns them "new_man". There are no female models with the attribute, so none are going to be assigned "new_woman". But model "33_Blazie" uses animation "33_Blazie.ani", which could cause trouble, except that characters defined to use that model have the "model.animation" set. This confirms that setting the same attribute for the admiral character should solve the problem. (Though it doesn't answer the question about why "Character_PostInit" only assigned him the wrong animation during the boarding scene...)

 

[Pieter Boelen]

Sounds like wonderfully messy coding again.

It could probably be updated to check the character model array instead, but I remember the code for that wasn't as simple as I'd prefer...

 

[Grey Roger]

Presumably there's a reason why "Character_PostInit" checks the character rather than the model. I can probably knock up some code to make it check both - if it can't find "ch.model.animation" then find "ch.model" and look for the model's "model.ani", and only assign a default if it can't find either. But as the current code works (provided that characters using non-standard models have the "model.animation" line), I'll leave it until after the new installer is out. I have, however, replaced "towngirl" with "woman_sit" as the default animation for female characters.

 

[Pieter Boelen]

Presumably there's a reason why "Character_PostInit" checks the character rather than the model.

Because that's easier to code...?

Though that particular function IS quite an intensive one, so keeping it simple is probably better for performance.
Sounds sensible enough to leave it as-is for now.