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

[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

[Mr Technician]

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?

[Mr Technician]

@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

[donttouchmethere]

13 hours ago, worik said:

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

I don't think it's a bug, more like a fast travel prevention ;D

Weee that's an old one, guess it's since the DD/ZAZ split.

Heavy bondage prevents you from using furniture and carriages.

 

Main issue with that "feature" => zaz furniture can't be used and will get quest scenes stuck that need you to be in zaz furniture to continue.

 

[Lupine00]

18 hours ago, Kimy said:

but it's a severe performance hog that will cause noticeable lag in scenarios when multiple devices are manipulated.

I don't doubt it, though part of that may be due to it not being released when it should.

A mechanism where you could pre-lock the mutex would solve any performance issue for mods that were new enough to use it.

In that case they have to provide their own wrapping lock and unlock calls that disable mutex checks in the individual API calls.

 

I suppose it's also possible to use a bit-locking mechanic, similar to that used in SLAX that would allow you to "mask" locking based on slot masks, so devices with no conflict can get a lock immediately, and only devices with conflicting slots result in lock waits.

 

The device operation completion tracking is another issue again; that would solve all those issues we see now where slot-overlapping devices get in races with each other.

 

But I appreciate that if I don't implement it, and just expect it to magically happen, then it's just a lot of wishful thinking, so I guess I'll leave that there for now.

 

 

 

However, would be nice if the API could - one day - gain a way to modify a device's "genuinely locked" status.

I haven't looked at how hard it is, but I'd have though there was just a piece of state to flip somewhere?

 

That would be a generally useful new capability, and one that has been requested previously, I think?

While it might not have been envisaged in the design of that feature, it would still be useful.

It would be a nice additional action for NPCs to perform in DCL, as part of the "device comments" feature, for example.

And DF has immediate uses for it, which is why I brought it up.

[Mr Technician]

10 hours ago, donttouchmethere said:

I don't think it's a bug, more like a fast travel prevention ;D

Weee that's an old, guess it's since the DD/ZAZ split.

Heavy bondage prevents you from using furniture and carriages.

 

Main issue with that "feature" => zaz furniture can't be used and will get quest scenes stuck that need you to be in zaz furniture to continue.

 

Oh... That's good to know also.

Thank You! ? 

[LazyBoot]

15 hours ago, worik said:

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

DD does explicitly prevent activating the carriage when wearing heavy restraints

[Kimy]

5 hours ago, Lupine00 said:

However, would be nice if the API could - one day - gain a way to modify a device's "genuinely locked" status.

I haven't looked at how hard it is, but I'd have though there was just a piece of state to flip somewhere?

Not really easy, as this flag is set/kept in the equip script, which is not exposed to the API. Not impossible either, of course. Just...work, that will involve me having the redesign the feature.

 

I cannot recall this feature getting requested before, either. As I said, the use-case for this feature was for the user to customize their "bondage experience" by allowing them to wear devices in a purely cosmetic manner. While this doesn't necessarily mean that unlocked devices should be able to "protect" a slot from DD mods putting actually locked devices in there, exposing this feature to the API was indeed not intended.

 

[Zaflis]

4 hours ago, Kimy said:

Not really easy, as this flag is set/kept in the equip script, which is not exposed to the API. Not impossible either, of course. Just...work, that will involve me having the redesign the feature.

 

I cannot recall this feature getting requested before, either. As I said, the use-case for this feature was for the user to customize their "bondage experience" by allowing them to wear devices in a purely cosmetic manner. While this doesn't necessarily mean that unlocked devices should be able to "protect" a slot from DD mods putting actually locked devices in there, exposing this feature to the API was indeed not intended.

Just a few mentions about it before, i still would disable the whole device manipulation function entirely if it was an option (MCM? TES5Edit?). If i play with Cursed Loot sometimes i feel like it's a necessity to go through all my restraints and manipulate them, and that's a chore. Manipulating is same as choosing an easy way out of a problem because it's just handed to you. It's trivializing and boring to have such items that you can just insta-take off when you want without even keys. Do not like.

In other words, the current way is semi-forcing the "cosmetic" gameplay to bondage enthusiasts.

 

On top of that, there are mods like Devious Followers that make you "voluntarily" equip items on yourself. If you manipulate them in the process, it loses half of the fun.

[A Hobbit]

I'm having an issue and I'm not sure what's causing it since my playthrough was fine for a while.  Whenever a mod equips a blindfold (haven't tried manually equipping one yet) my character will visibly wear a blindfold and I get the effect from it but the actual item won't appear in my inventory (or if it does, it will say that it's not equipped and if i try equipping it it tells me I'm already wearing one).  This means that if a blindfold is equipped there is no way to remove it (even the safe word from DCL doesn't remove it).  Also, I'm using DDi 4.3, not 4.3a if that has anything to do with it.

