Skyrim SexLab and VR

[EchoSage]

K - that isn't going to work on skyrim vr:

It will not work with SSE until I port the plugin.

[BerserkerXX]

Tried it with an argonian and I got a snout-full of clipping geometry with the camera. That might need some adjusting.

[reikiri]

4 hours ago, BerserkerXX said:

Tried it with an argonian and I got a snout-full of clipping geometry with the camera. That might need some adjusting.

There's options in VRIK itself for adjustment. Worst case you can set 'head hide distance' to 0, it will make the entire head invisible by effectively shrinking it away. It'll work as long as you never go into 3rd person view.. then it just gets really really creepy. You can set near fade to 1, and -maybe- it helps.

[reikiri]

Here's v23, 'the weekend build'. Did some fixes and changes, listed in second post on first page. The 'free mode' is still partially broken, namely the alignment at start of every stage (including first) is off. A fix exists, after which it will align correctly, but I couldn't enable it yet in this build, because it needs the new build of VRIK to work - and that wasn't ready for release yet (it has major things coming that'll take a bit longer to implement). But hopefully this version is getting close to 'production quality' already.

[EchoSage]

Initial take on V23 is that it is nicely improved.  Will validate more over the weekend.  Kudos @reikiri

[reikiri]

Version 24. I uploaded new dev version of VRIK, and with that, the 'free mode' should be now fixed as well. You MUST use the latest (dev build 10) of VRIK to use version 24 since it uses a feature from VRIK that didn't exist in previous versions.

 

I gave some thought to including function to pass SL settings for VRIK from call by external mod, but in the end didn't put it up on this version. It wouldn't work nicely from SLU script, and I went back to look how SL is actually doing the API functions - they are basically mapped through the main script. If I add something like that, I want it to be implemented similar to other properties of SL. I can do all sorts of hacks inside the code itself because I know I can change anything later if I realize I did something wrong.. but that doesn't apply with anything intended to be called by other mods. Once you implement an interface, changing or removing it is a major issue.

 

SL 8 was released, but looking through the code there were almost no changes to beta 7 - basically just some dependency version number updates, and one fix I could see - the biggest thing was recompile of slu dll (because Skyrim itself updated), which doesn't apply to VR version. You can use the VR patch with either beta 7 or beta 8 of SL, it makes no real difference.

[prinyo]

There is still no technical reason why not implement it in the most technically sound and easy to implement and support way. Other than "because I said so" (1 vs 3). God help people who will want to patch DD, ZAZ and the others.

 

As you say

Quote

Once you implement an interface, changing or removing it is a major issue.

so I'm not sure why do you want to implement a very narrow inerface cemtered around the current options of VRIK. This is like the worst thing you can do at the moment. Instead of proper wrapper functions that will make everybody's life easy.

 

Like the suggestion was - create two global functions SLPrepareVRPlayer() and SLResetVRPlayer() that will take care of the VR settings for the plugin mods. This is flexible and easy to use to patch mods. 

Instead of only passing settings and letting the mods try to deal with them or creating VRIK specific layer with hardcoded function parameters.

[prinyo]

Quick impressions from the latest files.

The description for the Free is still wrong and misleading, It says you need to walk to the correct position in room scale mode which is not true.  The Free preset itself is ... confusing. In 80% of the animations I tested it worked, but when it broke it broke in different ways. But it is the best I have ever seem it working!

 

Edit: After about 30 animations only one had a turned head and only one had a positional problem in the first stage, It is indeed working really well!

[EchoSage]

V24 on top of SLFullB8 is working wonderfully for the 3rd person view.  Synchronization and scene startups working well.  At this point you should just kill the clone functionality as it will allow you to make the patch less invasive.  Just take a hard dependency on VRIK.  Good work!

[BerserkerXX]

13 hours ago, reikiri said:

There's options in VRIK itself for adjustment. Worst case you can set 'head hide distance' to 0, it will make the entire head invisible by effectively shrinking it away. It'll work as long as you never go into 3rd person view.. then it just gets really really creepy. You can set near fade to 1, and -maybe- it helps.

It works perfectly fine in regular play, it is only when an animation is playing that it happens. So an option to hide the head while in animation would be nice.

[reikiri]

9 hours ago, BerserkerXX said:

It works perfectly fine in regular play, it is only when an animation is playing that it happens. So an option to hide the head while in animation would be nice.

Added 24b version with extra slider to do that. You can set what the hide head distance is during SL animations. Set it to 0 in SL VR menu, and it's hidden.

 

It also has API for setting the VRIK settings based on SL MCM. You'll find that from SexLabFramework.psc

I can write something about it when I have more time, but it should be fairly easy to figure from the code.

[Shirya]

