SexLab Disparity

[hextun]

9 hours ago, hextun said:

I had an idea... what about introducing a set of global variables (i.e. GLOB records in the .esp), maybe even with an API for "claiming" them. The idea then would be that SLD would monitor those additional GLOB values and allow you to create effects based on those values.

 

How would this help? Expandability. You could easily create patches where, for example, a set of values is periodically checked and the GLOB updated, or an event handler is registered for a mod and when it fires, a result is updated to the appropriate GLOB. And SLD would just merrily go about its business applying the changes based on its periodic scan of the value.

 

It would mean that, up to the limit of the number of GLOB values added and manageable, SLD could then be extended to match any condition you want, provided a suitable patch script was written. Heck, you could just use it by updating values via console commands if you wanted.

 

Thoughts?

 

That didn't take as long as I thought. THIS IS NOT SAVE COMPATIBLE AS SOME MEMORY STRUCTURES ARE ONLY INITTED ONCE AND I DID NOT BOTHER TO GO BACK AND CHANGE THAT. SORRY FOR SHOUTING.

 

** Removed the download; see post below **

 

Changes:

v14.4.4
+ _fwb_apropos2.psc: Checks for the editorID then falls back to FormID checks
+ _fwb_modifiers.psc: fixed bug with Wear and Tear Oral modifiers
+ _fwb_modifiers.psc: added GLOB record trackers
+ FWB_SexLabDisparity.esp: added GLOB records

 

Note: To use the GLOB trackers, set your buff/debuff values as desired for a given GLOB tracker in the MCM. There are 5 and I am a programmer so they are titled 0-4:
  _fwb_GLOBTracker0
  _fwb_GLOBTracker1
  _fwb_GLOBTracker2
  _fwb_GLOBTracker3
  _fwb_GLOBTracker4

The buff/debuff scaling goes from 0.0-100.0 so bear that in mind when setting the GLOB values.

 

You can set a GLOB via the console:
  set _fwb_GLOBTracker0 to 33.3

 

So, if you enable GLOB Tracker 0, and set buffs to 100% and Speechcraft to 100, then open the console and "set _fwb_GLOBTracker0 to 42", once SLD updates you should see a +42 buff to Speechcraft.

 

Similarly if another mod is patched to modify one of those GLOB trackers, SLD will behave accordingly.

 

The GLOBs are added as a property of _fwb_modifiers.psc so the .esp has been updated. If you wanted to add more GLOBs (so that you have 10, 20, or 50 GLOB trackers available), you would need to:

- add the GLOB records to the .esp

- add the created GLOB records to the globTrackers property of _fwb_modifiers

- and, because Papyrus is a dork and does not do 2+ dimensional arrays, you have to modify _fwb_modifiers.psc and add some globTracker_##_XXXX variables and handling. It's cookie cutter, so follow the trail of crumbs.

 

Let know what you think.

Edited January 17 by hextun

[hextun]

It occurs to me you could do "staged" buffs/debuffs. Like if you build a modpack and wanted to trigger various effects based on the player's progress across multiple mods, you could tie it to a few GLOB trackers. 

 

Self-pitch: I develop SLTriggers Redux, which makes it pretty easy to create scripts that don't require pre-compiling papyrus, including messing with GLOB records.

 

Whether you use that or create a Papyrus patch, you could imagine periodically checking whether the player has completed various questlines, or for example tying into SunHelm or Starfrost or any of the other survival mods and polling warmth values, you could apply additional effects.

[Hex Bolt]

6 hours ago, hextun said:

I had an idea... what about introducing a set of global variables (i.e. GLOB records in the .esp), maybe even with an API for "claiming" them. The idea then would be that SLD would monitor those additional GLOB values and allow you to create effects based on those values.

