Devious Devices Framework Development/Beta

*Kimy* · July 6, 2017

Ok, I pondered the entire thing a while, and I came the conclusion that I've had enough.

In light of recent events, I thought hard about just packing up my toys entirely and moving on to something more fun than what happened here as of late. Which right now is pretty much anything. We had a chat in the DD team about what transpired as well. In the end we decided that we all love modding just a bit too much to give it up. But I will make some drastic changes to how I am handling some things here.

So that's the policy I am going to adapt for the foreseeable future:

I will continue working on my mods. I will work on what's fun for me and the DD team, and definitely not work on anything else. I will work under the assumption that I don't owe anyone but me and the people working with me any explanation for what I am doing or not doing. I hope this goes without saying, because that's what every other modder does. I am still committed to make fun bondage mods and make them available to those who want to play them, just as before.
Do not expect to see me posting anywhere outsides of my own support threads anymore. At all. Because I won't.
Even in my own threads, I will reduce my public presence to an absolute minimum. I will regularly not post anything anymore here, except when absolutely warranted (e.g. announcing new releases etc.)
In particular, I will not engage in any discussions of any kind, anywhere on this forum, PARTICULARLY not about any features of my mods.
People are still welcome to post suggestions and bug reports. I will read (not necessarily respond to) them and act upon them as I see fit, provided they are phrased respectfully and constructive. I hereby emphasize that no matter how many people make any given suggestion or request, I still reserve the right to dismiss them for any imaginable reason and instead do whatever I and the team think is best and/or more fun. People have the right not to use any mod maintained by me, if they don't like them.
I will continue responding to support requests, particularly if I have the feeling that nobody but me can reasonably reply to the issue presented.
If people want to talk to me, they are welcome to PM me. I will respond, provided that:
If I encounter postings or PMs I find disrespectful/rude/offending/unfair, I will not reply in any shape or fashion, other than by putting the poster on my (virtual) ignore/shit list, regardless of what color their forum tag is, and never interacting with them ever again, including ignoring each and every of their support requests and suggestions.

This is to protect my sanity, my precious time, and what's left of the joy I used to have with modding.

Thank you, everyone who voiced their support for me and/or the team in the past couple days, either openly or by PM. It's most appreciated.

Have a nice day.

Kimy

donotbugme · July 6, 2017

For the benefit of folks looking for discussion/thoughts on the Dev branch not wanting to have to revisit the pages of vitirol in order to see what I brought up im copying it forward two points here. I don't see a way to delete the old posts however. I have a strange gift with timing it appears. I seem to walk between the rain.

Fuck: I Clicked add reply before i proof checked. we're doing it live.

Played as of now for roughly two hours, equipping different devices and checking how they felt. Then I spent around three hours alternating between CK making up items with different properties set. Thank you for your hard work. Obviously not a lot to get into the nitty gritty, but i feel i've kicked the tyres sufficiently to comment. I'm not going to write a bible, but I'd quite like to offer my thoughts if that is alright.

I think the 'lock' hours timer and the 'struggle' functionality times are not very effective with their intent. I'm doing some interpretation and squinted a little but the way I look at it; it doesn't work as is. if anything it just makes me press T, wait three hours and go right back to menu struggling/unlocking. I suggest adding a real time component that prevents removal of perhaps no shorter than thirty seconds. whichever comes first, if that is possible to do.

For one of the more contentious subject I have seen discussed I will don my safety helmet and shitkickers and wade into the mirk.

I have read comments about exposing a way to blanket modify some aspect of the hardcoreness/difficulty on part of the user without being too permissive and ensuring that the vision of the device creator/modder/scripter/questmaker whatever is maintained .

