Devious Devices Framework Development/Beta

[galgat]

there are a bunch of mods that I have been hearing have problems with 4.0, many with the arm binder, and Yoke,  but I am assuming this means that any older mod that use's the Arm binder, and the author to it has left the scene, will never be functional with 4.0.

 

  I am in some testing forums, and there seem to be having problem's, mostly with the arm binder, and yoke, but the new forced wait 2 hours, and for me every generic item I put on, breaks the key I would say 50% of the time. ( I play on the easiest Level )

 

  This is why I have backed away from 4.0 for now, it is just to frustrating, I have a profile for testing other peoples mods with 4.0 in it, but as a rule right now, I don't want to actually be in any lengthy game play with it.

 

   Is a really hard choice for me, because there have been some really nice additions to the bondage wear, but ( wonderful work from the clothing maker's of DDI ) is just to much forced stuff came with DDI 4.0, and to little choice for me to create my own personal fantasy conditions.

 

 

  P.S. Captured dreams will not remove the Arm binder, this is fucked sense DDI 4.0, I believe the CD arm-binders will get removed, but not the generic from DDI 4.0.

[BAB PEEG]

I installed version 4 and even if I have to key for certain items like gags and cuffs it keeps saying "you choose to put etc on" when I just want them off.

[LazyBoot]

6 hours ago, BAB PEEG said:

I installed version 4 and even if I have to key for certain items like gags and cuffs it keeps saying "you choose to put etc on" when I just want them off.

Make sure you don't have any mod overwriting any scripts or modifying items from devious devices.

[DCPDDP]

On 1/7/2018 at 10:25 PM, bicobus said:

Those are never advertised to the player. It is also something that should go into a content mod, not into a framework.

Remain claim your question will be answered with or without sass depending on how you ask it. With that said this is a mod not something will in the vanilla game maybe you should read the mod's page/patch notes a head of time to understand everything the mod does an not expect a step by step in-game tutorial for the mod.

 

P.S you can also always just click manipulate lock when equipping the item you said it your self you use the mod for aesthetic an want the freedom to remove the item without key braking well equipping it this way let you do that.

[Veladarius]

On 1/7/2018 at 6:18 PM, worik said:

DD for the masses https://www.loverslab.com/files/file/424-d comes to my mind. But unfortunately it is still for DD3 and not yet updated to cope with DD4 ... I can't comment on the impact of that old version on keys .. have not tested it in game yet.

All items in For the Masses come directly from DD including real keys. Armbinders and yokes may not work on npc's but the rest should.

[zer0hour]

Hey guys, was the bug with followers' hands showing when wearing a straitjacket fixed?

 

Cos I'm still getting it, and searching the forum doesn't seem to show a resolution.

[HyperonicX]

1 hour ago, zer0hour said:

Hey guys, was the bug with followers' hands showing when wearing a straitjacket fixed?

 

Cos I'm still getting it, and searching the forum doesn't seem to show a resolution.

I found that changing cell locations helps. I've got Lydia in one of those and at first she had that bug, but when I went elsewhere the glitch disappeared. (I think.)

[DeepBlueFrog]

I came across a serious loophole/cheat you probably know about, but in case it has not been reported yet, here it is in spoilers.

 

Spoiler

- receive a generic item (I tested it with locked gloves)

- find a vendor that is willing to buy it (tested with one of the Khajiit caravans)

- sell the gloves

- gloves get briefly unequipped and you receive the money before they get automatically equipped again

- rinse and repeat for profit

 

I don't know how that would be fixable though.

[Veladarius]

10 hours ago, DeepBlueFrog said:

I came across a serious loophole/cheat you probably know about, but in case it has not been reported yet, here it is in spoilers.

 

  Reveal hidden contents

- receive a generic item (I tested it with locked gloves)

- find a vendor that is willing to buy it (tested with one of the Khajiit caravans)

- sell the gloves

- gloves get briefly unequipped and you receive the money before they get automatically equipped again

- rinse and repeat for profit

 

I don't know how that would be fixable though.

It isn't fixable and has been known about since the mod's creation years ago. If you want a cheat to get money try   player.additem f 1000000000  it is faster, not limited by the vendors gold and you won't have to worry about gold again (unless it gets stolen then you just repeat the cheat).

[Code Serpent]

6 hours ago, Veladarius said:

It isn't fixable and has been known about since the mod's creation years ago. If you want a cheat to get money try   player.additem f 1000000000  it is faster, not limited by the vendors gold and you won't have to worry about gold again (unless it gets stolen then you just repeat the cheat).

It could be fixed, by either editing the vendor's dialogue conditions so they won't trade with the player when she's wearing restraints, or adding blocking dialogue to vendors when the player is wearing restraints, similar to how carriage drivers reject the player when they're wearing a yoke or armbinder.

 

Of course, the former option could cause compatibility issues, and the latter would make it impossible to complete some quests until the player is completely free, and both would make the game much more difficult by making it impossible to sell anything for most of the game, depending on how they use this mod.

[naaitsab]

19 minutes ago, IronDusk33 said:

It could be fixed, by either editing the vendor's dialogue conditions so they won't trade with the player when she's wearing restraints, or adding blocking dialogue to vendors when the player is wearing restraints, similar to how carriage drivers reject the player when they're wearing a yoke or armbinder.

 

Of course, the former option could cause compatibility issues, and the latter would make it impossible to complete some quests until the player is completely free, and both would make the game much more difficult by making it impossible to sell anything for most of the game, depending on how they use this mod.

That's the difference between something that should be fixed and something that could be fixed.

As Veladarius points out there are a lot easier ways to cheat for money. Modifying default game scripts/dialogue with comparability in mind is not recommendable and even unwanted for something like DD.

[Veladarius]

37 minutes ago, IronDusk33 said:

It could be fixed, by either editing the vendor's dialogue conditions so they won't trade with the player when she's wearing restraints, or adding blocking dialogue to vendors when the player is wearing restraints, similar to how carriage drivers reject the player when they're wearing a yoke or armbinder.

 

Of course, the former option could cause compatibility issues, and the latter would make it impossible to complete some quests until the player is completely free, and both would make the game much more difficult by making it impossible to sell anything for most of the game, depending on how they use this mod.

Items are already marked with the vendornosale keyword, you have to have the proper perk to be able to sell them, be in the thieves guild and selling to one of their people or selling to CD's Master as she is set to buy even items with that keyword on it.

 

As for the carriage drivers that is from Cursed Loot as I have used carriages with those items on without hassle.

 

Overall as I said before, there are much faster and easier ways to cheat and get gold. This was discussed years ago among the developers and deemed a non issue.

[LazyBoot]

33 minutes ago, Veladarius said:

As for the carriage drivers that is from Cursed Loot as I have used carriages with those items on without hassle.

The main issue with carriages while bound, if I recall, is that wearing heavy restraints (at least armbinders) will block using the actual carriage (same way it prevents sitting etc)

Though I personally have made a change to exclude the carriage from the blocker.

[DeepBlueFrog]

1 hour ago, Veladarius said:

Items are already marked with the vendornosale keyword, you have to have the proper perk to be able to sell them, be in the thieves guild and selling to one of their people or selling to CD's Master as she is set to buy even items with that keyword on it.

 

As for the carriage drivers that is from Cursed Loot as I have used carriages with those items on without hassle.

 

Overall as I said before, there are much faster and easier ways to cheat and get gold. This was discussed years ago among the developers and deemed a non issue.

Then maybe some generic items from DDx  are missing said keywords?

 

I was able to sell them without any perk.

 

I agree there are easier ways to cheat. I only brought it up because I ran into it by accidentally cheating.

[greyspammer]

As per request relayed to me by LazyBoot, I'm posting this here as well (already did so in the regular thread for DDi):

 

The bug that I believe to have found here seems to still exist in the current version 4.0. Original code from 3.3b:

 

On 22.9.2017 at 7:20 PM, greyspammer said:

But I think I may have found the culprit. I took another look at the whole loop in that function and think there's a bug here, in line 1994:

 

		;;;;;;;;;;
		; Play horny idle?
		;;;;;;;;;;
		if (Config.HardcoreEffects || akActor != PlayerRef) && (vibAnimStarted == 0) && Utility.RandomInt() <= (3+(VibStrength * 2)) && !IsAnimating(PlayerRef)
			; Log("XXX Starting Horny Idle")
			ApplyExpression(akActor, expression, (Aroused.GetActorExposure(akActor) * 0.75) as Int, openMouth=true)
			; Select animation
			string randomAnim
			if (nPiercings && !(vPlug || aPlug))
				randomAnim = "Horny03"
			Else
				randomAnim = "Horny01"
			EndIf
			cameraState=StartThirdPersonAnimation(akActor, AnimSwitchKeyword(akActor, randomAnim), permitRestrictive=true)
			vibAnimStarted = timeVibrated + 1
			; Log("XXX VibrateEffect: Done starting horny idle")
		EndIf

Take a look at the very last condition in the first if-statement. It always checks against the player. But shouldn't it check against the actor that the function is called on? Because the way it's written there, I can see why it's not working. Whatever factions the actor is in, don't actually matter. As soon as the loop decides to play the horny animation, it'll happen.

 

To test my theory, I changed my code so that the player is also set to be animating. And lo and behold, now the actor can be stimulated for several minutes and she never plays a horny animation or loses her animating state. But I don't think that's how it's supposed to work.

 

 

So either there's something I have yet to understand, or there might be a bug in the zadlibs.psc that needs fixing.

 

 

That code is still present in 4.0 (line 2129):

 

		;;;;;;;;;;
		; Play horny idle?
		;;;;;;;;;;
		if (vibAnimStarted == 0) && Utility.RandomInt() <= (3+(VibStrength * 2)) && !IsAnimating(PlayerRef)

 

It is my belief that "!IsAnimating(PlayerRef)" needs to be changed to "!IsAnimating(akActor)". As it is currently written, the if-statement always checks if the player is currently animating. Even if the function isn't called on the player but some other actor. It should check the actor that the animations would have to be played on, shouldn't it?

[Kimy]

Will fix this. Thanks!

[Solatium]

I'll totally defer to the more experienced modders here (I've barely just started working with Papyrus), but would it make sense to offload the device menu system to a quest script/instance, or series of quest scripts/instances (one base script per device type)? If I'm understanding this right, item scripts can have several running in parallel, while quest scripts would be more like singletons since you can't "spawn" quests. Since all menus would be handled by the player, I imagine a menu system could exist as one instance, and would be easier to maintain than a menu system dedicated to each device. It might also help reduce the number of "if zad_someMenu zad_someMenu.show() else libs.zad_someMenu.show() endIf" blocks that are in zadEquipScript, and the number of properties in the property editor.

 

