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

April 23, 2019

2 hours ago, LazyBoot said:

I believe most of the tail plugs should copy the player characters hair color when worn.

? oh that's really cool!

I never noticed

TheArchlich · April 23, 2019

Hey I have a gamebraking problem with this mod.

It's about the animation filter - It just doesn't work.

Is there any fix for that?

I also get thing like: Game says playing blowjob and he fucks her in a pussy.

May be related to this:

Edit: I fixed it. It's a bug in DDi script. It's the use bound animation option - it has a higher priority than the animation filter.

TheArchlich · April 26, 2019

This mod is broken!

First of all it adds new sex animations and there is nothing about that in the mod description. It took me 2 days to find where those animations are coming from.

Those animations do not show up in SexLab neither can be successfully unregistered with SexLab Tools.

Animations added by DDi are incompatible with Devious devices - they ignore the animation filter.

Here is my stream, where this mod is preventing me from playing normally:

Problems start about 23:30 and persist till the end of the video.

https://www.pornhub.com/view_video.php?viewkey=ph5cc2838505b3f

LazyBoot · April 26, 2019

2 hours ago, TheArchlich said:

First of all it adds new sex animations and there is nothing about that in the mod description. It took me 2 days to find where those animations are coming from.

Those animations do not show up in SexLab neither can be successfully unregistered with SexLab Tools.

Animations added by DDi are incompatible with Devious devices - they ignore the animation filter.

Unless another mod has registered them in sexlab, any animations from DDi should not show up in normal scenes, only when wearing devices...

And they are specifically designed to be compatible with devices.

TheArchlich · April 26, 2019

2 hours ago, LazyBoot said:

Unless another mod has registered them in sexlab, any animations from DDi should not show up in normal scenes, only when wearing devices...

And they are specifically designed to be compatible with devices.

They are not specifically designed to be compatible with the devices, and if they are they fucked it up, cause it's clearly not working.

I'm getting pussy-fucked through a chastity belt using a DDi animation.

Zaflis · April 27, 2019

36 minutes ago, TheArchlich said:

They are not specifically designed to be compatible with the devices, and if they are they fucked it up, cause it's clearly not working.

I'm getting pussy-fucked through a chastity belt using a DDi animation.

Did you check Cursed Loot that attackers can strip chastity belts, and that chastity prevents rape? It also seemed that you may have some other mod starting sex too but i didn't look too carefully. Not many mods talk about "your master". There are 2 main filters that matter for bound animations, one from DDi and other from ZAP.

TheArchlich · April 27, 2019

34 minutes ago, Zaflis said:

Did you check Cursed Loot that attackers can strip chastity belts, and that chastity prevents rape? It also seemed that you may have some other mod starting sex too but i didn't look too carefully. Not many mods talk about "your master". There are 2 main filters that matter for bound animations, one from DDi and other from ZAP.

As I said, I didn't do anything wrong, that's a DDi only issue.

Edit: That is not even a DCL rape so why would it matter?

*Inte* · April 27, 2019

@Kimy,

After trying DDi 4.2, I have some suggestions.

1. I have noticed you are no longer using ‘zadRestraintArmBinderScript’ on armbinders or any other extending script, is there a reason for this?

It is a good practice to create a script for each device that will extend the ‘zadEquipScript’ and attaching that to the corresponding device instead of attaching ‘zadEquipScript’ directly to every device. This will allow for more customization of each device type.

When used on armbinders for example, it will allow you to do this.

Spoiler


ScriptName iDDeResArmBinderScr Extends zadEquipScript

STRING[] Property sDefStruggleIdles
	STRING[] Function Get()
		STRING[] sIdles = NEW STRING[5]
			sIdles[0] = "DDRegArmbStruggle01"
			sIdles[1] = "DDRegArmbStruggle02"
			sIdles[2] = "DDRegArmbStruggle03"
			sIdles[3] = "DDRegArmbStruggle04"
			sIdles[4] = "DDRegArmbStruggle05"
		RETURN sIdles
	EndFunction
EndProperty

STRING[] Property sDefStruggleIdlesHob
	STRING[] Function Get()
		STRING[] sIdles = NEW STRING[2]
			sIdles[0] = "DDHobArmbStruggle01"
			sIdles[1] = "DDHobArmbStruggle02"
		RETURN sIdles
	EndFunction
EndProperty

Keyword[] Property DefEquipConflictingDevices
	Keyword[] Function Get()
		Keyword[] kws = NEW Keyword[3]
			kws[0] = libs.zad_DeviousArmbinderElbow
			kws[1] = libs.zad_DeviousYoke
			kws[2] = libs.zad_DeviousPetSuit
		RETURN kws
	EndFunction
EndProperty

Event OnInit()
	SetDefaults()
EndEvent

Function SetDefaults()
	If (struggleIdles.Length < 1) ;only overwrite them if they are not already manually set in CK
		struggleIdles = sDefStruggleIdles
	EndIf
	If (struggleIdlesHob.Length < 1)
		struggleIdlesHob = sDefStruggleIdlesHob
	EndIf
	If (EquipConflictingDevices.Length < 1)
		EquipConflictingDevices = DefEquipConflictingDevices
	EndIf
EndFunction

which will make it way easier to add or remove default idles for armbinders, and help tremendously with the existing armbinders’ backward compatibility as modders would not have to add all those idles manually.
Also, notice the similar implementation of device conflict keywords which does not seem implemented atm.

Since this method is dependent on the ‘OnInit’ event, should you decide to add that event to the ‘zadEquipScript’ don’t forget to add an empty function like ‘SetDefaults()’ so other scripts can also use the ‘OnInit’ event, and let me know so I can remove my ‘OnInit’ event as only the last one in the chain will execute.

This can also be done for other devices types as well, by creating their own scripts of course.

Spoiler


ScriptName iDDeResElbowBinderScr Extends zadEquipScript

STRING[] Property sStruggleIdlesDef
	STRING[] Function Get()
		STRING[] sIdles = NEW STRING[5]
			sIdles[0] = "DDRegElbStruggle01"
			sIdles[1] = "DDRegElbStruggle02"
			sIdles[2] = "DDRegElbStruggle03"
			sIdles[3] = "DDRegElbStruggle04"
			sIdles[4] = "DDRegElbStruggle05"
		RETURN sIdles
	EndFunction
EndProperty

STRING[] Property sStruggleIdlesHobDef
	STRING[] Function Get()
		STRING[] sIdles = NEW STRING[2]
			sIdles[0] = "DDHobElbStruggle01"
			sIdles[1] = "DDHobElbStruggle02"
		RETURN sIdles
	EndFunction
EndProperty

Keyword[] Property EquipConflictingDevicesDef
	Keyword[] Function Get()
		Keyword[] kws = NEW Keyword[3]
			kws[0] = libs.zad_DeviousArmbinder
			kws[1] = libs.zad_DeviousYoke
			kws[2] = libs.zad_DeviousPetSuit
		RETURN kws
	EndFunction
EndProperty

Event OnInit()
	SetDefaults()
EndEvent

