Devious Devices Framework Development/Beta

[zaira]

Do I understand correctly that Zaz armor support has been dropped or is planned to be dropped?

[LazyBoot]

Do I understand correctly that Zaz armor support has been dropped or is planned to be dropped?

According to the latest commits to github, zaz animation pack is completely removed as a master as of about 3-4 days ago.

[zaira]

So sad

[Kimy]

There is honestly no good reason to have ZAP as a master for DD. ZAP and DD have two mostly disjunct topics. The DD framework made next to no use of ZAP content - with some very minor exceptions, such as the animation filter we decided to implement on our end in DD 4.0. The ZAP animation filter didn't support half of the devices we have and was unable to use newer bound sex animations not shipping with ZAP. Also, when we made the decision, ZAP was unmaintained for over a year, and stuff started to break left and right. We had to fix so many ZAP related things in DD that it was just a much cleaner solution to cut loose the few bits the two frameworks were actually integrated by.

 

In the end, ZAP is mostly about furniture bondage, DD is about wearable restraints. There relate more like sister mods than parent and descendant. They still are closely related in spirit, and people can still use them together. Except for the lightweight bondage code in ZAP, which always was incompatible with DD's, the two mods can still be used in the same content mod with no hassle. For content mods, almost nothing has changed. They can still add ZAP as a dependency together with DD and use both frameworks. No DD content mod has to remove ZAP as a master just because the framework did.

For example, Cursed Loot still uses both, as I make use of ZAP furniture. I don't use ZAP's bondage devices code of course, but no DD mod has any reason to - providing a better framework for wearable restraints is the very reason why DD was started, after all.

 

I fail to see how it would be possible to make changes to the new DD escape system in other ways than via a patch against the original DDI scripts.

[...]

You do realize you come off as incredibly arrogant when saying it that way?

 

I understand that you really love bashing me at every opportunity given, for whatever I did to deserve that. But if you publicly accuse me of arrogance, I challenge you outlining a method to make changes to the escape system WITHOUT touching any of DDI's scripts. I -honestly- can't see one.

[Ekirts Ykcul]

Hi,

 

thanks for the new Beta and sharing your development with the common folk.

The new animations i have seen so far, straitjacket and armbinder, look really great.

 

I've found one problem with the straitjacket (the model looks amazing btw.). It seems as if the debuff for walking speed / encumbrance conflicts with SOT Hardcore Encumbrance

As soon as i equip it, my characters carrycapacity drops from 600 to -600. Movement is made nearly impossible. I tried the extreme version of the hobbled dress. Here the drop in carry capacity goes from 600 to -300. The same problem existed in the release version with the hobbled dress if i remember correctly. I solved it by uninstalling the hardcore encumbrance mod.

Would be nice to use both. But if there is no easy solution to be implemented, i will probably ditch SOT in favor of your great work.

 

Thanks for all the effort.

Have fun.

 

[Kimy]

Bug report.

 

Vaginal Piercing (Soulgem) display incorrect messages after selecting choice in device menu.

Property zad_DeviceMSG set to incorrect menu (numbers in menu does not match to numbers in script).

 

Fixed. Thanks!

[Kimy]

I noticed that you can "unlock" anything even if you do not have the keys. The attempt will fail but the message that pops up says something about being unable to insert the key in to the lock. I can imagine this could get rather annoying with something like DCLs specialized keys, as there would be no way of knowing, if you have the right key or not.

 

