Skyrim SexLab and VR

[reikiri]

12 minutes ago, prinyo said:

I'm blind..... Like if I was reading this today at the office with glasses I would have seen that it is -1 and would have guessed that it is a flag value. But at home am using a big TV as a monitor and usually do not wear glasses. And I really didn't expect the value corrections to happen at the final function, this is an interesting choice but it does make sense.

So it is my fault! This is exactly the function I was talking about all alone ( maybe it needs a global tag however). And because yesterday you specifically said you wont do it, causing me to leave the chat in protest, I was expecting something along the lines you were actually planning to do.

I'm really sorry about the confusion! It is my fault!

 

I kept it consistent with how SL itself does things - none of the API functions in SexLabFramework have global tags, and sslActorLibrary actually has 'getter' functions for accessing the sslSystemConfig, so I added VR specific configs into those, and accessed them in actor alias rather than the API. Making the checks in API would technically make the internal call slightly more efficient - either way changing it later wouldn't break anything.

[prinyo]

2 hours ago, reikiri said:

I kept it consistent with how SL itself does things

Ah, so you have abandoned the idea to make VRIK a hard requirement. That's good to hear.

 

But the function is still pretty much just an interface for VRIK and not a general function for preparing the PC. You can't for example enable the clone. You can only tweak VRIK settings.

And this was the example use case we had earlier in the thread - switch from clone in SL animations to 1st person in another mod. Or are you sure there will be a way to make VRIK behave exactly as a clone?

 

[reikiri]

53 minutes ago, prinyo said:

Ah, so you have abandoned the idea to make VRIK a hard requirement. That's good to hear.

 

But the function is still pretty much just an interface for VRIK and not a general function for preparing the PC. You can't for example enable the clone. You can only tweak VRIK settings.

And this was the example use case we had earlier in the thread - switch from clone in SL animations to 1st person in another mod. Or are you sure there will be a way to make VRIK behave exactly as a clone?

 

- VRIK will almost certainly be a requirement for SL VR patch. Running SL in VR without VRIK would be too much of a niche case to warrant the effort of splitting the code in every turn

- Using clone doesn't really need to prep the player in any way, there wouldn't be anything for the function to do. The clone is simply another NPC. To actually create the clone is simple enough that there's little point to do that through SL, when it's a) a feature I'm considering dropping in the first place, and b) it would mess with SLs internal working for several reasons (clone is tied to thread - but thread wouldn't exist without SL running the animation)

- I'm not sure if there's reasonable way to use the VR body for SL animation while still allowing the player to move freely around, not just in room scale, but by using controller to make it possible to use it while playing seated. Currently I'm still dragging the clone around while trying to figure what to do about it. But if mods were to use the 'clone approach', they would need to deal with the split of applying things to PC and NPC regardless - e.g. milk mod would likely need to apply the 'milkin changes' to PC, while using NPC somehow to display the animations.. DD would have to somehow deal with applying restraints to both PC and NPC clone, I'm not going to even try to imagine how that would work with mods like soul gem oven or hentai pregnancy. Creating a clone would be the least of their issues.

[prinyo]

42 minutes ago, reikiri said:

- VRIK will almost certainly be a requirement for SL VR patch.

The arguments for and against VRIK requirement and making the function global  are the same - breaking the convention for convenience. You can choose which one is more important, but you should be consistent. What is more - SL is a framework, not just any mod. So a global function that provides services to other mods is way more appropriate than a dependency with no justification. Also I expect at least half players will play using clone. The typical Skyrim player is a straight male who plays a female character. They will not be enjoying giving BJs up and close. (I can see a request for functionality to auto switch between VRIK and clone depending if it is FF or something else)

 

42 minutes ago, reikiri said:

- Using clone doesn't really need to prep the player in any way, there wouldn't be anything for the function to do.

It will create the clone and return the clone ref. It doesn't matter how easy or hard it is. The point is that the mod doesn't know what the settings in the MCM of SL are. With the exclusion of the clone you are making the function pointless. And you won't be able, for example, to fix this case. I guess we need to wait until the clone is added in some manner.

 

42 minutes ago, reikiri said:

