Missing AnimationEnd events??

[Qviddhartha]

Working on a mod that makes intensive use of SL animations and I am encountering a number of issues: (1) actors dropping out of animations, (2) actors stuck in animation loops after the animation is done, and most importantly, (3) I seem to be missing some global AnimationEnd events (but NEVER AnimationEnding events).

 

I figure (2) and (3) are related... to some defect in how SL handles thread resets.  I do get most AnimationEnd events and all AnimationEnding events.  It seems to happen mostly (if not exclusively) when I go through load doors while the animation is playing but I am unsure on this point.  Strangely, most of the time the SexLabAnimatingActors faction is correctly reset, but sometimes not.

 

The first issue (1), actors dropping out of animations, looks like an AI issue.  It mostly affects actors running my custom AI and it may be related to state transitions within my AI package that are causing spurious animation events to be sent to the actor.

 

Can anyone provide information on these glitches, or at least a confirmation that I have the correct suspects?

 

At this point I am considering wrapping my animations in an extra quest in order to force an AI that just waits (procedure wait), and use a scene to double check for ending animations.  I feel like i am grasping at straws.

 

Thanks in advance,

 

PS: Using LE "SexLabFramework_v162_FULL(1).7z" version d2021.10.17

 

[Qviddhartha]

I have made some progress on these issues.

 

1) I could not dismiss the possibility that actors where removed from memory somewhere in the finalization stages, and so I added code to ensure this would not happen (though I have no evidence it actually was happening).

 

2) a careful review of the sslThreadModel.startThread code shows there are plenty of opportunities to have an "AnimationStarting" event and then nothing else.  I improved my handling of thread start failures.

 

I am no longer seeing missing "AnimationEnd" events.  But I still see plenty of botched actor resets and I am now thinking that some of the actions taken at this time are ineffective if the actor is not in an attached cell.   I am seeing actors stuck in animation loops, and actors that keep the SexLabAnimatingActors faction after the thread has reset.

 

If anyone has information that can help... please show yourself!

 

[Qviddhartha]

Oh well. I now have a better handle on the problem(s). There are two problems: (1) sendAnimationEvent does not always work and sometimes leaves the actor locked in a sexlab animation loop, though without a sexlab thread to drive it, and (2) the code that attempts to recover from this makes things worse.

sendAnimationEvent does not work under some circumstances... though I do not know all the details, it is clear and it is linked to the actor not being in an attached cell and/or not having 3D loaded. Knowing more precisely what the conditions are will be paramount to developping a full fix. My best idea at this point is to use a wide area cloak spell to detect actors that where added to sexlab threads and no longer are in a sexlab thread. Being seen by the cloak likely suffices to ensure the sendAnimationEvent will be effective (can anyone confirm?).

The sslActorAlias script tries to fix the missing sendAnimationEvent very clumsily, by doing it a second time when a new animation starts on the old thread. This is counter productive since there is little chance that the actor is now in a state to process the sendAnimationEvent if it was not in such a state when his animation ended. And if it is in an animatable state, it may already be in a new sexlab animation which will be disrupted by the attempted fix. Removing this "fix" in my sslActorAlias script completely fixed the issue I was having with actors dropping out of animations.

For the actors that are stuck in a loop, I have a partial fix, effective 95% of the time. I test whether the actor is in an attached cell when the AnimationEnding and AnimationEnd events are received. If their are detached, I mark them with a faction, and arrange for the sendAnimationEvent when they come in the players vicinity. The fix is not complete because my test is not precise enough to catch all the cases in which the sendAnimationEvent didn't work.

There is also a third problem... which I don't quite understand... but results in the actor finishing the animation normally but staying in the SexLabAnimatingFaction. It looks like a race condition in sslActorAlias where the code does "removeFromFaction, setFactionRank( 0), alias.clear()" but the last two get executed in the wrong order. Though the effect is real, my explanation sounds wrong.

[Fotogen]

On 10/5/2023 at 11:46 PM, pfB6cs said:

1) I could not dismiss the possibility that actors where removed from memory somewhere in the finalization stages, and so I added code to ensure this would not happen (though I have no evidence it actually was happening).

If Actor is not in an active cell, Skyrim can drop it. This is how Skyrim engine works.

 

If you try to use "droped" Actor, its easy to get a CTD. Its why mods do a lot of checking (.IsEnabled, .IsThis, .IsThat). As doing something with that Actor can generate CTD, your only options is to stop doing whatever you are doing.

47 minutes ago, pfB6cs said:

it is linked to the actor not being in an attached cell and/or not having 3D loaded.

Yes. Skyrim engine droped(unloaded) Actor. ObjectReference.Is3DLoaded() function is a common way to detect this.

 

Function SexlabFramework.ValidateActor() can also help. It checks for a lot of things (including Is3DLoaded). It also checks if Actor is not inside SL Thread, but is in SexlabAnimatingFunction.

 

My main point is, that you are not "fighting" SL, but Skyrim engine. Its a weird beast.

 

[Qviddhartha]

A Strange beast indeed, but once you unravel its workings it does work predictably.

The main problem in taming the beast is that there are a number of interacting components and no clear documentation. Identifying the proper cause of these glitches is not easy. At times I am grasping in the dark. I have made some progress, with RAM persistance, for example; I consider that "solved". I understand the causes, how to test for them, and how to work around them. Animation events are another story.

In any case, I am trying to add is3DLoaded checks to my current approach. We'll see if that's sufficient.

BTW, there are problems with SL... There are circumstances where it does not return to its normal base state before reusing a thread. I am also seeing cases where expected events don't fire, and cases of actors frozen in SL animation loops after the thread has exited. I am just still unsure how these behaviors relate.