Jump to content

Recommended Posts

Posted
21 minutes ago, c_harlock125 said:

Thanks, that made it.

What´s the difference between them ?

 

I was going to direct you to the fine wiki I've been working on.

 

But the wiki... it is not fine. 

 

I'll go ahead and answer directly but I intend to properly flesh out the wiki docs. I really thought I had... anyway...

 

 

The &= is for string comparison. It goes back to the fact that, under the hood, all the variables are strings. So when you compare, if you don't want it to do string comparisons, which would give different results from numeric comparisons, you have to use the appropriate operator.

 

Fotogen's documentation was much better about laying out the operators and some semantics of the language. I need to fix up the wiki in that regard.

Posted

v117 changelog

    Savegame compatibility: tested succesfully with an update from v116
    MAJOR enhancement: running scripts should now resume on loading a save (you can have suuuuuper long-running scripts now; theoretically lifetime)
    MAJOR enhancement: new Core event: OnNewSession (fires at the start of a new game and each time you load a save; provides a unique sessionId for each session)
    enhancement: new modevent published ("_slt_event_slt_on_new_session_"), fires at the start of a new session (i.e. at start of new game and after each save load)
    enhancement: added function in API to retrieve the event name
    enhancement: actor_getscale/actor_setscale
    bugfix: Top of the Hour events were not respecting Chance
    bugfix: sl_triggersAPI.psc.headeronly not valid
    change: removed the roughly 4 second (technically 3.9 second) additional delay and have sacked the ones responsible for it

 

Although I *had* done a lot of work to create isolated "heaps" for each script to run without conflicting with others, it wasn't perfect. Plus, I really wanted the scripts to be able to pick back up where they left off after a save, because while SLT started with SexLab events in mind, which understandably have a short shelf life and don't typically involve a save in the middle, with the expanded feature set the possibility of wanting longer running (or even lifetime) scripts is present and needed proper support.

 

This release aims to provide that support.

 

You also now have access to a new Core event "OnNewSession". Not only does SLT fire that as a mod event (so if you wanted you could hook it in your own mod), but of course it is available for you to run scripts against. It fires once at the start of each save session. Once at game creation (which, unfortunately, is likely to start running in the alternate start zones) and once each time you load a save. Creating a new save during a session does nothing; it's not a new session until it is loaded. Additionally, the event itself will send you a sessionId, global and unique per session (i.e. any object requesting sl_triggers_internal.GetSessionId() will get the same value as any other object, but different from the previous session).

 

In other news: man bites dog, dog bites self, man gets jealous, story at 11.

Posted

I'm still on v115, bumped into an issue though. I don't know if bug or user error, but I cannot make 'actor_say' work.

Am I doing this right?

actor_say $partner "skyrim.esm:049500"

Should result in a male Argonian saying "Yield, and I may still show mercy!".
The rest of the command it is in runs fine, it passes the valid $partner check and the debug isn't saying the FormID doesn't exist. Am I grabbing the wrong FormID?

Posted (edited)
3 hours ago, MannySauce said:

I'm still on v115, bumped into an issue though. I don't know if bug or user error, but I cannot make 'actor_say' work.

Am I doing this right?

actor_say $partner "skyrim.esm:049500"

Should result in a male Argonian saying "Yield, and I may still show mercy!".
The rest of the command it is in runs fine, it passes the valid $partner check and the debug isn't saying the FormID doesn't exist. Am I grabbing the wrong FormID?

 

Okay, here's what I've turned up about Topics.

 

First, I have no idea what the actor_say function should actually do :) ; the actor_say command was ported in from v12; I didn't create it. Moreover, although most of the functions added were documented, this one wasn't. You can see that my "documentation" for actor_say is pretty generic.

 

So I took a look and found a couple of links of interest:

 

- https://ck.uesp.net/wiki/Topic
https://ck.uesp.net/wiki/Say
https://ck.uesp.net/wiki/Say_-_ObjectReference

 

So for your example, you wanted to use:

 

    actor_say $self "Skyrim.esm:49500"

 

FormID 00049500 is one INFO entry underneath the Topic type DIAL with FormID 00046648.

 

According to the Topic documentation, what *should* happen is you feed it "Skyrim.esm:00046648" and it picks the Topic, then starts running down all of the INFO entries until it finds one that matches all of the INFO entry's attached Conditions.

 

In your case, 00049500 is pretty far down the list and, as you say, requires the target be an NPC, not the Player, and a Male Argonian. Target in this case being the Actor doing the speaking, i.e. $self.

 

So if your script, at that point, is running against a target of a "Male Argonian NPC" and none of the previous INFO records matched current conditions, then the following would work:

 

    ; 0x00046648
    ;    288,328
    actor_say $self "Skyrim.esm:288328"

 

Now, I mentioned the other links because the actual API interface is:

 

    ObjectReference
    Function Say(Topic akTopicToSay, Actor akActorToSpeakAs = None, bool abSpeakInPlayersHead = false) native

 

Keep in mind, an Actor *is* an ObjectReference and currently I implement by first resolving your target actor and then using that as the object calling Say. i.e. something like:

 

    $topicForm = Game.GetFromFromFile(topicFromString) as Topic
    $self.Say($topicForm)


  
