Skyrim SexLab and VR

[Bolan]

EVERYTHING IS WORKING.
That includes: SL, SLAL, DD, DCL. Zaz, SL Aroused, Defeat (I think)
First off, I deliberately left DCL and associated mods off the mod list
Loot, FNIS, Bodyslide...
Run the game, new game
(Skyrim Unbound startup)

started in a city, went to the tavern

lots of usual MCM messages including DD registration
save/load
allow SL to completely load
customize all the mods the way you usually do
save / exit the game
add DCL related mods back in
Loot, FNIS, Bodyslide
start up Skyrim VR and select continue
allow time for everything to load 
should see new MCM menu registered (DCL)
customize DCL (I have my settings file imported)
If DCL doesn't respond on MCM just backout and wait
 

[Beef Cheeks]

5 hours ago, Bolan said:

Thanks thats really useful information. 

Btw make sure you install the Naked Dungeons SLIF+SLSO patch on top of the Naked Dungeons mod if you decide to use it. You really want to use SLIF for a lot of mods anyways...

[reikiri]

On 7/9/2020 at 11:29 PM, prinyo said:

@reikiri I have added a file from the patch in the Select NPC for MCM mod, maybe it is a better idea to incorporate this in the patch behind a check if the mod is installed to prevent future chaos for people who use it.

It is an easy and quick change - a 1 line of code that gets the crossref from a quest,

 

Ok, on a quick look at that mod, the version of VR patch MCM script you use is old enough it would already break the current released version of VR patch. You'll run into same issue with any other mods that get updated - although I suppose most of those aren't updated very frequently.

 

Anyhow, have you given thought for avoiding overwriting the files on mods, and instead triggering the actor select through functions the mods themselves use? For sexlab f.ex. you could do something like this:

----------------------

Function SetSelctedActor(Actor mySelectedActor)

    Form SexLabQuestFramework  = Game.GetFormFromFile(0xD62, "SexLab.esm")
    sslSystemConfig sslConfig = none
    if SexLabQuestFramework
        sslConfig      = SexLabQuestFramework as sslSystemConfig
    endIf

    if sslConfig
        sslConfig.OnCrosshairRefChange(mySelectedActor as ObjectReference)
        sslConfig.SetTargetActor()
    endIf

endFunction

-----------------------

of course, you'd want to create properties for the pointers (such as sslConfig) into script itself, and just search them once when game is loaded.. and then in actually selecting the actor, you'd call the

    if sslConfig
        sslConfig.OnCrosshairRefChange(PartnerReference as ObjectReference)
        sslConfig.SetTargetActor()
    endIf

and similar calls for any mods you'd be supporting through this. The advantage is, it's not very likely to break even if the mod is updated, and in the unlikely event that it does, it's likely just that your mod stops working for that particular mod.

 

I'm not certain if every one of the mods has a mechanism you could hook into like that, but the thing is in papyrus events and functions are pretty much the same - you can call the OnCrosshairRefChange event as if it were a function. And in case of sexlab, when you select the actor, you're supposed to also seed the actor stats (which setTargetActor does), and if you're targeting an actor that's in NPC-only animation, it'll also take control of the thread. There's a possibility some other mods may have similar mechanisms to trigger.

[reikiri]

On 7/9/2020 at 11:29 PM, prinyo said:

@reikiri I have added a file from the patch in the Select NPC for MCM mod, maybe it is a better idea to incorporate this in the patch behind a check if the mod is installed to prevent future chaos for people who use it.

It is an easy and quick change - a 1 line of code that gets the crossref from a quest,

 

After a bit of fiddling, here's a working example that selects MCM target for sexlab and scholongs, without overwriting anything on those mods, and using soft dependencies (so neither mod is required, but it'll work if they are installed):

