SES - Slaverun Enforcer Standsalone

[Yuuen]

Upgraded from 0.4 to 0.5 It now keeps enslaving my followers, kept trying to free them but it doesn't stick and enforcer doesn't seem to react to the player at all, going to downgrade.

Edited October 26, 2022 by Yuuen

[Leoosp]

@kaxat Are the scripts from this modification based on version 2 or version 3 of Slaverun Reloaded, especially with the latest version(s) of this mod?

[kaxat]

@Leoosp Version 3 Beta 1.

 

@Yuuen Those do not sound like known bugs. My guess is that should double check your settings after updating. Follower enslavement changed a bit. The followers are now solely subject to your strip settings unless you check Followers are NPCs too.

 

@gollum007 @xyzxyz What version of the following are you running: Skyrim, SexLab, PapyrusUtils ?

[Leoosp]

3 minutes ago, kaxat said:

@Leoosp Version 3 Beta 1.

 

@Yuuen Those do not sound like known bugs. My guess is that should double check your settings after updating. Follower enslavement changed a bit. The followers are now solely subject to your strip settings unless you check Followers are NPCs too.

 

@gollum007 @xyzxyz What version of the following are you running: Skyrim, SexLab, PapyrusUtils ?

 

Thank you for your reply. Anyway, from what SlaveTats pack does the tattoo on the slave's back come from, in the included screen shots please? Also has this been tested against, EFF I know Slaverun Reloaded isn't compatible. But are wondering where that modification's incompatibility of EFF and multiple follower mods lies, if it's the enforcer is it possible for this to be fixed with you modification?

[kaxat]

@Leoosp You're welcome.

I believe the tattoo comes from a pack called CN 17. Something like that. A bunch of people have asked. I almost need to put that in a FAQ. ?

 

What incompatibility have you experienced? I have been running EFF + Slaverun for the past year. I do not recall any issues. Perhaps there were some Story options that did not detect your follower? There are some story branches I never played. But the Enforcer should be fully EFF compatible.

[xyzxyz]

44 minutes ago, kaxat said:

 

@gollum007 @xyzxyz What version of the following are you running: Skyrim, SexLab, PapyrusUtils ?

Skyrim: LE newest 1.9.32.0  . Sexlab 1.62, papyrus 3.3

[kaxat]

Hmm, I wonder if this is an LE issue. Has anyone got v0.5 game to load without JSON errors?

Unfortunately that is a very old version of PapyrusUtils. And that mod author is not backporting fixes to LE. But they have done a bunch of JSON patches since v3.3. Only released for Special Edition and newer though.

[Leoosp]

8 minutes ago, kaxat said:

Hmm, I wonder if this is an LE issue. Has anyone got v0.5 game to load without JSON errors?

Unfortunately that is a very old version of PapyrusUtils. And that mod author is not backporting fixes to LE. But they have done a bunch of JSON patches since v3.3. Only released for Special Edition and newer though.

 

@kaxat This could be due to the different format of addresses for the formID's used if this is to do with the outfits jsons. The reason being the json's used by PapyrusUtil I think are different between LE and SE. Specifically the LE of Skyrim is utilising decimals for its PapyurusUtil json FormIDs so need to be converted from hexadecimal, while SE of Skyrim is natively hexadecimal. Since you started off on SE this means your formID json files are in the wrong format for LE use, they need to be converted. So therefore, an update (or attached) converted json files for LE, followed by inclusion in a future update.

Edited October 26, 2022 by Leoosp

[Yuuen]

7 hours ago, kaxat said:

 

@Yuuen Those do not sound like known bugs. My guess is that should double check your settings after updating. Follower enslavement changed a bit. The followers are now solely subject to your strip settings unless you check Followers are NPCs too.

What settings specifically affect that? Because as far as I could tell after checking settings several times when the issue came up I couldn't see what I would've missed to cause that.

[TBDM]

14 hours ago, kaxat said:

@TBDM The Slaveguards will forcegreet you at the interval you select. I think 12hr is the default. The forcegreet is not something I have touched. More or less the same as vanilla Slaverun.