There exists already functionality to make successive escape attempts more likely to succeed, as well as some kind of general device escape number that is tracked that counts the number of restraints you have escaped from. Why not leverage what exists already. one humble proposal forgive me it won't compile or work out of the box but should offer clear intent. I didn't know this existed until i trawled through the code, it would I suggest benefit everyone if these functions were more visible or apparent to a player.
Float Function CalclulateStruggleSuccess()
Float result = BaseEscapeChance
; Apply modifiers, but only if the device is not impossible to escape from to begin with.
If BaseEscapeChance > 0.0
; add 1% for every previous attempt
result += EscapeStruggleAttemptsMade
SNIP
becomes conceptually
Float Function CalclulateStruggleSuccess()
Float result = BaseEscapeChance
; Apply modifiers, but only if the device is not impossible to escape from to begin with.
If BaseEscapeChance > 0.0
; add USER_MCM_CONFIG.SUCCESSIVE_ESCAPE_ATTEMPT_CUMULATIVE_BONUS for every previous attempt
result += USER_MCM_CONFIG.SUCCESSIVE_ESCAPE_ATTEMPT_CUMULATIVE_BONUS
as well as this I can see
Float Function CalclulateStruggleSuccess()
SNIP...
Int EscapesMade = libs.zadDeviceEscapeSuccessCount.GetValueInt()
If EscapesMade > 10
result += 1.0
Endif
If EscapesMade > 25
result += 1.0
Endif
If EscapesMade > 50
result += 1.0
Endif
If EscapesMade > 100
result += 1.0
Endif
SNIP...
that could also be changed to reflect a players growing expertise. there is another section open for configuration without risking breaking devices.
Float Function CalclulateStruggleSuccess()
SNIP...
Int EscapesMade = libs.zadDeviceEscapeSuccessCount.GetValueInt()
If EscapesMade > 10
result += USER_MCM_CONFIG.BONDAGE_EXPERTISE_LEVEL_NOVICE_ESCAPE_CHANCE_MODIFIER
Endif
If EscapesMade > 25  # PROBABLY TOO GENEROUS. would be nice to see a perk level entry to reflect this
result +=  USER_MCM_CONFIG.BONDAGE_EXPERTISE_LEVEL_PADAWAN_ESCAPE_CHANCE_MODIFIER
Endif
If EscapesMade > 50   # PROBABLY TOO GENEROUS. would be nice to see a perk level entry to reflect this
result += USER_MCM_CONFIG.BONDAGE_EXPERTISE_LEVEL_CONTORTIONIST_ESCAPE_CHANCE_MODIFIER
Endif
If EscapesMade > 100  # PROBABLY TOO GENEROUS. would be nice to see a perk level entry to reflect this
result += USER_MCM_CONFIG.BONDAGE_EXPERTISE_LEVEL_EXPERT_NINJA_BONDAGE_WARRIOR_ESCAPE_CHANCE_MODIFIER
Endif
SNIP
I've got some more comments on what i've fiddled with so far but i'd rather not bury you folks under what might look like a tirade of complaints and why is foo not bar. that is not my intention.

happy to discuss further if wanted, my schedule has solidified though still not much free time; and i might get back into the CK, and god forbid finish a gorram mod. Really interested to see the beta and the new options available.

Edit1: less hostile appearing phrasing argh

Hi Folks, Finding several issues as I play around. The first one is that I created a bondage mitten DD with a unique key. after several attempts to fail to remove it, where it fell to the ground, i picked it up apparently my character dropped it on the next removal and the message stated they couldnt see it and it was definitely not on the floor. given it was a unique key. should this be accounted for in some way?

seems to ignore the fact one might have a unique key "removeitem" permanently. I had catastrophic failure to 0 and key break to 0 in properties. i looked at the script. 20% chance to lose key generic or otherwise with mittens?
if Utility.RandomFloat(0.0, 99.9) < 20.0
libs.Notify("With a lot of patience and a little luck you manage to insert the key into the lock and turn it. The bondage mittens fall off your hands.", messagebox = true) 
DeviceMenuRemoveWithKey() 
else
if Utility.RandomFloat(0.0, 99.9) < 20.0
libs.Notify("You try to insert the key into the lock, but it slips away and falls to the ground. You can't find it anywhere.", messagebox = true) 
libs.playerref.RemoveItem(devicekey, 1)
Else
libs.Notify("You try to insert the key into the lock, but it slips away and falls to the ground.", messagebox = true) 
libs.playerref.DropObject(devicekey, 1)
Endif

July 6, 2017

I am glad you too this stance Kimy I hope you can get away from all this stress it really is a bad environment for you to work in and I am glad you're staying

I really love your mods!

*Princessity* · July 6, 2017

