Devious Devices - Integration 4.3a (2019-09-10)

[darktej]

17 minutes ago, onlytrans said:

So i have a quick question hopefully. Im new-ish to modding first of all. I have skyrim SE, CBBE, SKYUI,  I run FNIS get no errors, the game generally runs good minus the few things you'd expect from a modded game. My issue is that when My character has a corset/chastity device/straight jacket she goes  invisible for some reason.  The ball gags, some shoes, collars and blinds all work amazingly well. For some reason some of the other stuff I cant see. I am unsure as to why. I have all the updated versions of mods, like i said the game works good generally with no FNIS errors. Ive made sure ive only downloaded the SE versions of things.

 

Just some of these outfits just do not appear or worse make me invisible.  Im at a loss really. Im sure its something simple hopefully.

 

thanks a lot !

 

 

have you run bodyslide? Run bodyslide for DDi and DDx files.

[onlytrans]

I did run bodyslide and made a batch file, it worked. thats what i was needing to do. ty!   

 

I do though have another dilemma, if its not to much to ask.  I think this has to do the with options for DD. If my character has a corset or a breast chastity device, etc,  and another device or multiple are added to her, the game basically crashes. I do think this is part of the options in the DD where you can have like 4 items per slot.. it seems? they all seem to be disabled and im  not exaclty sure how this works..

 

Like if i'm on lets say.. slot 38 and all are disabled now, do I just go in and open them all up to say 'slot 38' ?   is there a tutorial on this i am perhaps missing?

 

any help again would be appreciated. tyvm.

[merManc]

2 hours ago, onlytrans said:

I do though have another dilemma, if its not to much to ask.  I think this has to do the with options for DD. If my character has a corset or a breast chastity device, etc,  and another device or multiple are added to her, the game basically crashes. I do think this is part of the options in the DD where you can have like 4 items per slot.. it seems? they all seem to be disabled and im  not exaclty sure how this works..

 

Like if i'm on lets say.. slot 38 and all are disabled now, do I just go in and open them all up to say 'slot 38' ?   is there a tutorial on this i am perhaps missing?

 

any help again would be appreciated. tyvm.

 

I don't know what the cause of the crashing would be, but it sounds like the menu options you're asking about are the Devices Underneath system. This is designed to allow you to have items in certain equip slots invisible when wearing something in another slot. If the SE version works the same way, you should see that slots 49, 51, 56 and 58 are listed in the four entries under slot 32 by default. This means that when wearing anything in slot 32 (the main body armour/clothing slot) anything worn in those other four slots will be invisible, so they won't clip. In devious terms, those four slots are chastity belts, nipple piercings, chastity bras and harnesses/corsets.

 

If you set 38 in any of the four entries for slot 38, it would mean that equipping something in slot 38 would make anything equipped in slot 38 invisible - including the item you just equipped.

 

As you're playing SE, you may have better luck getting help with the crashing in the DD SE support topic. Good luck!

[maxsteiner]

20 hours ago, Zaflis said:

This is a quick fix, you can install it as mod to override DD-Integration 4.3a. Just contains the script file from DDI 4.3.

DD 4.3a gag fix.zip 1.78 kB · 12 downloads

Sorry, that didnt do anything. I installed it with nmm but it didnt ask to overwrite anything.

Edit: Did it manually and that worked. Thanks man.

[MrsBelch]

1 hour ago, maxsteiner said:

Sorry, that didnt do anything. I installed it with nmm but it didnt ask to overwrite anything.

Try this:

Devious Devices - Integration 4.3a Gag Fix.7z

[onlytrans]

5 hours ago, merManc said:

 

I don't know what the cause of the crashing would be, but it sounds like the menu options you're asking about are the Devices Underneath system. This is designed to allow you to have items in certain equip slots invisible when wearing something in another slot. If the SE version works the same way, you should see that slots 49, 51, 56 and 58 are listed in the four entries under slot 32 by default. This means that when wearing anything in slot 32 (the main body armour/clothing slot) anything worn in those other four slots will be invisible, so they won't clip. In devious terms, those four slots are chastity belts, nipple piercings, chastity bras and harnesses/corsets.

 

If you set 38 in any of the four entries for slot 38, it would mean that equipping something in slot 38 would make anything equipped in slot 38 invisible - including the item you just equipped.

 

As you're playing SE, you may have better luck getting help with the crashing in the DD SE support topic. Good luck!

 

