Forum > Modelling and Animation

[SOLVED] Playable Animations Lookup ?

<< < (2/3) > >>

schlumpf:
animkits, it seems. I have no idea how they work though and didn't understand for four hours.

spik96:
Thanks anyway Schlumpf.
Hmm AnimKits, where did you get that name from ?

If there is absolutely no way I'll just make a function where it assigns the "most suitable" animation for an action.

I think the playable lookup doesn't map directly from the global animation list like the wiki says but from the animation lookup, which still exists today and is used as a link between "physical" positions in the global animation list and Animation List and their ID. The Playable lookup then link between IDs and real actions, there are always 203 of them.

Sometimes I see the model don't even have the AnimLookup anymore (it's just a 0..) but it's easy to create it (its length is max{AnimIDs}+1 and then you go through the Animations and then AnimLookup[AnimID]=current "for" Index.
When it's done I could make the mapping..
Example for Drowned (AnimID 132 in AnimationData.DBC) :

--- Code: ---//First I make an int array with valid (Not == -1 in Anim lookup) AnimIDs in it
//then I start to map
if(131 in AnimIDs){
    ID=131;//131 is Drown
} else {
    ID=0;
}
Flag=3;//3 means Freeze which is what happens with Drowned as you don't move after

--- End code ---

It would be a bit artificial as it was originally done by hand but it would works...

schlumpf:
I got that from the client. The animations/animkits are hardcoded in looting.


--- Code: ---void CGUnit_C::UpdateLootAnimKit (int desired)
{
  uint current_state = this->current_anim_kit ? this->current_anim_kit->GetID() : 0;
  uint new_state;
  if ( this->IsLooting() && this->ShouldKneelForLoot() )
  {
    new_state = (desired == 0 && current_state > 203) ? 204 : 202;
  }
  else
  {
    new_state = current_state == 202 ? 204 : 0;
  }
  if ( current_state != new_state )
  {
    if ( this->current_anim_kit )
    {
      this->current_anim_kit->SetStopCallback (0LL, 0LL);
      this->current_anim_kit->Stop (1, 0LL);
      this->current_anim_kit->Release();
    }
    if ( new_state )
    {
      this->current_anim_kit = this->animKitManager->PlayAndMaintain
        (new_state, (ANIMATIONDATAENUM)-1, 0LL);
      if ( this->current_anim_kit )
      {
        this->current_anim_kit->SetStopCallback
          (&UnitCallbacks::LootAnimKitStopCallback, this->field_2050);
      }
    }
    else
    {
      this->current_anim_kit = 0LL;
    }
  }
}
--- End code ---

spik96:
A decompiled client... you're cheating x). I wonder how they haven't leaked on the Web somewhere.

Okay so they probably hardcoded it in LK as they realized the logic was always the same for each model.
There is also probably a "death" function too handling death and drowning (they are the same but with different flags, like for loot) and other actions with similar mechanics.
I should have no difficulty to reproduce this logic with the method I described a bit above.

Thanks a lot.

schlumpf:
Seeing as I spent about 5 hours to get to the point of being able to show you that code with confidence, I don't think it qualifies as cheating too much.

In addition to hardcoded animkits, there is also fallbacks for some in dbcs: flystand, flyhover, flyshuffleleft/right, flymount, flyfly, flydrown, flydrowned, open, close, opened, closed.

Other hardcoded kits contain mountride, some on charselection, looking at something, something for spell effects (81 and 125), wheels (139Fh, 13A1h, 13A2h, 13A3h, 13A4h, 13A5h, 13A6h, 13A7h), movement (29h, 29h, 2Ah, 2Ch, 2Bh, 2Dh, 12Dh), combatReady (56h, 8Dh, 8Eh), standState (0B5h, 0B6h, 0B7h, 0B8h, 0B9h, 0BAh), emotes (4B7h, 4B6h, 0CDh, 0CEh, 550h, 54Fh, 54Dh, 54Eh), raid markers, … and really a shitload more.

Navigation

[0] Message Index

[#] Next page

[*] Previous page