sslTarget and sosTarget need to be defined somewhere before the functions. StuffForInit() needs to be called once when the script starts (e.g. when player loads game, or f.ex. OnEffectStart if that script is magic effect.

SetSelectedActor would need to be called whenever an actor is selected, f.ex. when spell is cast on an actor that triggers the magic effect - in which case both init and select could be called at effect start. I tested this by embedding it into SLSO_SpellGameScript of SLSO that I'd modified, calling the stuffForInit from OnEffectStart, and calling the SetSelectedActor from partner change function of that script. Seemed to work fine.

-----------------------------------------------

sslSystemConfig sslTarget
SOS_PlayerAliasScript sosTarget

 

Function StuffForInit()

    ; Sexlab
    if Game.GetModByName("SexLab.esm") != 255
        Form SexLabQuestFramework  = Game.GetFormFromFile(0xD62, "SexLab.esm")
        if SexLabQuestFramework
            sslTarget = SexLabQuestFramework as sslSystemConfig
        endIf
    endIf
    ; Scholongs of Skyrim
    if Game.GetModByName("Schlongs of Skyrim - Core.esm") != 255
        SOS_API SOSframework  = SOS_API.Get()
        if SOSframework
            sosTarget = SOSframework.SOS.config.PlayerAliasScript
        endIf
    endIf

endFunction

 

Function SetSelectedActor(Actor akActor)
    ; Sexlab
    if sslTarget
        sslTarget.OnCrosshairRefChange(akActor as ObjectReference)
        sslTarget.SetTargetActor()
    endIf
    ; Scholongs of Skyrim
    if sosTarget
        sosTarget.OnCrosshairRefChange(akActor as ObjectReference)
    endIf
endFunction
----------------------------------------------------------------

 

[prinyo]

10 hours ago, reikiri said:

Anyhow, have you given thought for avoiding overwriting the files on mods, and instead triggering the actor select through functions the mods themselves use?

As you guessed, not all mods can be handled this way. There are cases where the crosshairref is assigned within a function or event immediately before it is used. 

 

Event OnEffectStart(Actor Target, Actor Caster)

    Actor targetRef = (Game.GetCurrentCrosshairRef() as actor) 

    if targetRef

    ...

I prefer consistency and predictability in programming, so I really don't like the solution where some mods are handled one way and others in a different way.

 

Also I want it to be a modular solution, a service/utility mod that the other mods use it if they want to. I want it to just replace GetCurrentCrosshairRef() without adding any more complexity and logic. It is now equally easy to use both in a script and they do exactly the same:

Actor targetRef = (Game.GetCurrentCrosshairRef() as actor) 

vs

Actor targetRef = nsmquestscript.getInstance().NSMActor

 

Consistency and predictability ? This way new mods can use it and people can easily add it to their own patches without the need to get me involved. I want to avoid the situation where the usefulness of the mod depends on the availability of the author, in this case there is no real need for it.

 

The intent of the mod is not to patch other mods, but to provide a replacement for functionality that was cut from the VR port. But since almost all mods are no longer updated I decided to put the patches in the download.  At some point I was thinking to put it for download in two or more files - the mod itself (the two files with the spell) and the patches separately. I was even thinking of having an archive file per patch. But it would be too user unfriendly and since most of the mods are no longer updated I decided there is no need for it. So it is wait and see if a mod does get updated what is the best course of action.

Similarly to a mod like VRIK it replaces functionality that exists in Flatrim and is removed from the VR version. So using it in a VR patch for a Flatrim mod does make sense. But that's only my point of view, it is up to you to decide what to do, I just wanted to explain why it is the way it is.

 

 

[reikiri]

3 hours ago, prinyo said:

As you guessed, not all mods can be handled this way. There are cases where the crosshairref is assigned within a function or event immediately before it is used. 

 

Event OnEffectStart(Actor Target, Actor Caster)

    Actor targetRef = (Game.GetCurrentCrosshairRef() as actor) 

    if targetRef

    ...

 

My guess is what's really needed is a hook in SKSEVR - but I'm not familiar enough with how dlls hook into Skyrim to really be sure how deep that would need to go. You're talking about two different things there though. Yes, you could build a framework that essentially just stores an actor selected by spell, and lets mods access that information if they will. That would be the other 'non destructive' way to go about it, but yeah.. a lot of mods aren't maintained actively, or have no plans to get patched to be VR compatible at the moment, if ever.. so that's not perfect either. Personally I'd pick a method case by case, based on what works best for each mod.. and yes, the cases where hooking externally doesn't work, probably make it a separate patch with clear notes on exact version of mod it can patch - that way people know what they're getting into. If you roll it all into one install.. people will simply install it - and potentially end up breaking mods (as would have happened to VR patch).

 

But really, up to you. I can probably make it work for the time being, if I add a test for detecting the mod into SL system config, and change the config menu:

 

    ; Target actor
    StatRef = PlayerRef
    TargetRef = Config.TargetRef
    EmptyStatToggle = false
    if (!TargetRef || !TargetRef.Is3DLoaded()) && Config.SelectNPCMCM
        TargetRef = Config.SelectNPCMCM.NSMActor
        Config.OnCrosshairRefChange(TargetRef as ObjectReference)
        Config.SetTargetActor()
    endIf
    if TargetRef && TargetRef.Is3DLoaded()
        TargetName = TargetRef.GetLeveledActorBase().GetName()
        TargetFlag = OPTION_FLAG_NONE
    else
        TargetRef = none
        TargetName = "$SSL_NoTarget"
        TargetFlag = OPTION_FLAG_DISABLED
        Config.TargetRef = none
    endIf

 

That should be a non-disruptive way of adding it in on SL side - assuming the SetTargetActor works when called from MCM menu. With that in, you can remove the VR patch file, and nothing on SL side should break/change if the NPC picker isn't installed. The 33 version (I think that's what the mod page mentioend) is broken anyway.

 

 