Function SetDefaults()
	If (struggleIdles.Length < 1) ;only overwrite them if they are not already manually set in CK
		struggleIdles = sStruggleIdlesDef
	EndIf
	If (struggleIdlesHob.Length < 1)
		struggleIdlesHob = sStruggleIdlesHobDef
	EndIf
	If (EquipConflictingDevices.Length < 1)
		EquipConflictingDevices = EquipConflictingDevicesDef
	EndIf
EndFunction

You should add a dedicated script for each device type even if empty because it will afford you more flexibility in the future.

The armbinders for instance, can very easily be done in TESV Edit as you would only need to change the script name (from zadEquipScript to zadRestraintArmBinderScript), and all the properties already assigned will remain because ‘zadRestraintArmBinderScript’ extends ‘zadEquipScript’ already.

Also, just by applying a filter in TESV edit you can simplify and expedite the process by quite a bit.

Spoiler

Then rename the script, just make sure it is compiled before opening it in CK.

Spoiler

2. You might want to expand this function

Spoiler


string Function LookupDeviceType(keyword kwd)
...
ElseIf kwd == zad_DeviousHobbleSkirtRelaxed
	return "HobbleSkirt"
ElseIf (kwd)
	RETURN (kwd AS STRING) ;or 
	RETURN kwd.GetName() ; Not sure if this works for keywords, tho. 
EndIf
...
[/code]

in ‘zadLibs’ to accommodate for new custom keywords added by other mods (e.g. Mech Suit from DDe).

3. You’ve emphatically shut me down on this before, but I will suggest a change to the DDi versioning one last time.
Keeping 2 different version numbers for a mod is just a bad practice because it creates a lot of confusion, as least for modders, which is more prevalent when it comes to frameworks such as DDi. If I need to see which version of DDi is installed I have to go into DDi’s code and see whether the script version 10.0 corresponds to DDi 4.2 or 4.00 or whatever.

How about this simpler implementation?

It seems that since most scripts are already using 'zadLibs' as a property, it cannot be called for global functions as well. So, you'll have to create a separate script extending a quest, you do not need to attach it to a quest, tho. But, this will afford you the opportunity to provide users with even more functionality such as an API function.

Something like this,

Spoiler


ScriptName zadUtil Extends Quest

Import Game

;Version
FLOAT Function GetVersion() GLOBAL  
	RETURN 4.20 
EndFunction 
STRING Function GetVersionStr() GLOBAL  
	RETURN StringUtil.Substring(GetVersion(), 0, 4)  
EndFunction 
 
;API
zadLibs Function GetAPI() GLOBAL
	If (GetModByName("Devious Devices - Integration.esm") < 255)
		RETURN GetFormFromFile(0x0000F624, "Devious Devices - Integration.esm") AS zadLibs 
	EndIf
	RETURN None
EndFunction

Then, in the zadLibs script for continuity,

Spoiler


FLOAT Function GetVersion()
	RETURN zadUtil.GetVersion()
EndFunction 
STRING Function GetVersionStr()
	RETURN zadUtil.GetVersionStr()
EndFunction

Finally, in the MCM config script

Spoiler


Int Function GetVersion()
	RETURN ((zadUtil.GetVersion() * 100) AS INT)
EndFunction

With this, any mod looking just to check the DDi version would only need one line of code.

zadUtil.GetVersion()

works from any script with no dependency checks, no properties, no guesswork (i.e. wether the returned version of 10.0 = DDi 4.2 or some other DDi version; the official version is the script version), just simple and efficient. Also with every update you need only change one number in one place.

4. Struggling out of an armbinder is utter nonsense IMHO (especially the elbowbinders), and having a NPC release you should be the only way out. Therefore, you should add back the armbinder/heavybondage dialogue release option (you can make it toggleable in the MCM), so all the small mods out there (DDe, DC, etc.) do not have to create their own dialogue system just to release the player from the armbinder, and end up with 50 different dialogs from 50 different mods. You could just move the DCL one to DDi.

5. I have noticed that plugs (the rendered part of the device) are still being dropped (as they were in DDi 3) when wearing bondage mittens and equipped in script. This results in a broken device. You might want to add the zad_DeviousPlug keyword to the ‘IsDeviousDevice()’ function check in the bondage mittens effect script.

6. When the elbowbinder is equipped there is a 3 time animation cycling between normal and bound pose. Is this a known issue, or is it just on my end?
BTW, love the elbowbinder. Ouch! ❤️ Have I known it was in there I would have ‘converted’ earlier. :classic_wink:

7. Your usage of ‘zad_DeviousHeavyBondage’ keyword for all the devices that bind the arms is super convenient, however it seems to break the ‘ManipulateGenericDeviceByKeyword()’ function. In my tests it failed to add back the items removed (armbinder, elbowbinder) about 50% of the time where it worked perfectly in DDi 3.

8. What is the point of the extra keyword (token) on ‘quest’ devices?

9. I still get belt message boxes after sleep and wait even tho I've unchecked that option in the MCM.

Ninja edited, for better readability and more content.

*Kimy* · April 29, 2019

On 4/26/2019 at 11:14 PM, Inte said:

@Kimy,

After trying DDi 4.2, I have some suggestions.

1. I have noticed you are no longer using ‘zadRestraintArmBinderScript’ on armbinders or any other extending script, is there a reason for this?

The old implementation was very, as in VERY complicated. Wrist restraints required several scripts and effects to set up, and it made making custom devices living hell. The new one? Just slap the standard script (zadEquipScript) on, put the generic enchantment on the rendered device, and you're done! No messing with multiple scripts!

On 4/26/2019 at 11:14 PM, Inte said:

It is a good practice to create a script for each device that will extend the ‘zadEquipScript’ and attaching that to the corresponding device instead of attaching ‘zadEquipScript’ directly to every device. This will allow for more customization of each device type.

You CAN inherit that script for custom devices, but 99% of time you won't have to, and in fact, shouldn't. zadEquipScript is meant to be used unchanged for almost all devices. Pretty much all item behavior can be defined via script properties (see documentation in the code!). No custom code needed! Even the idles can be set individually via properties and without changing any code whatsoever. I know it's a bit of a paradigm change compared to 3.x, but I am absolutely convinced you will love the new implementation once you get used to it!

Some device types with non-standard behavior still use inherited device scripts (e.g. plugs and belts). If we ever introduce new device types that need non-standard code, they will get their own device script, of course. Right now, I can't imagine what that should be, though. There is almost no type of restraint left in the world we don't already cover.

On 4/26/2019 at 11:14 PM, Inte said:

in ‘zadLibs’ to accommodate for new custom keywords added by other mods (e.g. Mech Suit from DDe).

A mech suit's device keyword (as far as the framework is concerned) would still be zad_DeviousSuit (assuming it occupies slot 32). You can put as many custom keywords on a device as you wish, mind you, but if you need text replacement, you'd have to do that in your content mod.

On 4/26/2019 at 11:14 PM, Inte said:

3. You’ve emphatically shut me down on this before, but I will suggest a change to the DDi versioning one last time.
Keeping 2 different version numbers for a mod is just a bad practice because it creates a lot of confusion, as least for modders, which is more prevalent when it comes to frameworks such as DDi. If I need to see which version of DDi is installed I have to go into DDi’s code and see whether the script version 10.0 corresponds to DDi 4.2 or 4.00 or whatever.

