Devious Devices Framework Development/Beta

[Code Serpent]

Are you guys at all interested in making the crafting and 'lore' of these devices more uniform and fleshed out? As in adding new quests, books, and loading screens? I might be able to write some books myself if you are interested. I've also made a separate forum post explaining my current ideas for a "lore-friendly" explanation, as crazy as that sounds: http://www.loverslab.com/topic/77263-lore-friendly-devious-devices

[WaxenFigure]

Are you guys at all interested in making the crafting and 'lore' of these devices more uniform and fleshed out? As in adding new quests, books, and loading screens? I might be able to write some books myself if you are interested. I've also made a separate forum post explaining my current ideas for a "lore-friendly" explanation, as crazy as that sounds: http://www.loverslab.com/topic/77263-lore-friendly-devious-devices

Crafting is good, lore is not. Lore might interfere with someone else's ideas or even how they want to consider their play through. Write some lore and someone will get the idea that everything ought to be conformed to that lore. Yeah, it's silly but there are people like that.

[Code Serpent]

 

Crafting is good, lore is not. Lore might interfere with someone else's ideas or even how they want to consider their play through. Write some lore and someone will get the idea that everything ought to be conformed to that lore. Yeah, it's silly but there are people like that.

 

Maybe instead add some options in the MCM to change how the GetGenericDevice functions work, so that you receive certain devices due to the player's location, or due to the npc giving them? Or, alternatively, add the ability to globally suppress tags for items gotten randomly.

 

I do realize that child mods can do this individually, but to have any sort of synergy every mod author would have to have the same idea on the 'lore', or have every mod add options themselves, which likely won't happen.

[Verstort]

 

 

Starting 1 compile threads for 1 files...
Compiling "crdeplayermonitorscript"...
G:\Games\Mod Organizer\mods\Deviously Cursed Loot 6.1\Scripts\Source\dcur_mastercontrollerscript.psc(269,13): DestroyKey is not a property on script zadcon
fig or one of its parents
G:\Games\Mod Organizer\mods\Deviously Cursed Loot 6.1\Scripts\Source\dcur_mastercontrollerscript.psc(269,5): type mismatch while assigning to a none (cast
missing or types unrelated)
G:\Games\Mod Organizer\mods\Deviously Cursed Loot 6.1\Scripts\Source\dcur_mastercontrollerscript.psc(270,13): DestroyKeyProbability is not a property on sc
ript zadconfig or one of its parents
G:\Games\Mod Organizer\mods\Deviously Cursed Loot 6.1\Scripts\Source\dcur_mastercontrollerscript.psc(270,5): type mismatch while assigning to a none (cast
missing or types unrelated)
G:\Games\Mod Organizer\mods\Deviously Cursed Loot 6.1\Scripts\Source\dcur_mastercontrollerscript.psc(271,13): DestroyKeyJamChance is not a property on scri
pt zadconfig or one of its parents
G:\Games\Mod Organizer\mods\Deviously Cursed Loot 6.1\Scripts\Source\dcur_mastercontrollerscript.psc(271,5): type mismatch while assigning to a none (cast
missing or types unrelated)
G:\Games\Mod Organizer\mods\Deviously Cursed Loot 6.1\Scripts\Source\dcur_mastercontrollerscript.psc(277,13): UseDeviceDifficultyEscape is not a property o
n script zadconfig or one of its parents
G:\Games\Mod Organizer\mods\Deviously Cursed Loot 6.1\Scripts\Source\dcur_mastercontrollerscript.psc(277,5): type mismatch while assigning to a none (cast
missing or types unrelated)
G:\Games\Mod Organizer\mods\Deviously Cursed Loot 6.1\Scripts\Source\dcur_mastercontrollerscript.psc(278,13): DeviceDifficultyCooldown is not a property on
 script zadconfig or one of its parents