So again, if $self isn't a "Male Argonian NPC", your call won't work.

 

What I don't know is could I just always use something like:

 

    $player.Say($topicForm, $self, true)

 

There was a line of code to that effect but it was commented out and would have only run when the speaker was the player and you were in freecam. As such I suspect (and based on the parameter name alone) that it's just going to try to do the same thing but give it the echoey effect like with the Psijic dude is time-stop-chatting with you.

 

Thing is, I still think you might need a "Male Argonian NPC" to reference. 

 

Now... if it turns out you *are* targeting $self as a "Male Argonian NPC" (I'm getting the hang of typing that with the double quotes, watch) "Male Argonian NPC" and were aware of the DIAL/Topic/INFO-conditions-checkdown thingy then the problem is just that you needed to a) reference the actual DIAL/Topic and b) convert it to decimal (until I get around to doing the hex conversion automatically if needed).

 

A word about decimal vs hex formatted FormIDs

My original edit said you had to use a decimal conversion instead of hex. That is incorrect. As long as you provide a number that has a preceding "0" it will attempt to convert from hex to integer. I'm now going to go forget I've learned how to quickly use Calc.exe.

 

Edited by hextun
Edit to correct the bit about requiring decimal(non-hex) FormIDs
Posted

Also, quick add, it means I goofed up on the implementation when I split SexLab and non-SexLab versions. The SexLab version basically works to spec, the comment about "not working on the player" notwithstanding; that was more a warning based on a misinterpretation of what I saw in the original code. The more egregious issue is in the non-SexLab version which actively restricts use by the player. So I'll be at least fixing these and, honestly, I'm not entirely sure why the original restriction was in place (i.e. not allowing it if called for the player during SexLab freecam). I may just remove the restrictions altogether and collapse back to the base version and fix it. Regardless, the rest of the notes stand.

Posted (edited)

Aaah ok so I DID mess up, gotta grab the parent topic, not the line.

So does this mean there is no way to play a specific voice line if multiple in a topic meet all their conditions, they'll just get picked randomly? I can work around this, sure.

 

Also you mentioned converting the FormID? I'm just rawdogging the FormID straight from xEdit, it seems to work. (actor_say now too, thanks.)

 

EDIT: I took too long to type this, again!

Edited by MannySauce
bro
Posted

v118 changelog:

 

    Savegame compatibility: tested succesfully with an update from v117
    Savegame compatibility: SCRIPT-BREAKING if using the old "$g" style global variable names
        Shipped scripts in the 'sl_triggers/commands' subfolder have been updated
    MAJOR enhancement: variable names, i.e. not just numbers
        $<any-non-breaking-characters> - local variables
        !<any-non-breaking-characters> - global variables
        Yes, this means that any existing scripts you have written that make use of the previous "$g" global variable approach is now actually referencing local variables
    bugfix: SLT.actor_say not working if self is player

 

So, ah... this would now be a valid script. Enjoy your weekend. :)

 

; rnd_list "skyrim.esm:216158" "skyrim.esm:853342" "skyrim.esm:181082" "skyrim.esm:329930" "skyrim.esm:201531" "skyrim.esm:201532" "skyrim.esm:1079946" "skyrim.esm:901490" "skyrim.esm:758231"
; 34c5e   Ale
; d055e   Stros M'Kai Rum
; 2c35a   Black-Briar Mead
; 508ca   Honningbrew Mead
; 3133b   Alto Wine
; 107a8a  Mead with Juniper Berry
; dc172   Balmora Blue
; b91d7   Cyrodilic Brandy

set $ale                    "skyrim.esm:034c5e"
set $strosMkaiRum           "skyrim.esm:0d055e"
set $blackBriarMead         "skyrim.esm:02c35a"
set $honningbrewMead        "skyrim.esm:0508ca"
set $altoWine               "skyrim.esm:03133b"
set $meadWithJuniperBerry   "skyrim.esm:0107a8a"
set $balmoraBlue            "skyrim.esm:0dc172"
set $cyrodilicBrandy        "skyrim.esm:0b91d7"

rnd_list $ale $strosmkAiRuM $blaCkBrIaRMead $honningbrewMead $altoWine $meadWithJuniperBerry $balmoraBlue $cyrodilicBrandy
set $hairOfTheDog $$
item_adduse $self $hairOfTheDog 1 0

 

Posted
11 minutes ago, hextun said:

v118 changelog:

 

    Savegame compatibility: tested succesfully with an update from v117
    Savegame compatibility: SCRIPT-BREAKING if using the old "$g" style global variable names
        Shipped scripts in the 'sl_triggers/commands' subfolder have been updated
    MAJOR enhancement: variable names, i.e. not just numbers
        $<any-non-breaking-characters> - local variables
        !<any-non-breaking-characters> - global variables
        Yes, this means that any existing scripts you have written that make use of the previous "$g" global variable approach is now actually referencing local variables
    bugfix: SLT.actor_say not working if self is player

 

So, ah... this would now be a valid script. Enjoy your weekend. :)

 