I know you disagree with me on that VERY much so, but I really think it's good practice to differ between an internal build number and the official version number. It's not that it's a not widespread practice in software development, you know?

On 4/26/2019 at 11:14 PM, Inte said:

4. Struggling out of an armbinder is utter nonsense IMHO (especially the elbowbinders), and having a NPC release you should be the only way out. Therefore, you should add back the armbinder/heavybondage dialogue release option (you can make it toggleable in the MCM), so all the small mods out there (DDe, DC, etc.) do not have to create their own dialogue system just to release the player from the armbinder, and end up with 50 different dialogs from 50 different mods. You could just move the DCL one to DDi.

I totally agree! Struggling out of a properly applied armbinder is utterly impossible. At least I am not aware of anyone who ever managed to accomplish such a feat. However, struggling has been in the framework since DD 1.0 (I suppose because there were otherwise no mechanics available to escape these things and Min wanted to avoid people getting stuck). If I change that device's behavior so drastically, I have no idea how much stuff I would break in people's mods. I consider the standard armbinders to be "practice restraints", and don't normally use them in my quest content etc. Good that DD4 made making custom devices so easy, so all I have to do is cloning an armbinder and set the struggle chance property to zero! Try that with DD3, haha!

The device dialogue I actually DID remove to prevent having 50 different dialogues from 50 different mods. There are so many good "help me out of my bonds" mods around, that there is simply no good reason for the framework to provide that feature. This way users can pick the mod they want to have. Personally, I am using Devious Followers.

On 4/26/2019 at 11:14 PM, Inte said:

5. I have noticed that plugs (the rendered part of the device) are still being dropped (as they were in DDi 3) when wearing bondage mittens and equipped in script. This results in a broken device. You might want to add the zad_DeviousPlug keyword to the ‘IsDeviousDevice()’ function check in the bondage mittens effect script.

Will look into this! I think the mitten code needs some TLC in general.

On 4/26/2019 at 11:14 PM, Inte said:

6. When the elbowbinder is equipped there is a 3 time animation cycling between normal and bound pose. Is this a known issue, or is it just on my end?

Not quite sure what you mean?

On 4/26/2019 at 11:14 PM, Inte said:

BTW, love the elbowbinder. Ouch! ❤️ Have I known it was in there I would have ‘converted’ earlier.

There are literally hundreds of new devices in DD4. Have fun exploring them!

On 4/26/2019 at 11:14 PM, Inte said:

7. Your usage of ‘zad_DeviousHeavyBondage’ keyword for all the devices that bind the arms is super convenient, however it seems to break the ‘ManipulateGenericDeviceByKeyword()’ function. In my tests it failed to add back the items removed (armbinder, elbowbinder) about 50% of the time where it worked perfectly in DDi 3.

I will have to test that. I never use that function for anything but removing devices, so no clue, really!

On 4/26/2019 at 11:14 PM, Inte said:

8. What is the point of the extra keyword (token) on ‘quest’ devices?

It prevents mods from accidentally removing somebody's quest devices, so quest device removal can be done only REALLY on purpose.

On 4/26/2019 at 11:14 PM, Inte said:

9. I still get belt message boxes after sleep and wait even tho I've unchecked that option in the MCM.

There is a MCM option for that? Haha!

Nimkal · April 30, 2019

On 4/21/2019 at 5:01 AM, Nimkal said:

Hi, seems like DDi is the only mod causing my game to crash during save load (not startup). I have the usual 250~ plugins and they are all working stably. Masters were checked,
DDa v3 is in fact working no problem. I have sexlab plus other animations working no problem. It's just DDi (v4.2). Animations are not maxed I'm at ~1500.
So my first question is, what are some mods that can be incompatible with DDi? And 2nd question is: Since DDi is an esm, load order does not matter correct?
I can't think of anything else Any help would be appreciated.

Can someone please help me with the issue above?

There is literally nothing that I can think of that would make DDi crash my game on loading screen. I just can't load game with this mod active. What is happening. I've checked everything. The only other explanation is if there is a mod incompatibility.

*Inte* · April 30, 2019

11 hours ago, Kimy said:

Quote

It is a good practice to create a script for each device that will extend the ‘zadEquipScript’ and attaching that to the corresponding device instead of attaching ‘zadEquipScript’ directly to every device. This will allow for more customization of each device type.

You CAN inherit that script for custom devices, but 99% of time you won't have to, and in fact, shouldn't.

Although I agree that you do not have to extend the ‘zadEquipScript’ to make the device work, like I mentioned before you should extend it regardless (even if empty) for future expansion, always. Why? Because there is absolutely no downside in doing so. In fact doing it will make for a more robust modding.

However, if not done and later on you find that someone has made some new cool idles that would work perfectly with your 500 devices you’ve already made, or the ‘zadEquipScript’ was changed so much that it cannot be used with your devices anymore, you are screwed. Your only choices then would be to,

1. Not use those new cool idles or the updated ‘zadEquipScript’.
2. Change about 30 properties for each one of your 500 devices for an estimated total of 15,000 properties.
3. Abandon your now broken mod.

For instance, ‘luckily’ for me I did extend ‘zadEquipScript’ on every single one of the DDe devices and by just adding the code I mentioned previously and changing a couple of properties for each device I was able to save DDe.

11 hours ago, Kimy said:

Quote

in ‘zadLibs’ to accommodate for new custom keywords added by other mods (e.g. Mech Suit from DDe).

A mech suit's device keyword (as far as the framework is concerned) would still be zad_DeviousSuit (assuming it occupies slot 32). You can put as many custom keywords on a device as you wish, mind you, but if you need text replacement, you'd have to do that in your content mod.

I was considering that, but the mech suit occupies all slots except for the gag and belt. Although the ‘zad_DeviousSuit’ keyword is already on it, I thought to use a custom keyword for removal. Or maybe ‘zad_DeviousStraightJacket now available in 4.2, IDK?
Also, that function is not used for text replacement but to temporary store devices in StorageUtil for quicker removal. Therefore, every time the mech suit is equipped players get the error box at the end of that function, which can get annoying after a while.

11 hours ago, Kimy said:

Quote

3. You’ve emphatically shut me down on this before, but I will suggest a change to the DDi versioning one last time.
Keeping 2 different version numbers for a mod is just a bad practice because it creates a lot of confusion, as least for modders, which is more prevalent when it comes to frameworks such as DDi. If I need to see which version of DDi is installed I have to go into DDi’s code and see whether the script version 10.0 corresponds to DDi 4.2 or 4.00 or whatever.

I know you disagree with me on that VERY much so, but I really think it's good practice to differ between an internal build number and the official version number. It's not that it's a not widespread practice in software development, you know?

So let me see here, if modders want to check for the DDi 4.20 version it would be better to:

1. Just grab the version and compare it to 4.20 and... that’s it. Or...
2. Go digging through 100 scripts to find out that version 4.20 is actually version 10, then grab that version and check against that. They would have to do this with every new DDi release because they wouln’t know whether the new release is 11 or 10.5 or whatever?

