SexLab Aroused eXtended

[rhino_4]

7 hours ago, BlackHawk46 said:

To help with the immersion, I think it'd be cool to add a few more things:

- Idle animations where she starts casually teasing herself at higher arousal levels

- Facial expressions to show that she's 'enjoying herself' a bit more with higher arousal levels, whether she's in idle with a bit of embarrassed blushing, or a sexually aroused expression during sex scenes.

 

Are these 2 features in the aforementioned mods, or am I just doing something weird?

 

If not, anyone know if there is a patch to implement such features?

Your're looking for "Aroused sexy idles DAR" for the idles, and "Blush while aroused" for the expressions.

[archknight]

hello i was just wondering but is there any other mod like this for se i mean where you can say set sexlab aroused possible keywords in game when you put on the armour?

[TJHinSkyrim]

On 11/14/2021 at 3:21 AM, blaatand said:

 

You can define all these factors in the MCMs. Arousal can be set 'to trigger' from 'being around naked NPCs - either by LOS (line of sight), or by physical distance.

You can set specific clothing items (internally dictated by item slots), to be seen as "nakedness" (thus becoming a trigger) ...

There are several versions of some of these mods, some allow you to further define whether specific clothing items should be seen as being "slooty" or some degree of partially naked (again triggering arousal).

Or seen as being high value/respectable/noble clothing - which can trigger other mechanisms - like how NPCs will treat you/talk to you.
    Sexy
    Slooty
    Illegal
    Respectable
    Ragged
    High-Heels
    Bikini

(can also depend on the mods installed)
For instance, the mod Horrible Harassment hooks into those settings.

The arousal levels needed for these behaviors to trigger, can be set in the MCMs as well.
Some settings are found in Schlongs of Skyrim's - some in SLA's MCM (aka SexlabAroused.esm), and so forth.

 

Whether witnessing sex acts should be a trigger can also be defined (if i remember correctly), but there are also other mods which implement specific events that can be triggered by that scenario.

"I've got SOS enabled in SLAX, but I've never seen it trigger."

Depending on the mods in use and assuming the install/load order is correct - it's all a matter of defining these triggers and levels in the MCMs.

 

Also the Player and NPC's sexuality is a factor.

 

So if your Player has a schlong and you want attraction (and arousal) between you and a specific NPC - make sure your sexuality matches each other.

 

For a Male with a Schlong - to animate with a Female - both should be Straight or Bi.
For a Female with a Schlong/Strapon - to animate with a female - both should be Gay or Bi.
-etc etc.

 

For lesbian animations without schlongs, both can be set as females. Otherwise you'll mostly or entirely get "penetration sex animations" and no Lesbian animations (tribbing, etc)

If a schlong/strapon is toggled on and you want "penetration sex animations" - set the one with the schlong/strapon - as a Male (in the MCM of Sexlab.esm)

 

