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

[Veladarius]

 

 

 

 

 

 

 

 

 

 

Nice to hear that guys, keep up the good work)

 

 

Here is the script, put it in the scripts folder and overwrite the one there.

 

zadPlugScript.pex

 

 

If you give me the source code, I will merge it (provided it patches against the current dev build, not DD3.x)...

 

 

 

Here is is but I don't use the dev build.

zadPlugScript.psc

 

Also, if you haven't already you may want to check the locking and pump plug properties as several don't have keys set in them so they are not removable by the player.

[Kimy]

 

I was able to change the plug script in about 15 minutes including testing with open and closed back belts, wasn't very difficult.

 

 

I believe that. Still, a lot of 15 minute tasks do still add up, and the DD team has to put their time into the stuff that matters most. More realistic open belt support, while nice to have for the people using these items, just isn't as important to the mod as a whole as some of the other things on our plate atm. There are a lot of little things I want to do, but I am working a near full-time equivalent on my mods already, so I have to prioritize what I am putting my hours into. And sometimes that might or might not align with what someone wants me to add ASAP.

 

 

 

Also, if you haven't already you may want to check the locking and pump plug properties as several don't have keys set in them so they are not removable by the player.

 

 

Will look into that! Thanks!

 

And thanks for the code, but I don't think I can merge it if it's not meant to patch against the current GitHub version of that script. Making sure it wouldn't overwrite anything would probably take more than the 15 mins it took for you to write it. You're still welcome to submit that patch for the dev build, if you want it to go into the framework.

[Veladarius]

 

 

I was able to change the plug script in about 15 minutes including testing with open and closed back belts, wasn't very difficult.

 

 

I believe that. Still, a lot of 15 minute tasks do still add up, and the DD team has to put their time into the stuff that matters most. More realistic open belt support, while nice to have for the people using these items, just isn't as important to the mod as a whole as some of the other things on our plate atm. There are a lot of little things I want to do, but I am working a near full-time equivalent on my mods already, so I have to prioritize what I am putting my hours into. And sometimes that might or might not align with what someone wants me to add ASAP.

 

I know that it isn't something high on your list of things to fix but it has been an issue for years and was never fixed and something that has been requested for just as long.

 

 

 

Also, if you haven't already you may want to check the locking and pump plug properties as several don't have keys set in them so they are not removable by the player.

 

 

Will look into that! Thanks!

 

And thanks for the code, but I don't think I can merge it if it's not meant to patch against the current GitHub version of that script. Making sure it wouldn't overwrite anything would probably take more than the 15 mins it took for you to write it. You're still welcome to submit that patch for the dev build, if you want it to go into the framework.

 

 

I'm not using the dev build so I don't know how much the plug scripts have changed. The only parts that I changed are in the OnEquippedFilter, RemovePlugNoLock and RemovePlugLock functions so it checks for the allowanal keyword on the belt to determine if it can be added or removed.

 

 

Specifically this is what I added in those three places in the opening IF statements:

If libs.Playerref.WornHasKeyword(libs.zad_PermitAnal)
   if deviceRendered.HasKeyword(libs.zad_DeviousPlugAnal)
      if deviceRendered.HasKeyword(libs.zad_kw_InflatablePlugAnal) && (libs.zadInflatablePlugStateAnal.GetValueInt() > 0)
         libs.notify("You cannot remove this plug as long as it is inflated.", messagebox = true)
         return
      endif
   endif
else

And I also removed the 'Return' command at the end of the if statement it was in and added it to the parts where it would be blocked so it would allow the script to continue and allow the insertion/removal of the plug using the rest of the existing function.

 

 

Do what  you want with it, this is as far as I am going with it.

[Kimy]

 

I know that it isn't something high on your list of things to fix but it has been an issue for years and was never fixed and something that has been requested for just as long.

 

Do what  you want with it, this is as far as I am going with it.

 

Judging from our last few exchanges and the way they are phrased, I think you seem to hold quite a few grudges about how the team and I in particular have handed DD development lately. For starters, you wrongly assume that I have memorized every single bug report and request since DD was started. I do not. I am human and prone to error, like everyone else. I had very little to do with DD development before Min asked me to take over and most of what happened before I did is now lost in impossible to search private messaging threads. If you made any requests regarding DD development that went unanswered, give me the benefit of the doubt and assume that I just overlooked them or never had a chance to see them to begin with. I do not go through old threads, ever. If there is something you want to tell us/me, post it in the new public dev thread. I read it daily. If there is old stuff we didn't react to, you're welcome to remind us.

 

Next thing, and I feel the need to point this out very clearly so, is that no matter how often somebody requests something, there is still no guarantee that we will do it. As I said above, my time is limited. So is everyone else's in the team. That and we do this for free. I cannot remember me ever refusing to merge contributed code, but if you refuse to even look at the development of the framework your -own- mods are relying on, I can't help you. You seem to be very upset that we/I didn't add your request(s), but at the same time you refuse writing a proper patch for it despite you easily could, and instead basically demand me to put in work for a feature you seem to want more much more than I do. That makes very little sense. Or rather, isn't terribly fair. If you refuse to be a part of DD development you have no right to complain about how we're handling it and about what features we're adding and when.

 

