Jump to content

Recommended Posts

version 34

  • fixed physical sneaking not getting restored after animation finishes, this may have fixed some other obscure issues as well
  • checkbox toggle to reset VRIK body proportions during animation (e.g. arm size, hand size etc) - it's now entirely separate from other scaling toggles
  • added height adjust speed setting to presets, fixed 3rd person height lock in static 1st person preset (now defaults to off)
  • changed version number in sexlab utils script, this will get rid of the 'unsupported rollback' pop-up
  • now requires VRIK dev build 23 (included below with the VRpatch 34 link)

version 33

  • when animation finishes in "free cam mode", move player to animation location to avoid falling through terrain etc
  • when scaling is NOT disabled on animation settings page (CTD fix is not enabled), reset VRIK arm/hand/body etc scales to defaults for animation (you don't need to enable 'even actor scales' for this to work, it works as long as CTD fix is not enabled)

version 32

  • 'free camera' mode for 3rd person. it actually just disables collision, which kind of lets you fly around. it's optional, you can enable/disable it and set it on/off by default
  • added gestures to set animation offsets
  • jumping is disabled during animation, so it no longer accidentally breaks animations
  • disabled interacting with objects, and sneaking during animation
  • disabled most of the logging from VR patch to VRIK log, because things seem to be working

version 31

  • moved anim disable/enable to right paragraph on MCM for visibility
  • added haptic pulse on stage shift in debug mode
  • hide gesture info during animation when gestures are disabled, replaced by clicky text to enable them
  • always enable collision on game load (prevents being locked to no-collision if you load a save during animation)
  • fixed light orgasm whiteout (actual whiteout instead of brief flashes)
  • push stage auto-advance when enabled, to ensure it actually starts (gesture didn't always start it, this hopefully fixes it)
  • gray out disabled controls in MCM in victim role (some gestures are disabled if you select "disable victim controls" in animation settings page)
  • 'height adjust speed' setting in SL MCM (explained in notes at bottom of page)

version 30

  • There's 'reset to defaults' preset that should reset all VR patch settings to reasonable, working defaults - use it first if things seem to not work right
  • Added better testing for install requirements. If some requirements are not found, the VR page of SL MCM should list requirements, and which ones are broken
  • Active spells are now 'sheathed' when animation starts
  • I tried to make the 'no collision' reset after animation more robust, so you won't end up in strange floaty mode, running through walls and ground after animation

 

version 29

  • added gesture controls
  • fixed next/previous animation to skip disabled animations and actually maintain a static order
  • rearranged SL VR MCM menu to make room for new stuff, and separate 1st and 3rd person specific settings
  • you can move between 1st and 3rd person views with controller gesture
  • don't jump while in animation, jumping will break you out of the animation
  • animation props still not showing up on animations, this seems likely to be an issue with player character in VR, fix may be possible, but v29 doesn't have one yet

 

version 28

  • probably the first one where it feels like all three modes (1st person, free mode, 3rd person) work without some positional jitter of misalignment. I hope that holds true for all the different animations - there's only so many I can test with all modes.
Link to comment

@EphemeralSagacity - One issue I have is, if I enable 'marker-as-vehicle' in the code (which is what SL full uses), Both the VR viewpoint and the VR body go up into air, and totally not in alignment with the scene.. even if I just use minimal changes to actorAlias script. So I have a creeping suspicion that the vehiclefix -may- be important for the working of this. But I'm really not sure - it could be something else too.

 

I still have the problem that the viewpoint orbits a 'center point' depending on what direction you look into. And depending on animation, it's possible that you would be in 'correct location' when looking into some other direction (although generally the correct location aligns with looking into direction where you were looking at the start of animation). As a result, some animations work and align really well (if PC position is near the center point, or if the direction happens to be correct), and some animations are totally broken. If I find a fix for this, or someone else does, this could work just about as perfectly as I can imagine it working in Skyrim VR though.

 

-- edit --

Also generally the VR body isn't facing exactly the right direction either - again this may be dependent on animation. My first thought is to possibly fiddle with the settings that lock/unlock the various VRIK functions, and try to let the animation / SL functions handle the positioning freely when they do.. and then set the VR viewpoint to correct location. The second possibility - more work but possibly better chance of success - would be to shift position of every character in animation, based on the position of VR body.. and do this separately for every stage - to make sure that at all times the VR body is at the center point. This would still require being able to actually move the viewpoint around though - but I'm pretty sure at one point I had settings that would have worked with this approach.

 

I think I just need to fully understand when, where and how SL moves the actors around - and how -exactly- all the VRIK settings relate to it (what block/allows what).

Link to comment

I already dropped this in the SLLight Patch thread but I'm re-dropping it here bundled with my own script changes I made (this includes the SexLabUtil.psc you put in that thread). These do actually work for creature animations (and includes a patch on SLAC to make it work properly), but it can cause thread timeouts, especially when you start using SLAL. Feel free to integrate anything here you think would help.

FYI: When I say it works what I mean is I was able to get the built-in sexlab creature animations to work. Since adding SLAL started causing thread timeouts I can't say for certain if all creatures were working, but I assume they would be.

my VR patch.7z

Link to comment

That's a lot of papyrus on those race functions : )

I can imagine it puts a huge load on papyrus engine when SLAL slaps it with a couple hundred animations.

slal loader seems like it just runs all the animations in a while loop, and throws out mod events for each of them - and they aren't light weight events, especially with everything running on papyrus. If it can handle registering a single animation (could try that simply by enabling only one on slal and registering it), then it should be possible to rewrite the system to register the animations more slowly - it would take a while to register all the animations, but you don't need to do that often. One possibility that comes to mind, would be to rewrite slalLoader.psc - functions registerCategoryAnimations and registerAnimations to just push the animIDs into an array, and then fire up onUpdate that starts working on that array - calling registerAnimIfEnabled for one animation at time. You could either put a flat delay by calling the onUpdate with something like 0.5 second or 1 second delay - whatever would seem to work.. but there's downside of that being system dependent (how fast any particular PC can handle the requests).

 

A 'smarter' script could hold the number of active registrations in a variable, and hold the onUpdate loop when it goes past say, 4 concurrent registration threads.. since OnRegisterAnim acts as a callback - add the count when RegisterAnimationCB is called, and reduce the count when OnRegisterAnim is called. Or have separate array for 'working on' animIDs, let onUpdate check it for empty slots - when one is available, put next animID there, and fire up mod event.. and have OnRegisterAnim empty the ID from that array once the registration is finished. Or something like that. : )

 

It's probably not useful when going forward with SL Full, but it could allow SL Light to work with SLAL.

Link to comment
1 hour ago, prinyo said:

I downloaded the archive from the first post and loaded it after the SL full but can't get to MCM - only Install is an option even after I have installed several times.

 

I'll have to look into that. I'd installed it earlier without the dll, and with different script changes.

Link to comment

Obviously I'll take this down the moment I get told to. That's fine by me. I've asked twice and had no answer one way or the other - so right now I'm just assuming he doesn't want to support the thing because there's -SO- many issues with it, and he barely has time to work on the SE edition. And based on that assumption I figure as long as there's clear distinction - e.g. it's not mingled into official SL thread, it should be fine. I don't see a huge difference between running SL Llight (with patch) on VR or SL Full (with patch) on VR honestly - neither of those approaches is officially supported on SL thread.

 

On the other hand I feel working and experimenting on this is a good thing - because it shows what's possible, and what's not at the moment.. what are the limits, what workarounds might help to get past them. For me personally the 'clone approach' works fine - I've used flower girls with the clone before, and was perfectly happy with it.. except it had (had) little support for other mods. I would have been fine with SL light IF it had been able to work fully with other mods.. which it didn't. So I went for the SL full. What I have right now, pretty much works for everything I need it to (through the clone approach), but I've also seen how much the 1st person approach can actually improve -some- animations, so I want to at least put some effort to seeing how far that can go at the moment.

 

On that, the biggest wall I'm hitting is, no matter what I do, I haven't been able to set the VR body to fully follow the animation AND tie the VR viewpoint to the body. In other words, I haven't been able to tie the viewpoint itself into the animation, no matter what I do. The body either follows the viewpoint, or follows the animation. And sometimes tries to unsuccessfully follow both at the same time. Sometimes I get as far as setting the VR body to animation location... and attaching the viewpoint to roughly the same location.. and it can look really good. But usually there's still some kind of glitch in that. And I haven't been able to get the "vehicle code" to work properly on viewpoint / VR body.. it always attached both somewhere up in the air. I don't know if the (missing) vehicle mode fix would help on that or not - but that's not available on the old source so, whatever - I'll work with what I have. I -want- SL to work fully in VR, and I'll do what I can, and have time to, towards that goal.

Link to comment
22 hours ago, prinyo said:

I downloaded the archive from the first post and loaded it after the SL full but can't get to MCM - only Install is an option even after I have installed several times.

 

 

20 hours ago, reikiri said:

I'll have to look into that. I'd installed it earlier without the dll, and with different script changes.

 

19 hours ago, EphemeralSagacity said:

I just tried out reikiri's bits on the first post clean and got the MCM.

 

Hmm.. well.. I loaded a save from the very start - when I had just gotten to Riverwood, loaded up the SL and patch, got the install menu.. clicked install, closed MCM.. after a while it popped the 'voices installed' and such.. and then eventually 'ready'. Went back to MCM, and had the full menu. So.. it worked for me. And I haven't changed anything on sslSystemAlias, so it should.

Link to comment

So, question. I've been trying to keep up with this conversation while simultaneously knowing almost literally nothing about programming, and thank yall both for the effort and collaboration that's going into this by the way, I'd tip my hat to you if I was wearing one. I'm curious though, a while back it seemed like yall were discussing the possibility of making SexLab Light, specifically in VR, work with SLAL, which would be amazing, because as it stands I can only reliably add 40ish creature animations that will actually fire, and then any loaded after will only say its registered, but wont actually do anything. Also, Matchmaker seems to work as long as you don't actually change any of the settings in the SexLab MCM except for the VR body tab introduced with the VR Light Patch, touching anything else makes all creatures fizzle, and will no longer train. I  guess what my question is, is will this patch youre creating allow for SLAL to add animations up to the actual 500 amount allowed?

 

Link to comment

Fixed the bug.  Problem was in SeedStats, there was a condition in that method that could result in Skills[kStat_SexCount] being zero which caused issues with this part of the kstat_Aggressor -> std::floor(rand(0.8f, Skills[kStat_SexCount] / rand(1.0f, 2.0f)))  <- to have a max value that was lower than the min value for the rand.  Guessing the latest sources would have had that fixed.  Looked like code that was likely being experimented with for the point in time snapshot that is being used.

 

attached is my minimum working patch to the full sexlab.  It just uses the cloning style which comes with some issues that need to be addressed to get full compatibility.  The cloning style does break a few mods that extract the actors from Positions array since that array then has the vrdummy clone.  Also I noticed in prinyo's patch and maybe ?reikiri's? that the SetupThreadEvent was modified to have an extra parameter.  That causes any mod that is listening for the two parameter event to not receive it.  I've left that untouched as I believe it should be possible to handle that without breaking that external contract.  Also with the clone I suspect (but have not confirmed) that the stats are being done for the clone and not the player.  It should be very possible to hide the cloning from external mods to have full compatibility with older mods.  Oh - but I do copy the player's equipment to the clone.  New add there.

SL 1.63B7 Full Patch.7z

Link to comment
On 11/5/2019 at 3:03 AM, AkylasLovesLicks said:

 I  guess what my question is, is will this patch youre creating allow for SLAL to add animations up to the actual 500 amount allowed?

It does, but only on SL full (beta 7). SL diary / skills didn't work at all, it may be connected to what Ephemeral posted. Creature animations do work, and SLAL works - I believe it already lets you use SLAL to load up animations (including creature ones). But again, only on SL full beta 7 (it won't work with SL light, and won't work with any other version of SL full - although as long as I keep working on it I'd probably update it if/when new version of SL full comes out).

