SL Triggers Redux

[hextun]

17 hours ago, Dakhma said:

I wanted to ask, how can I make this mod: 

 

Work with triggers, so that there is a drinking trigger from an oral event, I don't want to receive an item, I want it to be consumed on trigger.

 

If I'm understanding your request correctly, you would want the trigger to happen:
- On SexLab Start (I guess? or perhaps On Orgasm?)

- Once per scene, 100% chance

- Tag - Oral

- I'm not sure who you want to have consume this. If it's Player only:

- Player: Is Player

 

You would then create a script, say... "Data/SKSE/Plugins/sl_triggers/commands/DrinkBeastUrine.ini" to attach to the trigger.

 

The contents would be something like:

 

; Inspiration taken from Alcohol.ini

; This is to store the formid for the item to drink
; The format is "mod file name with spaces.esp(or .esm or .esl):123123123" where 12312123 is the base 10 (not base 16 hex) value of the formid in the mod without the mod's prefix
; 
; I think I've added support for more variations as well including editor ID though I think that's dependent on PO's tweaks.
set $1 "Enchanted Bestial Urination.esp:123123123"

; item_adduse adds the specified item to the specified actor, in this case in a quantity of 1, and also "uses" it, which in the case of a drink, imbibes it
; the final 0 is to mask or not the notification

; this acts on the player, regardless of who the script is running on
; so, for example, if your script was set to trigger on orgasm in a scene, then each time anyone at all in the scene orgasms, the player takes a drink
item_adduse $player $1 1 0

; or

; here, only the actor on whom the script "lands" takes a drink.
; so assume you set the trigger for only undead actors and you are in a scene with you, your mate, and two draugr
; I'm assuming your mate is not undead
; if the trigger was restricted to only undead, then only the draugr in question would drink
item_adduse $self $1 1 0


; but... if you used this one again, but now with the trigger set to only target undead, and you are in your 4 way with 2 draugr, then any time a draugr orgasms, the player takes a drink
item_adduse $player $1 1 0

 

I don't know the mod. Do you have any specific formIDs? I can help transform them if you need.

[hextun]

20 hours ago, Dakhma said:

I think I called victory too fast, the file was the settings.json file in the overwrite folder from the old triggers. I deleted it and started a new save and the menu was working properly. I decided to leave the game to, to finish setting up the load order and all that. Then started a new save again, but this time the menu didn't show up complete again. 

I am testing right now if its a plugin order issue or something else. Should the MCM display everything right away on a new save? or does it take a minute to kick off?

 

EDIT:

okay, it seems like putting the .esp lower in the load order fixed the issue. At least I hope that it works flawlessly for now!

 Ooo this is interesting info. I know it's working now, but if you happen to recall which mods it got moved below that would be good info to have.

[Dakhma]

1 hour ago, hextun said:

 

If I'm understanding your request correctly, you would want the trigger to happen:
- On SexLab Start (I guess? or perhaps On Orgasm?)

- Once per scene, 100% chance

- Tag - Oral

- I'm not sure who you want to have consume this. If it's Player only:

- Player: Is Player

 

You would then create a script, say... "Data/SKSE/Plugins/sl_triggers/commands/DrinkBeastUrine.ini" to attach to the trigger.

 

The contents would be something like:

 

; Inspiration taken from Alcohol.ini

; This is to store the formid for the item to drink
; The format is "mod file name with spaces.esp(or .esm or .esl):123123123" where 12312123 is the base 10 (not base 16 hex) value of the formid in the mod without the mod's prefix
; 
; I think I've added support for more variations as well including editor ID though I think that's dependent on PO's tweaks.
set $1 "Enchanted Bestial Urination.esp:123123123"

; item_adduse adds the specified item to the specified actor, in this case in a quantity of 1, and also "uses" it, which in the case of a drink, imbibes it
; the final 0 is to mask or not the notification

; this acts on the player, regardless of who the script is running on
; so, for example, if your script was set to trigger on orgasm in a scene, then each time anyone at all in the scene orgasms, the player takes a drink
item_adduse $player $1 1 0

