[Discontinued] SexLab Light VR patch

[porn128]

Thank you so much Prinyo for making this possible, to play those sex mods in first person view in VR, it's really amazing

[reikiri]

It's really nice. I was hoping to see some integration of SL to VR ever since I first came across flower girls mod. The first person view would be great if it got a bit more refined from how it is right now - but aside from that, the 'clone' option works really well on many of animations, just has position issues on some of them.

 

Ideally, the first person view could work by locking the VRIK body fully to the animation, and locking the VR view to the head position of the PC model - with the view direction relative to head position in the animation, modified by the actual turn of the VR gear. I know in practice that's not easily attainable though, if at all.

 

Finally got the Defeat working (mostly) the way I wanted - had to basically disable the way it kills player in some situations, and the timed disabling of the mod on player after it's played a scene, and the settings that limit the creature races (to none, with SL light). After that with essential player option it works as an.. interesting 'death alternative' mod. : ) Now just need to get the SLAL working to get the alternate animations loaded with their full tag lists. I do wonder if that'll help at all with the position issues though, or if that's something else.

[prinyo]

3 hours ago, reikiri said:

the 'clone' option works really well on many of animations, just has position issues on some of them.

Can you check if yo have the same issues with the "stable" version of the patch (the one without VRIK in the name)? The clone is a "standard" NPC, there should be no specific problems with it. But it is possible some of the  changes I have made in order to integrate VRIK have broken things. The next step is to merge the two, but first I need to decide which of the two approaches is better (which of the VRIK related versions works better).

 

3 hours ago, reikiri said:

with the view direction relative to head position in the animation, modified by the actual turn of the VR gear.

There is an option in the SL Light MCM that will lock the position of the headset, but it is not possible to lock the rotation. When I asked the author of VRIK about this he said he can't do it. What I can't understand at the moment is why at the start of some animations the body is facing the wrong direction and you need to rotate in RL to align. If we can be sure the body will always start in the correct direction there are things that can be done further.

 

3 hours ago, reikiri said:

Now just need to get the SLAL working

If you find a way to do that I'll be thankful if you let me know how you did it. I'm still not sure if I don't have setup issues with PapyrusUtilVR.

[reikiri]

On 10/23/2019 at 9:58 AM, prinyo said:

Can you check if yo have the same issues with the "stable" version of the patch (the one without VRIK in the name)? The clone is a "standard" NPC, there should be no specific problems with it. But it is possible some of the  changes I have made in order to integrate VRIK have broken things. The next step is to merge the two, but first I need to decide which of the two approaches is better (which of the VRIK related versions works better).

I'm suspecting it's not connected to clone, but rather specific animation + gender combination, and probably whatever mod initiates the scene (and places the actors into it).. which would mean the same issue should show even when placing regular NPCs into same scene. I can try to do some experimenting on that, probably not before weekend.

On 10/23/2019 at 9:58 AM, prinyo said:

There is an option in the SL Light MCM that will lock the position of the headset, but it is not possible to lock the rotation. When I asked the author of VRIK about this he said he can't do it. What I can't understand at the moment is why at the start of some animations the body is facing the wrong direction and you need to rotate in RL to align. If we can be sure the body will always start in the correct direction there are things that can be done further.

Yes, but the body still rotates along with the headset - which limits how much you can actually look around, and also breaks things entirely if the initial view direction is wrong (e.g. eyes on your back). I haven't found a setting on VRIK that would limit the way the body responds to turning your head - at least not to that extent. I'm also seeing the same 'stuttering' that's mentioned earlier on the thread.. interestingly my experience on it was  similar - I didn't see it initially, but at some point it started to show up.. and then it seems to be constant issue. It does look like the headset position is 'off' from where VRIK would like to place it.. and the view kind of slides quickly to the headset position.. snaps back to where VRIK body is, and then slides to where game thinks headset should be - repeating that infinitely. My current thought is, the 'facing in wrong direction' is in most cases - if not all of them - the same thing that causes the displacement.. e.g. actors are placed in wrong slots in the scene but still use correct animations. I did notice when I used the 'realign' feature, that at least on one instance it actually placed both actors into SAME animation and I think position, when it realigned them. So I think somewhere in the code the "slot" gets confused, for some of the actors at least. Again something I'd need to investigate further to make more sense of it.

On 10/23/2019 at 9:58 AM, prinyo said:

If you find a way to do that I'll be thankful if you let me know how you did it. I'm still not sure if I don't have setup issues with PapyrusUtilVR.

