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

[hextun]

Minor update. I added a json config file to set your random number range, your increment step, and the initial value for the actor value, including what it gets reset to.

Note that if you don't keep the AVG.toml in sync with the starting value in the pet_collar_game.json, your character will start with the value in the .toml, so expect that behavior.

I also changed the defaults. The random number is from 1 to 50, the initial value is -5, and the increment is still 1. So you are guaranteed at least 5 sex encounters with followers before having to worry about them possibly slipping a collar onto you. Likewise, you'll be in that collar that long before mercy may kick in.

 

ETA: Ugh, I forgot to remove a debugging "msg_notify" in the trigger command .txt file 'FollowerPetSexCheck.txt'. It's really obvious and easy to remove just the one line.

 

SLT_PetCollar_Game.um.0.2.7z

Edited March 20, 2025 by hextun

[maxdenusenko]

Skyrim VR
The OnBegin event does not trigger when selecting a scene via SL Tools.

[j-e-s-s-t-e-r]

For some reason the default addperkpoint .json isn't giving me a perk point when it triggers. Is anyone else having this problem? 

[WCSC]

I'm sure this has been discussed here before but can't seem to find it anywhere on this thread.  Is there a way to make a trigger to change a clothing to a skimpy version during an animation?

[hextun]

10 hours ago, WCSC said:

I'm sure this has been discussed here before but can't seem to find it anywhere on this thread.  Is there a way to make a trigger to change a clothing to a skimpy version during an animation?

 

I think the problem at the moment would be that currently there are no commands to fetch the actor's armor, retain a reference to it, and so on. I'm playing with an idea right now that would add a few more extension functions. Something like adding various "fetch_thus_and_such" and associated "fx_soandso_get_something". The idea being that "fetch_*" functions retrieve a Form and put it into a formStash while "fx_*" (for formeXtract) functions would grab values from the formStash and put them into "$$". For example, imagine the following:

 

["fetch_actor_worninslot", "$self", "32"],

["fx_armor_getwarmthrating"],

["set", "$1", "$$"]

 

and now "$1" contains the  warmth rating of the armor worn by $self in slot 32.

 

For your particular example, we want to unequip an item in said slot if it's there, equip another item, then when done reverse it. 

 

["fetch_actor_worninslot", "$self", "32"],

["fx_form_getid"], -- idea being this fetches a form id that could be used to look up the item on the person

["set", "$1", "$$"], -- item id of what they are wearing in slot 32

["set", "$2", "skimpy.esp:69420"], -- the skimpy clothes

["item_uequipex", "$self", "$1", "0"],

["item_add", "$self", "$2", "$1"],

["item_equipex", "$self", "$2", "0", "0"],

["util_waitforend"],

["item_remove", "$self", "$2", "1", "1"],

["item_equipex", "$self", "$1", "0", "0"]

 

As a further extension, while $1-$9 are basically strings, $f1-$f9 could be introduced as form variables for more advanced functionality.

 

Alternatively, there is the option of adding direct manipulation functions as needed.

 

Thoughts?

[hextun]

I'm tinkering with what is becoming something of an overhaul of sl_triggers and was wondering what anyone else's appetite for it would be.

 

Essentially I'm altering it to allow easier expandability. The goal would be for anyone who was so inclined to create their own mod that would add additional commands to the command set or respond to different events. I have a design and have worked through some of the implementation.

 

Thoughts?

[hextun]

So, I'm mid-way through. Updates:

 

- instead of triggers all residing in settings.json, triggers added by a given extension (or core for.. core) will reside, one per file, in a folder with the name of the extension

- you'll be able to just write a trigger in json (if that's your thing) and drop it in and it will be picked up next game start

- if you use the MCM in game to edit triggers, they will be saved back to the file they were loaded from

- if you add a trigger it will be saved with a simple numbering scheme 'trigger#.json' which you can rename after you leave the game (I just... do I have to put a filename editor in the MCM?)

- core and sexlab/slso functionality have been split out into separate extensions