; rnd_list "skyrim.esm:216158" "skyrim.esm:853342" "skyrim.esm:181082" "skyrim.esm:329930" "skyrim.esm:201531" "skyrim.esm:201532" "skyrim.esm:1079946" "skyrim.esm:901490" "skyrim.esm:758231"
; 34c5e   Ale
; d055e   Stros M'Kai Rum
; 2c35a   Black-Briar Mead
; 508ca   Honningbrew Mead
; 3133b   Alto Wine
; 107a8a  Mead with Juniper Berry
; dc172   Balmora Blue
; b91d7   Cyrodilic Brandy

set $ale                    "skyrim.esm:034c5e"
set $strosMkaiRum           "skyrim.esm:0d055e"
set $blackBriarMead         "skyrim.esm:02c35a"
set $honningbrewMead        "skyrim.esm:0508ca"
set $altoWine               "skyrim.esm:03133b"
set $meadWithJuniperBerry   "skyrim.esm:0107a8a"
set $balmoraBlue            "skyrim.esm:0dc172"
set $cyrodilicBrandy        "skyrim.esm:0b91d7"

rnd_list $ale $strosmkAiRuM $blaCkBrIaRMead $honningbrewMead $altoWine $meadWithJuniperBerry $balmoraBlue $cyrodilicBrandy
set $hairOfTheDog $$
item_adduse $self $hairOfTheDog 1 0

 

 

Is that the named variables? Hell yeah.

Posted
14 minutes ago, MannySauce said:

 

Is that the named variables? Hell yeah.

 

Indeed. :)

 

I have also updated the "Scripts" page on the wiki, to clean it up, to add more info about the operators, to update it about the variable names... and to talk about some potential chaos.

 

 

$self, $player, $actor, $partner, $partner2, $partner3, $partner4

 

These special variable names are now sitting squarely in your brand new variable space. Except they aren't. But if you let yourself realize they aren't it could cause confusion.

 

Take the following:

 

set $1 "Health"
av_restore $self $1 100

 

Works a charm. But now $self is technically a valid variable name, which means there is nothing stopping you from doing this:

 

set $self "Health"
av_restore $self $self 100

 

And that will work too! It's because the position of the argument *tends* to drive how the function treats it, and *everything* starts off in an SLTScript as a string. So when it sees "$self" in the slot that it knows to use ResolveActor() for, it goes and grabs the same "$self" Actor it always has. But now when it goes for the amount, instead of choking on "$self" it just assumes it's another variable and goes and fetches it. It does *not* in *any way* have *anything* to do with the special "$self" variable that refers to an Actor. It would be, in the sample above, your temporary little slice of chaos.

 

I would recommend against this because as you can imagine it could get pretty confusing reeeeeeeaally quickly. 

 

Now, why didn't I change "$self" and friends? I wish that I could but if I did *that* right now it would break a LOT of scripts. And until that choice is made, technically you *can* use the variable names too, just, you know... *makes googly eyes*CHAOS. 

Posted

FYI, preliminary tests look promising.

 

I am close to (guesstimating) 85+% coverage of Form, ObjectReference, and Actor, for creating bindings from SLTScript to Papyrus script.

 

I'm creating a handful of very large, but ultimately very simple, sub-function style wrappers. They are themed by object type (e.g. Form, ObjectReference, Actor) and function signature.

 

Actions - functions that take no parameters and return no results

Getters - functions that take no parameters but return a result

Consumers - functions that take one or more parameters but return no results

Functions - functions that take parameters and return a result

 

So there will be:

form_doaction
actor_doaction
form_dogetter
actor_dogetter
form_doconsumer
actor_doconsumer

 

and so on

 

For example:

actor_dogetter GetEquippedShield
set $shieldFormID $$
form_consumer $shieldFormID SetWeight 0.1

 

Assuming that that works out to a valid operation (i.e. I don't even know if you are allowed to just change a weight like that), then... well... that's what would happen. Um... yeah... not my most professorial.

 

actor_dogetter GetEquippedShield is returning the FormID of the equipped shield. form_consumer SetWeight calls Form.SetWeight(float) on the shield Form object. Maybe that's valid, maybe it's not. Welcome to Creation Kit Papyrus script development. I'll be placing links to the creation kit script API docs in my documentation. I won't be replicating all of that.

 

With this approach, you should be able to do a LOT more scripting.

 

So... heads up on a big drop coming in the next few days. :)

Posted

New drop, v119. It should be save game compatible as for the most part it is just introducing new functionality.

 

But oh, the functionality.

 

I am introducing 12 new functions you can use in your scripts, 4 each for 3 object types, Actor, ObjectReference, and Form. They are

  • Actor
    • actor_doaction
    • actor_dogetter
    • actor_doconsumer
    • actor_dofunction
  • ObjectReference
    • objectreference_doaction
    • objectreference_dogetter
    • objectreference_doconsumer
    • objectreference_dofunction
  • Form
    • form_doaction
    • form_dogetter
    • form_doconsumer
    • form_dofunction

The four functions refer to the four types of functions on that object.

  • Actions - no parameters, no return value
  • Getter - no parameters, has return value
  • Consumer - has parameters, no return value
  • Function - has parameters, has return value