The open belt issue isn't even a bug, so please spare me the "You don't fix your bugs!!!" treatment. The code works fine, it just doesn't properly support these items, because they were never implemented properly. That's NOT a bug.

 

I have nothing but respect for you and your work. CD has been a staple in my own load order since the day I started modding. It always has been a mod I looked up to. I have no idea what I ever did to wrong you, but yes, I did of course notice the passive-aggressive tone you're using when talking to/about me lately, and the fact that you stepped away from the DD development conversation basically the very moment I took over (even in the old thread you barely ever posted in). Which is your prerogative, but if you make the choice not to talk to us/me anymore, or contribute code, you can't complain about your wishes not getting implemented. And I'd totally appreciate if we could switch back to communicate respectfully with each other.

 

 

 

[Veladarius]

 

 

I know that it isn't something high on your list of things to fix but it has been an issue for years and was never fixed and something that has been requested for just as long.

 

Do what  you want with it, this is as far as I am going with it.

 

Judging from our last few exchanges and the way they are phrased, I think you seem to hold quite a few grudges about how the team and I in particular have handed DD development lately. For starters, you wrongly assume that I have memorized every single bug report and request since DD was started. I do not. I am human and prone to error, like everyone else. I had very little to do with DD development before Min asked me to take over and most of what happened before I did is now lost in impossible to search private messaging threads. If you made any requests regarding DD development that went unanswered, give me the benefit of the doubt and assume that I just overlooked them or never had a chance to see them to begin with. I do not go through old threads, ever. If there is something you want to tell us/me, post it in the new public dev thread. I read it daily. If there is old stuff we didn't react to, you're welcome to remind us.

 

Next thing, and I feel the need to point this out very clearly so, is that no matter how often somebody requests something, there is still no guarantee that we will do it. As I said above, my time is limited. So is everyone else's in the team. That and we do this for free. I cannot remember me ever refusing to merge contributed code, but if you refuse to even look at the development of the framework your -own- mods are relying on, I can't help you. You seem to be very upset that we/I didn't add your request(s), but at the same time you refuse writing a proper patch for it despite you easily could, and instead basically demand me to put in work for a feature you seem to want more much more than I do. That makes very little sense. Or rather, isn't terribly fair. If you refuse to be a part of DD development you have no right to complain about how we're handling it and about what features we're adding and when.

 

The open belt issue isn't even a bug, so please spare me the "You don't fix your bugs!!!" treatment. The code works fine, it just doesn't properly support these items, because they were never implemented properly. That's NOT a bug.

 

I have nothing but respect for you and your work. CD has been a staple in my own load order since the day I started modding. It always has been a mod I looked up to. I have no idea what I ever did to wrong you, but yes, I did of course notice the passive-aggressive tone you're using when talking to/about me lately, and the fact that you stepped away from the DD development conversation basically the very moment I took over (even in the old thread you barely ever posted in). Which is your prerogative, but if you make the choice not to talk to us/me anymore, or contribute code, you can't complain about your wishes not getting implemented. And I'd totally appreciate if we could switch back to communicate respectfully with each other.

 

 

 

I have no clue as to how to use GitHub, never have other than downloading things as a zip file and writing some of the instructions for Min. I know that a number of the people contributing to scripting and such work in programming or others that use GitHub, I worked as a financial auditor so I had no clue to what it was when DD switched to using it and I have never been able to make much sense out of it.

 

 

As to the direction DD has been taking, no I have not been pleased with it starting with the addition of the Questitem keyword and removal command and voiced my displeasure with it when it was added during development, this is when I pretty much quit. Just that change required months of rewriting scripts and adjusting devices, dialogue and scenes including the time it took to test it and track down all of the scripts that reference quest device removal. 

 

 

As for my tone I will say it is a combination of my dislike of the direction DD has been going and my mental issues, bipolar in particular. Few medications actually work for me, most have caused serious side effects and the only drug that worked to keep my bipolar swings under control has been damaging my liver and I had to stop taking it.

 

With everything else that has gone on in my life in the last 9 months I have been on the verge of quitting modding altogether, sometimes to the point of wanting to take everything I made down and trashing it. I still get that urge from time to time. I am not entirely stable emotionally and it doesn't take much to send me off in a different direction.

[Kimy]

 

 

 

I know that it isn't something high on your list of things to fix but it has been an issue for years and was never fixed and something that has been requested for just as long.

 

Do what  you want with it, this is as far as I am going with it.

 

Judging from our last few exchanges and the way they are phrased, I think you seem to hold quite a few grudges about how the team and I in particular have handed DD development lately. For starters, you wrongly assume that I have memorized every single bug report and request since DD was started. I do not. I am human and prone to error, like everyone else. I had very little to do with DD development before Min asked me to take over and most of what happened before I did is now lost in impossible to search private messaging threads. If you made any requests regarding DD development that went unanswered, give me the benefit of the doubt and assume that I just overlooked them or never had a chance to see them to begin with. I do not go through old threads, ever. If there is something you want to tell us/me, post it in the new public dev thread. I read it daily. If there is old stuff we didn't react to, you're welcome to remind us.

 