@donotbugme: We didn't respond but we saw your post, don't worry n_n It's been taken into consideration, we may use some of it. Thank you!

@everyone else:

Public Service Announcement: New Public Interaction Policy

We are no longer interested in discussing philosophy, modding morality, target demographics, policy, semantics or debating the definition of what DD framework constitutes (as we have a pretty good idea of that, it has never changed and will not for the foreseeable future).

Only feedback that deals with technical aspects of the currently tested build (such as performance, bugs, balance and gameplay experience) will be acknowledged.

Furthermore, while everyone is welcome to post feedback and suggestions, the input from active testers (as in, those who are speaking from experience with the most up to date build) will be given significantly higher priority. Contributors (active testers who proposed solutions, code or assets that got approved for inclusion) continue to enjoy the highest priority. In other words: if you want to have a say, get involved.

Attempts to bring drama into this thread or vague, development-irrelevant complaints will be treated as spam and summarily ignored.

We have decided that user interaction is not critical to successful development.

Responding to posts over the last couple of pages has cost us a significant amount of development time, caused mental distress and discouragment and damaged our relations with the community. After some consideration, we have decided that direct public interaction is harmful to the development of Devious Devices.

As such, regardless of the validity and value of your feedback, we reserve the right to acknowledge it in any way we want, including using canned responses, funny gifs, or even silently. We do still read helpful feedback, even if we choose not to respond to it.

Feedback that we deem as requiring follow-up from our end will be followed up on.

Testing will continue to be open to the public.

We will maintain the same amount of development transparency as always and will continue to make announcements every time significant changes are made to the development build.

Thank you for your understanding. We hope that the new policy will contribute to healthy and productive development.

donotbugme · July 6, 2017

Apologies for being a nuisance, I wouldn't subject anyone to peering over the last few pages looking for any notes I was willing to share. I'm not a sadist, not that kind of sadist anyway.

rjn · July 6, 2017

After another round of testing the escape system;

There is a lot of clicking involved and the user makes choices which seem obvious. For instance, in inventory clicking on an equipped device -- why are you doing that? Because you want to unequip it. You don't need to choose "Try to escape" in a pop-up. Likewise, if you were willing to sacrifice the "Examine device" selection, the whole process could be more streamlined with less user interaction. After clicking the equipped device in inventory you could have one of several possible messages appear based on player inventory:

- if you have the proper key -- "You try to use your X key to unlock the device and either succeed, fail, jam or lose your key"

-if you don't have the key -- "You have no key so... struggle and either fail (to cut or pick the device) or succeed with possible messages being you cut the device or picked the device" (With this one there are a good number of conditional involved that affect the outcome, but still no user choices. Maybe you try picking half the time and cutting the other half.) The success message would then be "You successfully picked the lock (if you have picks) or else "cut the device"

-if you failed the first attempt and the device requires a helper (like the yokes) you get a message saying you're going to need help to escape.

-if the failure result was jamming the lock all further attempts (clicking device in inventory) are about your attempts to repair the lock/cut the device (maybe a random 50/50 choice between those two)

So from the user end you only click the device in inventory and acknowledge a message box on each attempt.

dnoah · July 6, 2017

After another round of testing the escape system;

There is a lot of clicking involved and the user makes choices which seem obvious. For instance, in inventory clicking on an equipped device -- why are you doing that? Because you want to unequip it. You don't need to choose "Try to escape" in a pop-up. Likewise, if you were willing to sacrifice the "Examine device" selection, the whole process could be more streamlined with less user interaction. After clicking the equipped device in inventory you could have one of several possible messages appear based on player inventory:

- if you have the proper key -- "You try to use your X key to unlock the device and either succeed, fail, jam or lose your key"

-if you don't have the key -- "You have no key so... struggle and either fail (to cut or pick the device) or succeed with possible messages being you cut the device or picked the device" (With this one there are a good number of conditional involved that affect the outcome, but still no user choices. Maybe you try picking half the time and cutting the other half.) The success message would then be "You successfully picked the lock (if you have picks) or else "cut the device"

-if you failed the first attempt and the device requires a helper (like the yokes) you get a message saying you're going to need help to escape.