Ok, ok.. So i had how this works basically backwards. I thought I needed to enable those slot to have things appear when in fact they do just the opposite. TY for that information.  Yea im not sure about the crashing, im not blaming any one thing. It just usually happens when my character has mulitple devices added to her. Game freezes and crashes, at no otherpoint does it do this.

 

but!, i will forward my issues to the other forum as not to clutter this one. tyvm for your time!

[darktej]

1 hour ago, onlytrans said:

 

Ok, ok.. So i had how this works basically backwards. I thought I needed to enable those slot to have things appear when in fact they do just the opposite. TY for that information.  Yea im not sure about the crashing, im not blaming any one thing. It just usually happens when my character has mulitple devices added to her. Game freezes and crashes, at no otherpoint does it do this.

 

but!, i will forward my issues to the other forum as not to clutter this one. tyvm for your time!

I maybe wrong here but anyone please correct me if I am mistaken. saying that...I think the reason why your game maybe crashing could be that you have installed high resolution textures (when it comes to the devices) and by equipping multiple restraints that is overworking the game and perhaps that is leading to the crash. this may be not optimal but could you re-install with lower textures and see whether it still crashes? 

[MariSkyrimNerd]

I don't know if I am in the right place. When my characters hands are shackled the "Fist unequipped" notification and sound keeps looping and its getting annoying.

[stobor]

With the new version, gags no longer retain the 'mouth open' facial expression; they start with that expression, but seldom keep it for long - and once they revert to the default expression, they never seem to go back to 'mouth open'.

[WaxenFigure]

10 minutes ago, stobor said:

With the new version, gags no longer retain the 'mouth open' facial expression; they start with that expression, but seldom keep it for long - and once they revert to the default expression, they never seem to go back to 'mouth open'.

Read back a few pages, the "fix" you can use until the next version is discussed.

[Lupine00]

A curiousity...

 

Kimy never uses ManipulateGenericDevice or ManipulateGenericDeviceByKeyword with equipOrUnequip set to true, only with false.

 

Does that mean that the equip path of that function is not well tested and can't really be trusted?

I guess the main ManipulateDevice with true doesn't have much room to go wrong, as it calls almost straight through to EquipDevice or RemoveDevice, but the generic device functions are more complex, with various 'optimisations' and checks.

 

 

The name of the parameter equipOrUnequip is somewhat misleading, as it suggests it toggles the item state if true, and does nothing if false.

Examination of the function code suggests otherwise though.

 

Presumably, it should have been called requiredEquipState. or something like that?

[merManc]

2 hours ago, LetheOminous said:

I don't know if I am in the right place. When my characters hands are shackled the "Fist unequipped" notification and sound keeps looping and its getting annoying.

 

That sounds like SPERG, which is listed in the Compatibility and Conflicts section. It automatically equips "fists" when you have no other weapons equipped. So, dd removes weapons when binding you, prompting SPERG to equip fists, prompting dd to remove them, prompting SPERG to equip them again, prompting dd to remove them again, and so on.

 

Set SPERG's unarmed mode to Manual to prevent that. The side effect is that the fists will become an item in your inventory you can't drop without them being forced back in, and you will have to equip them yourself when you want to use them. Unfortunately, disabling the unarmed feature in SPERG doesn't actually seem to disable it - or didn't when I last used it, at least - so, manual is the only way around this issue if you want to use both mods.

[Lupine00]

What is the preferred (most efficient way) to lock a device (remove the manipulation that allows removal without a key) - if present - and do nothing if absent?

 

If my NPC sees the PC wandering about with some devices on, and wants to check they are properly locked on, what is the best way to go about it?

 

I don't see anything exposed for this in the main zadLibs, so you would seem to need to remove the device and re-equip it?

That's far from ideal. I can't believe that would be the intended solution.

 

I know the DCL has some functionality like this, but that's a bit of a needle+haystack search.

[MariSkyrimNerd]

1 hour ago, merManc said:

 

That sounds like SPERG, which is listed in the Compatibility and Conflicts section. It automatically equips "fists" when you have no other weapons equipped. So, dd removes weapons when binding you, prompting SPERG to equip fists, prompting dd to remove them, prompting SPERG to equip them again, prompting dd to remove them again, and so on.

 

Set SPERG's unarmed mode to Manual to prevent that. The side effect is that the fists will become an item in your inventory you can't drop without them being forced back in, and you will have to equip them yourself when you want to use them. Unfortunately, disabling the unarmed feature in SPERG doesn't actually seem to disable it - or didn't when I last used it, at least - so, manual is the only way around this issue if you want to use both mods.