Next thing, and I feel the need to point this out very clearly so, is that no matter how often somebody requests something, there is still no guarantee that we will do it. As I said above, my time is limited. So is everyone else's in the team. That and we do this for free. I cannot remember me ever refusing to merge contributed code, but if you refuse to even look at the development of the framework your -own- mods are relying on, I can't help you. You seem to be very upset that we/I didn't add your request(s), but at the same time you refuse writing a proper patch for it despite you easily could, and instead basically demand me to put in work for a feature you seem to want more much more than I do. That makes very little sense. Or rather, isn't terribly fair. If you refuse to be a part of DD development you have no right to complain about how we're handling it and about what features we're adding and when.

 

The open belt issue isn't even a bug, so please spare me the "You don't fix your bugs!!!" treatment. The code works fine, it just doesn't properly support these items, because they were never implemented properly. That's NOT a bug.

 

I have nothing but respect for you and your work. CD has been a staple in my own load order since the day I started modding. It always has been a mod I looked up to. I have no idea what I ever did to wrong you, but yes, I did of course notice the passive-aggressive tone you're using when talking to/about me lately, and the fact that you stepped away from the DD development conversation basically the very moment I took over (even in the old thread you barely ever posted in). Which is your prerogative, but if you make the choice not to talk to us/me anymore, or contribute code, you can't complain about your wishes not getting implemented. And I'd totally appreciate if we could switch back to communicate respectfully with each other.

 

 

 

I have no clue as to how to use GitHub, never have other than downloading things as a zip file and writing some of the instructions for Min. I know that a number of the people contributing to scripting and such work in programming or others that use GitHub, I worked as a financial auditor so I had no clue to what it was when DD switched to using it and I have never been able to make much sense out of it.

 

Downloading stuff as a ZIP is all you need to get the newest package. I will gladly merge any code contributions for you. I do that for other contributors, too. But it makes life for me MUCH easier if I can rely on the code being based on the recent dev build and not some old version of DD.

 

As to the direction DD has been taking, no I have not been pleased with it starting with the addition of the Questitem keyword and removal command and voiced my displeasure with it when it was added during development, this is when I pretty much quit. Just that change required months of rewriting scripts and adjusting devices, dialogue and scenes including the time it took to test it and track down all of the scripts that reference quest device removal. 

 

You wouldn't have need to change anything at all, and I told you back then. The new quest item feature is 100% backwards compatible. Your items would have worked for all eternity the way they were.

 

 

As for my tone I will say it is a combination of my dislike of the direction DD has been going.

 

Well, then talk to me about it. I think it beats holding grudges, no?

 

 

[Veladarius]

 

As to the direction DD has been taking, no I have not been pleased with it starting with the addition of the Questitem keyword and removal command and voiced my displeasure with it when it was added during development, this is when I pretty much quit. Just that change required months of rewriting scripts and adjusting devices, dialogue and scenes including the time it took to test it and track down all of the scripts that reference quest device removal. 

You wouldn't have need to change anything at all, and I told you back then. The new quest item feature is 100% backwards compatible. Your items would have worked for all eternity the way they were.

 

My only problem with this is any mod could decide to remove my quest items because they were not tagged as such, hence back to my original argument: If blockgeneric was all that was needed to show an item was a quest item then why add the new keyword and removal function? Your 'removable' items are all tagged with blockgeneric so any other mod could have decided that they were the same sort of item and removed them thinking they were the same sort of item.

 

 

As for my tone I will say it is a combination of my dislike of the direction DD has been going.

 

Well, then talk to me about it. I think it beats holding grudges, no?

 

- Shield Lock feature that keeps the player from using a key immediately.

- Debug function that removes Quest Devices. Yes you are sending a mod event out but most of my quests that use the items are not made to be reset. My only option is to have them automatically reapplied.

- Limiting how often an attempt to escape from a device can be made. Picking a lock should only be limited by how many lock picks you have (I never used the lock jamming feature either).

 

This is from things listed in GitHub that were added that have a description. As it was the entire new escape system that was added to DDi in v3 I did not like and always disabled. There were things that I remember reading about in the forum thread that went back and forth but I don't know what is or isn't being implemented or how they were to be managed.

 

I have no issue with making restrictive items more restrictive but not basic restraints.

 

[bicobus]

 

 

I was able to change the plug script in about 15 minutes including testing with open and closed back belts, wasn't very difficult.

 

 

I believe that. Still, a lot of 15 minute tasks do still add up, and the DD team has to put their time into the stuff that matters most. More realistic open belt support, while nice to have for the people using these items, just isn't as important to the mod as a whole as some of the other things on our plate atm. There are a lot of little things I want to do, but I am working a near full-time equivalent on my mods already, so I have to prioritize what I am putting my hours into. And sometimes that might or might not align with what someone wants me to add ASAP.

 

 

It is possible, through git, to easily review and apply the patch to your development branch. If you make then apply the patch to a copy of the current stable branch then merge that branch into development, git should auto-resolve history. I'm not sure how advanced you are with using that tool, so I would advise using a second local repository to test this one. With the how powerful git is, the only issue that remains is wether or not the new code would work.

[Guest]