- you can extend a couple of classes to create your own extension in a separate .esp; you'll call sl_Trigger.RegisterExtension() to get started (at the moment anyway)

- with an extension you can:

-- add new operations (e.g. actor_name, sl_isin... the functions you call in your trigger scripts)

-- add new variables/variable types (e.g. $f1 to store forms in scratch variables)

-- add interfaces to new mods (e.g. something for MilkModEconomy, FillHerUp, SexLab Survival, SexLabAroused/OSLAroused that exposes their API through operations)

-- listen to events from new mods and ask sl_triggers to run the requested file (i.e. the whole point of all of this)

 

At the moment I'm working on the implementation of the scratch memory.

 

The upshot is that once this is done, one could have however many different packages of operations or interfaces to different mods, each adding ways to move data between that mod and the core dataset, giving some interoperability without needing to create patch mods.

 

You could download an extension for arousal gains and another extension that adds an "on game day start" trigger and then have a script that bumps your arousal daily. You could add an extension for FHU and catch semen level change events and an extension for, say, SunHelm, and adjust thirst levels as your body absorbs semen and extracts moisture. And so on. All without needing wait for an update to the core mod. You'll be able to mix and match modules, keeping the number of events hooked to just the minimum you want for your list.

 

I'll post with more updates as I have them.

[hextun]

Okay, this isn't where I intend to go in terms of a redesign, but instead of waiting for that I wanted to get something out to show more of what sl_triggers could do.

 

Attached you will find sl_triggers13.zip. It contains the following changes:

- added a new event type to listen for "Top of the Hour": will try to fire once at the top (1 oclock, 2 oclock) of each in-game hour. The player will be $self.

  - SexLab oriented trigger filters are disabled for this event; operations may or may not function if used outside their intended environment ('sl_in' outside of a SexLab scene)

- added a new variable type, globals, accessible via "$g0" through "$g9"; as the name implies, these are persistent and visible across all command .json executions; your scripts can talk to each other now

- added three new operations usable in your command .json files

  - actor_worninslot

  - actor_wornhaskeyword

  - actual_hours_since_last_top

    - okay, I hate this name, but... when you register for a "top of the hour" event, your player may sleep for 12 hours. you will only get a notification once completed and then you have to determine how you want to handle the... "actual hours since the last top of the hour". If you have a better name, propose it please. Please.

 

If you have other event suggestions, let me know, ideally expanding on core Skyrim or SKSE events since those won't require adding more dependencies. But, you can understand why I want to make this modular.

sl_triggers13.zip

[nopse0]

10 hours ago, hextun said:

Okay, this isn't where I intend to go in terms of a redesign, but instead of waiting for that I wanted to get something out to show more of what sl_triggers could do.

 

Hi, great that you are adding new features to SLTriggers and planning to redesign it, since Fotogen seems to be inactive for quite a while now.

 

The biggest deficit of SLTriggers is, in my opinion, that "Is Player"/"Is Not Player"/"Other Is Player"/"Other Is Not Player" are part of the "If Race" condition, they should be a separate condition.

 

Because the "If Actor" (="Victim"/"Aggressor")  and "If Gender" conditions are checked on the $self actor, so if you want that something is happening to the player, if the sex partner of the player is a "Victim" or "Aggressor" and has a certain gender, $self must be the sex partner and you have to choose "Other Is Player" as the "If Race" condition.

But then you cannot choose the race of the sex partner ("Humanoid"/"Creature"/"Undead"), because the "If Race" condition must be "Other Is Player".

 

Phew, difficult to describe what I mean, I hope this was understandable.

 

 

[hextun]

12 hours ago, nopse0 said:

 

Hi, great that you are adding new features to SLTriggers and planning to redesign it, since Fotogen seems to be inactive for quite a while now.

 

The biggest deficit of SLTriggers is, in my opinion, that "Is Player"/"Is Not Player"/"Other Is Player"/"Other Is Not Player" are part of the "If Race" condition, they should be a separate condition.

 

