Skyrim SexLab and VR

[Bolan]

10 hours ago, XenoDrake said:

The latest DD should be obtained from here and it does not have 4.37 in the filename, so I don't know where you got yours: 

https://www.loverslab.com/files/file/5878-devious-devices-se-beta/

 

The download file link on tha page leads me here:

[Bolan]

I am trimmed down to 90 mods total having removed a lot of quest and geographic expansion, immersive patrols, CACO, stripped out all equipment and armor mods, left the enviornment, skeleton, animation, hair/body/eyes mods. Here is the SL / DD / DCL Load right now - should be very close to yours:


The *only* issue I am having is with MCM. If I try to navigate DCL MCM menu, MCM hangs in general and will no longer open other menus, or even finish opening the last menu selected. DCL works... oh DCL works... I know because I am not able to supply my imported settings which reduce the number of times bad stuff happens significantly LOL. So any clues about why I am having MCM trouble? as long as I don't touch the cursed loot menu, all the SL functions and even DCL functions work just fine.  I am not even contemplating adding any more SL mods, this small group creates enough anxiety - but I am really stumped about MCM. I've turned Supersampling down in Open Composite to 1.4 and performance in game is (someone used the word "buttery" ) excellent, visuals are excellent. 

[reikiri]

15 hours ago, osmelmc said:

To know the compatibility issues with the VR the best way is compare the original SexLab LE or SE files with those for VR.

Yes, and I can assure you the differences are many. ?The actor alias in particular I had to practically rewritten the parts that handle player character (there was no way to get PC to adhere to animations through papyrus, so player position in animation is controlled purely through VRIK.. third person camera through normal means is disabled, and instead handled through some VRIK trickery, etc). There's changes in other scripts that would have to carry over, but I've mostly contained it within actor alias. Also the MCM menu has had a fair bit of changes to include the VR page into it - but again I've mostly contained the changes to that single page.

 

It's not impossible to mix them together, of course, but if you put VRpatch files against SL beta 8 on winmerge or just linux diff - whatever works - there's a huge number of changes.. and those grow more complex when you count merging (and basically rewriting) SLSO into the mix - which isn't still there in the released version (I had to change a number of things to make it adapt to VR.. then I ended up fixing a couple things.. then rewriting most of the logic.. and eventually going 'uhh.. why don't I just rewrite the whole thing from scratch at this point').

 