So if you use actor_doaction, you know you just need to provide the target Actor and you will not have a return value, etc.

 

Functions that return objects derived from Form will return the FormID, a simple integer. If you then pass that value to a function that expects a Form, it calls Game.GetForm(int) and retrieves the Form. So this means you should be close to a first class citizen when it comes to these Papyrus functions, which should also significantly increase the scope of what you can do.

 

In the future, I can continue to add bindings for things like Armor, Weapon, Spell, MagicEffect, and so on.

 

I. Have. Not. Exhaustively. Tested. This.

 

Too much work and I'm not paid neeearly enough to actually do comprehensive testing. That said, if you see something, say something and I will be happy to fix things. But as you can imagine, this is tedious to implement. :) (If anyone is inclined to help, I'm open to pull requests *hint*hint*)

 

But I did put a simple test in the regression test script. Two actually.

 

Anyhow, time for a walk. Have fun folks. :)

Posted

If you already downloaded v119, you probably want to redownload and update. I accidentally left some very chatty debug message output in sl_triggersCmd.pex and have updated the .zip to remove it. Sorry about that. :)

Posted

Just did a v115>v116>v117>v118 upgrade and "call" seems to have been broken somewhere after v115.

All instances of "call" in my commands are just glossed over, while the rest of the command after them run fine.

 

That's the only issue I've run into, the named variables are working great - so much easier to keep track of things. 👍

 

And since you brought up possible shenanigans with "$self" earlier due to variable naming, what about "@self"?

Maybe "@RefID" too for non-SL stuff. 🫣

Posted
4 hours ago, MannySauce said:

Just did a v115>v116>v117>v118 upgrade and "call" seems to have been broken somewhere after v115.

All instances of "call" in my commands are just glossed over, while the rest of the command after them run fine.

 

That's the only issue I've run into, the named variables are working great - so much easier to keep track of things. 👍

 

And since you brought up possible shenanigans with "$self" earlier due to variable naming, what about "@self"?

Maybe "@RefID" too for non-SL stuff. 🫣

 

Seriously, if I were earning money on this I would hire you for testing. I have been chasing down that call bug just about since I dropped 119. :)

 

It's funny because at first I got tired of getting hung up on the string vs number comparison stuff, so I decided I would make a quick fix for that. Then, while I was doing that, I had this crazy idea for something called "set resultfrom" and I implemented that. Then I ran my regression test and things were fine. Then I fixed one other thing and suddenly call wasn't working. For hours I thought it was my comparison fix.

 

Well it turns out it WAS my comparison fix. Also the call logic was busted when I changed how I was managing the callstack.

 

Anyhow... I got it all working, and was going to bundle it up and drop v120 but wanted to check to see if any new bugs had been reported that I ought to try to pop in first, but  apparently not. So... give me a few minutes... y'all are gonna like this one.

Posted

Okay, introducing v120. The changelog, if you please:

 

    Savegame compatibility: tested succesfully with an update from v119
    bugfix: callstack corruption could occur in some scenarios; fixed
    bugfix: BUG IN THE REGRESSION TEST! yuck
    bugfix: parser will no longer assume "!=" is a global variable named "="
    bugfix: PARTIAL: strings starting with "$" will now work IF THEY HAVE A SPACE IN THEM. quirk of the whole "variables start with $, everything is a string, resolve all the things!" design
        workaround: if you need a string with no spaces that starts with a "$"... you can can use 'cat $food "$" "therestofthestring"'; ugly, I know, needs some thinking
    enhancement: added additional equality operator, "==" because I got tired of my brain trying to stop me from not typing it
    enhancement: you should be able to safely mix "==", "=", and "&=" (as well as, on the opposite side, "!=" and "&!=")
        if the two values "can be" evaluated as numbers for equality, they will be, otherwise it will perform string equality
    enhancement: sl_triggers_internal.SafeSmartEquals(string, string) is the native logic wrapper (mostly for speed)
    enhancement: "set <variable> resultfrom <function.....>"
        example:
            set $actorName resultfrom actor_name $player
        it's what we all do anyway

 

Okay, so, it fixes the callstack corruption bug, so "CALL" should be working again.

 

I also updated the equality comparison so that "=", "==", and "&=" are all equivalent, regardless of what you put in your variable, same with "!=" and "&!=". .. .. Oh... you noticed "=="? Yeah, I miss that little guy, and so does my muscle memory. 

 

I also found and fixed some bugs in the regression tests. The nature of the bug is also why the CALL bug was missed in my regression tests and actually goes back to why I wanted to make numeric and string equality no longer different. When I wrote the tests for CALL, I used a string variable. Not sure why really but I did. Well, when I was comparing the output from the global variables being set all over the place, guess which comparator I used? If you guess a moon rocket or an ice cream sundae you are very strange. I was using the numeric equality operator for a string comparison. Strings that are not actually a number resolve to 0 or 0.0 (int or float depending). So when you compare two strings with numeric equality they are always equal. Now, at first, CALL really was working. But when it stopped working, the regression test wasn't reporting on it.

 

