Devious Devices Framework Development/Beta

[UnEvenSteven]

In regards to Timed Locks what if a mod author wants to have a timed device that's inescapable and can't be removed until the timer is over. I don't speak for Laura but IIRC she was wanting to use timed locks and have them in her shop mod. I think the intention was to have our characters locked in them until the timer is over and couldn't be removed otherwise.

 

Unless I was understanding the issue incorrectly you may want consider adding a way to make a timed device inescapable until the timer is up. Maybe check if the timed device is flagged as a quest device and make it inescapable if it is? That way any regular timed device could be removed if the lock is bypassed but a timed device couldn't be removed until the timer is over if it's a quest device.

[DeWired]

1 hour ago, Kimy said:

Hm, good question. So far, I'd think the code worked as intended. After all, if you struggle out of a restraint or cut it open, it wouldn't matter if the lock is timed, or not. You'd be free anyway. Not sure if this should be changed?

Hm.. Seems reasonable. Well, then - what about lockshield timer? Shouldn't it block lockpicking attemts, at least?

Also - how about adding a feature of so called "divine powers to prevent escape" - third timed effect, in addition to TimedUnlock and LockShieldTimer? ?

Because as I see it - features must be shaped by usage, which means, things that are done right now in non-framework device scripts, shoud in time migrate into framework. And, for example, Dollmaker Billboard Suit from DCL can't be remade as a framework device right now. At least, I think so.

[Kimy]

2 hours ago, UnEvenSteven said:

In regards to Timed Locks what if a mod author wants to have a timed device that's inescapable and can't be removed until the timer is over. I don't speak for Laura but IIRC she was wanting to use timed locks and have them in her shop mod. I think the intention was to have our characters locked in them until the timer is over and couldn't be removed otherwise.

 

Unless I was understanding the issue incorrectly you may want consider adding a way to make a timed device inescapable until the timer is up. Maybe check if the timed device is flagged as a quest device and make it inescapable if it is? That way any regular timed device could be removed if the lock is bypassed but a timed device couldn't be removed until the timer is over if it's a quest device.

Just set all escape chances to zero, add the zad_BlockGeneric keyword to tell helpful blacksmith to not be helpful, and you'd have a very much inescapable timed device.

[Zaflis]

13 hours ago, Kimy said:

Hm, good question. So far, I'd think the code worked as intended. After all, if you struggle out of a restraint or cut it open, it wouldn't matter if the lock is timed, or not. You'd be free anyway. Not sure if this should be changed?

That's not it, the code doesn't get to the struggle and "struggle chance" set in property to validate if you get free. Because device doesn't have a key you get free instantly when trying any escape option. Even if setting struggling very hard to do.

[DeWired]

1 hour ago, Zaflis said:

That's not it, the code doesn't get to the struggle and "struggle chance" set in property to validate if you get free. Because device doesn't have a key you get free instantly when trying any escape option. Even if setting struggling very hard to do.

Well - create unique key, set device to use it, never spawn it.

[Zaflis]

1 hour ago, DeWired said:

Well - create unique key, set device to use it, never spawn it.

Yeah i used this workaround to it. Speaking of which, it would be very handy if DD framework provided a hidden key for that purpose. DCL has something like "Kimy's key" but using that would give a dependency of DCL to your mod.

[UnEvenSteven]

7 hours ago, donttouchmethere said:

The new SliderGroup file for UUNP works for me (while building BRRF separately).

No invisible devices so far and also the glove/corsets/hobble skirts/suits fit the UUNP special body.

Saves a lot of clicking =D

 

That's good to hear, one confirmation the new SliderGroup xml for UUNP working correctly. ?

 

 

Quote

Unrelated to the SliderGroup file (same outcome with or without SliderGroup file):

All DD restrictive boot variations clip since DD5beta

I didn't install the male DD plugin, but the BRRF one. Maybe there is a mixup in BS files?

 

Not sure about this one. I don't normally use UUNP but for a quick test I built a UNP body, UNP Restrictive Boots, tossed in some UNP textures and checked in-game. I didn't see any clipping with the boots, tested ebonite, leather and transparent versions. Even tried some different UNP shapes and still couldn't get clipping. Judging by your screenshots you don't seem to be using some extreme body shape either.

 

