dmc Devious Mimic Clothing SE

[Mister X]

New version 2.4.0 is up!

 

With this one comes the chance to find Protector Charms throughout chests in the world, that can protect against nasty Mimics (yes, this idea totally is stolen from DCUR ?)

 

There now is an experimental feature to support a follower, too!

For this to happen, you have to enable debugging though, as it's not yet meant for a normal playthrough. It will affect only one follower at a time, but this one then can get hit by Mimics on the same events and with the same chances as the player.

[JuliusXX]

21 hours ago, Mister X said:

New version 2.4.0 is up!

 

With this one comes the chance to find Protector Charms throughout chests in the world, that can protect against nasty Mimics (yes, this idea totally is stolen from DCUR ?)

 

There now is an experimental feature to support a follower, too!

For this to happen, you have to enable debugging though, as it's not yet meant for a normal playthrough. It will affect only one follower at a time, but this one then can get hit by Mimics on the same events and with the same chances as the player.

 

Is a clean install needed?

[Mister X]

Nope, should be fine to just overwrite, I think.

[forsythia_vahl]

Hi!

I need help since I cant get it work at all!

 

The papyrus.log only shows:

...

[Mimic Clothes] Equip event attempts triggering - 

[Mimic Clothes] Unequip event attempts triggering - 

...

But nothing happened.

 

[Mister X]

On 7/30/2021 at 12:32 PM, forsythia_vahl said:

Hi!

I need help since I cant get it work at all!

 

The papyrus.log only shows:

...

[Mimic Clothes] Equip event attempts triggering - 

[Mimic Clothes] Unequip event attempts triggering - 

...

But nothing happened.

 

 

After the "-" there should be the name of the item that triggered. As nothing's there I assume some technical item or helper tried to trigger a mimic. Those will get filtered, they can't trigger anything.

 

Try this to see if there's really a problem:

- Search a quiet place ingame and save there

- Then, set the chances really high in the MCM and deactivate any restrictions