[prinyo]

1 hour ago, reikiri said:

My guess is what's really needed is a hook in SKSEVR

Yep, ideally Expired can find a way to recover the crosshair functionality to work as it does in Flatrim. But for now I think the mod provides a flexible and easy to use solution.

 

1 hour ago, reikiri said:

That should be a non-disruptive way of adding it in on SL side - assuming the SetTargetActor works when called from MCM menu.

This looks nice. My intentions were only to get the selected NPC in order to show the extra info in MCM, so I only did the first part (only assigning the ref within the MCM scrip). However assigning the ref in the config opens new possibilities - you can take control over NPC-NPC animations and manage them the way you do the ones where the PC is involved. I was planning to explore that in more detail but never did.

The mod has only a spell to select, not to unselect, so there is no way to select the PC. I was thinking if I should add a spell for that, but for now I haven't found a practical use for it to justify cluttering people's inventories. This can have an effect however when patching a mod if the mod uses the lack of crosshair ref as a hint to select the PC. But so far this hasn't actually happened with the mods I have patched.

What I was planning to experiment was - select a NPC, when you open the SL MCM while PC is not in animation, it would check if the target!=player and if yes then search for a running SL thread with the NPC. If there is one - show the VR menu for animation control, if not - show the VR settings. SL already has this functionality - you can target a NPC in the crosshairs and press N, but in VR this workflow is not really userfriendly.

 

1 hour ago, reikiri said:

With that in, you can remove the VR patch file, and nothing on SL side should break/change if the NPC picker isn't installed. The 33 version (I think that's what the mod page mentioend) is broken anyway.

I removed it earlier today when I uploaded a new version. The version that was in the patch is the one I myself still use and is the one that has stayed the longest for download here. It was added relatively recently by request.

However in the update today I added Nether's Follower Framework and I see that it was last updated less than a month ago. It is also not possible to patch any other way (the example above with the event was from that mod) even if I want to. So I'll probably make it a separate download and will contact the author.

[reikiri]

47 minutes ago, prinyo said:

What I was planning to experiment was - select a NPC, when you open the SL MCM while PC is not in animation, it would check if the target!=player and if yes then search for a running SL thread with the NPC. If there is one - show the VR menu for animation control, if not - show the VR settings. SL already has this functionality - you can target a NPC in the crosshairs and press N, but in VR this workflow is not really userfriendly.

MCM menu isn't a user-friendly way to manipulate animation either way - that's why the whole gesture control system is there. Opening SL MCM already shows the nimation control page if player is involved, so there's some reference to see at least the most common gestures if/when you forgot them.

 