G:\Games\Mod Organizer\mods\Deviously Cursed Loot 6.1\Scripts\Source\dcur_mastercontrollerscript.psc(278,5): type mismatch while assigning to a none (cast
missing or types unrelated)
G:\Games\Mod Organizer\mods\Deviously Cursed Loot 6.1\Scripts\Source\dcur_mastercontrollerscript.psc(279,13): DeviceDifficultyCatastrophicFailChance is not
 a property on script zadconfig or one of its parents
G:\Games\Mod Organizer\mods\Deviously Cursed Loot 6.1\Scripts\Source\dcur_mastercontrollerscript.psc(279,5): type mismatch while assigning to a none (cast
missing or types unrelated)
G:\Games\Mod Organizer\mods\Deviously Cursed Loot 6.1\Scripts\Source\dcur_mastercontrollerscript.psc(280,13): lockShieldActive is not a property on script
zadconfig or one of its parents
G:\Games\Mod Organizer\mods\Deviously Cursed Loot 6.1\Scripts\Source\dcur_mastercontrollerscript.psc(280,5): type mismatch while assigning to a none (cast
missing or types unrelated)
G:\Games\Mod Organizer\mods\Deviously Cursed Loot 6.1\Scripts\Source\dcur_mastercontrollerscript.psc(281,13): lockShieldMinTime is not a property on script
 zadconfig or one of its parents
G:\Games\Mod Organizer\mods\Deviously Cursed Loot 6.1\Scripts\Source\dcur_mastercontrollerscript.psc(281,5): type mismatch while assigning to a none (cast
missing or types unrelated)
G:\Games\Mod Organizer\mods\Deviously Cursed Loot 6.1\Scripts\Source\dcur_mastercontrollerscript.psc(282,13): lockShieldMaxTime is not a property on script
 zadconfig or one of its parents
G:\Games\Mod Organizer\mods\Deviously Cursed Loot 6.1\Scripts\Source\dcur_mastercontrollerscript.psc(282,5): type mismatch while assigning to a none (cast
missing or types unrelated)
No output generated for crdeplayermonitorscript.psc, compilation failed.

 

 

Double checking, there wouldn't happen to be a public DCL repo I can pull from so I don't have to make a second 'old' build configuration, would there?

[neosuduno]

Just a quick question, but how far do you fell the progress is towards the next release? Looks like we have had a few steps forwards, backwards, and sideways, all in the space of a few weeks.

[Derenriche]

The elbowbinder's horny animation is currently set to as if not bound by armbinder. Is this something that is overlooked or simply not implemented?

[Princessity]

Not implemented. Everything regarding heavy restraints is currently on hold pending test results of Armbinder MK II

 

Not saying that everyone should be focusing on testing that to the exclusion of all else... but everyone SHOULD be testing that to the exclusion of all else n_n

[barak43]

ok further testing of the mk II

i screened each actions i just attempted and zipped it

 

when putting it on, no menu appear. and after that when wearing it and opening the menu via inventory, there it is... put it on lol

does nothing when clicking on it of course.

 

i had a key on me while trying this time, and all other functions i tried seems to works fine

Screenshots.7z

[Kimy]

Yes, the Mk II has only a generic device menu atm. I already created new, proper device menus for all devices that I am going to merge in a bit. These will again display only appropriate actions.

 

 