; or

; here, only the actor on whom the script "lands" takes a drink.
; so assume you set the trigger for only undead actors and you are in a scene with you, your mate, and two draugr
; I'm assuming your mate is not undead
; if the trigger was restricted to only undead, then only the draugr in question would drink
item_adduse $self $1 1 0


; but... if you used this one again, but now with the trigger set to only target undead, and you are in your 4 way with 2 draugr, then any time a draugr orgasms, the player takes a drink
item_adduse $player $1 1 0

 

I don't know the mod. Do you have any specific formIDs? I can help transform them if you need.

You mean these:

 

Also in regards to your other question, I have to many mods to figure out which one was the culprit, but I guess if someone has the issue in the future, just follow the golden rule of lowering the plugin in load order.

[hextun]

3 hours ago, Dakhma said:

You mean these:

 

Also in regards to your other question, I have to many mods to figure out which one was the culprit, but I guess if someone has the issue in the future, just follow the golden rule of lowering the plugin in load order.

 

Yep, so, I believe you'd want (I'm guessing ESL, so if this doesn't work let me know):

"Enchanted Bestial Urination.esp:123123123"

Watery Bear Urine
80F base 16
2063 base 10
"Enchanted Bestial Urination.esp:2063"

Fresh Goopy Boar Urine
810
2064
"Enchanted Bestial Urination.esp:2064"

etc. so

Fresh and Hot Horse Urine
"Enchanted Bestial Urination.esp:2065"

Sticky Riekling Urine
"Enchanted Bestial Urination.esp:2066"

Infected Skeever Urine
"Enchanted Bestial Urination.esp:2067"

Fresh Seasoned Canine Urine
"Enchanted Bestial Urination.esp:3436"

Mage's Bestial Urine
"Enchanted Bestial Urination.esp:3438"

Fatty and Thick Troll Urine
"Enchanted Bestial Urination.esp:3440"

 

[Dakhma]

23 minutes ago, hextun said:

 

Yep, so, I believe you'd want (I'm guessing ESL, so if this doesn't work let me know):

"Enchanted Bestial Urination.esp:123123123"

Watery Bear Urine
80F base 16
2063 base 10
"Enchanted Bestial Urination.esp:2063"

Fresh Goopy Boar Urine
810
2064
"Enchanted Bestial Urination.esp:2064"

etc. so

Fresh and Hot Horse Urine
"Enchanted Bestial Urination.esp:2065"

Sticky Riekling Urine
"Enchanted Bestial Urination.esp:2066"

Infected Skeever Urine
"Enchanted Bestial Urination.esp:2067"

Fresh Seasoned Canine Urine
"Enchanted Bestial Urination.esp:3436"

Mage's Bestial Urine
"Enchanted Bestial Urination.esp:3438"

Fatty and Thick Troll Urine
"Enchanted Bestial Urination.esp:3440"

 

mm ok thank you, I will look carefully into it later and see if I can do it!

[Dakhma]

5 hours ago, Dakhma said:

mm ok thank you, I will look carefully into it later and see if I can do it!

Sorry I am new to all this, is this correct?

 

 

set $1 "Enchanted Bestial Urination.esp:123123123"

Watery Bear Urine
"Enchanted Bestial Urination.esp:2063"

Fresh Goopy Boar Urine
"Enchanted Bestial Urination.esp:2064"

Fresh and Hot Horse Urine
"Enchanted Bestial Urination.esp:2065"

Sticky Riekling Urine
"Enchanted Bestial Urination.esp:2066"

Infected Skeever Urine
"Enchanted Bestial Urination.esp:2067"

Fresh Seasoned Canine Urine
"Enchanted Bestial Urination.esp:3436"

Mage's Bestial Urine
"Enchanted Bestial Urination.esp:3438"

Fatty and Thick Troll Urine
"Enchanted Bestial Urination.esp:3440"

item_adduse $player $1 1 0

 

