SexLab p+ Dev/Feature Discussion

[Scrab]

Sup'

 

This is the dev topic for SLp+, the download thread can be found here:

 

 

Some of you already know that Im working on a refracture patch for SexLab called SexLab p+. Since I wanted development of this patch to be public Ill be using this thread here to document and showcase some of the progress Im making and also to see how much interest there is for this patch and what kind of features & things are most interesting to you

Fundamentally, SexLab is the by far most advanced framework in terms of general ideology and architecture, allowing a very loosely defined yet precise interaction with it, something any other framework can only dream of. However SL lacks heavily in concrete implementation causing a lot of unnecessary processing and slow code

 

Please note that this project will be exclusive to SE (incl AE) and very maybe VR

 

To get started, here is a quick rundown on the issues SL has and how I approach these:

Spoiler

1. Data Structure & Algorithms

There are 2 primary issues with SL, and one of them is how data is stored, accessed and processed. The most severe case of this lack of structure is on the actual animation class itself:

Animations are being parsed, stored and accessed the way the animator has put them in, but heres the issue: By not having any structure whatsoever on how data is stored, the accessing of said data becomes incredibly complicated and creates a large bulk of code required to be processed to properly account for this lack of structure. Take for example this 5p animation here:

 

FMMFM

 

For us, this seems like a very simple animation, if I were to give you an actor array, lets say MFFMM then you as a human (im going to blatantly assume that youre not from the cat council) should be able to instantly recognize that this key matchs (3m and 2f) and be able to sort this key to match the given animation, but its not that simple to do inside a system where we can only do step-by-step operations. The algorithms SL uses to fight this lack of structure are incredibly slow and inefficient and often impossible to optimize properly and in some cases create a severe overhead significantly slowing down processing

 

1.1 Sorting

The first thing SLp+ does is to ensure all data stored is sorted. This eliminates the necessity to sort given data during the processing multiple times and with a globally enforced sorting priority, the framework has access to use more advanced algorithms to ensure that everything is in order. More precisely, this means that:

- Sorting will overall be faster (currently most sorting algorithms used in SL are extremely complicated and inefficient)

- Things will only have to be sorted once and will match any other