I will just say the features of lock jamming and shield lock I rather liked, but I could see how it could be something optional which I think it is if I am not mistaken.

[Veladarius]

 

 

 

I was able to change the plug script in about 15 minutes including testing with open and closed back belts, wasn't very difficult.

 

 

I believe that. Still, a lot of 15 minute tasks do still add up, and the DD team has to put their time into the stuff that matters most. More realistic open belt support, while nice to have for the people using these items, just isn't as important to the mod as a whole as some of the other things on our plate atm. There are a lot of little things I want to do, but I am working a near full-time equivalent on my mods already, so I have to prioritize what I am putting my hours into. And sometimes that might or might not align with what someone wants me to add ASAP.

 

 

It is possible, through git, to easily review and apply the patch to your development branch. If you make then apply the patch to a copy of the current stable branch then merge that branch into development, git should auto-resolve history. I'm not sure how advanced you are with using that tool, so I would advise using a second local repository to test this one. With the how powerful git is, the only issue that remains is wether or not the new code would work.

 

 

That went about 10 feet over my head.

[bicobus]

I will just say the features of lock jamming and shield lock I rather liked, but I could see how it could be something optional which I think it is if I am not mistaken.

Never used them personally. I rely on the mods to manage devices, and they don't seem to care about those features because it's non-applicable. Most of the mods I use are about removing some freedom from the player available actions. Beside there is no real incentive for the player to wear those devices by choice, so it never really occurs to me.

 

 

 

 

I was able to change the plug script in about 15 minutes including testing with open and closed back belts, wasn't very difficult.

 

I believe that. Still, a lot of 15 minute tasks do still add up, and the DD team has to put their time into the stuff that matters most. More realistic open belt support, while nice to have for the people using these items, just isn't as important to the mod as a whole as some of the other things on our plate atm. There are a lot of little things I want to do, but I am working a near full-time equivalent on my mods already, so I have to prioritize what I am putting my hours into. And sometimes that might or might not align with what someone wants me to add ASAP.

 

 

It is possible, through git, to easily review and apply the patch to your development branch. If you make then apply the patch to a copy of the current stable branch then merge that branch into development, git should auto-resolve history. I'm not sure how advanced you are with using that tool, so I would advise using a second local repository to test this one. With the how powerful git is, the only issue that remains is wether or not the new code would work.

 

 

That went about 10 feet over my head.

 

I was just stating that it is possible to apply your changes to the git repository and work it up to the develop branch without too much problem. That's the base purpose of git, to not get in the way. As long as the lines of code you changed haven't been touched by DD's dev team, there would theoretically be no conflict. Git is complex enough that I would understand if you get a panic attack from reading this well thought branching model, especially if you have no prior knowledge of the thing.

 

However it is the maintainer's job to get patches and apply them in the repository. I do understand kimy's unwillingness to cherry pick patches designed for old versions of the framework, considering the time available to the team. However the stable version isn't old, it is the version everybody is using. But again, I'm not maintaining the project and I don't make the rules.

[Veladarius]

 

I will just say the features of lock jamming and shield lock I rather liked, but I could see how it could be something optional which I think it is if I am not mistaken.

Never used them personally. I rely on the mods to manage devices, and they don't seem to care about those features because it's non-applicable. Most of the mods I use are about removing some freedom from the player available actions. Beside there is no real incentive for the player to wear those devices by choice, so it never really occurs to me.

 

 

 

 

I was able to change the plug script in about 15 minutes including testing with open and closed back belts, wasn't very difficult.

 

I believe that. Still, a lot of 15 minute tasks do still add up, and the DD team has to put their time into the stuff that matters most. More realistic open belt support, while nice to have for the people using these items, just isn't as important to the mod as a whole as some of the other things on our plate atm. There are a lot of little things I want to do, but I am working a near full-time equivalent on my mods already, so I have to prioritize what I am putting my hours into. And sometimes that might or might not align with what someone wants me to add ASAP.

 

 

It is possible, through git, to easily review and apply the patch to your development branch. If you make then apply the patch to a copy of the current stable branch then merge that branch into development, git should auto-resolve history. I'm not sure how advanced you are with using that tool, so I would advise using a second local repository to test this one. With the how powerful git is, the only issue that remains is wether or not the new code would work.

 

 

That went about 10 feet over my head.

 

I was just stating that it is possible to apply your changes to the git repository and work it up to the develop branch without too much problem. That's the base purpose of git, to not get in the way. As long as the lines of code you changed haven't been touched by DD's dev team, there would theoretically be no conflict. Git is complex enough that I would understand if you get a panic attack from reading this well thought branching model, especially if you have no prior knowledge of the thing.

 

However it is the maintainer's job to get patches and apply them in the repository. I do understand kimy's unwillingness to cherry pick patches designed for old versions of the framework, considering the time available to the team. However the stable version isn't old, it is the version everybody is using. But again, I'm not maintaining the project and I don't make the rules.

 

 

I understand what GitHub is for and does but I have tried reading the manual for using GitHub and it left me clueless, it is obvious the manual was written by a programmer or someone similar. I documented processes for a bank I worked at and wrote a large number of manuals. I also ended up testing new software for one of the departments I was in and it was obvious when programmers wrote the documentation. There is a big difference as programmers rarely write documentation for people that know nothing on the subject and tend to leave out some basic information or don't describe things for someone who has used or seen the software.