Thank you for the quick response I will try that

[piotsze]

Does anybody know a way how to run manually script zadBQ00, can it be exucuted by inputing any console command? ?

Also please don't give reply that it should run by itself. I already know that. TY

[Kimy]

10 hours ago, Lupine00 said:

A curiousity...

 

Kimy never uses ManipulateGenericDevice or ManipulateGenericDeviceByKeyword with equipOrUnequip set to true, only with false.

 

Does that mean that the equip path of that function is not well tested and can't really be trusted?

I guess the main ManipulateDevice with true doesn't have much room to go wrong, as it calls almost straight through to EquipDevice or RemoveDevice, but the generic device functions are more complex, with various 'optimisations' and checks.

 

 

The name of the parameter equipOrUnequip is somewhat misleading, as it suggests it toggles the item state if true, and does nothing if false.

Examination of the function code suggests otherwise though.

 

Presumably, it should have been called requiredEquipState. or something like that?

This function was implemented by Min years before he passed DD to me. Personally, I don't see a use-case for calling it to equip devices, so I only ever use it to unequip devices. This doesn't necessarily mean that the function is not to be trusted, it just means that Kimy doesn't see a need for it and probably would have implemented it for removing devices only.

[Kimy]

2 hours ago, piotsze said:

Does anybody know a way how to run manually script zadBQ00, can it be exucuted by inputing any console command? ?

Also please don't give reply that it should run by itself. I already know that. TY

Why would you want to do it? Did the script stop working for you?

[piotsze]

@Kimy Just for fun. Take it easy. ?

[Lupine00]

16 hours ago, Kimy said:

Personally, I don't see a use-case for calling it to equip devices, so I only ever use it to unequip devices.

And the question about locking manipulated devices? I know it's a different kind of manipulation

I guess I'll re-quote it:

On 9/27/2019 at 4:19 PM, Lupine00 said:

What is the preferred (most efficient way) to lock a device (remove the manipulation that allows removal without a key) - if present - and do nothing if absent?

 

If my NPC sees the PC wandering about with some devices on, and wants to check they are properly locked on, what is the best way to go about it?

 

I don't see anything exposed for this in the main zadLibs, so you would seem to need to remove the device and re-equip it?

That's far from ideal. I can't believe that would be the intended solution.

 

I know the DCL has some functionality like this, but that's a bit of a needle+haystack search.

Is there a way to do this efficiently via the API?

Obviously, there is a state in the object that indicates if it is really locked, or just pretend (closed, manipulated?)

I want to go through the DD API, so it doesn't create a fragile binding to code that might get changed.

 

But I don't want to use that... Unless it's a StorageUtil variable, which would be super-convenient.

[Kimy]

The manipulate lock feature is designed to offer a way for the user to wear a device for "fun", and allow them to remove it at any time. I did not design a way into the framework to allow locking such a device after the fact. If you want to write a feature doing this, you would probably need to check for the device worn, unequip it and replace with a locked version of the same device.

[DayTri]

Does DDI_DeviceRemoved ModEvent send only when the player removes the device through the normal menu, or is it triggered by mods removing it too?

 

I am trying to keep a count of equipped devices without dependency by counting the equipped devices and removals. I can't seem to catch removal by cursed loot at the end of quests or when the free me debug option is used.

[Reesewow]

 

7 hours ago, Lupine00 said:

If my NPC sees the PC wandering about with some devices on, and wants to check they are properly locked on, what is the best way to go about it?

*PC who often wears required Devious Follower items with manipulated locks starts sweating profusely and eyeing her willpower stat*

[Lupine00]

12 hours ago, Kimy said:

If you want to write a feature doing this, you would probably need to check for the device worn, unequip it and replace with a locked version of the same device.

Urgh. That's what I was trying to avoid.

 

The remove-re-add cycle is inherently perilous - a race condition nightmare.

 

DCL runs into this problem often enough:

Devices are removed, then new ones added ... but the old ones aren't fully removed when the new ones try to fit, both devices end screwed up, one sort of fitted, the other sort of not.

In some cases even removing the devices and getting them from containers, DD panic button, and DCL free me cannot fix it.

 

I think it might be safe if I spin wait for the device to be gone, but I'm not 100% sure even that is infallible.