[Lupine00]

18 hours ago, Kimy said:

I cannot recall this feature getting requested before, either. As I said, the use-case for this feature was for the user to customize their "bondage experience" by allowing them to wear devices in a purely cosmetic manner. While this doesn't necessarily mean that unlocked devices should be able to "protect" a slot from DD mods putting actually locked devices in there, exposing this feature to the API was indeed not intended.

It's certainly possible the request wasn't on the DD forum  

 

I want it for Devious Followers. Many people use the manipulate feature to put on devices in an easy to remove way to satisfy the follower.

 

The follower doesn't even have a way to know if they are really locked on. Which limits the follower's ability to respond to that however might be interesting.

 

And it would certainly be useful for the follower to be able to lock items in place as a punishment, or just for fun.

 

As discussed, that currently requires removal and re-add of the device, which is surprisingly slow and convoluted if you want to do it for all the worn devices because it involves discovering the actual worn devices, not just keywords. Unless there's an easy way to get around that I haven't noticed?

[Zaflis]

3 hours ago, Lupine00 said:

As discussed, that currently requires removal and re-add of the device, which is surprisingly slow and convoluted if you want to do it for all the worn devices because it involves discovering the actual worn devices, not just keywords. Unless there's an easy way to get around that I haven't noticed?

If it takes a while to do it, you can do it take a while lorewise too. Follower tells player to stand still or kneel while she inspects restraints, and then controls are disabled during that time.

 

Devious Followers was just one thing though, there are other smaller mods and even Cursed Loot that has it as downside. Devious Helpers is one mod that comes to mind, follower used restraints that you carry to lock them for certain time. If they are altered, well, you can just take them off right away.

 

Cursed Loot has self-bondage feature where you may lock your items on yourself. Again same thing, if you manipulated them all, there's the end of that. The will to manipulate at least armbinders might have been strong when you first got into one, thinking that you don't want it to happen in a dangerous place. But there goes another chance to trigger all of our devious defeat mechanisms.

 

What if the manipulation had to be done on a workbench, and only if device has a keyword that it can be manipulated, or not with a keyword that prevents it?

Hold on... doesn't all yokes already have a keyword like that? So we could basically give it to all other restraints too with a patch?

[Kimy]