[Kimy]

 

 

As to the direction DD has been taking, no I have not been pleased with it starting with the addition of the Questitem keyword and removal command and voiced my displeasure with it when it was added during development, this is when I pretty much quit. Just that change required months of rewriting scripts and adjusting devices, dialogue and scenes including the time it took to test it and track down all of the scripts that reference quest device removal. 

You wouldn't have need to change anything at all, and I told you back then. The new quest item feature is 100% backwards compatible. Your items would have worked for all eternity the way they were.

 

My only problem with this is any mod could decide to remove my quest items because they were not tagged as such, hence back to my original argument: If blockgeneric was all that was needed to show an item was a quest item then why add the new keyword and removal function? Your 'removable' items are all tagged with blockgeneric so any other mod could have decided that they were the same sort of item and removed them thinking they were the same sort of item.

 

I think you missed the point when I said that NOTHING about the behavior of existing items was changed. At. All. Unfriendly/careless mods have been removing items tagged with zad_blockGeneric forever. They did it back then. They are still doing it. Nothing has changed. I introduced the new keyword to approach that exact issue - we had no clear distinction between "touch this item only if REALLY needed" and "don't touch this item, EVER". You made the decision to update your items and use the new system, when you could have opted to do exactly nothing and your stuff would still have worked. Nobody forced you to. I don't get what bad thing I did there, really.

 

 

As for my tone I will say it is a combination of my dislike of the direction DD has been going.

 

Well, then talk to me about it. I think it beats holding grudges, no?

 

- Shield Lock feature that keeps the player from using a key immediately.

 

This feature is optional. You can set both values to zero and the item will allow you to use the key immediately.

 

- Debug function that removes Quest Devices. Yes you are sending a mod event out but most of my quests that use the items are not made to be reset. My only option is to have them automatically reapplied.

 

Again, you are missing the point of that function. It's for DEBUG purposes. As in when something went really wrong. And for these situations ONLY. It's not meant for unfriendly mods to override your quests. I wrote a very blunt comment in the source code saying exactly this. I can totally guarantee you that if I ever catch a 3rd party mod calling this function from outsides the framework and/or abuses it to override other people's quests, I will make sure that this mod will never use a DDI API function ever again. The user also gets presented with a clear warning message that this feature is for resolving technical issues only. You will have to do NOTHING on your end (processing the event is optional). It's a DEBUG function and that's the end of it.

 

- Limiting how often an attempt to escape from a device can be made. Picking a lock should only be limited by how many lock picks you have (I never used the lock jamming feature either).

 

You can disable the cooldown for your own items by setting the value to zero. The point of the feature is to prevent spam escape attempts, like the old armbinder struggle that just made you to stand still and spam the struggle as often as needed to break free. Now you can set a realistic (e.g not artificially low) value that doesn't allow the player to basically escape immediately by mindlessly hammering the "Get me outta here!!!" key as long as it takes.

 

As it was the entire new escape system that was added to DDi in v3 I did not like and always disabled.

 

Likewise - you can disable the entire thing for each and every single one of your items. The entire system is optional for any items you create.

 

I have no issue with making restrictive items more restrictive but not basic restraints.

 

Basic restraints were boring, IMHO. Now they are a little bit more interesting and still won't break your game. If you don't like the new mechanics and/or the default values I picked for the standard library, just create your own items and adjust the values to your liking. You don't even have to use the standard items at all. NOTHING about the new systems is forced down any modder's throat. Their entire point was to put full control in the hand of the modder designing the items. In other words, yours. Again, I don't get why giving you guys more options and more control is a bad thing? I am totally willing to listen if some default values I picked for standard items turn out to be unfun or unbalanced.

 

 

 

[Inte]

So colorful​.

 

Say, how about a link to the dev thread.

[Veladarius]

 

 

 

 

- Shield Lock feature that keeps the player from using a key immediately.

 

This feature is optional. You can set both values to zero and the item will allow you to use the key immediately.

 

- Limiting how often an attempt to escape from a device can be made. Picking a lock should only be limited by how many lock picks you have (I never used the lock jamming feature either).

 

You can disable the cooldown for your own items by setting the value to zero. The point of the feature is to prevent spam escape attempts, like the old armbinder struggle that just made you to stand still and spam the struggle as often as needed to break free. Now you can set a realistic (e.g not artificially low) value that doesn't allow the player to basically escape immediately by mindlessly hammering the "Get me outta here!!!" key as long as it takes.

 

As it was the entire new escape system that was added to DDi in v3 I did not like and always disabled.

 

Likewise - you can disable the entire thing for each and every single one of your items. The entire system is optional for any items you create.

 

I have no issue with making restrictive items more restrictive but not basic restraints.

 