with the last release, clone dont works anymore, i wondered if u realy wan to remove this feature, cuz i actualy only use clone option. I suppose, vrik option is nice for male chars, but for female one its a little more useless, most of animation dont give us a nice view from head spot.

[reikiri]

 

with the last release, clone dont works anymore, i wondered if u realy wan to remove this feature, cuz i actualy only use clone option. I suppose, vrik option is nice for male chars, but for female one its a little more useless, most of animation dont give us a nice view from head spot.

When/if I get the '3rd person' preset working better, yes - probably remove clone. At the moment it should still work.. if it doesn't, I'll need to look into it later when I get a chance.

[Shirya]

i tried 3rd person, the bad point is we can't rotate in any direction for chance the view. When i use clone, its like vrik preset 1st person.

this is possible to add again old files? i removed mine before test the last update :x

[EchoSage]

1 hour ago, Shirya said:

i tried 3rd person, the bad point is we can't rotate in any direction for chance the view. When i use clone, its like vrik preset 1st person.

this is possible to add again old files? i removed mine before test the last update :x

I just physically walk around and physically turn in the 3rd person view to change angles and perspective and it works quite well doing that.  I'm using a wireless setup so the cords don't get in the way.  Perhaps that's the difference?  It really feels almost identical to the clone for me.

[EchoSage]

The blackout is a super nice touch btw.  hides all the jaring bouncing.

[prog0111]

I thought the fade to white effect was really cool too.

 

There's still a bunch of VRIK things I'm working on to try and help, but I've also started on an input gesture system.  The idea is to create simple gestures where you press a button and move your hand in some direction, and to allow the user to configure gestures to do just about anything with VRIK's MCM.  I want to open it up to mods.  That would enable gestures to pop up a SL menu, to advance scenes, toggle 3rd person, and so on.

[EchoSage]

The white effect is also cool.

 

I've had to ditch magevr - some conflict going on.  So you have me extremely intrigued with the gestures.

[prinyo]

15 hours ago, reikiri said:

It also has API for setting the VRIK settings based on SL MCM. You'll find that from SexLabFramework.psc

I'm blind.... Everything below in this post is wrong. I didn't see that the hardscoded parameters are actually flags and the function in actorlib is both a setter and is executing the settings which is unusual but it does make sense. 

 

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

From a functional point of view it fails in the main idea - to use the settings in the SL MCM. The whole point of this is to avoid multiple identical settings pages in multiple mods. This function expects the user to open the MCMs of SL, DD, ZAZ and the others and set there the same settings. It also expects somebody already added all those duplicate tabs with settings. From a functional point of view this is useless.

 

From a programmer point of view this takes the current options of VRIK and makes them a hardcoded part of the API. Any new VRIK option or any other new mod that can play a role in this will need to be hardcoded and mods all over will need to be updated. This contradicts all logic and all "best practices". From a programmer point of view this is just a bad function.

 

From an integration or logical point of view this is pointless because it means all client mods must be aware of all the intricacies of VR integration. And the whole point of such a function is for the framework to provide this service for the mods. Basically this strange solution fails in all regards.

 

All while there is no single con to creating two universal global functions that would make everything easy and logical.

 

 

Or maybe I'm wrong. Can you give a short code example of this function used in a mod? Something like:

 

if isPlayer

; <- example code here

endif

Debug.SendAnimationEvent(....)

[reikiri]

12 hours ago, Shirya said:

i tried 3rd person, the bad point is we can't rotate in any direction for chance the view. When i use clone, its like vrik preset 1st person.

this is possible to add again old files? i removed mine before test the last update :x

Tracked down the issue that broke the clone, fixed, and uploaded as v25. Hopefully everything works again now.

[reikiri]

6 hours ago, prinyo said:

From a functional point of view it fails in the main idea - to use the settings in the SL MCM.

 

This is exactly what it does.

6 hours ago, prinyo said:

From a programmer point of view this takes the current options of VRIK and makes them a hardcoded part of the API. Any new VRIK option or any other new mod that can play a role in this will need to be hardcoded and mods all over will need to be updated. This contradicts all logic and all "best practices". From a programmer point of view this is just a bad function.

No it doesn't. That's the point of using defaults in the API, you only need to care about parameters you actually want to change - if you do it the correct way.

6 hours ago, prinyo said:

From an integration or logical point of view this is pointless because it means all client mods must be aware of all the intricacies of VR integration. And the whole point of such a function is for the framework to provide this service for the mods. Basically this strange solution fails in all regards.

I'm not sure what you mean by 'intricacies of VR integration'. VR modding is not simple or easy, there's differencies you'll have to be aware of - like how trying to use 3rd person camera will break things.

6 hours ago, prinyo said:

All while there is no single con to creating two universal global functions that would make everything easy and logical.