If I get a chance to look into that and actually figure it out, I'll toss you whatever changes I'd do on scripts to make it work. Given that SKSEVR has apparently some limitations (NIoverride isn't supported, UILIB crashes game when calling UI), it's not impossible that PapyrusVR would also lack some functionality. However simply loading up animations from external mod instead of using the defaults scripts from within SL(light), should be entirely possible, although there is a possibility that it would also require some tweaking/rewriting on SLAL itself.

 

-- edit --

About SLAL - I did a quick test. It installs fine, it sees animation packs.. I can toggle the ones I want to install, and click to register them. It tells me It has registered the animations, and from there on - even saving and reloading the game - it remembers which animations were toggled, and it shows them as having registered.

 

The animations don't actually show up on the SL light list of animations, however that list is broken for me at any rate. It only shows 128 animations on any category - first page (full) has 62 rows on two columns for 124, and second page shows 4 animations, for total of 128 which I'm assuming is some internal array size. The rest of the pages are empty.. but it does have varying number of pages which I imagine may be related to actual number of animations. Regular animations show 4 pages for me (two empty) and creature animations shows 3 pages (one empty).

 

So I wouldn't discount the possibility that the issue isn't so much in registration process but in some internal array or array handling. But That's just a quick thought on it.. I'll need to have a look next weekend if I get a chance.

[reikiri]

Actually.. I think SLAL probably works.

 

I did another test, looking at the rebuild & clean page of SL, it shows the number of regular and creature animations. I ran SLAL on Babo creature animations, and the number of creature animations on SL went up. So I'm thinking it actually registers the animations with SL, and they just don't show up on the list, because the list only shows 128 animations. Though, I haven't actually tested whether those new animations play. I'll need to check on that at some point. When I have time, I'll try to just strip out all the default animations and use SLAL to register some - and see if it works like intended.

[prinyo]

4 hours ago, reikiri said:

I'm also seeing the same 'stuttering' that's mentioned earlier on the thread.

There are two different things that can be perceived as stuttering:

1. The first one is the camera shake that happens when the PC is moved rapidly to a new place. This was also an issue in SSE as Vinfamy actually added code to work around it. This can happen even when using translateTo() if the speed of the translation is too fast. My solution for this is to completely remove all teleporting around, have the scene always happen where the player currently is located and gently slide them in the scene. However I still sometimes see the stuttering during preparation stage - while the NPCs and PC are within eachother. But after the animation starts the stuttering stops.

If you have this during animations you can disable the disabling of player controls in the MCM and in a stuttering animation try to run forward with the controller. There will be some rubberbanding and you will be snapped back with no more shaking. But with the latest 2 versions of the patch I don't expect this to happen.

 

2. The second one is the VRIK body fighting the animation. It will switch quickly between the position the animation wants it to have and the calculated standing pose, There are two option that tell VRIK to stop doing that - that basically shut the IK down. In the September version of the patch this is done at the preparation stage so when the body enters the animation it is already prepared. In the October version however  this is done after the animation starts. If for some reason it doesn't trigger or gets delayed then you would have this "fighting".

The change is an attempt to fix the problem that appears when the animation itself turns the body around. With the IK active the camera seems to rotate together with the body, when it is off it doesn't so end up looking at the back of your head. In my current testing it seems the fix has worked since I haven't seen the back of the head for some time (the October version).

I think whatever the final solution will be there will probably need to be a second or two of black screen at the preparation stage (like FG offers now) because it can feel creepy in VR.

4 hours ago, reikiri said:

I haven't found a setting on VRIK that would limit the way the body responds to turning your head - at least not to that extent

There is a tolerance setting - how far you can rotate your head before the body follows. There is also the Papyrus setting to block rotation that is exactly what we would want to use as it prevents the body from rotating at all. But before we can use it we need to be sure that it will always start correctly rotated.

You can find all Papyrus options in vrik.psc. There is also commented out part in the VRIK MCM script that allows those options to be turned on and off in real time.

 

 

4 hours ago, reikiri said:

Yes, but the body still rotates along with the headset

The body rotates following the headset, but not the other way around. The camera will not rotate when the body rotates - this is what he said he can't do. I suspect that he can (like he did it with the position), but he would need to do more testing and debugging and he has stopped working on the mod.

 

4 hours ago, reikiri said:

Given that SKSEVR has apparently some limitations (NIoverride isn't supported, UILIB crashes game when calling UI), it's not impossible that PapyrusVR would also lack some functionality

The SKSE part works fully. What breaks is interface elements and other graphic functionality (no idea how to formulate this). But the scripting side works.

 

4 hours ago, reikiri said:

So I wouldn't discount the possibility that the issue isn't so much in registration process but in some internal array or array handling.

When I experimented with it I got to the situation where SLAL was saying that the animations are registered, but the actual SL animation registry was completely empty, the animations page in the MCM was empty and the only animation SL would actually use was a female solo one, You need to enable several lines in SL Light to make it work.

My understanding is that SLAL is writing an JSON file that SL is reading.

[reikiri]

5 hours ago, prinyo said:

2. The second one is the VRIK body fighting the animation.

This feels like it's what I'm getting. I can even see the direction of the stutter change when I move the headset around - like it rapidly tugs 'towards the headset', only to be yanked back to scene position.

5 hours ago, prinyo said:

There is a tolerance setting - how far you can rotate your head before the body follows. There is also the Papyrus setting to block rotation that is exactly what we would want to use as it prevents the body from rotating at all. But before we can use it we need to be sure that it will always start correctly rotated.

You can find all Papyrus options in vrik.psc. There is also commented out part in the VRIK MCM script that allows those options to be turned on and off in real time.

 

The body rotates following the headset, but not the other way around. The camera will not rotate when the body rotates - this is what he said he can't do. I suspect that he can (like he did it with the position), but he would need to do more testing and debugging and he has stopped working on the mod.

I suppose technically everything is possible, just a matter of just how much work it would require - and how easily it would break when/if new version of game is released. The tolerance setting wasn't enough to fully stop the rotating, I'll see if I can do something with those commented MCM options. You'd still need to be able to rotate/move the bodies between stages of animation too, which could be tricky.

5 hours ago, prinyo said:

The SKSE part works fully. What breaks is interface elements and other graphic functionality (no idea how to formulate this). But the scripting side works.

 

When I experimented with it I got to the situation where SLAL was saying that the animations are registered, but the actual SL animation registry was completely empty, the animations page in the MCM was empty and the only animation SL would actually use was a female solo one, You need to enable several lines in SL Light to make it work.

My understanding is that SLAL is writing an JSON file that SL is reading.

Well the settings are stored in a file, but it looks like AnimationFactory handles reading the file and calling SL functions directly to register them. MCM is even now half-empty at least for me (the 128 animations showing per category), I'm guessing the animations that aren't showing might also not be registered with SL, just having empty slots, which show as such on MCM too.

[prinyo]

15 hours ago, reikiri said:

Well the settings are stored in a file, but it looks like AnimationFactory handles reading the file and calling SL functions directly to register them.

My understanding at the moment is that

RegisterOtherCategories() in the end of LoadAnimations() in sslAnimationDefaults.psc needs to be uncommented.But I'm not sure if it is important for SLAL.

 

 

Also in sslAnimationSlots.psc:

    ;ModEvent.Send(ModEvent.Create("SexLabSlotAnimations"))

because SLAL is waiting for that.

[reikiri]

18 hours ago, prinyo said:

My understanding at the moment is that

RegisterOtherCategories() in the end of LoadAnimations() in sslAnimationDefaults.psc needs to be uncommented.But I'm not sure if it is important for SLAL.

 

 

Also in sslAnimationSlots.psc:

    ;ModEvent.Send(ModEvent.Create("SexLabSlotAnimations"))

because SLAL is waiting for that.

It seems to go like this:

--> slalMCM
RegisterAnims
    page = 0 --> num = Loader.registerAnimations()
    page > 0 --> num = Loader.registerCategoryAnimations(CurrentPage)
--> slalLoader
- animID = animation ID to register
- anims = instantiate JMap of AnimID -> Animation Info
- enableState = instantiate JMap of AnimID -> bool (is this animation enabled)
- catAnims = JArray of animation IDs for the category

...either case, loop through 'animID' strings that are animation IDs, and register them with
registerAnimIfEnabled(animID, anims, enableState)

--> slalAnimationFactory
sslAnimationSlots animSlots = getSlots(animInfo)
RegisterAnimationCB(animSlots, animID, "OnRegisterAnim")

- getSlots = return either Slots or CreatureSlots depending on animation, which are references to SexLab animation slot arrays
--> slalAnimationFactory
InitAnimSlot(animSlots, id, Registrar, Callback)
--> slalLoader
OnRegisterAnim(int id, string animID)
stuff info into 'anim' object
--> sslBaseAnimation
anim.Name =        (inherited from sslBaseObject)
anim.SoundFX =    (StageSoundFX[0])
anim.AddPositionStage x1..n
anim.SetStageSoundFX x1..n
anim.SetStageTimer x1..n
anim.SetTags()
anim.save(id)

 

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

On the sslBaseAnimation, SL Light has removed 'getSchlong', replaced the json utility with vinutility, and basically butchered away the creature race handling and the ExportJSON. There's also some snips from handling stages and positions I think.

 

It's not just that. sslAnimationFactory has cut off mod event stuff from RegisterAnimation, and cut off the whole RegisterCategory.

And for sslAnimationSlots - commenting out the mod event is the LEAST of the changes in it really. The entire script has been rebuilt, with papyrusUtils cut away from it, and I think LOTS of stuff hard coded in to make it work.

 

I think there's a lot of stuff snipped away all around SL Light, that SLAL would want. It goes back to my original thought about, whether it would be easier to try to restore all of that into SL light, or just see what really needs to be cut off from current SL full build to make it work in VR. Either way it's likely it would go beyond the current scope of the SL light VR patch, but it wouldn't be the first time I did some heavy customizing to make Skyrim work the way I want it to. >.>

 

Right now, I think for me the most likely path would be to pick the SL full beta 7, do a quick comparison to SL light to see what was changed, and try to understand why. And to see how that corresponds to the SL light VR patch. Then try to make SL Full work with VR (cut off anything nioverride, and see if everything it uses from papy/json works.. or if I'd need to alter/cut some of that).. and then see if I can modify the SL Light VR patch to work with the VR version of SL Full.

 

And biggest issue - if sexlabUtil is compiled to latest SKSE, and won't work on SKSEVR, that may be a royal pain.  I don't really know where that dll is used.

[prinyo]

10 hours ago, reikiri said:

butchered

I strongly disagree with this and similar words. SL Light was created to work with no SKSE ( so no PapyrusUtil) and no SkyUI. For me it was done quite well - with preserving the original code in place and with finding alternatives to make as much possible functionality work. 

Now we are trying to get to a middle ground. Which way to use is a question of preference, for me personally the more pragmatic approach is to start from SL Light. Not only because the code is already there and I just need to decide what to uncomment, but also because there is almost no risk of breaking something else. If I haven't decided to publish the patch and was doing it only to accommodate my specific needs I would have probably been more "adventurous". But I can't risk publishing changes I do not completely understand or in other way risking to break people's games. For my way of thinking and programming this works best. Admittedly my own needs and wants play a role in my priorities - first enabling mod events to make some mods work, then VRIK integration, then SLAL and so on.

 

I still think SLAL can be enabled relatively easy, I have a feeling I missed some small detail somewhere, but I only spent an hour trying to make it work. The idea now is to combine all 3 versions that are currently uploaded into one with settings and then - when there is an unified code base, start seriously handling the next issue - SLAL.

 

The way I see it if the tags of the creature animations are the only reason you want SLAL then the fastest and most secure way is to simply add the missing tags in sslAnimationDefaults. It can be tedious but it will probably take about an hour and with no risks of complications.

[reikiri]

1 hour ago, prinyo said:

I strongly disagree with this and similar words. SL Light was created to work with no SKSE ( so no PapyrusUtil) and no SkyUI. For me it was done quite well - with preserving the original code in place and with finding alternatives to make as much possible functionality work. 

Now we are trying to get to a middle ground. Which way to use is a question of preference, for me personally the more pragmatic approach is to start from SL Light. Not only because the code is already there and I just need to decide what to uncomment, but also because there is almost no risk of breaking something else. If I haven't decided to publish the patch and was doing it only to accommodate my specific needs I would have probably been more "adventurous". But I can't risk publishing changes I do not completely understand or in other way risking to break people's games. For my way of thinking and programming this works best. Admittedly my own needs and wants play a role in my priorities - first enabling mod events to make some mods work, then VRIK integration, then SLAL and so on.

 

I still think SLAL can be enabled relatively easy, I have a feeling I missed some small detail somewhere, but I only spent an hour trying to make it work. The idea now is to combine all 3 versions that are currently uploaded into one with settings and then - when there is an unified code base, start seriously handling the next issue - SLAL.

 

The way I see it if the tags of the creature animations are the only reason you want SLAL then the fastest and most secure way is to simply add the missing tags in sslAnimationDefaults. It can be tedious but it will probably take about an hour and with no risks of complications.

Fair enough - when I say 'butchered', I mean:

Form[] property CreatureRaces hidden
    form[] function get()
        string[] Races = sslCreatureAnimationSlots.GetAllRaceIDs(RaceType)
        int i = Races.Length
        Form[] RaceRefs = Utility.CreateFormArray(i)
        ;while i
        ;    i -= 1
        ;    RaceRefs[i] = Race.GetRace(Races[i])
        ;endWhile
        ;return PapyrusUtil.ClearNone(RaceRefs)
    endFunction
endProperty

it's simply cut out, dropping the ball .. the whole CreatureRaces returning a 'none'. There's no way any mod that relies on them will work with that. F.ex. the way I got Defeat to work with creatures, I had to cut out the test for creature races from that mod as well. (Why does it even call the getallraceids, and create the racerefs form array - instead of just doing 'return none'?) It's similar issue than what MakeActorArray faces in sexlabutil, and could have used similar solution - but of course there's other issues with handling creatures and races.. I don't know if all of them could be solved reasonably without papyrus utils.

 

On that one I would have gone with...
 

Form[] property CreatureRaces hidden
    form[] function get()
        string[] Races = sslCreatureAnimationSlots.GetAllRaceIDs(RaceType)
        int i = Races.Length
        Form[] RaceRefs = Utility.CreateFormArray(i)
        int n = 0
        while i
            i -= 1
            RaceRefs[n] = Race.GetRace(Races[i])
            if RaceRefs[n]
                n += 1
            endIf
        endWhile
        return VinUtil.ResizeFormArray(RaceRefs, n, none)
    endFunction
endProperty

Overall just making SL work without SKSE *is* pretty amazing. It's also true that SKSEVR has come a long way, which is why I'm looking at it from that 'adventurous' perspective, and trying to figure out which parts of the SL are still outside what SKSE(VR) is capable of doing. If it can handle almost everything, then the question is if there's still a strong enough reason to use SL light as a base (which among other things is branched from older version of SL, so misses any possible bug fixed up to beta 7 - and will continue to miss any new ones down the line), or whether it would be easier to just disable the few things that still don't work.

 

NiOverride as far as I could tell, only really removes/enables the high heels effect - which wouldn't work in Skyrim VR at the moment anyway.. so that's moot. SexLabUtil.dll however is recompiled on the new Beta 7, and I'm assuming it needs to be compiled to specific SKSE version - so it would be unavailable.. meaning any functions it provides, will be too. Unfortunately while I've done a fair bit of papyrus scripting, my experience in dealing with SKSE directly is essentially zero.. and I can't really say how much SL actually relies on that dll. Obviously Ashal wouldn't have made it if it wasn't important enough.

 

Is it possible to make SLAL work with SL light? By enabling enough of the removed code - yes, obviously (unless current SLAL relies on something that was introduced after SL light branched from SL full.. which I seriously doubt). However I don't think it's possible to restore creature animations into functional state in a way that supports mods that expect to be dealing with SL full, without putting back in a *lot* of the code that's been snipped away to make it all work without papyrus utils.

 

-- edit --

Also, I think the whole VinUtil - almost 4000 lines of script - is basically made to work around not having papyrus util, with solutions that are not as effective as papyrus util itself IF you have access to it. So a lot of code that does work, would probably work more efficiently if it was reverted to use papyrus utils.

[prinyo]

4 hours ago, reikiri said:

the whole CreatureRaces returning a 'none'.

So this was cut out because of PapyrusUtil.ClearNone(RaceRefs). I think SKSE plugins are used in cases like this for data processing (like rearranging or clearing up arrays) because it is way faster than doing it in Papyrus. If you recover the lines it will probably be OK. I'm not aware of the context this exists - I have seen in my own game that creature animations do work (in my case triggered by Random Sex). From what you said Defeat was looking for allowed creatures, but not all mods do. It is possible that while testing Vinfamy didn't encounter this problem.

 

In my eyes SL Light offers some performance benefits as some features are completely disabled - enjoyment, experience, skills and so on. I don't know what mods use them (in my experience the mods keep track of those things separately), but they can have impact on the performance. In my game the animations start really quickly while in Oldrim the actors would stay nested inside each other for quite some time before the animation. With VR been more taxing on the PC than Oldrim any optimization is welcome.

 

<edit>

Actually they are used for the expressions. I can see how some people would prefer to have them enabled.

</edit>

 

4 hours ago, reikiri said:

only really removes/enables the high heels effect - which wouldn't work in Skyrim VR at the moment anyway

I have zero understanding about that, but I know that Lazy Heels (Lazy Tools) works as it made actors "float" above the ground. I tried it while patching it for the Select NPC for MCM spell.

 

Quote

Also, I think the whole VinUtil - almost 4000 lines of script - is basically made to work around not having papyrus util, with solutions that are not as effective as papyrus util itself IF you have access to it. So a lot of code that does work, would probably work more efficiently if it was reverted to use papyrus utils.

 

I think it is a workaround for both PapyrusUtil and SexlabUtil. Reverting those changes will be a serious task and it goes against my current approach to only enable/add what is needed. (In the spirit of "if it is not broken don't fix it".)

I consider the VR patch to be a temporary thing - until Ashal publishes the dll recompile that he has already done long time ago. I can imagine several reasons why he isn't publishing it yet, but at some point he will. When that happens I'll delete the patch. So this is only to allow people (and me) to play with SL mods in the mean time. That's why I'm not so enthusiastic in doing bigger changes. I consider all the "big" features working and for probably 90% of people the current state of the patch will cover all they need. SLAL is "good to have" but at the moment there are probably 1 or 2 new packs that are not already included. There are specific cases like your situation where I'm ready to help if I can, but I'm thinking more about quick fixes than bigger development. The source code of the SL dll used to be available on GitHub but no longer is. If it was we would have had it recompiled for VR  on day one - the SKSE dev that worked on SKSEVR offered to recompile stuff. So my attitude towards the patch is - try to enable features that people need or find other solutions (like patching mods) so they can play until the full SL gets published.

[reikiri]

5 hours ago, prinyo said:

In my eyes SL Light offers some performance benefits as some features are completely disabled - enjoyment, experience, skills and so on. I don't know what mods use them (in my experience the mods keep track of those things separately), but they can have impact on the performance. In my game the animations start really quickly while in Oldrim the actors would stay nested inside each other for quite some time before the animation. With VR been more taxing on the PC than Oldrim any optimization is welcome.

Possible, but I'm not certain of that. SKSE plugins can offer huge performance boost by offloading things from papyrus to native dll code. Of course if you hybridize it fully to the point that you use the plugins where possible, but just disable some functions - then you could likely get some boost. On the other hand 32-bit oldrim isn't comparable to 64-bit SE or VR in any way.. though I think the SE version of SL had problems with slow starting of animations at least in previous versions - think that was listed as a known issues.

 

Well, I did a quick test:

- installed current SL full beta 7

- converted all sexlabutil functions to regular papyrus functions - there's going to be some performance impact, but it works without changing rest of the code

- spliced in the SLL VR patch

The result:

- clone option works

- 1st person option works, I get no stutter

- SLAL works

- mod events fire as intended (e.g. it triggers drip when aroused etc)

Downsides:

- there's issues with initial position in scene as well as scene starting location

- I got brief blackscreens between scene changes. It actually wasn't -too- bad, and for VR it might even be desirable when positions change

- I couldn't get creatures to work on initial test. SL matchmaker fizzles on them, which suggests SL doesn't think they are valid targets

 

There's also something in the .getInstance() call of SL solutions integration script that refused to compile for me, so I had to disable the SL solutions integration. But for a quick job of few hours, without fully understanding what all the SLL VR patch is supposed to do.. for me that feels really promising, so I'll look a bit further into that. That -is- just a quick test with a few scenes initiated through SL match maker, so I can't say anything conclusive yet.

 

If you have any interest in looking at it, I can drop in the modified scripts - a winmerge check between them and original beta 7 source shows the changes pretty easily.

[prinyo]

2 hours ago, reikiri said:

[...]

I need to sleep on this in order to reply fully, but just a few things before I disappear until Monday,

 

2 hours ago, reikiri said:

SL matchmaker fizzles on them

The SL Matchmaker fizzles on everything more often than it doesn't. It is a problem with the mod. Use the Oldrim version or some other mod to trigger scenes. For example Random Sex.

 

2 hours ago, reikiri said:

there's issues with initial position in scene as well as scene starting location

In the versions of the patch that has VRIK integration the location of the scene is forced to be the location of the player character when the scene involves it. With the other version of the patch it will probably not happen. But it is interesting to know what the issues are exactly.

 

2 hours ago, reikiri said:

- 1st person option works, I get no stutter

- SLAL works

You now have a setup where the files involving the execution of the scenes come from the patch and the maintenance and support scripts are from the full SL. This means that unlocking the SLAL integration is somewhere in the files the patch currently doesn't touch (otherwise the file would have been overwritten with the SL Light version).

About the 1st person option - something in your test setup has changed or the animations you happened to see now are different from before. Because everything that would influence how VRIK behaves is in the patch files that in your current setup are the same as before. In my experience it takes several scenes in several different location before I can understand what is going on.

Did you try rebuilding the animation registry? This is where my test broke. If it does work it means that animationdefaults and animationfactory are safe to use as is from the full SL. This also means that there are way less default animations. 

 

2 hours ago, reikiri said:

converted all sexlabutil functions to regular papyrus functions

How do you know what is in SexlabUtil? It and PapyrusUtil are made by the same person and they are both part of SL. It seems strange that they would have overlapping functionality.

This is actually the most important question. If we can get a version of the full SL that doesn't really rely on the SexlabUtil then I can reapply the changes for the clone and VRIK quite quickly and everything will work. But I have no idea what exactly is in the both dll files and if a workaround will actually work as expected.

[reikiri]

53 minutes ago, prinyo said:

The SL Matchmaker fizzles on everything more often than it doesn't. It is a problem with the mod. Use the Oldrim version or some other mod to trigger scenes. For example Random Sex.

I think this was oldrim version. It's been reliable, and the issue is consistent - defeat doesn't trigger creature anims, hentai creatures won't work. This will probably be easy to fix, I may simply need to reset animation registry, so not worried about this yet.

53 minutes ago, prinyo said:

In the versions of the patch that has VRIK integration the location of the scene is forced to be the location of the player character when the scene involves it. With the other version of the patch it will probably not happen. But it is interesting to know what the issues are exactly.

Yes, I'll need to look more closely through the parts that were changed, and especially compare it to changes I left out. It was partially purposeful - I wanted to try to preserve as much of the original positional handling as possible, probably just need to integrate more of the VR patch changes. I honestly wasn't expecting it to work *at all* on first try.. I was really surprised how well it did.

53 minutes ago, prinyo said:

You now have a setup where the files involving the execution of the scenes come from the patch and the maintenance and support scripts are from the full SL.

No, that's not what I meant. I didn't just overwrite files. When I said 'spliced', I meant I took the beta 7 files and the VR patch files side by side, and manually applied some of the changes of the VR patch into beta 7 - but nowhere near all of them. I left all the papyrus calls for example as is, pure beta 7. This means f.ex. the export and import work as they do in SL full. I also added the VR patch settings to the export and import of the profile that SL7 does. It's going through all of the changes, and trying to figure out what they actually do, that took me a few hours. If I had just overwritten them, there wouldn't be any point to offer you your own files back to have a look at : )

53 minutes ago, prinyo said:

About the 1st person option - something in your test setup has changed or the animations you happened to see now are different from before. Because everything that would influence how VRIK behaves is in the patch files that in your current setup are the same as before. In my experience it takes several scenes in several different location before I can understand what is going on.

Did you try rebuilding the animation registry? This is where my test broke. If it does work it means that animationdefaults and animationfactory are safe to use as is from the full SL. This also means that there are way less default animations.

... and so this doesn't really apply. Except that yes, I was thinking about the same thing - will need to reset the registry. But it *does* mean that anim defaults and anim factory can be used with Skyrim VR 'as is' - as long as a number of other changes are reverted for them to work properly. Also keep in mind that I did essentially remove the SkyrimUtils dll by replacing all of it's functions with papyrus.. which will reflect in a lot of places. I figured it was much cleaner to do it like this.

Yes, there's hardly any 'default' animations, but I think that's a good thing. You could still simply bundle ALL the current SL Light anims into single SLAL, and include it as an option - for basically the same result.. as long as SLAL works. And meanwhile it gives people the opportunity to leave them out and instead pick and choose what they want - without going past the Skyrim animation registry limit (well, behavior registry, but kind of same thing).

53 minutes ago, prinyo said:

How do you know what is in SexlabUtil? It and PapyrusUtil are made by the same person and they are both part of SL. It seems strange that they would have overlapping functionality.

They use different script as a wrapper to integrate with papyrus. PapyrusUtil (VR) uses ActorUtil, JsonUtil, MiscUtil, ObjectUtil, PapyrusUtil and StorageUtil - check for any functions there with 'native' tag, those are the ones that relay calls for the dll. For SexlabUtil the wrapper is SexlabUtil script - same deal, anything with 'native' tag will pass calls to SexlabUtil.dll plugin.

 

Papyrus util is not part of Sexlab. It's included in sexlab, but that's different. It's used far and wide elsewhere (you can get it from here: https://www.nexusmods.com/skyrimspecialedition/mods/13048 along with a mile long list of mods that use it) SexlabUtil - as name implies - is specific to SL framework, although technically you could use it elsewhere.

-- edit --

The interesting thing here is, if I can make this truly work like this, it means with a few changes, the same VR patch could have a working version for SL full to patch it to be VR compatible (would just need to add the sexlabUtil disabler patch). The downside though, while SL Light is - I think - kind of frozen code base, SL full is far from it... and a patch like that would work only for the one version it's made for. So as soon as beta 8 comes out, it would either need to be re-built, or anyone using it would need to stay in beta 7.

[prinyo]

2 hours ago, reikiri said:

They use different script as a wrapper to integrate with papyrus. PapyrusUtil (VR) uses ActorUtil, JsonUtil, MiscUtil, ObjectUtil, PapyrusUtil and StorageUtil - check for any functions there with 'native' tag, those are the ones that relay calls for the dll. For SexlabUtil the wrapper is SexlabUtil script - same deal, anything with 'native' tag will pass calls to SexlabUtil.dll plugin.

Yes, there are Papyrus scripts to interface all those parts. But what you said was:

Quote

converted all sexlabutil functions to regular papyrus functions

What I understand from this is that you have found functions in PapyrusUtil that are identical to SexlabUtil. Or you have found which regular papyrus functions do the same thing as the PapyrusUtil functions. But how do you know if they are doing the same thing if you don't know what the dll functions do exactly?

 

In other words:

Quote

(would just need to add the sexlabUtil disabler patch).

What is the disabler patch? What do you do with the SLUtil functions?

 

 

However this kind of clears the way forward - all "native" calls will have versions in vinutil. So redirecting all those in the full SL scripts to vinutil while keeping the papyrusutil ones in place would produce exactly the result we want.

 

Quote

The downside though, while SL Light is - I think - kind of frozen code base, SL full is far from it... and a patch like that would work only for the one version it's made for. So as soon as beta 8 comes out, it would either need to be re-built, or anyone using it would need to stay in beta 7.

SL Light was allowed to stay an independent standalone entity, I guess this would also be allowed as long as the name doesn't suggest it is the "official" VR version. And then in a week or two changes can be merged.

 

[reikiri]

1 hour ago, prinyo said:

Yes, there are Papyrus scripts to interface all those parts. But what you said was:

What I understand from this is that you have found functions in PapyrusUtil that are identical to SexlabUtil. Or you have found which regular papyrus functions do the same thing as the PapyrusUtil functions. But how do you know if they are doing the same thing if you don't know what the dll functions do exactly?

 

However this kind of clears the way forward - all "native" calls will have versions in vinutil. So redirecting all those in the full SL scripts to vinutil while keeping the papyrusutil ones in place would produce exactly the result we want.

I meant papyrys script functions, not papyrus util functions. : ) Writing scripts directly into SexlabUtil.psc that replace the native calls with comparable functionality. I had to just disable the vehicle fix and the HasKeywordSub though - because I have no idea what VehicleFixMode does, and while I know what HasKeywordSub does, I don't know how to get full list of keywords from an object.. and doing that, and searching for substring within them, would be very costly.. for the limited functionality it offers. Although if I did have a way to pull that list, I'd still write the code just to be complete.. and make MCM checkbox to enable it for those who might need it to get some mod to work properly.
-- edit --
this is the modified sexlab util script. There's no need to put redirect hacks all over the SL full because it's all already redirected to SexlabUtil script and can be handled there. That's the whole point of having a wrapper like that - so you can use the wrapper to change where those calls go from one place.

-- edit2 --

Ah, crap... I totally missed the MakeActorArray. That might be why creatures didn't work.. I'll need to write a function to replace that one too. Will upload a new file when I get it done.

-- edit3 --

There.. better. May very well have been an issue with some things. Had to make another fix on the minMaxValue searches too.

 

SexLabUtil.zip

[prinyo]

29 minutes ago, reikiri said:

There's no need to put redirect hacks all over the SL full because it's all already redirected to SexlabUtil script and can be handled there.

Yep, but you still need to know what exactly the function does. But I do agree that for most of them it is obvious from the name. And you can redirect them from the wrapper/helper/util, whatever you want to call it.

And some of those functions are not actually in use. For example FloatMinMaxIndex and FloatMinMaxValue are only used for debug, so with an additional check they can be avoided for performance reasons. 

 

I need to say my approach to all this was a bit stupid... Staring from SL full and not from SL Light is the better approach actually.

[prinyo]

1 hour ago, reikiri said:

There.. better. May very well have been an issue with some things. Had to make another fix on the minMaxValue searches too.

It is 2:30 at night here so I would like to look at this and test it in the next few days.

But it does seem that the SLLightVRPatch is dead and instead there will be ... SLVRCE (community edition)?

I wonder if it will need a fresh install.

 

[reikiri]

31 minutes ago, prinyo said:

Yep, but you still need to know what exactly the function does. But I do agree that for most of them it is obvious from the name. And you can redirect them from the wrapper/helper/util, whatever you want to call it.

And some of those functions are not actually in use. For example FloatMinMaxIndex and FloatMinMaxValue are only used for debug, so with an additional check they can be avoided for performance reasons. 

 

I need to say my approach to all this was a bit stupid... Staring from SL full and not from SL Light is the better approach actually.

If you already had access to fully functional papyrus utils VR and SKSE VR then at that point SL Full becomes easier. Prior to that SL Light was the only option really. Yes, I didn't find those functions anywhere, but there's still a possibility that some mod that uses sexlab decides to use those - and since they were easy enough to make, figured it's better to cover all bases.

 

the keyword sub function I couldn't guess on, but it was mentioned on one SL thread, which explained it well enough (it checks if there are any keywords on object that match the string given as argument.. so argument 'nude' would match keyword 'nudesuit' or 'nevernude', or whatever. But since I couldn't find a way to check what all keywords an object has, couldn't build that with pure papyrus script. I think it's rarely used function though, so I just left it disabled for now.

 

After the fixes, and resetting the animation registry, the creatures still wouldn't work, the scenes still start at what I think is probably 0,0 position on cell, and positions within the scene itself are off (at least on some scenes, again). But it's all still pretty much what I expected to see initially even under best circumstances. The basics are working anyway.

[reikiri]

17 hours ago, prinyo said:

It is 2:30 at night here so I would like to look at this and test it in the next few days.

But it does seem that the SLLightVRPatch is dead and instead there will be ... SLVRCE (community edition)?

I wonder if it will need a fresh install.

 

"Houston, we've had a problem..."

 

Unfortunately it seems not all SexLabUtil functionality is funneled through the SexLabUtil script - there's more all over the place. Enough I think that SL will not work properly without it. Creatures for one, the whole racekey etc goes back to native functions. Position adjustments use native functions. Actor skills use native functions (which is why the journal wouldn't work). I believe that's the reason so much has been cut away from SL light (and not all of it gracefully).

 