Basic restraints were boring, IMHO. Now they are a little bit more interesting and still won't break your game. If you don't like the new mechanics and/or the default values I picked for the standard library, just create your own items and adjust the values to your liking. You don't even have to use the standard items at all. NOTHING about the new systems is forced down any modder's throat. Their entire point was to put full control in the hand of the modder designing the items. In other words, yours. Again, I don't get why giving you guys more options and more control is a bad thing? I am totally willing to listen if some default values I picked for standard items turn out to be unfun or unbalanced.

 

 

 

 

I am not looking at these from the perspective of the modder but the player that doesn't want to deal with these at all. If players want to use those features that's fine but I don't. Being able to set these values to 0 on devices I make is great so long as I only use my mod and don't use standard items. As it is of the few hundred custom items I have the only ones that are standard non-quest devices is a full set of metal devices in each of my custom colors. I suppose if I don't want to deal with these features I will just have to uninstall the other mods I have that add items to the player that don't give me the option to not use these features. That is how much I dislike them and while you are not forcing them down the modders throat to use them the players that are using mods that don't allow the changing of these values or to disable them entirely are being forced to use them. If I don't want to subject players to these features with the standard devices I equip should I make a whole new set of standard items and abandon the ones from DD completely or should I just set the values on the base items to 0 myself and overwrite what is already there?

 

Reducing the player's options on these is not something I see as a good thing as far as players are concerned.

 

 

Edit: My only other option is to stick with the current versions of DD and not use or support future versions.

[Guest]

I don't understand this at all I mean setting it to 0% means that you don't ever have to worry about it being active 0_o

 

I used almost every DD related mod and I don't believe these features you're talking about are forced onto the player I may be wrong but

I don't believe I am. I would say that not supporting the current DD team in their efforts is a bad idea Veladarius, especially since this seems

even to me to be a non-issue.

 

So if I am reading you, you have said you felt like pulling your mods and now you're giving (if I am taking it out of context forgive me) ultimatum of sorts

that if these features aren't pulled or remedied then you'll discontinue your support for the current version of the framework?

 

Anyway I encourage you guys to talk this out as I can already see the future of this conversation going in the wrong direction when you threaten to pull your support its not a good way to get things done :/

[Veladarius]

I don't understand this at all I mean setting it to 0% means that you don't ever have to worry about it being active 0_o

 

I used almost every DD related mod and I don't believe these features you're talking about are forced onto the player I may be wrong but

I don't believe I am. I would say that not supporting the current DD team in their efforts is a bad idea Veladarius, especially since this seems

even to me to be a non-issue.

 

So if I am reading you, you have said you felt like pulling your mods and now you're giving (if I am taking it out of context forgive me) ultimatum of sorts

that if these features aren't pulled or remedied then you'll discontinue your support for the current version of the framework?

 

Anyway I encourage you guys to talk this out as I can already see the future of this conversation going in the wrong direction when you threaten to pull your support its not a good way to get things done :/

 

The issue is that, as I understand it, the current options for these things currently in the MCM menu are being removed and added as predetermined properties on the items. You get no opportunity to change them and are forced to deal with them as a player.

 

As to would I stop supporting future versions of DD? Yes, I would. Kimy has stated before that she would not do / support things she had no interest in, I feel removing these as options and instead making them mandatory (having these set on all of the general DD devices makes it mandatory) is not in the best interest of DD overall, not something I am interested in as a player or supporting as a modder.

[Guest]

Oooh ok sorry i just wasn't entirely clear but now I understand and if what you're saying is correct about these being applied to standard devices despite the wishes of the player or the modder than I agree with you that it should be 100% optional.

 

From my full understanding though if the standard items fall within that escape system I would assume it would use the players set values in the MCM if not that should be changed, but if you yourself want to create your own items that bypass the escape system regardless of what is set by the player, I believe you can do that.

 

 

 

 

 

 

 

[incrediblysecure]

 

 

Edit: My only other option is to stick with the current versions of DD and not use or support future versions.

 

 

or make an esp that changes the default devices to do whatever you want which should take all of ten minutes

 

could you tell us what exactly about the new system you don't like? kimy's asked for specific feedback verbatim and your response has been "new stuff sux i'm dropping support for new dd bye." Which features of the new escape system are you not a fan of?

 

personally, i'm a fan of anything that reduces mcm options. Kimy's logic re: users can break things seems super solid. with release ddi and cursed loot, you can change like three settings and wind up with a game that's basically unplayable. While this is an extreme example, as long as users have huge amounts of control, there's no consistent experience for a player who winds up with a bunch of devices on them via a mod. Devices could be either trivial to remove or impossible to remove. You as a mod author have no idea which.

 

As a bad example, let's consider your confiscation quest. A low-level player starts the game, finds an armbinder on a bandit or something, then hops over to your shop and triggers the quest. If the user has made devices trivial to remove via the mcm, this is a small annoyance and the player struggles out and is on their way. If the user has made devices nearly impossible to remove, this might effectively end their playthrough, especially if they don't have enough gold to use your removal service.

 

unrelated i feel like in the current ddi beta the odds of getting a really long string of "you need to wait 3 hours" in a row is a bit too high. Forcing the user to take a game action in between attempts to remove devices is cool, but if you're indoors in a safe location there's not much of a penalty for just waiting over and over again. Reducing the chance of having to wait for each failure would work, or you could even replace "wait three hours" with "sleep in a bed you own" or something if you wanted to force the user to travel to a safe indoor location (and then give 100% success if they do)