Are you by chance using a different skeleton other than the one that installs with XPMSE? Can anyone else using UUNP check clipping with Restrictive Boots?

 

Also after checking the files, Beast Race Refits don't seem to overwrite Restrictive Boots so no problem there.

 

 

7 hours ago, donttouchmethere said:

The hooked elbow shackles are great but also have many animation glitches (try keep pressing forward+strafe right^^)

I guess it's still worked on right?

 

Noticed that as well, my characters arms keep trying to be put in the yoke position. The bound combat animations don't seem to play either when locked in the elbow shackles. I mean my character moves when attacking but there's no kicking animation.

 

[Kimy]

7 hours ago, Zaflis said:

That's not it, the code doesn't get to the struggle and "struggle chance" set in property to validate if you get free. Because device doesn't have a key you get free instantly when trying any escape option. Even if setting struggling very hard to do.

For non-keyed devices that are supposed to be hard to remove, you'd also need to set LockAccessChance to something higher than zero. 100% makes the device inescapable by unlocking. The timed unlock should still work if you're setting the device to automatically unlock.

[Kimy]

6 hours ago, DeWired said:

Well - create unique key, set device to use it, never spawn it.

Or that!

[Kimy]

4 hours ago, Zaflis said:

Yeah i used this workaround to it. Speaking of which, it would be very handy if DD framework provided a hidden key for that purpose. DCL has something like "Kimy's key" but using that would give a dependency of DCL to your mod.

Sure, I can provide that.

 

I can't guarantee that certain mods won't start selling it, though. :S

[Kimy]

8 hours ago, donttouchmethere said:

The hooked elbow shackles are great but also have many animation glitches (try keep pressing forward+strafe right^^)

I guess it's still worked on right?

Yes, that's the reason why this device isn't yet listed in the change log. The problem is indeed with the animation set. It works mostly right, but it lacks combat-movement animations. The creator of that device even provided me with some, but I have zero clue about which animation name corresponds to which exact animation. I normally got entire sets with the correct FNIS names to merge, which I can do without having a clue about the naming scheme. In this case I'd need to properly rename them. But I couldn't find any documentation about these names anywhere so far, so that's kind of a roadblock for this device. I don't have the time to try renaming 97 animations one by one and see what happens in game.

 

 

[Kimy]

On 10/24/2020 at 4:45 PM, titlover123 said:

How do i see the settings of a contraption? i don't think i've ever seen the instructions for them anywhere.

They are visible in CK, when opening the script properties on the device.

[merManc]

1 hour ago, UnEvenSteven said:

Can anyone else using UUNP check clipping with Restrictive Boots?

 

I get a bit, but not in the same place:
 

Spoiler

 

 

 

It only happens in that one exact spot, on the front of the left thigh, and I could only see it when walking or when going through the animation that plays when taking off the boots. Both the leather and ebonite versions were the same. It didn't happen when walking in a straitjacket, so something about the walking animation I use could be causing it (not a clue which one it is, I'm afraid, as I put together a pack from various sources years ago, but it's a subtle one.) However, as it also happens with the included devious animation for removing the boots it can't really be blamed on idles and animations.

 

I did check the previous bodyslide files I had from the current release version and saw the same thing. I hadn't noticed it before. Shows how much I've been using those boots, I guess!

 

And I also checked if racemenu morphs might be something to do with it (I build with tri files and my character has slightly chunkier legs than standard thanks to morphs.) The boots correctly expand and contract when playing around with the various leg sliders, and the clipping still happened with the unaltered uunp preset I build for (MRB) so that seems fine. This is all using XPMSE.

[UnEvenSteven]

@Kimy In a follow up to my previous post regarding devices and the animation filter I finally managed to get around to testing the armbinder, yoke and the pet suit while my character was also wearing a ball gag or both versions of the chastity belt. Without a gag and belt the filter seemed to be working correctly, was getting armbinder animations while locked in one, yoke anims when wearing a yoke, etc.

 