Starting 1 compile threads for 1 files...
Compiling "crdeplayermonitorscript"...
G:\Games\Mod Organizer\mods\Deviously Cursed Loot 6.1\Scripts\Source\dcur_mastercontrollerscript.psc(269,13): DestroyKey is not a property on script zadcon
fig or one of its parents
G:\Games\Mod Organizer\mods\Deviously Cursed Loot 6.1\Scripts\Source\dcur_mastercontrollerscript.psc(269,5): type mismatch while assigning to a none (cast
missing or types unrelated)
G:\Games\Mod Organizer\mods\Deviously Cursed Loot 6.1\Scripts\Source\dcur_mastercontrollerscript.psc(270,13): DestroyKeyProbability is not a property on sc
ript zadconfig or one of its parents
G:\Games\Mod Organizer\mods\Deviously Cursed Loot 6.1\Scripts\Source\dcur_mastercontrollerscript.psc(270,5): type mismatch while assigning to a none (cast
missing or types unrelated)
G:\Games\Mod Organizer\mods\Deviously Cursed Loot 6.1\Scripts\Source\dcur_mastercontrollerscript.psc(271,13): DestroyKeyJamChance is not a property on scri
pt zadconfig or one of its parents
G:\Games\Mod Organizer\mods\Deviously Cursed Loot 6.1\Scripts\Source\dcur_mastercontrollerscript.psc(271,5): type mismatch while assigning to a none (cast
missing or types unrelated)
G:\Games\Mod Organizer\mods\Deviously Cursed Loot 6.1\Scripts\Source\dcur_mastercontrollerscript.psc(277,13): UseDeviceDifficultyEscape is not a property o
n script zadconfig or one of its parents
G:\Games\Mod Organizer\mods\Deviously Cursed Loot 6.1\Scripts\Source\dcur_mastercontrollerscript.psc(277,5): type mismatch while assigning to a none (cast
missing or types unrelated)
G:\Games\Mod Organizer\mods\Deviously Cursed Loot 6.1\Scripts\Source\dcur_mastercontrollerscript.psc(278,13): DeviceDifficultyCooldown is not a property on
 script zadconfig or one of its parents
G:\Games\Mod Organizer\mods\Deviously Cursed Loot 6.1\Scripts\Source\dcur_mastercontrollerscript.psc(278,5): type mismatch while assigning to a none (cast
missing or types unrelated)
G:\Games\Mod Organizer\mods\Deviously Cursed Loot 6.1\Scripts\Source\dcur_mastercontrollerscript.psc(279,13): DeviceDifficultyCatastrophicFailChance is not
 a property on script zadconfig or one of its parents
G:\Games\Mod Organizer\mods\Deviously Cursed Loot 6.1\Scripts\Source\dcur_mastercontrollerscript.psc(279,5): type mismatch while assigning to a none (cast
missing or types unrelated)
G:\Games\Mod Organizer\mods\Deviously Cursed Loot 6.1\Scripts\Source\dcur_mastercontrollerscript.psc(280,13): lockShieldActive is not a property on script
zadconfig or one of its parents
G:\Games\Mod Organizer\mods\Deviously Cursed Loot 6.1\Scripts\Source\dcur_mastercontrollerscript.psc(280,5): type mismatch while assigning to a none (cast
missing or types unrelated)
G:\Games\Mod Organizer\mods\Deviously Cursed Loot 6.1\Scripts\Source\dcur_mastercontrollerscript.psc(281,13): lockShieldMinTime is not a property on script
 zadconfig or one of its parents
G:\Games\Mod Organizer\mods\Deviously Cursed Loot 6.1\Scripts\Source\dcur_mastercontrollerscript.psc(281,5): type mismatch while assigning to a none (cast
missing or types unrelated)
G:\Games\Mod Organizer\mods\Deviously Cursed Loot 6.1\Scripts\Source\dcur_mastercontrollerscript.psc(282,13): lockShieldMaxTime is not a property on script
 zadconfig or one of its parents
G:\Games\Mod Organizer\mods\Deviously Cursed Loot 6.1\Scripts\Source\dcur_mastercontrollerscript.psc(282,5): type mismatch while assigning to a none (cast
missing or types unrelated)
No output generated for crdeplayermonitorscript.psc, compilation failed.

 

 

Double checking, there wouldn't happen to be a public DCL repo I can pull from so I don't have to make a second 'old' build configuration, would there?

 

Yes, that was a function in DCL that would let you set "recommended" values for DDI. I removed most of these options from DDI now, so that script needs recompiling.
 

[Kimy]

Just a quick question, but how far do you fell the progress is towards the next release? Looks like we have had a few steps forwards, backwards, and sideways, all in the space of a few weeks.

 

It will indeed be another major, major release, probably one that would warrant a major release number. As you guys know I am never going to commit to any ETAs, but I can say that we now have completed most of what we wanted to do for this release and are working on the last few remaining items.

 

