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

[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.

[piotsze]

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.

[maxsteiner]

I have a question, I have never got the anim filters in this mod to work. I untick "use bound animations" and the others but still I only get the one or two bound animations when in restrains like armbinder or prison chains. The straitjacket however works with every animation, whitch is great. How come I dont get the same with armbinder or prison chains or chackles? I used to get axess to all the anims with the prison chains but after updating to the latest version, there is only two I think. The armbinders has always been a sad affair for me. Sorry to sound like a whining bitch here but it gets really boring really fast with the same two animation over and over. Wouldnt it be possible to open up all animation to all types of restrains even if many of them would look akward? I mean, if I can get it with the straitjacket, wy not the rest of the restrains?

[shiagwen]

do the events happen even with no devices worn ?  (eg. Horny)

[DeWired]

I don't know if it's a right thread to post this, but I have a question for bound combat animations - is it possible to make kill move animations actually relevant and immersive? As in, when character in armbinder kicks bandit to death, last hit isn't done using magically free hands. This is just a pet peeve of mine ? Either that, or maybe completely disable kill moves when bound.

 

[pnutz78]

Hi everyone,

 

I lately have issues with my avatar not opening her mouth when gagged. I tried all of the gags from DDX and it's the same problem for all of them. I thought it may be a problem with the custom body I am using so I uninstalled it and reinstalled bodyslide outfit studio with a plain CBBE curvy (HDT) body -> same problem as before. I read that the zaz animation pack at some point was responsible for chars to open their mouths for gags, but not sure if that is still the case today (old post). Any advice would be very much appreciated.

[Taki17]

14 minutes ago, pnutz78 said:

I lately have issues with my avatar not opening her mouth when gagged.

It's a DD script issue.  For the time being, there is an unofficial fix for it somewhere on a few pages back.

[piotsze]

2 hours ago, pnutz78 said:

Hi everyone,

 

I lately have issues with my avatar not opening her mouth when gagged. I tried all of the gags from DDX and it's the same problem for all of them. I thought it may be a problem with the custom body I am using so I uninstalled it and reinstalled bodyslide outfit studio with a plain CBBE curvy (HDT) body -> same problem as before. I read that the zaz animation pack at some point was responsible for chars to open their mouths for gags, but not sure if that is still the case today (old post). Any advice would be very much appreciated.

 

"GAG FIX" description here:

 

 

"GAG FIX" file shared here:

 

 

Possible also to happen if using Devious Body Alteration mod, reported by others, to author thread - here (FIXED! scroll down couple posts there...):

 

 

[Baxlek]

Is there a way anyone can compile the zadlibs.pex file to remove or comment out line 1311. I have narrowed down my CTD issues to this particular function but cannot seem to figure out a way to recompile the pex into psc.

[Taki17]

As of now, the insertion of butt plugs with an open chastity belt is not allowed, due to the plug script only checking for the belt keyword, if I'm getting this right. Would it be viable to add a check for the permitanal keyword, so that butt plug usage with an open back belt will be possible?

[Rogwar002]

6 hours ago, Baxlek said:

Is there a way anyone can compile the zadlibs.pex file to remove or comment out line 1311. I have narrowed down my CTD issues to this particular function but cannot seem to figure out a way to recompile the pex into psc.

But you know the sourcecode is part of the package, don´t you?

There is no need to decompile a script, because the psc is already there. Maybe you have a closer look to the zip file, if you didn´t install it first hand.

I´m wondering: How did you narrow it down to linie 1311 without the source code?

Just for the fun of it... I will decompile the pex and will have a look what will be in linie 1311...

function ApplyGagEffect(actor akActor)

This function just opens your mouth.?I don´t think this function causes a CTD

 

But I think I have a solution for you. If there is a CTD, perhaps you are missing a mod. MFG console (no joke!) It should be part of SexLabFramework. Have a look to your data folder. There should be an SKSE Plugin namend MfgConsole.dll (in the data\SKSE\Plugins folder of course)

 

 

[Nept.tune]

I was wondering if there was a way to disable the debug devious devices remover, kinda like how "Deviously Cursed Loot" locks the menu whenever in devious devices, so you actually have to escape.

[Zaflis]

2 hours ago, Rogwar002 said:

But you know the sourcecode is part of the package, don´t you?

There is no need to decompile a script, because the psc is already there.

I think he meant compiling psc into pex. Line 1311 is just:

Log("Debug-7")

 

That can't cause any CTD's.

[Baxlek]

8 hours ago, Rogwar002 said:

But you know the sourcecode is part of the package, don´t you?

There is no need to decompile a script, because the psc is already there. Maybe you have a closer look to the zip file, if you didn´t install it first hand.

I´m wondering: How did you narrow it down to linie 1311 without the source code?

Just for the fun of it... I will decompile the pex and will have a look what will be in linie 1311...

function ApplyGagEffect(actor akActor)

This function just opens your mouth.?I don´t think this function causes a CTD

 

But I think I have a solution for you. If there is a CTD, perhaps you are missing a mod. MFG console (no joke!) It should be part of SexLabFramework. Have a look to your data folder. There should be an SKSE Plugin namend MfgConsole.dll (in the data\SKSE\Plugins folder of course)

 

 

Maybe I have a different pex file. Line 1311 for me is 

Input.TapKey(Input.GetMappedKey("Forward"))

Using this function for me on SE with Xbox Controller is causing the CTD issue. it doesn't happen with keyboard and mouse. Everything works fine then. It's just when using a gamepad.

I read in another forum that another mod (Fill Her Up SE) was using the same function. Someone on that forum commented that line out and everything worked fine with that mod after that. All I did was search for the exact same function in this mod and found it in zadlibs.psc. I can edit the psc similarly, but it always fails in Creation Kit's Papyrus Compiler when I try to recompile it.

I was just hoping somone else who is better at recompiling than me could make that edit and post an updated pex file.