An interesting idea in principle, but in practice, other mod authors are unlikely to want to interact with these global variables (I know I wouldn't).  Another mod would have to either make SL Disparity a hard dependence or make use of clunky GetFormFromFile functions and hope that the IDs never change.  Instead, why not use StorageUtil?  It doesn't need GetFormFromFile or require a new dependence.

[hextun]

14 minutes ago, Hex Bolt said:

An interesting idea in principle, but in practice, other mod authors are unlikely to want to interact with these global variables (I know I wouldn't).  Another mod would have to either make SL Disparity a hard dependence or make use of clunky GetFormFromFile functions and hope that the IDs never change.  Instead, why not use StorageUtil?  It doesn't need GetFormFromFile or require a new dependence.

 

That is such a better idea. I'm .. um.. I'm going to be over here coding a bit... *writes that down*.

[hextun]

Taking the download down. While the first version (GLOB only) had been working, when I added the StorageUtil bits, it broke the load and save. Saving leads to an unbound loop (missing incrementor) and thus a corrupted save file. I'll repost once it's tested and ready.

 

Edited January 18 by hextun
Removed non-functional upload

[hextun]

Since a new feature (two I suppose) is (are) being added, I've gone ahead and bumped the minor version, so welcome to 14.5. This is the same as 14.4.4 just with less bug.

 

I've tested the save/load. Old exported settings will not work on load; the new fields are missing and the framework does not appear to tolerate that. I verified that by regressing to 14.4.3, and removing an entry from an exported settings file; it also failed to load. At this point I consider this a pre-existing issue. Unfortunately that will mean rebuilding your settings, possibly from memory.

 

It should, however, attempt to auto-update, so you may be able to use this on an existing save; you'll just have to recreate your settings from scratch once and re-save them.

Note: On further testing, updating an existing save did not work for me. For now a new save will be required until I find the issue.

 

Here's the changes.txt entry:

v14.5
+ _fwb_apropos2.psc: Checks for the editorID then falls back to FormID checks
+ _fwb_modifiers.psc: fixed bug with Wear and Tear Oral modifiers
+ fixed build environment
+ _fwb_modifiers.psc/_fwb_mcm.psc: added GLOB record trackers
+ FWB_SexLabDisparity.esp: added GLOB records
+ _fwb_modifiers.psc/_fwb_mcm.psc: added StorageUtil value trackers

Note: To use the GLOB trackers, set your buff/debuff values as desired for a given GLOB tracker. There are 5 and I am a programmer so they are titled 0-4:
  _fwb_GLOBTracker0
  _fwb_GLOBTracker1
  _fwb_GLOBTracker2
  _fwb_GLOBTracker3
  _fwb_GLOBTracker4
The buff/debuff scaling goes from 0.0-100.0 so bear that in mind when setting the GLOB values.
You can set a GLOB via the console:
  set _fwb_GLOBTracker0 to 33.3

Note: To use the StorageUtil trackers, set your buff/debuff values as desired for a given StorageUtil tracker. There are 5 and I am still a programmer so you have:
  _fwb_SUTracker0
  _fwb_SUTracker1
  _fwb_SUTracker2
  _fwb_SUTracker3
  _fwb_SUTracker4
The buff/debuff scaling goes from 0.0-100.0 and is clamped so bear that in mind when setting the StorageUtil values.
These are StorageUtil float value keys, so:
  StorageUtil.GetFloatValue(None, "_fwb_SUTracker0")
  StorageUtil.SetFloatValue(None, "_fwb_SUTracker0", 33.3)

 

 

Edited January 29 by hextun
Removed dead download link

[hextun]

Should I be doing this as a separate file/project/download? This is starting to feel a little intrusive.

 

Summary: Added FillHerUp support. Fixed update and configuration load logic, restoring support for updating and loading from save games using versions 14.5 or older.

 

Changelog:

v14.6
Save compatible
+ _fwb_fhu.psc/_fwb_modifiers.psc/_fwb_mcm.psc: added tracking for FillHerUp Baka Edition 2.0.3.9
+ _fwb_mcm.psc: fixed update logic; you can once again update an existing save
+ _fwb_mcm.psc: fixed load logic; you can once again load old JSON configurations (i.e. those saved in v14.5 and older)

 

Explanation:

FillHerUp Baka Edition 2.0.3.9 (not sure about other versions) support added.

- Vaginal, Anal, Oral, and Inflation (Vaginal+Anal) Amounts

- Days Since Last Vaginal, Anal, or Oral Inflation

- looks for "sr_FillHerUp.esp"

 

Bugfix: Update logic was not correctly implemented in my 14.5 release; additional update logic has been added to better support updates from pre-14.6 (including 14.5) versions.

 

Bugfix: Load logic was not correctly implemented; the new features (GLOB, StorageUtil, and now FillHerUp) were being treated as required. This has been altered to not require but to report their absence per normal _fw_util calls. This means that your previous JSON that you painstakingly set up before GLOB, StorageUtil, or FHU were added can once again be safely loaded in 14.6 and will have all of the desired values properly reconstituted. Subsequent saved configuration JSON files will, of course, have the new features included.

 

SLD SSE 14.6.zip

[Anunya]

Disparity is one of my favourite mods, it's great for changing the flavour of any given game.

 

I'm interested to see what you're doing with this @hextun 

 

If you're open to suggestions or requests, one of the features I've long wished to have in Disparity is more visibility for the player for what triggers a given buff or debuff, and when it changes (during gameplay I mean).

 

IIRC, right now it just has a very generic "Stamine Regen Debuff" type phrasing in the Magic Effects menu, and that's it. It means as a gameplay experience, you basically have to remember all your MCM settings to understand what's happening.

 

I don't know if this is practical or reasonable, but one way to do it could be something like this:

• Each combination has it's own Magic Effect name - so you might see "Collar Worn Buff" or "High Heels Withdrawal Debuff" in the Magic Menu
• This could also show up as a text message when it turns on or off. So when the PC puts on a collar they get a "Collar Worn Buff Activated" message, and when they put the High Heels on again (or they overcome the Withdrawal) they get a "High Heels Withdrawal Debuff Inactive" message.
• If I remember my OAR correctly, naming the Magic Effects differently then allow players to key different animations off SLD buffs and debuffs - say if they wanted to use different idles or a different walk cycle when the High Heels Withdrawal Debuff was active.

Like I said, I don't know if it's practical or interesting for you to do - but personally I think something like that would be really cool.

Edited January 28 by Anunya

[crajjjj]

2 hours ago, Anunya said:

Disparity is one of my favourite mods, it's great for changing the flavour of any given game.

 

I'm interested to see what you're doing with this @hextun 

 

If you're open to suggestions or requests, one of the features I've long wished to have in Disparity is more visibility for the player for what triggers a given buff or debuff, and when it changes (during gameplay I mean).

 

IIRC, right now it just has a very generic "Stamine Regen Debuff" type phrasing in the Magic Effects menu, and that's it. It means as a gameplay experience, you basically have to remember all your MCM settings to understand what's happening.

 

I don't know if this is practical or reasonable, but one way to do it could be something like this:

• Each combination has it's own Magic Effect name - so you might see "Collar Worn Buff" or "High Heels Withdrawal Debuff" in the Magic Menu
• This could also show up as a text message when it turns on or off. So when the PC puts on a collar they get a "Collar Worn Buff Activated" message, and when they put the High Heels on again (or they overcome the Withdrawal) they get a "High Heels Withdrawal Debuff Inactive" message.
• If I remember my OAR correctly, naming the Magic Effects differently then allow players to key different animations off SLD buffs and debuffs - say if they wanted to use different idles or a different walk cycle when the High Heels Withdrawal Debuff was active.

Like I said, I don't know if it's practical or interesting for you to do - but personally I think something like that would be really cool.

To add to that I have a feeling that those affects somehow break the STB Active effects widget. But that is just a suspicion. (I have a permanent white cross widget)

[hextun]

@crajjjj About the effects impacting STB Active Effects

The MGEF records that are applied to the player are driven by SPEL records with 'Constant Effect' cast type, meaning they don't have timers and would appear to be a more or less untimed permanent buff/debuff. When one of these MGEF records needs to be updated (e.g. you already have a Movement Speed debuff applied due to MME Milk-Weight, but now the player is barefoot, and you wish to further reduce Movement Speed), it is removed and reapplied. By default, SLD polls each 11 seconds.

 

I'm not aware of how STB Active Effects works, but assuming the displayed icons are supposed to appear when a MGEF is added and then fade away after a short while or unless a hotkey is pressed, then if the SLD effect is being driven by something that is causing the value to be adjusted more frequently than the timeout of STB Active Effects, that would mean the MGEF is being removed and reapplied frequently enough that STB isn't showing you the same icon, it's showing you the new icon each time the MGEF is removed/reapplied. For example, any "worn time" effect would be updated literally every poll until a cap is reached, necessitating frequent removal/reapplication of the MGEF.

 

I'll be honest; I'm not familiar enough with how the Skyrim Papyrus engine works, but given the original author's desire to optimize performance, to the point of creating a SKSE plugin to handle the floating point array calculations, I would imagine that the remove/reapply method is the only option that worked and that attempting to e.g. simply adjust the magnitude of an existing MGEF would not work as intended.

 

The upshot is that I'm not sure there's a good solution here; SLD is removing and reapplying MGEF records, and if that happens frequently enough, and STB has some sort of cooldown before fading icons, that might explain it. But again, only if that icon is tied to an SLD effect.

 

@Anunya About separating the MGEF records for more visible granularity

This would be problematic primarily due to the "combine and cap" approach that SLD takes to buffs/debuffs. Since SLD offers the feature allowing you to set an overall cap on how high or low you can adjust a given value, it requires that all existing buffs/debuffs be first tallied and then capped to prevent overrun. By separating the MGEF out, it would prevent, or at least greatly complicate, "combine and cap".

 

Example 1) You have multiple "Movement Speed" debuffs configured, each at -20, for each possible worn devious device, so that wearing any devious device slows you down by -20 per device. But really, you just want it set up so that if you are wearing *any* such device, you get the -20 debuff, even if you are wearing multiple. So you set the cap at -20 (i.e. you can't reduce it more). Now if you wear multiple devices, you'll still only get a total -20 debuff. If you split your MGEF you cannot accomplish this.

 

Example 2) You want to mimic the "turned on->more Stamina for sex" dynamic and apply a similar +10 Stamina buff for each device, and now want this capped at a total of +50 (you can only get so much more energized after all). If you split these out, and are wearing more than 5 devices, you would end up exceeding your +50 cap.

 

A possible solution might be to provide weighted averages; say you have the "Milk-Weight > -20 speed" and "Barefoot > -20 speed" effects configured. During recalculation, assuming you had multiple MGEF instead of just one per stat, when you determined that you needed both debuffs, you could note that there are two, note that their caps are equal, and therefore note that each would contribute -10, and then apply that adjustment to each. You still get capped but get your split MGEF. This is the "greatly complicate" part; these calcs happen pretty frequently typically and you want them to be as fast and simple as possible. There are currently 90 values being calculated and checked for MGEF application/update, for each of the tracked stats. In addition to the current work in the polling loop, now each value that is going to be updated needs to have additional calcs done to tally any applicable caps, do the weighting, and then update the effects.

 

Moreover, during your update loop, you would not only be doing the polling, you would be manipulating far more records (because now you need to keep track of the final "weighted and capped" values for each buff/debuff, in addition to the already currently calculated raw values) and far more MGEF records (during effect application, you would be removing/reapplying more than 1 MGEF instead of just the singleton, when more than one factor is affecting a given stat), further slowing down the calculation loop. Not to mention the number of buffs/debuffs appearing in the list is already crazy high; splitting out the MGEF would potentially explode the number of results, making it difficult in some cases to find anything *but* SLD effects.

[hextun]

@Anunya I forgot to add some other ideas for the issues you mentioned.

 

SLD effects altering animations

I believe OAR can also examine Keywords; perhaps keyword application/removal would be of use? So if "MME-Milk-Weight" and "Barefoot-Worn" are both applying a -10 Movement speed penalty, for a total of -20, what if keywords were added: "_fwb_kw_mme_milk_weight_debuff" (vs "..._buff" for a positive effect) and "_fwb_kw_worn_barefoot_debuff". Then in OAR, you can apply the HasKeyword() condition. You wouldn't get the magnitude for the specific effect, so differentiating between "barefoot_worn_debuff" of -10 vs -20 wouldn't be possible unless you were willing to just use the overall value.

 

Player feedback to know currently applied SLD effects

There are a few options:

- You mentioned a notification alert when you gain or lose a buff/debuff. This would be pretty straightforward to implement. When you first gain a movement penalty, you get an alert; when it changes, you get another; when it is removed, you get another. The problem would be that quite a few values might be adjusted every 11 seconds (I'm looking at you "worn time" effects), and that would get quite spammy, unless the notifications were kept solely to "when applied" and "when removed". Even then it might be iffy. Could be a toggleable feature.

- Another option would be a hotkey that would effectively dump the factors currently affecting the effects (heh) to the console. So you map "ctrl-alt-shift-F42" to "SLD Dump Effect Factors" and then press it with your noodly appendages, and the output gets dumped to console. Annoyingly non-immersive, but practical, out of the way, and not requiring anything fancy.

- As an adjunct to that, if I am able to use something to pop up a UI, perhaps the same "hotkey to dump" feature but instead it pops up some simple list of the effects/factors currently running. Still not immersive like STBAE and would require some sort of UI functionality (which I'm uncertain about obtaining currently as I don't know if I would need to create my own .swf files or can use an API) but would be at least a little less unimmersive due to avoiding looking at the console.

- An MCM tab (or expansion of the 'Developer' tab) that would give you the info; still unimmersive, but would not require a new UI function.

[Anunya]

That all sounds great @hextun

 

Personally I don't think the magnitude matters so much - you can typically see it in your movement speed or skill rating or stamina bar or where ever. From my POV as long as you know it's turned on or off that would do the trick. I don't think you'd need an update at every 11 second tick (or whatever you set it to), or know when it switches. Just knowing it's active or inactive is enough.

 

To me that's the most important function - everything else is gravy. So if that's simple to do and everything else is more complex to fix, I'd say it's not really necessary.

 

Thinking of a button to press to get information, I think something that's easily accessible and just dumps the current active buffs and debuffs with sources is enough; with current values being a bonus but not essential. I think the typical top left screen debug text is sufficient - no need for complex UI or anything. Same place you get your current arousal, state of dirtiness, etc from other mods.

 

IMO of course  

Edited January 29 by Anunya

[hextun]

14.7: MCM bugfix for the FHU slider Buff From: value range, and a typo (there is no such thing as "orvaginal", sorry).

 

Save safe, should auto-update.

 

SLD SSE 14.7.zip

[gghhjj666]

On 2/1/2026 at 8:04 PM, hextun said:

14.7: MCM bugfix for the FHU slider Buff From: value range, and a typo (there is no such thing as "orvaginal", sorry).

 

Save safe, should auto-update.

 

SLD SSE 14.7.zip 610.45 kB · 7 downloads

Quite excited to see someone continue updating the mod. Not save safe for when going from the old original version on the mod page to this one right? Also before going through making a new save and such, does the update fix the breast morph being wrongly inverted like it is on the mod page?

[hextun]

4 hours ago, gghhjj666 said:

Quite excited to see someone continue updating the mod. Not save safe for when going from the old original version on the mod page to this one right? Also before going through making a new save and such, does the update fix the breast morph being wrongly inverted like it is on the mod page?

 

- Save safety - I... *think* it is? Or should be? The update feature appears fairly robust. Worst case, if you're using a mod organizer like MO2, install latest SLD just after your current SLD install, with a new name, letting it override all of the files, then launch and see if it updates correctly. If it does, save, quit, remove old SLD and rename your new copy to the old name and you're golden. If it doesn't, you can either start a new save or just remove the new install and delete the recent save.

 

- Breast morph bug - I will need to go back and look into that... I recall seeing a post about that upthread, was that you? If I can't get enough details to fix it, I'd need to... um... ask for them I guess.

 

- Ongoing updates - I don't mind doing updates, and as you can see with the 14.7 post I even added a feature (go me!), but I don't have a *vision* or *plan* per se. As a result, I feel like it's a little awkward at the moment; should I continue to make these updates and post them in this thread (which makes them far less likely to be seen and also would presumably be, I guess, a little uncool to Lupine00 since this is their support thread) or if I should fork (which would be a questionable move on my part given Lupine00 hasn't been on for going on 4 years or so now but there is no license for any of the SLD code). Given their stance on dead mods (see their blog post: 

), it's likely they would be fine with the takeover at this point, but I have nothing firm to go on. At this point, advice would be appreciated.

 

[gghhjj666]

11 hours ago, hextun said:

 

- Save safety - I... *think* it is? Or should be? The update feature appears fairly robust. Worst case, if you're using a mod organizer like MO2, install latest SLD just after your current SLD install, with a new name, letting it override all of the files, then launch and see if it updates correctly. If it does, save, quit, remove old SLD and rename your new copy to the old name and you're golden. If it doesn't, you can either start a new save or just remove the new install and delete the recent save.

 

- Breast morph bug - I will need to go back and look into that... I recall seeing a post about that upthread, was that you? If I can't get enough details to fix it, I'd need to... um... ask for them I guess.

 

- Ongoing updates - I don't mind doing updates, and as you can see with the 14.7 post I even added a feature (go me!), but I don't have a *vision* or *plan* per se. As a result, I feel like it's a little awkward at the moment; should I continue to make these updates and post them in this thread (which makes them far less likely to be seen and also would presumably be, I guess, a little uncool to Lupine00 since this is their support thread) or if I should fork (which would be a questionable move on my part given Lupine00 hasn't been on for going on 4 years or so now but there is no license for any of the SLD code). Given their stance on dead mods (see their blog post: 

), it's likely they would be fine with the takeover at this point, but I have nothing firm to go on. At this point, advice would be appreciated.

 