Not sure which part of what are doing is "backwards", though. We modernized a lot of DDI's systems, which of course meant ripping old code and replacing it with new code. The framework is now more powerful and offers more control to modders. We have a new and much better device escape system, more options for devices, and a new wrist restraint implementation that will make creating new devices much easier going forward. With the new API, modders can make many types of custom devices without writing one line of code. That wasn't possible before. In the end, I never had the impression that we were doing anything but moving forward.

[lopjik]

gotta ask since its been removed btw, is there a way to manually jam device locks in order to properly test the lock repair system in place? or is that feature more of a teaser at this point?

[neosuduno]

 

Just a quick question, but how far do you fell the progress is towards the next release? Looks like we have had a few steps forwards, backwards, and sideways, all in the space of a few weeks.

 

It will indeed be another major, major release, probably one that would warrant a major release number. As you guys know I am never going to commit to any ETAs, but I can say that we now have completed most of what we wanted to do for this release and are working on the last few remaining items.

 

Not sure which part of what are doing is "backwards", though. We modernized a lot of DDI's systems, which of course meant ripping old code and replacing it with new code. The framework is now more powerful and offers more control to modders. We have a new and much better device escape system, more options for devices, and a new wrist restraint implementation that will make creating new devices much easier going forward. With the new API, modders can make many types of custom devices without writing one line of code. That wasn't possible before. In the end, I never had the impression that we were doing anything but moving forward.

 

 

The backwards is the number of bugs that sprang up and caused you to lose time. Major time loss is considered a step backwards. Sideways is when you are creating alternate methods to accomplish a goal rather than tried and true. The new system wasn't "necessary" But made things a bit easier for you and modders, but may make strait up gamers a bit more frustrated. Really, if everything just went forward, you would have had no bugs in development at all.

[lopjik]

 

 

Just a quick question, but how far do you fell the progress is towards the next release? Looks like we have had a few steps forwards, backwards, and sideways, all in the space of a few weeks.

 

It will indeed be another major, major release, probably one that would warrant a major release number. As you guys know I am never going to commit to any ETAs, but I can say that we now have completed most of what we wanted to do for this release and are working on the last few remaining items.

 

Not sure which part of what are doing is "backwards", though. We modernized a lot of DDI's systems, which of course meant ripping old code and replacing it with new code. The framework is now more powerful and offers more control to modders. We have a new and much better device escape system, more options for devices, and a new wrist restraint implementation that will make creating new devices much easier going forward. With the new API, modders can make many types of custom devices without writing one line of code. That wasn't possible before. In the end, I never had the impression that we were doing anything but moving forward.

 

 

The backwards is the number of bugs that sprang up and caused you to lose time. Major time loss is considered a step backwards. Sideways is when you are creating alternate methods to accomplish a goal rather than tried and true. The new system wasn't "necessary" But made things a bit easier for you and modders, but may make strait up gamers a bit more frustrated. Really, if everything just went forward, you would have had no bugs in development at all.

 

 