So... equality operators should now be fungible between numeric and string. I'm using the plugin for this, so there is also a new endpoint, "sl_triggers_internal.SafeSmartEquals(string, string)" if you want to use it.

 

There is also a funny little bug that technically has been around since I added "named variables". You couldn't have strings that started with a "$" because I would assume that was a variable. Well, I weakened that a bit... now if there is a space in it, it won't assume it is a variable name. So if you have "$this is a string" it will work, but if you have "$thisIsAString" it will still think that is a variable.

 

Right now I use a *VERY* basic approach to tokenization, specifically I do not differentiate between things you stuff into double quotes and things you don't, except that double quotes allow you to include white space that would ordinarily break a variable name. What I *ought* to do is treat double quoted strings as bare strings and *not* resolve them as variables, but that would also potentially affect existing scripts. Breaking changes and all.

 

 

Oh... oh that? "set resultfrom"? Oh that's... well sure, I'll show you.

 

; we all do this
actor_name $player
set $playerName $$

; but now, we can do this
set $playerName resultfrom actor_name $player

 

Should work for any function except built-ins. Obviously you want to use a function that actually returns something, though I suppose if you don't mind zeroing out your variable that works too.

Posted

How do you figure out one particular location's code?

For example let's say I want a trigger to happen inside winking skeever, how do i find the location code of that place to use for my sl trigger code?

Posted
1 hour ago, Fraying9981 said:

How do you figure out one particular location's code?

For example let's say I want a trigger to happen inside winking skeever, how do i find the location code of that place to use for my sl trigger code?

 

Well, you would need to look it up, either online (e.g. https://en.uesp.net/wiki/Skyrim:Places) or via something like CreationKit or through the console or other mods. You would need to find a suitable formID and use that when referencing the location.

 

That said, a formID for SLTScript has, until ... soon... required you to specify it in one of two (three I guess) formats:

 

Septims

  • "Skyrim.esm:0f" - modname:hex offset
    • "Skyrim.esm:15" - modname:decimal offset (pseudo-third?)
  • "0f" / "15" - you can specify an absolute value but now you are load order dependent

 

And I don't like that. I prefer editorIds and I suspect others do to. So I added "SafeFindFormByEditorId" to sl_triggers_internal and will allow you to just use (what I think are more readable) editorId strings instead of numbers. I have it queued up for v121 which could go out... whenever I suppose. I wonder sometimes if people dislike my update pace.

 

Anyway, so, in your case, take the Winking Skeever. https://en.uesp.net/wiki/Skyrim:The_Winking_Skeever says it has editorID "SolitudeWinkingSkeever", so once v121 rolls out, assuming I'm sure I can ship the feature, you could just use that. Understand, of course, that if multiple mods publish something with the same editorId, there is no guarantee that you will get the one you wanted or expected. Thus the relative modid is still the most accurate.

 

Unfortunately I have not found a reliable method to easily go from that (an editorID) to a hex formID, so, again until I'm happy with the editorId lookup and drop v121, you would need to take the editorID you found from UESP and look it up in something like SSEEdit or CreationKit to get the formID, or go to the in-game Skyrim console and use "help <editorID>".

 

I'll go take a walk for a bit and mull it over, run some tests when I get back. If everything checks out, I'll push v121 and then the answer to your question would just be:

 

"Just use the editorID and that will probably work in most cases"

Posted (edited)

How is the .json file itself supposed to be formatted for "json_getvalue" to work? I'm a bit lost and can't find an example.

 

And can "if" statements like "if $$ = 1 label" support gosub to run the subroutine?

Edited by MannySauce
additional question
Posted (edited)
20 minutes ago, MannySauce said:

How is the .json file itself supposed to be formatted for "json_getvalue" to work? I'm a bit lost and can't find an example.

 

And can "if" statements like "if $$ = 1 label" support gosub to run the subroutine?

 

Seriously @MannySauce, are you reading my journals? Listening at doors and around corners?

 

I am looking at adding the if support you mentioned as a next release; still investigating but I think it's doable. So... let me know what I'm supposed to work on next I guess. Saves me the trouble of thinking of it in advance to have you ask for it before I release it. :)

 