- It will become impossible for female actors to animate in a male position or vice versa (unless it is explicitly allowed (such as females using strapons)

 

1.2 Data Keys

SLp+ will use Data Keys to store any necessary data for Actors. Data Keys are integer keys, storing a multivariable gender*, the racekey, if an actor is victim and going forward potentially many more things, such as if an actor is to be a vampire; which can be used to allow animators to create vampire animations that are specifically only used by vampires in the future

The key contains all data there is to know about an actor and allows accessing same data with a little bit of arithmetic (math). Further as these keys are just integers, we can sort them much, much faster than a set of actors which gives 1.1 an additional bonus in speed and reliability

 

*multivariable genders are a new concept introduced by SLp+, allowing actors to take on multiple genders at the same time. This means that, for example, a futa actor can be male, female and futa at the same time without requiring any secondary checks. This is also what will allow SLp+ to offer full support for futa actors going forward

 

1.3  Conclusion

Mixing a global sorting priority together with actor data keys, allows for things such as animation validation to be significantly faster than before while at the same time also being much more reliable. It also introduces new invariants SL can use to skip significant amounts of processing, while also significantly improving gender matching, actor sorting and offering additional expandability such as futa support or vampire/victim exclusive animations and that without any additional performance cost

 

2. Code Obfuscation

The second primary issue of SL is about SL shooting itself in the foot, as weird as that may sound. When you try to follow (emphasis one 'try')  SLs code and succeed, you will find a large quantity of it actually being called more than once, two times, sometimes even three times in a row attempting to "backup" its own lack of speed by checking 2, 3, 4, 5 times before actually doing things. Needless to say, this is a vicious circle: The more checks you do the slower your code gets, creating more insecure points in your code that you try to check for making your code even slower in the process. Normally this is not a big deal but at SLs scale, this is indeed quite dramatic

For us 1st person players in the crowd, Im sure we all know how SL forces you back to 3rd person multiple times scattered over 2~3 seconds? This is exactly what Im talking about here

 

This issue roots (in my opinion) from a heavy overuse of Papyrus Script-State function, incorrect usage of inheritance and attempts to do most processing async. Smart multi-threading can save time and is in fact needed in some parts of SL but because of how Papyrus works, a code that requires 20 frames will always require 20 frames, independent of how many async calls you split up your code in, this is because of Papyrus's inbuilt op-code-limit works

 

2.1 States

SLp+ will, to everyones surprise, address this obfuscation by refracturing how exactly code executes

Some States should as the "Prepare" and "Advance" States have been completely removed/made redundant/merged. Instead SL now follows a strict chain of execution from

Inactive -> Making -> Animating -> Ending -> inactive

Compared to before:
Inactive -> Making -> Preparing -> Advancing -> Animating -> Advancing -> Animating -> Advancing -> (...) -> Ending -> Inactive

 

The same is reflected in the alias script, allowing SLs internal architecture to follow clear principles and properly sectioning the code

 

2.2 sslThreadController.psc

Over the course of SLp+ development, this script will lose more and more logic. The way inheritance is used in SL causes you to have logic split in 3 scripts simultaneously, all focusing on the same chain of execution. This can easily confuse not only those which try to interact with SL but apparently also the ones actually writing on it, as can be observed when looking at how many times code is called multiple times

 

This script will instead be used to hide internal logic for the common author and lay open, proper API in SexLabFramework.psc style to give authors all info they need on how and what they can access and use to interact with a running or ending thread

Internally, this will allow code to be properly merged and streamlined in a way that makes it easier to see where exactly things are called, when they are being called, and where the chain execution ends up in

 

2.3 Centralizing Logic

As already mentioned, SL splits the same chain of execution into multiple scripts. While its common in oop to have different parts of code maintain different tasks, the issue that arises in SL is that this has been taken a little bit... too seriously

This is by far the greatest offender of "repeating code" used to keep a threads actor pieces "independently dependent" on the animations main thread. SLp+ will remove these async calls where they arent necessary and logic that is intended to be shared will be stored on the main thread directly, no longer does data need to be "synced" between these single pieces and most of an animations main loop becomes a more obvious and easier to recognize/follow chain of execution

 

2.4 Conclusion

All these changes together will have the by far biggest influence on SLs micro-optimization-problems. The deletion of repeated code is about 40% of the total starting code (this is not a joke) and properly isolating and marking internal logic will allow for far easier expansion of the framework itself

 

About backwards-compatibility

Spoiler

• Projects which exclusively utilize SexLab public API and only access data from Threads are guaranteed to stay compatible (this should cover 95%+ of all SL mods)
• Projects which interact with thread logic and other internal parts stay compatible so long they do not interact with strictly internal data (This is where, for example DD falls in)
• Projects which actively invade SexLabs internal functionality will become incompatible (This includes SL Utility+, Seperate Orgasm, and projects which try to influence the flow of an animation by actively invading and changing SLs State data, I am unaware of any project doing this)

 

 

Information on the Poll Options:

The poll is multiple choice because I want to see where exactly general interests lie, Id appreciate if you could only vote for up to 3 things on the list and only the ones you are most interested, so that a certain bias towards specific options becomes more obvious to me

No matter which option gets the most votes, the current priority is to get SLp+ at a playable state with roughly the same content that SL currently has. It will be multiple weeks/months before I start working on any of these additions

 

1. Advanced Orgasm Logic

This will introduce a new "base excitement" variable to SLp+ (which can be set by SLA mods) and a second "current excitement" one. Excitement will scale depending on the current scene and base excitement and will likely utilize things such a bone position and velocity to properly calculate excitement gain, s.t. excitement is only added when there is actual stimulation, rather than having these values be based on the animations tags. When excitement hits 100, the specific actor will have an orgasm, instead of having everyone orgasm at the end of the scene

 

Please note that this is an incredibly complex system that will require a lot of testing and research. You can perhaps compare it with how CBPC calculates the strength of its physics, we will be using node distance & velocity to calculate stimulation

 

*This will include a custom UI with stimulation bars n all that

 

2. Advanced Sound & Expression Systems

This is related to suggestion 1, where we use the same idea not do calculate stimulation but to add new sounds to SL. Imagine "Slap that ass" but with volume and sound type calculated by measuring and analyzing an actors skeleton. I will likely leave applying visual SFX to other mods btw

 

3. Branched Animations (Including UI) and SLAL2

Imaging you have a Blowjob and the giving Actor could choose whether they want to "pull out" or "keep in". I know that some animators for SL are very interested in adding something like this but lack the necessary tools from SL to actually do so

 

This change will be accompanied by my own iteration of SLAL. This is a necessary step to give animators a way to actually tell SL how to treat their new animations

SLAL2 will also add a lot of other useful features, such as making animations exclusive to vampires or victimized actors and proper in-depth futa support beyond basic recognition

 

*This will include a custom UI to properly navigate the branches

 

4. QoL Fixes & Performance

This is pretty loosely defined but is basically the option to take if you really just want SL to work without any jank whatsoever

 

 

Edited September 1, 2023 by Scrab

[Scrab]

Starting off my first report right away:

 

Due to how aggressive most changes are, there will also be changes to API itself. Most notable, the all famous "StartSex" function has been made redundant, instead SLp+ uses this one as the preferred function to start animations with:

 

Spoiler

 

and the "sslBaseAnimation" class will be reduced to an internal storage class. Gender tags will also become unnecessary making Scene starting much easier and less complicated

 

 

Edited December 22, 2022 by Scrab

[ninjagaidenguy]

Looking forward to this!

[aisa9210]

In LL, people who have created multiple IDs with temporary mail can manipulate votes, so I think it would be good to make it first based on what you need.

 

Personally, it would be cool if Branched Animations (Including UI) and SLAL2 were developed first.

 

That feature seems to have the potential to improve Battlefuck and Yobai or Sleep rape mods.

[alcurad90]

For me, I think the animation control is the most important.

The 4+1 steps of sex scenes is too long for NPC x NPC while it's not controlabe for PC scene.

So first of all I think it's better reduce the basic sex scene to just 2+1 steps,  (animation 1 -> faster -> orgasm )

Then the  Branched Animations feature can ask the PC whether you want more or not

[bathoz]

Good luck to you. Though based on prior work, I have confidence in your ability to create a thing.

 

From a purely end-user point of view, one of the key reasons I enjoy SL is that I have some control. I can end the scene relatively early. I can skip parts, etc. The other way I've experienced is the AAF approach in FO4, where you watch a movie. And the movie is as long as the movie is. And then it's over. Probably good for the animators and consistency, but can lead to mental checkout.

 

Finally, how much buy-in do you have from the likes of Kimy etc?

[Scrab]

5 hours ago, alcurad90 said:

For me, I think the animation control is the most important.

The 4+1 steps of sex scenes is too long for NPC x NPC while it's not controlabe for PC scene.

So first of all I think it's better reduce the basic sex scene to just 2+1 steps,  (animation 1 -> faster -> orgasm )

Then the  Branched Animations feature can ask the PC whether you want more or not

The length of an animation depends on the animator and on your config actually, the frame itself can work with any length of animations from 1 to 2.147.483.647 stages

 

7 minutes ago, bathoz said:

Finally, how much buy-in do you have from the likes of Kimy etc?

Osmel was big help getting me started and resolved some of my early confusion and worries which gave me a major headstart

 

Because the patch is SE exclusive you can assume that all of the LE folks arent going to care about it, similar to how none of the new SE features that Osmel implemented into SL are being used by these projects. Theyll still benefit from some of the changes tho

 

 

 

[Monozero10]

If you need help testing or anything, let me know.

[TnTTnT]

Would be nice if you can collaborate work with OsmelMC and further enhance feature of Sexlab Utility Plus.

 

[Scrab]

14 hours ago, TnTTnT said:

Would be nice if you can collaborate work with OsmelMC and further enhance feature of Sexlab Utility Plus.

Ive already discussed this with Osmel and we decided that the best approach would be to have me maintain my own patch

 

I should also note that due to the scale of p+, nobody other than me can realistically work on the code base until I have a first version ready. p+ isnt "tweaking" SL, its rewriting it inside out, essentially constructing a new code base within SL itself

[TnTTnT]

8 hours ago, Scrab said:

Ive already discussed this with Osmel and we decided that the best approach would be to have me maintain my own patch

 

I should also note that due to the scale of p+, nobody other than me can realistically work on the code base until I have a first version ready. p+ isnt "tweaking" SL, its rewriting it inside out, essentially constructing a new code base within SL itself

 

Sorry, I didn't know that.

Thanks for your explaination.

Enjoy X'Mas and Happy New Year.

[Ery2]

This sound like a good project. Hyped for the eventual release!

[Scrab]

Lemme throw you guys a bone:

 

 

Im not sure where exactly the FPS went, making that recording just cut them in half for some reason, more importantly this here is my current WIP featuring most of the important changes to the thread & animation logic in this first iteration

 

What you can see here:

• The MM I use takes about 10 seconds to start an animation, I cast the second spell at 3 seconds, and am unable to move at 13 seconds, which indicates that the preparations of a SL Scene with SLp+ takes only about a second or less to complete
• Actors will path towards you at the moment the preparations are to be completed and the scene starts only a second later. The only noticeable delay between the completion of preparations/pathing and the actual starting the animation is the time in which actors are being "placed" in position (the only visual indicator for this "placing" is the actor being stripped) but we  can all agree that this short delay doesnt actually change anything on the fact that this is multiple times faster than default SL
• The final part of the video gives you information of the placement. The entire placement logic has been remade in SLp+ and you can see that this new logic I use is incredibly accurate, the maximum error in placement Ive seen thus far is still less than 0.1 units, which is much much less than what SL used to consider acceptable (SL accepted an error of up to 30 units)

 

Please note that:

My game does not use any kind of "performance mods" to speed up papyrus, such as papyrus tweaks. Meaning this is vanilla papyrus during the initialization process of a bunch of other mods, such as CF, ZAZ and DD and that the matchmaker I used here is SL Mass Matchmaker without any modifications, i.e. what you see here is the speed of SLp+ using legacy functions (which are performing much worse than the new ones included in SLp+)

 

.. so you can assume that SLp+ would be even faster if I

• Would not have my FPS gutted by the recording
• Would have waited for all these mods to initialize
• Would tweak the matchmaker to use the new functions instead

 

For a proper test release version something something upload I still need to

• Take a look at genders, in particular the multi variable gender to properly recognize futa actors in the given data key
• Add support for creeature animations, which are currently completely neglected
• Redefine actor adjustements, this is that you can move actors mid scene. This is actually very important for some default animations which are heavily misaligned otherwise (I know most of you probably disable them anyway but we gotta do what we gotta do)

 

---

 

And some self advertisement:

Im having a dedicated channel for this project on my discord where I post some minor progress reports and oddities I find in SLs code, you can join that one here if you want:

https://discord.com/invite/mycaxFPSeV

 

 

 

 

Edited December 29, 2022 by Scrab

[Frayed]

@Scrab That looks very promising. The slow scene startup is by far my biggest gripe with the current Sexlab framework. With how fast your scene startup seems to be, I foresee an increase in people looking for foreplay animations as going straight from dressed to penetration becomes the next most jarring feature A question for you, though: In my understanding (but I could certainly be wrong) part of the reason the current SL scene startup takes so long is that it scales poorly with the number of possible animations, which naturally after 11 years of mods is now a lot larger than when SL was first designed. How well do you expect your tweaked version to scale?

 

Regardless, I'll be following your development with interest ?

[Scrab]

2 hours ago, Frayed said:

In my understanding (but I could certainly be wrong) part of the reason the current SL scene startup takes so long is that it scales poorly with the number of possible animations, which naturally after 11 years of mods is now a lot larger than when SL was first designed. How well do you expect your tweaked version to scale?

 

Its not actually the quantity of animations that is the problem, but more how they are being processed. I could write up a whole wall about this now but the bottom line is essentially that SL when filtering animations runs every animation through heavily branched multiple hundred line long safety checks - multiple of them. One more strict than the next but thats not necessarily the issue. The animation filtering for SL only takes about 2-3 seconds which admittedly is still 2-3 seconds too much but there is a lot more going on that causes significantly more severe delays

 

As for p+, I hope to eventually write the entire Animation Library for SL into a dll but even it that isnt going to happen (it likely wont happen, as the sslBaseAnimation class is referenced too much by too many mods here) the new way I store data with these datakeys and the fact that I can freely make use of a dll anywhere I want will always have SLp+ way of parsing and validating animations be faster than the one SL currently uses

[Silvain]

This sounds and looks awesome so far. I'm really excited by the new placement logic. Will this also help with actors that don't have the standard scale? I tend to use height overhauls which are always a little bit difficult for SL to handle.

 

 

My personal wishlist would be as follows:

1. VR support - not only just the features but also handling the quirks of VR. SL seems to change how SetVehicle works which causes a spinning camera without patches ->

2. You already have it on your list so I'll keep it short: Backward compatibility.

3. Separate Orgasm feature: if possible with compatibility for mods that rely on SLSO feature so mod authors don't need to rewrite or keep adding support for a second SLSO like system.

4. Options for increased interactivity/dynamic scenes: goes along with the third point but what I mean with this is an api/feature set that allows other mods to have a wide array of influence on the scene that is currently playing. Stuff like being able to hotkey certain expressions, sound effects, animation speed. stage transitions, branching animations and for VR VRIK/PLANCK support.

 

 

On a more realistic note: stability and backwards compatibility are the two most important things I would say.

[Scrab]

1 hour ago, Silvain said:

. VR support - not only just the features but also handling the quirks of VR. SL seems to change how SetVehicle works which causes a spinning camera without patches ->

VR support is difficult as I dont actually have the source code for SLs own dll and dont want to just go ahead and replace all functions in that dll (which I could do) to not unnecessarily provoke Ashal or anything. Id rather have her support in all of this than trying to push her out

 

Then theres also the fact that I will be adding a variety of menus to p+ and Im still not sure if VR actually support that (we are talking about from-scratch menus, not the one from SKSE)

 

Fundamentally, Im making the dll to be compatible with VR and SE (AE) tho

 

1 hour ago, Silvain said:

3. Separate Orgasm feature: if possible with compatibility for mods that rely on SLSO feature so mod authors don't need to rewrite or keep adding support for a second SLSO like system.

Once I get to this system, I plan on using the same event as SLSO does, yes

 

1 hour ago, Silvain said:

4. Options for increased interactivity/dynamic scenes: goes along with the third point but what I mean with this is an api/feature set that allows other mods to have a wide array of influence on the scene that is currently playing. Stuff like being able to hotkey certain expressions, sound effects, animation speed. stage transitions, branching animations and for VR VRIK/PLANCK support.

As mentioned I do plan on adding a variety of menus to simplify customization and manual manipulation

 

Branched Scenes are defined by animators because the transition to a new stage is its own animation, Theres nothing stopping an author from swapping animations of course but a fluent transition can only be made by the animator making that stage as it has been the case for any other animation created until now

 

I have no idea what VRIK or PLANKCK support is and as I dont use VR myself I doubt Ill be able to properly implement anything VR exclusive ?

Edited December 29, 2022 by Scrab

[Silvain]

16 hours ago, Scrab said:

VR support is difficult as I dont actually have the source code for SLs own dll and dont want to just go ahead and replace all functions in that dll (which I could do) to not unnecessarily provoke Ashal or anything. Id rather have her support in all of this than trying to push her out

 

Absolutely fair. Those points were just unrealistic rambling. I know most of the VR stuff is difficult and probably not worth it from a effort-value point of view since it's the least used Skyrim version out there. Hearing that - in theory - the patch will work with VR makes me happy already. 

 

16 hours ago, Scrab said:

Then theres also the fact that I will be adding a variety of menus to p+ and Im still not sure if VR actually support that (we are talking about from-scratch menus, not the one from SKSE)

 

Dunno if that will help but UIExtension works well. The menues from SL Survival and Wartimes use those and they work fine. Stuff like widgets are often more of a problem. 

 

16 hours ago, Scrab said:

Once I get to this system, I plan on using the same event as SLSO does, yes

 

Sweet! Looking forward to it. 

 

16 hours ago, Scrab said:

I have no idea what VRIK or PLANKCK support is and as I dont use VR myself I doubt Ill be able to properly implement anything VR exclusive

 

Also fair.

 

If you're interested I'll put a short description in the spoiler. 

 

Spoiler

VRIK: Is a player avatar mod. It enables having a visible body in VR and that animates with your movement. It also has a lot of extra stuff like having "holster" where you can put your weapons into. You then draw them with a gesture while holding the "grab" key on the controller. You can draw your 2 hander from the back, your dagger from your thigh but also use it to activate certain powers or items. It also changes the player perspective with height, works with physics and a few other things. In short it makes everything more immersive and is probably the most "must-have" mod for VR. Also has additional patches/extending mods that make it work with high heels and SL. If you're interested in what that means the most recent patches for SL and SL + VRIK for VR are here: https://www.loverslab.com/topic/132489-skyrim-sexlab-and-vr/

 

 

PLANCK: Physics. You can slap those hanging signs and they spin. Also works with bodies and stuff. You can grab chickens. And throw them. Nuff said xD Does not have good integrations with any adult mods yet as far as I'm aware and is less important than VRIK overall. 

 

[Someone92]

A QoL suggestions:

A hotkey to disable the current animation. Would make it much easier to get rid of the animations in an animation pack you don't like.

[Scrab]

5 hours ago, Silvain said:

Dunno if that will help but UIExtension works well. The menues from SL Survival and Wartimes use those and they work fine. Stuff like widgets are often more of a problem

These are SKSE menus

What Im talking about are completely new menus, like a second HUD menu or something. I do this in YK a lot

 

29 minutes ago, Someone92 said:

A QoL suggestions:

A hotkey to disable the current animation. Would make it much easier to get rid of the animations in an animation pack you don't like.

I plan on a complete control interface during scenes that lets you control a lot of stuff, such as a mid-scene expression editor or a way to more easily identify which actors position youre currently editing (if youre using that feature). Its possible to add something like that quite easily in fact once everything stands

[indolu]

Looking forward to his. Personally making a new sexlab that just works i think is the first step, adding things afterward. That will help with compatibility in the future too i think. if they don't need to immediately support a new framework but instead naturally shift to the higher preforming then need to make patches that might be a better transition. 

[Karkhel]

I'm still stuck on LE for now but I just wanted to say good luck with your project this looks very interesting. I love that you are gonna replicate Separate orgasm as its one mod that's non negotiable for me, if something replaces it and works with mods that require it its a win. Branching animations where npcs get to pull out could probably make me switch to SE tbh. Would it be possible to ask npc during a scene or is that sort of thing not possible? Like a popup choice or just a button promp to pick an option and then npc might choose to do what was asked or not, or leave that up to a different mod to manage?

[Scrab]

57 minutes ago, Karkhel said:

Would it be possible to ask npc during a scene or is that sort of thing not possible? Like a popup choice or just a button promp to pick an option and then npc might choose to do what was asked or not, or leave that up to a different mod to manage?

There is a whole UI to navigate these scenes which is almost functional already, I just need to fit it to SL, how much freedom you then get to navigate these scenes depends on your config and the mod authors custom settings

 

 

[pinky6225]

Think a few of us have started to use Papyrus Tweaks NG https://www.nexusmods.com/skyrimspecialedition/mods/77779

 

With this option turned on

 

Spoiler

• Speed up native calls (Formerly "Run Scripts On Main Thread")
• Scripts will only run in tasklets that aren't on the main thread most of the time, hence functions like "Game.GetPlayer" or "Formlist.GetAt" needing to be synced to framerate for thread safety. This experimental tweak speeds up most of those calls by syncing them to a spinlock instead of framerate, greatly improving script performance for most scripts. By default, only the read-only/getter functions are sped up this way (ex: "HasKeyword", "IsLoaded", "GetWornArmor", etc.) as they are much more safe than functions that alter the game in any way (ex: "EquipItem", "RemoveItem", "MoveTo", etc.) as those could have issues if ran multiple times in one frame.

 

Which seems to give a boost to the more heavily scripted mods around on LL and makes sexlab itself start a bit quicker, i still get a delay from saying to start one via a dialogue option but it is a lot less than it was without this

 

From what i've read here your trying to make SL more efficent and that is making papyrus run faster, will they be compatible?

[Scrab]

12 minutes ago, pinky6225 said:

Which seems to give a boost to the more heavily scripted mods around on LL and makes sexlab itself start a bit quicker, i still get a delay from saying to start one via a dialogue option but it is a lot less than it was without this

 

From what i've read here your trying to make SL more efficent and that is making papyrus run faster, will they be compatible?

 

Papyrus Tweaks doesnt fix anything, it just increases the tolerance the game has for poorly performing mods and it only affects Papyrus as a whole, not any kind of code specifically

 

SLp+ without Papyrus Tweaks is faster than default SL with Papyrus Tweaks, you can see a preview video above and Ive slightly improved speed since then (to a point where some think I should artificially slow down the code again as it now feels "unnatural")

You can of course continue to use Papyrus Tweaks, you should be able to smooth out the stripping & ending of scenes with it even more. Currently theres still a very short delay where clothes are being stripped off from one actor, then the other though I may work on that in the future too

Edited January 4, 2023 by Scrab