For taking control of NPC animation properly, I'd need to rework the gesture system. It resides in actorAlias, and only works when that actorAlias is assigned for player, and it controls the thread the particular actorAlias is assigned to, thus always controlling the thread the player is assigned to. The controls activate when the actor alias (and thus the thread) activates, and deactivate when thread is done - it has to be that way since the system uses pretty much every available gesture, and masks the normal gestures the player has.

 

It's not impossible to rewrite the system to manipulate another thread... probably, but to do it properly would be a fairly large undertaking - it's too much work to get into for a relatively minor feature (taking active control of purely NPC animation), that would only be available through an external mod to begin with (NPC selector). It would involve, most likely, several changes to multiple scripts. I'd need to separate the gesture controls from actorAlias, or do some megahack to activate them on a different actorAlias if taking control of another thread.. I don't want the headache and added confusion that would cause. And you really don't want to pull 3+ scripts out of mod in active development, and try to implement all of that into them in your own patch.. probably needing to re-apply the changes every couple weeks to new versions of the scripts. ?

 

Making just the MCM menu to work on NPC thread..? Yeeeeah... I may actually have to do something about it now that I opened that can of worms - because as it stands now, taking control of thread means player is smacked with SetPlayerAIDriven - which locks the player down. Either that, or I'll have to just disable that feature from next update on. The way it's implemented now is pure SL SE code, and it will not work right.

 

Maybe I really do need to move the gesture controls out of actoralias, possibly into thread controller. I'll think about it.

 

-- edit --

Thought about it - yes, have to do it. It was mistake to put them in actorAlias to begin with.. I didn't understand fully how they work when I put them in. From papyrus side they are just mod events and have nothing to do with player actor, and logically they belong to thread controller because frankly, they control the thread. Putting them there means I can just activate them in a thread I want to have controlled.. and it'll no longer be dependent on player specifically.

[prinyo]

Yeah, taking control of NPC animations is a Pandora's box. What I wanted to say, but distracted myself is that I purposefully didn't set the config ref and only limited it to the MCM script because it might have unexpected side effects.

The only reason to patch SL at all was only so it will show what does the NPC have equiped on a slot when browsing the strip editor. It was a request here at LL.

 

It does seem that for taking control over NPC scene the best option is to not use the SelectNPCforMCM mod, but to add a new spell in SL itself. Equivalent to pressing N on the target. Because even adding mod events will not be enough for implementing the gestures. My idea was limited to basic things like change of roles, next stage, next animation and mostly disabling the current animation. 

 

[reikiri]

9 hours ago, prinyo said:

Yeah, taking control of NPC animations is a Pandora's box. What I wanted to say, but distracted myself is that I purposefully didn't set the config ref and only limited it to the MCM script because it might have unexpected side effects.

The only reason to patch SL at all was only so it will show what does the NPC have equiped on a slot when browsing the strip editor. It was a request here at LL.

 

It does seem that for taking control over NPC scene the best option is to not use the SelectNPCforMCM mod, but to add a new spell in SL itself. Equivalent to pressing N on the target. Because even adding mod events will not be enough for implementing the gestures. My idea was limited to basic things like change of roles, next stage, next animation and mostly disabling the current animation. 

 

Change roles, next (previous) stage, next (previous) animation, disable animation, end animation, configure alignments - all things that would be available through scene control gestures. But you're right, the MCM selector is not the right thing for taking control of the scenes. First because it's different from it's usual working (which is just picking the target for MCM menus), and second because it would hide more of SL features behind external mod. I guess I'll need a SL internal way of picking actors, which means I'll have to either make an extra plugin (which I've tried to avoid), or modify SL's own plugin (which would be even worse when SL gets updated), or I repurpose the debug spells SL currently has - which may be an option.

 

This is all separate from moving the gesture controls out of actorAlias though - it's something I should do either way, because actorAlias is logically the wrong place for them, it bloats that single script and makes the whole mod more confusing internally.

 

-- edit --

