SL Triggers(v12) [2022-06-05]

[hextun]

Fresh meat, get it while it's hot! Beta 101 - The SexLabbening, has arrived.

 

Officially, the changelog reads:

 

101
    bugfix: sexlab compat
    enhancement: sl_orgasm

 

And that doesn't really do it justice. There was more going on in this update than that, but the SexLab compatibility working is definitely a positive. Did some cleanup, fixed a few annoyances. I want to do a nice cleanup pass, plus I still need to actually get some longer term play in with it.

sl_triggers101.zip

[hextun]

9 hours ago, MannySauce said:

 

 

I'm just looking for a way to trigger/reach separate orgasm, don't think I want to mess with the behind the scenes enjoyment progress.
Something like ["sl_so", "$self"].

And I'm not objecting to the .dll, my only worry would be game version support. I'm still on 1.6.640 because my 1.6.1170 setup is still incomplete.

 

@MannySauce There's a goody in the latest beta for you.

 

[hextun]

And, sorry for the spam, but to give some insight into how I work/have been working, by way of explaining why the first beta of an overhaul of SEXLAB triggers did not work with SexLab.

 

I can test the keymapping trivially in both sexlab and non-sexlab installs which allows me to fix things that are generally related to the overall task flow more quickly. That lets me focus on things like why none of the SexLab events were working and yet I could trigger an orgasm via a hotkey.

 

sl_orgasm is cool... I got the camera shake and all. But I installed SexLab Survival to see if the hotkey triggered orgasm counted toward statistics; it didn't but it could be the slapdash SexLab install I put on top of Skyrim Modding Essentials. I mean, it all works but I didn't even bother with obody so everyone's dry humping each other, but I've got my events and that's what matters.

 

Anyway, I posted the first one in a state of delirium because by late evening, hour by hour, I just knew I was within 1 more hour of getting something nailed down. If anyone has tried their hand at managing the event lifecycles and handling large sets of dynamic data in Skyrim modding, I'd love to talk shop and, regardless of how you feel about that, you have my sincerest condolences. This shit be cray-cray.

 

So it all came down to a) a very compressed testing lifecycle and b) a huge desire on my part to actually release the beta.

[ebbluminous]

Spam is good if it means new, more and better things!  

[MannySauce]

Going from v23 to Beta 101 I can't get anything to actually trigger, not my own stuff before and after converting nor the included examples. No .dll compatibility error on launch, the MCM works fine and the triggers are generated in their new extension folders.

[hextun]

3 hours ago, MannySauce said:

Going from v23 to Beta 101 I can't get anything to actually trigger, not my own stuff before and after converting nor the included examples. No .dll compatibility error on launch, the MCM works fine and the triggers are generated in their new extension folders.

 

Okay, going through the usual:

- Which Skyrim/SKSE version are you running? 

- Does it fail on a new save?

- Do you still have the previous version installed (i.e. is this installed to a different mod folder)? If so, would you mind removing the previous version?

- Which triggers have you tried? Just to test things, try a key mapping to something like give gold 10.

 

And to everyone else, is anyone else having similar issues?

[Fraying9981]

7 minutes ago, hextun said:

And to everyone else, is anyone else having similar issues?

 

Too scared to try 😄😄😄

[MannySauce]

1 hour ago, hextun said:

 

Okay, going through the usual:

- Which Skyrim/SKSE version are you running? 

- Does it fail on a new save?

- Do you still have the previous version installed (i.e. is this installed to a different mod folder)? If so, would you mind removing the previous version?

- Which triggers have you tried? Just to test things, try a key mapping to something like give gold 10.

 

And to everyone else, is anyone else having similar issues?

 

- 1.6.640 with SKSE 2.2.3
- Does not fail on a new save. I just did a quick "coc riverwood" from the main menu to test a new game and the same keymapped Core trigger with Ab02.ini gave me 69 gold just fine, so I think there's an issue with upgrading the mod on ongoing saves.
- Just one version enabled at a time in MO2.
- On my ongoing save, all the ones it came packaged with plus my own abominations. On the new save, just the one I mentioned. EDIT: I mean the commands here, the .json and .ini files. For events I tried Keymapping, Begin, Orgasm and End with Player and Not Player as targets all at 100% chance.