Because the "If Actor" (="Victim"/"Aggressor")  and "If Gender" conditions are checked on the $self actor, so if you want that something is happening to the player, if the sex partner of the player is a "Victim" or "Aggressor" and has a certain gender, $self must be the sex partner and you have to choose "Other Is Player" as the "If Race" condition.

But then you cannot choose the race of the sex partner ("Humanoid"/"Creature"/"Undead"), because the "If Race" condition must be "Other Is Player".

 

Phew, difficult to describe what I mean, I hope this was understandable.

 

 

 

Easily enough done, I think. Because the "race" list is shrinking, with options effectively moving to the new "player" list, existing triggers that had the "race" option set will need to be reconfigured in most cases.

[nopse0]

2 hours ago, hextun said:

 

Easily enough done, I think. Because the "race" list is shrinking, with options effectively moving to the new "player" list, existing triggers that had the "race" option set will need to be reconfigured in most cases.

I thought this, too, at first. But on second thought, I think, doing a new "player" list, doesn't require to remove the player conditions from the "race" list, the player options are just redundant then in the race list (and of course, it's no good idea to choose "Is Player" in one of the two lists, and "Is Not Player" in the other one), then it would not be needed to renumber the options in the race list (much easier to implement, I think, I had a look at the main script, too )

[hextun]

Hope you don't mind the version number bumps. Just makes sense I think.

 

CHANGELOG

14
	split "if_race" into "if_race" and "if_player"
		you will likely need to update any triggers that relied on "if_race" previously
		existing "if_race" values will not be automatically updated and you will probably see:
			if you had...			then you will now have until you edit it...
			Player					Undead
			Not Player				Partner Humanoid
			Undead					Partner Creature
			Partner Humanoid		Partner Undead
			Partner Creature		??
			Partner Player			.. crabs??
			Partner Not Player		.. the void of space??
			Partner Undead			Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.
			
		"if_race" now offers:
			Any
			Humanoid
			Creature
			Undead
			Partner Humanoid
			Partner Creature
			Partner Undead
			
		"if_player" offers:
			Any
			Player
			Not Player
			Partner Player
			Partner Not Player

 

EDIT: You'll see that I changed sl_TriggersSetup.psc considerably, shifting to the event based SkyUI config functions. It's still tedious with the repeated option sets, but since it currently implements a fixed set of "cards" per page, it's not too onerous to add 5 states per configurable item. Just... bleh.

 

EDIT: Removed misleading download link.

Edited April 16, 2025 by hextun

[nopse0]

Cthulhu R'Lyeh ... ? Yes!, I love that stuff, too (and sex, of course, but that's nothing special, everybody does (except those artificial slime things perhaps, Shoggoths or what they are called))

[hextun]

New build. Biggest thing is a bug fix honestly: previously a StorageUtil value would be set for a couple of variables, then a wait timer used until the value was unset. Funnily enough it was checking the wrong variable on the unset. Anyhow, when I changed the logic, I missed that and as a result when I spin up the commands sometimes the timing would be off and if you had multiple commands for the one trigger, both might run the same file. Or one might run nothing. I have patched that up.

 

Fixed the "top of the hour" processing logic. It's just better now.

 

You can now access as many variables as you wanted. I doubt you needed this but it was part of something else I was working on. Here's to "$42".

 

15
	enhancement: improved "top of the hour" updategametime processing
	enhancement: variables can be any "$<non-negative-int>"
		["set", "$42", "life, the universe, and everything"]
		is now valid
	enhancement: global variables can be any "$g<non-negative-int>"
		["set", "$g42", "life, the universe, and everything"]
		is now valid
	fixed bug: fixed race condition when running multiple commands from one trigger
	change: renamed operation "actual_hours_since_last_top" to "toh_elapsed_time"
		"actual_hours_since_last_top" redirects to the new functionality for now

 

sl_triggers15.zip

[hextun]

New build and I'm pretty excited about this one.

 

Keymapping. With modifiers. And checking for Dynamic Activation Key if that's your groove. On a per trigger basis. Go nuts.

 

