devious skyrim Unforgiving Devices

[Zaflis]

4 hours ago, hungvipbcsok said:

I have a question. Is the newest Devious Lore 3.0 work with UD 2.0. 

If a mod normally works with DD 5.x then it works with UD. Maybe main Devious Lore mod works but about its extra addons you probably want to disable them.

[smannfrau]

On 3/13/2023 at 9:56 PM, kurotatsu said:

Known bug, it's actually in the DD itself. Fixed in in-dev UD version.

 

In this case it probably wasn't a DD bug. I fixed the issue. It was a load order issue... sort of.

 

Devious Devices for him. esp and Devious Devices - brrf.esp are flagged as esl for SSE.

 

esl plugins are indexed starting with FE. So the two DD esps were overwriting UD's patch not matter what I order I put it.

 

My solution was to recreate the UD patch as an esl and load that one after brrf and for him. Now everything works as intended (as far as I can tell).

[Guest]

11 hours ago, smannfrau said:

 

In this case it probably wasn't a DD bug. I fixed the issue. It was a load order issue... sort of.

 

Devious Devices for him. esp and Devious Devices - brrf.esp are flagged as esl for SSE.

 

esl plugins are indexed starting with FE. So the two DD esps were overwriting UD's patch not matter what I order I put it.

 

My solution was to recreate the UD patch as an esl and load that one after brrf and for him. Now everything works as intended (as far as I can tell).

I think it is a DD bug, that device has always been broken for me

[loniceraa]

Hi,

 

I noticed that devices with weak vibrations don't seem to have any impact on arousal. In particular, this is fairly obvious with spell-triggered vibrations. Once the strength of the device passes a certain threshold, however, arousal then skyrockets off of any vibration. I'm still using the last stable version of UD (2.0) with the basic version of Sexlab Aroused, so I apologize if this has been changed in the newer beta version, but I briefly looked and didn't see anything there.

 

I don't entirely follow the arousal updates in the code, but a brief inspection suggests to me that this is due to integer tracking of arousal in the Aroused.GetActorExposure() and Aroused.SetActorExposure() functions used in zadlibs_UDPatch.UpdateExposure(). A lot of weak vibrators seem to update arousal frequently with low values close to zero, and so all of these would get truncated or rounded to zero.

 

To get around this, I tried updating the script to instead use the StorageUtil tracking internal to Sexlab Aroused, partly similar to how the the original zadlibs script worked prior to UD. This seems to work much more appropriately, though I understand this was changed for compatibility with other arousal mods. See below for my changes.

 

Spoiler

Function UpdateExposure(actor akRef, float val, bool skipMultiplier=false)
    If (akRef == None)
        Error("UpdateExposure passed none reference.")
        return
    EndIf
    int lastRank = Aroused.GetActorExposure(akRef)
    if skipMultiplier
        ; This function is very slow, and sometimes hangs for multiple seconds (Seen 10+). Directly access internals as a work-around.
		
        ; edit: ints are not granular enough for regular vibrate updates with weak devices. need to use floats
        ; therefore, resorting to old zadlibs version + more storageutil usage
        float newVal = StorageUtil.GetFloatValue(akRef, "SLAroused.ActorExposure") + val
        if newVal > 100
            newVal = 100
        EndIf
        StorageUtil.SetFloatValue(akRef, "SLAroused.ActorExposure", newVal)
        StorageUtil.SetFloatValue(akRef, "SLAroused.ActorExposureDate", Utility.GetCurrentGameTime())
    Else
        int newRank = Round(lastRank + val * Aroused.GetActorExposureRate(akRef))    
        Aroused.SetActorExposure(akRef, newRank)
    EndIf
EndFunction

 

 

There's probably a better way to accomplish the same thing, e.g. checking for incompatible mods first before using StorageUtil. Generally, though, I think integers are insufficient to handle arousal updates when UD uses so many floating point calculations.

 

 

Edit: After further testing, I'm not sure interacting with SLA using StorageUtil like this is any better. Other functions still update arousal frequently (every second?) and force the floating point values to integers, meaning the minimum exposure update is still going to be 1, which is probably too much for a weak vibrator.

 

It seems like base DD only updates arousal at longer time intervals during vibrations. Maybe UD could do something similar, "bundling" smaller arousal updates into bigger chunks to update arousal frameworks?

Edited March 17, 2023 by loniceraa

[ihatemykite]

12 hours ago, loniceraa said:

Hi,

 

I noticed that devices with weak vibrations don't seem to have any impact on arousal. In particular, this is fairly obvious with spell-triggered vibrations. Once the strength of the device passes a certain threshold, however, arousal then skyrockets off of any vibration. I'm still using the last stable version of UD (2.0) with the basic version of Sexlab Aroused, so I apologize if this has been changed in the newer beta version, but I briefly looked and didn't see anything there.

 

I don't entirely follow the arousal updates in the code, but a brief inspection suggests to me that this is due to integer tracking of arousal in the Aroused.GetActorExposure() and Aroused.SetActorExposure() functions used in zadlibs_UDPatch.UpdateExposure(). A lot of weak vibrators seem to update arousal frequently with low values close to zero, and so all of these would get truncated or rounded to zero.

 

To get around this, I tried updating the script to instead use the StorageUtil tracking internal to Sexlab Aroused, partly similar to how the the original zadlibs script worked prior to UD. This seems to work much more appropriately, though I understand this was changed for compatibility with other arousal mods. See below for my changes.

 

  Reveal hidden contents

Function UpdateExposure(actor akRef, float val, bool skipMultiplier=false)
    If (akRef == None)
        Error("UpdateExposure passed none reference.")
        return
    EndIf
    int lastRank = Aroused.GetActorExposure(akRef)
    if skipMultiplier
        ; This function is very slow, and sometimes hangs for multiple seconds (Seen 10+). Directly access internals as a work-around.
		
        ; edit: ints are not granular enough for regular vibrate updates with weak devices. need to use floats
        ; therefore, resorting to old zadlibs version + more storageutil usage
        float newVal = StorageUtil.GetFloatValue(akRef, "SLAroused.ActorExposure") + val
        if newVal > 100
            newVal = 100
        EndIf
        StorageUtil.SetFloatValue(akRef, "SLAroused.ActorExposure", newVal)
        StorageUtil.SetFloatValue(akRef, "SLAroused.ActorExposureDate", Utility.GetCurrentGameTime())
    Else
        int newRank = Round(lastRank + val * Aroused.GetActorExposureRate(akRef))    
        Aroused.SetActorExposure(akRef, newRank)
    EndIf
EndFunction

 

 

There's probably a better way to accomplish the same thing, e.g. checking for incompatible mods first before using StorageUtil. Generally, though, I think integers are insufficient to handle arousal updates when UD uses so many floating point calculations.

 

 

Edit: After further testing, I'm not sure interacting with SLA using StorageUtil like this is any better. Other functions still update arousal frequently (every second?) and force the floating point values to integers, meaning the minimum exposure update is still going to be 1, which is probably too much for a weak vibrator.

 

It seems like base DD only updates arousal at longer time intervals during vibrations. Maybe UD could do something similar, "bundling" smaller arousal updates into bigger chunks to update arousal frameworks?

Thank you for heads up. Original SLA always store arousal as whole number, so that is why. Because of that I had two way to do the arousal calculation

1. Floor the value. This means that if arousal rate would be 0.95 per second, it would be rounded to 0. This was making weak vibrators to not work

2. Ceil the value. This means that if arousal rate would be 0.95 per second, it would be rounded to 1. This was making weak vibrators too strong. If actor would have 4 weakest vibrators, they would have still arousal rate 4.

3. Round the value. This means that if arousal rate would be < 0.5, it would be rounded to 0. If Arousal rate would be >= 0.5, it would be rounded to 1. This is most optional way, but it still makes the vibrator which have exactly 0.5 arousal rate have 1. So it would be 2x powerful.

 

Currently, the update arousal function looks like this

Function UpdateArousal(Int aiUpdateTime) Actor loc_actor = GetActor() Float loc_arousalRate = UDOM.getArousalRateM(loc_actor) Int loc_arousal = Round(loc_arousalRate)*aiUpdateTime if loc_arousal != 0 loc_actor.SetFactionRank(UDOM.ArousalCheckLoopFaction,UDOM.UpdateArousal(loc_actor ,loc_arousal)) else loc_actor.SetFactionRank(UDOM.ArousalCheckLoopFaction,UDOM.getActorArousal(loc_actor)) endif EndFunction

Better would be to just add the float variable, which will store all additional values after decimal point. Then, once this value reaches a value bigger than a whole number, it will be added to update. I have some idea how to do it, so I will give it a try. It should be now possible with transferred calculation to NPC slots.