-if the failure result was jamming the lock all further attempts (clicking device in inventory) are about your attempts to repair the lock/cut the device (maybe a random 50/50 choice between those two)

So from the user end you only click the device in inventory and acknowledge a message box on each attempt.

I think skipping top-tier message menu would make it less transparent for the user. There is also 'unlock with key' option there which appears when a matching key is present in inventory, and in case of a belt there are other options. "Examine device" provides a modder with additional opportunity to describe the device and its properties. From user's point of view, additional info can add to immersion, especially in case of some heavily customized devices and device escape conditions.

naaitsab · July 6, 2017

When equipping a device there is no more "warning" if you want to continue. Is this part of the new system or something on the to-do list?

Now it's a bit dangerous if you click on something like the hobble dress straitjacket by accident

baronesa · July 6, 2017

If shield lock is 2 hours, I don't mind that...

Key break chance?

normally use it at 5% and does happen enough, specially sine i keep getting devices put on me thanks to DCL. 25% seems waaaay too much, specially cause i also add the jamming chance (so i can rely on Master or Dollmaker to release me if the worse happen)

rjn · July 6, 2017

After another round of testing the escape system;

There is a lot of clicking involved and the user makes choices which seem obvious. For instance, in inventory clicking on an equipped device -- why are you doing that? Because you want to unequip it. You don't need to choose "Try to escape" in a pop-up. Likewise, if you were willing to sacrifice the "Examine device" selection, the whole process could be more streamlined with less user interaction. After clicking the equipped device in inventory you could have one of several possible messages appear based on player inventory:

- if you have the proper key -- "You try to use your X key to unlock the device and either succeed, fail, jam or lose your key"

-if you don't have the key -- "You have no key so... struggle and either fail (to cut or pick the device) or succeed with possible messages being you cut the device or picked the device" (With this one there are a good number of conditional involved that affect the outcome, but still no user choices. Maybe you try picking half the time and cutting the other half.) The success message would then be "You successfully picked the lock (if you have picks) or else "cut the device"

-if you failed the first attempt and the device requires a helper (like the yokes) you get a message saying you're going to need help to escape.

-if the failure result was jamming the lock all further attempts (clicking device in inventory) are about your attempts to repair the lock/cut the device (maybe a random 50/50 choice between those two)

So from the user end you only click the device in inventory and acknowledge a message box on each attempt.

I think skipping top-tier message menu would make it less transparent for the user. There is also 'unlock with key' option there which appears when a matching key is present in inventory, and in case of a belt there are other options. "Examine device" provides a modder with additional opportunity to describe the device and its properties. From user's point of view, additional info can add to immersion, especially in case of some heavily customized devices and device escape conditions.

Well, right now "Unlock" is an option whether you have a key or not and you first have to choose "Try to Escape" to get to it. I think after the first struggle/fail you could have a message like the "you'll need help" which could also be "this device is special and will require X". I think what I'm envisioning here would be very similar to Kimy's revised gag-talk system with a good variety of messaging based on conditionals. As such I think it would fit in very well. I don't think the user needs the option to try and cut or lockpick a device they have a key for.

*pinky6225* · July 6, 2017

Luck to you both, as i fall under the - runs script heavy load/your not here to help fix my shit category i will not have a reason to post.

donotbugme · July 6, 2017

Sincere apologies folks on that one, I totally dropped the ball. I'm completely unable to reproduce the original issue. I have nothing but a guess what went wrong, and thats I tried to fiddle with devices before DD initialisation had finished. Unfortunately lost the original full log text to a file reload, and none of the older logs still had the details could salvage. Those logs are very very chatty.

I created a belt that cannot be removed while wearing a bra, and a bra that cannot be removed while wearing a belt. What seems to be happening is that I can always remove the belt, but never remove the bra while the belt is on. I can imagine this functionality might be alright as it avoids the sorta device deadlock I thought I had stumbled across in the smalltext below this post. But the bra attempt to remove does not bring up any messagebox, zero that indication either it is unremovable, or requires the belt to be removed before it can be removed.

The following log details putting on the bra, then the belt, then attempting to remove the bra