However whenever my character was wearing a ball gag, which normally blocks oral animations, and locked in an armbinder I was still getting bound oral animations. Same for the yoke and pet suit, would get the bound oral animations even though my character was locked in a ball gag. Would also get bound vaginal or anal animations while wearing either versions of the belt when locked in an armbinder, yoke or pet suit.

 

Have two logs here, the second one simply covers an oral animation while wearing a ball gag and pet suit. Gave up trying to get it yesterday but got the animation right away earlier today ?

 

Papyrus.0.log Papyrus.1.log

 

Even though the logs have "Permit Oral FALSE", "Permit Vaginal FALSE" or "Permit Anal FALSE" when starting animations the bound filter doesn't seem to pick up on those and selects those animations anyways.

 

An idea, would it be possible or just too much trouble to have a separate hotkey to cycle through bound sex animations? Similar to how you can cycle through normal sex animations?

 

[UnEvenSteven]

@Kimy I can confirm that all the CBBE devices built with the new SliderGroup xml are working correctly, checked all of them. Well except for one device, Transparent Catsuit High Heels. A slider simply doesn't exist for CBBE so the device was invisible when testing. Of the 27 that downloaded the UUNP version only one has reported that it's working correctly so. No reports of invisible devices yet except for the aforementioned heels.

 

While testing all these devices I noticed some issues with the preview/ground objects of certain devices. The mesh that's used for most rope devices had some issues that kept if from showing your inventory and would get stuck in the air if dropped, same for the Spiked Ebonite Collar. The Studded Ebonite Collar was simply pointing to a non-existent mesh.

 

So I fixed issues with the ground meshes for the devices I mentioned and created a .esp with the necessary changes for the Studded Collar. As a bonus I created new ground objects for elbowbinders and made appropriate changes in the .esp. All elbowbinders point to the new ground meshes and have the proper TextureSets applied to them (red textures for red elbowbinder). Also went through the tedious process and assigned proper TextureSets for all the colored rope devices, black for black, red for red, etc.

 

Finally I included pre-built devices for the Transparent Catsuit High Heels for CBBE users. UUNP users will be overwriting them when they build devices but at least they won't be invisible for CBBE users. It's not perfect as it is just a temporary solution. Some of the textures for the heels had incorrect dimensions, fixed those as well.

 

Nothing special nor is it really important, just some polish. Hopefully you'll be able to easily carry over/merge the changes in the .esp over to the DD Framework files.

 

 

DDInventoryGroundObjects.7z

 

EDIT: Forgot to mention, while checking on issues with UUNP-based restrictive boots clipping I noticed the leather version was using incorrect textures. Included a fixed version.

 

/incoherent post

[UnEvenSteven]

34 minutes ago, donttouchmethere said:

So for now it's not conclusive if it's a DD BS issue or something more sinister in my LO.

 

This clipping issue is indeed odd. I don't use UUNP, I don't have a personal and polished UUNP setup like I do for CBBE. Yet I can quickly build a UUNP-based body and UUNP-based devices and not have clipping with Restrictive Boots.

 

Is your character's body shape the same as the body shape that was used when building devices? For example, you built a UNPB body and any devices you built were also UNPB?

 

 

34 minutes ago, donttouchmethere said:

basically there is only one base mesh for all variations, everything else are textures if I understand it right

 

You are correct regarding textures but it's also the material/shader settings that are different and thus require three different sets of meshes for the restrictive boots ?

 

 

[El_Duderino]

9 hours ago, donttouchmethere said:

I will experiment a bit more and give feedback if I found out where I messed up.

Which UUNP preset are you using? It could just be that the particular preset you're using has an issue in the boots' slider set, especially if it isn't one of the standard ones (UUNP-UNP, UNPB, zero-sliders, etc.). UUNP contains dozens of presets by default and I know that it's all too easy to miss some clipping in one of the more "obscure" presents for the person who creates the model's slider set.

 

10 hours ago, donttouchmethere said:

[Anim Filter Test] Various outcomes:

Is that a skeever in two of the pictures? As far as I'm aware, DD is only friendly for the playable races. Which makes me wonder if the filter even acknowledges animals and creatures in a scene. I don't think so, because, again as far as I know, animations for that exist only exist outside of DD.