I'd say keep to what you're doing with SL Light. There's no point trying to get SL full to work in Skyrim VR, not without SL utils. But do a global search from all of SL (light) code for 'native'. It might save you some headache down the line if you're trying to restore more of the functions.

 

-- edit --

Just for the records - by splicing in the OffsetCoords code from sslActorAlias of SL Light (among the other changes I had brought over), I got the NPC part working - but creatures did not. Enabling the commented out 'lockRotation' and 'lockPosition' made it *perfect* for some animations, but not so much on others. On some animations there's horrible stutter, on some it fails to reach the right position - but on those that it works, it's spot on.

 

What you'd need is a way to make the VRIK body settle on right position on all animations, and then enable those two options - and possibly disable/enable them on scene changes if they contribute on not being able to get on right position. Either way, that's really, really close. But yeah, without SexLabUtil, it'll always be crippled in some ways.

[EphemeralSagacity]

*crosses fingers*  from here: https://www.loverslab.com/applications/core/interface/file/attachment.php?id=232035 I compiled a sexlabutil.dll for sksevr.

 

I spent too much time getting it to compile but it looks like it "might" be good to work with the full beta 7.  Missing the VehicleFixMode.  The changes for the full beta 7 version checks in the scripts have to be adjusted for sksevr, papyrusvr etc still but it looks "goodish".  Here is hoping its good if someone wants to kick this around.  Let me know whatever other native methods it might be missing hopefully we can fill those gaps in with vinfamy's stubs.  I'll give it more of a spin later.  All I did so far was do a "woot...I can boot and it all installs!"