[bicobus]

 

I don't understand this at all I mean setting it to 0% means that you don't ever have to worry about it being active 0_o

 

I used almost every DD related mod and I don't believe these features you're talking about are forced onto the player I may be wrong but

I don't believe I am. I would say that not supporting the current DD team in their efforts is a bad idea Veladarius, especially since this seems

even to me to be a non-issue.

 

So if I am reading you, you have said you felt like pulling your mods and now you're giving (if I am taking it out of context forgive me) ultimatum of sorts

that if these features aren't pulled or remedied then you'll discontinue your support for the current version of the framework?

 

Anyway I encourage you guys to talk this out as I can already see the future of this conversation going in the wrong direction when you threaten to pull your support its not a good way to get things done :/

 

The issue is that, as I understand it, the current options for these things currently in the MCM menu are being removed and added as predetermined properties on the items. You get no opportunity to change them and are forced to deal with them as a player.

 

As to would I stop supporting future versions of DD? Yes, I would. Kimy has stated before that she would not do / support things she had no interest in, I feel removing these as options and instead making them mandatory (having these set on all of the general DD devices makes it mandatory) is not in the best interest of DD overall, not something I am interested in as a player or supporting as a modder.

 

 Err, yeah, I go with you on this case. I don't enjoy being forced to use the gag talk system, and enjoy is a very light word to express my hate for that "mini game". If other annoying features becomes like that one, with no way for the user to tweak or disable them, I'll just not upgrade DD. However if the vanilla items are configurable through the MCM, then it would alleviate most of my issues. It is not currently the case with gag talk.

 

 

 

Edit: My only other option is to stick with the current versions of DD and not use or support future versions.

 

or make an esp that changes the default devices to do whatever you want which should take all of ten minutes

 

could you tell us what exactly about the new system you don't like? kimy's asked for specific feedback verbatim and your response has been "new stuff sux i'm dropping support for new dd bye." Which features of the new escape system are you not a fan of?

 

Veldarius and kimy already answered those.

 

New esp: kimy may step in and say it's not cool, like stated in the first post of this page.

Veldarius talked about the lack of options for the player: unable to do anything if whatever is planted on your character.

 

personally, i'm a fan of anything that reduces mcm options. Kimy's logic re: users can break things seems super solid. with release ddi and cursed loot, you can change like three settings and wind up with a game that's basically unplayable. While this is an extreme example, as long as users have huge amounts of control, there's no consistent experience for a player who winds up with a bunch of devices on them via a mod. Devices could be either trivial to remove or impossible to remove. You as a mod author have no idea which.

 

As a bad example, let's consider your confiscation quest. A low-level player starts the game, finds an armbinder on a bandit or something, then hops over to your shop and triggers the quest. If the user has made devices trivial to remove via the mcm, this is a small annoyance and the player struggles out and is on their way. If the user has made devices nearly impossible to remove, this might effectively end their playthrough, especially if they don't have enough gold to use your removal service.

You advance a genuine issue here. However if you raise the standard by the bottom of the barrel, we wouldn't get anything nice. Yeah you could make your game unplayable, but removing any interactions or solution for the player to remove a device (and I used the word remove and not escape) could potentially break user space. There is a damn warning in the MCM about the "jamming" feature that is "if you don't have a mod to remove those items for you, too bad". That's silly. The framework isn't something that should force anything on the player, but something used by the modders to create scenarios and stories. And then again, how people experience those stories and scenarios are up to themselves, not the mod author and not the framework.

 

I'm not asking for much though, an "enable/disable" like the jamming option would be sufficient and only for vanilla DD item.

 

Incidentally, I always make it so it is very easy to escape bondage because of my inability to remove bugged items (items put on and not removed by the same mod, and thus stuck on my character).

unrelated i feel like in the current ddi beta the odds of getting a really long string of "you need to wait 3 hours" in a row is a bit too high. Forcing the user to take a game action in between attempts to remove devices is cool, but if you're indoors in a safe location there's not much of a penalty for just waiting over and over again. Reducing the chance of having to wait for each failure would work, or you could even replace "wait three hours" with "sleep in a bed you own" or something if you wanted to force the user to travel to a safe indoor location (and then give 100% success if they do)

The need to wait between escape trials is a bit odd, because the player will remove those devices anyway and all this feature is doing is stalling. This is a weakness of the game of random, it can be fixed with proper content like cursed loot and the mini-quests to remove devious items. The removal would succeed 100% but invite the player to work for it. I'm referring to the "I can't help you, but I know somebody who can." answer, then send the player to the next city.

[Veladarius]

 

 

 

Edit: My only other option is to stick with the current versions of DD and not use or support future versions.

 

 

or make an esp that changes the default devices to do whatever you want which should take all of ten minutes

It would take far longer than 10 minutes if all of the values are on the individual devices and not based on a central variable as they are now. It would require the updating of the properties of every DDi / DDx inventory item of which there are probable over a hundred of them.

 

 

could you tell us what exactly about the new system you don't like? kimy's asked for specific feedback verbatim and your response has been "new stuff sux i'm dropping support for new dd bye." Which features of the new escape system are you not a fan of?

 