[07/06/2017 - 09:18:18PM] [Zad]: OnEffectStart(): Bra
[07/06/2017 - 09:18:18PM] [Zad]: OnEquipped(Prisoner: an exclusive bra)
[07/06/2017 - 09:18:18PM] [Zad]: Sending device event DeviceEquippedChastity Bra(Prisoner:1)
[07/06/2017 - 09:18:18PM] [Zad]: SyncInventory(): Equipping Chastity Bra.
[07/06/2017 - 09:18:29PM] [Zad]: OnEffectStart(): Belly
[07/06/2017 - 09:18:29PM] [Zad]: OnEquipped(Prisoner: an exclusive belt)
[07/06/2017 - 09:18:29PM] [Zad]: Sending device event DeviceEquippedChastity Belt(Prisoner:1)
[07/06/2017 - 09:18:29PM] [Zad]: SyncInventory(): Equipping Chastity Belt.
[07/06/2017 - 09:18:29PM] [Zad]: original exposure rate was 2.000000. Setting to 3.000000.
[07/06/2017 - 09:18:29PM] [Zad]: CorsetMagic(): No corset equipped, done.
[07/06/2017 - 09:18:32PM] [Zad]: OnEffectFinish(): Bra
[07/06/2017 - 09:18:32PM] [Zad]: OnUnequipped(Prisoner: an exclusive bra)
[07/06/2017 - 09:18:32PM] [Zad]: OnEffectStart(): Bra
[07/06/2017 - 09:18:33PM] [Zad]: SyncInventory(): Equipping Chastity Bra.

This log does the same with putting on the belt before the bra

[07/06/2017 - 09:19:39PM] [Zad]: OnEffectStart(): Belly
[07/06/2017 - 09:19:39PM] [Zad]: OnEquipped(Prisoner: an exclusive belt)
[07/06/2017 - 09:19:39PM] [Zad]: Sending device event DeviceEquippedChastity Belt(Prisoner:1)
[07/06/2017 - 09:19:39PM] [Zad]: SyncInventory(): Equipping Chastity Belt.
[07/06/2017 - 09:19:40PM] [Zad]: original exposure rate was 2.000000. Setting to 3.000000.
[07/06/2017 - 09:19:40PM] [Zad]: CorsetMagic(): No corset equipped, done.
[07/06/2017 - 09:19:42PM] [Zad]: OnEffectStart(): Bra
[07/06/2017 - 09:19:42PM] [Zad]: OnEquipped(Prisoner: an exclusive bra)
[07/06/2017 - 09:19:42PM] [Zad]: Sending device event DeviceEquippedChastity Bra(Prisoner:1)
[07/06/2017 - 09:19:42PM] [Zad]: SyncInventory(): Equipping Chastity Bra.
[07/06/2017 - 09:19:48PM] [Zad]: OnEffectFinish(): Bra
[07/06/2017 - 09:19:48PM] [Zad]: OnUnequipped(Prisoner: an exclusive bra)
[07/06/2017 - 09:19:49PM] [Zad]: OnEffectStart(): Bra
[07/06/2017 - 09:19:49PM] [Zad]: SyncInventory(): Equipping Chastity Bra.

Attached images of pictures with properties set, the rendered devices are the original beltpadded and brapadded that do have the zad_deviousbelt and zad_deviousbra keywords.

I hope i'm understanding the implementation correctly but just to make sure

UnEquipConflictingDevices ; These item keywords, if present on the character, will prevent the item from getting unequipped, unless a script does it.

Below can be ignored, original post

I created a Belt that cannot be removed while wearing a bra, and a bra that cannot be removed while wearing a belt. it worked fine, right up until the point i attempted to remove one with the key and the device got shoved into an error state, no surprises here really.

This works as expected in technicality there is no "bug", this is intended behavior, but a combination of behaviors that blows up. But lets imagine I could have 10 beautiful assets from a few different mods, force equipped to the player on some trigger out of the players control. maybe something to do with traps, or walking around naked being a bad idea.

One of these mods is setup several non remarkable devices at random plus a punishing enchanted belt/device that must be the last item that can only be removed from a player if they are otherwise completely unrestrained. The player triggers such event. It might be a trap.

Another one of these mods must for instance has a collar that can only be removed if the player is not wearing a belt. This makes for a compatibility problem though both separate modders worked entirely within the permitted framework, breaking the player's DD item state.