There's probably something I haven't considered in this proposal, and Papyrus is probably much different than the programming languages I'm used to, but the way I see it it's like designing data models - if something gets too big or too complex, you split it apart into different functional pieces. If an object has dozens of fields that all deal with the same bit of functionality, I might group them together into their own object. If a class has a huge, difficult to traverse hierarchy, I might consider composition in place of inheritance (i.e. one class delegates to an instance of another class dedicated to a specific function, instead of using a subclass).

[Veladarius]

11 hours ago, Solatium said:

I'll totally defer to the more experienced modders here (I've barely just started working with Papyrus), but would it make sense to offload the device menu system to a quest script/instance, or series of quest scripts/instances (one base script per device type)? If I'm understanding this right, item scripts can have several running in parallel, while quest scripts would be more like singletons since you can't "spawn" quests. Since all menus would be handled by the player, I imagine a menu system could exist as one instance, and would be easier to maintain than a menu system dedicated to each device. It might also help reduce the number of "if zad_someMenu zad_someMenu.show() else libs.zad_someMenu.show() endIf" blocks that are in zadEquipScript, and the number of properties in the property editor.

 

There's probably something I haven't considered in this proposal, and Papyrus is probably much different than the programming languages I'm used to, but the way I see it it's like designing data models - if something gets too big or too complex, you split it apart into different functional pieces. If an object has dozens of fields that all deal with the same bit of functionality, I might group them together into their own object. If a class has a huge, difficult to traverse hierarchy, I might consider composition in place of inheritance (i.e. one class delegates to an instance of another class dedicated to a specific function, instead of using a subclass).