There's always a 'con' if you deviate from mod's original intent and style in doing things. I went through the SL code, and to the best of my understanding, the way it prefers to give APIs to other mods, is by implementing them into SexLabFramework script as API calls, which then funnel the calls to relevant parts of the mod. So this is exactly what I did. From interface standpoint, this makes it easier to maintain - because you can change the internal implementation without breaking the API, and I had to be especially careful about maintaining that kind of flexibility for several reasons (f.ex. because I have no control over the platform (SexLab itself) development, and the mod itself is still under development, so changes can and will happen - and I want to avoid breaking compatibility with whatever integrations this call might be used from now on).

6 hours ago, prinyo said:

Or maybe I'm wrong. Can you give a short code example of this function used in a mod? Something like:

 

if isPlayer

; <- example code here

endif

Debug.SendAnimationEvent(....)

In my opinion? Yes, you are wrong.

An example? Well, in the simple case where it would be..

-- to pass the settings from SL MCM, you'd call:

SexLabFramework.SetVrSettings()

-- once you are done with animation, you'd call:

SexLabFramework.SetVrSettings(enabled=false) - or just SexLabFramework.SetVrSettings(false) since it's the first parameter.

-- if you were making a bound animation that especially requires the animation to always animate player's arms, regardless of SL MCM setting, you'd call:

SexLabFramework.SetVrSettings(trackHands=false)

-- once you are done with animation, you would still call:

SexLabFramework.SetVrSettings(enabled=false)

 

I'm really not sure how much more simple I could make it, while still maintaining the integrity of SL style API. What I will not be doing in this function, is to implement the more generic preparation, such as passing the DisablePlayerControls, or SetPlayerAIDriven - and other similar things. Any mod that is currently implementing their own animations, will need to do that already in SE, and trying to implement that while maintaining flexibility, would just make this way too complicated.

 

What my purpose here is, is to allow mods that already would use SL framework, but for some reason prefer to pass their own animations from time to time, a way to use the current VR specific settings of SL in setting up player for the animation. I left in the code to handle the 'comfortsneak' setting, but left out the starting blackout because it can't be handled right with a single call to a function (you have to cut it at right point after you've set up the animation).

[reikiri]

Uploaded v26 to fix one missed default in the API call. float nearDistance needs to be float nearDistance=-1.0

[prinyo]

1 hour ago, reikiri said:

SexLabFramework.SetVrSettings()

I can be very wrong here., but calling this will just apply the values you have hardcoded in the definition of the function? I don't understand where is it checking the config.

 

The use cases that you give are exactly what I was talking about, I just don't understand how this function can achieve them:

 

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

 

In sslActorAlias the lib function gets called with the config values:

 

	ActorLib.SetVrSettings(enabled=true, lockHeight=Config.VRIKlockHeight as int, trackHands=Config.VRIKtrackHands, trackHead=Config.VRIKtrackHead as int, hideHead=Config.HideHeadDist, nearDistance=Config.NearDistance, lockHmdToBody=Config.lockHmdToBody as int,hmdTol=Config.HmdTol, hmdDis=Config.HmdDis, hmdSpd=Config.HmdSpd)

 

But not in SexLabFramework where it is just some hardoded stuff.

 

 

So my confusion here is when calling SexLabFramework.SetVrSettings() where exactly does it check for the config values?

I expected it will fetch the config values for the parameters that are not specified. But it doesn't.

So I concluded you expect the mods to fetch all those values themselves. But maybe I have missed something.

 

[reikiri]

16 minutes ago, prinyo said:

But not in SexLabFramework where it is just some hardoded stuff.

 

 

So my confusion here is when calling SexLabFramework.SetVrSettings() where exactly does it check for the config values?

Maybe you aren't familiar with using defaults in function calls?

 

If you make a function like:

function foobar(int i = -1)

  Log("I is " + i)

endFunction

 

And you call it like:

foobar()

it will log '-1'.

If you call it like:

foobar(i=3) or just foobar(3)

it will log '3'

You can override the defaults with your own values. What I'm doing there is, I pass 'illegal' or 'unused' values to all parameters in API (SexLabFramework side of the function), which will remain unless user overrides them with their own values. The actual implementation (ActorLib) side checks the values it's given. If they are at -1 (the default) it will replace them with values from the SL Config (SL MCM values). If user overrides some of the values, then the values the API passes are no longer -1, and so the SL Config values for those will not be used.

 

You can ignore the actorAlias case, I'm not calling the function through API there - that's sexlab internal use of the function.. I have no reason to pass through the API since if I ever change the implementation, I'll just change the actor alias call as well. External mods would not call the actorLib function directly, but rather through the API (SexLabFramework), so that if I ever decide f.ex. move that function from actorlib into sexlabutils or the systemconfig script, I can just make the change in the API - and any external mods will still work as intended, without needing to change their own code.

[prinyo]

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. So I read them as proper hardcoded values. 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!