[jiudg]

On 5/21/2025 at 9:36 PM, hextun said:

 

Can you be a little more specific? Some of the functions intentionally just add an item and others actually equip it. Is there a case where you are expecting something to be equipped or used but it is not?

Yes, there is a case where an item that should be equipped is only added to the backpack but not actually equipped.

[hextun]

On 5/31/2025 at 9:58 AM, jiudg said:

Yes, there is a case where an item that should be equipped is only added to the backpack but not actually equipped.

 

Aw.. bummer... well, okay. Can you paste the .ini script to reproduce the issue?

[hextun]

By way of an update, things are progressing.  More details you say? Probably not since I'm a bit of a motor-mouth but here we go.

 

I've been playing with the SKSE side, working on making the context tracking nicer and more resilient. After going back and forth a number of times on how to approach it, and finding out a LOT about the SKSE/CommonLib environment in the process, not to mention blowing off a ton of rust on the ol' C++ skills, I think I've settled on where the tech split will reside on the next iteration. Meaning how much is done in Papyrus vs. SKSE.

 

Architecturally, here is how things have evolved:

 

- Initial version: Fotogen's original: fully Papyrus script driven

- Early Redux: Added SKSE plugin, enabling extensibility; RunOperationOnActor() - key function, allowing the function libraries to work as they do

- v120: most core functionality of the engine still driven by Papyrus script; skse continuing to take over more work; all context info stored via PapyrusUtil/StorageUtil

 

Where I have traveled:

- One call does it all: I had turned the entire SLTScript process into a latent function call to run on a worker thread in skse, and then ignoring the papyrus vm threads until I needed to call a papyrus function again, when I would dispatch a call, which would now go to the main thread (not my worker thread), and I would set up a promise and wait; this wouldn't block because, again, different threads; then I could get the result asap and proceed

-- fast

-- but pushes the limits of my not-nearly-up-to-date-enough c++ (managing a multi-threading scripting engine and keeping it in sync with... another multi-threaded scripting engine... not impossible, just not what I wanted to inflict on my users just yet)

-- I wanted this but that was more for me to say I did it than a need

-- I got 90% regression test pass before realizing I should probably back away and resimplify

- multiple separate mods, separation of concerns, suite of dev focused custom papyrus objects

-- since I originally set out to get better access to data structures in papyrus for context tracking, this was also an option I looked into

-- but I have a specialized need

-- custom papyrus objects, true first class ones, are not.. casual

-- I would end up supporting two mods; two cool mods, to be sure, but still

-- overkill

 

Where I am:

- using some simple handle based custom objects for the complex data type tracking

- adding some skse serialization for them

- currently in the process of converting the sl_triggersCmd.psc script to make use of the new data types

 

Once I've done that and testing completes, I'll test some more. And a little more. Then release.

 

Also, at present, variable names might look like this going forward:

 

$varname         ; local scope (only within this script during this specific instance)
                 ; so if scriptA calls scriptB calls scriptA, the two instances of scriptA will have different copies of the same variables)
$actor#varname   ; actor scope (across all scripts while targeting this actor)
$session#varname ; session scope (across all scripts during this specific execution run
                 ; e.g. scriptA calls scriptB calls scriptC, a session scoped variable would exist throughout all of them
                 ; but if another scriptA starts a similar call chain, it's session scoped variables would be separated
$global#varname  ; global scope (across all scripts)

 

Still not sold on it. More to come.

[LinksSword]

how would you make a script where a item is forced onto the player when they try to loot a dungeon chest for example? 

[hextun]

On 6/18/2025 at 8:18 PM, LinksSword said:

how would you make a script where a item is forced onto the player when they try to loot a dungeon chest for example? 

 

Out of the box, SLTR can't do that because it only knows the following triggers by default:

- Core: keymapping (so you would have to have mapped a key binding to the desired script in advance; i.e. press NP4)