Edited April 23, 2025 by MannySauce
oops

[hextun]

6 minutes ago, MannySauce said:

 

- 1.6.640 with SKSE 2.2.3
- Does not fail on a new save. I just did a quick "coc riverwood" from the main menu to test a new game and the same keymapped Core trigger with Ab02.ini gave me 69 gold just fine, so I think there's an issue with upgrading the mod on ongoing saves.
- Just one version enabled at a time in MO2.
- On my ongoing save, all the ones it came packaged with plus my own abominations. On the new save, just the one I mentioned. EDIT: I mean the commands here, the .json and .ini files. For events I tried Keymapping, Begin, Orgasm and End with Player and Not Player as targets all at 100% chance.

 

Well, first of all, *phew* that it works for you on a new save. I hadn't tried to upgrade from the original, and given the fact that I am rearranging the guts, I would not expect this to work with an existing save.

 

For a little background... the scripts, when compiled to .pex, are just describing the "shape" of the script/class i.e. this attribute, this type, with this name, and this function etc. The game loads them and the VM references them to know what to do with them. On an existing save, the game had loaded those scripts with v12 or v23 or whatever, when there were only 5 scripts and the had a certain set of attributes and functions. Then you install new scripts and when it wakes up it starts trying to put round pegs into square holes (or vice versa) and now what it thought was an "sl_triggersMain" doesn't look right at all. So a lot would, at best, be ignored.

 

So yeah... I suppose I should have said up front that this is going to require a new save. 

[MannySauce]

22 minutes ago, hextun said:

 

Well, first of all, *phew* that it works for you on a new save. I hadn't tried to upgrade from the original, and given the fact that I am rearranging the guts, I would not expect this to work with an existing save.

 

For a little background... the scripts, when compiled to .pex, are just describing the "shape" of the script/class i.e. this attribute, this type, with this name, and this function etc. The game loads them and the VM references them to know what to do with them. On an existing save, the game had loaded those scripts with v12 or v23 or whatever, when there were only 5 scripts and the had a certain set of attributes and functions. Then you install new scripts and when it wakes up it starts trying to put round pegs into square holes (or vice versa) and now what it thought was an "sl_triggersMain" doesn't look right at all. So a lot would, at best, be ignored.

 

So yeah... I suppose I should have said up front that this is going to require a new save. 

 

Don't know why I didn't expect that with the rework you're doing, yeah, all cool. I've salvaged my SL Triggers saves with some ReSaver shenanigans and it's back to working condition. I think. I'll test it some more when I have time, else new save it is.

[hextun]

NEW BETA DROP: v102

 

Chef, today I have prepared for you a main course of multiple MCM related bug fixes, with a side of bugfixes related to triggers not updating between launches, and a garnish of localization.

 

 

102
    bugfix: fixed problem where available triggers would not reset between launches of the game
    bugfix: fixed problem with MCM OID handling (might not have noticed it; it could be subtle)
    enhancement: QoL for your developer; lots of code clean up and trying to fix problems I introduced due to code clean up
        .. like, a LOT of code cleanup. Refactoring. Removing comments. Adding comments.
    enhancement: Added localization. sl_triggers doesn't have much to translate, but if you want to donate translations I'll add them

 

I'm feeling a lot better about the MCM. It may not seem like a big deal but honestly I have probably put more time at this point into the MCM than in the rest of the overhaul. So um... yeah...

 

Anyhow, if you intend to continue down this path, this is a must-have upgrade from the previous beta, which I will be disabling the download for momentarily. As is the way.

 

The individual extension-specific MCM settings pages aren't functional but just placeholders.

sl_triggers102.zip

[MannySauce]

6 hours ago, hextun said:

NEW BETA DROP: v102

 

Chef, today I have prepared for you a main course of multiple MCM related bug fixes, with a side of bugfixes related to triggers not updating between launches, and a garnish of localization.

 

 

102
    bugfix: fixed problem where available triggers would not reset between launches of the game
    bugfix: fixed problem with MCM OID handling (might not have noticed it; it could be subtle)
    enhancement: QoL for your developer; lots of code clean up and trying to fix problems I introduced due to code clean up
        .. like, a LOT of code cleanup. Refactoring. Removing comments. Adding comments.
    enhancement: Added localization. sl_triggers doesn't have much to translate, but if you want to donate translations I'll add them

 