As for the .json formatting, it's the same formatting that the PapyrusUtil JsonUtil.* functions use. I had been shipping a test file for the json functions (if you updated you probably still have it, ZZ_test_jsonutil.ini) but removed it during a cleanup when I realized folks didn't need to see all of my goofy little Zb files. (fun fact: until a script is run, you can change it. So if you want to test but don't want to have to reload the game or SLT, make a bunch of scripts with generic names like, I don't know, Zb01.ini, Zb02.ini, and so on. Then modify 01, test it and if you don't like what you see, tab out, copy it into 02 with corrections, tab in, change the trigger, test, repeat. Welcome to part of my test kit.

 

I'm going to add the test back and also the test .json file it uses. Here is what it looked like after a run:

 

{
	"float" : 
	{
		"key1" : 87.0
	},
	"int" : 
	{
		"value1" : 23
	},
	"intList" : 
	{
		"somelist" : 
		[
			1,
			2,
			3,
			1
		]
	},
	"string" : 
	{
		"value1" : "this is a text string",
		"value2" : "48"
	}
}

 

Basically JsonUtil takes the type (int, int[], string, string[], etc.), and your key, and creates the value. 

 

There *are* functions in JsonUtil that let you work with paths directly; I make use of them for working with the -attributes.json files. But there are some caveats you have to be careful with when doing so. Much fun was had finding out about that. *shiver* *goosebumps*

 

And here are the contents of my "ZZ_test_jsonutil.ini" test suite for the json functions (which I will be adding back in the next release):

 

deb_msg "SLT Test: jsonutil"
util_getrealtime
set $9001 $$
deb_msg "Start realtime: " $9001
set $8000 0

goto begintestpath

[done]
deb_msg "SLT Test Script 2: End"
util_getrealtime
set $9002 $$
deb_msg "Ending realtime: " $9002
set $9003 $9002 - $9001
deb_msg "Elapsed realtime: " + $9003
deb_msg "Passed " $8000 " tests."
return




[begintestpath]
set $1 "../sl_triggers/commandstore/jsonutil_function_test"

jsonutil exists $1

if $$ = 1  existsworks
deb_msg "FAILED: exists :" $$ ":  :" $1 ":"
goto done


[existsworks]
inc $8000

jsonutil set $1 "key1" "string" "avalue"
if $$ = "avalue"  setworks
deb_msg "FAILED: set"
goto done


[setworks]
inc $8000

jsonutil has $1 "key1" "string"
if $$ = 1  hasworks
deb_msg "FAILED: has"


[hasworks]
inc $8000

jsonutil unset $1 "key1" "string"
if $$ = 1  unsetworks
deb_msg "FAILED: unset"
goto done


[unsetworks]
inc $8000

jsonutil has $1 "key1" "string"
if $$ = 0  hasalsoworks
deb_msg "FAILED: unset or has failed, still reports set"
goto done


[hasalsoworks]
inc $8000

jsonutil set $1 "key1" "float" "87"
if $$ = 87  setfloatworks
deb_msg "FAILED: set float :" $$ ":"
goto done


[setfloatworks]
inc $8000


jsonutil has $1 "key1" "string"
if $$ = 0  hasstillworks
deb_msg "FAILED: has failed, crossed the streams float and string?"
goto done



[hasstillworks]
inc $8000

jsonutil listclear $1  "somelist" "int"

jsonutil listadd $1  "somelist"  "int"  1
jsonutil listadd $1  "somelist"  "int"  2
jsonutil listadd $1  "somelist"  "int"  3
jsonutil listadd $1  "somelist"  "int"  1

jsonutil listcount $1 "somelist" "int"
if $$ = 4  listcountworked
deb_msg "FAILED: honestly, listclear, listadd, and listcount are all suspect"
goto done


[listcountworked]
inc $8000


jsonutil save $1

goto done

 

Edited by hextun
Posted
1 hour ago, hextun said:

 

Seriously @MannySauce, are you reading my journals? Listening at doors and around corners?

 

I am looking at adding the if support you mentioned as a next release; still investigating but I think it's doable. So... let me know what I'm supposed to work on next I guess. Saves me the trouble of thinking of it in advance to have you ask for it before I release it. :)

 