The menu's are only accessed by the player so how fast and often is not very high. If it was thought that there was too much of a load on the equip script for these then they could be moved to the device scripts themselves as they extend the equip script (I extend the script and use my own menu's for my custom items in place of the standard menus) and could still access its functions while maintaining its own menu.

[throwaway219]

DD is good kinky fun, but we all have our own thresholds where pleasure tips over into pain.

 

I know that the new device escape options are one of the pillars of v4, and it gives a lot of control to modders to customize their items, but I do really wish we could change the options individually.  Please... please let us configure EscapeCooldown, KeyBreakChance, LockJamChance, RepairCooldown, UnlockCooldown, LockAccessDifficulty, LockShieldTimerMin, and LockShieldTimerMax individually.  At least the default values for items that haven't been manually configured by the modder.  Although I'm not sure how modders actually override it for their own objects (does every item inherit from zadEquipScript then set the Properties on the object?) so I'm not sure it's that easy.

 

The code in zadEquipScript is well factored now and it seems like it would be a straightforward change - the MCM code and then one change to each of the methods in zadEquipScript.  I think?

But if yall are still really, really opposed... is the solution to write an MCM mod that offers the individual values, then, uh, hmm.  CalculateDifficultyModifier doesn't know which modifier is being checked and doesn't have an extensibility hook anyway.  I don't think it's as easy as just getting a reference to zadEquipScript and changing the Properties because I think it's per-item?  So perhaps have the config mod listen for, um, OnEquipped, then set the Properties on each item?  They would still be affected at runtime by the DD4 difficulty modifier, but the config mod could duplicate the CalculateDifficultyModifier code and use that plus the modifier to display the resulting values.