I'm feeling a lot better about the MCM. It may not seem like a big deal but honestly I have probably put more time at this point into the MCM than in the rest of the overhaul. So um... yeah...

 

Anyhow, if you intend to continue down this path, this is a must-have upgrade from the previous beta, which I will be disabling the download for momentarily. As is the way.

 

The individual extension-specific MCM settings pages aren't functional but just placeholders.

sl_triggers102.zip 444.76 kB · 2 downloads

 

Alrighty, some stuff for 102:

Triggers do not dispel/expire when the command is done, they linger around on actors for their entire 86400 second duration as Trigger01, Trigger02, Trigger03 etc and keep adding new ones as they're called.
Trigger-Core-01 and Trigger-SexLab-01 end correctly, it's just the generic ones.

Also 'sl_isin' is giving me issues now, is this test correct? Because it always returns 0, both in and out of scenes:

[loop]
util_wait 5
sl_isin $self
if $$ = 0 no
msg_notify "1 / Yes"
goto loop
[no]
msg_notify "0 / No"
goto loop

[hextun]

3 hours ago, MannySauce said:

 

Alrighty, some stuff for 102:

Triggers do not dispel/expire when the command is done, they linger around on actors for their entire 86400 second duration as Trigger01, Trigger02, Trigger03 etc and keep adding new ones as they're called.
Trigger-Core-01 and Trigger-SexLab-01 end correctly, it's just the generic ones.

Also 'sl_isin' is giving me issues now, is this test correct? Because it always returns 0, both in and out of scenes:

[loop]
util_wait 5
sl_isin $self
if $$ = 0 no
msg_notify "1 / Yes"
goto loop
[no]
msg_notify "0 / No"
goto loop

 

Thank you. New drop with both fixes.

 

The trigger items that weren't going away were actually the "prime" commands that drive everything. I had hooked the same event I send to all the others to have them self-terminate but for some reason it wasn't taking. So I queued it up manually (for the prime) immediately after sending it (for the rest of the cluster). Weird... something I truly expected, and still would expect, to work.

 

As for sl_isin not working, without this update any command that is part of a non-base command set (i.e. all sexlab commands and a couple of them that are tied to "core" like toh and such) was using its own private result stack and not returning it back to the central heap to share. Fixed that too. For commands that "do something" it wouldn't have mattered because the effect occurs and nothing has to be communicated to anyone else. It would only have been attempts to return a value.

sl_triggers103.zip

[Fraying9981]

hey @hextun, may I ask what format is returned by util_getgametime and util_gethour?

 

I ran util_getgametime around 4.20 AM and got 14.xxx

I also created a tracker between roughly 4 AM and 4.20 AM, the difference was 0.089xxx

 

So i'm a bit confused as to how to use these?

[hextun]

30 minutes ago, Fraying9981 said:

hey @hextun, may I ask what format is returned by util_getgametime and util_gethour?

 

I ran util_getgametime around 4.20 AM and got 14.xxx

I also created a tracker between roughly 4 AM and 4.20 AM, the difference was 0.089xxx

 

So i'm a bit confused as to how to use these?

 

I am just about to step out, but here's a quick rundown.

 

First, they are both wrappers around: https://ck.uesp.net/wiki/GetCurrentGameTime_-_Utility

 

util_getgametime returns the float value directly. The value represents the number of in-game days that have passed. So after the first 24 hours of in-game time have passed (72 minutes of playing?) the value will return 1.0. After an additional day and a half, 2.5. 

 

util_gethour attempts to calculate the hour of the day as an integer. So it takes the float returned, and subtracts Math.floor(value) to get just the decimal part. Then it multiplies by 24 and returns the value.

 

When creating time tracking between game time (rather than real time) the values can get very small. 1/72 of normal to be precise. 

 

util_getgametime return 14.xxx means you called it 14 days into your game play. And I would be willing to be that the .xxx was roughly ~0.17 (i.e. the percentage of time passed in a day to reach 4:20 (nice) AM).

 

 