After looking around for a while - yes. I should be able to repurpose the debug spells - the only issue will be they are named strangely for their new purpose, but I'm not going to worry about that. There's 'self' spell and there's 'target' spell, that'll work fine. What I'm thinking is:

 

- Sexlab, Scholongs, and Aroused - all use the same method of crosshair interaction, which allows actors to be set from outside source. They are kind of 'cornerstones' of SL framework, so I'm going to integrate the selection from SL to all of those. I'm also going to check if NPC selector mod is installed, and if it is, will try to set the same selected actor to it, which if it works, should spread the selection to every mod it integrates with.

 

- Casting 'target' spell will select the targeted actor for all integrated mods. SL also has a feature to track up to 5 last selected actors

- If targeted actor is involved in SL animation, take control of the animation

- If no actor is selected within 60 seconds, the stored actors will be reset, including the MCM selected actor

- Casting 'self' spell will basically be 'do sex' action. It will try to trigger a random SL animation with all the stored selected actors after 5 seconds

- If no actors were select, then casting self spell will just select player, casting it second time within 5 seconds will start sex for player only

- If you cast 'self' spell a second time within those 5 seconds, you will add yourself to the list (and the 5 second timer will reset)

- If you cast 'self' spell third time before the 5 second timer ends, the start will be canceled, stored actors reset, target cleared

 

- Want to select NPC for MCM? Cast target spell on NPC, you now have 60 seconds to open the MCM.

- Want to select yourself for MCM (useful for SL aroused)? Cast self spell once.

- Want to start random scene for one NPC? Cast select on NPC, then cast self spell.

- Start sex between multiple NPCs? Select up to 5 NPCs, then cast self spell.

- Start sex with player and an npc? Cast select on NPC, cast self spell twice.

- You selected some actors, and cast self spell to start scene, and now want to cancel it? Cast self spell twice more.

- Want to get rid of some arousal? Cast self spell twice. Regrets? Cast it third time within 5 seconds.

 

It's not perfect, but should be intuitive enough to remember, and have a good range of options. It's a bit confusing with the 60 second timer, since at some point you might or might not have stored selected actors - which can change the behavior of spells.. but it's always safe to cast self spell three times to make sure things are reset.  If you had actors stored, 1st = start sex, 2nd = join in, 3rd = cancel and reset. If you didn't, 1st = select self, 2nd = start sex alone, 3rd = cancel and reset. So three casts ends up the same either way.

[Beef Cheeks]

19 hours ago, reikiri said:

MCM menu isn't a user-friendly way to manipulate animation either way - that's why the whole gesture control system is there.

The gesture system would be nice but for some reason VRIK thinks my right controller is the left controller, and the left controller isn't working at all. So I can't trigger right-controller gestures. I am using Oculus Quest via Virtual Desktop, making it emulate as Rift controllers in SteamVR. I'm not sure what's wrong, but I just simply have to load the SexLab MCM every time I want to change animations.

 

EDIT: Well I'm stupid. I saw the "For INDEX ONLY" in the description of the Controller Bindings addon, so I thought it was for Index only. LMAO. This is why using capital letters is a bad thing. Nexus has a colored text feature for a reason. lol.

[reikiri]

So, I got debug spells working for selecting NPCs and starting animations.. and selection spreads to aroused and schlongs "standalone", as well as MCM selector if it's installed, which then also spreads it to other mods it supports (worked on EFF which I have installed).

 

TODO:

- move gesture controls to thread control and enable them to work on NPC-only animations if you use select an NPC in the animation (done)

- try to make built-in selection and scene starting a little smarter with gender selection maybe? (got a male NPC taking a ride cowgirl style on a female...) (done)

- still need to fix / clean-up or rollback the SLSO integration, I might just disable it so I can upload what I have, and then take more time to work on it later (done) - ended up disabling SLSO integration for this version, I need to decide what to do with it, and put some more work into it. Still not sure if I want to actually do integration with SLSO, or just add some similar features into VR patch itself. The purpose of the patch would favor supporting SLSO, but in practice it might be easier and more stable in long run, to keep it internal to patch.

 