The biggest issue with SLSO was that it does so extensive changes to same flies that VR patch modifies, that maintaining it as soft requirement (support if present, otherwise work without) would be a total nightmare both when going ahead with VR patch, and when/if SLSO gets updated and I'd have to mix the changes back in again. Right now in dev version, it exists as a soft requirement - probably, I haven't tested without it - and I'm at the point where I'm unsure if I want to forget it and roll it all back, or to fully rewrite whatever functions I want from it and make them part of VR patch, or just go ahead as it is now (which I'd probably regret later on). The best way to go might be to externalize it all, keep changes to SL itself to absolute minimum, and try to mostly just interact through API calls. Add a config property 'HasSLSO', and if present, disable parts of SL that don't work with it, and have SLSO VR version take over through API calls.. create new API interactions for it where needed.

 

I think SUplus would likely run into same issue. VRpatch isn't so much a mod that 'adds' something to SL, rather it changes major parts of it. It still tries to maintain same API as far as possible, so things that mostly interact with SL through API calls should largely work.. but anything that likewise changes the internal workings of SL, is going to be a lot more difficult.

[reikiri]

1 hour ago, Bolan said:

The download file link on tha page leads me here:

That's version 4.3 - the 7z is the compression suffix ? There's couple times that suffix has confused me too with files that end in a number - especially version number that has dots. Whoever came up with the idea of using number to lead a suffix, should get spanked.

[Bolan]

13 minutes ago, reikiri said:

That's version 4.3 - the 7z is the compression suffix ? There's couple times that suffix has confused me too with files that end in a number - especially version number that has dots. Whoever came up with the idea of using number to lead a suffix, should get spanked.

No kidding. And not in a good way.
We agree its the correct file though yes? I guess I didn't watch the name MO2 gave it.

[reikiri]

9 minutes ago, Bolan said:

No kidding. And not in a good way.
We agree its the correct file though yes? I guess I didn't watch the name MO2 gave it.

I believe so. The page said 4.3 beta I think, so that should be it.

 

What comes to MCM hanging, I find it's generally because the script that shows the page does something heavy on the same thread that handles MCM. Usually waiting for a while on that page will solve it. On the other hand sometimes it launches the process in a way that requires you to exit the menu, so at those times you may have to fully exit from MCM for a while for it to settle. Then there's times when something runs, and then opens an MCM pop-up.. which can open in such a way that if you left the page, reopening MCM will bring you to a page with pop-up that has no focus .. and you have no way of closing it (save possibly by using mouse and keyboard, haven't tried that). And then of course there's the worst possibility - a script error that stops the process before it ever shows up the page to you... and I guess it's possible it could break the MCM until you reload/restart the game.

[Beef Cheeks]

2 hours ago, Bolan said:

No kidding. And not in a good way.
We agree its the correct file though yes? I guess I didn't watch the name MO2 gave it.

Oh. I didn't think about with the extension. haha. Yeah 4.3 is the version. 7z stands for 7zip which is a compression archive format like zip and rar.

 

But yes I wonder if getting DCL to work in VR is just a moot point. I may have to test it myself. I honestly haven't yet. Usually I don't install DCL because it limits capability of almost any quest-based mod, because it overrules a lot of the game, forcing NPC's to stop you all the time, sending you off to the middle of nowhere mid-quest. It's a fantastic mod, but I guess my issue is once you install it it will block off a lot of things to you. A number of the extra devious devices it equips on you will limit the amount of scenes you can have. All of the sudden sex scenes won't fire unless you have that rare animation that has aggressive and blowjob tags together... which there's only like 2 or 3 that I know of for any major pack. So basically the variety drops significantly. I just ended up resetting my save after like an hour of play because it got too repetitive.

[Bolan]

22 minutes ago, XenoDrake said:

But yes I wonder if getting DCL to work in VR is just a moot point.

that is actually a fascinating question now that I think about it.
I guess I thought of it as one mod offered a substantial number of possible scenarios all on it's own. Whereas you point out it may be limiting other opportunities. I am looking for that balance where bad things happen naturally, you lose a battle, the foes take liberties, you piss off the wrong mage, you find yourself locked up, or you go to jail and the guards take their liberties.... I'm looking for bad things to happen when I misbehave or lose. So SLDrunk is a good example, it can get out of hand and bad things can occur but you probably deserved what you got. Same thing with POP, justice can be hell but you probably earned it. So maybe with that in mind, whats the list of mods that makes sense?

[prinyo]

Isn't getting DD mods to wok in VR generally a mute point as long as it doesn't work on the PC? No wearable devices, no tracking limitations...

I still think the first step in trying to patch is a parameter in the VR settings function of the SLVR patch that would block it from running the function internally when starting a thread.

 

[prinyo]

@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,

 

[Rick Sanchez]

2 hours ago, prinyo said:

Isn't getting DD mods to wok in VR generally a mute point as long as it doesn't work on the PC? No wearable devices, no tracking limitations...

I still think the first step in trying to patch is a parameter in the VR settings function of the SLVR patch that would block it from running the function internally when starting a thread.

 

I have pretty much got player worn DD nearly working with VRIK, my test game is running DDI/DDE/DCL/DT and Devious Followers pretty seamlessly.  I still have a couple of hold out bugs on teasing at tripping anims, but the core stuff, heavy bondage gear, etc is all working great.   You can still use the VR controllers as normal to select items, open doors etc, but my patch overrides the body posture to comply with the DD. 

 

The general animated events are causing me the most grief atm,  I still got a couple of things to try but they are a PITA to troubleshoot because A) they are random and B) I suck bigly at papyrus.  Sadly, unlike the heavy bondage which works standalone, I can't find a way to do the general anims without modifying zadlibs