Yes, this means you can just pick a random keymapping, set up some command .json files for it, and just run it whenever.

 

16
	enhancement: added keymapping as an event; you can now bind keymappings to, as usual, up to 3 command files
		also allows for modifier use
		also allows for Dynamic Activation Key use per trigger
	enhancement: events will only be registered for if triggers exist that use them; if you do not hook any SexLab events, they will not be registered
		registration will update if you update the MCM
	change: lots of refactoring, technically some performance improvements but I haven't done timings so it's mostly my instinct, some general code cleanup (mostly due to mess of my own making)
	change: event id values (0 for SLStart...) are now 1 higher (1 for SLStart) to make the MCM behave more nicely; this should get converted automatically
	change: started adding some non-trigger values into settings.json, currently to track version; this is to help allow for settings updates in the future

 

EDIT: Removed misleading download link.

 

Edited April 16, 2025 by hextun

[hextun]

Not an update to the mod, but something I wanted to mention.

 

ConsoleUtils Extended (CUE) lets you not only create custom console commands via Papyrus, but also run console commands via API calls to their library. One of the limitations has been, at least that I'm aware of, that you cannot call custom console commands through the Papyrus API.

 

I've submitted a pull request (https://github.com/Scrabx3/ConsoleUtil-Extended/pulls) that at least on my machine (Nefaram build, 1.5.97) solves the problem. Following the instructions on the CUE website I was able to create and compile a Papyrus script, use it in console commands, but also run it via the "console" operation in an sl_triggers command.

 

This offers an opportunity for a big jump in execution speed. Right now each operation you perform in your script is read line by line, parsed, and then (very elegantly, hats off to fotogen) the appropriate operation is looked up and executed. Variables go through an extra few layers of activity for them to be read/written. And that is Papyrus script, reading text, and choosing Papyrus script functions to run.

 

Now what if you had a library of sorts to rely on so you could create simple (for Papyrus) scripts that could do some (not necessarily all) the same things your trigger .json is doing now but significantly faster?

 

The thing is, this isn't anything sl_triggers has to be modified to take advantage of. Assuming the PR goes through (or if I'm wrong, made a mistake somewhere, and it's not really a bug, whatever) and this functionality does become available, it just expands the scope of what you could effectively do within the span of a trigger.

[hextun]

New build and this is sidegrade territory, but important I think. Okay, this wasn't as hard as I feared. First, some photographic proof of a sort:

 

 

And yes, that would be sl_triggers running on a non-SexLab carrying copy of SkyRim. I installed SkyRim Modding Essentials to test this, so that would be against 1.6.whatever. The approach was pretty easy; I isolated all the uses of SexLab and tried to modify operations where possible to either degrade gracefully or return as meaningful a result as possible (e.g. falling back to Actor.GetBaseActor().GetSex() in lieu of SexLab.GetGender(); they return 0,1 identically and just differ on the other values, which should be fine given the specific use case).

 

EDIT: Removed misleading download link.

Edited April 16, 2025 by hextun

[labuser1234]

@hextun sorry if i'm late to the party if this was already answered - but does this work with SLP+ & the SLSB coverted animations?

[hextun]

3 hours ago, labuser1234 said:

@hextun sorry if i'm late to the party if this was already answered - but does this work with SLP+ & the SLSB coverted animations?

 

In what sense? I used sl_triggers with the Masterstroke list for awhile before I switched to Nefaram, so I know the core of it works. Which make sense given that SLP+ is, for now at least, still firing the original events. As for the individual API calls, I haven't made a pass to check. If the API is still there and hasn't changed, it *should* work, assuming they have agreed to keep it backward compatible.

 

As for animations specifically, everything SLT does goes through the SL API, so if that works with your animation, so should SLT (as far as I can tell anyway). If it's something related to tags and such, then it would come down to whether you have tagged it properly.

 

If that doesn't answer you question, please clarify.

[sirretinee]

On 9/4/2024 at 8:11 AM, libertyordeath said:

Feature request:

 