- After this, try to manually un-/equip some piece of armor or clothing every few seconds (don't spam it, though)

- Eventually, if everything's ok, it should successfully trigger for that normal armor, if not, then send me the log of that try

[BreadDain]

On 7/30/2021 at 1:32 PM, forsythia_vahl said:

Hi!

I need help since I cant get it work at all!

 

The papyrus.log only shows:

...

[Mimic Clothes] Equip event attempts triggering - 

[Mimic Clothes] Unequip event attempts triggering - 

...

But nothing happened.

 

Same issue, fresh install of 2.4, mod events do nothing and prompt - instead of item name.
Downgraded to 2.3.2, event message appears, but no item is getting equipped. Maybe 5.1 DD is incompatible?

Edited August 7, 2021 by BreadDain

[Mister X]

@BreadDain Did you try to force Events for certain items? Eg, take a leather armor and try to equip and unequip it every few seconds until something triggers.

Basically try forcing a event with an item of that you're sure that it should be possible.

 

And a Papyrus log of that could help, too.

[BreadDain]

@Mister X no problemo, here you go
2.4
Papyrus.1.log
Nothing relevant in the file, debug line appears in game.

2.3.2
Papyrus.0.log
Event fires, messagebox appears, log line exists with erroneous item reference.
 

Spoiler

Note: DD 5.1 (recent), SexLab 163 beta 9 (recent, experimental), SL Aroused Modular (experimental). The latter 2 shouldn't matter I think, issue is most likely within DD conflict or the mod itself.

UPD Yes I tried testing it extensively with low cooldown and 100% proc chances, nothing worked.

Edited August 9, 2021 by BreadDain

[Mister X]

Hmm, it seems you DID have enabled the debug flag (set dmcDebug to 1 in console) as you got the messages on screen, right?

The thing is, that there are absolutely no messages of my mod in your log, normally it would give additional information when debugging is enabled.

 

Like this I only can tell, that a variable that should hold the piece of armor somewhere gets emptied for some reason, but I'm not really sure where or when.

Especially, as I didn't really change anything essential in between those versions concerning those functions ...

[BreadDain]

1 hour ago, Mister X said:

Hmm, it seems you DID have enabled the debug flag (set dmcDebug to 1 in console) as you got the messages on screen, right?

The thing is, that there are absolutely no messages of my mod in your log, normally it would give additional information when debugging is enabled.

 

Like this I only can tell, that a variable that should hold the piece of armor somewhere gets emptied for some reason, but I'm not really sure where or when.

Especially, as I didn't really change anything essential in between those versions concerning those functions ...

Yes, version 2.4 of your mod is completely silent (except in-game debug log). Screenshot is from 2.3.2, and yes, I toggled debug mode on both tests.

Edited August 9, 2021 by BreadDain

[Seeker999]

On 7/19/2021 at 4:47 AM, Mister X said:

 

Heyho, yes, that issue already has been reported and I came across it by myself, too. The thing is, I never was able to find a good solution, as the problem isn't in my code but in the one of the DD framework or in the game engine itself.

For some reason, sometimes my LeveledItem I fill with the allowed and usable DD items, doesn't get transferred or read properly to the framework code.

The log spam is a result of that: the framework has only a sanity check for the first iteration, after that it will try until the end of time. It always get's past that first check, which tells me that my stuff got filled properly, but then the framework gets stuck in a loop forever.

 

On my end though, anything seems to be fine, even two other coders couldn't find an error in the scripting. So I absolutely have no idea, how to get rid of this  

I even asked Kimy some time ago but didn't get an answer for this.

 

Hi,

I may have found a workaround for the papyrus blow up problem. It's definitely not a solution, but....

• I saved and quit the game.
• I scrolled through the papyrus log noticed that most if not all the bloat involved the .dmcarmorthreadscript.
• I copied the script to a safe place and then deleted it from my game's Data/scripts folder.
• Started Skyrim SE, played a couple of minutes w/o issue.
• Saved and quit.
• Copied the script back into the Data/scripts folder.
• Opened the game and went to the debug section in the MCM, saw that events were blocked and reset the block flags.
• Tested that mimic worked by setting equip chance to 100% and trying things on. Worked - I got mimiced!

It's not elegant. Maybe I didn't have to do that save without script. I don't know if there will be some weird long-term effect down the road. I do know that I didn't have to load a previous save, losing however much game played time, or go through the hassle of uninstalling the mod, making a clean save, reinstalling the mod. My papyrus log went from over 81k lines in 3 minutes to less than 3000 lines in over 30 minutes.

 

I'm still using v. 2.3.2. I didn't upgrade because I didn't see anything about this issue being fixed or patched or anything. The Protector charms sound interesting, but not enough to make the switch mid-game. Just thought I'd share what I did in case it was useful to someone.

[Mister X]

6 hours ago, Seeker999 said:

The Protector charms sound interesting, but not enough to make the switch mid-game

 

Well, it should be safe to update mid-game, but that's your decision.

 

And that's definitely an interesting approach and I'm somewhat even more amazed that it actually worked. The thing is, the problematic function isn't even part of my scripts but in a file of the DD framework. But I'm happy it worked on your end, I'm just not sure about recommending it generally.

[TrickyK]

Had an idea for a small (and hopefully easy to add feature). Can we get a slider to set the chance that a mimic will actually equip a device? If we have items equipped it would just destroy it sometimes (or most of the time depending on how you set the slider) instead of always equipping a device.

[BreadDain]

Ok so I had another attempt of fixing the mod since script recompilation didn't just work. Added some console logging to check what scripts are running and how do they run. It seems like the mod a) can't fetch actor being valid for event at all and b) script is designed in such way (a bad one) that a single armor unequip produces several script loops without a reason. I guess some failsaves are required.

This is console log for a single armor unequip event after I tried to fiddle with a lot of equipment at once. Note that conditions before equipping are checked several times for no reason and everywhere actor is being invalid. Will look into it a bit more.

Spoiler

UPD1 Actor wasn't valid because there is a condition if the first main quest was completed (not just active as it could be), which blocked mod from working in test cell. In real gameplay conditions it appears that mod is working, but ultimately slow and with overlapping loops. I pinpointed possible part of the script that has a long work time before it lets other functions fire.

dmcArmorThreadScript, line 156-166
 

Spoiler

            ; check for already worn device, try to find alternative
            int i = 0
            While (akDevice && i < 10 && libs.GetWornDeviceFuzzyMatch(theVictim, ddKw))
                akDevice = ddList.GetRandomDevice(liDevicePool)
                ddKw = libs.GetDeviceKeyword(akDevice)

                i += 1
            EndWhile
            If (akDevice && libs.GetWornDeviceFuzzyMatch(theVictim, ddKw))
                akDevice = none
            EndIf

UPD2 dmcMainTrigger, line 125, doesn't check if cooldown is possible and always sets trigger on cooldown.
UPD3 dmcArmorThreadScript, line 152-153 sometimes also take too long to pass. Should be DD framework to blame.
 

Spoiler

            akDevice = ddList.GetRandomDevice(liDevicePool)
            Keyword ddKw = libs.GetDeviceKeyword(akDevice)

 