[reikiri]

1 hour ago, prinyo said:

Isn't getting DD mods to wok in VR generally a mute point as long as it doesn't work on the PC? No wearable devices, no tracking limitations...

I still think the first step in trying to patch is a parameter in the VR settings function of the SLVR patch that would block it from running the function internally when starting a thread.

 

Well... some people want to have their followers bound up, or some npcs decorating their homes.. so I guess there's that.

 

Actual worn items should work on players - or should be possible to be made to work. I understand DD uses a bit more complex setup where there's separate inventory item that controls the restraint.. and the actual worn object doesn't show up in inventory. Maybe something in that arrangement isn't working right when ported to VR.. but I don't know of any limitations that would make it impossible to make it work. Animation objects however will not at the moment, and I don't know how DD uses things between the two. I can't imagine that it would always just use separate objects in animations, that wouldn't be able to match up all the gear the actors are wearing - like, an actor could have rope bindings or iron cuffs or leather armbinder.. and use same arms-behind-back animation in any of the cases.

[prinyo]

25 minutes ago, Rick Sanchez said:

The general animated events are causing me the most grief atm

Maybe you know it already, but the SL VR patch has a function that can be called by mods:

 

SetVrSettings(bool enabled=true, int lockHeight=-1, int trackHands=-1, int trackHead=-1, float hideHead=-1.0, float nearDistance=-1.0, int lockHmdToBody=-1, float hmdTol=-1.0, float hmdDis=-1.0, float hmdSpd=-1.0, int thirdPerson=-1)

 

It can be used when a mod is sending an animation event - just before sending it. If you use it like

SetVrSettings() ;no params

then it will prepare VRIK according to the VR settings in the SL MCM. This way there is a consistency and it is easier for the user.

After the animation ends you can regain control by

SetVrSettings(enabled=false)

If you have bind hands for example and the mod is sending an animation event, then you can call   

SetVrSettings(trackHands=0)

As a result the VRIK settings will be changed as the player has chosen in the SL MCM, except the hand tracking will be overwritten - in this case disabled.

The problem is that this can be used when the mod itself is sending the animation event (as DD and ZAZ sometimes do), but not when it is using SL to do it. The VR patch is calling this function (so to say) as part of it's own preparations, so if you use it and then call an SL scene your setting will be overwritten. The patch will enforce the user preferences fully.

Hence the idea to add a new parameter - like "preserve" that would tell te patch to not run the function itself.

At least this what I was planning to do when I was thinking of doing some patching. I'm using DD and ZAZ for Isle of Mara, so my thinking is based mostly on that mod.

[reikiri]

2 hours ago, 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,

 

Should be simple enough, and a lot easier than updating that mod every time something gets updated on VR patch. I'll try to take a look at it this weekend (although might be some time still before I actually have something stable enough to put out a new version)

[Rick Sanchez]

@prinyo  Yeah Reikiri already put me onto those, but I couldn't call them for some reason.  I could call the VRIK functions direct though.   I'm not really worried about SL overriding what I'm doing as the individual 'idle' animations should end before SL calls a scene, even if they don't I figured that the users SL settings should always take priority.   I mean, fair enough, if you like your SL to go to 3rd person, that is understandable, but do you really want to be transported out of your body every time your character does a 2 second struggle idle... probably not.  (although I can concede, for people more prone to VR motion sickness the dd boot trip may be a bit much  ) 

 

I have quite a few working but, some of my setting overrides are not reverting properly and some of the idles are not following the body as it leans forward for some reason... but I'm also not sure where I stand on editing zadlibs. 

 

Once I get everything working, I have probably learn't enough in the last few weeks that I could now go back and use Reikiri's functions and probably the SL MCM integration where appropriate. 

 

[prinyo]

11 minutes ago, Rick Sanchez said:

but do you really want to be transported out of your body every time your character does a 2 second struggle idle.

Yes, this is a valid point when talking about a "pure" DD setup, but with some mods there will be sex mixed in.