On 11/5/2019 at 7:40 AM, EphemeralSagacity said:

Fixed the bug.  Problem was in SeedStats, there was a condition in that method that could result in Skills[kStat_SexCount] being zero which caused issues with this part of the kstat_Aggressor -> std::floor(rand(0.8f, Skills[kStat_SexCount] / rand(1.0f, 2.0f)))  <- to have a max value that was lower than the min value for the rand.  Guessing the latest sources would have had that fixed.  Looked like code that was likely being experimented with for the point in time snapshot that is being used.

 

attached is my minimum working patch to the full sexlab.  It just uses the cloning style which comes with some issues that need to be addressed to get full compatibility.  The cloning style does break a few mods that extract the actors from Positions array since that array then has the vrdummy clone.  Also I noticed in prinyo's patch and maybe ?reikiri's? that the SetupThreadEvent was modified to have an extra parameter.  That causes any mod that is listening for the two parameter event to not receive it.  I've left that untouched as I believe it should be possible to handle that without breaking that external contract.  Also with the clone I suspect (but have not confirmed) that the stats are being done for the clone and not the player.  It should be very possible to hide the cloning from external mods to have full compatibility with older mods.  Oh - but I do copy the player's equipment to the clone.  New add there

I caught the same extra parameter, it was giving errors to log - and I commented it out. That was probably after I put out the v2 files though, but will be included in next. The clone is done from player base I think, so should be recognizable by any mod that knows to look for it.. but might confuse others. Right now I'm mostly trying to understand how the first person view works, how it behaves when actor is moved.. how to align it more correctly, and avoid the strange glitches that happen - largely connected to view direction. Basically trying to get the 1st person view to work as correctly as i can make it.

 