SexLabUtil.dll

[reikiri]

2 hours ago, EphemeralSagacity said:

*crosses fingers*  from here: https://www.loverslab.com/applications/core/interface/file/attachment.php?id=232035 I compiled a sexlabutil.dll for sksevr.

 

I spent too much time getting it to compile but it looks like it "might" be good to work with the full beta 7.  Missing the VehicleFixMode.  The changes for the full beta 7 version checks in the scripts have to be adjusted for sksevr, papyrusvr etc still but it looks "goodish".  Here is hoping its good if someone wants to kick this around.  Let me know whatever other native methods it might be missing hopefully we can fill those gaps in with vinfamy's stubs.  I'll give it more of a spin later.  All I did so far was do a "woot...I can boot and it all installs!"

SexLabUtil.dll 737.5 kB · 1 download

Given that I was going through the beta 7 source and trying to either replace natices with pure papyrus, or disable them.. I'd say if it's slightly older version, it's still a *lot* easier. Thanks for this.

 

On another note - apparently lockrotation locks the rotation of the body (which is good), but lockposition locks the position of camera/viewpoint (which might be useful if managed properly).

 

On the other hand with lockrotation, moving the hmd around will still move the body around.. and between stages the hmd will not move - which means it'll pull the body out of alignment.. at least that's how I understand what's happening. So basically it's not "lockhmdtobody" so much as "lockbodytohmd".

 

