 |
[untested] PlayAnimationTask and PathCycleAnimTask have the same set-up and probably share the problem |
|
|
Best fix is to move the job of starting the animation from the c++ code to the ai AnimState scripts, ai_darkmod_base::Torso_CustomAnim and Legs_CustomAnim. The other AnimState scripts all start their own animations, which is why they can do the things above in the right order. Nothing else uses those script functions. These tasks can use the same setup. |
|
|
These scripts (ai_darkmod_base::Torso_CustomAnim and Legs_CustomAnim) are used only by those 3 tasks in the Game c++ code. No scripts in the core mod or published maps use them. To implement this fix, the scripts need to know what anim to play, but those tasks use different spawnargs and have their own record of what to play. So to minimise disruption to the existing setup I propose to get the tasks to set 2 keys on the Actor, specifying the required anim and whether to cycle, and the script events will read those keys. The other animState scripts interpret spawnargs to find out what to play too. PlayAnimationTask is used by conversations, and the state subsystem. I'll use a conversation in the test map. |
|
|
Hmm blend_in not being used isn't the whole of the story. Something is actively kicking the animation out of kilter for the path anim tasks but not the play anim task. |
|
|
The second bug is that the legs channel is being sync'd to the torso by the two path tasks without any blending. That means that if the legs are playing a different anim from the torso when the task starts, the legs anim is being lost in a single frame. |
|
|
A side-effect of this fix should be that scripts will finally be able to play anims without those anims getting interrupted by idle or patrolling anims, by setting the keys and calling AnimState(ANIMCHANNEL_TORSO, "Torso_CustomAnim", 12); etc. Wants testing then wrapping in a more user-friendly script function. |
|
|
A problem with the fix: frame commands are now being called on both anim channels. Sync'ing the anims channels is supposed to take care of that. |
|
|
The sync is happening before the animations are starting, because the AI scripts post PlayAnim as an event, and the c++ code is running the sync before the events get processed. Putting the call to SyncAnimChannels on the event queue with zero ms delay doesn't work -- it still gets processed before the PlayAnim events. Giving it 16ms (1 frame) delay works 80% of the time, but it can still fail. And it risks a double-call of a frame command for any anims that have a command in the first frame. |
|
|
Moving the Sync call to the scripts doesn't help. Still getting duplicate frame commands, saying to destroy attachments spawned by an anim. Either script events can fire out of sequence, or something else is intervening to re-enable the frame commands on the legs channel. None of the script events seem to do a deferred hand-off. UPDATE: the commands probably aren't out of sync. The second option was true: something else was fiddling with the setting: |
|
|
It was the new AI LOD transition causing the duplicate frame commands. Testing this issue has revealed a subtle bug in the animated LOD setup: the LOD code does a model swap and restores same-named anims at the right frame, if the md5 skeletons are compatible. But it needs to restore more than that: whether or not an animation is allowed to fire off frame commands, for example. That parameter is private to idAnimBlend right now, so I've added an accessor FrameCommandsAllowed() so that the LOD code can see it and restore it. I'll add a child issue to the AI LOD tracker to add a LOD copy method to idAnimBlend, so we can transfer the rest of the flags with LOD too. I suspect most are not used, but even if so they might be in future. |
|
|
Committed at rv6094 (code) rv13974 (script, binaries) |
- Anonymous
