What I am saying is that that list is largely useless because many of the events that can be registered for will never actually trigger an event.
Because there are a few type of event. From my understanding, they are:
- Trigger Event:
which can be used to initiate animation. So you can use Debug.SendAnimationEvent on- Transition Event:
which event being sent when conditions are met. IE: when you are playing attack animation, and got shield-bashed to the face, you will receive 'staggerStart' event. In this case, 'staggerStart' is Transition Event and Trigger event at the same time, which results in you playing stagger animation- Listening Event:
events which are being notified when animations play or change states. These animations event are mostly tied with the underlying code, like 'hitframe', so you know when to calculate damage, when attack should hit, etc.... Or serve the purpose of scripting/Quest. These are only type of event you can RegisterForAnimationEventDepend on what animation state the actor/creature is on at that moment, some events work and the other become useless. Or some animation events are deemed not to much important to be 'Listening Event' by the dev and hence there is no need to make them Listening Event in the behavior files. Such unimportant events are mostly creatures' behavior.hkx , unfortunately. Most events you can RegisterForAnimationEvent are player/NPC's events, because they serve the purpose of quests/scripting
- Many events present in 0_Master get duplicated to race-specific behavior files, often with varying case i.e. footLeft vs FootLeft.
- 0_Master sometimes contains events that will fire for a given race but are not present in that race's own behavior file.
- There are many races that have animations not present in 0_Master.
- Whether an animation is present in 0_Master, the race behavior or the Idles tab is not an indicator of whether using RegisterForAnimationEvent actually results in an event being triggered.
For 1. & 2. & 3. I think you can somewhat read the xml, so you know a bit of programming, yes? 0_Master is what programmer call 'Abstract Class', which provide a 'general code' for other classes to extend on. So to use a 'parent' events on a 'child' object would not work sometimes as the 'child' class might have different implementation or override 'parent' event in some way (again, in different animation states)
- Horses use an almost identical animation event list to other quadrupeds, but they do not fire the syncleft and syncright events, despite being present in the file and other quadraqeds (and mudcrabs(!)) doing so.
Yep, they have pretty much the same list of animation event, but how these events being used are not the same. As horse and other 'quadripeds' have different behaviors (in common sense, a horse is a horse, right? Not ... other quadrupeds) so they would behave differently, and have different states, different .... walks animation, different behaviors in general, not just footleft, footright, syncleft and right as you suggested
To sum up, they have different animation states, so animation register-able for a horse might not work for the others
- Most enemies have a Ragdoll and RagdollInstant event present in the Idle Animations tab, but they never fire. Instead, when an enemy is ragdolled (not killed), "RemoveCharacterControllerFromWorld" fires. That event is not listed in Idle Animations, only in the behavior files.
RemoveCharacterControllerFromWorld is 'Listening Event' as I described above, not triggering event. It mostly tell when an actor is entering ragdoll mode
- Giants have combat and warning idles where they shake their club and yell at you. Although you can force them to do that with SendAnimationEvent or even PlayIdle, the event associated with that action NEVER fires. Instead, only the event at the end of the taunt fires, aggroWarningStop.
Because they are different event types as I described above.
For your information, I looked into Giantbehavior.hkx, and have to tell you that there is no way for you to detect different giant's attack. Unless you define new Listening Event in each attack
I hope you understand now why it is not just as simple as "looking up" the relevant animation events.
I think I misinterpreted my point. 'Looking up' doesn't mean you just check the complete list at the begin/end of the behavior, but you have to read the corresponding state/animation for events you want. This way is much faster than trial/mistake for thousands of event as you did
» Tue Nov 20, 2012 3:55 pm 
Lucky me. Thanks again!
)