Yeah that message about breast and also butt morph I believe was me. The main issue I noticed is that they are considered "inverted" morphs, like breastsmall for example where a negative morph means larger breasts and a positive smaller. Older versions would have the breast morph be like this but atleast cbbe 3ba and I'm pretty sure all other SE versions of cbbe changed it to be positive morph meaning larger. I did have a look at the source code as I'd say I'm a pretty experienced programmer but haven't dipped my toes into papyrus yet and think I managed to find where breast(and some other morphs) are tagged as inverted. I should have mentioned the line I found it on in my original message but keep in mind I might not have found everything needed to make the change. 

 

As for the update thing. I read the blog post and it sounds like he'd be fine with someone else continuing the mod. Specificly bthe part in a reply where he mentions that if someone disappears and is unable to reinforce their own policies that it should be kinda "open". I haven't posted any mods and such so might wanna find people more experienced and who knows the sites policies on that kind of stuff. For the moment being I'd say posting it here in the support thread foe the mod seems like a good alternative as it's very clear whos the original creator.

[hextun]

Okay, here is a 14.8 version that re-inverts the morph scaling for "Breasts" and "Butt".

 

I did hook up the update logic so it will modify the scaling from negative back to positive for those two morphs, but it means if you have existing rules for these morphs they will not work opposite to how they were previously, so you'll have to go in and modify them (change the sign basically).

 

 