Anything and everything can change at this point, so I'm less focused on full compatibility with other mods - although I do try to keep SL full intact as much as I can, to make it less likely for mods to break. But yeah, I imagine any mod that relies on player being one of the actors in scene, will not be happy without specific patch for that mod. But I also think sooner or later there will be official VR version of sexlab full, and at that point authors of mods that aren't directly compatible will need to evaluate the situation - and decide if they want to add what's needed (assuming the authors are still active). And from what Ashal has said before, I think that version will be focused - if not exclusive - to using 1st person view. Personally I'd like to keep both as an option.

 

Further down the line - if I have time - would be nice to add support for flags that would mark some animations as compatible to 1st person view.. so that the view mode could be picked per animation based on those. (Thinking of custom flag you can set on animations you want to play on 1st person, but I suppose an animation author could set it as well).

Link to comment
4 hours ago, prinyo said:

I added that at the very beginning and it is not used anywhere, it should be removed. I wasn't sure at the time what the complications will be from adding the clone into the equation.

But I don't think external mods care if a replacer is used so it seems the internal variables are enough. Except

I don't know which mod is this but it seems to me it is important why it does that. Because even if you send a mod event that there is a replacer you also need to tell the mod which actor is the replacer. Or you need to adopt some way of marking the clone, but then you wouldn't need to broadcast it anyway.

 