- Core: top of the hour (i.e. at each in game o'clock: 1am, 2am, 3am... 5pm, 6pm... 11pm..

- Core: on new session (each time you load a save)

- SexLab: on start scene/on end scene/on orgasm

 

"Core" and "SexLab" are just built-in extensions using the same framework that I describe on the SLTR extensions link on the wiki. For situations where you aren't adding new functions, just wishing to request the script be run based on an event, currently you wouldn't even need to create an "extension"; just a regular mod that listens for the event and uses the integration to request the script would be sufficient. If you want such triggers managed by the SLTR MCM, you would need to set up an extension.

 

Of course, I'm also willing to expand the available trigger base, too, so "on container open" could be a good candidate to add to Core.

 

That said, SLTR, as a script executor, can be interacted with via mod events. So anything capable of sending a mod event can use the SLTR mod event integration:

 

ModEvent
    "sl_triggers_SLTRequestCommand"
usage:
    targetedActor.SendModEvent("sl_triggers_SLTRequestCommand", "scriptname")
if everything checks out (valid script, valid actor, etc.), the script will begin executing on the targetedActor


ModEvent
    "sl_triggers_SLTRequestList" (available v111)
usage:
If your list should be attached via StorageUtil to the Form that sends the mod event, either pass 0.0 as the float argument or let it default
    FormYouWantStorageUtilDataAnchoredTo.SendModEvent("sl_triggers_SLTRequestList", "yourStorageUtilStringListKey")
If your list should be attached via StorageUtil to the the global namespace, pass the value 1.7 (yes, specifically 1.7, I am weird that way)
    FormYouWantStorageUtilDataAnchoredTo.SendModEvent("sl_triggers_SLTRequestList", "yourStorageUtilStringListKey", 1.7)
Upon receiving the event, SLT will populate the indicated StorageUtil key with the list of commands.
If you put an event name in the first index of the list prior to calling, SLT will also fire that event back to you once the list is populated.

 

And as I'm sitting here thinking about it, I'm considering whether it would be useful to allow users to (as an additional means of triggering scripts above and beyond current methods) specify specific event names that SLTR would listen for and trigger scripts in response to. This would be perhaps a bit "generic" because it would be virtually impossible to try to determine dynamically what valid attributes to check for given nothing more than a "string" event name, so for example, if "On Open Container" were done this alternative way, it would just fire off the script each time the event comes in vs. with a proper extension setup where you might be able to specify e.g. type of container, in combat or not, time of day, invisible status, etc. For certain simplistic events that might be sufficient and enable folks to trigger scripts in more varying situations without requiring additional changes to the mod to incorporate.

[hextun]

I bring glad tidings! I have a stable (still beta, but not quite AS beta) release candidate!

 

What does this mean?

 

SLTR has been in beta since it was still "SL Triggers v16" or thereabouts. Originally because I was adding features/rearchitecting rapidly and I couldn't guarantee stability between releases, and lately because I have not been happy with the feature I added in v117, save/load resume. There has been instability surrounding that, having to do with both the actual resume functionality but also the impact adding that feature had on the call feature's callstack functionality. With the latest branch commits, I have an implementation that I'm much happier with in terms of stability and as a reasonable launch point for future tuning.

 

This sounds kinda boring. Did you give us any new toys?

 

Yes, I too like the shinies, and I did not come empty handed.

 

BEHOLD! MY STUFF!

 

New variable scopes (with new variable name syntax) / BREAKING: for global variable names

 

;;;;;;;;;;;;;;;;;;;;;
; In v120, your variables had two scopes, local:
set $mylocalvar "somevalue"

; and global:
set !myglobalvar "somevalue"

; As of v121 (and yes, for global variables in particular this is a breaking change), you
; now have this format as your variable naming syntax:

; $[<optional-built-in-scope>.]<varname>

; where <optional-built-in-scope> is any of "local", "thread", "target", "global", or "system" (case insensitive)
; "local" is the "default" case when no scope is specified.

; Thus, local:
set $myvar 42
set $local.myvar 42

; thread: (new, thread scoped variables are available in the initial script and any script that it "calls" or that is subsequently "called" in that sequence)
set $thread.myvar 42

; target: (new, target scoped variables are available to any script targeting that actor)
set $target.myvar 42

; global:
set $global.myvar 42

; other scopes are invalid and will result in the variable name being treated like a string literal
; so if you try this
set $custom.myvar 42
; that will just fail
set $othervar $custom.myvar
; and that will set $othervar to "$custom.myvar" because $custom.myvar is not a valid scoped variable name
;;;;;;;;;;;;;;;;;;;;;

 

Examples of the new `system` scope/special variable names change / BREAKING: for any use

 

;;;;;;;;;;;;;;;;;;;;;
; In v120, all 'special' variables were specified just like regular variables, i.e. prefixed with a $:
; $player
; $self
; $actor
; $partner2
; etc..

; As of v121 (and yes this is a breaking change for any previous usages) system variables will now be in the new "system" scope, ergo:
; $system.player
; $system.self
; $system.actor
; $system.partner2

; All scripts that are shipped with SLTR have been modified to use the new syntax. You will need to update any custom scripts accordingly.
;;;;;;;;;;;;;;;;;;;;;

 

I know, lots of "breaks muh scripts" happening, but it should definitely make for cleaner code and opens up possibilities for future scopes. But in case you were wondering if there were any new features with no downsides, here is a little something new:

 

String interpolation, C# style:

 

;;;;;;;;;;;;;;;;;;;;;
; In v120, if you wanted formatted strings you had to do something like this:
; Note the global variable, !username
msg_notify "There are " $count " things going on and " !username " needs to deal with them."

; As of v121, you can instead do this:
msg_notify $"There are {count} things going on and {global.username} needs to deal with them."

; As you can see, scopes are supported, as is the default/empty scope. I dunno... feels a bit tidier
;;;;;;;;;;;;;;;;;;;;;

 

Variable use is going to be a little more strict.

 

Variable names must now be bare, cannot be quoted, to be resolved

 

;;;;;;;;;;;;;;;;;;;;;
; In v120, you could enclose each token on a line in double quotes, or leave it bare, and it would be treated the same.
set $myvar something
set $myvar "something"
set "$myvar" something
set "$myvar" "something"
; all did the same thing.

; In v121, enclosure in double quotes will force the token to be treated like a string literal and will absolutely prevent it from being resolved as a variable.
; Similarly, enclosure in $-double quotes for string interpolation will only allow variable expansion for {} enclosed variable names and will treat it otherwise also like a string literal
; Put another way, all variable names must be bare to be resolved as a variable
set $myvar something
set $myvar "something"
; these work just like they used to
set "$myvar" something
set "$myvar" "something"
; both will NOT set ANYTHING to ANY VALUE. The variable will not be resolved, the value will not be placed anywhere, and nothing will happen except error output to the log.
;;;;;;;;;;;;;;;;;;;;;

 

Error messages are improving.

 

I have made more of an effort to improve error reporting; squaked error messages that list a line number with your script name should actually be matching up to the real line number, making it easier to see which line of your script is causing a problem. Due to how lax the parsing is for SLTScript, there are a number of scenarios that I'm not outputting diagnostics for, but I'll be adding them as I go.

That's all I can think of off the top of my head. 

 

So when will a new release come out?

 

I'm recovering from something... flu? covid? The symptoms match but so far all tests have been negative. Anyhow, it has slowed me down the last few days, but barring interruptions or unforeseen circumstances, I would like to get this pushed out some time tomorrow (it's a bit late for me right now).

 