ALSO

 

I know there are some outstanding bugs. Truly spectacular really. I have another release I've been working on but it's going to rearrange the file structure a bit and will require a new save.

 

 

[hextun]

Hey folks, something of a big chunk of an update that doesn't actually look like much. I virtually rewrote the MCM handling. There were bugs that I believe I ironed out as well (so, the small thing you might notice) but otherwise you probably wouldn't care. But I'm going to crow about it a bit anyway.

 

As I've said, my goal is to improve the extendability of SLT as a framework. One part of this is to make it as easy as possible for mod developers to choose to do so. Since there is already an MCM to support managing triggers, and I wanted to add the ability to extend triggers, I felt I needed to offer extension developers the ability to just tell me the attributes they would want tracked in a trigger and I would manage the display, retrieval, and storage. As opposed to making them write their own MCM code. If it sounds a little ambitious, it is. It's probably the kind of thing that should sit apart as its own little framework that you use to make MCM development easier, because what I've developed it to now is having an attributes file tied to your extension that defines what you want me to track and display for you. I *had* created a bunch of code but seeing how formulaic it was and how much code I was having to support for it, I chose to do this instead. This reduced the amount of code I have to support and also reduced the complexity of the approach, which in turn should reduce the likelihood of showstopping bugs down the road.

 

Also I think it's cool.

 

So, what does it mean to you? Well, like I said in the previous post this update will require a new save, done and done. That said, back up your existing triggers. The file format didn't change but the locations did.

What used to be organized like:

 

SKSE/Plugins/sl_triggers/
    settings.json
    commands/
    commandstore/

 

Has now morphed into this:

 

SKSE/Plugins/sl_triggers/
    settings.json
    commands/
    commandstore/
    extensions/
        sl_triggersExtensionCore-attributes.json
        sl_triggersExtensionCore-settings.json
        sl_triggersExtensionSexLab-attributes.json
        sl_triggersExtensionSexLab-settings.json
        sl_triggersExtensionCore/
            trigger***.json
        sl_triggersExtensionSexLab/
            trigger***.json

 

 

So in the extensions folder, for any given extension, you will likely see two files (-settings and -attributes) and a subfolder for it.

 

The attributes file is really read-only and not meant for modifying. Reinstall it if you change it and have problems. The settings file is what you expect.

 

Note that the "enabled" flag if changed in the file before starting the game will be what takes effect. So if you save the game with something enabled, manually change the flag, and start it, it will start disabled, and vice versa. Not sure if that's cool or not, but it is what it is. I mean.. like, on purpose. I wanted that.

 

Let's see... I want to create an API script of sorts, something that other mod authors could use to tap into some features. I already have a ModEvent that I register and listen for that technically any mod could send an event with the name of a command file and it will run it on the player. I would like to expand that. I also want to create a sample extension and have some ideas on additional functions to add.

 

Anyhow, have a go and let me know!

sl_triggers104.zip

[Fraying9981]

6 hours ago, hextun said:

util_getgametime returns the float value directly. The value represents the number of in-game days that have passed. So after the first 24 hours of in-game time have passed (72 minutes of playing?) the value will return 1.0. After an additional day and a half, 2.5. 

 

util_gethour attempts to calculate the hour of the day as an integer. So it takes the float returned, and subtracts Math.floor(value) to get just the decimal part. Then it multiplies by 24 and returns the value.

 

When creating time tracking between game time (rather than real time) the values can get very small. 1/72 of normal to be precise. 

 

util_getgametime return 14.xxx means you called it 14 days into your game play. And I would be willing to be that the .xxx was roughly ~0.17 (i.e. the percentage of time passed in a day to reach 4:20 (nice) AM).

 

thanks for the explanation! it's very clear.

 

I was wondering, still trying to improve my scripts: I have many mods, is there a way (not via this mod of course) to quickly find/get a list of all spells from my mods + effects + their code?

 

Also, one more question: are global variables reset on loading the save? or, are there stored with the save across game sessions?

Edited April 26, 2025 by Fraying9981

[hextun]

33 minutes ago, Fraying9981 said:

 

thanks for the explanation! it's very clear.

 