[Kimy]

17 hours ago, UnEvenSteven said:

@Kimy I can confirm that all the CBBE devices built with the new SliderGroup xml are working correctly, checked all of them. Well except for one device, Transparent Catsuit High Heels. A slider simply doesn't exist for CBBE so the device was invisible when testing. Of the 27 that downloaded the UUNP version only one has reported that it's working correctly so. No reports of invisible devices yet except for the aforementioned heels.

 

While testing all these devices I noticed some issues with the preview/ground objects of certain devices. The mesh that's used for most rope devices had some issues that kept if from showing your inventory and would get stuck in the air if dropped, same for the Spiked Ebonite Collar. The Studded Ebonite Collar was simply pointing to a non-existent mesh.

 

So I fixed issues with the ground meshes for the devices I mentioned and created a .esp with the necessary changes for the Studded Collar. As a bonus I created new ground objects for elbowbinders and made appropriate changes in the .esp. All elbowbinders point to the new ground meshes and have the proper TextureSets applied to them (red textures for red elbowbinder). Also went through the tedious process and assigned proper TextureSets for all the colored rope devices, black for black, red for red, etc.

 

Finally I included pre-built devices for the Transparent Catsuit High Heels for CBBE users. UUNP users will be overwriting them when they build devices but at least they won't be invisible for CBBE users. It's not perfect as it is just a temporary solution. Some of the textures for the heels had incorrect dimensions, fixed those as well.

 

Nothing special nor is it really important, just some polish. Hopefully you'll be able to easily carry over/merge the changes in the .esp over to the DD Framework files.

 

 

DDInventoryGroundObjects.7z 1.65 MB · 1 download

 

EDIT: Forgot to mention, while checking on issues with UUNP-based restrictive boots clipping I noticed the leather version was using incorrect textures. Included a fixed version.

 

/incoherent post

That's awesome! I will merge these! Thank you!

[DeWired]

@Kimy If you have seen my previous comment about "moonwalking issue" - please disregard code there, I did more research and found a better place to patch. If you hadn't seen it - to recap, there is an issue when bound NPCs are killed and looted, they start "moonwalking" - walking in place despite being dead. Now, I narrowed it down to zadBoundCombatScript.psc, proposed change is:

$ diff -Naur zadBoundCombatScript.psc.old zadBoundCombatScript.psc
--- zadBoundCombatScript.psc.old        2020-10-27 10:38:54.267066300 +0300
+++ zadBoundCombatScript.psc    2020-10-27 10:39:02.458524300 +0300
@@ -361,7 +361,7 @@
        FNIS_aa.SetAnimGroup(akActor, "_mtturn", 0, 0, "DeviousDevices", Config.LogMessages)
        FNIS_aa.SetAnimGroup(akActor, "_mtidle", 0, 0, "DeviousDevices", Config.LogMessages)
        akActor.SetAnimationVariableInt("FNIS_abc_h2h_LocomotionPose", 0)
-       if akActor != libs.PlayerRef
+       if akActor != libs.PlayerRef && !akActor.isDead()
                akActor.EvaluatePackage()
                Debug.SendAnimationEvent(akActor, "IdleForceDefaultState")
        EndIf

As far as I tested it, it fixes issue, and contrary to previous suggested patch, it doesn't cause reanimated NPCs to be stuck in bound pose ?

[Kimy]

4 minutes ago, DeWired said:

@Kimy If you have seen my previous comment about "moonwalking issue" - please disregard code there, I did more research and found a better place to patch. If you hadn't seen it - to recap, there is an issue when bound NPCs are killed and looted, they start "moonwalking" - walking in place despite being dead. Now, I narrowed it down to zadBoundCombatScript.psc, proposed change is:

$ diff -Naur zadBoundCombatScript.psc.old zadBoundCombatScript.psc
--- zadBoundCombatScript.psc.old        2020-10-27 10:38:54.267066300 +0300
+++ zadBoundCombatScript.psc    2020-10-27 10:39:02.458524300 +0300
@@ -361,7 +361,7 @@
        FNIS_aa.SetAnimGroup(akActor, "_mtturn", 0, 0, "DeviousDevices", Config.LogMessages)
        FNIS_aa.SetAnimGroup(akActor, "_mtidle", 0, 0, "DeviousDevices", Config.LogMessages)
        akActor.SetAnimationVariableInt("FNIS_abc_h2h_LocomotionPose", 0)