Expand the "IF ACTOR" condition to include "IS ACTOR 1" and "IS NOT ACTOR 1".

 

Right now the if-actor condition only allows testing for victim/aggressor in aggressive animations. The above two options would allow testing if an actor is the "receiver" or "giver" in an animation, regardless of aggressive or consensual. Yes, testing for actor slot 1 is not perfect for this, but it should work for 95% of cases, and it's super simple. Frankly, i'm not sure why this doesn't exist yet.

I'd like to double up on this request.
I have a handful of scripts that handle scaling but they're very restricted due to the lack of actor identification options.

For example: if an animation calls for a scaled up male, that's easy enough to do. Check for a male in any animation with appropriate tags and scale them up.
However! This immediately falls apart if the 'male' in this case is a female w/strapon or a futa character.
And that's really the crux of the issue. The scripts work, mostly, for M/F scenes, but fall apart when any multiples of the same gender are involved.

[hextun]

11 hours ago, sirretinee said:

I'd like to double up on this request.
I have a handful of scripts that handle scaling but they're very restricted due to the lack of actor identification options.

For example: if an animation calls for a scaled up male, that's easy enough to do. Check for a male in any animation with appropriate tags and scale them up.
However! This immediately falls apart if the 'male' in this case is a female w/strapon or a futa character.
And that's really the crux of the issue. The scripts work, mostly, for M/F scenes, but fall apart when any multiples of the same gender are involved.

 

Hi there!

 

To be clear, I added that with v14 (though I removed that download link since there was a problem that I corrected in v15). So pick any of sl_triggers15, sl_triggers16, or sl_triggers17 and you should be able to separately select:

"Is Player"/"Is Not Player"/"Other Is Player"/"Other Is Not Player"

and

"Humanoid"/"Creature"/"Undead"/"Partner Humanoid"/"Partner Creature"/"Partner Undead"

 

I would recommend going with v17 obviously, but maybe there is a reason you wanted to stick with an older version.

 

Here's the latest full CHANGELOG (since I've started updating and tracking):

 

17
	enhancement: removed SexLab hard dependency; you can now enjoy your sl(shhh)_triggers on your more vanilla Skyrim experiences
		existing functions should gracefully degrade or give best accurate answer (i.e. gender coming from base actor instead of sexlab if not available)
	enhancement: MCM Main page now displays SexLab status
	bugfix: fixed a bug in the MCM trigger cleanup code

16
	enhancement: added keymapping as an event; you can now bind keymappings to, as usual, up to 3 command files
		also allows for modifier use
		also allows for Dynamic Activation Key use per trigger
	enhancement: events will only be registered for if triggers exist that use them; if you do not hook any SexLab events, they will not be registered
		registration will update if you update the MCM
	change: lots of refactoring, technically some performance improvements but I haven't done timings so it's mostly my instinct, some general code cleanup (mostly due to mess of my own making)
	change: event id values (0 for SLStart...) are now 1 higher (1 for SLStart) to make the MCM behave more nicely; this should get converted automatically
	change: started adding some non-trigger values into settings.json, currently to track version; this is to help allow for settings updates in the future
	

15
	enhancement: improved "top of the hour" updategametime processing
	enhancement: variables can be any "$<non-negative-int>"
		["set", "$42", "life, the universe, and everything"]
		is now valid
	enhancement: global variables can be any "$g<non-negative-int>"
		["set", "$g42", "life, the universe, and everything"]
		is now valid
	fixed bug: fixed race condition when running multiple commands from one trigger
	change: renamed operation "actual_hours_since_last_top" to "toh_elapsed_time"
		"actual_hours_since_last_top" redirects to the new functionality for now
	

14
	split "if_race" into "if_race" and "if_player"
		you will likely need to update any triggers that relied on "if_race" previously
		existing "if_race" values will not be automatically updated and you will probably see:
			if you had...			then you will now have until you edit it...
			Player					Undead
			Not Player				Partner Humanoid
			Undead					Partner Creature
			Partner Humanoid		Partner Undead
			Partner Creature		??
			Partner Player			.. crabs??
			Partner Not Player		.. the void of space??
			Partner Undead			Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.
			
		"if_race" now offers:
			Any
			Humanoid
			Creature
			Undead
			Partner Humanoid
			Partner Creature
			Partner Undead
			
		"if_player" offers:
			Any
			Player
			Not Player
			Partner Player
			Partner Not Player