[Zylch000]

After some testing with PSQ, I was finding that the PSQ Lure spell wasn't working because the player actor was detected as still in animation, but the masturbation animation (for the lure) had just ended.  The player actor is still in the thread, but no longer part of the animating faction.  You have made a couple of changes in your scripts to SexLab's actor validation checks that prevent this from working correctly and allowing the player actor to be added to a new thread after a successful lure.

In SexLabFramework.psc on line 297, I removed the second condition for finding the actor controller.  The original SL only checked the faction

bool function IsActorActive(Actor ActorRef)
	return ActorRef.IsInFaction(Config.AnimatingFaction)|| Config.ThreadSlots.FindActorController(ActorRef) != -1
endFunction

I also reverted the additional controller check from sslActorLibrary.psc in the section starting on line 457

With both of these changes reverted, the functionality in PSQ was able to proceed correctly.  I've included the compiled scripts that I altered in addition to the source with those changes based on your Beta8 35 scripts.

 

 

SL VRpatch Beta8 35.1 - fix.7z

[Zylch000]

Also, thank you so much for making SL work with VR and VRIK.  This is fantastic work!

[reikiri]

9 hours ago, Zylch000 said:

After some testing with PSQ, I was finding that the PSQ Lure spell wasn't working because the player actor was detected as still in animation, but the masturbation animation (for the lure) had just ended.  The player actor is still in the thread, but no longer part of the animating faction.  You have made a couple of changes in your scripts to SexLab's actor validation checks that prevent this from working correctly and allowing the player actor to be added to a new thread after a successful lure.

In SexLabFramework.psc on line 297, I removed the second condition for finding the actor controller.  The original SL only checked the faction

bool function IsActorActive(Actor ActorRef)
	return ActorRef.IsInFaction(Config.AnimatingFaction)|| Config.ThreadSlots.FindActorController(ActorRef) != -1
endFunction

I also reverted the additional controller check from sslActorLibrary.psc in the section starting on line 457

With both of these changes reverted, the functionality in PSQ was able to proceed correctly.  I've included the compiled scripts that I altered in addition to the source with those changes based on your Beta8 35 scripts.

 

The original SL managed to put an actor into three separate threads at once - resulting in a rather superhuman act of humping for a split second in each thread before bouncing to another.. and another.. and another, switching between their intended position in each of the threads. I never managed to figure out why that happened.. why the actor fell off the faction before the animation had finished.. but single actor shouldn't be in multiple threads at once. I'm not even sure what that could do for actoraliases.. would the player be in multiple actor aliases? That could get messy, if they locked and unlocked the player out of sync. Or would the same actoralias be in several threads? That could break things when each thread tried to manipulate the same alias, again out of sync. Possibly trigger cleanup on the actoralias from one thread while other was trying to use it?

 

I don't know how that particular mod works, or what it does - since I haven't used it.. but normally I'd rather take a few seconds of safety net after animation ends, to let the thread and actoralias properly clean up, before throwing the same actor into next thread.

[Zylch000]

Interesting.  That makes sense.  I'll have to see if I can find a workaround for the PSQ script to wait until the thread is cleared.  This was just more obvious and simple.

[reikiri]

3 hours ago, Zylch000 said:

Interesting.  That makes sense.  I'll have to see if I can find a workaround for the PSQ script to wait until the thread is cleared.  This was just more obvious and simple.

My initial thought would be, why stop if you don't mean to?

 

I don't think it's necessary to drop the thread in the first place, it should be possible to stop the animation, add an actor, throw in a new animation and then keep going. It's possible to switch between animations on the fly, so it might even be possible to make the transition more or less seamless - but I'm not sure of that without actually looking through the code, never really thought about doing that.

 

That would be kind of nice.. you could keep adding actors and grow it into an orgy, keep the player succubus in position 0, and search for F, then FM then FMM, FMMM tagged animations. Or just have a set of pre-picked animations that work well together. Could also go F, FF, FFM, FFMM, etc, just picking what's appropriate for new 'customers'.

[prinyo]