I was wondering, still trying to improve my scripts: I have many mods, is there a way (not via this mod of course) to quickly find/get a list of all spells from my mods + effects + their code?

 

Also, one more question: are global variables reset on loading the save? or, are there stored with the save across game sessions?

 

SLT globals should persist across saves.

 

I don't know of a good way of getting the list you're talking about, at least not as I interpret it; export a list of all MGEF and SPEL records with their associations. When you say "get a list of all spells" .. "+ effects + their code"? What, for example, would you be looking for? What, if I gave it to you, would you be able to describe and say "yes, that is what I want"?

[Fraying9981]

7 hours ago, hextun said:

 

SLT globals should persist across saves.

 

I don't know of a good way of getting the list you're talking about, at least not as I interpret it; export a list of all MGEF and SPEL records with their associations. When you say "get a list of all spells" .. "+ effects + their code"? What, for example, would you be looking for? What, if I gave it to you, would you be able to describe and say "yes, that is what I want"?

 

No need for the code.

As im improving my triggers im looking for ideas of spells to add from existing mods.

 

also, wondering if there is a way to detect animation tag change? I know you can use the trigger begin/slso/end to fetch punctually whatever tag the animation has, but is there a way to detect when animation changes due to user input, for example when switching to foreplay to blowjob?

Edited April 26, 2025 by Fraying9981

[hextun]

I will likely be making another release later today.

 

I already have the code working for "gosub" and am working on "call".

 

Here is an example script that would use "gosub":

 

msg_notify "Begin GosubExample"

set $1 1

gosub helloworld
gosub helloworld
gosub helloworld

msg_notify "End GosubExample"

gosub helloworld
msg_notify "Hah, now for real"


beginsub helloworld
    set $1 $1 + 1
    set $2 "Hello world! " & $1
    msg_notify $2
endsub

 

The output would be:

 

Begin GosubExample

Hello world! 2.000

Hello world! 3.000

Hello world! 4.000

End GosubExample

Hello world! 5.000

Hah, now for real

 

beginsub/endsub will be ignored if encountered during parsing, i.e. you don't have to put them at the bottom.

 

The intent with "call" will be to do the same thing but with entire command files.

[hextun]

New drop. I think you'll like this one.

 

105
    bugfix: possible resolution issue with global variables in some cases
    enhancement: new feature, subroutines
        beginsub <subroutinename>/endsub to demarcate the subroutine
        gosub <subroutinename> to execute and return
    enhancement: new feature, "call"
        call <command file name> <optional $1 argument> <optional $2 argument> ...
            stops execution of current command file, runs the requested file, then resumes current command file
            if an extension is not specified .ini is tried first, then .json
            variable scopes are NOT shared (global variables are, of course, still global)
                so if you set $1, then call a function, it will not see your $1 value
                but if you use $g1, it will
            arguments are passed by value
        callarg <index> <variable name>
            Example: callarg 0 $2
            this will place the first (index 0) argument passed into $2

 

That's right, you can now create subroutines (i.e. functions) within your commands, and you can also call one command from another command *as* a command. You can even pass arguments to those commands.

 

I said GO NUTS!!!!

sl_triggers105.zip

[hextun]

I've started a wiki for documentation.

 

https://github.com/lynnpye/sl_triggers/wiki

[hextun]

I want to create a sample extension that adds additional commands you can run in your scripts. Possibly even something that offers hooks for more events i.e. tied to another mod.

 

What other mods would you suggest I have a look at? The primary goal would be to add commands, so things you would want to *do to* or *do at* the mod. Adding triggers would be *responding to* the mod, which is fine and I would happily add hooks in for events, but is there a mod you want to be able to alter its behavior for?

[hextun]

Also, who has some cool scripts you would like to share? It would be nice to beef up the base library a bit with some battle-tested scripts that have already been found useful.

[ebbluminous]

7 hours ago, hextun said:

Also, who has some cool scripts you would like to share? It would be nice to beef up the base library a bit with some battle-tested scripts that have already been found useful.

So far I've only done ones to use potions, modifying existing ones.

I've done it for mods like Lacttat, Eager NPCs etc to use the potion so it fires off those effects.

Need to have a ponder on what else can start to be done with this mod