There is a API function called ForceEquipDevice() that will handle the unquip part for you (as the name suggests, it will force the device given into the slot even if it is already occupied, EXCEPT when the already equipped item is a quest item.

 

Other than that, I will note the request to redesign that system, but as a "I'll consider it", not as a promise. I will not release DD feature updates anytime soon anyway, as the next "Kimy timeslice" will go into DCL, which I want to work on a new major update next.

[Lupine00]

55 minutes ago, Kimy said:

There is a API function called ForceEquipDevice() that will handle the unquip part for you (as the name suggests, it will force the device given into the slot even if it is already occupied, EXCEPT when the already equipped item is a quest item.

 

Other than that, I will note the request to redesign that system, but as a "I'll consider it", not as a promise. I will not release DD feature updates anytime soon anyway, as the next "Kimy timeslice" will go into DCL, which I want to work on a new major update next.

ForceEquip would be useful. It's a skyrim pain that walking the slots takes slightly longer than an Amazon delivery. No way around that though. Would probably be an issue even for lock flipping.

[Kimy]

As I said, I could implement it in a way that would allow people to modify these locks via script, that would be very cheap, CPU-wisely, but it would require me to re-implement the entire thing. I have put it on the wishlist for future reference.

[Lupine00]

17 hours ago, Kimy said:

As I said, I could implement it in a way that would allow people to modify these locks via script, that would be very cheap, CPU-wisely, but it would require me to re-implement the entire thing. I have put it on the wishlist for future reference.

It would be double win if any major change also addressed the issue of efficiently finding all the devices on a character and getting references to them in a dynamically sized array, that would simplify a lot of clunky logic that mods seem to come up with.

 

Right now, most mods try to deal only with keywords as much as they can, because it's easy and efficient.

They may add a specific device, but if you want to find and work with specific devices - or kinds of devices - that might be present, you have to write a lot of code.

 

 

I had expected that keywords would easily do something like identify a rubber suit, or a leather harness, but it's much more complicated than that. Suit means something to the implementation, but it doesn't describe things that look like suits. And material isn't keyworded at all - though I admit that could be awkward.

 

 

The slot walker in SLD shows that identifying each of the fundamental device-kinds requires additional special-case processing beyond checking a single keyword. In some cases it needs lists of specific device IDs (which is clearly brittle) because otherwise you can't tell some devices apart. And hoods ... hoods ... hoods are a very complicated situation, as I'm sure you know. Some are blindfolds, some are gags, some are both, some are neither. Sometimes they go in the helmet slot, sometimes the circlet slot, sometimes both, some might even go in neither.

 

So there is a piece of special case code for just about every class of devices, simply to identify them as that conceptual kind of device. Possibly, it could have used a keyword here or there where it used an ID list (because I wasn't aware of the right keyword), but the special case code would still be there, just a little less brittle.

 

Possibly, in some cases I had to go down the ID path because the keywords sometimes had bugs (I think this was the case with hoods). Front cuffs might have been another tricky case, despite there being a keyword.

 

I can get accurate details if you are interested.

 

 

SLD can afford to do so much processing because of its background update process that only deals with the PC, but doing the same thing in SLAX, for arbitrary lists of NPCs has caused me some headaches, and two major rewrites. Getting it to perform responsively and not overload the system is a fine line to walk.

 

I have to run a parallel dependent scanner that gradually updates the item status of NPCs that are found by the main scanner. It's not rocket science, but it is probably more bother than most modders would put up with.

 

 

Of course, DD isn't the only problem for SLAX. I have to get the worn items anyway, to determine nakedness or find bikinis. But I only need to look at a small range of slots to do that.

 

In contrast, to find all the DDs requires looking at all the slots - or walking the inventory, which is probably worse, I didn't even consider that. Or some spaghetti code that mixes keyword checking and special case checks, like SLD.

 

 

However... If keywords indicated material - even at a crude level -  I might be able to skip that entirely and could simply check if a character is wearing leather, rubber or chains.

 

 

I guess any change is too late to help me anyway, but in terms of usability for the future, being able to get a list of DDs almost instantly could make it easier for mods to create sensible interactions the worn devices.

 

And I know that users are always asking for material related features, because they like rubber, or leather, but not both and ... well you know ...

 

 

In the short term, tweaking some keywords might yield notable benefits. There are a few kinds of items that are tricky to work with because of keyword overlap. Suits and hoods mainly. Probably wrist cuffs too. The venerable age of that latter class of devices may be the cause of oddities there.

 

Mostly categorisation starts with a top level keyword and then checks for the special case ones, and that leaves you with some category of left over items...

e.g. Suits, you find relaxed dresses, strict dresses, breast yokes, and then what's left is probably an actual "suit".

 

Other categories are similar. You have to check some special cases, and sometimes keywords aren't enough to filter them out.

 

 

Don't take this the wrong way - the keywords have exploded in capability since DD3, and there are so many items - it's a huge number of items to deal with and get set up correctly. But that huge space of items creates new challenges for consumer modders too.