[SleepyJim]

On the subject of the difficulty settings, I suppose it's not as easy as using console commands to configure each part of it? So if someone really didn't want locks to jam, for example, or keys to break, or cooldowns to apply, would there be a command that could be entered to set the chance of these individual things to zero, even if you've already chosen a high difficulty?

[LazyBoot]

10 hours ago, throwaway219 said:

 Although I'm not sure how modders actually override it for their own objects (does every item inherit from zadEquipScript then set the Properties on the object?) so I'm not sure it's that easy.

Make item, add script to item, then set properties on the item in the creation kit. No editing of scripts or compiling needed, that's quite a lot easier than it used to be.

 

And how do you propose to make a menu to choose escape settings when pretty much every device is using a different value for them? Yes, nearly all, if not all, of the devices included in DD is using values that are not the default values. That's probably why the devs decided to go with the global setting that affect all the values the same.

[El_Duderino]

12 minutes ago, LazyBoot said:

10 hours ago, throwaway219 said:

 Although I'm not sure how modders actually override it for their own objects (does every item inherit from zadEquipScript then set the Properties on the object?) so I'm not sure it's that easy.

Make item, add script to item, then set properties on the item in the creation kit. No editing of scripts or compiling needed, that's quite a lot easier than it used to be.

 

And how do you propose to make a menu to choose escape settings when pretty much every device is using a different value for them? Yes, nearly all, if not all, of the devices included in DD is using values that are not the default values. That's probably why the devs decided to go with the global setting that affect all the values the same.

Further to what LazyBoot already said:

 

The way I understood it, the new system works as follows:

- zadEquipScript sets default values for Escape and Struggle mechanics (escape chances, key brake, cooldown timers, etc.)

- when related Properties are not filled for a device in the CK, they default to those from zadEquipScript

- otherwise, properties as defined per device override the defaults (for example, base escape change = 0 for an inescapable device)

- Difficulty Modifier applies up to +/- 75% to all chances, both the defaults in the script and (I think) also custom ones

- Difficulty Modifier does NOT apply to devices tagged with QuestItem or BlockGeneric keywords (unless those also have the AllowDifficultyModifier=true property)

 