Like in the mod I'm using you get cuffed or get put on the pillory and participate in different SL animations.

Ideally patching SL, DD and ZAZ (the frameworks) would make (almost) all mods work fine.

 

18 minutes ago, Rick Sanchez said:

but I couldn't call them for some reason. 

You can make it global and test it this way or use it this way in your own setup. If you want to publish things then you can change it to call it via SL.

[Rick Sanchez]

47 minutes ago, prinyo said:

Yes, this is a valid point when talking about a "pure" DD setup, but with some mods there will be sex mixed in.

Like in the mod I'm using you get cuffed or get put on the pillory and participate in different SL animations.

Ideally patching SL, DD and ZAZ (the frameworks) would make (almost) all mods work fine.

 

You can make it global and test it this way or use it this way in your own setup. If you want to publish things then you can change it to call it via SL.

Yeah, I think I know where I was going wrong initially when trying to call the functions from SL, if I do a rewrite now, I'm sure I can fix it.  

 

Cuffed anims work fine while controlling the character and during SL anims, haven't even looked at furniture yet.    Basically what I'm doing is using the heavy_bondage enchantment and appending an extra magical effect to it  via a plugin with the following script (I know it has a lot of redundant items in it, the hands, obviously doh!  But I'm a noob and barely had any understanding of papyrus when I made it) 

 

Spoiler

Scriptname VRIKHeavyBondage extends ActiveMagicEffect  

; Libraries
zadLibs Property Libs Auto

bool property enableLeftArm auto hidden
bool property enableRightArm auto hidden
bool property enableLeftHand auto hidden
bool property enableRightHand auto hidden

Float DeviceEquippedAt 
Int MsgCounter

Actor Me

Event OnUpdate()
            VRIK.VrikSetSetting("enableLeftArm", 0)
            VRIK.VrikSetSetting("enableRightArm", 0)
            VRIK.VrikSetSetting("enableLeftHand", 0)
            VRIK.VrikSetSetting("enableRightHand", 0)
            RegisterForSingleUpdate(45)
EndEvent

Event OnEffectStart(Actor akTarget, Actor akCaster)
            VRIK.VrikSetSetting("enableLeftArm", 0)
            VRIK.VrikSetSetting("enableRightArm", 0)
            VRIK.VrikSetSetting("enableLeftHand", 0)
            VRIK.VrikSetSetting("enableRightHand", 0)
            RegisterForSingleUpdate(45)
EndEvent

Event OnEffectFinish(Actor akTarget, Actor akCaster)
                VRIK.VrikSetSetting("enableLeftArm", 1)
            VRIK.VrikSetSetting("enableRightArm", 1)
            VRIK.VrikSetSetting("enableLeftHand", 1)
            VRIK.VrikSetSetting("enableRightHand", 1)
    UnregisterForUpdate()
EndEvent
 

 

It's probably very possible to do without a plugin esp using something in zad, but this was the first thing I managed to get working and I'm pretty happy with the result for now. 

[Bolan]

With DCL off everything appears to be running fine - only thing odd is hands apear to be twisted an extra 180 degrees at the wrist which looks painful and awkward. Is that something in the realm of VRIK?

[Bolan]

Also, adding DCL after all other mods running and then in addition as suggested, waiting after hitting enter on DCL MCM the first time, DCL now appears to work (I was able to use the menu to load my settings and triggers some events. Here is my SL / DD /DCL collection - still obviously testing out functions but all have worked so far. Re-titled a few of the DD ones just to make filtering easy in MO2

 

[Beef Cheeks]

6 hours ago, Bolan said:

that is actually a fascinating question now that I think about it.
I guess I thought of it as one mod offered a substantial number of possible scenarios all on it's own. Whereas you point out it may be limiting other opportunities. I am looking for that balance where bad things happen naturally, you lose a battle, the foes take liberties, you piss off the wrong mage, you find yourself locked up, or you go to jail and the guards take their liberties.... I'm looking for bad things to happen when I misbehave or lose. So SLDrunk is a good example, it can get out of hand and bad things can occur but you probably deserved what you got. Same thing with POP, justice can be hell but you probably earned it. So maybe with that in mind, whats the list of mods that makes sense?

It's a 50/50 situation. DCL has some triggers that no other mods have, but it overrides or is not compatible with a lot of other mods because it locks your player into quests quite often that prevent a lot of things. So it depends whether those features are worth it to you. If you want some similar features, I tend to use Deviously Enchanted Chests (I had to convert it myself from LE to SE) for a similar chest/barrel/pouch DD trap mechanic, only instead of finding them inside the actual inventory of the container, it has a random chance to just spawn a configurable range of random devices on you. I then use Deviously Vanilla+Devious Confabulation for some extra triggers for Devious Devices. Not as good as DCL, but at least enough to get by for my tastes. And Confabulation and Deviously Vanilla has a patch for SexLab Solutions. So I use SexLab Solutions Revisited v3 (probably need to see if this is actually compatible /shrug, but I haven't had problems so far) and Deviously Vanilla and Confabulation. I had to convert the latter two for SSE though, since they don't have released conversions. But they seem to work fine. I also use Naked Dungeons for some extra Devious Devices traps inside of dungeons, as well as spicing up the gameplay in dungeons. It also has its own basic immortality function with Sexlab Slavery support when you take fatal damage, or do other things if you wish instead of dying. I use this in VR since SexLab Defeat is reportedly problematic in SkyrimVR. Naked Dungeons also has a number of other features like cum inflation. Although make sure to install the patch, found below, on top of the SSE port.

 

[reikiri]

8 hours ago, Rick Sanchez said:

via a plugin with the following script (I know it has a lot of redundant items in it, the hands, obviously doh!  But I'm a noob and barely had any understanding of papyrus when I made it)

No! *bap*

Bad! *bap*

Instead of doing the enable(1) things when effect ends, just do VRIK.VrikRestoreSettings()

Those settings, when you modify them through papyrus, are temporary (unless you call SaveSettings, which you should NOT do).. and calling the restoresettings will revert them back to whatever player has defined in their VRIK settings. The only problem is if they go to VRIK menu, VRIK will automatically saveSettings when they leave the menu, thus making your adjustments permanent.  But that's how it goes. ?

 

What comes to calling the SetVrSettings, maybe you figured it out alredy.. but VRIK API is global functions, so you can call them anywhere, anytime. SL API is not defined as global functions, so you need to take the extra step to define a reference to SL, then call the API through that reference. It's the model SL uses, and I didn't make exception for that function.

 

Even if you call it through SetVrSettings, you can always override the 3rd person setting, e.g.

SetVrSettings(enabled=true, trackHands=0, thirdPerson=0)

and possibly a few other parameters. And then just SetVrSettings(enabled=false). Following the body during leaning forward etc.. might be related to few things.

SetVrSettings(enabled=true, trackHands=0, thirdPerson=0, trackHead=0, lockHmdToBody=1, hmdTol=0, hmdDis=0, hmdSpd=1000)

would probably do it. You might want to leave the last 3 parameters away to let whatever the player had defined in their settings take effect - so if someone wants a 'smoother ride', they can have it.

 

You should not call setVrSettings(enabled=true) twice, so in this case you'd just call it in OnEffectStart() once and then call the (enabled=false) in OnEffectFinish().  That's instead of everything you have there now, not in addition to it. There's a bunch of stuff those lines won't handle, like disabling sneaking (which seems likely). On the other hand the SL function was intended for running actual longer animations, so it removes holsters from view among other things.. which may not be what you want in a short clip. I may need to add a parameter to allow holsters to stay visible.. it would be simple to put there.

 

Also also! Nitpicking here, but put the unregisterForUpdate() *before* restoresettings, if you want to keep that arrangement. It shouldn't make a difference in practice, but logically you want to first ensure the update no longer fires and locks the arms, and only then release the arms. VRIK does stuff on dll level, which means I think the calls will fire on next frame.. so in theory at least it might be possible that you release the arms, then onupdate fires and set them to be locked again.. before the unregisterforupdate triggers. And whether or not, it's just the logical order for things to happen.

[Rick Sanchez]

1 hour ago, reikiri said:

What comes to calling the SetVrSettings, maybe you figured it out alredy.. but VRIK API is global functions, so you can call them anywhere, anytime. SL API is not defined as global functions, so you need to take the extra step to define a reference to SL, then call the API through that reference. It's the model SL uses, and I didn't make exception for that function.

Nope, that's the bit I haven't figured out yet  clearly the route cause of all my issues calling scripts functions.  Is it just a line of code I'm missing at the start of my scripts or something?  If it's not too much trouble, what would that script look like if I were calling the SL API?  Thanks for the advice on the other items, that will certainly improve the heavy bondage script and probably fix a lot of the issues I'm having in zadlibs even if at the minute I'm stuck calling VRIK direct, my preference would be to use the SL API scripts where appropriate. 

[reikiri]

3 hours ago, Rick Sanchez said:

Nope, that's the bit I haven't figured out yet  clearly the route cause of all my issues calling scripts functions.  Is it just a line of code I'm missing at the start of my scripts or something?  If it's not too much trouble, what would that script look like if I were calling the SL API?  Thanks for the advice on the other items, that will certainly improve the heavy bondage script and probably fix a lot of the issues I'm having in zadlibs even if at the minute I'm stuck calling VRIK direct, my preference would be to use the SL API scripts where appropriate. 

Depends...

One way is to do a script that extends SL itself, there's insturctions to that in SL source code. Basically you define your script as:

Scriptname myScriptThatUsesFunctions extends SexLabFramework

if the script was called myScriptThatUsesFunctions

Then you could simply call that function directly from the script - and any other scripts on your mod you could hook in through that one.

 

Or you should be able to get a pointer directly to the script, like..

 

SexLabFramework property Sexlab auto


;;; other stuff here


function SomethingYouCallToInitStuff()

::: other stuff

    Form SexLabQuest = Game.GetFormFromFile(0xD62, "SexLab.esm")

    if SexLabQuest

        SexLab = SexLabQuest as SexLabFrameWork

    else

        ;;; fail.. couldn't find sexlab installed

    endIf

endFunction

Once you've ran that, you've hooked into Sexlab, and could call any of the functions in it, so like..

 

Sexlab.SetVrSettings( ..... )

 

[Rick Sanchez]

@reikiri  Thanks again, I'll give those a go.

[Bolan]

12 hours ago, XenoDrake said:

It's a 50/50 situation. DCL has some triggers that no other mods have, but it overrides or is not compatible with a lot of other mods because it locks your player into quests quite often that prevent a lot of things. So it depends whether those features are worth it to you. If you want some similar features, I tend to use Deviously Enchanted Chests (I had to convert it myself from LE to SE) for a similar chest/barrel/pouch DD trap mechanic, only instead of finding them inside the actual inventory of the container, it has a random chance to just spawn a configurable range of random devices on you. I then use Deviously Vanilla+Devious Confabulation for some extra triggers for Devious Devices. Not as good as DCL, but at least enough to get by for my tastes. And Confabulation and Deviously Vanilla has a patch for SexLab Solutions. So I use SexLab Solutions Revisited v3 (probably need to see if this is actually compatible /shrug, but I haven't had problems so far) and Deviously Vanilla and Confabulation. I had to convert the latter two for SSE though, since they don't have released conversions. But they seem to work fine. I also use Naked Dungeons for some extra Devious Devices traps inside of dungeons, as well as spicing up the gameplay in dungeons. It also has its own basic immortality function with Sexlab Slavery support when you take fatal damage, or do other things if you wish instead of dying. I use this in VR since SexLab Defeat is reportedly problematic in SkyrimVR. Naked Dungeons also has a number of other features like cum inflation. Although make sure to install the patch, found below, on top of the SSE port.

 

Thanks thats really useful information.