SLD SSE 14.8.zip

Edited February 11 by hextun

[Anunya]

IMO after a few years I think it's fair to do a fork on LL and post a link to the original thread, giving credit to Lupine00. If you're feeling extra cautious, you could put in a statement that you're happy to respect Lupine00's wishes if he comes back and expresses any - I feel like I've seen a number of mods like that in my time on LL (and Nexus for that matter).

 

That's just one person's opinion though.

[gghhjj666]

15 hours ago, hextun said:

** TEST RELEASE 14.8 **

 

Okay, here is a 14.8 version that re-inverts the morph scaling for "Breasts" and "Butt". I did hook up the update logic so it will modify the scaling from negative back to positive for those two morphs, but it means if you have existing rules for these morphs they will not work opposite to how they were previously, so you'll have to go in and modify them (change the sign basically).

 

I have not used the morph values, I don't even really know how to. This is entirely untested (though the change itself did appear to be super simple), so until someone (locks eyes with @gghhjj666 hopefully) tests and reports back success I do not recommend downloading it. Once it has been proven, I'll edit this post and leave the link in place. (I haven't even committed the changes locally!)

 

I don't have an out of band method to offer the .zip for someone to test, so am going this route.  Please, no torches or pitchforks. (And why can't we attach files to DMs here?  )

 