As for the .json formatting, it's the same formatting that the PapyrusUtil JsonUtil.* functions use. I had been shipping a test file for the json functions (if you updated you probably still have it, ZZ_test_jsonutil.ini) but removed it during a cleanup when I realized folks didn't need to see all of my goofy little Zb files. (fun fact: until a script is run, you can change it. So if you want to test but don't want to have to reload the game or SLT, make a bunch of scripts with generic names like, I don't know, Zb01.ini, Zb02.ini, and so on. Then modify 01, test it and if you don't like what you see, tab out, copy it into 02 with corrections, tab in, change the trigger, test, repeat. Welcome to part of my test kit.

 

I'm going to add the test back and also the test .json file it uses. Here is what it looked like after a run:

 

{
	"float" : 
	{
		"key1" : 87.0
	},
	"int" : 
	{
		"value1" : 23
	},
	"intList" : 
	{
		"somelist" : 
		[
			1,
			2,
			3,
			1
		]
	},
	"string" : 
	{
		"value1" : "this is a text string",
		"value2" : "48"
	}
}

 

Basically JsonUtil takes the type (int, int[], string, string[], etc.), and your key, and creates the value. 

 

There *are* functions in JsonUtil that let you work with paths directly; I make use of them for working with the -attributes.json files. But there are some caveats you have to be careful with when doing so. Much fun was had finding out about that. *shiver* *goosebumps*

 

And here are the contents of my "ZZ_test_jsonutil.ini" test suite for the json functions (which I will be adding back in the next release):

 

deb_msg "SLT Test: jsonutil"
util_getrealtime
set $9001 $$
deb_msg "Start realtime: " $9001
set $8000 0

goto begintestpath

[done]
deb_msg "SLT Test Script 2: End"
util_getrealtime
set $9002 $$
deb_msg "Ending realtime: " $9002
set $9003 $9002 - $9001
deb_msg "Elapsed realtime: " + $9003
deb_msg "Passed " $8000 " tests."
return




[begintestpath]
set $1 "../sl_triggers/commandstore/jsonutil_function_test"

jsonutil exists $1

if $$ = 1  existsworks
deb_msg "FAILED: exists :" $$ ":  :" $1 ":"
goto done


[existsworks]
inc $8000

jsonutil set $1 "key1" "string" "avalue"
if $$ = "avalue"  setworks
deb_msg "FAILED: set"
goto done


[setworks]
inc $8000

jsonutil has $1 "key1" "string"
if $$ = 1  hasworks
deb_msg "FAILED: has"


[hasworks]
inc $8000

jsonutil unset $1 "key1" "string"
if $$ = 1  unsetworks
deb_msg "FAILED: unset"
goto done


[unsetworks]
inc $8000

jsonutil has $1 "key1" "string"
if $$ = 0  hasalsoworks
deb_msg "FAILED: unset or has failed, still reports set"
goto done


[hasalsoworks]
inc $8000

jsonutil set $1 "key1" "float" "87"
if $$ = 87  setfloatworks
deb_msg "FAILED: set float :" $$ ":"
goto done


[setfloatworks]
inc $8000


jsonutil has $1 "key1" "string"
if $$ = 0  hasstillworks
deb_msg "FAILED: has failed, crossed the streams float and string?"
goto done



[hasstillworks]
inc $8000

jsonutil listclear $1  "somelist" "int"

jsonutil listadd $1  "somelist"  "int"  1
jsonutil listadd $1  "somelist"  "int"  2
jsonutil listadd $1  "somelist"  "int"  3
jsonutil listadd $1  "somelist"  "int"  1

jsonutil listcount $1 "somelist" "int"
if $$ = 4  listcountworked
deb_msg "FAILED: honestly, listclear, listadd, and listcount are all suspect"
goto done


[listcountworked]
inc $8000


jsonutil save $1

goto done

 

( I'm in your walls)

 

🫡 Thanks for the json examples, got it working now, but now I ran into an unrelated issue while testing (on v120).

 

I sat up a keymapped Core trigger to test my json_getvalue setup, but the following happened:

 

First keypress: "End" events triggered. 🤔
Second keypress: Nothing.
Third keypress: Nothing.
Fourth keypress: Keymap event finally triggered.

 

This happened when the trigger first got added to the save, I can save&load after doing the above and it works as expected from that point on with every keypress. At first I thought my save was being wonky again from updating, so I relaunched the game and started a new save from main menu with "coc riverwood" and I can't trigger keymapped Core triggers at all on the new save.

How is it inverted now, maaaaan. 😭

 

Posted
1 hour ago, MannySauce said:

( I'm in your walls)

 

🫡 Thanks for the json examples, got it working now, but now I ran into an unrelated issue while testing (on v120).

 

I sat up a keymapped Core trigger to test my json_getvalue setup, but the following happened:

 

First keypress: "End" events triggered. 🤔
Second keypress: Nothing.
Third keypress: Nothing.
Fourth keypress: Keymap event finally triggered.

 

This happened when the trigger first got added to the save, I can save&load after doing the above and it works as expected from that point on with every keypress. At first I thought my save was being wonky again from updating, so I relaunched the game and started a new save from main menu with "coc riverwood" and I can't trigger keymapped Core triggers at all on the new save.

How is it inverted now, maaaaan. 😭

 

 

Deleted the previous response.

 

Would you mind pasting your script?

 

Have you tried "Reset SLT"? I don't see how things could be busted on a fresh save (and therefore how a reset could help), but do give it a shot.

 

And lastly, if you're doing fresh saves, would you also consider uninstalling/reinstalling the mod altogether? Including removing existing folders, triggers, etc.? Again, the fact it doesn't work on a fresh save with what sounds like the most basic of configurations is what's baffling me, so I'd like to know if perhaps there is something stuck in the filesystem. Back up the folders and files, of course, since they include your customizations.

Posted (edited)
4 hours ago, hextun said:

 

Deleted the previous response.

 

Would you mind pasting your script?

 

Have you tried "Reset SLT"? I don't see how things could be busted on a fresh save (and therefore how a reset could help), but do give it a shot.

 

And lastly, if you're doing fresh saves, would you also consider uninstalling/reinstalling the mod altogether? Including removing existing folders, triggers, etc.? Again, the fact it doesn't work on a fresh save with what sounds like the most basic of configurations is what's baffling me, so I'd like to know if perhaps there is something stuck in the filesystem. Back up the folders and files, of course, since they include your customizations.

 

No luck then? Damn.

Here's my script:

 

rnd_list "value1" "value2" "value3" "value4" "value5" "value6" "value7" "value8"
	set $GetValue $$
msg_console "DEBUG: Trying to get " $GetValue
json_getvalue "../sl_triggers/commands/DataTable.json" int "$GetValue"
	set $ReportValue $$
msg_console "DEBUG: Got " $ReportValue

 

I went ahead and disabled all SL Trigger related mods in MO2, downloaded a fresh copy of v120, went ingame on a new save and;

 

- Waited around until all notifications and setup console log spam had stopped.

- Created the trigger, Core keymap no modifier no DAK command 1.

- Pressed the bound key, nothing.

- Waited a few seconds, pressed again. x10

- "Reset SL Triggers" and did x10 again.

- Ran the ingame SexLab install just in case.

- Did the x10 again.

- "Reset SL Triggers" and did x10 again.

 

So far, "msg_console" never printed.

 

- Gave up, saved game, exit game.

- "Hold up" moment, relaunched game, loaded save.

- Pressed the bound key, it now works on every key press from now on. 🤪

 

Possibly tangled up with "OnNewSession" code?

 

Still don't know why it does the "End event > nothing > nothing > works" thing when I've got other triggers on my current save.

EDIT: Ok this ^ issue seems unrelated to my Core unresponsiveness, it was just perfectly timed during my tests.

Edited by MannySauce
Posted
3 hours ago, MannySauce said:

 

No luck then? Damn.

Here's my script:

 

rnd_list "value1" "value2" "value3" "value4" "value5" "value6" "value7" "value8"
	set $GetValue $$
msg_console "DEBUG: Trying to get " $GetValue
json_getvalue "../sl_triggers/commands/DataTable.json" int "$GetValue"
	set $ReportValue $$
msg_console "DEBUG: Got " $ReportValue

 

I went ahead and disabled all SL Trigger related mods in MO2, downloaded a fresh copy of v120, went ingame on a new save and;

 

- Waited around until all notifications and setup console log spam had stopped.

- Created the trigger, Core keymap no modifier no DAK command 1.

- Pressed the bound key, nothing.

- Waited a few seconds, pressed again. x10

- "Reset SL Triggers" and did x10 again.

- Ran the ingame SexLab install just in case.

- Did the x10 again.

- "Reset SL Triggers" and did x10 again.

 

So far, "msg_console" never printed.

 

- Gave up, saved game, exit game.

- "Hold up" moment, relaunched game, loaded save.

- Pressed the bound key, it now works on every key press from now on. 🤪

 

Possibly tangled up with "OnNewSession" code?

 

Still don't know why it does the "End event > nothing > nothing > works" thing when I've got other triggers on my current save.

 

A couple of other questions then:

 

- after queueing a few up, could you go into the console, "prid player", and (hopefully you have... Console PlusPlus? Extended Console? the one that you can hit tab a few times and see nice menus with current effects and such)... if you have that, could you take a look and see how many (if any) "Trigger" effects you have on you?

- on your "End-nothing-nothing-nothing-works" save, can you try "Reset SLT" to see if that knocks it loose?

- and... I hate to ask... but I just went through, as an exercise, starting completely over with a brand new profile for an MO2 based modlist... scorched earth, no prior install of anything SLT related ever, so nothing even to delete... installed v120, set up a GiveGold10 hotkey, and it worked... can you try that as well? I'd like to try to isolate the difference between "a setup where it launches" and "a setup where it does not".

- other option, if you have the stomach for it, would be to go back to a prior save/prior version (if you don't have the downloads, I can recreate one quickly enough... I take them down when I fix a bug because I'd rather folks not download buggy copies)

Posted
1 hour ago, hextun said:

 

A couple of other questions then:

 

- after queueing a few up, could you go into the console, "prid player", and (hopefully you have... Console PlusPlus? Extended Console? the one that you can hit tab a few times and see nice menus with current effects and such)... if you have that, could you take a look and see how many (if any) "Trigger" effects you have on you?

- on your "End-nothing-nothing-nothing-works" save, can you try "Reset SLT" to see if that knocks it loose?

- and... I hate to ask... but I just went through, as an exercise, starting completely over with a brand new profile for an MO2 based modlist... scorched earth, no prior install of anything SLT related ever, so nothing even to delete... installed v120, set up a GiveGold10 hotkey, and it worked... can you try that as well? I'd like to try to isolate the difference between "a setup where it launches" and "a setup where it does not".

- other option, if you have the stomach for it, would be to go back to a prior save/prior version (if you don't have the downloads, I can recreate one quickly enough... I take them down when I fix a bug because I'd rather folks not download buggy copies)

 

Fresh profile, just SLT and the requirements to get into the MCM and setup triggers:

 

- Tested v120-119-118-117-116 on new games through "coc riverwood" from main menu.

- Set up a fresh Core keymap trigger on each version and clicked it 10 times.

- v120-119-118-117 failed to give me gold and caused Trigger01-10 to be stuck on my character. v116 was a success.

- Saving and loading caused the stuck Trigger02-10 on v120-119-118-117 to finish and give me gold, Trigger01 was stubborn and hung around.

 

I've got nothing on my end-nothing-nothing-works issue. I did try to reset early on to no avail and the more I've been trying to solve it, the more it seems to break. Like, it's haunting my previous saves now where it hadn't even happened yet. 😭

I'm convinced I've broken one of my scripts, but I'm not finding anything. Time for a clean slate. When I've got the energy.

Posted

Ok I'm fairly sure my end-nothing-nothing-works issue is another save game incompatibility. On a new game it's not present, but there still is the whole "nothing works until you save and reload" during that.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...