But if mods were to use the 'clone approach', they would need to deal with the split of applying things to PC and NPC regardless

Yes, but there is nothing you can do about this in the framework. You can prepare the player by creating the clone and returning it's ref.  And then the patch in the mod can see that the returned ref is not the player and can do whatever it needs to. The mods will need to handle specific situations specifically, beyond the baseline PC preparation.

 

 

 

All that said, I think we need to shake the lurker tree. ?

50 - 60 people have downloaded the patch and so far there are only few people providing feedback. Now is the moment for people to share their experiences. If you are happy with how it works - say so. If you experience a problem - now is the moment to ask about it. No need to be scared, shy or something.

[reikiri]

7 hours ago, prinyo said:

The arguments for and against VRIK requirement and making the function global  are the same - breaking the convention for convenience. You can choose which one is more important, but you should be consistent. What is more - SL is a framework, not just any mod. So a global function that provides services to other mods is way more appropriate than a dependency with no justification. Also I expect at least half players will play using clone. The typical Skyrim player is a straight male who plays a female character. They will not be enjoying giving BJs up and close. (I can see a request for functionality to auto switch between VRIK and clone depending if it is FF or something else)

That's a whole lot of assumptions there. ?Further along I'd like to make a system that can select per-animation whether you use 3rd or 1st person, but it wouldn't be based on gender tags - rather your overall thought on whether the animation works better in 1st or 3rd person. This could be exceedingly simple for the user (although far from trivial to actually implement) if I get the controller support working: have a controller action to switch between 1st and 3rd person, and save that selection as a default along with the position offsets. It it worked right, this would make it a per-stage default for the animation - from there on every time you start specific stage on that animation, it would display to you in 1st or 3rd person as you chose. Changing that temporarily would be one controller action. Saving it as a new default would be another. This would be another reason to try to bake the 3rd person mode into VRIK body - switching would be seamless, and you could utilize it to help you manage the offsets.

7 hours ago, prinyo said:

50 - 60 people have downloaded the patch and so far there are only few people providing feedback. Now is the moment for people to share their experiences. If you are happy with how it works - say so. If you experience a problem - now is the moment to ask about it. No need to be scared, shy or something.

Well truth is if 10% or more of people who d/l a mod post about it on forums, the mod probably has problems. ?Most people will d/l the mod, install and play - and if it does what it says on the box, they'll move on to install the rest of the mods. Most of them will never even read the thread, let only comment on it. That's why the installation instructions - such as they are - are on the top of the post. That's usually the only thing people really care about. If the mod is totally broken, they probably uninstall, and most of them won't bother getting back to have the hissy fit. If it mostly works, but has a few glitches or broken things that are annoying enough - that's generally what gets people to writing.. in hopes that they can get it fixed.

 

My overall policy is, if someone hisses at me, I have better things to do than spit back. If someone plays nice or is constructive, then I'll try to answer in kind. And I try to always keep in mind, whatever you write on the forums, will likely stay there forever.

[oberag]

I am happy  with it! )))  Prog, Reikiri, Ephemeral THANK you for youre awsome job!  I think people who use clone will be happy with SLLight and VRpatch from Prinyo. There are not so much difference with full SL.  And for modders, it will not be  so difficult to add Vrik functions in code.    I've just pasted  lockvrik and unlockVrik with default settings (without call sexlab or vrik mcm settings) in FG  script ( prepare actor section) , and it works. ))  So, it will be greate if  everybody will be happy, but  the main objective of this mod was VRIK , First person view and finally immersion. ))

[oberag]

Good news. Author of Racemenu get his HMD and start testing RacemenuVR . https://www.patreon.com/expired6978

[prinyo]

7 hours ago, oberag said:

  I think people who use clone will be happy with SLLight and VRpatch from Prinyo.

There is no SL Light patch. There is only one patch - this one. It started as SLLight patch, then came the dll that Ephemeral provided, then Prog made a lot of updates in VRIK with the assistance of Reikiri. So this is the only publicly available way to play SL mods in VR. It needs to satisfy all use cases. It also needs to satisfy Ashal.

 