SLD SSE 14.8.zip 610.77 kB · 1 download

Happy to say that the "Breasts" and "Butt" morph seems to work correctly now. I've only tested to see if the calculated morphs increase isntead of decreases so haven't seen if anything else stopped working because of it though. I'm using SLIF aswell so that also works. 

[hextun]

31 minutes ago, gghhjj666 said:

Happy to say that the "Breasts" and "Butt" morph seems to work correctly now. I've only tested to see if the calculated morphs increase isntead of decreases so haven't seen if anything else stopped working because of it though. I'm using SLIF aswell so that also works. 

 

Thank you! I'd be wildly surprised if anything else was affected, so I'm going to go ahead and update the original post. I've updated as well, though without the morph use. If anything comes up, lmk.

 

[crajjjj]

1 hour ago, hextun said:

 

Thank you! I'd be wildly surprised if anything else was affected, so I'm going to go ahead and update the original post. I've updated as well, though without the morph use. If anything comes up, lmk.

 

Can we have amount of orgasms before sleep trigger pls? Thx

[hextun]

2 hours ago, crajjjj said:

Can we have amount of orgasms before sleep trigger pls? Thx

so like a counter with a reset?

 

honestly I had been wondering about something like that myself. 
 

Will mull it over.

[hextun]

I have a hypothetical use case and would like others input as SLD users.

 