Edited August 23, 2021 by BreadDain

[Mister X]

On 8/17/2021 at 10:05 PM, TrickyK said:

Had an idea for a small (and hopefully easy to add feature). Can we get a slider to set the chance that a mimic will actually equip a device? If we have items equipped it would just destroy it sometimes (or most of the time depending on how you set the slider) instead of always equipping a device.

 

A bit ago I've added the feature of "struggling" based on your character stats: sometimes your PC can struggle effectively against a mimic after it triggered. In that case nothing will be ewuipped. There's a toggle, too, to set whether your piece of clothing should get destroyed even when struggling is successful. Is that what you meant?

 

 

3 hours ago, BreadDain said:

Ok so I had another attempt of fixing the mod since script recompilation didn't just work. Added some console logging to check what scripts are running and how do they run. It seems like the mod a) can't fetch actor being valid for event at all and b) script is designed in such way (a bad one) that a single armor unequip produces several script loops without a reason. I guess some failsaves are required.

This is console log for a single armor unequip event after I tried to fiddle with a lot of equipment at once. Note that conditions before equipping are checked several times for no reason and everywhere actor is being invalid. Will look into it a bit more.

  Reveal hidden contents

UPD1 Actor wasn't valid because there is a condition if the first main quest was completed (not just active as it could be), which blocked mod from working in test cell. In real gameplay conditions it appears that mod is working, but ultimately slow and with overlapping loops. I pinpointed possible part of the script that has a long work time before it lets other functions fire.

dmcArmorThreadScript, line 156-166
 

  Reveal hidden contents

            ; check for already worn device, try to find alternative
            int i = 0
            While (akDevice && i < 10 && libs.GetWornDeviceFuzzyMatch(theVictim, ddKw))
                akDevice = ddList.GetRandomDevice(liDevicePool)
                ddKw = libs.GetDeviceKeyword(akDevice)

                i += 1
            EndWhile
            If (akDevice && libs.GetWornDeviceFuzzyMatch(theVictim, ddKw))
                akDevice = none
            EndIf

UPD2 dmcMainTrigger, line 125, doesn't check if cooldown is possible and always sets trigger on cooldown.
UPD3 dmcArmorThreadScript, line 152-153 sometimes also take too long to pass. Should be DD framework to blame.
 

  Reveal hidden contents

            akDevice = ddList.GetRandomDevice(liDevicePool)
            Keyword ddKw = libs.GetDeviceKeyword(akDevice)

 

 

For 1) It checks only once whether an actor is a valid target, afterwards it just uses that result again to check if different outcomes are usable.

The thing with the first main quest is there, so you don't get mimics during character creation, or when playing the vanilla intro. That's how many mods check if they are allowed to run, I just used existing code for that. If you don't like that: for testing, I used Alternate Start with the "I want to escape this cell", works like a charm, too 

 

For UPD 1) The overlapping loops are there because of the multi-threaded coding of the mod. It was even slower for v1, where each and every check was done one after another.

So, before v2 the checks where serial with low stress on the engine, now they are parallel but with more stress on the engine. It won't matter though for the most time.

dmcArmorThreadScript is the one that checks if the armor is usable and what device fits to the body region of that armor. I already sourced out as much as I can to formlists and alike to avoid Papyrus Arrays, still you have to iterate a list. The speed of that is just limited by the current speed of your Papyrus engine and the amount of other active scripts.

The loop you pinpointed just really is used, when other devices are worn in the affected body region. It won't run if no devices are worn there. I could try to speed it up a bit by using an alternate DDf function for collision checks, that will have bad negatives more often though. The other possibility is to lower the number of iterations before aborting, but I don't know if this will have much influence as most often you won't have more than 3 iterations.

For UPD 2), I will look into that, thanks for that report.

EDIT That's totally fine, cooldown set just saves the time of the last trigger. The HasCooldown() function respects whether to use cooldown. And even then, a small CD of 2 ingame minutes always is there to avoid a new trigger right after a successful one.

 

For UPD 3) There you have found a culprit for a bug report I received long ago, yet I have still no idea how to fix it. Sometimes that DDf function seems to get a LeveledItem with nothing in it, so it is caught in an endless loop. I've already reported that to Kimy, but I don't know when or if she will fix that. Neither do I know why my mod seems to fail with filling the LeveledItem sometimes, I wasn't really able to reliable reproduce the bug, even though I came across it myself a few times already.

Edited August 23, 2021 by Mister X
Added explanation

[BreadDain]

1 hour ago, Mister X said:

...