As a player everything that is in the new escape system. Currently I turn it off and use the original system. Removing this choice and leaving it to the mod author may be what Kimy likes / wants but I have no interest in any of those features as a mod author and don't want them as a player.

 

 

personally, i'm a fan of anything that reduces mcm options. Kimy's logic re: users can break things seems super solid. with release ddi and cursed loot, you can change like three settings and wind up with a game that's basically unplayable. While this is an extreme example, as long as users have huge amounts of control, there's no consistent experience for a player who winds up with a bunch of devices on them via a mod. Devices could be either trivial to remove or impossible to remove. You as a mod author have no idea which.

 

If someone sets up their game and gets completely stuck they have the option of changing those options and make it playable and set it up how they want to their experience in the game to be. having options is not a bad thing as I added them in CD and gave options on quests and devices as people asked for them, some didn't like some quests or wanted specific devices used or not used. Removing the choice of the escape system removes the choice in how I want to play and forces me to use something I don't want to.

 

So that leaves me with the following choices:

 

 

- create an esp that negates it all - only problem is it would need to include any mod I use that has standard (non quest) devices as well as my own

- stop using any mods that can place random items on my character and avoid being locked in any items at all.

- Don't upgrade to newer versions of DD so I don't have to deal with the new 'features'

- Stop using DD altogether

 

Everyone always says if you don't like a mod then don't use it and that is my intent.

 

 

[Kimy]

/re: Overriding framework assets: Not cool. But what's totally acceptable is duplicating the standard library in a new mod using a new namespace and changing any values you want, then releasing it as an alternative library.

 

As for changing EVERY single item, it took me about 2-3 days to go through the entire library. It's more than 10 mins, but hey, you have to do it only once.

 

@Vel: Just for clarification: Are you opposed to the new escape system because you hate it, or because there is no user control? Huge difference.

For example: Are you sure that the default values for the lock shield are THAT much a game breaker, considering that I set them to a couple -hours- only? The old (albeit configurable) defaults were -several days-. Again, ALL default values are up for debate. Including lock shield timers and escape/unlock cooldowns. Mind suggesting some you could live with?

 

Also, would you guys mind to continue the debate in the dev thread? We're currently debating that exact issue there:  http://www.loverslab.com/topic/69936-devious-devices-framework-developmentbeta/page-20?do=findComment&comment=1946149

[Kimy]

 

The need to wait between escape trials is a bit odd, because the player will remove those devices anyway and all this feature is doing is stalling.

 

What this feature is meant to do is preventing the player from standing still where they are and spam escape attempts for as long as it takes. While the realism of the cooldown is debatable, it -does- prevent the player from instantly escaping any item just by trying long enough and encourages her to continue playing the game, which the restraint still worn.

 

This is a weakness of the game of random, it can be fixed with proper content like cursed loot and the mini-quests to remove devious items. The removal would succeed 100% but invite the player to work for it. I'm referring to the "I can't help you, but I know somebody who can." answer, then send the player to the next city.

 

Yes, these features are meant to coexist. There are multiple paths to freedom: Struggling, finding help, doing quests, scavenging for keys etc. That's supposed to make bondage content much more interesting than offering one route of escape that's distinctively easier than the others (which is spamming escape attempts), but also super boring.

 

 

 

 Err, yeah, I go with you on this case. I don't enjoy being forced to use the gag talk system, and enjoy is a very light word to express my hate for that "mini game". If other annoying features becomes like that one, with no way for the user to tweak or disable them, I'll just not upgrade DD. However if the vanilla items are configurable through the MCM, then it would alleviate most of my issues. It is not currently the case with gag talk.

 

I thought long ago about bringing DCL's gag talk system to DDI, but DCL's gag talk system doesn't make sense without DCL. If you have any ideas how to revamp the DDI gag talk and make it more fun, let me know in the dev thread!

 

[pavelius_pavlentius]

If you are stuck in belt, it must be the most painful situation youve ever got it.

You must be frustrated, every key must break or be "misplaced" whatever that mean, both plugs must be inflatable, that will throw you in orgasm on any unprecise move.

I hope that in some nearest future we will get enema functions.

[Veladarius]

/re: Overriding framework assets: Not cool. But what's totally acceptable is duplicating the standard library in a new mod using a new namespace and changing any values you want, then releasing it as an alternative library.

 

As for changing EVERY single item, it took me about 2-3 days to go through the entire library. It's more than 10 mins, but hey, you have to do it only once.

 

@Vel: Just for clarification: Are you opposed to the new escape system because you hate it, or because there is no user control? Huge difference.

For example: Are you sure that the default values for the lock shield are THAT much a game breaker, considering that I set them to a couple -hours- only? The old (albeit configurable) defaults were -several days-. Again, ALL default values are up for debate. Including lock shield timers and escape/unlock cooldowns. Mind suggesting some you could live with?

 

Also, would you guys mind to continue the debate in the dev thread? We're currently debating that exact issue there:  http://www.loverslab.com/topic/69936-devious-devices-framework-developmentbeta/page-20?do=findComment&comment=1946149

 

Moved as requested.