[throwaway219]

Thanks you two!

9 hours ago, LazyBoot said:

Make item, add script to item, then set properties on the item in the creation kit. No editing of scripts or compiling needed, that's quite a lot easier than it used to be.

 

And how do you propose to make a menu to choose escape settings when pretty much every device is using a different value for them? Yes, nearly all, if not all, of the devices included in DD is using values that are not the default values. That's probably why the devs decided to go with the global setting that affect all the values the same.

It's useful to know that the default items in DD4 do in fact have custom difficulties set, and the explanation for how they actually get applied to items is very helpful.  Given that data, I think it would be just fine to use the global setting to modify their built-in difficulties.  All I really want to do is have eight different global settings - one for each different options.  Based on what you two have said, and from reading the code, I don't see a good way to plumb that into the existing architecture from outside.  There are no extensibility hooks that I could plug into.  So I think it would have to be a DD4 change.

 

I think the ideal pull request would:

- Add a parameter to CalculateDifficultyModifier to select a specific difficulty modifier (an enum, or value from a set of consts since I don't remember if Papyrus has enums)

- Change each of the escape methods in zadEquipScript to pass in the appropriate enum.

- Change the existing difficulty setting and its UI strings to affect just EscapeCooldown.

- Add seven new MCM settings to allow individual control over KeyBreakChance, LockJamChance, RepairCooldown, UnlockCooldown, LockAccessDifficulty, LockShieldTimerMin, and LockShieldTimerMax.

- Add UI strings and tooltips for each of them.

- Add MCM code to set a default value for each of the new settings when upgrading DD4 to DD4.1.

 

If I wanted to take a swing at this pull request - and I'm not committing to it - would it be something that the dev team would approve, or is the concept a flat no even with code in hand?

[Solatium]

For the random animations that disable player control, is it possible to make the player walk at half speed instead?

 

It feels like it would flow better with the game if my character is struggling to move instead of coming to a complete stop. Also, and maybe this is just because I’ve used DD for so long, some of the animations end up feeling boring and repetitive.

[Solatium]

20 minutes ago, throwaway219 said:

Thanks you two!

It's useful to know that the default items in DD4 do in fact have custom difficulties set, and the explanation for how they actually get applied to items is very helpful.  Given that data, I think it would be just fine to use the global setting to modify their built-in difficulties.  All I really want to do is have eight different global settings - one for each different options.  Based on what you two have said, and from reading the code, I don't see a good way to plumb that into the existing architecture from outside.  There are no extensibility hooks that I could plug into.  So I think it would have to be a DD4 change.

 

I think the ideal pull request would:

- Add a parameter to CalculateDifficultyModifier to select a specific difficulty modifier (an enum, or value from a set of consts since I don't remember if Papyrus has enums)

- Change each of the escape methods in zadEquipScript to pass in the appropriate enum.

- Change the existing difficulty setting and its UI strings to affect just EscapeCooldown.

- Add seven new MCM settings to allow individual control over KeyBreakChance, LockJamChance, RepairCooldown, UnlockCooldown, LockAccessDifficulty, LockShieldTimerMin, and LockShieldTimerMax.

- Add UI strings and tooltips for each of them.

- Add MCM code to set a default value for each of the new settings when upgrading DD4 to DD4.1.

 

If I wanted to take a swing at this pull request - and I'm not committing to it - would it be something that the dev team would approve, or is the concept a flat no even with code in hand?

Device difficulty sort of led to my whole “delegate device functionality to quests” post. Say a developer wants to create a series of leather items (easy to cut through and struggle out of) and a series of high-security items (unpickable locks, impenetrable material, etc). When you set the properties for each item, you’re probably re-using the same set of values for the leather items and the same set for the inescapable ones, which seems like a hassle if you’re making a ton of new items.

 

What if you had a script that was just the device escape properties, and you used instances of that one script in place of the half-dozen properties that determine escape? One instance could be for leather, one could be for high-security, one could be padded metal, etc. Then those instances could be configured in the menu.