REMEMBER, THERE WILL BE MANY SCRIPT-BREAKING CHANGES IN THE NEXT RELEASE DUE TO SIGNIFICANT SYNTAX CHANGES AROUND VARIABLE NAMING. DO NOT UPDATE WITHOUT CONSIDERING ANY CUSTOM SCRIPTS YOU HAVE WRITTEN.

Edited June 21, 2025 by hextun
humor

[hextun]

🤢🤮

[hextun]

New version up. Roast me.

 

BTW... THE .DLL NAME CHANGED.

 

Previously I was installing "sl-triggers-internal.dll". I am now just using "sl-triggers.dll". Be aware if you update in place and the old .dll is still present YOU WILL LIKELY HAVE PROBLEMS. Maybe tax related. Possibly relationship related. I'm not sure at this point, but THERE WILL LIKELY BE PROBLEMS if you have both. Just sayin'.

[NismoMan]

13 hours ago, hextun said:

New version up. Roast me.

 

BTW... THE .DLL NAME CHANGED.

 

Previously I was installing "sl-triggers-internal.dll". I am now just using "sl-triggers.dll". Be aware if you update in place and the old .dll is still present YOU WILL LIKELY HAVE PROBLEMS. Maybe tax related. Possibly relationship related. I'm not sure at this point, but THERE WILL LIKELY BE PROBLEMS if you have both. Just sayin'.