Give me one example where it is a good practice to have two different version numbers for the same mod build keeping in mind that, we are not talking Windows here, where you have 100 different departments working on the same build.

11 hours ago, Kimy said:

If I change that device's behavior so drastically, I have no idea how much stuff I would break in people's mods. I consider the standard armbinders to be "practice restraints", and don't normally use them in my quest content etc.

That is just it. You are not changing that device’s behavior at all. You are adding back the dialogue that allows a NPC to free a player in heavy bondage, that’s all.

11 hours ago, Kimy said:

Good that DD4 made making custom devices so easy, so all I have to do is cloning an armbinder and set the struggle chance property to zero! Try that with DD3, haha!

Actually in DDi 3 it was much simpler than that. All you had to do to is to call these functions after equipping the armbinder,
DisableStruggling() - It will... well disable struggle escapes,
DisableDialogue() - It will remove the dialog where any NPC can let you out of the armbinder,
and the best part, it worked with any armbinder, new or old.

11 hours ago, Kimy said:

The device dialogue I actually DID remove to prevent having 50 different dialogues from 50 different mods. There are so many good "help me out of my bonds" mods around, that there is simply no good reason for the framework to provide that feature. This way users can pick the mod they want to have. Personally, I am using Devious Followers.

So, having a centralized dialog option that all mods would have access to use and instead forcing each of them to create their own dialog option would prevent having 50 different dialogs from 50 different mods, how?

Show me a mod that provides just that one dialog feature* nothing more, and I will gladly use it and shut up about this, and that is to say nothing about the extra LO slot for a feature that we already had.

Personally, I thought you’d be using DCL, no? :classic_wink:

* - the feature DDi 3 has where a NPC would have the dialog to release the player from heavy bondage (for a price of course). Also it would allow the mod that equipped said heavy bondage to disable the dialog, and/or the struggle-out option.

11 hours ago, Kimy said:

Quote

6. When the elbowbinder is equipped there is a 3 time animation cycling between normal and bound pose. Is this a known issue, or is it just on my end?

Not quite sure what you mean?

Sorry, English is my 3rd language and the other 2 don’t like it when I use it. :classic_tongue:
After the elbowbinder is equipped the arms go in, then they pop out (no hands) then they go back in. This repeats about 3 times and in the end they stay in as they should.

11 hours ago, Kimy said:

Quote

8. What is the point of the extra keyword (token) on ‘quest’ devices?

It prevents mods from accidentally removing somebody's quest devices, so quest device removal can be done only REALLY on purpose.

IDK, I think the previous system (DDi 3) worked fine for that.

11 hours ago, Kimy said:

Quote

9. I still get belt message boxes after sleep and wait even tho I've unchecked that option in the MCM.

There is a MCM option for that? Haha!

Why yes there is and it’s not working for those message boxes which gets really annoying after you click off the same message box 50 times.

*Lupine00* · April 30, 2019

Some kind of debug menu feature to remove devices from NPCs would be handy.

e.g. I accidentally traded Maiden's Shield to Chloe.

I wanted to remove it from her, as I didn't intend to put her in it.

I couldn't seem to remove it via the console. I removed the device and the render device, but the render device would reappear after every cell change.

*Kimy* · April 30, 2019

14 hours ago, Inte said:

Although I agree that you do not have to extend the ‘zadEquipScript’ to make the device work, like I mentioned before you should extend it regardless (even if empty) for future expansion, always. Why? Because there is absolutely no downside in doing so. In fact doing it will make for a more robust modding.

However, if not done and later on you find that someone has made some new cool idles that would work perfectly with your 500 devices you’ve already made, or the ‘zadEquipScript’ was changed so much that it cannot be used with your devices anymore, you are screwed. Your only choices then would be to,

1. Not use those new cool idles or the updated ‘zadEquipScript’.
2. Change about 30 properties for each one of your 500 devices for an estimated total of 15,000 properties.
3. Abandon your now broken mod.

For instance, ‘luckily’ for me I did extend ‘zadEquipScript’ on every single one of the DDe devices and by just adding the code I mentioned previously and changing a couple of properties for each device I was able to save DDe.

Sure, if you want to code it that way in your mod, go ahead and do it! As you said, there is no obvious downside. I won't change the framework, because right now there is no reason to, and it would be just be work for me. If ever needed I can still set TES5Edit loose on it. Mind you that DD4 has been out for 1.5 years now, and never there has been a need for forking that script in places where it wasn't already.

14 hours ago, Inte said:

I was considering that, but the mech suit occupies all slots except for the gag and belt. Although the ‘zad_DeviousSuit’ keyword is already on it, I thought to use a custom keyword for removal. Or maybe ‘zad_DeviousStraightJacket now available in 4.2, IDK?
Also, that function is not used for text replacement but to temporary store devices in StorageUtil for quicker removal. Therefore, every time the mech suit is equipped players get the error box at the end of that function, which can get annoying after a while.

Ah right! I get it! Be careful not to confuse "occupied slots" with "used slots". The main device keyword should always be the "main device type" (e.g. the one your NIF is using), regardless of what other DD slots the item occupies. You can block any number of DD slots you want by putting on the additional keywords, but the one in the script should be the "main type", if that makes sense. E.g. If you make a belt with built-in plugs, pick zad_DeviousBelt as the device keyword and add the two plug keywords on the rendered device, in addition to the belt one. There are numerous devices in DD implemented that way.

14 hours ago, Inte said:

Actually in DDi 3 it was much simpler than that. All you had to do to is to call these functions after equipping the armbinder,
DisableStruggling() - It will... well disable struggle escapes,
DisableDialogue() - It will remove the dialog where any NPC can let you out of the armbinder,
and the best part, it worked with any armbinder, new or old.

Yeah, but IIRC, to get that done, you'd have to clone the entire armbinder AND all its scripts, because that function was called from the effect script. That's not exactly simple!

14 hours ago, Inte said:

So, having a centralized dialog option that all mods would have access to use and instead forcing each of them to create their own dialog option would prevent having 50 different dialogs from 50 different mods, how?

Show me a mod that provides just that one dialog feature* nothing more, and I will gladly use it and shut up about this, and that is to say nothing about the extra LO slot for a feature that we already had.

Devious Helpers is pretty much what you want, then.

14 hours ago, Inte said:

Personally, I thought you’d be using DCL, no?

Yes, I do! I use Devious Followers too, because its help dialogue is totally different from DCL's and adds another kind of fun risk.

14 hours ago, Inte said:

After the elbowbinder is equipped the arms go in, then they pop out (no hands) then they go back in. This repeats about 3 times and in the end they stay in as they should.

Oh right. I have seen that effect. I am not exactly sure what's causing it, tbh. I haven't really investigated it all that much, because it's purely cosmetic. I will have another look.

14 hours ago, Inte said:

IDK, I think the previous system (DDi 3) worked fine for that.

There was at least one mod that brute-forced quest devices off the player, so I felt the need to implement quest devices a bit more robust.... ?

I will have a look at the belt messages, too.

*Kimy* · April 30, 2019