(In other words giving her the male role - (if it's a female and you want her to penetrate the partner), - this setting doesn't affect any other aspects of the game in general.
NPCs won't start considering her a male. [Just adding this because it has confused me in the past a few times]

 

Those roles just define what set of animations the framework hooks into in the given situation.

Some mods have their own similar parameters for this, which can be defined - they might override whatever the (Sexlab Framework MCM) is set to btw.

 

With the mod 'Sexlab Attraction' you can define - 'Overall attractiveness' and whether or not 'Wealth', 'Race', 'Height', 'Weight', etc - should affect attraction also

 

 

Thanks for getting back to me. I think I've got it all working now.

[safado]

On 11/19/2021 at 10:37 AM, archknight said:

hello i was just wondering but is there any other mod like this for se i mean where you can say set sexlab aroused possible keywords in game when you put on the armour?

 

Credits to:

redneck2x: I think is the original Aroused Framework mod creator. MIA since 2014

TheDriedFinger: I think is the developer of Sexlab Aroused Redux optimizations.

Lupine00: for SLAX even more optimizations and stability to the framework.

Tenri: for the fixes.

MasterDev: for a proper SE SKSE64 conversion.

 

Without MasterDev work on the SKSE64's DLL the UnOfficial SE version is not posible.  

Spoiler

 

 

 

The keywords are for use with FactoryClose mods.  factoryclose - LoversLab

There's a guide to add the keywords in the description/download of his BaboDialogue mod.  About Sexlab Aroused Redux Additional Keywords.pdf

The easiest is using the MCM current armor menu but is done only to equipped armor manually.  

 

 

Edited November 21, 2021 by safado

[Nymra]

sorry for my ignorance but I still need days to read and understand new scripts

 

I am looking for a Script that I can call from my mod that will change the Arousal of a selected NPC actor.

Like 

Function ChangeArousal()

Actor.SetArousal(0) 

EndFunction

 

Ideally I would also love to lock an actors arousal at a certain value for some time.

Like "Actor.LockArousal(true/false).

 

Are there any functions like that? and if so, where exactly can I find them?
Thanks alot!

 

BTW: since this is SLAX would be cool if these are functions that work with all SLA versions.

 

[HexBolt8]

2 hours ago, Nymra said:

Function ChangeArousal()

Actor.SetArousal(0) 

slaFrameworkScr has what you want:

 

UpdateActorExposure(Actor who, Int exposureDelta, String debugMessage = "")
SetActorExposure(Actor who, Int newActorExposure)

 

2 hours ago, Nymra said:

Ideally I would also love to lock an actors arousal at a certain value for some time.

Like "Actor.LockArousal(true/false).

SetActorArousalLocked(Actor who, Bool isLocked)

[Nymra]

3 hours ago, HexBolt8 said:

slaFrameworkScr has what you want:

 

UpdateActorExposure(Actor who, Int exposureDelta, String debugMessage = "")
SetActorExposure(Actor who, Int newActorExposure)

 

SetActorArousalLocked(Actor who, Bool isLocked)

 

thanks alot!!! 

[archknight]

20 hours ago, safado said:

 

Credits to:

redneck2x: I think is the original Aroused Framework mod creator. MIA since 2014

TheDriedFinger: I think is the developer of Sexlab Aroused Redux optimizations.

Lupine00: for SLAX even more optimizations and stability to the framework.

Tenri: for the fixes.

MasterDev: for a proper SE SKSE64 conversion.

 

Without MasterDev work on the SKSE64's DLL the UnOfficial SE version is not posible.  

  Reveal hidden contents

 

 

 

The keywords are for use with FactoryClose mods.  factoryclose - LoversLab

There's a guide to add the keywords in the description/download of his BaboDialogue mod.  About Sexlab Aroused Redux Additional Keywords.pdf

The easiest is using the MCM current armor menu but is done only to equipped armor manually.  

 

 

Just wanted to say thank you

Edited November 21, 2021 by archknight
want -> wanted

[benjamin713457]

In case someone has the same problem i do:

 

I think it was after i upgraded from SLAR to SLAX, and i looked in the actor selector in the Puppet Master selector where there were 3 actors to choose from.

I noticed that the third actor would always be there, despite me not having interacted with it for a long time.

 

I used Fallrimtools Save cleaner, and digged around. Turns out that in the script instance of "slaconfigscr", there was a variable called "slaMostArousedActorInLocation_var" which contained the ID of the actor that wouldn't go away from the menu. I changed the value to my own player actor ID, and after that i only had 2 actors to choose from, myself and the one i've selected.

[metalar]

this work with Skyrim AE ? thanks 

[Taki17]

On 12/31/2021 at 4:49 AM, metalar said:

this work with Skyrim AE ? thanks 

It won't. Its dll would need to be recompiled.

Edited January 2, 2022 by Taki17

[abdulah2]

Is there any particular reason to not rewrite this mod's scripts using Global Variables insteaf of Factions? Globals store floats (float arousal = no more rounding cancer!) and GetValue() and SetValue() functions are non-delayed whereas all Faction related functions aren't. For instance, a single GetActorArousal call goes through 8 Faction calls. That's 8 frames spent per call, or 136ms at 60fps.

By itself it's not insane, and there are definitely other exceedingly simple tweaks that can be done to increase performance at no functionality cost as well (like fixing the rampant function re-use), but there are many other delayed calls that can't be skipped because there is no good alternative to use. So at least ditching the Faction usage would speed up the whole thing a fair amount.

Besides dependent mods that checked SLA factions directly (which they shouldn't) breaking, what other downside is there?

[HexBolt8]

25 minutes ago, abdulah2 said:

Besides dependent mods that checked SLA factions directly (which they shouldn't) breaking, what other downside is there?

This.  Arousal level checking outside of scripts, such as condition checking for dialog topics, quest conditions, and so on, is being done using the faction.  Mods will break if this changes.  However beneficial it might have been to take another approach, the original Aroused set the standard.  If this mod were to deviate from that, it would no longer be a transparent replacement.  When there's breakage, players won't care that it's a few cycles faster.  This is unfortunate, but it makes such a change impractical.

[abdulah2]

2 hours ago, HexBolt8 said:

This.  Arousal level checking outside of scripts, such as condition checking for dialog topics, quest conditions, and so on, is being done using the faction.  Mods will break if this changes.  However beneficial it might have been to take another approach, the original Aroused set the standard.  If this mod were to deviate from that, it would no longer be a transparent replacement.  When there's breakage, players won't care that it's a few cycles faster.  This is unfortunate, but it makes such a change impractical.

Globals are also usable as conditionals. But yeah, I guess everything that used SLA Factions in form conditionals would break until updated. What a shame.

[Eviance]

So, I am using this mod and for some reason exposure -never- updates.
ive tried longer arousal scanning and shorter arousal scanning, nothing seems to make a difference
I have the tenri patch.

Edited January 6, 2022 by Eviance

[HexBolt8]

7 minutes ago, Eviance said:

I am using this mod on LE and for some reason exposure -never- updates.

Yours, or NPC's?  Or both?

[Eviance]

30 minutes ago, HexBolt8 said:

Yours, or NPC's?  Or both?

Both, I tried disabling all mods except for these and the issue persists.

Skyrim.esm

Update.esm

Unofficial Skyrim Patch.esp

Dawnguard.esm

Unofficial Dawnguard Patch.esp

HearthFires.esm

Unofficial Hearthfire Patch.esp

Dragonborn.esm

Unofficial Dragonborn Patch.esp

CreatureFramework.esm

Schlongs of Skyrim - Core.esm

ZaZAnimationPack.esm

SexLab.esm

Devious Devices - Assets.esm

SexLabAroused.esm

Devious Devices - Expansion.esm

Devious Devices - Contraptions.esm

RaceMenu.esp

Schlongs of Skyrim.esp

BDLoincloth.esp

SkyUI.esp

RaceMenuMorphsUUNP.esp

RaceMenuPlugin.esp

SOS - Leito Addon.esp

SOS - Smurf Average Addon.esp

SOS - VectorPlexus Muscular Addon.esp

SOSRaceMenu.esp

XPMSE.esp

SOS - Shop.esp

Devious Devices For Him.esp

Devious Devices - BRRF.esp

SOS - VectorPlexus Regular Addon.esp

SD Addons.esp

Alternate Start - Live Another Life.esp

 

 

Edited January 6, 2022 by Eviance

[HexBolt8]

1 hour ago, Eviance said:

Both, I tried disabling all mods except for these and the issue persists.

You're not on AE, by chance?  This mod uses a DLL.  Beyond that, exposure is driven by nudity.  Are you around any naked NPCs?  Are you naked, or wearing torso apparel flagged as naked in this mod's MCM?  Just trying to rule out any obvious problems.

[DayTri]

22 hours ago, abdulah2 said:

Globals are also usable as conditionals. But yeah, I guess everything that used SLA Factions in form conditionals would break until updated. What a shame.

 

But how many globals? The framework supports arousal for player and NPCs. In order to use globals, you need to create lots of them and then have some kind of pointer between NPC and the global variable, and a way of swapping out unused actors when you run out of globals. But dialog still wouldn't be able to know which global to access for which NPC. If it was player only then globals would make sense.

[abdulah2]

On 1/7/2022 at 5:49 AM, DayTri said:

 

But how many globals? The framework supports arousal for player and NPCs. In order to use globals, you need to create lots of them and then have some kind of pointer between NPC and the global variable, and a way of swapping out unused actors when you run out of globals. But dialog still wouldn't be able to know which global to access for which NPC. If it was player only then globals would make sense.

Yeah I was thinking player-centric. Globals for player only would still help, though it won't be as dramatic, and would be a lot of hassle to code.

 

 

On an unrelated note, here's an edited slaFrameworkScr that aims to tame a bit the infuriating way the original operated. With one exception, no functionality has been lost at all, that exception being the use of voicetype to determine the initial exposure rate. (Reverted to using voicechecks; check next page for info) Perhaps it sounded cool originally but, as Lupine00 also points out in their comments, it's slow and probably can cause more harm than good. I replaced it with a simple randomizer.

 

On to the more juicy stuff, a factor in the slowness of SLA and its successors was the waste of power to re-calculate things that weren't saved when they should have been.

For example: GetActorArousal(Actor who) is the function that calculates and returns a given Actor's arousal. So far so good. It is also called by other functions, namely SetActorExposure and FloatUpdateActorExposure (UpdateActorExposure before SLAX), to update the arousal of a given Actor after those functios have calculated its exposure. Okay, perhaps a different function could be used for that but it's not the end of the world.

However, here's the stupid part. GetActorArousal needs to add 2 things to calculate arousal: time arousal and exposure. No matter how it was called, it calculates BOTH. This means if SetActorExposure just set an Actor's exposure before calling GetActorArousal, then GetActorArousal would RECALCULATE that Actor's exposure to find their arousal. That's dumb. SetActorExposure could have simply passed the up-to-date exposure value it just set to GetActorArousal so that recalculation could be skipped.

All in all, with GetActorArousal two sins have been commited. First, it is one function that does two different things: calculate time arousal and calculate total arousal. This should have been split into two functions, one to only calculate time arousal (like GetActorExposure only calculates exposure) and another to calculate total arousal. Second, it recalculates things that don't always need to be recalculated, resulting in wasted time/processing power. My edit only fixes the second, as fixing the first by splitting it into two functions would break dependent mods that use GetActorArousal to get an Actor's total arousal.

 

Similarly, GetActorArousal also calls many other functions in its calculations but does the same mistake in letting them recalculate things that GetActorArousal already did (it already calls and stores GetActorDaysSinceLastOrgasm, so why not pass it to GetActorTimeRate and GetActorFatigue instead of letting each recalcualte it?) or calling functions that will need a specific value but lets each calculate it on its own instead of calculating it itself and passing it to them (GetActorTrauma and GetActorMasochism will both call GetActorDaysSinceLastRape so why not do it before calling them and pass them the value? Also, both GetActorDaysSinceLastOrgasm and GetActorDaysSinceLastRape need the current time which GetActorArousal has. Why not pass it to them?).

All those things, while quite simple calculations that wouldn't be worth a mention were we using an actual programming language, each call at least one of the so-called Latent Papyrus functions (usually GetCurrentGameTime()) and that's the source of the problem. Each of those functions will not return until the NEXT frame at minimum. If at the time one such function called the game was running at 60fps then that function will take up to 17ms to return, assuming the game started processing it RIGHT after a frame was rendered. Having multiple of them in a row, with simple or no calculations inbetween, will average that time at close to 17ms. Those delays aren't because those functions are heavy or anything. It's just how the language works because Bethesda made it so. More on Latent functions:

Latent Functions on the Wiki

NOTE: you'll notice that only a few functions are listed in the above link. This DOESN'T mean that only those functions are Latent/delayed/whatever-you-wanna-call-them. I don't know why that is but I've tested multiple different game functions myself and they all behave like Latent functions EXCEPT:

Non-delayed Native Functions on the Wiki

The functions in the above link are not subject to that frame delay and will return as soon as they are done. Functions created by mods or SKSE functions are also NOT subject to the frame delay. So if you wanna know if a function is delayed: if it's a mod function, an SKSE function, or in the link above, it is not delayed. Otherwise, it's probably delayed.

 

Besides those, there are some other very minor edits. For example, in many functions LewdMod() was repeatedly called. LewdMod() doesn't call any delayed functions but it is still slower to call it multiple times compared to calling it once and storing the value and then just using that value. Many functions also use various Properties of slaConfig. Getting a property is very, VERY slightly slower than using a local variable but the main benefit is that it makes the code much more readable. Still, both are performance upgrades, albeit tiny.

 

I've been writting a mod that, at times, needs to increment exposure and then get an Actor's arousal. I profiled calling UpdateActorExposure and then GetActorArousal at 60fps and it was taking ~1200ms (!) for both. With my edit, which I've been using these past few days, it takes me ~780ms. Still a lot, partly because UpdateActorExposure wastes the value GetActorArousal returns to it so GetActorArousal ends up being called twice, but about 33% faster than before.

Some more profilings:

GetActorArousal: original SLAX ~540ms,  edited ~420ms

GetActorExposure: original SLAX  ~125ms,  edited ~95ms

UpdateActorExposure: original SLAX ~700ms,  edited ~360ms

The time saved in GetActorExposure is purely from stopping the debug messages from being called if debugging is disabled. This check was performed AFTER GetActorExposure called a Latent function to pass as input, and it happened twice, hence the ~30ms saved from having to wait 2 less frames.

Also worth noting that UpdateActorExposure basically became twice as fast, since it now passes to GetActorArousal everything it has that GetActorArousal would need, like the time, the IsChild check, and of course the exposure value. SetActorExposure would see a similar speedup for the same reason, though I didn't bother profiling it.

 

Attatched is the script along with its source. Commented below each edited function is its original code, as taken from SLAX.

Also attatched are the profiling logs. I ran each function in a simple loop 20 times with a loop overhead of ~0.35ms which is completely negligible.

 

EDIT: If you start using this mid-playthrough then the Status page in MCM as well as many parts of the passive arousal updates in Main will break because of how they handle their quests. A simple solution that involves no further scripting is to recompile slaconfigscr.psc and slamainscr.psc. No edits are needed, just recompile the original source. Just make sure to have my slaFrameworkScr.psc replacing the original one. To verify it worked press the arousal message hotkey ingame (default N). If the message says anything but 0 then it worked (assuming player's arousal isn't 0).  As for MCM, just go in Status page. If it shows the arousal value correctly as the sum of the displayed exposure and timearousal then it also worked. New games shouldn't have this issue.

 

EDIT2: Head here for more up to date edits of mine. Read this post and the post below for documentation only.

 

Edited January 30, 2022 by abdulah2
updates

[abdulah2]

As a continuation to my above post, I applied the same thinking in slaMainScr as well as the other functions I hadn't touched in slaFrameworkScr before. It still centers around functions passing down the chain of function calls information that would be needed later and they already have, with minimizing delayed function calls as much as possible.

Besides the change in GetActorExposureRate, which used to use voice types to get the rate, that I described in the above post, there are no functionality changes in any of the functions uploaded. There are a couple of fixes but otherwise they do exactly they did, just more efficiently.

 

The slaConfigScr.pex included in scripts.7z has had no changes in its source whatsoever. I simply compiled it anew to try and fix the issue where MCM Status page breaks if my scripts start being used mid-playthrough. I say "try" because it may not work unless you compile it yourself, though it should. If you are starting a new game and want to use my files then you shouldn't need that script from me at all. Edit: Paragraph obsolete. Read Edit2 at the end

 

slaNakedScript, slaScanAllNPCScript, and slaScanAllScript contain the simplest changes. I simply replaced GetActorRef(), which is a delayed function calling another delayed function as per the CK wiki, with GetReference() as Actor which is a non-delayed function and a typecast. Typecasts have no delays either so this is a lot faster than GetActorRef(). The result returned in the end is exactly the same.

 

slaFrameworkScr got the rest of its calculating functions updated to minimize the recalculation of stuff in a chain that had already been calculated before. Do not confuse this with any kind of caching. Nothing is being cached. All the changes are doing is that if a function knows Utility.GetCurrentGameTime(),  for example, and is about to call a function that would also need Utility.GetCurrentGameTime() then, instead of letting the second function recalculate it, the first function passes the value down. This reduces the run time of the first function by 1 frame, since the second function, which the first function waits for before finishing, doesn't waste that frame to call Utility.GetCurrentGameTime(). Getting the time was a major offender in wasteful delayed calls, another being Faction related functions that we sadly can't skip without breaking mod dependencies.

Note: I implemented a new StorageUtil int value called SLAroused.ActorArousal in which GetActorArousal stores each Actor's arousal after calculating. It follows the exact same logic other functions like GetActorExposure do. The benefit is that other mods can get an Actor's arousal very quickly through StorageUtil and rely on SLAX's passive arousal updates to update it, if their needs don't require them to have a completely up-to-date arousal value. To get it, use

StorageUtil.GetIntValue(someActor, "SLAroused.ActorArousal", aDefaultIntValue)

where someActor is the Actor whose arousal you want and aDefaultIntValue is an Int that will be returned if that actor's arousal has never been set in StorageUtil.

 

 

Lastly, and more importantly, slamainscr got its arousal update code overhauled. But before that, there is three things that I fixed.

 

First, there exists a function in there called UpdateClothedArousal. It is called during arousal updates when the MCM option "Require naked actors to change arousal."  is not checked and the pair of actors that were being processed atm (pairs is mainly how exposure updates are handled, one actor seeing and the other being seen) were both not naked. The thing is, this function is empty. It was never implemented. The way the arousal update actually worked was that, if the MCM option was off, it would update the arousal of everyone seeing a naked actor. That's it. Nothing would be done with clothed actor pairs because UpdateClothedArousal was empty. Since it is empty I could not account for it in my overhaul, as I'd need to know its math to do that. Instead, I replicated the original MCM-option-on functionality and in case the option is off then I made it so every actor scanned will at least get their arousal updated by having GetActorArousal called on them.

 

Second, again during passive arousal updates, when an actor was recognized as naked and another actor "saw" them, the naked actor was supposed to get some exhibitionism if a cooldown (set in the MCM) had passed since the last time they were seen. To check that condition, slaFrameworkScr's GetActorTimeSinceLastSeenNaked was called and its return value was checked against said cooldown. And the way GetActorTimeSinceLastSeenNaked calculated its return value would be to subtract

StorageUtil.GetFloatValue(Who, "SLAroused.LastSeenNakedTime", 0.0)

from Utility.GetCurrentRealTime(). The problem is that SLAroused.LastSeenNakedTime was never set by SLAX, meaning the above call would always return its default 0.0 and that, subsequently, GetActorTimeSinceLastSeenNaked would always return Utility.GetCurrentRealTime(). This, in turn, would lead to the check against the cooldown to always return false before seconds equal to the cooldown had passed since the game started and always return true if at least as many seconds as the cooldown had passed since the game started. Iirc it was mentioned in the thread that setting SLAroused.LastSeenNakedTime to Utility.GetCurrentRealTime() had the issue that after a game session ended and a new one started then the new would have to last as long as the previous one before exhibitionism updates started happening. The fix, however, wasn't to not set the value but to simply reset it on game start, since Utility.GetCurrentRealTime() also resets on game start. I did exactly that, in slamainscr's Maintenance(). When it runs, which is on game start, it resets this value on every actor it was found on. Of course, I also made exhibitionism updates also update that value to Utility.GetCurrentRealTime() so that the cooldown can actually work as a cooldown.

 

Third, setting an actor to be an exhibitionist during arousal updates was broken. The function in slaFrameworkScr responsible for it was called with faulty arguments resulting in actors that should be made exhibitionists to be unmade instead, even if they were one already. The fix was as simple as changing a boolean's value so I'm not going into more specifics.

 

And as far as the overhaul goes, there are too many things to go into. The function that is called to do the arousal updates is UpdateActorArousals(). In contrast with its name, it didn't actually update much of anyone's anything. The only update it did itself was to call GetActorArousal on the naked actor if the require-naked option was checked in the MCM and there was exactly one naked actor in the update. Every other arousal/exhibitionism updating happened in another function named UpdateNakedArousal, which UpdateActorArousals() repeatedly called. As you can maybe imagine by now, there were many things that were needed by UpdateNakedArousal, like the gender preference or sex of actors, that were never somehow stored resulting in it re-obtaining them every time. There was also the issue of constant function-hopping which, although not very costly, did slow down things a bit. And the major issue is that it could potentially do multiple arousal updates on an actor under some conditions. As mentioned earlier, the way arousal updates process actors is in pairs. Each actor and each naked actor were passed to UpdateNakedArousal as a pair. So an update that scanned 5 actors of which 3 were naked would call UpdateNakedArousal 12 times. Each of the 2 clothed actors would form a pair with each of the 3 naked actors (6 pairs) and each of the 3 naked actors would form a pair with each of the other 2 naked actors (6 more pairs). And this is the issue. Each UpdateNakedArousal updated the exposure of the "observer" actor it received resulting in 12 updates, spread among 5 actors. That is 7 updates too many. It would be exactly equivalent to update each actor's exposure once with the sum of the values. Additionally, if a naked actor was also an exhibitionist they would also receive an exposure update if passed to UpdateNakedArousal as the "observed" actor. These updates could also be added to a sum and performed with a single call. Now, if there was a single naked actor then each other actor would get processed only once, and only if that naked actor was an exhibitionist would it result in multiple exposure updates for them, but for 2+ naked actors there were guaranteed to be pointless exposure updates that could be replaced with one summed-up one.

So that's what I did. UpdateNakedArousal is no longer used and UpdateActorArousals() is now doing all the work, as its name suggests. It will obtain exactly the information it needs for each actor and store it before doing the calculations UpdateNakedArousal previously did but will not do anything other than that until all the math is finished. Afterwards it will update the exposure and exhibitionism of each actor, as well as (now properly) set an actor to be an exhibitionist if the threshold set in MCM is reached. The result is that exactly one arousal related function will be called on each actor, as well as exactly one exhibitionism related function on each naked actor. What gets called on who follows the logic of the original implementation which I won't get into here but I sort of documented it for a comprehensive read in the source files attatched.

 

As for the time saved, I'm attatching a load of profilings done with and without my edits. The profilings were done with 1+ naked actors and the require-naked MCM option enabled. Their name format is as follows:

a3n1_1__game_3009_(1003).log

a3: 3 actors scanned

n1: 1 of those actors is treated as naked

_1: this was the first log generated with the above actor combination. Not otherwise useful information.

game_3009_(1003): 3009 is the miliseconds measured through scripting by calling Utility.GetCurrentRealTime() before and after UpdateActorArousals(). That function returns the seconds since game start as a float, so I subtracted after from before then multiplied by 1000. 1003 is 3009 divided by the number of actors scanned.

So in the example line, 3 actors were scanned, 1 of them was naked, it took 3009ms for the function to finish and 1003ms was "spent" on each actor.

Note: that 1003 number may seem a weird thing to measure but it is a quite useful metric. Basically, it is what we need to reduce to speed up the update.

Note2: "Aren't these profiling logs? What's the deal with also timing them in-script?" Yes, these are profiling logs which you can parse in any profiling parser for SSE (probably LE too). The reason I also timed them in-script is to make my own life easier when creating these logs. I simply had the message printed in the console after every update for easy debugging. I sampled a few logs at random and the game timings seen in the filenames are basically identical to the profiling numbers you get by parsing the log, plus 10-20ms which is probably from the frame used calling Utility.GetCurrentRealTime() after the profiling was finished (I started and stopped the profiling exactly before and after UpdateActorArousals() was called for maximum accuracy), so yeah either read those or parse the logs.

 

Edit: Adding some profiling comparisons

Listing the fastest and slowest time, and the number of times each actor combination was ran (instances).

 

3 Actors, 1 of which naked:

Original: 2822ms to 3009ms (6 instances), => 940ms to 1003ms per actor

Edited: 1509ms to 1604ms (5 instances), => 503ms to 534ms per actor

 

6 Actors, 1 of which naked:

Original: 5575ms to 5986ms (6 instances), => 929ms to 997ms per actor

Edited: 2382ms to 2739ms (6 instances), => 399ms to 456ms per actor

 

9 Actors, 1 of which naked:

Original: 8363ms to 8805ms (4 instances), => 929ms to 978ms per actor

Edited: 3203ms to 3292ms (6 instances), => 355ms to 365ms per actor

 

12 Actors, 1 of which naked:

Original: 11169ms to 11474ms (4 instances), => 930ms to 956ms per actor

Edited: 4120ms to 4290ms (6 instances), => 343ms to 357ms per actor

 

15 Actors, 1 of which naked:

Original: 13994ms to 14299ms (4 instances), => 932ms to 953ms per actor

Edited: 5021ms to 5109ms (6 instances), => 334ms to 340ms per actor

 

15 Actors, 2 of which naked:

Original: 26468ms to 26724ms (3 instances), => 1764ms to 1781ms per actor

Edited: 5237ms to 5310ms (6 instances), => 349ms to 354ms per actor

 

15 Actors, 3 of which naked:

Original: 38793ms to 38989ms (3 instances), => 2586ms to 2599ms per actor

Edited: 5373ms to 5500ms (6 instances), => 358ms to 366ms per actor

 

The original implementation essentially did all it's work again for every naked actor, which is why its numbers get so absurd with 2+ naked. The same doesn't happen in the edited version is because all the extra naked actors do is make it do a bit more math. Also, the reason the time per actor in the edited version drops as actors increase is because the time overhead generated from the scanners is mostly static. The reason the time per actor in the original version doesn't do it as much is probably because of factors like function-hopping. Its higher numbers also make it harder to spot but there is a slight decrease on the time per actor there as well.

 

Edit2: Apparently, adding/removing parameters of a function breaks scripts that were compiled using that function as reference, in that all their SLA function calls end up not going through/doing nothing. So, me adding parameters to most functions in slaFrameworkScr breaks pretty much every mod that used SLA, since that script is the "API". The solution is as simple as renaming all the functions I added parameters to and adding a wrapper function with the original name and parameters for each of them. The API seems to work fine for other mods with said wrappers in place so I'm reuploading scripts and sources with the new slaFrameworkScr and slamainscr. slamainscr was simply made to use the non-wrapper versions internally. The recompiled slaConfigScr.pex is not included anymore since adding wrappers fixed that one breaking too.

 

Edit3: Head here for more up to date edits of mine. Read this post and the post above for documentation only.

 

 

Edited January 30, 2022 by abdulah2
updates

[Silvain]

On 1/13/2022 at 3:24 AM, abdulah2 said:

As a continuation to my above post,

 

Thanks for the interesting read (even though I barely understand coding related stuff). I'm in the process of setting up a new playthrough and wanted to test your scripts but sadly something is causing quite a bit of crashes. 

I doubt it is related to your scripts since Netscript doesn't show anything related (or anything at all really which makes it frustrating), but as soon as I get it sorted out I'll do a bit of playtesting. 

[Silvain]

On 1/13/2022 at 3:24 AM, abdulah2 said:

Edit2: Apparently, adding/removing parameters of a function breaks scripts that were compiled using that function as reference, in that all their SLA function calls end up not going through/doing nothing. So, me adding parameters to most functions in slaFrameworkScr breaks pretty much every mod that used SLA, since that script is the "API". The solution is as simple as renaming all the functions I added parameters to and adding a wrapper function with the original name and parameters for each of them. The API seems to work fine for other mods with said wrappers in place so I'm reuploading scripts and sources with the new slaFrameworkScr and slamainscr. slamainscr was simply made to use the non-wrapper versions internally. The recompiled slaConfigScr.pex is not included anymore since adding wrappers fixed that one breaking too.

 

Profilings.7z 1.46 MB · 12 downloads scripts_apifix.7z 22.15 kB · 3 downloads source_apifix.7z 21.2 kB · 3 downloads

 

A bit late but that was my observation as well. Started noticing it with SL Widgets that did not display any changes in arousal anymore. Then other stuff also behaved weirdly.

I'm gonna test the new scripts this weekend. Thanks again for your work on this. 

 

[abdulah2]

15 hours ago, Silvain said:

 

A bit late but that was my observation as well. Started noticing it with SL Widgets that did not display any changes in arousal anymore. Then other stuff also behaved weirdly.

I'm gonna test the new scripts this weekend. Thanks again for your work on this.

 

You're welcome, and please lmk if you find more weirdness.

[ThatMother3Song]

I downloaded this mod and I am quite excited to use the defeat baka edition, but when I downloaded this mod, My Norton anti virus software said these files contained something to change my system 32, should I be afraid? Has anyone else experienced this?