The way the system is set up is that the conditionals in the device messages have no way to know what exact key (if any) is needed to unlock the item, so the "Unlock" option is always displayed. This was a little compromise we had to make to allow much easier creation of custom items and reuse of framework assets (otherwise you'd have to create a custom message every time your item is using another key).

 

It's good practice to mention what key is needed in the device description and/or item messages, so users will know what key is needed.

[Kimy]

Elbow binder masturbation animation is currently being played as if there is no armbinder on.

 

Fixed that!

 

Elbow binder masturbation animation is currently being played as if there is no armbinder on.

 

The same animations play even with a chastity belt equipped when you select the "masturbate" option.

 

 

 

Fixed that, too!

[Kimy]

 

One slight issue, however. The new system that prevents certain items being equipped or removed when wearing wrist restraints is a great idea, however it applies to strap-ons equipped by sexlab. While obviously bound characters are less likely to be wearing the strap-on, if they do it gets removed at the start of every animation stage.

 

Aaaand fixed that!

[WaxenFigure]

There is honestly no good reason to have ZAP as a master for DD. ZAP and DD have two mostly disjunct topics. The DD framework made next to no use of ZAP content - with some very minor exceptions, such as the animation filter we decided to implement on our end in DD 4.0. The ZAP animation filter didn't support half of the devices we have and was unable to use newer bound sex animations not shipping with ZAP. Also, when we made the decision, ZAP was unmaintained for over a year, and stuff started to break left and right. We had to fix so many ZAP related things in DD that it was just a much cleaner solution to cut loose the few bits the two frameworks were actually integrated by.

 

In the end, ZAP is mostly about furniture bondage, DD is about wearable restraints. There relate more like sister mods than parent and descendant. They still are closely related in spirit, and people can still use them together. Except for the lightweight bondage code in ZAP, which always was incompatible with DD's, the two mods can still be used in the same content mod with no hassle. For content mods, almost nothing has changed. They can still add ZAP as a dependency together with DD and use both frameworks. No DD content mod has to remove ZAP as a master just because the framework did.

For example, Cursed Loot still uses both, as I make use of ZAP furniture. I don't use ZAP's bondage devices code of course, but no DD mod has any reason to - providing a better framework for wearable restraints is the very reason why DD was started, after all.

 

 

 

I fail to see how it would be possible to make changes to the new DD escape system in other ways than via a patch against the original DDI scripts.

 

[...]

You do realize you come off as incredibly arrogant when saying it that way?

 

 

I understand that you really love bashing me at every opportunity given, for whatever I did to deserve that. But if you publicly accuse me of arrogance, I challenge you outlining a method to make changes to the escape system WITHOUT touching any of DDI's scripts. I -honestly- can't see one.

 

I was not offended by Kimy's response. I understand there is some sensitivity about this topic from posts in the past.

 

I for one am looking forward to seeing what the mods that use this framework do with all of the changes since I'd bet most of the changes were made to enable new features in those mods.

[KomradePavlov]

Just a quick question unrelated to the ZAP discussion:
I don't need to use the Special Edition to use this mod right? I don't remember that being a requirement ever, but the FNIS 7.0 bit is on the SE Nexus page.

I just want to know if I need to switch to the SE if I want to continue with DD mods, or if I just have to grab FNIS 7.0 from it's nexus page and manually install it.

 

I also love the fact that you guys put straitjackets in. 100% my most favorite restraint ever!

[LazyBoot]

Just a quick question unrelated to the ZAP discussion:

I don't need to use the Special Edition to use this mod right? I don't remember that being a requirement ever, but the FNIS 7.0 bit is on the SE Nexus page.

I just want to know if I need to switch to the SE if I want to continue with DD mods, or if I just have to grab FNIS 7.0 from it's nexus page and manually install it.

 

I also love the fact that you guys put straitjackets in. 100% my most favorite restraint ever!

This is not for skyrim SE, and you'll want to use the non-SE version of FNIS too.

[CovertDemon]

What's the difference between the current gag dialogue system and the upcoming one?

[KomradePavlov]

 

Just a quick question unrelated to the ZAP discussion:

I don't need to use the Special Edition to use this mod right? I don't remember that being a requirement ever, but the FNIS 7.0 bit is on the SE Nexus page.

I just want to know if I need to switch to the SE if I want to continue with DD mods, or if I just have to grab FNIS 7.0 from it's nexus page and manually install it.

 

I also love the fact that you guys put straitjackets in. 100% my most favorite restraint ever!

This is not for skyrim SE, and you'll want to use the non-SE version of FNIS too.

 

 

Ah wait, I'm a fool! Totally didn't notice the beta versions in the regular FNIS page. Woopsie.

Yet another example of just needing to Read the Friggen Screen (RtFS)!

[Kimy]

What's the difference between the current gag dialogue system and the upcoming one?

 

We will add new options to the dialogue to allow it generally much faster to complete, and not having to go through 10-20 lines of dialogue each time. Depending on the gag, speaking will be either totally impossible (strict/hard gags) or always succeed (less strict/easy gags), but with a heavy penalty to Speech. The latter can be avoided by having writing utensils. which also allows "speaking" through strict gags if your wrists aren't tied. Writing utensils can be crafted from scrap material.

[galgat]

 

What's the difference between the current gag dialogue system and the upcoming one?

 

We will add new options to the dialogue to allow it generally much faster to complete, and not having to go through 10-20 lines of dialogue each time. Depending on the gag, speaking will be either totally impossible (strict/hard gags) or always succeed (less strict/easy gags), but with a heavy penalty to Speech. The latter can be avoided by having writing utensils. which also allows "speaking" through strict gags if your wrists aren't tied. Writing utensils can be crafted from scrap material.

 

 

   That would be a god send, I might actually turn the gag back on in mods that allow me to turn it off, ( and those that don't I seldom play ) if this were the case, it has always been just to much of a time waster for me.  I like the concept, but did not like the procrastinated, and overly lengthened dialogue, for me it was a terrible waste of My game playing time.

[VirginMarie]

Testing with latest dev, DL'd today, with FNIS 7 and a new game. Found that my code that would normally remove plugs, since they are generic, is failing. I dug deeper as follows...

1. DCL put a vaginal and anal plug on, along with a chastity belt. Each are generic from DDx
2. CANNOT see the plugs on the character, but they show as equipped in inventory
3. CAN see the chastity device
4. Took chastity belt off to inspect further. No difference, still no visible plugs
5. Code runs to remove devices. Succeeds on chastity belt, but fails on the plugs. It's failing because these if statements return false... If playerref.wornhaskeyword(libs.zad_deviousPlugVaginal) / If playerref.wornhaskeyword(libs.zad_deviousPlugAnal)
6. I assume the fail is because the render device is not there. I checked both and they do have the keyword on their render armor item

Note: If I manually remove then re-equip the two plugs, they become visible, and the code succeeds on removal.

 

I don't think this is new. I have seen plugs that end up invisible but showing equipped in inventory, in the production version. The problem is 2-fold:

• the device being invisible
• the device cannot be removed to equip something new

[Nazzzgul666]

 

I noticed that you can "unlock" anything even if you do not have the keys. The attempt will fail but the message that pops up says something about being unable to insert the key in to the lock. I can imagine this could get rather annoying with something like DCLs specialized keys, as there would be no way of knowing, if you have the right key or not.

 

The way the system is set up is that the conditionals in the device messages have no way to know what exact key (if any) is needed to unlock the item, so the "Unlock" option is always displayed. This was a little compromise we had to make to allow much easier creation of custom items and reuse of framework assets (otherwise you'd have to create a custom message every time your item is using another key).

 

It's good practice to mention what key is needed in the device description and/or item messages, so users will know what key is needed.

 

Something that i assume related, but hopefully not exactly the same case:

If i manipulate locks on mittens before equipping them, i can take them off via unlock, but still need several tries with messages that i dropped the key for fails. While i'm fine with the unlock compromise in general, i found that... confusing.

[LazyBoot]

 

 

The way the system is set up is that the conditionals in the device messages have no way to know what exact key (if any) is needed to unlock the item, so the "Unlock" option is always displayed. This was a little compromise we had to make to allow much easier creation of custom items and reuse of framework assets (otherwise you'd have to create a custom message every time your item is using another key).

 

It's good practice to mention what key is needed in the device description and/or item messages, so users will know what key is needed.

 

Something that i assume related, but hopefully not exactly the same case:

If i manipulate locks on mittens before equipping them, i can take them off via unlock, but still need several tries with messages that i dropped the key for fails. While i'm fine with the unlock compromise in general, i found that... confusing.

 

I mentioned something similar a few weeks ago, the old mittens escape system is still set up in front of the new system it seems.

[Kimy]

 

 

I noticed that you can "unlock" anything even if you do not have the keys. The attempt will fail but the message that pops up says something about being unable to insert the key in to the lock. I can imagine this could get rather annoying with something like DCLs specialized keys, as there would be no way of knowing, if you have the right key or not.

 

The way the system is set up is that the conditionals in the device messages have no way to know what exact key (if any) is needed to unlock the item, so the "Unlock" option is always displayed. This was a little compromise we had to make to allow much easier creation of custom items and reuse of framework assets (otherwise you'd have to create a custom message every time your item is using another key).

 

It's good practice to mention what key is needed in the device description and/or item messages, so users will know what key is needed.

 

Something that i assume related, but hopefully not exactly the same case:

If i manipulate locks on mittens before equipping them, i can take them off via unlock, but still need several tries with messages that i dropped the key for fails. While i'm fine with the unlock compromise in general, i found that... confusing.

 

 

That's sort of intended. When you manipulate the locks, it will disable THIS lock. But you still need to be able to actually able it to undo it, and other restraints will still behave the way they are normally behaving. E.g. a locked belt would still cover a pair of manipulate plugs. And mittens still behave like mittens.

 

[phate45]

 

 

 

I noticed that you can "unlock" anything even if you do not have the keys. The attempt will fail but the message that pops up says something about being unable to insert the key in to the lock. I can imagine this could get rather annoying with something like DCLs specialized keys, as there would be no way of knowing, if you have the right key or not.

 

The way the system is set up is that the conditionals in the device messages have no way to know what exact key (if any) is needed to unlock the item, so the "Unlock" option is always displayed. This was a little compromise we had to make to allow much easier creation of custom items and reuse of framework assets (otherwise you'd have to create a custom message every time your item is using another key).

 

It's good practice to mention what key is needed in the device description and/or item messages, so users will know what key is needed.

 

Something that i assume related, but hopefully not exactly the same case:

If i manipulate locks on mittens before equipping them, i can take them off via unlock, but still need several tries with messages that i dropped the key for fails. While i'm fine with the unlock compromise in general, i found that... confusing.

 

 

That's sort of intended. When you manipulate the locks, it will disable THIS lock. But you still need to be able to actually able it to undo it, and other restraints will still behave the way they are normally behaving. E.g. a locked belt would still cover a pair of manipulate plugs. And mittens still behave like mittens.

 

 

 

I think that Nazzzgul hinted at the message being confusing, talking about dropping the key even though the locks were manipulated beforehand. Since there is a condition for manipulation included on the item, can the message be also changed depending on it?

 

[Nazzzgul666]

 

*snip*

 

That's sort of intended. When you manipulate the locks, it will disable THIS lock. But you still need to be able to actually able it to undo it, and other restraints will still behave the way they are normally behaving. E.g. a locked belt would still cover a pair of manipulate plugs. And mittens still behave like mittens.

 

 

 

I think that Nazzzgul hinted at the message being confusing, talking about dropping the key even though the locks were manipulated beforehand. Since there is a condition for manipulation included on the item, can the message be also changed depending on it?

 

 

True, it's rather about the message then the mechanics, but i'm not sure if this can be detected easily. Just to be clear: i've maipulated the mittens and also tried to unequip the mittens, no second item involved. I still could understand if the mittens are supposed to disturb unequipping them, because of their nature.

But if it's possible to change the message in this case without too much effort, that would be nice. After all, there is no key involved either.

 

I'd think about something like:

"Although the locks were manipulated, the mittens still restrict your movements. Your attempt to take the mittens off fails." 

*edit:

Optionally more precise:

"Although the locks were manipulated, the mittens still restrict your movements. You press the mittens against your belly to be able to use some pressure, rubbing and struggling, but to no avail. Your attempt to take the mittens off fails and all the rubbing left you slightly [more] aroused." 

 

No change of mechanics, but it could prevent further bug reports in this direction, especially when new users put their hands on the public release. Which is something we all would be glad about i think.

[Corsayr]

 

 

*snip*

 

That's sort of intended. When you manipulate the locks, it will disable THIS lock. But you still need to be able to actually able it to undo it, and other restraints will still behave the way they are normally behaving. E.g. a locked belt would still cover a pair of manipulate plugs. And mittens still behave like mittens.

 

 

 

I think that Nazzzgul hinted at the message being confusing, talking about dropping the key even though the locks were manipulated beforehand. Since there is a condition for manipulation included on the item, can the message be also changed depending on it?

 

 

True, it's rather about the message then the mechanics, but i'm not sure if this can be detected easily. Just to be clear: i've maipulated the mittens and also tried to unequip the mittens, no second item involved. I still could understand if the mittens are supposed to disturb unequipping them, because of their nature.

But if it's possible to change the message in this case without too much effort, that would be nice. After all, there is no key involved either.

 

I'd think about something like:

"Although the locks were manipulated, the mittens still restrict your movements. Your attempt to take the mittens off fails." 

*edit:

Optionally more precise:

"Although the locks were manipulated, the mittens still restrict your movements. You press the mittens against your belly to be able to use some pressure, rubbing and struggling, but to no avail. Your attempt to take the mittens off fails and all the rubbing left you slightly [more] aroused." 

 

No change of mechanics, but it could prevent further bug reports in this direction, especially when new users put their hands on the public release. Which is something we all would be glad about i think.

 

 

Maybe some kind of generic line that could work for both?

 

"The handicap of the mittens and the intricacy of the locking apparatus frustrates you, and you fail to successfully undo the device." 

[galgat]

 

Testing with latest dev, DL'd today, with FNIS 7 and a new game. Found that my code that would normally remove plugs, since they are generic, is failing. I dug deeper as follows...

1. DCL put a vaginal and anal plug on, along with a chastity belt. Each are generic from DDx
2. CANNOT see the plugs on the character, but they show as equipped in inventory
3. CAN see the chastity device
4. Took chastity belt off to inspect further. No difference, still no visible plugs
5. Code runs to remove devices. Succeeds on chastity belt, but fails on the plugs. It's failing because these if statements return false... If playerref.wornhaskeyword(libs.zad_deviousPlugVaginal) / If playerref.wornhaskeyword(libs.zad_deviousPlugAnal)
6. I assume the fail is because the render device is not there. I checked both and they do have the keyword on their render armor item

Note: If I manually remove then re-equip the two plugs, they become visible, and the code succeeds on removal.

 

I don't think this is new. I have seen plugs that end up invisible but showing equipped in inventory, in the production version. The problem is 2-fold:

• the device being invisible
• the device cannot be removed to equip something new

 

 

  I wonder if this is the same thing that happens to the Inflatable plugs in the standard DDI, I know if a mod allows me to turn off the Inflatable plugs I do.

 

They seem, for me at least to get stuck quite often, and have become another overly  high frustration item for me.

 

 

[rjn]

I still think the escape messaging, particularly for the armbinders, will confuse everyone.  The preferred escape strategy in the dev version is: click the armbinder in inventory (an "unequip" click) and use the "Unlock" choice in the popup menu.  A struggle animation plays and the armbinder is unequipped with appropriate message box (although the arms stay behind until you "jump"). 

 

This process can be learned after you see it succeed, but the average user has already seen there is a "Struggle" choice under "Try to escape" and remembers struggling out of armbinders in the previous version, it's not going to be clear to them that they should choose "Unlock" for an item that isn't locked even if they have no key.

 

I know the generic approach to escape has been thoroughly explained here (no need to repeat that!), just be prepared for some consequences.