The reason this patch was moved to it's own thread is to prevent confusion. If for some reason this patch failed to progress (Ashal said no, the dll was too old or something else) then the SL Light patch would have continued without been affected. Just like the SL Light patch was deleted and you here didn't notice.

The point is to make the VR SL experience as best as possible, not name recognition. 

 

Quote

Good news. Author of Racemenu get his HMD and start testing RacemenuVR . https://www.patreon.com/expired6978

17 hours ahead ?

By the way LL has a VR subforum where things can be discussed without been offtopic in the thread they are posted.

[prinyo]

This is not a good situation - people read the discussion without the context it has and I'm the bad guy for fighting battles that are not mine. And this also makes the thread unpleasant and unhelpful. Also many people do not understand the difference between a "normal" mod and a framework and have a bit of self centered view - "if it works for me then it is perfect".  So lets fix this.

 

From my point of view the current SL patch + VRIK build are 99.99% perfect. I personally do not care about the clone or other out of body options so I'm quite happy with the way things work. Prog and Reikiri did a really great job! I was privileged to watch as things unfolded and I know how much passion and effort was put into making things work as good as they do now. I'm very happy I was able to bring them together and we are all very lucky that they clicked and were able to work so well together.

 

There are two issues that are currently under discussion. None of them are my personal cause or of personal interest, they became "my" points on Discord as I tried to think about all angles and use cases. But it is better to lay them to their real interested parties.

 

I have been against making a mod (in this case VRIK, but the question is not about a specific mod) a hard requirement with no real technical reason - partly because of "good practices" and "it feels wrong", but mostly because I'm worried how Ashal will react to that. I already know prog is not in favor of the idea  - he himself explained how he decided to do more work in order to not have avoidable dependencies for VRIK. But he will not involve himself in the discussion which I can understand.

The people with real say about this are @Ashal and @prog0111 and if they are fine with SL getting an avoidable dependency then everything is OK. I don't expect them to reply here - silence means agreement so that is also fine in my books. What I definitely want to avoid is bad surprises and complications months down the line.

 

The issue about nerfing the clone without a proper alternative in place is also not my personal issue, I have principle objections against 3rd person solutions in a 1st person experience. I wanted to help Ephemeral and other users in this thread who prefer to use it.

There is an obvious desire to have a working clone solution and an easy way to integrate the VR options in the mods that require SL. And this is not possible at the moment. The half solution that is now in place does not allow for that. For me personally this leads to just having to wait until the dust settles so I don't need to revisit already patched code when the interface changes. As it inevitably will.

But this is not my battle -  @EphemeralSagacity and the other users who are interested in using the clone in SL and the related mods should make the point if they want to. And discuss implementation issues with Rei if they want to. I'm personally fine with the current way it is done so I'm not going to raise the point if nobody else will anymore.

As long as we all understand and agree that the clone is been shut out of the system then everything is OK. If not everybody is fine with that they should make their voice heard louder now.

 

<added>What I mean is that sooner or later people will push for updates to the preparation function to include the clone. And this would be a serious change as it will mean the function will start to return a ref. So everything that was patched will need to be re-pached. hence it is better if the change happens sooner than later</added>

 

Hope this clears all confusion and hope this helps resolve things. With this I'm no longer going to discuss the above issues.

[prog0111]

I've been trying to keep up with the thread here myself, too.  I don't mind if another mod depends on mine.  In VRIK's case, this also means I may need to assist when new things are being done just because of it's technical nature.  I'll try to do my best.  Reikiri has been great to work with - it was exciting watching these big strides of progress happening every single day.

 

I'm hoping to have a build 11 tonight or tomorrow with a very-alpha level gesture recognition system, and hopefully the "force position" feature that I've been discussing with Reikiri.  It may or may not end up being useful for SL, but it'll be there for the next potential SL build to follow (assuming it works out).  I think that's the last big mod feature on my list to try and assist with static animations.

 

As for the gesture system, the next build will likely only support Index Controllers and hopefully Rift controllers.  I need to get some type of Vive-Wand detection working, because right now it breaks if you try to use it with wands.  The first build with this will only support "change outfit + equipped weapon/spell" gestures, but for even later builds, I'm still hoping to add mod framework type features that could allow SL to register special events triggered by VRIK gestures.  This should make it possible to add features where we can control scenes without needing to enter menus.