[loniceraa]

15 hours ago, ihatemykite said:

Better would be to just add the float variable, which will store all additional values after decimal point. Then, once this value reaches a value bigger than a whole number, it will be added to update. I have some idea how to do it, so I will give it a try. It should be now possible with transferred calculation to NPC slots.

 

Yeah, that sounds like an ideal solution. Thanks for looking into this. On the subject of vibrators, here's another couple issues I noticed...

 

1) In UDCustomDeviceMain, it seems like there was a copy/paste error in the getActivableVibrators() function. Pretty sure it should return getNPCSlot(akActor).getActivableVibrators() instead of getNPCSlot(akActor).getOffVibrators() (which is what the function above it returns).

 

2) In UD_OrgasmManager, I'm pretty sure the getActorArousal() function should be returning the getActorArousal() function (or perhaps GetFactionRank(sla_Arousal)) from slaFrameworkScr, instead of GetActorExposure(). At least in the base version of SLAR, if you just use exposure that will ignore time rate completely, and I've experienced situations where my character has had 100 arousal but still has a really high anti-ORAT because of this.

Edited March 18, 2023 by loniceraa

[ihatemykite]

17 hours ago, loniceraa said:

 

Yeah, that sounds like an ideal solution. Thanks for looking into this. On the subject of vibrators, here's another couple issues I noticed...

 

1) In UDCustomDeviceMain, it seems like there was a copy/paste error in the getActivableVibrators() function. Pretty sure it should return getNPCSlot(akActor).getActivableVibrators() instead of getNPCSlot(akActor).getOffVibrators() (which is what the function above it returns).

 

2) In UD_OrgasmManager, I'm pretty sure the getActorArousal() function should be returning the getActorArousal() function (or perhaps GetFactionRank(sla_Arousal)) from slaFrameworkScr, instead of GetActorExposure(). At least in the base version of SLAR, if you just use exposure that will ignore time rate completely, and I've experienced situations where my character has had 100 arousal but still has a really high anti-ORAT because of this.

Thanks for letting me know

1. Will fix
2. I don't think that it is possible to change that without breaking the mod. I would better focus on why you had problems. Even if you have 100 arousal, it still doesn't mean you can orgasm, that still depends on ORAT. At 100 arousal, the AntiORAT will be same as Orgasm resistance (3.5 by default). How big AntiORAT did you get ?

 

[POLE7645]