If you use lockposition AND lockhmdtobody, the viewpoint (or camera) will be locked in place but the body will still move to initial scene position... and then the body will be essentially locked to static position in relation to the viewpoint - which means if you look around, the body will follow around at same position in your field of view.

 

So what you'd have to do I think:

- lockposition 1 (to prevent the viewpoint from moving)

- lockrotation 1 (to prevent the body from turning around with viewpoint)

- lockhmdtobody 0 (possibly - I *think* this may make the body part of the scene rather than tied to turning of the viewpoint - essentially make it 'NPC' rather than 'your body')

 

Then at the start of each stage, move the viewpoint AND the body into correct location. This might be the tricky part. Can you move the viewpoint when lockposition is set to 1? I think you might have to set lockposition 0 and lockhmdtobody 1, move the viewpoint, and then immediately lockposition 1 and possibly lockhmdtobody 0. But it's possible you can keep lockhmdtobody 1 on constantly (or it might not even matter), as long as the player model is never moved while lockposition 1 is in effect - having lockposition 1 on seems to pull the body out of alignment, and then bad things happen.

 

 

Either way, to make it work right, I think viewpoint would need to be disconnected entirely from the body, to keep the body aligned with animation.. and the viewpoint would need to still move together with the body between the stages. Whether the viewpoint should be locked in place so that moving the headset doesn't move it within game, I think is matter of preference. I don't think there's any reasonable way to make the viewpoint directly follow the movement of the animated body, unless there's an option to do that by counting the body as 'vehicle', possibly with similar effect to cart scene at the start of the game (where the cart would be the animated body).

 