Don't really trust AS LAL because Arthmoor implemented some console blocking stuff, that's why I am using Dimes instead. Still loading qasmoke is somewhat faster for testing, but alright, at least I figured why mod didn't work at all. Wonder if similar to Sheogorath's quest condition will work better, isrunning and !iscompleted.
About cooldown - that's somewhat contrary to mcm option because cooldown is expected to be removed entirely, but again, alright. Just gave me a feeling that something was wrong when console was silent and didn't produce any logs.

But the problem is still there, something is hogging a lot of script execution time and mod hits 10/30 second failsave boundaries. I am constantly getting (customized message for debugging purposes):

Quote

[Mimic Clothes] Armor thread probably encountered an error and is locked up;

from ArmorFuture script, so it doesn't recieve the 'end result' and stops working. Thread clears itself afterwards and nothing happens.

I don't really understand the mod in-depth, but I actually think that a lot of resources can be saved with certain optimizations. Since DD functions are to blame, why just not move it after mod calculates trigger chances and validates an actor?
It is also probably worth to reduce the use of GetWornDeviceFuzzyMatch by removing records from liDevicePool each loop, so script doesn't have a possibility to hit one and the same record each time, which it had previously checked. I also don't really get it why this loop fires even if an actor doesn't have any devices equipped? Why I=10? Isn't it better to link loop number to the list size of items it can possibly check every time?
But again, I am really low skill at scripting, these are just wild ideas to try. If you think they could help, I would be glad that I've tried.

PS I see it is a static Leveled list, but it's still worth to consider an additional stress on Papyrus from 10 loops when the list contains less devices in pool. God, I am too sleepy for this right now, need a break.

Edited August 23, 2021 by BreadDain

[Mister X]

1 hour ago, BreadDain said:

Wonder if similar to Sheogorath's quest condition will work better, isrunning and !iscompleted.

 

This works for Sheogoraths quest as that the player can choose when to start. The first quest is the intro, the Vanilla Helgen escape, where the player can't choose whether or when to start it normally. But since alternate start mods (not just ASLAL) won't necessarily FINISH the quest, I chose to check if it got to state 1000 (which is the destroyed Helgen), as every alternate start mod I've found sets that stage after you chose your start. I honestly don't know if that finishes the quest, too, but like that it works as I want to, so I'll probably leave it that way ^^

 

1 hour ago, BreadDain said:

Since DD functions are to blame, why just not move it after mod calculates trigger chances and validates an actor?

 

Because all those three things are done at the same time. It's multi-threaded, so it validates the actor in one thread, validation of the armor in another one and calculation of the chances in the third thread.

When it's done calculating the chances it asks for the results of the other  twothreads and waits until it gets those to decide which outcome to use.

 

1 hour ago, BreadDain said:

removing records from liDevicePool each loop

 

That won't be possible as those are nested LeveledItem lists. So, it's a LeveledItem inside a LeveledItem inside a LeveledItem and only the lowest layer really contains the devices. As those LeveledItems are provided by the framework, I can't remove a device from them. So, I only could remove a top layer LeveledItem, which then as consequence would remove a handful to a dozen of devices and not only the one which wouldn't work.

Additionally I don't have a good way of finding out which LeveledItem holds the chosen device: diving INTO the LeveledItem layers is easier than diving out of them and that's done by the framework, too, which only gives back the found device and not the LeveledItem where it found it.

 

That's also a reason why i=10: I don't really know how many LeveledItem lists are there and moreover how many are NESTED INSIDE of those. You can see it like a tree diagram, where each branch is a LeveledItem and only the most bottom layer are the devices. Look at the example picture.

 

I can't calculate how many actual DEVICES I can choose from, so I use a fixed, not too high number to restrict the attempts.

Spoiler

 

Edited August 23, 2021 by Mister X
Add picture

[Mister X]

New version 2.5.0 is up!

 

With this one there come two new features: exporting MCM settings to files aswell as triggers after sleeping (only when not interrupted during sleep)

Of course all can be set up individually in the MCM.

 

I also tackled the long problem of the countless error messages that some people come by. The solution was so easy, I just overlooked it ^^

As I now use my own, slightly altered version to iterate the device lists, I can make sure it aborts when something went wrong in a LeveledItem.

 

Please let me know if that fixes the problem on your end, at least I didn't get the error spam anymore during testing.

 

@forsythia_vahl and @BreadDain I couldn't reproduce your problem no matter what I've tried. I only ever get empty names when it's a technical item of another mod, normal armor pieces always worked like a charm during testing. Maybe something went wrong during your installation?

I only can suggest you try to uninstall the mod, make a clean save, play some time ingame to get rid of some remaining update calls and then install the new version.