10 hours ago, Lupine00 said:

Some kind of debug menu feature to remove devices from NPCs would be handy.

e.g. I accidentally traded Maiden's Shield to Chloe.

I wanted to remove it from her, as I didn't intend to put her in it.

I couldn't seem to remove it via the console. I removed the device and the render device, but the render device would reappear after every cell change.

I will consider it!

*OsmelMC* · May 1, 2019

I notes a issue whit Creature Animations in DDi 4.2 so i made changes in the code and works fine for my this is the file if some on like to use.

DDi v4.2 Creature Animation PATCH (2019_04_25).7z

Addasus · May 2, 2019

Hi there

I'm suddenly having a weird issue where some of the plugs and piercings no longer equip. Like the soulgem shock piercings. I've tried reinstalling the DD series, but that didn't seem to help. Am I missing an update?

Thanks

TurboNerd · May 2, 2019

I have some questions about how to do some things with DDi 4.2:

Manipulated locks: Is there a way to find out whether locks have been manipulated? Is there a way to manipulate or un-manipulate locks after a device is applied? (Something that works similarly to the accessor functions for jammed locks.) The motivation is I want to create some buffs for wearing devices that only work if the PC is not carrying keys. That’s pretty pointless if I don’t deal with the “manipulate the locks” work around.

Can a Papyrus script manipulate the properties of standard devices or must I clone all the devices? For example, can I disable struggling out of a standard armbinder?

Is there a straightforward way to see whether a given inventory device conflicts with any devices a given actor is already wearing? (Something other than attempt to equip and see if it sticks.) I am aware of a function called isAllowedItem in DCL (which I plagiarized for DDH) but I think that the knowledge really belongs in the devices themselves (or, second choice, a DDi library) rather than every mod. The equipScript obviously has to deal with the issue. Could it’s function be made generally available (or made more prominent if it already is)?

What is the preferred method for overriding the gag dialogue (for all gags)?

Thanks

*Inte* · May 2, 2019

On 4/30/2019 at 10:42 AM, Kimy said:

Sure, if you want to code it that way in your mod, go ahead and do it! As you said, there is no obvious downside. I won't change the framework, because right now there is no reason to, and it would be just be work for me. If ever needed I can still set TES5Edit loose on it. Mind you that DD4 has been out for 1.5 years now, and never there has been a need for forking that script in places where it wasn't already.

So that’s a NO then?
That’s fine, but by you using ‘zadEquipScript’ directly on devices, and assuming that all mods that use DDi took their cue from this bad practice, it will make any future DDi change/improvement to those devices result in breaking them in all the mods using them.

Another bad practice is using common/default idles that all devices use, as properties. First, modders have to manually fill them in for all the devices already made, unless they start anew and clone the ones from DDi. Second, this practice locks all devices made into using these idles permanently, seeing as any new idles would have to be manually filled in for all the devices in all the mods using them, and I am sure that no one is willing to redo their own work over and over with every DDi 'improvement'. My question is, why do it like this? It’s not like every single device will have their own custom idles. Instead, the default idles should have been coded on an extension script for each device type and a custom idles property should have been provided to be used in addition/instead of the default ones if needed/preferred.

The same thing applies to your system of conflicting device keywords. Any new device introduced to the system will force a manual update for all the conflicting devices in all the mods, otherwise the new device will not be ‘seen’ by the others. Again, having a device type oriented script extending ‘zadEquipScript’ would have solved that because you would only need to add a keyword to that, and all the devices in all the mods extending that script would be automatically updated.

On 4/30/2019 at 10:42 AM, Kimy said:

Ah right! I get it! Be careful not to confuse "occupied slots" with "used slots". The main device keyword should always be the "main device type" (e.g. the one your NIF is using), regardless of what other DD slots the item occupies. You can block any number of DD slots you want by putting on the additional keywords, but the one in the script should be the "main type", if that makes sense. E.g. If you make a belt with built-in plugs, pick zad_DeviousBelt as the device keyword and add the two plug keywords on the rendered device, in addition to the belt one. There are numerous devices in DD implemented that way.

So is this is another NO?
I see what you mean and why you suggested ‘zad_DeviousSuit’ for the mech suit. It would be the best fit because its NIF is using the body slot (32).
However, the implementation where I should block the DD slots I need by adding those specific keywords to the rendered device will not work as the equipping code only checks for the script keyword and the conflict keyword list. If you meant the latter, although it will work, like I mentioned previously, it is not feasible.
The reason?
The mech suit needs the body slot but will also need the plugs, bra, harness, cuffs, boots and the armbinder slots. This means that I would have to add the ‘zad_DeviousSuit’ keyword to all those devices and vice versa. Not doable because that will interfere with the existing devices using the ‘zad_DeviousSuit’ keyword that do not need all those slots blocked. So that is where the custom keyword comes in. Thing is, that will not work with your system at all because, although I can add all the conflicting device keywords to the mech suit conflicts list, all the existing devices (plugs, bra, harness, cuffs, boots and the armbinder) from all the mods would have to do the same.

On 4/30/2019 at 2:56 AM, Inte said:

So let me see here, if modders want to check for the DDi 4.20 version it would be better to:

1. Just grab the version and compare it to 4.20 and... that’s it. Or...
2. Go digging through 100 scripts to find out that version 4.20 is actually version 10, then grab that version and check against that. They would have to do this with every new DDi release because they wouln’t know whether the new release is 11 or 10.5 or whatever?

By ignoring the versioning issue, does it mean yet another NO?

On 4/30/2019 at 10:42 AM, Kimy said:

Yeah, but IIRC, to get that done, you'd have to clone the entire armbinder AND all its scripts, because that function was called from the effect script. That's not exactly simple!

That’s exactly how DDi 4 devices work right now. In fact the DDi 4 devices have so many unnecessary properties that the only practical way to create a new one is to clone an old one.

On 4/30/2019 at 10:42 AM, Kimy said:

Devious Helpers is pretty much what you want, then.

Since you’re giving me the runaround on the dialogue issue as well, am I to assume that this is also a NO?
DDH does a whole lot more than offer a simple dialogue that allows NPCs to free the PC from heavy bondage. Besides it does not offer the most important option, a way for other mods to temporary block its removal of heavy bondage through dialog.

On 4/30/2019 at 10:42 AM, Kimy said:

There was at least one mod that brute-forced quest devices off the player, so I felt the need to implement quest devices a bit more robust.... ?

If a mod wanted to brute force the quest devices off the player, there isn’t much you can do about it.

Instead, I just thought your efforts would be better spent in IDK, adding back the heavy bondage removing dialogue, bug fixes, stuff like that.

FYI, your new more ‘robust’ system... not so much. It seems to me that all a mod would have to do is point your new FormList of existing keywords to ‘None’, remove the devices, then point it back to where it was. Very easy, very fast.

*Lupine00* · May 2, 2019

I notice that one (and perhaps more) of the newer hoods lack the correct slots to hide hair, resulting in hair poking through them.

Transparent ebonite open faced hood, for example.

Is this a known issue, or should I check them all?

*Kimy* · May 2, 2019

9 hours ago, Inte said:

So that’s a NO then?
That’s fine, but by you using ‘zadEquipScript’ directly on devices, and assuming that all mods that use DDi took their cue from this bad practice, it will make any future DDi change/improvement to those devices result in breaking them in all the mods using them.

Yeah, I don't see a reason to put in work for something that doesn't have an obvious purpose right now. There is a good chance that the devices not using inherited scripts already, never will need them. As I said, we cover pretty much every imaginable type of restraint already. I haven't gotten any feature requests for devices in ages, either. It's not that using the main script is bad practice, it's just another practice.

9 hours ago, Inte said:

Another bad practice is using common/default idles that all devices use, as properties. First, modders have to manually fill them in for all the devices already made, unless they start anew and clone the ones from DDi. Second, this practice locks all devices made into using these idles permanently, seeing as any new idles would have to be manually filled in for all the devices in all the mods using them, and I am sure that no one is willing to redo their own work over and over with every DDi 'improvement'. My question is, why do it like this? It’s not like every single device will have their own custom idles. Instead, the default idles should have been coded on an extension script for each device type and a custom idles property should have been provided to be used in addition/instead of the default ones if needed/preferred.

I don't like hardcoded stuff. With your solution, every device using individual idles would have to use custom scripts, which is something I wanted to avoid with the new system. Neither solution is 100% ideal. I just picked the one that makes the most sense to me, and I designed the system to use properties whenever possible, as that's easier to work with for content mod creators than code.

9 hours ago, Inte said:

The same thing applies to your system of conflicting device keywords. Any new device introduced to the system will force a manual update for all the conflicting devices in all the mods, otherwise the new device will not be ‘seen’ by the others. Again, having a device type oriented script extending ‘zadEquipScript’ would have solved that because you would only need to add a keyword to that, and all the devices in all the mods extending that script would be automatically updated.

Again, I consider the likelihood of us adding new (base) device types in the future to be a good approximation to zero, so your point (while not without merit) is probably not going to be a problem, which is something I -did- consider when implementing it like this. It's just another case of me using properties whenever I could.

9 hours ago, Inte said:

I see what you mean and why you suggested ‘zad_DeviousSuit’ for the mech suit. It would be the best fit because its NIF is using the body slot (32).
However, the implementation where I should block the DD slots I need by adding those specific keywords to the rendered device will not work as the equipping code only checks for the script keyword and the conflict keyword list. If you meant the latter, although it will work, like I mentioned previously, it is not feasible.
The reason?
The mech suit needs the body slot but will also need the plugs, bra, harness, cuffs, boots and the armbinder slots. This means that I would have to add the ‘zad_DeviousSuit’ keyword to all those devices and vice versa. Not doable because that will interfere with the existing devices using the ‘zad_DeviousSuit’ keyword that do not need all those slots blocked. So that is where the custom keyword comes in. Thing is, that will not work with your system at all because, although I can add all the conflicting device keywords to the mech suit conflicts list, all the existing devices (plugs, bra, harness, cuffs, boots and the armbinder) from all the mods would have to do the same.

I haven't looked at your device or your implementation, but if your mech suit blocks all slots it needs by slapping the extra keywords on the rendered device, other DD items should leave it alone, because the equipping code -does- check for worn keywords, not just the device ones. So it would block e.g. other plugs when that suit is equipped. When -you- are equipping the suit, I'd recommend using your own suggestion and use custom scripts to check for conflicting devices before it gets equipped (make the device script overload OnEquipPre() and return the correct error code to DDI)

9 hours ago, Inte said:

By ignoring the versioning issue, does it mean yet another NO?

Well, yes. My opinion about that hasn't changed. Honestly, nobody but other modders ever need versioning checks, and all they need to do is look up the build number of the minimum required build -once- in the code. I have to admit that I sort of assume fellow coders to be able to do that.

9 hours ago, Inte said:

That’s exactly how DDi 4 devices work right now. In fact the DDi 4 devices have so many unnecessary properties that the only practical way to create a new one is to clone an old one.

That's honestly the most common use case. Most modders don't make devices from scratch, they clone framework ones and change what they want changed, which is waaaay faster than setting up all the stuff from scratch. Honestly, why would you?

9 hours ago, Inte said:

Since you’re giving me the runaround on the dialogue issue as well, am I to assume that this is also a NO?

It's not something I rule out for all eternity, but I would implement such a system only when it's vastly different from existing solutions (e.g. other helper mods). It makes no sense reinventing the wheel. If it's a new take on the feature, I will consider it. Suggestions?

9 hours ago, Inte said:

DDH does a whole lot more than offer a simple dialogue that allows NPCs to free the PC from heavy bondage. Besides it does not offer the most important option, a way for other mods to temporary block its removal of heavy bondage through dialog.

Temporarily block device removal? What would be the use case for that? The framework declares standard framework items to be fair game to remove for anybody at any time, and at the same time helper mods shouldn't touch quest devices, ever. If you want a device not to be removed by 3rd party mods (welcome to my world, btw! haha!), mark them as quest devices and you will be the only one allowed to remove them. That should solve the issue, no?

9 hours ago, Inte said:

If a mod wanted to brute force the quest devices off the player, there isn’t much you can do about it.

Instead, I just thought your efforts would be better spent in IDK, adding back the heavy bondage removing dialogue, bug fixes, stuff like that.

FYI, your new more ‘robust’ system... not so much. It seems to me that all a mod would have to do is point your new FormList of existing keywords to ‘None’, remove the devices, then point it back to where it was. Very easy, very fast.

True enough. But if a mod would brute force off somebody's quest devices, there is absolutely no way to hide these intentions in the code. A mod would have to do that very intentionally so, in an obvious fashion. Which is all I wanted to achieve. I would then...take it from there.

Grey Cloud · May 2, 2019

On ‎4‎/‎30‎/‎2019 at 5:12 AM, Nimkal said:

Can someone please help me with the issue above?

There is literally nothing that I can think of that would make DDi crash my game on loading screen. I just can't load game with this mod active. What is happening. I've checked everything. The only other explanation is if there is a mod incompatibility.

There is no hard and fast 'max' number of animations. Different folks get different results but 1500 should not cause problems (15000 would be a prime suspect). It may just be that DD4 is 'straw which broke the camel's back'. I'm new to the DD stuff so I don't know what size difference is between DD3 and DD4.

*Inte* · May 3, 2019

13 hours ago, Kimy said:

Yeah, I don't see a reason to put in work for something that doesn't have an obvious purpose right now.

Since the easiest way to make new devices is to clone the existing ones, the purpose is to stop other mods from copying your mistake, and instead do it correctly from the start.

At least put a note somewhere telling modders to extend the main script and not use it directly on devices like you did.

13 hours ago, Kimy said:

There is a good chance that the devices not using inherited scripts already, never will need them.

They need them right now, let alone later.

13 hours ago, Kimy said:

I haven't gotten any feature requests for devices in ages, either.

Well with your attitude of shutting down everything new, I wander why.

13 hours ago, Kimy said:

It's not that using the main script is bad practice, it's just another practice.

If you were using the main script only on one device type I might have agreed with that, but you are not.