Without the viewpoint following the animation of the body, some animations will not work right.. on the other hand the effect of those animations in itself would probably be difficult to handle without motion sickness, so I'm inclined to think of it more like a case of some animations just being basically incompatible with VR.

 

I'll need to do some more testing with the lockhmdtobody, should be much better chance for that if I don't need to put more time into messing with SexLabUtil legacy

 

[Raya]

3 hours ago, EphemeralSagacity said:

*crosses fingers*  from here: https://www.loverslab.com/applications/core/interface/file/attachment.php?id=232035 I compiled a sexlabutil.dll for sksevr.

 

I spent too much time getting it to compile but it looks like it "might" be good to work with the full beta 7.  Missing the VehicleFixMode.  The changes for the full beta 7 version checks in the scripts have to be adjusted for sksevr, papyrusvr etc still but it looks "goodish".  Here is hoping its good if someone wants to kick this around.  Let me know whatever other native methods it might be missing hopefully we can fill those gaps in with vinfamy's stubs.  I'll give it more of a spin later.  All I did so far was do a "woot...I can boot and it all installs!"

SexLabUtil.dll 737.5 kB · 1 download

Tried it... managed to get to the game, everything says it's loading... and installed, but animations won't launch ;/

[reikiri]

Tried the dll, and looks promising. Animations work fine for me, and it seems it restored a bunch of functionality. 'Course you need to do some changes to full SL to make it work with VR - basically add some of the stuff from the SL light vr patch into right scripts, and then recompile them. I'll go through it again, and see how actually having the native function working changes things. One thing I noticed immediately, the viewpoint now actually slides back to right position with the body - which is a -huge- change. However it still seems to be a location not defined by the body so much as the scene... I think. Basically, this opened up a lot of possibilities, but needs experimenting to figure out how to best use them.