I have no idea at the moment what the solution is to this but I imagine you folks have thought more about what might happen in this case than I have started looking at.

20 words or less:

given that a player is wearing items that are a mutual unequipConflictingDevice, what should be the resolution of the deadlock.

edit: phrasing

Feliks · July 6, 2017

I'm late to the party but in my tests as both a modder and user I have to say I really like the new system(s) in place and eagerly look forward to whatever you've got planned next.

MrBig · July 6, 2017

Im sorry its got to this stage for the both of you.

I don't think cutting all user interaction entirely is the best choice for a mod so large and relied upon as Devious Devices but you gotta do what you gotta do. hopefully things will go better with future builds and give you less backlash. Thank you both again for all the hard work.

that aside I've run into a conflict with the bondage mittens and the new struggle mechanic

I unlock the bondage mittens...

only to get this message after...

and the mittens remain locked

t14thforsaken · July 6, 2017

Sorry if this has been mentioned (or already changed, since I haven't played Skyrim for months anyway and I only skimmed the last few pages of this thread), but from the other thread:

If you have any ideas how to revamp the DDI gag talk and make it more fun, let me know in the dev thread!

I will assert that encouraging a player to do nothing is not fun gameplay.

The best approach from a design standpoint is to make gags-blocking-communication not dependent on randomness. Right now in the stable release of DD you're encouraged to just repeatedly talk to the NPC you want to talk to but you have either a few or a lot of extra dialogue options that waste the player's time for no reason. (This is the same problem that armbinders had that has apparently been changed, from what I've read here).

Basically, if a device randomly blocks a player from doing something, you should either change it to be deterministic (e.g. the player can always talk with a gag on, the player can always unlock a belt with a lockpick and 100 lockpick skill) or make the attempt have a cost. That cost shouldn't be just waiting around.

Anyway, with gags specifically, I'd suggest just making them always allow communication. That would be a lot more fun than the current minigame.

swmas · July 7, 2017

DDI description:

"Easy Configurability! -- Highly configurable via MCM interface, so that you can customize your Devious experience to your personal tastes. Don't like how hard it is to make a key? Change it! Don't like the hardcore deviousness of the effects? Turn'em off! "

...NOT

rjn · July 7, 2017

In about 10 hrs of real time play with the newest version my player character has not experienced a single DD event. No pulling at belt, no vibrations and no shocks from plugs or piercings. It worked fine with the previous dev version.

incrediblysecure · July 7, 2017

were you guys actually going to remove tags from default items because if so I can do that if it's helpful

redmond · July 7, 2017

DDI description:

"Easy Configurability! -- Highly configurable via MCM interface, so that you can customize your Devious experience to your personal tastes. Don't like how hard it is to make a key? Change it! Don't like the hardcore deviousness of the effects? Turn'em off! "

...NOT

Makes me wonder how Min would feel about the direction of DDi. Don't think the current devs are bad modders by any means just don't agree with their direction, oh well.

Feliks · July 7, 2017

DDI description:

"Easy Configurability! -- Highly configurable via MCM interface, so that you can customize your Devious experience to your personal tastes. Don't like how hard it is to make a key? Change it! Don't like the hardcore deviousness of the effects? Turn'em off! "

...NOT

DDI description:

"Easy Configurability! -- Highly configurable via MCM interface, so that you can customize your Devious experience to your personal tastes. Don't like how hard it is to make a key? Change it! Don't like the hardcore deviousness of the effects? Turn'em off! "

...NOT

Makes me wonder how Min would feel about the direction of DDi. Don't think the current devs are bad modders by any means just don't agree with their direction, oh well.

I've got two points here, and I'd like you to remember I'm not affiliated with the dev team in any way.

That's from the 3.0 Description which still does fit that description. The 4.0 in which the changes you are complaining about are being made for reasons discussed at great length in many painful ways in these last few pages is no longer that same version.
Wonderfully helpful and constructive feedback you've left here.

redmond · July 7, 2017

That's from the 3.0 Description which still does fit that description. The 4.0 in which the changes you are complaining about are being made for reasons discussed at great length in many painful ways in these last few pages is no longer that same version.

Wonderfully helpful and constructive feedback you've left here.

1. That quote imo reflects what the default devices were supposed to be and was clearly done by Min. I get it was put in there before 3.x but I can't see how it's untrue previous to the dev builds.

2. I gave feedback in the last couple of pages back but clearly they have made their decision. I feel like you're the pot calling the kettle black here, lets end this discussion, too far off topic.

qawsedrftg765 · July 7, 2017

Just in reply to Kimy & Princessity regarding the previous pages. As someone who was a dev on a relatively large application and has read 100s of "elevated" support tickets that can be solved by RTFM, I get how frustrating on-going development can be. Especially how hard it can be when that work is, for the most part, a passion piece; where the stakes can feel higher, not lower, than professional work.

That being said, I have never had to suffer my work being a dependency of something else's also beloved work [Thank goodness]. So I do feel for Vel, even if he seems a little stubborn.

I just wanted to say to all the developers who read this, thanks for your work.

It may seem corny to some who have not been on the administration end of a support ticket to just randomly say thanks. But I just wanted to come in whilst tensions are high and just say for myself, out of the 10,000s of people who have made skyrim a more devious page.

Thankyou.

Also, so this post does not get removed for not being support related. I thought the two-tone 'hobblejacket' was intentional and I think looks pretty snazzy. In reply to @MrBig

donotbugme · July 7, 2017

I think the new system offers a lot of flexibility but some challenges to implementation. I agree with killing some of the user options to open up supportable modding experiences. I'm going to see what interesting devices can be made with a few property changing

Edit. I'm not even going to get into that can of worms never mind

donotbugme · July 7, 2017

i think we should be grateful that we have such talented modders.

if you dont like something why not change it yourself since isnt this what modding is about?

Foreword im not affiliated with the dd Dev team. I appreciate your sentiment but

I believe the problem is changing code or assets you have a dependency on affects other mods relying on that dependency unless you duplicate and continue to maintain it essentially making a branch. Making your mod potentially incompatible with other mods you expect for any given end user. Or forcing users to choose X mod or y mod. We have seen this happen already in the context of dd before but I mention no names and that is from some time ago.

Either way it's more headache and only the user base suffers. Not what modders want. So it should be avoided for all concerned.

At the end of the day I trust the DD team will make changes according to a decision after getting constructive feedback.

I believe there has been some resolution to a few of the worries brought up several pages ago but some discussion hopefully more civil, or least feedback given can only help. The silver lining is that people care enough to get angry and hopefully things will get eventually figured out by the people who care.

kinkykusco · July 7, 2017

I've been using the latest dev build for the past week, playing the game and mostly testing it through DCL fired events, plus some experimenting. A couple possible bugs:

Many of the white DDx items show the same item in black in the inventory view.
Taking off the elbow binder seems to leave my girl with her arms permanently welded behind her back.
The pear gag shows text about strapping it behind ones head - Should instead be something like "The metal contraption slides in past your teeth, already filling your mouth. Turning the end, you feel the petals push your mouth open further and further, until your jaw feels as if it's fire. The pear finally clicks in place, and cannot be closed again without a key."

And thoughts on the new release mechanism - It would be nice to see the menu be a bit "smarter", so that options that are not going to work at all are not shown - for example if the lock is jammed, the user should not even be offered the option to unlock. Along with, a device "status" should be part of the header text "locked, jammed, etc" if possible.

The 4 hour timer before being able to try again, as a universal setting, sometimes leads to some non-immersive results. For example, one time I tried unlocking the simple iron collar (no other restraints worn), and was told that I couldn't manage it, and was to exhausted to try again - in reality no one would ever have a hard time unlocking a iron collar if they had the proper key and were otherwise not bound. Even my yoke I can get out of with the key, but that does take a minute or two and dropping the key is easy, so I can accept it happening there.

I would suggest lowering the times either by item or universally. Generally I just ended up waiting 4 hours to try again.

Mostly I've been enjoying the changes in the dev pack, especially the heretic items. Nothing game breaking by far have I noticed. Thanks for your work -

Sign In

Devious Devices Framework Development/Beta

Recommended Posts

Link to comment

Link to comment

Guest

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Create an account or sign in to comment

Create an account

Sign in

Recently Browsing 0 members

Important Information