-       if akActor != libs.PlayerRef
+       if akActor != libs.PlayerRef && !akActor.isDead()
                akActor.EvaluatePackage()
                Debug.SendAnimationEvent(akActor, "IdleForceDefaultState")
        EndIf

As far as I tested it, it fixes issue, and contrary to previous suggested patch, it doesn't cause reanimated NPCs to be stuck in bound pose ?

Okies, added this patch instead!

[Kimy]

Devious Devices 5 Beta 9

- Added: New and cleaned up Bodyslide slider sets.
- Added: Missing levelled item list for hoods.

- Added: New inflatable panel gag variant
- Fixed: Removing restraints from dead NPCs no longer causes them to become reanimated in funny ways.
- Fixed: Added two missing textures for the wooden DDC yoke.
- Fixed: The animation filter will no longer ignore blocked sex interactions when picking bound animations.
- Fixed: Wearing an anal or vaginal plug will now properly block "access", even when no belt is worn.

 

Devious Devices 5 Beta 9 Download link (full release):
 
https://mega.nz/file/jJtw3arB#wqgkLIOs8qnCPZ0Nw-fHNMXnt0fpQsBBOxhs1JEZZgE

 

 

For those of you who do not want to download the full release:

 

Devious Devices 5 LE Beta 1 To Beta 9.7z

 

Attention:

- The delta patch does NOT contain the new Bodyslide slider groups.
- The delta patch does NOT contain the new UUNP mesh for the restrictive boots. If you are using UUNP, be advised that running Bodyslide after installing the delta patch, the restrictive boots will be overwritten with a default model that's likely to clip horribly on your character.

[zarantha]

Loading a saved config from a different version seems misleading. It says that it's aborting, but my old config is actually loaded. I started a new game because of a different mod when I went from beta 8 to beta 9.

 

[Kimy]

1 hour ago, donttouchmethere said:

Tests about NPC-NPC action while wearing devices.

To test:

Sexlife => NPC-NPC and NPC-Creature

Pet Collar => Collared NPC-NPC and NPC-Creature

SLAC=> NPC-Creature (also Creature-Creature, but we don't need that here right?^^)

 

I had to split the tests because they behave differently to the filter:

Sexlife => Seems to ignore the filter so far, thus can't cause stuck scenes

SLAC => From what I saw ingame it also ignores the filter (or the filter ignores creatures)

 

This leads me to Pet Collar. Pet Collar scenes don't ignore the worn devices and cause stuck Solo SL scenes.

Here is a log where 2 Pet Collar triggered NPC-NPC scenes get stuck and never finish.

Papyrus.DDPC2solostuck.log 880.73 kB · 0 downloads

 

  Reveal hidden contents

The stuck actors in the log are:

 

 

Expected behavior of the filter involving non-humanoid creatures is to do...nothing but hiding any worn wrist restraints.

[Kimy]

Intended behavior is that the filter should catch all SexLab animations, no matter which mod started them. DD mods can use the framework API to call valid animations for bound characters in the first place, so the filter would never have to replace any animation, ever. DCL does that (which is probably why I didn't notice for weeks that the filter isn't even working, lol). Mods do not have to update to or be aware of DD5 to invoke/use the filter. It should work with -any- SexLab mod.

 

Preventing awkward situations is why the filter exists in the first place, btw.

 

People who totally don't ever want to watch any bound animations can uncheck the "Use Bound Animations" MCM toggle. In which case the filter would just making sure that chastity devices and gags are respected.

[LazyBoot]

17 hours ago, Kimy said:

- Fixed: Wearing an anal or vaginal plug will now properly block "access", even when no belt is worn.

Not entirely sure how I feel about this change... 

On the one hand it does make sense, but on the other it is a change* compared to how the DD filter has done things in the past.

 

EDIT: Half tempted to ask for a keyword that could make specific plugs non-blocking...

 

* And as we all know: change is scary! ?