13
	added event handling for "top of the hour" (i.e. on the 'o'clock for each in-game hour, with the player as $self)
	added "global" variables: "$g0" through "$g9"; accessible across scripts, retained across executions
	added new operations:
		actor_worninslot
		actor_wornhaskeyword
		actual_hours_since_last_top

 

EDIT: Removed the empty reference to v18; I haven't released a v18.

 

Edited April 11, 2025 by hextun

[MannySauce]

Thanks for updating this, are you open for function requests?

[kamithemoon]

Horray for updates!

 

I don't suppose someone has examples of where this mod really shines? I can't really make heads or tails of it myself so I'm just using it for 4 things:

 

1. To display partner's stats during sex (because I like to see the numbers drain via succubus mods)

2. To reset facial expressions after sex (because otherwise it glitches)

3. For the cum alchemy mod to get cum vials after orgasm

4. Equipping ZAZ cum effects

 

It looks like you can set hundreds of triggers but I've only ever really used these 4.  Are there super cool things I'm missing?

Edited April 11, 2025 by kamithemoon

[sirretinee]

9 hours ago, hextun said:

 

Hi there!

 

To be clear, I added that with v14 (though I removed that download link since there was a problem that I corrected in v15). So pick any of sl_triggers15, sl_triggers16, or sl_triggers17 and you should be able to separately select:

"Is Player"/"Is Not Player"/"Other Is Player"/"Other Is Not Player"

and

"Humanoid"/"Creature"/"Undead"/"Partner Humanoid"/"Partner Creature"/"Partner Undead"

I'm not the best with this kind of scripting so bear with me on this one.
Apologies for the wall of text, i'm trying to be as concise as possible.
How exactly would these apply... at all?
Does 'Is Player' specifically target the player character or does it target actor 1/2/etc.?
These look like they only trigger depending on who/what an actor is, not on the actor's position in an animation.

Let me bring up a random animation as an example:

It doesn't matter who or what actors in this example are (blue boxes), what matters is what position they are in (red boxes).
'actor1' could be anything, and it looks like you've given us ample tools to do things to an actor based on what 'actor1' is.
I'm not looking for what 'actor1' is, though, i'm just looking for if an actor in an animation is 'actor1'.

This is what i've got for my scaling script:

It runs on every animation involving a male (probably a better way to do this, again, bear with me).
This immediately fails if the 'bigguy' is not male. If both characters are female, nobody gets scaled.
Now I could just run the script under the same conditions except for females instead of males.
Except that'd scale both characters as they're both female (this is assuming the 'receiver' is female in both cases).
However, I could also have it check if the player is involved in the animation. If the PC is the intended 'giver' scale the player and not the parter.
Double however, if I wanted to swap positions and have the PC be the 'receiver' in an animation, i'd need to somehow run a separate trigger for scaling the player partner ('giver') without triggering the other player-scaling trigger.
Triple however, both of those also fall apart if the two actors are npcs.
It's all just a whole lotta hooplah to figure out who is in what slot and what to do with them when the solution we're seeking is to just apply the scale to, in this case, the giver, AKA actor2.

TLDR: Is an actor a nord? Werewolf? Male, female, or futa? Player character or NPC? Purple or green? Stormcloak or Imperial? Milk-drinker or mead enjoyer? Irrelevant.
All we want to know is if they're actor1 or actor2 (or actor3/actor4/etc.).
As the guy I quoted suggested, an expansion on the 'if actor' selection in the MCM also had options for specific animation slots is what we're looking for.

[hextun]

17 hours ago, MannySauce said:

Thanks for updating this, are you open for function requests?

I am but I'm in the middle of a big overhaul. What did you have in mind?