[BreadDain]

13 hours ago, Mister X said:

New version 2.5.0 is up!

 

With this one there come two new features: exporting MCM settings to files aswell as triggers after sleeping (only when not interrupted during sleep)

Of course all can be set up individually in the MCM.

 

I also tackled the long problem of the countless error messages that some people come by. The solution was so easy, I just overlooked it ^^

As I now use my own, slightly altered version to iterate the device lists, I can make sure it aborts when something went wrong in a LeveledItem.

 

Please let me know if that fixes the problem on your end, at least I didn't get the error spam anymore during testing.

 

@forsythia_vahl and @BreadDain I couldn't reproduce your problem no matter what I've tried. I only ever get empty names when it's a technical item of another mod, normal armor pieces always worked like a charm during testing. Maybe something went wrong during your installation?

I only can suggest you try to uninstall the mod, make a clean save, play some time ingame to get rid of some remaining update calls and then install the new version.

Ok thx, I'll put Fallrim tools to good use instead. Will try new version and report findings.

UPD Mod seems to work very smooth, delay is still there but at least response from trigger is consistent. There is still a danger if you send trigger 5-10 times at once, but it can resolve this request spam after a while.

UPD 2 Small incompatibility report with any mod that forcefully equips items, they can appear as mimics and break stuff. Probably would be a good idea to make a check if item was equipped by player manually, if it is possible.

Edited August 25, 2021 by BreadDain

[Mister X]

13 hours ago, BreadDain said:

delay is still there but at least response from trigger is consistent. There is still a danger if you send trigger 5-10 times at once, but it can resolve this request spam after a while.

 

Yepp, it won't be possible to have no perceptual delay, as those scripts have to gather and process quite a bit data. Still, the mod is designed in a way that only one armor at a time will be processed, so 5-10 triggers at once won't add that much engine stress. The later ones will line up and wait until the active trigger is finished, that will add some delay though, but I loose less triggers that way. If one waits too long though, it just will give up and abort to free capacities.

 

But it's good to hear that it now is more stable on your end  

[Mister X]

On 8/24/2021 at 10:31 PM, BreadDain said:

UPD 2 Small incompatibility report with any mod that forcefully equips items, they can appear as mimics and break stuff. Probably would be a good idea to make a check if item was equipped by player manually, if it is possible.

 

I already have checks included to avoid this for certain items (like other DD stuff), aswell as keyword checks. So, DD items, ZAP or Toys items aswell as all items Sexlab may not strip and items with flags that normally show a quest item all are already excluded.

Can you tell me which mod that was and what items it tried to equip? Maybe they have a special keyword. Or you just use the console or AddItemMenu to get those items and put them in the NoTriggerChest. That one you find in the MCM menu.

 

Sadly, there is no good way of that I know to check whether the item was equipped manually or by mod, anything sends the same Event my mod just listens for.

[BreadDain]

2 hours ago, Mister X said:

Can you tell me which mod that was and what items it tried to equip? Maybe they have a special keyword. Or you just use the console or AddItemMenu to get those items and put them in the NoTriggerChest. That one you find in the MCM menu.

Got undesired trigger from FillHerUp Baka edition mod, where leaking mesh is equipped to actor, it doesn't have any tags. Example:

Spoiler

BaboDialogue mod equips certain items which for somewhat reason are classified as jewelery, I am almost sure they can also cause Mimics to trigger.
 

Spoiler

There is actually a good template for most of these items, Clothing with 0 weight and BaboRestraints Keyword. Or maybe a patch could work.

Edited August 26, 2021 by BreadDain

[Mister X]

Hmm, tbh it looks more like Babo forgot to set some flags, eg the IsPlayable flag or the SexLabNoStrip keyword, eg for his equipped cum items those would fit ...

But I can add a new check for the BaboRestraints keyword as well as weightless items

[BreadDain]

Well, I can probably redirect this issue to him then, but it is more about "following standarts".

[Mister X]

New hotfix 2.5.1

Nothing's added, just changed the armor validation a bit to have more compatibility with Baka's stuff

 

New BETA 3.0.0-b1

I've worked on the follower support, and it basically seems to work.

Followers have their own events, they won't trigger for the PC ones, though they share the chance settings. You can set the search interval and radius and it will show the found follower in the MCM > Debug section. Follower support can't be disabled, as it's a beta and therefor used for testing purposes - you have been warned. This will be changed for release, of course  

 

Known issue: followers seem to reload and thus reequip their whole stuff whenever a new armor is given or taken to/from them. That will trigger multiple events and a random one will win.