You see, It’s like building a house during the summer and only finishing the roof because your only concern at the time is the rain and the Sun. Does your house 'work' like that during the summer? Yeah... sorta. But then, the winter comes and your house is now useless.

So don’t kid yourself, it’s a bad practice. There is a reason @Min did it this way to begin with.

13 hours ago, Kimy said:

I don't like hardcoded stuff.

But if every single property is the same for every device, is it not more expedient and efficient to have them all in one place, where you can modify them for all devices with a press of a button?

13 hours ago, Kimy said:

With your solution, every device using individual idles would have to use custom scripts, which is something I wanted to avoid with the new system.

That’s simply not true. With my solution every device type would use a custom script. So if there are 100 armbinders there is only one script. Also, every device using individual idles will work like yours does now. If the idles are manually entered in CK, then the device will use those, if not it will use the hardcoded ones.

Can’t you see that my solution offers the best of both worlds?

13 hours ago, Kimy said:

Neither solution is 100% ideal.

My solution is pretty much ideal. Show me one drawback with it.

13 hours ago, Kimy said:

I just picked the one that makes the most sense to me,

Ok, I cannot argue with that. But if a better solution is presented why not adopt it?

13 hours ago, Kimy said:

I designed the system to use properties whenever possible, as that's easier to work with for content mod creators than code.

I can understand that, but with my solution the mod creators will not even need to bother using properties in the first place, unless they want to. With yours they are forced to use them no matter the situation.

13 hours ago, Kimy said:

Again, I consider the likelihood of us adding new (base) device types in the future to be a good approximation to zero,

Just because you do not want to add new device types, it does not mean they do not exist.
Hint: The Mech Suit.

13 hours ago, Kimy said:

I haven't looked at your device or your implementation, but if your mech suit blocks all slots it needs by slapping the extra keywords on the rendered device, other DD items should leave it alone, because the equipping code -does- check for worn keywords, not just the device ones. So it would block e.g. other plugs when that suit is equipped. When -you- are equipping the suit, I'd recommend using your own suggestion and use custom scripts to check for conflicting devices before it gets equipped (make the device script overload OnEquipPre() and return the correct error code to DDI)

Bottom line is that I cannot implement the new mech suit correctly without you modifying that function (long term solution) or adding a new device type keyword (short term solution), say zad_DeviousMech.

13 hours ago, Kimy said:

Well, yes. My opinion about that hasn't changed. Honestly, nobody but other modders ever need versioning checks, and all they need to do is look up the build number of the minimum required build -once- in the code. I have to admit that I sort of assume fellow coders to be able to do that.

You know, I tried doing that just now. Guess what I’ve discovered. You are actually using 3 different versions numbers for DDi. Yes three!

One for the MCM, version No. 21; then there is the script version, that is No. 10, and finally there is the official version of No. 4.20, that’s just... hilarious.

13 hours ago, Kimy said:

It's not something I rule out for all eternity, but I would implement such a system only when it's vastly different from existing solutions (e.g. other helper mods). It makes no sense reinventing the wheel. If it's a new take on the feature, I will consider it. Suggestions?

Yes, bring back the armbinder (heavy bondage) dialogue just the way it was. With its option to be turned off with a simple function call, it had everything needed.

13 hours ago, Kimy said:

Temporarily block device removal? What would be the use case for that? The framework declares standard framework items to be fair game to remove for anybody at any time, and at the same time helper mods shouldn't touch quest devices, ever. If you want a device not to be removed by 3rd party mods (welcome to my world, btw! haha!), mark them as quest devices and you will be the only one allowed to remove them. That should solve the issue, no?

Temporary block device (heavy bondage) removal through dialog like it works in DDi 3.
The use?

For example when I am enslaved and the master throws me into an armbinder, it would be nice not to be able to ask his cohorts to remove it, which would allow me to go ahead and kill them all, which for obvious reasons ruins the experience.

This has nothing to do with other mods. They can and should be able to remove it at will.

I rather not use your quest devices, they’re... not worth the aggravation to both the player and to me as a modder. If the players want to remove a device that bothers them, who am I to tell them how to play their own game?

13 hours ago, Kimy said:

I would then...take it from there.

Now I am curious, what would happen then?

*Lupine00* · May 3, 2019

18 hours ago, Kimy said:

It's not something I rule out for all eternity, but I would implement such a system only when it's vastly different from existing solutions (e.g. other helper mods). It makes no sense reinventing the wheel. If it's a new take on the feature, I will consider it. Suggestions?

I don't think DD framework should contain any dialogs.

It doesn't provide a way to get keys either.

It seems fine that actual content be delegated to other mods.

How you get put in devices, and how they get removed isn't something the framework should concern itself with - except perhaps for MCM features to remove devices from the PC, or NPCs.

That repair task seems like it should be in the DD MCM, and you should be able to remove devices by slot, even on NPCs, not just purge everything and stop all quests.

Often I have some broken device and I have to wreck all my running quests to remove it.

That's not a fix.

The best outcome of removing the device is to allow the quests to continue as if things didn't break, not to kill them completely.

18 hours ago, Kimy said:

But if a mod would brute force off somebody's quest devices, there is absolutely no way to hide these intentions in the code. A mod would have to do that very intentionally so, in an obvious fashion.

And why not? For example, the mod might be able to pause other quests so it can run its own, and then restore them properly afterwards.

To my mind, this should be a best practice for all DD quests, and there should have been a design pattern to implement it from the very start.

e.g.

New quest raises a "start exclusive locking DD quest" event - executing quests that want to, pause themselves politely.

No quest raises a "please don't interrupt me" event, so...

New quest copies the DD item form info off the player's slots and removes the devices.

New quest adds its own devices.

Quest plays out.

Quest replaces old items.

Completed quest raises a "end exclusive DD quest event" - suspended quest(s) resume.

Never going to happen now. But, hey, hindsight!

Whether there exist any DD quests that expose enough state to be interrupted and restarted, I'm not sure. Possibly.

DF can suspend itself though.

The problem was never that DD quests interfere with each other (unavoidable), the problem is that quests assumed they would not be interfered with and shouldn't have to worry about interfering with other mods. The better course it to design for co-existence ... a bit like DF does.

Once you have a mod like the Queen Sarah scenario, there's really no way to introduce a pause mechanism that makes any kind of sense. While it can be fun for the player, it has designed in exclusivity and to break it would be immersion shattering. OTOH, a mod like RDC could be interrupted and resumed with a dozen excuses.

DCL is full of quests that assume they are the only game in town. Fortunately, you can turn them off if you know they're going to cause trouble. It's not alone. SD+, Pet Project, CD, SS, and Devious Regs make similar assumptions. Slaverun OTOH, is very forgiving. There are probably more cases where DCL assumes it has free reign to modify the player than all the other mods put together, so I think the changes to DD mainly served to protect other mods from DCL, rather than the reverse.

*Kimy* · May 3, 2019