And what if a user sneaks in a device equip while I'm doing it? Then I spin wait until some long timeout and have to start over?

 

 

Now, I believe the DD mutex system is supposed to stop that, but it doesn't, and never has - even if people don't disable the mutex, and it's disabled by default - which is weird.

That design choice causes all kinds of bad interactions between mods because most mods use default values, so skipMutex = True for almost all API functions.

 

It should be the reverse. You should have to go to considerable trouble to avoid taking the mutex. I believe this wasn't done because it was constantly locking up, and not unlocking when it should - and that's due to errors that have probably been there since day one:
(a) common paths where it fails to get unlocked when it should get unlocked, and,

(b) it isn't actually a mutex so fails due to race conditions anyway.

 

 

The mutex is written in Papyrus, so it won't really work. Instead it just sort of helps a bit.

The test and the update are not atomic. That's why I had to write a real mutex for SLAX.

I know the Papyrus threading model is supposed to help you here, but the spin wait contains log calls, and a sleep, and a shortish timeout, and that means all bets are off.

e.g.

  EndWhile

  log("SpinLock() Completed. Cycles:" + timeout)

EndIf

DeviceMutex = false ; immediately reacquire lock

But it IS NOT immediate, you called log. This might happen 20 seconds after the EndWhile. You have no way to know how long it will be.

 

That said, even a brief perusal of the mutex logic easily finds cases where it has nasty surprises for the user, such as it isn't cleared after being taken, unless skipEvents is true or there's an actual conflict. Clearly, if it is only released in that case, then it should only be taken in that case. Or more clearly, if you take it, you must release it, and that isn't the case. Unless there's something else in play I missed, in which case, great!

 

My initial conclusion is that the mutex code is not really maintained or tested, and contains obvious hazards (you can argue whether they are outright bugs), but there can be no argument that it is not a true mutex and is subject to race condition failures, it's more like the pirate code than a reliable mechanism for preventing race-conditions or conflicts in equip.

 

 

These functions are likely old, and the bad paths and poor decisions regarding the mutex are likely historical artifacts. There hasn't been much attention given to them, or they wouldn't be like this. Perhaps it's time for a review?

 

I think fixing them properly would make a lot of other race-condition nonsense just go away.

 

Personally, I'd fix the mutex so it really works, and then clean up all the API functions so mutex is always used.

Leave the old skipMutex flag in the calls, but ignore it and mark it deprecated.

 

Then... Add a function you can call prior to do anything to disable mutex checks (you must call to re-enable after you're done) for those cases where you believe mutex checks can be skipped - and the code to turn off mutex checks would need to take the mutex, so two mods can't use it at once.

 

Another thing that's needed is that mutex release shouldn't happen until the scripts in the objects have finished.

This means that the API functions need to do something like...

• Update an atomic counter prior to invoking the object script.
• The object script needs to decrement that counter on completion.
• The mutex cannot be taken if the counter is not zero.
• StorageUtil counter on the target object should be atomic enough.

(And with timeouts for when scripts crash out etc)

This would work for the multi-operation mechanic shown above.

 

And for all the old mods that are unaware of this change, they'd get one-by-one operation with mutex, which is probably what they should have had all along.

 

 

I hadn't realised it was so in need of love, or I would have done it myself months ago. I probably have too much on my plate to care right now.

 

[Kimy]

As you pointed out correctly, the mutex has never really worked well enough to justify using it, but it's a severe performance hog that will cause noticeable lag in scenarios when multiple devices are manipulated. I found that most of the time, a simple Utililty.Wait(1.5) between unequip and reeuip will do nicely, though. It's a very simple solution and a very inelegant one, but it works.

[worik]

Probable bug report for DD4.3a

• bound in Laura's STC yoke, harness, gag, arm+leg cuffs
• able to gag-talk with carriage drivers
• unable to use the carriage, the activator to "climb" into the carriage seems disabled
• comments indicate this to be unintended and a general DD issue

 

More details:

• here in (2.) https://www.loverslab.com/topic/107764-devious-devices-lauras-bondage-shop-08-sept-2019-v301/?do=findComment&comment=2764687
• and here by Reesewow https://www.loverslab.com/topic/107764-devious-devices-lauras-bondage-shop-08-sept-2019-v301/?do=findComment&comment=2764716
• Edit: and here https://www.loverslab.com/topic/107764-devious-devices-lauras-bondage-shop-08-sept-2019-v301/?do=findComment&comment=2764777