[EchoSage]

@prog0111 As long as I keep the emulation of rift controllers for my vive cosmos controllers...i assume build 11 will support that for gestures?

 

@prinyo I'm actually quite happy with the 3rd person vrik support so far.  It does jar me around every so often which would be good to resolve.  For me walking around in roomscale is very nice.  That said, clone gives a type of movement akin to what is offered in mods like https://github.com/Eusth/HoneySelectVR/blob/master/README.md .  This is very nice for seated or other scenarios that require adjustment beyond what your play space can account for.  Also there are a number of animations where a lot of context of what is going on in the animation depending on position if only a 1st person view is available will be lost.  So 1st and 3rd person views really need to exist.

 

If the above can be met through just vrik then truly that is the cleanest implementation imho.  At the moment I am only using vrik 3rd person btw.

[prog0111]

Quote

@prog0111 As long as I keep the emulation of rift controllers for my vive cosmos controllers...i assume build 11 will support that for gestures?

In theory they could work through emulation.  Gestures are done by clicking and holding the thumbstick button, then moving your hand.  If you have a thumbstick button to emulate, then VRIK will totally take it over outside menus if you turn gestures on in the upcoming build - so watch out.  It'll require bindings that leave that input free.

 

I'm planning to provide my own bindings for Index controllers, and see if I can't get my Vive Wands working somehow as well.  I'll probably need someone to help me make sure Rift S controllers are up and running as well (might need some custom bindings for those too).

[EchoSage]

Yes there is a thumbstick to click.  Steam completely mimics the oculus touch controllers in-game.  Only way to get them to work with skyrimvr in fact.

[prinyo]

8 hours ago, EphemeralSagacity said:

I'm actually quite happy with the 3rd person vrik support so far.

I was talking about not been able to setup clone from external mods using SexLabFramework.SetVrSettings(). Right now in SL animations you can setup the "classic" clone or the VRIK 3rd person. But if you patch mods like DD, ZAZ and others with the new function then the clone is unavailable.

So a person using the clone in SL would be switched to "strict" 1st person view in those cases.(I think those are the defaults)

It is not possible to setup using a clone in an external mod as long as you do not bloat up the code in all external patches to check the SL config and setup the clone yourself every time.

But as I said - as long as we are all aware of this and are fine with this then everything is OK and we can start patching mods. I want to integrate the Select NPC for MCM spell in ZAZ one of this coming days and experiment with patching it further. What I want to avoid in longer terms is the appearance of different patches that do the same thing in different way. Like somebody creating a different API function, patching mods and distributing the files with a copy of the changed SL script. The less fragmentation - the better.

[reikiri]

- I consider current clone implementation a temporary hack to allow 3rd person view when playing seated (no roomscale available)

- I want to fix the 3rd person option to work while allowing player to move around with controller (e.g. while seated), and believe this is possible

- won't put support for temporary hack in the API, because I expect it to go away once 'permanent solution' works

- further down the line want to implement some new features (some mentioned before on the thread) that wouldn't work right with clone anyway

-- edit --

The bigger issue here is the 'free mode', it will not work correctly just with the API, because it has to be implemented in two phases. First phase works essentially like "strict 1st person mode", it sets the VR body in place in the animation, and pulls the view exactly to the position of the body's head. In second phase it releases the view, and locks the body to the view. This is the only reliable way I could find ("because Reasons"), that gets the alignment right in practically every animation, as long as the animation itself works (and it should also count in any custom position offsets for animations that have internal alignment issues, so it's possible to more or less fix them).

 

This second phase can't be done by the API, because it needs to be done once the mod is confident that the animation is running, and has set the player in correct location. At that point the mod would have to call VRIK.VrikSetSetting("lockHmdToBody", 2) (SL itself does this a few seconds after animation has advanced to 'steady phase'.. and then switches to lock 1 (strict) at the start of new stage to pull the view in again.. and back to 2 when it's in place.

 