The specific mod that breaks is sexlab aroused redux.  Alters exposure of the clone and not player.

Link to comment

Attached patch gets the stats for the player diary functional.  I did it quickly but with my testing the sexlabutil native code is now getting the player and the mcm has updated stats for the player...so cool.  

 

We still have the "Positions" array that is exposed externally which I know at least messes up sexlab aroused.  Wondering if the cleanest fix there is to make the Positions be the actual source refs and to have an InternalPositions be the ones that has the clone subbed, replacing the internal sexlab uses to be the InternalPositions.  Or would it be better to surgically add conditions like I did in sslActorAlias.  Really wanting these core changes to be non-invasive as possible.

 

@reikiri - if you could incorporate the "dress the clone" (makes sure jewlery and what not are on the clone...or horns etc at some point...) and what you think would be appropriate for the sexstats adjustment that I have here into yours that would be great.  Would really like yours to be the unofficial vr full patch since you have mcm and all.

SL 1.63B7 Full Patch Take2.7z

Link to comment

-- edit --

Ok, got the code from Ephemeral integrated, and the mod is still working. I don't get updates on diary though, so I'll need to look into that further - but at least it's combined code base now. There's still glitches all over the place, but it's probably in playable state for the time being.

Link to comment
11 hours ago, reikiri said:

It does, but only on SL full (beta 7). SL diary / skills didn't work at all, it may be connected to what Ephemeral posted. Creature animations do work, and SLAL works - I believe it already lets you use SLAL to load up animations (including creature ones). But again, only on SL full beta 7 (it won't work with SL light, and won't work with any other version of SL full - although as long as I keep working on it I'd probably update it if/when new version of SL full comes out).

Thank you!! Yall are doing awesome work!!

Link to comment
7 hours ago, reikiri said:

-- edit --

Ok, got the code from Ephemeral integrated, and the mod is still working. I don't get updates on diary though, so I'll need to look into that further - but at least it's combined code base now. There's still glitches all over the place, but it's probably in playable state for the time being.

I'll see if I can spot what is different in the integration.  I definitely get "time spent" and partner updates in the mcm page and stepping through the dll I saw experience getting added to the skills.  So either I dropped the wrong bits or something is slightly tweaked in the integrate.  For the diary, which of your modes were you using to validate? 

Link to comment

ok -  what I see in the debugger is that for the NPCs the Thread.SkillXP is correct and so the NPCs are getting everything bumped accordingly.  The clone however is a different story.  The Thread.SkillXP provided is blank so it likely got the clone's values somewhere.  Partners and Time are updated, but those are independent of this.  I've begun to think that it is a very bad idea to replace positions but rather we need to very specifically swap in the stunt double clone surgically for the animation and positioning.  This is otherwise going to be fraught with bugs.  Certainly open to suggestions.

 

Good news, dll is working.  Bad news is that dealing with the clone in the code cleanly is an interesting challenge.

Link to comment
3 hours ago, EphemeralSagacity said:

As I walked through, I do think it will be cleaner to do a wrapper function around Debug.SendAnimationEvent and swap in the stunt double there.  Going to give that a kick.  "Looks" cleaner at first blush for the clone style and should be more compatible externally.  Need to swap in the stunt double for position setting as well.

As a few thought exercises...

 

- devious devices, and it's various applications? like if 'defeat' puts on devices prior or after scene? should they go for clone, or for player? (probably player)

- things that make changes like.. say, 'fillherup'? In practice not important as long as there's no nioverride, but.. changes should happen for clone - but there can also be lasting effects -after- animation, that should technically affect player.

- any effects during animation - I think there was a mod that simulates injuries from anything rough/non-con. Those should linger on player

- same thing with any post-animation effects from.. anywhere really (e.g. exhaustion from defeat mod)

 

I think overall it's a question of making something that's clean and easy to understand, and has the capability to be hooked on by mods at any point current SL can be hooked (e.g. sends events that have rational parameters as actor etc.). Something that works out-of-box well enough that it doesn't actively break anything.. and in more complicated cases it'll have to be up to mod author to decide if they want to build more extensive support - which will only be relevant when/if this becomes something more stable and refined.

 

There might be a further version of VRIK in foreseeable future, which could fix some issues I'm struggling with right now. Also there's probably going to be a release or SL full that'll at least have the newer SLU.dll compiled for SKSEVR - which has a somewhat more stable code base than the several years old source. So, hopefully things will improve a bit further along.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. For more information, see our Privacy Policy & Terms of Use