@Lupine00: Pausing DD quests would be silly in more situations than not. Just imagine - one quest puts some stuff on the player to make her escape it, then another one requests a pause, puts its own stuff on to make the player do something completely else, only to put back the first set of items at the end. That makes... no sense. Likewise, it -usually- makes no sense to expect DD quests to "co-exist" (= running at the same time). Bondage content is about losing control and somebody else taking it (the person with the key). While there are exceptions (DF is really one of them, because it exerts control over you in a very subtle way that still leaves room for something else to dominate the player), it usually makes no sense to lose control to more than one context at the same time. If DD quests assume they are the only one running at any time, its in 99% of all cases because that's indeed what makes the most sense.

Therefore, the framework operates under a "First come, first serve" paradigm. The first feature of any mod to claim a DD slot owns it until it voluntarily(!!!) releases it. Content mods are expected to check for occupied slots and not start their content until the required slots are either free or there are just generic devices in them, which are considered fair game to remove.

DCL is no different - there is not a single case where it removes somebody's quest devices. It might be the most feature-rich DD mod on LL and impact your gameplay more than any other, but this doesn't mean it assumes to be alone in the world. Queen Sarah is designed NOT to start unless all required slots are open. Yes, when it RUNS, it expects to be left alone by other content. No other DCL quest will start while its active. And yes, it assumes that other mods don't try to force-quit it, either, because that's the way the framework is designed. First come, first serve.

@Inte: Look, I get that you would have implemented the framework differently, had you made it and not me. That's fine. I would have coded your mods differently, had I written them, too. That doesn't mean that my implementation is "bad practice" or doesn't work. It quite obviously does, as is evident by like two and a half dozen DD content mods using it without any major issues. Actually, there are MORE new DD mods releasing in the DD4 era than before, so I must have done -something- right, no?

Nobody keeps you from implementing devices the way you want on your end. If you want to use custom code for each and every device you make, I won't stop you, nor could I. The framework allows for both ways to implement devices. But I don't feel the need for making changes to the framework that have a 99% chance of never being required and/or are just another way to do the same thing. All device types that need non-standard behaviour already HAVE custom scripts.

Your mech suit isn't even a new device type, it's a variant of an existing one (suits...). There are items like that in framework too, and I showed you a solution how to implement that item on your end using existing framework features. Which happens to be the same solution I am using for framework items (look at the straitjacket and how its VERY similar to the mech suit you have described to me!). The mech suit features, including its keywords, do NOT have to be implemented at the framework level. All the framework needs to know is what slots you are using/occupying, which you can tell it by slapping the needed keywords on the rendered item. They rest of its mechanics (including when it can be equipped), the framework doesn't need to know about. You can define that in YOUR code.

The dialogue - honestly, you refusing to use existing framework features (quest items / block_generic items) doesn't constitute a use case for me implementing a feature that's already provided by several content mods. There is zero need for a "removal pause" feature, because the existing system (quest item and block_generic keywords) gives you full control over your items already and when they can be removed.

In short - I offered you my help to update your mods to DD4 if that's what you want to do. Which is the reason why we're even talking right now. What I STILL have no interest in, is endless back-and-forth arguments with you, because you can't take no for an answer and would rather die on any hill than compromise on even the least important thing. Been there, done that, got the T-shirt. I take suggestions from you as much as anyone else, but when I weigh the pros and cons and shoot them down, I expect the discussion to end there, even if you don't agree with my conclusion.

***Psalam*** · May 3, 2019

Quote

10 minutes ago, Kimy said:

@Lupine00: Pausing DD quests would be silly in more situations than not. Just imagine - one quest puts some stuff on the player to make her escape it, then another one requests a pause, puts its own stuff on to make the player do something completely else, only to put back the first set of items at the end. That makes... no sense. Likewise, it -usually- makes no sense to expect DD quests to "co-exist" (= running at the same time). Bondage content is about losing control and somebody else taking it (the person with the key). While there are exceptions (DF is really one of them, because it exerts control over you in a very subtle way that still leaves room for something else to dominate the player), it usually makes no sense to lose control to more than one context at the same time. If DD quests assume they are the only one running at any time, its in 99% of all cases because that's indeed what makes the most sense.

Therefore, the framework operates under a "First come, first serve" paradigm. The first feature of any mod to claim a DD slot owns it until it voluntarily(!!!) releases it. Content mods are expected to check for occupied slots and not start their content until the required slots are either free or there are just generic devices in them, which are considered fair game to remove.

DCL is no different - there is not a single case where it removes somebody's quest devices. It might be the most feature-rich DD mod on LL and impact your gameplay more than any other, but this doesn't mean it assumes to be alone in the world. Queen Sarah is designed NOT to start unless all required slots are open. Yes, when it RUNS, it expects to be left alone by other content. No other DCL quest will start while its active. And yes, it assumes that other mods don't try to force-quit it, either, because that's the way the framework is designed. First come, first serve.

@Inte: Look, I get that you would have implemented the framework differently, had you made it and not me. That's fine. I would have coded your mods differently, had I written them, too. That doesn't mean that my implementation is "bad practice" or doesn't work. It quite obviously does, as is evident by like two and a half dozen DD content mods using it without any major issues. Actually, there are MORE new DD mods releasing in the DD4 era than before, so I must have done -something- right, no?

Nobody keeps you from implementing devices the way you want on your end. If you want to use custom code for each and every device you make, I won't stop you, nor could I. The framework allows for both ways to implement devices. But I don't feel the need for making changes to the framework that have a 99% chance of never being required and/or are just another way to do the same thing. All device types that need non-standard behaviour already HAVE custom scripts.

Your mech suit isn't even a new device type, it's a variant of an existing one (suits...). There are items like that in framework too, and I showed you a solution how to implement that item on your end using existing framework features. Which happens to be the same solution I am using for framework items (look at the straitjacket and how its VERY similar to the mech suit you have described to me!). The mech suit features, including its keywords, do NOT have to be implemented at the framework level. All the framework needs to know is what slots you are using/occupying, which you can tell it by slapping the needed keywords on the rendered item. They rest of its mechanics (including when it can be equipped), the framework doesn't need to know about. You can define that in YOUR code.

The dialogue - honestly, you refusing to use existing framework features (quest items / block_generic items) doesn't constitute a use case for me implementing a feature that's already provided by several content mods. There is zero need for a "removal pause" feature, because the existing system (quest item and block_generic keywords) gives you full control over your items already and when they can be removed.

In short - I offered you my help to update your mods to DD4 if that's what you want to do. Which is the reason why we're even talking right now. What I STILL have no interest in, is endless back-and-forth arguments with you, because you can't take no for an answer and would rather die on any hill than compromise on even the least important thing. Been there, done that, got the T-shirt. I take suggestions from you as much as anyone else, but when I weigh the pros and cons and shoot them down, I expect the discussion to end there, even if you don't agree with my conclusion.

I don't usually comment on material that I have also liked but I must make an exception for what you wrote at the beginning of your post. It is a brilliant explanation and one that more modders in general need to hear and heed. Most of the problems I see on the Technical Threads come from just this source. People who keep adding mods to their load order that are trying to do things at the same time that make no sense. So, not that you need any encouragement from me, props to you.

Sign In

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

Recommended Posts

Guest

Create an account or sign in to comment

Create an account

Sign in

Recently Browsing 0 members