The API essentially implements the first phase - if you call it when hmdlock is set to off in SL MCM (or you override it in the call), it sets the HMD into strict mode. This is the value I might in future return with the API call, but I haven't really decided how to implement it, so right not it returns nothing. I might make it so that it simply returns a boolean that tells if the 'free mode' is enabled.. downside is it reserves the entire return value for that one bit of info, so I'd prefer a better option - and at the minimum I need to let it sit for a while, and get further in finishing the mod before making that kind of decision.

 

Meanwhile, most short and simple animations should run fine in 'strict mode', when MCM is set to 'free mode', so nothing will break terribly even if the mod doesn't release the lock. In short animations it wouldn't even have time to do that, because by the time it's through the setup phase, the animation's essentially done already.

 

Another point to be aware of is that the API will not handle the starting blackout. This is another technical issue - there is no way to predict how long the setup actually will take, and there's no way to know how long the animation itself will play.. it's not possible to do a reasonable blackout just by guessing it. The way the 'ENBproof blackout' works is a bit weird in itself, I basically tell the game to "start fading in after about a minute", to make it immediately black out, and start counting towards the fadin.. and then once the animation is set up, I send another call to "fade in now" to cancel the first one and fade into the animation.

[reikiri]

3 hours ago, prinyo said:

I was talking about not been able to setup clone from external mods using SexLabFramework.SetVrSettings(). Right now in SL animations you can setup the "classic" clone or the VRIK 3rd person. But if you patch mods like DD, ZAZ and others with the new function then the clone is unavailable.

So a person using the clone in SL would be switched to "strict" 1st person view in those cases.(I think those are the defaults)

Good thing you mentioned that - API call doesn't do any special checks for clone mode, so in this case it would simply follow whatever the rest of the settings tell it. Currently the settings in clone preset are somewhat similar to strict mode, but they have no effect while clone is enabled - I'm going to change those to match the '3rd person no clone' option in next release, so if the API is called while clone is enabled, it'll essentially set up the 3rd person no clone option.

[prinyo]

2 hours ago, reikiri said:

...and believe this is possible

Yep, if you (you and Prog) are definitely positive that a good VRIK based replacement of the clone is possible then I'm not worried anymore. Such an addition will "just work" without the need to revisit the API implementation in the other mods. And will fix all confusion about applying effects and so on.

 

About the Free - I'm thinking the same. The animations the mods run directly and not via SL are usually "simple" one-person idles. I also think Prog believes the Free can be made to work without the need of different stages of settings.

 

 

[EchoSage]

VR Patch Issue: Using V26, the hide head for the quality of life 3rd person preset is set to 0...so by default the animation has the player as a headless participant.

 

?VR Patch Issue?: Estrus Chaurus+ ends up not showing the tentacles, machines, etc...so character is moving through the animations with an invisible participant.  I think there might be issues with AnimObjects.  Was hitting issues with Komotor's similarly but at that time I had just written it off to those animations.  Looking more like a pattern now.

Edit: With more testing the old style clone method included in V26 shows the anim objects from Estrus properly.  Just not seeing them when doing animations with VRIK body (1st & 3rd person).  I'll be going back to the clone style for the time being as I'm vetting out Estrus in vr though this seems like a potentially general problem that will need some investigating to address.

[reikiri]

2 hours ago, EphemeralSagacity said:

VR Patch Issue: Using V26, the hide head for the quality of life 3rd person preset is set to 0...so by default the animation has the player as a headless participant.

 

?VR Patch Issue?: Estrus Chaurus+ ends up not showing the tentacles, machines, etc...so character is moving through the animations with an invisible participant.  I think there might be issues with AnimObjects.  Was hitting issues with Komotor's similarly but at that time I had just written it off to those animations.  Looking more like a pattern now.

Edit: With more testing the old style clone method included in V26 shows the anim objects from Estrus properly.  Just not seeing them when doing animations with VRIK body (1st & 3rd person).  I'll be going back to the clone style for the time being as I'm vetting out Estrus in vr though this seems like a potentially general problem that will need some investigating to address.

 