Suppose you are playing a relatively tough modlist, where leveling is slow, fights are dangerous, and failure is punished pretty hard. Ordinarily you would gear up and go forth, but suppose you also *want* to have your dragonborn dressed up in your favorite bondage gear while adventuring because you like the fashion show, but you *also* don't want to be more vulnerable as a result.

 

So you install SLD and decide you will apply buffs instead of debuffs for worn items. Disregard concerns about in-game justification (pretend you are making a mod called Sanguine's Perverted Delights where he wants to see the DB in bondage gear and decides to use more carrot and less stick). Your aim would be to, at minimum, provide buffs that would work to counteract the loss of armor slots (which would provide both armor and possibly enchants).

 

Assume you are using something like TAWOBA, so you have a lot of slots to fill with little pieces of possibly enchantable armor.

 

How might you go about setting it up? Would you apply identical buffs to every worn type? Would you customize it, making, say, leg cuffs give one type of buff while arm cuffs give another? Would you just focus on one type of buff (i.e. health/stam/magic vs skills vs movement/carryweight) or would you spread it around? Would you create different options for if you wanted to go as a caster, a stealth, or a fighter or would you try to make the buffs work for everyone (i.e. not just giving out stam but also magicka because you might use one or the other)?

 

Bonus points if you throw in how you would work with other settings like MME, Apropos2, morph values, or even the new StorageUtil and GLOB values (assume they would be manipulated via something like SLTriggers Redux or some other external source).

 

FWIW, I've been playing with options in this vein and have been going the route of "give each worn item a smattering of buffs across everything, to let you flex out to what you want to do", but I don't feel it's quite right. I use "Worn total time" scaled out to 30 days. I actually *do* apply some debuffs in there (slowing effects that you train back out of when barefoot or in bondage shoes, regen debuffs when MME fullness percentage is too high, etc.), but for now I'm more trying to focus on how to handle and balance the buffs.

 

 

[Anunya]

13 hours ago, hextun said:

I have a hypothetical use case and would like others input as SLD users...

 

I have a somewhat related use case (which I'll then extrapolate from). I want DD to be tempting and initially empowering for my PC, and then slowly become more of an addiction trapping her in them by means of game-play effects. There are a lot of different ways it could be set up, but what I do is generally this:

• Time Worn 0 = Big buff to Mana, Magic Skills, and Mana Rate (yeay, how awesome it is to wear this! That's amazing!), also a slight increase in screen colour saturation (it feels good!)
• Addiction (Worn) starting at 50 maxing at 100 = Equivalent Debuff. So once addiction reaches 100 there's no longer a benefit to wearing those items; but...
• Withdrawal (Unworn) starting at 20 and maxing out at 70 = Equivalent (or slightly larger). That means, once my PC has worn the items for a while, she'll not want to take them off due to negative effects.

In aggregate the effect I'm after is that when the item is first put on, it gives a big boost. After a bit, it still gives a big boost and a debuff when removed... so definitely keep it on now. Over more time (addiction really) it flips and the benefit from wearing the items fade to nothing, but the malus from taking them off gets worse so in the end she's mostly stuck with them - unless she's willing to take a period time of being weakened to get over the addiction.

 

I wouldn't have minded having that effect across all the possible DD types even clothing types (and I've experimented with some of them), and I wouldn't mind for them to have different nuances between different item types; but I found that in practice it became muddled for me what was happening at any given moment. Which item was causing what effect? Which one is at what stage of addiction? What did I even set them at?

 

Since a key part for me is to have a clear effect in-game that guides my game-play (even if I forget my explicit settings, which I usually do), I've chosen to limit the effect to a few items and stronger effects because otherwise I don't really know what's happening when I'm actually playing the game (and this goes back to the point/ request I made earlier about a more descriptive text in the Magic Effects UI and notifications when an effect is turned on or off ). I also don't really find "many DD" that much more interesting than "a few DD"; in this case for me "less is more". Therefore:

• The key item is the collar, because a lot of other LL DD type mods keys off of it - SubLola and Pet Collar for example. I'll also weigh the collar heavily as a thing in Sexy Adventures, and I've set up some specific idles in OAR for when the PC wears a collar. If YPS Thoughts had some comments on wearing a collar or not, I'd absolutely write a bunch also (even better if it keyed off the addiction/ withdrawal part). The scale of the buff is pretty significant and will totally impact game play at the max and min settings (something like +200 Mana when first put on, and -300 Mana when fully addicted and in withdrawal).
• I also have piercings as secondary with the same setup.

In terms of other mods touching the same things I have Sensual Needs (mostly buffing), Apropos2 (wear and tear), Magicka or Armor, Lovesick, Sexy Adventures (Vow of Nudity), Gender Matters, as well as a bit of a debuff from very high arousal using SL Disparity. I also used have Let Your Hair Down, but recently switched back to YPS for hair management. I have a spreadsheet with the source and magnitude of each modifier, so I can remind myself what the settings are without having to go into the MCMs, as well as play around with them in theory before changing things.

 

To support that I have OAR set up with (a modified version of) Brastia knocked out idles for low Stamina and Magicka (so removing the collar when addicted or at low Magicka can literally knock my PC to the ground), as well as crawling for locomotion. This is particularly impactful because the regen rate can also get down to zero in some instances. If there was a YPS Thoughts type implementation somewhere for low Magicka/ Stamina/ Health I'd also write a bunch of lines to mention that.

 

I don't use the StorageUtil or GLOB values because I don't understand how they work

 

So that's what I do in my current setup re: Magicka and DD, but...

 

... how would I do it if I wanted to do an "encourage the PC to wear TAWOBA stuff"? (and this is something I'd probably turn on in my own game as the path for melee focused characters)

• I'd identify the key stats to affect: I think Stamina, Stamina rate, Health, Health Rate, Weapon skills, and Weapon attack rates would be candidates. If there's a weapon damage multiplier, I'd look at that too. Since Stamina is a resource in my combat setup, supporting it is definitely useful (I also use Cardio).
• TAWOBA is all about assembling outfits from many pieces, so I wouldn't do the "key pieces only" thing that I do for my Magicka and DD setup. However, unless there's a very clear communication about the effect, I'd go with all of them affecting the same stats in the same proportion. That way it'd be simple to understand in-game without remembering the specific settings, it's just "more TAWOBA stuff = more Stamina and Stamina Rate" (for example).
• Personally I'd like to have the same kind of "getting hooked" addiction set-up I have in my Magicka set-up. Ideally Ideally, I think, the addiction would be tracked for "TAWOBA pieces" altogether rather than on a per slot basis, but it's not the biggest deal I think. In actual game-play, I think it'd be "wear as many TAWOBA pieces as possible for buffs" or "get rid of all of them to get clean" without regard for which specific item has the biggest impact, so maybe it's not that big a deal.
  • That said, since you're looking at more carrot than stick I'd probably never cancel the worn buff out completely (though I'd probably still reduce it over time).
  • This is is not an out of the box feature, but if I could I'd like for having nothing equipped not triggering the debuff, because being naked is also acceptable 
  • ... so going from that, if possible, I'd also want a way to tag non-TAWOBA stuff being acceptable one way or the other. That is, clothes tagged as slutty (for example) would either not trigger the debuff or even count as TAWOBA stuff - this would also facilitate adding other armour sets as being used if the user deemed it appropriate.
• I'd probably set up some OAR things if I could find appropriate idles/ locomotion/ attack animations.
• I'd track the values of the buff/debuffs in a spreadhseet. I don't really use morphs that much (except a bit of ABBA and for pregnancy), but if I did I'd probably track them same way.

 

[emaki5]

Possibly interesting ideas to consider adding on...
I've been fan of your work for years now @hextun and I spent countless hours writing functions for old triggers and now new ones.

 

Here are some concepts that might be interesting to add as options here:
1. Repeatable damage during noncon SexLab scene (possibly depending on partner's level, stamina and health)

2. Repeatable damage during SexLab scene with larger creatures (like stretch damage; possibly that will make some creatures unavailable for player at lower levels)

3. Buffs and debuffs that track SexLab basic diary stat (like oral, creature number...)

 

Have few more but I do not want to spam.

Thanks again for all the work so far!