I feel like expecting 0 bugs during development of any form of software is unrealistic at best personally, but maybe I`ve been playing too many games from a certain developer or ten recently so meh. quite frankly, the DD team does a much better job of de-bugging releases than what feels like 9/10 of the gaming industry as a whole today.

[Kimy]

 

 

Just a quick question, but how far do you fell the progress is towards the next release? Looks like we have had a few steps forwards, backwards, and sideways, all in the space of a few weeks.

 

It will indeed be another major, major release, probably one that would warrant a major release number. As you guys know I am never going to commit to any ETAs, but I can say that we now have completed most of what we wanted to do for this release and are working on the last few remaining items.

 

Not sure which part of what are doing is "backwards", though. We modernized a lot of DDI's systems, which of course meant ripping old code and replacing it with new code. The framework is now more powerful and offers more control to modders. We have a new and much better device escape system, more options for devices, and a new wrist restraint implementation that will make creating new devices much easier going forward. With the new API, modders can make many types of custom devices without writing one line of code. That wasn't possible before. In the end, I never had the impression that we were doing anything but moving forward.

 

 

The backwards is the number of bugs that sprang up and caused you to lose time. Major time loss is considered a step backwards. Sideways is when you are creating alternate methods to accomplish a goal rather than tried and true. The new system wasn't "necessary" But made things a bit easier for you and modders, but may make strait up gamers a bit more frustrated. Really, if everything just went forward, you would have had no bugs in development at all.

 

 

Nobody who ever wrote code for a living would claim that there is any software development that doesn't involve fixing bugs. No new code is ever perfect. Which is why we ask people to test it. Honestly, the development issues we had to fix for this release have been super minor so far. I can't remember any bug that we couldn't fix inside of 5 minutes. So, "Backwards" isn't really a term I would use for any stage of development we had for this release. Also, we can't technically lose time, because we're not bound to any release schedules and never will be. We write code, test it and release it when we're reasonably confident that it works correctly.

[barak43]

lol, developing new code will always, and i mean it, always create new bugs. as kimy said, anyone who code for a living will tell you so.

 

so it's not in any way going backward.

 

as for making strait up gamers more frustrated... as far as Devious Device is concerned, i'm just a gamer for now (even if i have a few ideas of mods, but i still have another project i want to continue first lol)

 

and i can tell you that i enjoy the new system even more than the old one !

 

nothing frustrating really ^^,

[lopjik]

>.> Ninja post: new build up I see, any way we can test the jam lock fix feature on this one kimy?

[rjn]

About the idle animations triggered by chastity belt:

 

Commentary for chastity belt - "You tuck at your belt..."  probably should be  "You tug at your belt..."

 

I can see that the animation for tugging at the belt is preceded by undrawing your equipped weapon (at least I think that's the case) but sometimes it doesn't have time and you're left holding your weapon through the animation and it's then frozen in hand so you can't wield it without going into inventory and unequip/re-equip.  So if you're supposed to unequip your weapon before the "frustrated with belt" animation, then it needs a bit more delay to work right all of the time.

[thefakebobdole]

First of all thanks for the mods, its very obvious lots of hard work is being done. I never imagined there would be mods of this caliber, concerning bondage.

 

Quick question, the DDI option for "break key on use",  is it being phased out? I really liked choosing what restraint to remove in what situation, instead of (almost) all or nothing. Will there be something with similar functionality?

 

I'm running these github builds along with lots of other mods. So I may be missing something(s). But so far as good, I'm not noticing problems.

 

I'm a big fan.

    Thank you.

[Kimy]

First of all thanks for the mods, its very obvious lots of hard work is being done. I never imagined there would be mods of this caliber, concerning bondage.

 

Quick question, the DDI option for "break key on use",  is it being phased out? I really liked choosing what restraint to remove in what situation, instead of (almost) all or nothing. Will there be something with similar functionality?

 

I'm running these github builds along with lots of other mods. So I may be missing something(s). But so far as good, I'm not noticing problems.

 

I'm a big fan.

    Thank you.

 

Most user settings affecting difficulty will be removed and replaced with item properties that the modder can set to their liking for each and every item they make. I already updated all items in DDI for the new system. The DDX items have still a 0% for key breaks to occur, but this will change as well.

[barak43]

ok i got an error from DD, not game breaking, but still ^^,

 

so i was in lot of devices (see screenshots), and received a restraint key from my follower (by the mod sexistgards), and the follower tried to unlock me, and that's when the error happen. i wear mittens, and the key dropped on the ground so maybe it's linked ?

 

anyway, the error is in the screenshots, and giving the log too.

Screenshots.7z

Papyrus.0.log

[Loki15kun]

 

First of all thanks for the mods, its very obvious lots of hard work is being done. I never imagined there would be mods of this caliber, concerning bondage.

 

Quick question, the DDI option for "break key on use",  is it being phased out? I really liked choosing what restraint to remove in what situation, instead of (almost) all or nothing. Will there be something with similar functionality?

 

I'm running these github builds along with lots of other mods. So I may be missing something(s). But so far as good, I'm not noticing problems.

 

I'm a big fan.

    Thank you.

 

Most user settings affecting difficulty will be removed and replaced with item properties that the modder can set to their liking for each and every item they make. I already updated all items in DDI for the new system. The DDX items have still a 0% for key breaks to occur, but this will change as well.

 

 

I see that default values have been added for the devices properties, but considering previous answers, I really don't understand why it's fixed inside the code.

 

So If I want to just change the default implementation values from DDI for all existing devices by creating a mod:

- Will I have to recompile the main equip script with the desired values? [this does not sound like a good option]

- Or will I have to re-create every single device (pair - Inventory Item/Equipped Item) on the creation kit and set up the properties manually?

 

The first option seems really wrong (I should never have to edit the framework scripts directly), but is the second one the correct? It seems doable but feels strange  (Sounds like the DDI items work like an abstract class, but feels like doing something that has already been done just for a small change).

 

Maybe I'm not seeing something important. Sorry for rambling.

[Kimy]

 

 

First of all thanks for the mods, its very obvious lots of hard work is being done. I never imagined there would be mods of this caliber, concerning bondage.

 

Quick question, the DDI option for "break key on use",  is it being phased out? I really liked choosing what restraint to remove in what situation, instead of (almost) all or nothing. Will there be something with similar functionality?

 

I'm running these github builds along with lots of other mods. So I may be missing something(s). But so far as good, I'm not noticing problems.

 

I'm a big fan.

    Thank you.

 

Most user settings affecting difficulty will be removed and replaced with item properties that the modder can set to their liking for each and every item they make. I already updated all items in DDI for the new system. The DDX items have still a 0% for key breaks to occur, but this will change as well.

 

 

I see that default values have been added for the devices properties, but considering previous answers, I really don't understand why it's fixed inside the code.

 

So If I want to just change the default implementation values from DDI for all existing devices by creating a mod:

- Will I have to recompile the main equip script with the desired values? [this does not sound like a good option]

- Or will I have to re-create every single device (pair - Inventory Item/Equipped Item) on the creation kit and set up the properties manually?

 

The first option seems really wrong (I should never have to edit the framework scripts directly), but is the second one the correct? It seems doable but feels strange  (Sounds like the DDI items work like an abstract class, but feels like doing something that has already been done just for a small change).

 

Maybe I'm not seeing something important. Sorry for rambling.

 

 

In short, the user is not supposed to be able to adjust item difficulty at a framework-wide level. Because in the past that affected -all- items, including these created by 3rd party modders. That's why these MCM controls got removed - we want DD mod creators to be able to set their own values and let them decide what the users can and cannot customize. 3rd party DD mods are still able and encouraged to provide difficulty sliders for -their- mods. E.g. Cursed Loot still has controls allowing users to influence difficulty for its own items and quests.

[neosuduno]

 

 

 

First of all thanks for the mods, its very obvious lots of hard work is being done. I never imagined there would be mods of this caliber, concerning bondage.

 

Quick question, the DDI option for "break key on use",  is it being phased out? I really liked choosing what restraint to remove in what situation, instead of (almost) all or nothing. Will there be something with similar functionality?

 

I'm running these github builds along with lots of other mods. So I may be missing something(s). But so far as good, I'm not noticing problems.

 

I'm a big fan.

    Thank you.

 

Most user settings affecting difficulty will be removed and replaced with item properties that the modder can set to their liking for each and every item they make. I already updated all items in DDI for the new system. The DDX items have still a 0% for key breaks to occur, but this will change as well.

 

 

I see that default values have been added for the devices properties, but considering previous answers, I really don't understand why it's fixed inside the code.

 

So If I want to just change the default implementation values from DDI for all existing devices by creating a mod:

- Will I have to recompile the main equip script with the desired values? [this does not sound like a good option]

- Or will I have to re-create every single device (pair - Inventory Item/Equipped Item) on the creation kit and set up the properties manually?

 

The first option seems really wrong (I should never have to edit the framework scripts directly), but is the second one the correct? It seems doable but feels strange  (Sounds like the DDI items work like an abstract class, but feels like doing something that has already been done just for a small change).

 

Maybe I'm not seeing something important. Sorry for rambling.

 

 

In short, the user is not supposed to be able to adjust item difficulty at a framework-wide level. Because in the past that affected -all- items, including these created by 3rd party modders. That's why these MCM controls got removed - we want DD mod creators to be able to set their own values and let them decide what the users can and cannot customize. 3rd party DD mods are still able and encouraged to provide difficulty sliders for -their- mods. E.g. Cursed Loot still has controls allowing users to influence difficulty for its own items and quests.

 

 

I get that, but I fear that many people will not like that. Maybe also include Mods to re-implement them if people want that. Like Key Breaking, timelimits and minimum struggles. Honestly, those are among the first things I change. If you cut things like that, you can end up making it less fun for a lot of people. I understand the intention, but I can only see needless frustration as a consequence of this decision, and people refusing to install it, or abandoning it altogether.

 

Long and short. You would be alienating people. I personally always remove time limits, and if the option to get rid of those are gone, then I will not be able to enjoy the mod. Too Frustrating.

 

[Kimy]

 

 

 

 

First of all thanks for the mods, its very obvious lots of hard work is being done. I never imagined there would be mods of this caliber, concerning bondage.

 

Quick question, the DDI option for "break key on use",  is it being phased out? I really liked choosing what restraint to remove in what situation, instead of (almost) all or nothing. Will there be something with similar functionality?

 

I'm running these github builds along with lots of other mods. So I may be missing something(s). But so far as good, I'm not noticing problems.

 

I'm a big fan.

    Thank you.

 

Most user settings affecting difficulty will be removed and replaced with item properties that the modder can set to their liking for each and every item they make. I already updated all items in DDI for the new system. The DDX items have still a 0% for key breaks to occur, but this will change as well.

 

 

I see that default values have been added for the devices properties, but considering previous answers, I really don't understand why it's fixed inside the code.

 

So If I want to just change the default implementation values from DDI for all existing devices by creating a mod:

- Will I have to recompile the main equip script with the desired values? [this does not sound like a good option]

- Or will I have to re-create every single device (pair - Inventory Item/Equipped Item) on the creation kit and set up the properties manually?

 

The first option seems really wrong (I should never have to edit the framework scripts directly), but is the second one the correct? It seems doable but feels strange  (Sounds like the DDI items work like an abstract class, but feels like doing something that has already been done just for a small change).

 

Maybe I'm not seeing something important. Sorry for rambling.

 

 

In short, the user is not supposed to be able to adjust item difficulty at a framework-wide level. Because in the past that affected -all- items, including these created by 3rd party modders. That's why these MCM controls got removed - we want DD mod creators to be able to set their own values and let them decide what the users can and cannot customize. 3rd party DD mods are still able and encouraged to provide difficulty sliders for -their- mods. E.g. Cursed Loot still has controls allowing users to influence difficulty for its own items and quests.

 

 

I get that, but I fear that many people will not like that. Maybe also include Mods to re-implement them if people want that. Like Key Breaking, timelimits and minimum struggles. Honestly, those are among the first things I change. If you cut things like that, you can end up making it less fun for a lot of people. I understand the intention, but I can only see needless frustration as a consequence of this decision, and people refusing to install it, or abandoning it altogether.

 

Long and short. You would be alienating people. I personally always remove time limits, and if the option to get rid of those are gone, then I will not be able to enjoy the mod. Too Frustrating.

 

 

 

We might provide a means to influence difficulty for the DDI/DDX standard item library, but these ONLY. There will never again be a means that lets users -globally- affect these settings. Providing difficulty settings for custom DD items is something that the DD content mod authors need to do for their own mods now. In the end that's the -much- better solution for everyone. Even for users, because they can make DD mod A more difficult and DD mod B harder, instead of having to apply a "one fits all" setting to each and every DD mod they are using, even mods that were not created with these settings in mind.

 

Just to drive the point home why global settings are not a good idea: For a while it was possible to break several quests in my content mod Cursed Loot by setting DestroyKey to True. The framework would then destroy the custom key when you unlocked the first item needing this key, but the quest had you wear FIVE items using this key. These items were simply not made with this setting in mind. With the new system, the modder can define whether or not the item will consume the key.

 

[neosuduno]

 

 

 

 

 

First of all thanks for the mods, its very obvious lots of hard work is being done. I never imagined there would be mods of this caliber, concerning bondage.

 

Quick question, the DDI option for "break key on use",  is it being phased out? I really liked choosing what restraint to remove in what situation, instead of (almost) all or nothing. Will there be something with similar functionality?

 

I'm running these github builds along with lots of other mods. So I may be missing something(s). But so far as good, I'm not noticing problems.

 

I'm a big fan.

    Thank you.

 

Most user settings affecting difficulty will be removed and replaced with item properties that the modder can set to their liking for each and every item they make. I already updated all items in DDI for the new system. The DDX items have still a 0% for key breaks to occur, but this will change as well.

 

 

I see that default values have been added for the devices properties, but considering previous answers, I really don't understand why it's fixed inside the code.

 

So If I want to just change the default implementation values from DDI for all existing devices by creating a mod:

- Will I have to recompile the main equip script with the desired values? [this does not sound like a good option]

- Or will I have to re-create every single device (pair - Inventory Item/Equipped Item) on the creation kit and set up the properties manually?

 

The first option seems really wrong (I should never have to edit the framework scripts directly), but is the second one the correct? It seems doable but feels strange  (Sounds like the DDI items work like an abstract class, but feels like doing something that has already been done just for a small change).

 

Maybe I'm not seeing something important. Sorry for rambling.

 

 

In short, the user is not supposed to be able to adjust item difficulty at a framework-wide level. Because in the past that affected -all- items, including these created by 3rd party modders. That's why these MCM controls got removed - we want DD mod creators to be able to set their own values and let them decide what the users can and cannot customize. 3rd party DD mods are still able and encouraged to provide difficulty sliders for -their- mods. E.g. Cursed Loot still has controls allowing users to influence difficulty for its own items and quests.

 

 

I get that, but I fear that many people will not like that. Maybe also include Mods to re-implement them if people want that. Like Key Breaking, timelimits and minimum struggles. Honestly, those are among the first things I change. If you cut things like that, you can end up making it less fun for a lot of people. I understand the intention, but I can only see needless frustration as a consequence of this decision, and people refusing to install it, or abandoning it altogether.

 

Long and short. You would be alienating people. I personally always remove time limits, and if the option to get rid of those are gone, then I will not be able to enjoy the mod. Too Frustrating.

 

 

 

We might provide a means to influence difficulty for the DDI/DDX standard item library, but these ONLY. There will never again be a means that lets users -globally- affect these settings. Providing difficulty settings for custom DD items is something that the DD content mod authors need to do for their own mods now. In the end that's the -much- better solution for everyone. Even for users, because they can make DD mod A more difficult and DD mod B harder, instead of having to apply a "one fits all" setting to each and every DD mod they are using, even mods that were not created with these settings in mind.

 

Just to drive the point home why global settings are not a good idea: For a while it was possible to break several quests in my content mod Cursed Loot by setting DestroyKey to True. The framework would then destroy the custom key when you unlocked the first item needing this key, but the quest had you wear FIVE items using this key. These items were simply not made with this setting in mind. With the new system, the modder can define whether or not the item will consume the key.

 

 

 

That makes sense, What about you rubber suits from cursed loot, will they be included? As long as I can turn off standard item struggle cool-down and manipulate key chances for standard library items, I will be happy, as will others. Custom settings, that is something for mod authors to work with. I can still see this update breaking a lot of mods though.