I don't know if this is something with the Nightly Builds, but anything that equips devices just stopped working after I've updated to the Nightly Builds. Just... nothing happens (both with Cursed Loot or Laura's Bondage Shop).

 

I think I just might wait for the next version (and I wonder if it'll require a new game).

[loniceraa]

1 hour ago, ihatemykite said:

I don't think that it is possible to change that without breaking the mod. I would better focus on why you had problems. Even if you have 100 arousal, it still doesn't mean you can orgasm, that still depends on ORAT. At 100 arousal, the AntiORAT will be same as Orgasm resistance (3.5 by default). How big AntiORAT did you get ?

 

At 100 arousal my Anti-ORAT was still at 35 (the maximum), using the default orgasm resistance of 3.5. This is because I only had ~40 exposure; most of my character's arousal was due to time rate. In my opinion it is clearly a bug, as the "wearer details" menu only lists an arousal of 40, despite Sexlab Aroused clearly reporting an arousal of 100.

 

I recompiled UD_OrgasmManager with the following change:

Spoiler

int Function getActorArousal(Actor akActor)
    return akActor.GetFactionRank(libs.Aroused.slaArousal)
EndFunction

 

And everything works as expected now: wearer details reports 100 arousal, Anti-ORAT is at 3.5, and vibrators can progress to orgasm even with time rate as the main component of arousal.

Edited March 18, 2023 by loniceraa

[NobodyImportant33333]

1 hour ago, POLE7645 said:

I don't know if this is something with the Nightly Builds, but anything that equips devices just stopped working after I've updated to the Nightly Builds. Just... nothing happens (both with Cursed Loot or Laura's Bondage Shop).

 

I think I just might wait for the next version (and I wonder if it'll require a new game).

Nightly builds involve every single change to the mod on a day by day basis. You can think of it as a daily Alpha build. Stuff WILL break. It's best not to use the nightly build, unless you like reporting bugs or really want to try out a new feature.

[ihatemykite]

1 hour ago, loniceraa said:

 

At 100 arousal my Anti-ORAT was still at 35 (the maximum), using the default orgasm resistance of 3.5. This is because I only had ~40 exposure; most of my character's arousal was due to time rate. In my opinion it is clearly a bug, as the "wearer details" menu only lists an arousal of 40, despite Sexlab Aroused clearly reporting an arousal of 100.

 

I recompiled UD_OrgasmManager with the following change:

  Hide contents

int Function getActorArousal(Actor akActor)
    return akActor.GetFactionRank(libs.Aroused.slaArousal)
EndFunction

 

And everything works as expected now: wearer details reports 100 arousal, Anti-ORAT is at 3.5, and vibrators can progress to orgasm even with time rate as the main component of arousal.

What UD does is that it saves the arousal internally as faction rank on new faction. But I still don't understand how did it break. Does the arousal scale normally now with your fix ? Like if you start with zero and turn on some vibrator, will it increase, and be same as the one from SLA ?

3 hours ago, POLE7645 said:

I don't know if this is something with the Nightly Builds, but anything that equips devices just stopped working after I've updated to the Nightly Builds. Just... nothing happens (both with Cursed Loot or Laura's Bondage Shop).

 

I think I just might wait for the next version (and I wonder if it'll require a new game).

Its possible that I broke it, will have to test. I was doing some maintenance on scripts so maybe I accidentally deleted something which should have not been deleted.

[loniceraa]

 

2 hours ago, ihatemykite said:

What UD does is that it saves the arousal internally as faction rank on new faction. But I still don't understand how did it break. Does the arousal scale normally now with your fix ? Like if you start with zero and turn on some vibrator, will it increase, and be same as the one from SLA ?

 

I didn't change the getArousal() function that uses the new UD faction, that's still the same:

 

Spoiler

Int Function getArousal(Actor akActor)
    if akActor.isInFaction(ArousalCheckLoopFaction)
        return akActor.GetFactionRank(ArousalCheckLoopFaction)
    else
        return getActorArousal(akActor)
    endif
EndFunction

 

Sexlab Aroused Redux is certainly a mess of code with lots of issues, so it's no wonder there's confusion (and at least three remakes of it floating around). Maybe some screenshots will help.

 

Here's how things are with base UD_OrgasmManager:

 

int Function getActorArousal(Actor akActor)
    return libs.Aroused.GetActorExposure(akActor)
EndFunction

 

Spoiler

Initial SLAR status

 

Initial UD status

 

UD status with minor vibrations

 

UD status with grand soulgem vag plug vibrating on very strong; note that exposure has increased (though not arousal, as it's still at max), so anti-ORAT has finally decreased

 

Now, here's with the recompiled UD_OrgasmManager:

 

int Function getActorArousal(Actor akActor)
    return akActor.GetFactionRank(libs.Aroused.slaArousal)
EndFunction

 

Spoiler

Initial SLAR status (same as before)

 

Initial UD status (notice arousal at 100 now, anti-ORAT appropriately at minimum)

 

UD status with minor vibrations. Capable of orgasm now!

 

UD status with major vibrations

 

Resetting exposure to zero, per your request...

 

UD status now

 

Arousal increases as expected with vibrations (discrepancy is due to timing delay)

 

Final SLAR status (again, slight discrepancy due to timing)

 

It's not really that the original UD getActorArousal() is *broken*, it's just that exposure is not the right attribute to grab from SLAR. You need arousal, which can either be retrieved via slaFramework.GetActorArousal(), a sadly incredibly expensive function, or from the slaFramework.slaArousal faction.

Edited March 19, 2023 by loniceraa

[ihatemykite]

8 hours ago, loniceraa said:

 

 

I didn't change the getArousal() function that uses the new UD faction, that's still the same:

 

  Reveal hidden contents

Int Function getArousal(Actor akActor)
    if akActor.isInFaction(ArousalCheckLoopFaction)
        return akActor.GetFactionRank(ArousalCheckLoopFaction)
    else
        return getActorArousal(akActor)
    endif
EndFunction

 

Sexlab Aroused Redux is certainly a mess of code with lots of issues, so it's no wonder there's confusion (and at least three remakes of it floating around). Maybe some screenshots will help.

 

Here's how things are with base UD_OrgasmManager:

 

int Function getActorArousal(Actor akActor)
    return libs.Aroused.GetActorExposure(akActor)
EndFunction

 

  Reveal hidden contents

Initial SLAR status

 

Initial UD status

 

UD status with minor vibrations

 

UD status with grand soulgem vag plug vibrating on very strong; note that exposure has increased (though not arousal, as it's still at max), so anti-ORAT has finally decreased

 

Now, here's with the recompiled UD_OrgasmManager:

 

int Function getActorArousal(Actor akActor)
    return akActor.GetFactionRank(libs.Aroused.slaArousal)
EndFunction

 

  Reveal hidden contents

Initial SLAR status (same as before)

 

Initial UD status (notice arousal at 100 now, anti-ORAT appropriately at minimum)

 

UD status with minor vibrations. Capable of orgasm now!

 

UD status with major vibrations

 

Resetting exposure to zero, per your request...

 

UD status now

 

Arousal increases as expected with vibrations (discrepancy is due to timing delay)

 

Final SLAR status (again, slight discrepancy due to timing)

 

It's not really that the original UD getActorArousal() is *broken*, it's just that exposure is not the right attribute to grab from SLAR. You need arousal, which can either be retrieved via slaFramework.GetActorArousal(), a sadly incredibly expensive function, or from the slaFramework.slaArousal faction.

I see, I tried using the getActorArousal from SLA, but that didn't work as expected, but the solution with faction works. Didn't find any issue yet, but more testing will be needed. I have pushed the change to main branch, so you can try the NB once it builds and test if everything is ok. Changing commit is https://github.com/IHateMyKite/UnforgivingDevices/commit/9b6a323c4841e27eba8d65d30658f78dee388d89

[hungvipbcsok]

ScreenShot16.bmpThe leg cuff trigger tied up event when my pc wearing pet suit. And it break the animation of pet suit.

[Zaflis]

11 hours ago, hungvipbcsok said:

ScreenShot16.bmpThe leg cuff trigger tied up event when my pc wearing pet suit. And it break the animation of pet suit.

This was the case in the stable version, have tried if it's still bugging with the github version?

[xyzfs]

Hello there! Does anyone know how does the custom orgasm mechanic work with SLSO?

If they're not compatible, is there an effective way to disable the orgasm mechanic from UD?

[girmrad]

Sorry for the stupid question, but can Unforgiving Devices be used with versions of Devious Devices that are more recent than the requirements? I'm on Special Edition and trying to use Unforgiving Devices 2.1 beta with Devious Devices 5.2 release and I'm having an issue where Unforgiving Devices causes the Devious Devices MCM to appear but fail to load. The Unforgiving Devices MCM menu also shows up but fails to load. I would try to revert back to Devious Devices beta 10 (the recommended version), but the Special Edition download links for that version aren't active anymore as far as I can tell. Unforgiving Devices version 2.0 works with Devious Devices 5.2 release just fine for me though.

Edited March 26, 2023 by girmrad

[someuselessuser]

19 hours ago, girmrad said:

Sorry for the stupid question, but can Unforgiving Devices be used with versions of Devious Devices that are more recent than the requirements? I'm on Special Edition and trying to use Unforgiving Devices 2.1 beta with Devious Devices 5.2 release and I'm having an issue where Unforgiving Devices causes the Devious Devices MCM to appear but fail to load. The Unforgiving Devices MCM menu also shows up but fails to load. I would try to revert back to Devious Devices beta 10 (the recommended version), but the Special Edition download links for that version aren't active anymore as far as I can tell. Unforgiving Devices version 2.0 works with Devious Devices 5.2 release just fine for me though.

I can confirm 2.1 beta isnt't working with DD 5.2, same issue. Can't test older versions right now though.

[kurotatsu]

Please try nightly build of UD, do not forget to start a new game after installing.

 

https://github.com/IHateMyKite/UnforgivingDevices/releases/tag/NB

[girmrad]

I tried the nightly build on a new save and got an error message:

!!FATAL ERROR!!

Error loading Unforgiving devices. One or more of the modules are not ready. Please contact developrs on LL or Github

 

The very end of my Papyrus log had this:

Spoiler

[03/27/2023 - 02:00:28PM] [UD,INFO,T=1729.916138]: !!FATAL ERROR!! = Error loading Unforgiving devices. One or more of the modules are not ready. Please contact developrs on LL or GitHub
[03/27/2023 - 02:00:28PM] [UD,INFO,T=1729.948120]: UDlibs=TRUE
[03/27/2023 - 02:00:28PM] [UD,INFO,T=1729.980103]: UDCDmain=False
[03/27/2023 - 02:00:28PM] [UD,INFO,T=1730.012085]: config=TRUE
[03/27/2023 - 02:00:28PM] [UD,INFO,T=1730.044067]: ItemManager=TRUE
[03/27/2023 - 02:00:28PM] [UD,INFO,T=1730.076050]: UDLLP=TRUE
[03/27/2023 - 02:00:28PM] [UD,INFO,T=1730.108032]: UDOM=TRUE

 

Edited March 27, 2023 by girmrad
Added additional information

[ihatemykite]

3 hours ago, girmrad said:

I tried the nightly build on a new save and got an error message:

!!FATAL ERROR!!

Error loading Unforgiving devices. One or more of the modules are not ready. Please contact developrs on LL or Github

 

The very end of my Papyrus log had this:

  Hide contents

[03/27/2023 - 02:00:28PM] [UD,INFO,T=1729.916138]: !!FATAL ERROR!! = Error loading Unforgiving devices. One or more of the modules are not ready. Please contact developrs on LL or GitHub
[03/27/2023 - 02:00:28PM] [UD,INFO,T=1729.948120]: UDlibs=TRUE
[03/27/2023 - 02:00:28PM] [UD,INFO,T=1729.980103]: UDCDmain=False
[03/27/2023 - 02:00:28PM] [UD,INFO,T=1730.012085]: config=TRUE
[03/27/2023 - 02:00:28PM] [UD,INFO,T=1730.044067]: ItemManager=TRUE
[03/27/2023 - 02:00:28PM] [UD,INFO,T=1730.076050]: UDLLP=TRUE
[03/27/2023 - 02:00:28PM] [UD,INFO,T=1730.108032]: UDOM=TRUE

 

Thank you for report. This will be very helpful when finding out what is causing the issue. I'm mostly testing UD on one save over and over again without starting the game, so I mostly realize this issue when it's too late. This has happened many times before, but I always fixed it before releasing the version. Basically, there is some kind of code that is causing issue with OnInit event. Strangely, I was starting a new game recently (after beta was released) and didn't have the issue. Can you share information about your mod list ? Also, do you use CursedLoot ? I was having issue starting a new game with DCL, then I deleted some meshes and it magically started working.

[ihatemykite]

On 3/23/2023 at 1:40 AM, xyzfs said:

Hello there! Does anyone know how does the custom orgasm mechanic work with SLSO?

If they're not compatible, is there an effective way to disable the orgasm mechanic from UD?

There is currently no was to disable the orgasm mechanic from UD. But I don't thing that the 2 mods will interact, as UD orgasm system is currently only focused on solo orgasms caused by vibrators. While SLSO is focused on orgasms from sex. But I might be wrong, I don't use SLSO and have no experience with it.

[ihatemykite]

On 3/21/2023 at 5:34 AM, Zaflis said:

This was the case in the stable version, have tried if it's still bugging with the github version?

It was never fixed. I forget that the issue even existed. Will try to fix it before I forget again ?

[girmrad]

1 hour ago, ihatemykite said:

Thank you for report. This will be very helpful when finding out what is causing the issue. I'm mostly testing UD on one save over and over again without starting the game, so I mostly realize this issue when it's too late. This has happened many times before, but I always fixed it before releasing the version. Basically, there is some kind of code that is causing issue with OnInit event. Strangely, I was starting a new game recently (after beta was released) and didn't have the issue. Can you share information about your mod list ? Also, do you use CursedLoot ? I was having issue starting a new game with DCL, then I deleted some meshes and it magically started working.

Unfortunately, my mod list is pretty huge (~800 mods). I have a lot of mods that interact with DD, such as Sexlab Survival, Devious Device Helpers, Deviously Enslaved Continued, Devious Captures, and Devious Strike. I don't use Cursed Loot though.

[ihatemykite]

10 hours ago, girmrad said:

Unfortunately, my mod list is pretty huge (~800 mods). I have a lot of mods that interact with DD, such as Sexlab Survival, Devious Device Helpers, Deviously Enslaved Continued, Devious Captures, and Devious Strike. I don't use Cursed Loot though.

I tried to replicate the bug but didn't manage to. UD was running without issue. Can you share the whole Papyrus log ? If you have trace enabled, it should also print some additional info which might help to figure out what is wrong. I also updated the script which is not loading so it will now also print what exact submodules are having issue. Please, try new NB and let me know what it is saying.