Hmm, there have been reports of chained scenes not triggering in VR, like multiple assaults in Defeat. I always assumed it is a setup issue, but maybe it is not?

[Zylch000]

I think I may stick with my fix since there may be other mods that rely on this "bug".  SexLab's code is this way, I don't see the value in changing it unless it's merged back into the original SexLab and other mods adjust to this behavior.  It's a bit too fundamental of a change for a simple refactoring or attempted bug fix.  There are other underlying things going on with SexLab threading.  I'd rather leave the ValidateActor change out and have the VR version have the same functionality as the SE version.

[reikiri]

Possible. I'll need to have another look at it, see if I can figure what the real issue is. That change fixed what was wrong with hentai creatures - and that was back during the LE era already, and the solution was logical. One actor should not participate in multiple animations at once, that's a fact. But is it ultimately the problem in SL, or was HC using SL wrong, I can't be certain. I think it's SL that decides when actor goes in and comes out of 'animating faction', and if that's the case then something in the check went wrong - but again the real issue may be elsewhere in the code. And I still think it's fundamentally wrong for one actor to participate in multiple threads at once, but is that just a matter of thread cleanup not being responsive enough? Should the actors be dropped from them faster once the animation ends? Or are mods in general using SL wrong - e.g. if you want to chain the animations, should you keep using the same thread for them.. or is it simply that running the animations too quickly in chain isn't something that SL supports?

 

What comes to Defeat though, it has internal timer that prevents actor from being 'defeated' too quickly in succession, if that happens, you simply die. And it has the 'satisfied' mechanism that makes it so the assailant isn't interested in another round until a bit later. And as far as I know, until just now (when Expired released the SKSEVR v12) much of the Defeat MCM didn't work. So there's multiple possible reasons there - although I don't discount the possibility of player (or other actors) lagging behind in previous thread, and that change then preventing them from being thrown into another.. that's entirely possible. It's also worth mentioning that SL has only so many threads that it reuses - I think it was 5, but I'm not certain.

 

-- edit --

There shouldn't be much delay between actor being released from animating faction, and being actually cleared from the animation.. and I don't recall having seen the 'multiple scenes' issue in more than two mods - if some mods rely on actors being freed earlier, and since it's true it's the original behavior, I figure I can revert that change, and just keep an eye on things. If it still causes problems somewhere, may have to look for some other way to fix it.

[prinyo]

For Defeat the problem seems to be when multiple scenes happen within one "defeat". I personally have never used this option, but there are several reports about this here. 

[reikiri]

New version, more on the release notes!

[reikiri]

On 7/12/2020 at 10:33 PM, Zylch000 said:

After some testing with PSQ, I was finding that the PSQ Lure spell wasn't working because the player actor was detected as still in animation, but the masturbation animation (for the lure) had just ended.  The player actor is still in the thread, but no longer part of the animating faction.  You have made a couple of changes in your scripts to SexLab's actor validation checks that prevent this from working correctly and allowing the player actor to be added to a new thread after a successful lure.

In SexLabFramework.psc on line 297, I removed the second condition for finding the actor controller.  The original SL only checked the faction

bool function IsActorActive(Actor ActorRef)
	return ActorRef.IsInFaction(Config.AnimatingFaction)|| Config.ThreadSlots.FindActorController(ActorRef) != -1
endFunction

I also reverted the additional controller check from sslActorLibrary.psc in the section starting on line 457

With both of these changes reverted, the functionality in PSQ was able to proceed correctly.  I've included the compiled scripts that I altered in addition to the source with those changes based on your Beta8 35 scripts.

 

Just a small note - this is reverted in 37 for the time being, and using the patch made for v35 may break any version other than exactly the one it was made for (beta 8 35)

[Zylch000]

Wonderful, thank you!  I'll check it out.

[Joshisadouche12]

For some reason when I enable the VR Patch, I can't install Sexlab in the MCM menu. I get a error that reads "CRITICAL ERROR: File integrity Framework quest / files overwritten. Unable to resolve needed variables". I don't have any other mods installed except for Sexlab/VR Patch and their requirements.  Anyone else have this issue?