The clone is technically simply another NPC, so I'd assume the mods/animations play as if they were playing on NPC. VRIK uses 3rd person body, so animations should play as normally played on player character. I'd try to run the animations on player, but without doing the VRIK prepping. It will of course totally break the player character's animations in a very painful way, but it should give some idea at least on whether the anim objects appear in the first place. You could also try checking the disable vrik option in vrik mcm before running that animation (again it's not going to work correctly, but could give some idea on what's going on).

 

Once the cause is isolated, it should probably be possible to fix it. The other alternative is to simply forget using SL for those animations, and just hardcode a simple clone system into mods like that. I'm not even sure how ES runs the animations - the flatrim version has SL as requirement, so does it actually register the animations with SL and run them through it (in which case the 'prep API' isn't used)?

 

Added defaults for hide head distance (defaults to 16), I'd forgotten to do the setup for it in the system config when I added that option. Should be included in next version.

[ksl123]

awsome works!

[Shirya]

fun fact, i had somes clones issues, sometime i got more than one, sometime he stucked at the end of animation, waiting something... maybe a friend or a dont know. I killed one of them, just for fun, and now, somes npc talk to me saying they lost her friend ^^

 

I wonder if that can be fixed? maybe send a command who disable/kill clone at the end of animation, or add a option in mcm for remove clone. If they are genered, we can keep id's clone in a array, and with the option, just disable/kill all ids in the array.

 

im sorry, i would like to help but i dont know how all thoses stuff works ^^ Ah, and another fun fact. Sometime when my clone is killed, that kick me out of the magic school, i need to pay 500 gold all time ^^

 

anyway, very nice work keep going

[prog0111]

I think we can probably get the VRIK body to do anything the clone would do.  What's needed is a better system for positional locking the let's you specify coordinates.  It needs to work with lockHmdToBody enabled so that we don't need the translateTo calls on the player (bouncing issues), and it also needs to work with lockHmdToBody fully disabled.  This way you could walk around, snap turn, and so on normally, and the body would stay in it's programmed position for the animation.

 

If it works out perfectly, we can combine the idea with a mod-gesture that would let you toggle into and out of 3rd person mode just by swiping your hand.  I won't have mod gestures in the next build, but I'm working out the first try at a positional lock system for us now.

[jmannyc]

I had a few months hiatus from Skyrim VR and came back to all these wonderful toys! It was kind of pain in the ass to get physics running in the animations due to an issue with 3BBB and XPMSSE. I had XPMSSE 4.65 loaded and Found it had issues with FNIS, CBP AND SL. Reverted back to 4.61 and all was working perfectly. A couple of issues with SL, It kept defaulting my character to female and I’m searching for a fix for that. I understand that the ‘debug’ spells have that issue, but one of the mods was causing that also. My biggest immersion breaker is when the npc is kissing you and seeing the interior of the body. I’m sure that’s due to my movement in the play space. If there was better collision detection or locking the HMD position, that may resolve that. I haven’t had any CTDs from the SL mods so that’s a plus. I promise to test this and post any problems or observations. 
Prog and Reikiri, you two are making Skyrim the perfect game, but I’m spending so much time with the adult mods, I’m never going to finish this game.

[reikiri]

I'm testing with newer build of VRIK, it looks like it may be able to solve the 3rd person issue, but I'll need to do some rewriting of the PC positioning and that'll probably take more time than I have before weekend. It's also not likely to do anything about the 'props' not appearing on animations like EC, I think that's going to be a separate issue.

[prinyo]

7 hours ago, jmannyc said:

My biggest immersion breaker is when the npc is kissing you and seeing the interior of the body. I’m sure that’s due to my movement in the play space. If there was better collision detection or locking the HMD position, that may resolve that.

Is there a solution for this? I can't imagine how this can be fixed. But yeah, it would be great if it can.

One of the benefits of the "Free" preset is that when the animation puts your head too close to the NPC you can step back a bit and fix the issue. On the other hand an involuntary movement can also cause it so maybe the "Strict" preset is better. I guess currently the solution is to find the preset where this happens less for one's use case.

 

But if you use the "Strict" preset you can simply disable animations that cause clipping which is possibly the best solution for people who are bothered too much by it.

Setting the near clip setting in the MCM of SL to 1 or 2 will also help - the issue will appear less frequent.