Dude. I'm almost finished setting up my MCMs for my new playthrough and this dropped in like a rock from outer space, lol. So yeah, Can I update the mod midway? I haven't even initialized SLAB / Defeat yet so nothing has been triggered (didn't even set up anything in SL Triggers as of yet).

 

Edit: Reason I'm asking is because I saw the note in your changelog... I'm just grasping at straws at this moment coz I don't wanna go through the MCM wormhole all over again >.<

Edited June 23, 2025 by NismoMan

[hextun]

4 hours ago, NismoMan said:

Dude. I'm almost finished setting up my MCMs for my new playthrough and this dropped in like a rock from outer space, lol. So yeah, Can I update the mod midway? I haven't even initialized SLAB / Defeat yet so nothing has been triggered (didn't even set up anything in SL Triggers as of yet).

 

Edit: Reason I'm asking is because I saw the note in your changelog... I'm just grasping at straws at this moment coz I don't wanna go through the MCM wormhole all over again >.<

Sorry about the timing, my person.

 

if you want to try it, remove the previous version fully (you can transfer custom scripts and triggers though) and try a save without it, then install the new version. Installing midplaythrough seems to be fine; I'm just not sure about the uninstall. And I am almost positive that a straight up direct reinstall will fail gloriously.  

 

the main issue is that a number of properties were added and changed on several quest scripts. 

[NismoMan]

6 hours ago, hextun said:

Sorry about the timing, my person.

 

if you want to try it, remove the previous version fully (you can transfer custom scripts and triggers though) and try a save without it, then install the new version. Installing midplaythrough seems to be fine; I'm just not sure about the uninstall. And I am almost positive that a straight up direct reinstall will fail gloriously.  

 

the main issue is that a number of properties were added and changed on several quest scripts. 

It's not like you planned it bro (or did you?!)

I'll try to export/save as many MCM settings as I possibly can and see if I can stomach going through the whole thing again. Doesn't make sense to kick start a new playthrough with broken scripts for a base, lol.

 

So, yeah. My circumstances aside; Thanks for maintaining this mod man. 🙂

[hextun]

1 hour ago, NismoMan said:

It's not like you planned it bro (or did you?!)

I'll try to export/save as many MCM settings as I possibly can and see if I can stomach going through the whole thing again. Doesn't make sense to kick start a new playthrough with broken scripts for a base, lol.

 

So, yeah. My circumstances aside; Thanks for maintaining this mod man. 🙂

Well, as fate would have it, I literally did this to myself, I tested my suggestion, and by the Nine it worked!

 

So I have 3 test modpacks I flit between. The least used one is just a different MO2 profile on the same modpack I actually play for personal use.

 

As it happens, I had in fact NOT tested 121 (or 120, or 119, or even 118) on that last oh so rarely used modpack. No, I still had 117 on that bad boy *slaps the hood and nervously watches for a CTD*. 

 

And having been a bit, I decided to start a new character. And I think I got into Whiterun before I realized which version I was on and why some of the scripts I had setup weren't working. *cough*

 

Yeah, I had assumed I had already updated to 121 and laid out my custom scripts that had been updated. And hilarity did, in fact, not ensue. Nothing ensued. Silly varname syntax change. 

 

So anyhow, can confirm...

 

It appears safe to just outright delete sl_triggers, load without it and re-save, then install the new version, load with that and save. That intermediate bit is just to clear it out. If you have a save cleaner... I guess that would work too? I've never tried one.

[Crocop777]

I remember having a script that adds item to my inventory after a scene with a specific actor , like getting troll fat after a scene with a troll , etc..  But i lost it , anybody got this script by any chance ?

[NismoMan]

6 hours ago, Crocop777 said:

I remember having a script that adds item to my inventory after a scene with a specific actor , like getting troll fat after a scene with a troll , etc..  But i lost it , anybody got this script by any chance ?

 

Try this:

item_add $system.self "skyrim.esm:241010" 1 0

 

Just create a text file, call it something like "Give TrollFat.ini", copy and paste the code above in it, save and drop it in "SKSE\Plugins\sl_triggers\commands". Now you just need to set up the rules you want (actor race, on end.. etc.) in the MCM to trigger the script.

 

I Hope I got the Item ID right.

 

Good Luck!

[NismoMan]

9 hours ago, hextun said:

Well, as fate would have it, I literally did this to myself, I tested my suggestion, and by the Nine it worked!

 

So I have 3 test modpacks I flit between. The least used one is just a different MO2 profile on the same modpack I actually play for personal use.

 

As it happens, I had in fact NOT tested 121 (or 120, or 119, or even 118) on that last oh so rarely used modpack. No, I still had 117 on that bad boy *slaps the hood and nervously watches for a CTD*. 

 

And having been a bit, I decided to start a new character. And I think I got into Whiterun before I realized which version I was on and why some of the scripts I had setup weren't working. *cough*

 

Yeah, I had assumed I had already updated to 121 and laid out my custom scripts that had been updated. And hilarity did, in fact, not ensue. Nothing ensued. Silly varname syntax change. 

 

So anyhow, can confirm...

 

It appears safe to just outright delete sl_triggers, load without it and re-save, then install the new version, load with that and save. That intermediate bit is just to clear it out. If you have a save cleaner... I guess that would work too? I've never tried one.

 

Lol, damn. is all I can say

 

I did fire up a save cleaner, looked up the esp and yep, lots of entries that I simply didn't feel comfortable dealing with them on a brand new playthrough so I just ended up sucking it up and created a new save just for the peace of mind >.< 

[hextun]

On 6/18/2025 at 8:18 PM, LinksSword said:

how would you make a script where a item is forced onto the player when they try to loot a dungeon chest for example? 

 

So would you want it to run the script when you open the container or when you take from the container (and if so, each time or just once per container opening)? And only in dungeons?

[Dakhma]

On 5/31/2025 at 2:52 AM, Dakhma said:

Sorry I am new to all this, is this correct?

 

 

set $1 "Enchanted Bestial Urination.esp:123123123"

Watery Bear Urine
"Enchanted Bestial Urination.esp:2063"

Fresh Goopy Boar Urine
"Enchanted Bestial Urination.esp:2064"

Fresh and Hot Horse Urine
"Enchanted Bestial Urination.esp:2065"

Sticky Riekling Urine
"Enchanted Bestial Urination.esp:2066"

Infected Skeever Urine
"Enchanted Bestial Urination.esp:2067"

Fresh Seasoned Canine Urine
"Enchanted Bestial Urination.esp:3436"

Mage's Bestial Urine
"Enchanted Bestial Urination.esp:3438"

Fatty and Thick Troll Urine
"Enchanted Bestial Urination.esp:3440"

item_adduse $player $1 1 0

 

Any chance someone can help me finish implementing this?

[hextun]

1 hour ago, Dakhma said:

Any chance someone can help me finish implementing this?

Sure. Which version are you running at this point? I just released v121 and it becomes reeeeaaally important now.

This script should work for v121 for example:

 

set $ebumod "Enchanged Bestial Urination.esp:"

set $wateryBearUrine			$"{ebumod}2063"
set $freshGoopyBoarUrine		$"{ebumod}2064"
set $freshAndHotHorseUrine		$"{ebumod}2065"
set $stickyRieklingUrine		$"{ebumod}2066"
set $infectedSkeeverUrine		$"{ebumod}2067"
set $freshSeasonedCanineUrine	$"{ebumod}3436"
set $magesBestialUrine			$"{ebumod}3438"
set $fattyAndThickTrollUrine	$"{ebumod}3440"

set $ebuOfChoice resultfrom rnd_list $wateryBearUrine $freshGoopyBoarUrine $freshAndHotHorseUrine $stickyRieklingUrine $infectedSkeeverUrine $freshSeasonedCanineUrine $magesBestialUrine $fattyAndThickTrollUrine

item_adduse $system.player $ebuOfChoice 1 0

 

 

If, for example, you wanted there to be a higher chance for infectedSkeeverUrine, etc. First of all, for your sanity, you would probably shorten the variable names. But the idea is that you repeat a given entry to represent it's weight.

 

Say you wanted, out of 10 random picks, 5 should be infectedSkeeverUrine, 3 should be from dogs, and 1 from horse. This would do it:

set $ebumod "Enchanged Bestial Urination.esp:"

set $wateryBearUrine			$"{ebumod}2063"
set $freshGoopyBoarUrine		$"{ebumod}2064"
set $freshAndHotHorseUrine		$"{ebumod}2065"
set $stickyRieklingUrine		$"{ebumod}2066"
set $infectedSkeeverUrine		$"{ebumod}2067"
set $freshSeasonedCanineUrine	$"{ebumod}3436"
set $magesBestialUrine			$"{ebumod}3438"
set $fattyAndThickTrollUrine	$"{ebumod}3440"

; even distribution
set $ebuOfChoice resultfrom rnd_list $wateryBearUrine $freshGoopyBoarUrine $freshAndHotHorseUrine $stickyRieklingUrine $infectedSkeeverUrine $freshSeasonedCanineUrine $magesBestialUrine $fattyAndThickTrollUrine

item_adduse $system.player $ebuOfChoice 1 0

; weighted between skeever:5, canine:3, horse:1
; use shortened names for better readability
set $skeever	$"{ebumod}2067"
set $canine		$"{ebumod}3436"
set $horse		$"{ebumod}2065"

; the rnd_list will pick from the list, including from among duplicates, allowing weighting
set $weightedEbuOfChoice resultfrom rnd_list $skeever $skeever $skeever $skeever $skeever $canine $canine $canine $horse

item_adduse $system.player $weightedEbuOfChoice 1 0

 

For older versions, the string interpolations: $"{var}..." become string concatenations: $var & "...". So:

$"{ebumod}2063"

; would have been (in pre-v121)
$ebumod & "2063"

 

and specifying the player as a target has changed from $player to $system.player:

$item_adduse $system.player $ebuOfChoice 1 0
; would have been, pre v121:
$item_adduse $player $ebuOfChoice 1 0

 

also, prior to v120, "set..resultfrom.." was not a thing, so:

set $ebuOfChoice result from rnd_list ....

; would be (pre v120)
rnd_list $....
set $ebuOfChoice $$

And please update to having variable names. Ideally all the way up to v121. If you save without the mod installed once to clear it out, then install and reload, it seems to pick up just fine. You'd need to modify any of your custom scripts but they wouldn't have been overwritten (unless you were modifying original scripts in place).

Edited June 24, 2025 by hextun

[hextun]

Next release:

  new Core event: OnPlayerCellChange: filters: chance, daytime (any, day, night), location (any, interior, exterior)

  new Core event: OnPlayerLoadingScreen: filters: chance (honestly, just exposed it because I get it for free when doing the player cell change work; triggers when the loading screen runs)