That is the guard I am referring to in my original post. If there are multiple female NPCs around then the greet/strip/blowjob Slaveguard never gets a chance to forcegreet the player as he just repeatedly goes back and forth between the female NPCs to get blowjobs. It might be good to have a cooldown interval for female NPCs as well.

 

11 hours ago, Yuuen said:

Upgraded from 0.4 to 0.5 It now keeps enslaving my followers, kept trying to free them but it doesn't stick and enforcer doesn't seem to react to the player at all, going to downgrade.

 

9 hours ago, kaxat said:

@Yuuen Those do not sound like known bugs. My guess is that should double check your settings after updating. Follower enslavement changed a bit. The followers are now solely subject to your strip settings unless you check Followers are NPCs too.

This sounds like the bug I am encountering with my followers (I'm using LE if it matters). I haven't had time to try the Free Woman Clothing option to see if they still get enslaved.

[kaxat]

@Yuuen Half of the settings on the Nudity Law page affect this. Various combinations produce different results. Also your outfit theme weighs in.

If you have it set that everybody gets an outfit, free, slave, and follower then the follower will be treated like any other NPC. If that NPC would be given a free outfit follower will to. Same is true for slave outfits.

If you do not have it set to apply outfits to followers then followers will only be stripped. The slots you tell the enforcer to check will be checked. If it finds free woman clothing in a slot she keeps it equipped. If the slot does not contain free clothing it gets unequipped. If the Enforcer finds that she is wearing more strippable clothing than free she is enslaved.

The rules can be summarized thus. If your settings leave her naked she will be treated as a slave. By default at least. Outfit themes can spice this up.

[kaxat]

7 hours ago, Leoosp said:

 

@kaxat This could be due to the different format of addresses for the formID's used if this is to do with the outfits jsons. The reason being the json's used by PapyrusUtil I think are different between LE and SE. Specifically the LE of Skyrim is utilising decimals for its PapyurusUtil json FormIDs so need to be converted from hexadecimal, while SE of Skyrim is natively hexadecimal. Since you started off on SE this means your formID json files are in the wrong format for LE use, they need to be converted. So therefore, an update (or attached) converted json files for LE, followed by inclusion in a future update.

It's using decimals!? That would do it.

I do not have LE installed nor the hard drive space to install it. Do you have an example JSON file containing forms that LE can read? Or anyone else. I could go digging but honestly I'm burning out. Help would be appreciated.

In SE a JSON form is stored thus:
 

"0x4F4D7|Skyrim.esm",

 

Are you saying that in LE it would be stored like this:
 

"324823|Skyrim.esm",

 

Does it have 0 padding or anything? Still use the pipebar separator? I need to examine the format. I do not see any documentation for this but I might be missing something.

[Yuuen]

3 hours ago, kaxat said:

@Yuuen Half of the settings on the Nudity Law page affect this. Various combinations produce different results. Also your outfit theme weighs in.

If you have it set that everybody gets an outfit, free, slave, and follower then the follower will be treated like any other NPC. If that NPC would be given a free outfit follower will to. Same is true for slave outfits.

If you do not have it set to apply outfits to followers then followers will only be stripped. The slots you tell the enforcer to check will be checked. If it finds free woman clothing in a slot she keeps it equipped. If the slot does not contain free clothing it gets unequipped. If the Enforcer finds that she is wearing more strippable clothing than free she is enslaved.

The rules can be summarized thus. If your settings leave her naked she will be treated as a slave. By default at least. Outfit themes can spice this up.

I used the SWR theme and I'm pretty sure the "treat as NPC" option didn't matter. Since I installed it, had it ticked, followers were constantly enslaved. Thought it was a bad load, reinstalled, loaded an old save, unticked it and it still happened.

 

All my followers were clothed in different outfits so none went into a city naked or anything like that.

Edited October 27, 2022 by Yuuen

[gollum007]

DD equip contains some JSONs with forms, e.g.

{
    "formList" :
    {
        "nostrip" : [ "888146|Skyrim.esm", "506906|Skyrim.esm", "888144|Skyrim.esm" ]
    },
    "intList" :
    {
        "nostrip" : [ 1, 1, 1 ]
    },
    "string" :
    {
        "ssemanticver" : "5.30.1"
    }
}

 

Give me a minute, and I'll try converting to decimal, that's something I haven't tried- They seem to be in decimal in both LE and SE variants.

I agree with you about total lack of documentation

 

(As I understand it, all numbers should be 0x based, and SKSE will perform a bitshift to get it to the load order ID)

[gollum007]

Something *really* funky is going on; I'd suspect script load as being a major culprit, along with the usual Skyrim instability at this point....

 

Convert all values to decimal, and everything appears to work other than the second outfit SLV_SlaveOutfit1

https://www.rapidtables.com/convert/number/hex-to-decimal.html

[10/27/2022 - 10:49:10AM] SES log opened (PC)
[10/27/2022 - 10:49:10AM] [slv_mcmmenu <SLV_Menu (1E001828)>] -- Slaverun Reloaded Enforcer: Cleared 1 cities of their actor caches. Cleared 0 actor prevalidation flags. Typically 3 flags per city actor.
[10/27/2022 - 10:49:10AM] UpdgradeStrippedLists(1) Updated list of stripped NPCs in Whiterun (1/11 cities complete).
[10/27/2022 - 10:49:10AM] UpdgradeStrippedLists(2) Updated list of stripped NPCs in Riverwood (2/11 cities complete).
[10/27/2022 - 10:49:11AM] UpdgradeStrippedLists(3) Updated list of stripped NPCs in Falkreath (3/11 cities complete).
[10/27/2022 - 10:49:11AM] UpdgradeStrippedLists(4) Updated list of stripped NPCs in Dawnstar (4/11 cities complete).
[10/27/2022 - 10:49:11AM] UpdgradeStrippedLists(5) Updated list of stripped NPCs in Markarth (5/11 cities complete).
[10/27/2022 - 10:49:11AM] UpdgradeStrippedLists(6) Updated list of stripped NPCs in Riften (6/11 cities complete).
[10/27/2022 - 10:49:11AM] UpdgradeStrippedLists(7) Updated list of stripped NPCs in Morthal (7/11 cities complete).
[10/27/2022 - 10:49:11AM] UpdgradeStrippedLists(8) Updated list of stripped NPCs in Winterhold (8/11 cities complete).
[10/27/2022 - 10:49:11AM] UpdgradeStrippedLists(9) Updated list of stripped NPCs in Windhelm (9/11 cities complete).
[10/27/2022 - 10:49:11AM] UpdgradeStrippedLists(10) Updated list of stripped NPCs in Solitude (10/11 cities complete).
[10/27/2022 - 10:49:11AM] UpdgradeStrippedLists(11) Updated list of stripped NPCs in RavenRock (11/11 cities complete).
[10/27/2022 - 10:49:11AM] Location = (Dragonsreach) Worldspace = ()
[10/27/2022 - 10:49:11AM] UpdgradeStrippedLists(12) Updated list of stripped NPCs in None (12/11 cities complete).
[10/27/2022 - 10:49:11AM] Finished updating list of stripped NPCs (11/11 cities complete).
[10/27/2022 - 10:49:11AM] NEW LOCATION NAME=Dragonsreach; CITY=Whiterun <NEW=#0001F871 OLD=#00018A56/Whiterun>
[10/27/2022 - 10:49:11AM]   PeriodicCheck Location changed. Scheduling new run in 2 seconds.
[10/27/2022 - 10:49:12AM] SAME LOCATION (Dragonsreach) CITY=Whiterun <NEW=#0001F871 OLD=#0001F871>
[10/27/2022 - 10:49:13AM]   PeriodicCheck - Location changed during enforcer run. Next update will happen immediately.
[10/27/2022 - 10:49:15AM]   PeriodicCheck - Location changed during enforcer run. Next update will happen immediately.
[10/27/2022 - 10:49:17AM]   PeriodicCheck - Location changed during enforcer run. Next update will happen immediately.
[10/27/2022 - 10:49:17AM] Enforcer - Missing form specified in ../Slaverun/SlaverunOutfitsSlave.json[outfits_apply][1]=None PrevForm=[Outfit < (1E0012CC)>]; NextForm=[Outfit < (1EBC79F2)>]
[10/27/2022 - 10:49:17AM] CheckJsonFile(SlaverunOutfitsSlave.json) Enforcer - ERROR loading SlaverunOutfitsSlave.json[outfits_apply] contains invalid value
[10/27/2022 - 10:49:19AM]   Please exit the game and correct the JSON errors.
[10/27/2022 - 10:49:19AM]   PeriodicCheck - Location changed during enforcer run. Next update will happen immediately.
[10/27/2022 - 10:49:21AM]   Check your console or papyrus logs for further details.
[10/27/2022 - 10:49:21AM]   PeriodicCheck - Location changed during enforcer run. Next update will happen immediately.
[10/27/2022 - 10:49:23AM]   PeriodicCheck - Location changed during enforcer run. Next update will happen immediately.
[10/27/2022 - 10:49:26AM]   PeriodicCheck - Location changed during enforcer run. Next update will happen immediately.
[10/27/2022 - 10:49:28AM]   PeriodicCheck - Location changed during enforcer run. Next update will happen immediately.
[10/27/2022 - 10:49:30AM]   PeriodicCheck - Location changed during enforcer run. Next update will happen immediately.
[10/27/2022 - 10:49:32AM]   PeriodicCheck - Location changed during enforcer run. Next update will happen immediately.
[10/27/2022 - 10:49:34AM]   PeriodicCheck - Location changed during enforcer run. Next update will happen immediately.
[10/27/2022 - 10:49:35AM]   Opened Menu: Console

 

Log with this removed just takes a dump on an outfit that managed to load last time:

[10/27/2022 - 10:54:16AM] SES log opened (PC)
[10/27/2022 - 10:54:16AM] [slv_mcmmenu <SLV_Menu (1E001828)>] -- Slaverun Reloaded Enforcer: Cleared 1 cities of their actor caches. Cleared 0 actor prevalidation flags. Typically 3 flags per city actor.
[10/27/2022 - 10:54:16AM] UpdgradeStrippedLists(1) Updated list of stripped NPCs in Whiterun (1/11 cities complete).
[10/27/2022 - 10:54:16AM] UpdgradeStrippedLists(2) Updated list of stripped NPCs in Riverwood (2/11 cities complete).
[10/27/2022 - 10:54:16AM] UpdgradeStrippedLists(3) Updated list of stripped NPCs in Falkreath (3/11 cities complete).
[10/27/2022 - 10:54:16AM] UpdgradeStrippedLists(4) Updated list of stripped NPCs in Dawnstar (4/11 cities complete).
[10/27/2022 - 10:54:16AM] UpdgradeStrippedLists(5) Updated list of stripped NPCs in Markarth (5/11 cities complete).
[10/27/2022 - 10:54:16AM] UpdgradeStrippedLists(6) Updated list of stripped NPCs in Riften (6/11 cities complete).
[10/27/2022 - 10:54:16AM] UpdgradeStrippedLists(7) Updated list of stripped NPCs in Morthal (7/11 cities complete).
[10/27/2022 - 10:54:16AM] UpdgradeStrippedLists(8) Updated list of stripped NPCs in Winterhold (8/11 cities complete).
[10/27/2022 - 10:54:16AM] UpdgradeStrippedLists(9) Updated list of stripped NPCs in Windhelm (9/11 cities complete).
[10/27/2022 - 10:54:16AM] UpdgradeStrippedLists(10) Updated list of stripped NPCs in Solitude (10/11 cities complete).
[10/27/2022 - 10:54:16AM] UpdgradeStrippedLists(11) Updated list of stripped NPCs in RavenRock (11/11 cities complete).
[10/27/2022 - 10:54:16AM] UpdgradeStrippedLists(12) Updated list of stripped NPCs in None (12/11 cities complete).
[10/27/2022 - 10:54:16AM] Finished updating list of stripped NPCs (11/11 cities complete).
[10/27/2022 - 10:54:16AM] Location = (Dragonsreach) Worldspace = ()
[10/27/2022 - 10:54:17AM] NEW LOCATION NAME=Dragonsreach; CITY=Whiterun <NEW=#0001F871 OLD=#00018A56/Whiterun>
[10/27/2022 - 10:54:17AM]   PeriodicCheck Location changed. Scheduling new run in 2 seconds.
[10/27/2022 - 10:54:18AM] SAME LOCATION (Dragonsreach) CITY=Whiterun <NEW=#0001F871 OLD=#0001F871>
[10/27/2022 - 10:54:19AM]   PeriodicCheck - Location changed during enforcer run. Next update will happen immediately.
[10/27/2022 - 10:54:21AM]   PeriodicCheck - Location changed during enforcer run. Next update will happen immediately.
[10/27/2022 - 10:54:23AM]   PeriodicCheck - Location changed during enforcer run. Next update will happen immediately.
[10/27/2022 - 10:54:23AM] Enforcer - Missing form specified in ../Slaverun/SlaverunOutfitsSlave.json[keywords][0]=None PrevForm=None; NextForm=None
[10/27/2022 - 10:54:23AM] Enforcer - Missing form specified in ../Slaverun/SlaverunOutfitsSlave.json[keywords][1]=None PrevForm=None; NextForm=None

 

Converted slave outfit file FWIW:

{
    "string" : {
        /* Theme name is used in logs and MCM. Give it a unique name if you plan to share this theme with others. */
        "theme_name" : "Devious Devices - Basic",

        /* This is the MCM text label used to describe what happens when someone ticks the box that gives Slaves an outfit. Leave blank to use the generic label. */
        "mcm_apply_outfits_label" : "Give Devious Devices to Slaves",

        /* This is the MCM info box that appears when someone hovers over the Apply Outfits checkbox. Like the above this can be used to clarify what happens in your theme. Leave blank to use the generic description. */
        "mcm_apply_outfits_description" : "When an NPC is enslaved she will be given various Devious Devices to wear."
    },
    "formList" : {

        /* These are the outfits given to Slaves if MCM settings allow it. Contains (OTFT) records. */
        "outfits_apply" : [
            "4812|slaverun_reloaded.esp",     /*SLV_SlaveOutfit*/
            "137783|slaverun_reloaded.esp",    /*SLV_SlaveOutfit1*/
            "12351986|slaverun_reloaded.esp",    /*SLV_SlaveOutfit2*/
            "12351987|slaverun_reloaded.esp",    /*SLV_SlaveOutfit3*/
            "12351988|slaverun_reloaded.esp",    /*SLV_SlaveOutfit4*/
            "12351989|slaverun_reloaded.esp",    /*SLV_SlaveOutfit5*/
            "12351990|slaverun_reloaded.esp",    /*SLV_SlaveOutfit6*/
            "3597494|slaverun_reloaded.esp",    /*SLV_SlaveOutfitBlackDiamond*/
            "460281|slaverun_reloaded.esp",    /*SLV_SlaveOutfitBlackFull*/
            "460282|slaverun_reloaded.esp",    /*SLV_SlaveOutfitBlackNormal*/
            "369833|slaverun_reloaded.esp"     /*SLV_SlaveOutfitDiamond*/
        ],
        
        /* Anyone female wearing one of these will not have any clothing stripped and will be deemed a Slave. Contains Outfit (OTFT) records. */
        "outfits_valid" : [],
        
        /* These clothes will not be stripped. Enforcer is more likely to view a woman as a Slave when she wears some of these. Contains Armor (ARMO) records. */
        "clothes" : [],
        
        /* Clothes with these keywords will not be stripped. Enforcer is more likely to view a woman as a Slave when she wears some of these. Contains Keyword (KYWD) records. */
        "keywords" : [
            "192878|SexLab.esm",    /*SexLabNoStrip*/
            "41340|ZaZAnimationPack.esm"    /*zbfWornDevice*/
        ]
    }
}

 

 

 

TLDR:

At this point, I'd probably convert the numbers to decimal for LE, and remove the none check in the array load.

Tweak the outfit selection code a little so it just picks another random if the one it first tried was no good, and I think that's going to make most things work as well as they ever do.

 

I'll try and get a LE setup going, as well as testing with a more limited load order if you're interested to see if the instability is still there, but now I've converted the hex, this feels like 'normal' issues as opposed to your bug.

Edited October 27, 2022 by gollum007

[alex77r4]

15 hours ago, Leoosp said:

 

@kaxat This could be due to the different format of addresses for the formID's used if this is to do with the outfits jsons. The reason being the json's used by PapyrusUtil I think are different between LE and SE. Specifically the LE of Skyrim is utilising decimals for its PapyurusUtil json FormIDs so need to be converted from hexadecimal, while SE of Skyrim is natively hexadecimal. Since you started off on SE this means your formID json files are in the wrong format for LE use, they need to be converted. So therefore, an update (or attached) converted json files for LE, followed by inclusion in a future update.

 

7 hours ago, kaxat said:

It's using decimals!? That would do it.

I do not have LE installed nor the hard drive space to install it. Do you have an example JSON file containing forms that LE can read? Or anyone else. I could go digging but honestly I'm burning out. Help would be appreciated.

In SE a JSON form is stored thus:
 

"0x4F4D7|Skyrim.esm",

 

Are you saying that in LE it would be stored like this:
 

"324823|Skyrim.esm",

 

Does it have 0 padding or anything? Still use the pipebar separator? I need to examine the format. I do not see any documentation for this but I might be missing something.

 

No.... A number is always a number... No mater if we write it in decimal, exadecimal or binary. Example:

000000000000000 = 0x00000000000 = 00000000000

8749352111144 = 0x7F51E064C28 = 01111111010100011110000001100100110000101000

The value of 0 is always 0 and the value of 8749352111144 is equivalent to 0x7F51E064C28 and equal to 01111111010100011110000001100100110000101000

We can conver any number to any format while preserve their value.

 

The main motive because PapyrusUtil and JContainers have launched new versions for SE is the use of ESP files flaged as ESL because any ESP with ESL flag is encoded inside the game as FExxxyyy and the old formulas used in legenday with the format ZZxxxxxx was giving a bad identification of the formID.

 

From PapyrusUtil:

Spoiler

• Version 3.8

  • Updated for SKSE 2.0.17 & SE 1.5.97
  • Fixed handling of forms from ESL files

• Version 3.4

  • Added back TFC related functions
  • Added back ActorUtil package override functions
  • Fixed issue with forms sometimes storing/returning wrong while an .esl file is active in load order

 

From JContainers (SE) v4.1.10 GitHub:

Spoiler

Fixed loading of ESL forms (#60)

 

 

 

The SKSE group was the first to solve a stupid problem in the GetFormID function when handling large load orders in Legendary, many years ago, when loading an ESP past position 128, 80 in hex, because converting the ID to a signed integer returns a negative number.
But again, the number is exactly the same regardless of whether we represent it as a signed or unsigned int. The only difference was the result of the mathematical operations that had to be controlled. Similar mathematical problem we had in PapyrusUtil and JContainers when computing the ID of ESP's flaged as ESL.

 

Then, forget any problem related to the diferent format of the numbers, decimal or exadecinmal, because the number is always exactly the same.

And forget any problem caused by the diferent versions of the DLL's in Legenday or Special. The DLL's was diferent because the game was diferent.

Edited October 27, 2022 by alex77r4

[gollum007]

Ah-

I think I've just realised why SLV_Slaveoutfit1 isn't working.

Looking at it in Tes5Edit, it's actually an empty outfit, with no INAM records.

 

Converting the ZAP OTFT records appears to be working OK.

 

 

The other errors (second log) seem to be keyword related (not outfit as I thought- was misreading that).

Looking in my copy of SexLab LE, the SexLabNoStrip keyword appears to be located at 0x0058F1, which is different to yours. zbfWornDevice is at the same address though.

 

Editing that, and will test again in a second. (oh for a decent debugger......)

Edited October 27, 2022 by gollum007

[alex77r4]

33 minutes ago, gollum007 said:

I'd suspect script load as being a major culprit, along with the usual Skyrim instability at this point....

 

That never can affect the correct or in-correct conversions of the numbers. Please, stop saying that Papyrus is a bucket of poo and Skyrim crash every day. That is NOT true.

 

A script is always correctly executed under all the posible circunstances that you can imagine. Mainly becuse Papyrus is a programing languaje. Any developer relly in the programing language and need be absolutelly sure that, when the depeloper put this inside the code, the game always execute that code, no matter any other related circunstances.

 

Nobody as a developer can say: Papyrus execute that they want when they want. Because that made imposible the developent of a mod.

We have thousand and thousand of mod for Skyrim because Skyrim WORKS.

And we have millons and millons of lines of code writen in Papyrus because Papyrus WOKS.

[alex77r4]

19 minutes ago, gollum007 said:

Ah-

I think I've just realised why SLV_Slaveoutfit1 isn't working.

Looking at it in Tes5Edit, it's actually an empty outfit, with no INAM records.

 

Converting the ZAP OTFT records appears to be working OK.

 

 

The other errors (second log) seem to be keyword related (not outfit as I thought- was misreading that).

Looking in my copy of SexLab LE, the SexLabNoStrip keyword appears to be located at 0x0058F1, which is different to yours. zbfWornDevice is at the same address though.

 

Editing that, and will test again in a second. (oh for a decent debugger......)

 

That can be the real problem, the in-correct data and the in-correct relation of the KeyWords.

But the problem never can be related to the decimal or exacedimal format of the numbers or the versions of the DLL's or the overload in the Script Engine.

[Leoosp]

40 minutes ago, alex77r4 said:

 

 

No.... A number is always a number... No mater if we write it in decimal, exadecimal or binary. Example:

000000000000000 = 0x00000000000 = 00000000000

8749352111144 = 0x7F51E064C28 = 01111111010100011110000001100100110000101000

The value of 0 is always 0 and the value of 8749352111144 is equivalent to 0x7F51E064C28 and equal to 01111111010100011110000001100100110000101000

We can conver any number to any format while preserve their value.

 

The main motive because PapyrusUtil and JContainers have launched new versions for SE is the use of ESP files flaged as ESL because any ESP with ESL flag is encoded inside the game as FExxxyyy and the old formulas used in legenday with the format ZZxxxxxx was giving a bad identification of the formID.

 

From PapyrusUtil:

  Reveal hidden contents

• Version 3.8

  • Updated for SKSE 2.0.17 & SE 1.5.97
  • Fixed handling of forms from ESL files

• Version 3.4

  • Added back TFC related functions
  • Added back ActorUtil package override functions
  • Fixed issue with forms sometimes storing/returning wrong while an .esl file is active in load order

 

From JContainers (SE) v4.1.10 GitHub:

  Reveal hidden contents

Fixed loading of ESL forms (#60)

 

 

 

The SKSE group was the first to solve a stupid problem in the GetFormID function when handling large load orders in Legendary, many years ago, when loading an ESP past position 128, 80 in hex, because converting the ID to a signed integer returns a negative number.
But again, the number is exactly the same regardless of whether we represent it as a signed or unsigned int. The only difference was the result of the mathematical operations that had to be controlled. Similar mathematical problem we had in PapyrusUtil and JContainers when computing the ID of ESP's flaged as ESL.

 

Then, forget any problem related to the diferent format of the numbers, decimal or exadecinmal, because the number is always exactly the same.

And forget any problem caused by the diferent versions of the DLL's in Legenday or Special. The DLL's was diferent because the game was diferent.

 

Yes, it is still a number. But it is written in a different form so depending on how PapyrusUtils and its json handles it when version 3.3 on LE, as well as what it expects then you can have issues. Eg if it expects decimal instead of hexadecimal and can't or doesn't convert it thus can then run into trouble.

Edited October 27, 2022 by Leoosp

[Leoosp]

8 hours ago, kaxat said:

It's using decimals!? That would do it.

I do not have LE installed nor the hard drive space to install it. Do you have an example JSON file containing forms that LE can read? Or anyone else. I could go digging but honestly I'm burning out. Help would be appreciated.

In SE a JSON form is stored thus:
 

"0x4F4D7|Skyrim.esm",

 

Are you saying that in LE it would be stored like this:
 

"324823|Skyrim.esm",

 

Does it have 0 padding or anything? Still use the pipebar separator? I need to examine the format. I do not see any documentation for this but I might be missing something.

 

WolfHelmet.json

 

The file attached comes from SexLab Survival which definitely utilises FormID in LE, utilising json format of PapyrusUtil version 3.3. It's in decimal rather than hexadecimal. Take a look at the FormID section of the file, so you can see how it needs to be formatted for LE when using it in json format.

 

 

Has a set of files for converting into decimal based json formIDs for use with Skyrim LE as this modification was originally developed for LE. The process may be only form SexLab Survival. But the section for "Getting A List of FormIds For Jsons" is likely done in a fashion to make it easy to convert, I'm not utilising your mod at the moment, trying to get it setup though. Are going to be running into this soon, I haven't converted it yet as are trying to identify modifications which are SE only.

Edited October 27, 2022 by Leoosp

[gollum007]

Frankly, Papyrus is a badly documented, buggy heap of junk, with behavioural differences between SE and LE

Start running a massive load order, and things that previously worked perfectly on a smaller load order can and will give unexpected random issues, been there, done that.

 

Unfortunately, it's what we've got, and I have no engine source or decent debugger to play with.

(not helped at all by SKSE etc. being largely documented in 1000 page forum threads, not a full developers reference)......

 

 

 

Back a little on topic, the current follower outfit logic is broken. The game will currently assign a new outfit to each follower each time the enforcer runs, as well as treating her as a slave even if the player is free. (IMHO a regression from the original, which allowed for treating followers as per the player rules)

[alex77r4]

55 minutes ago, Leoosp said:

 

Yes, it is still a number. But it is written in a different form so depending on how PapyrusUtils and its json handles it when version 3.3 on LE, as well as what it expects then you can have issues. Eg if it expects decimal instead of hexadecimal and can't or doesn't convert it thus can then run into trouble.

 

Take a look to StorageUtil, JsonUtil, JMap, JArray and all the scripts starting with J* and try find any reference to hexadecimal values. You go to find nothing.

 

The only real diference is how us, the developers, make our own definition of our JSON files because that is the only real diference and the key of all the problems.

Of course, if we write inside the JSON exadecimal values we need read them as STRING and when we try read it as INT we get invalid data.

We can't say to the DLL "read this as exadecimal and return it to me as decimal" because the DLL can't make that.

The DLL only can process String and Integer and not know what is an exadecimal number.

 

So, only the developer who made the program that read the JSON file must say if the data must be writen in decimal or in exadecimal and they, as developer, call

JMap.getInt(Int object, String key) or JMap.getStr(Int object, String key) depending, only and excusivelly, of how they, as developer, want format their own JSON file.

 

Is a excusive problem of Papyrus code and not have any relation to the version of the game (Legendary or Special) or to the version of the DLL.

All that numbers normally are used to call functions like GetForm and GetFormFromFile and we need format the number as necesary depending of the call.

How we made that in Papyrus is, only and excusively, a decision of the developer and not have any relation to the version of the game or the DLL.

Edited October 27, 2022 by alex77r4

[alex77r4]

52 minutes ago, gollum007 said:

Start running a massive load order, and things that previously worked perfectly on a smaller load order can and will give unexpected random issues, been there, done that.

 

What do you call a massive load order?

Spoiler

 

A game with 197 ESP's and 73 ESL's with 7893 scripts and 118539 instances is enougth masive for you?

Of course, i see people making merges with 500 mods and 1000 mods but ask them how many mods with script they have.

 

As i said before, all the problems are related to bad data, incorrect keywords, bad replacement of the ESP's records or bad overwrites of files.

Normally, the problems never had anything to do with the Papyrus code, the overload of the game or the number of scripts.

[alex77r4]

1 hour ago, Leoosp said:

The file attached comes from SexLab Survival which definitely utilises FormID in LE, utilising json format of PapyrusUtil version 3.3. It's in decimal rather than hexadecimal. Take a look at the FormID section of the file, so you can see how it needs to be formatted for LE when using it in json format.

 

This file come from More Nasty Critters that is made for Legendary and have formID in exadecimal. Anybody can take a look to the source code to know how process it.

MNC.json

 

Of course, if you take a look to others JSON files you can see how some use decimal numbers, like Adquisitive Sools Gems, while others use exadecimal numbers, like SOS.

vanilla.json

SOS_Ho_Compat.json

 

I repeat, is a exclusive decision of the developer not related to Legenday or Special or DLL version.

Edited October 27, 2022 by alex77r4