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

[Kimy]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

@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]

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.

[Srende]

I'll have to add some comments, just poking in randomly after reading the few last comments. Sorry

 

The current system with loads of customizable properties seems to be working well and as intended. Adding new items doesn't really require a custom script anymore, as you can block removal if needed (which has been 99% of my use cases) through the properties. Would've made things a bit simple back when first starting with DR.

 

Similarly, it's great that all the items now share the common base script and behave similarly, it just makes more sense than having loads of special cases.

 

13 hours ago, Inte said:

 

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?

Then I have to ask, why even have the mod installed in the first place? All the quest devices I've seen are pretty integral to the mod/quest they're in, and removing it could be achieved just by uninstalling the mod.

 

In general, it doesn't really make sense to have some kind of pause option in quests if the whole point of the quest is to lock you in. Not to mention how much checks you would need in code & dialogue to support a case like that properly.

[Lupine00]

8 hours ago, Kimy said:

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.

I disagree. The framework really says almost nothing about this. The behaviour of quests is primarily a choice of the quest implementor.

 

I believe I already addressed what you call "silly"...

• There are quests that are intrinsically exclusive, both in story and mechanics, and there are quests that are not, but simply happen to act that way because it was easy to act like that.
• I proposed that quests that don't want to be interrupted due to it being "silly" could raise a "do not interrupt event" to veto interruption, and as long as they fired that event within a certain time frame of the "request to interrupt" event, the interrupter wouldn't proceed.

 

Such a simplistic "time window" system might be vulnerable to extreme script lag.

If we wanted to be fancier, we could fix that by requiring DD quests that partake of the pausing mechanism to register with the framework, so any given mod could then establish if all registered running quests had responded, rather than that being uncertain.

 

Instead of any system of event based negotiation, with proposals, implicit acceptance, or explicit veto, we have the brutal world that is supposed to be first-come-first-served, but often ends up as "now both quests are still broken", even if the devices themselves aren't the cause of the breakage.

 

 

For example, what happens now when you put on the RDC when you're wearing a parasite from parasites? I had this back on Monday. It didn't break my game, but it wasn't ideal either.

 

I also did the Chloe quest, while wearing the parasite. Much of the Chloe quest device addition failed, but the quest barrelled on regardless, and I was able to finish it - and the parasite didn't get broken - but it was as you put it ... silly.

 

 

Now I think about this, we could manage something even simpler... A booking system for slots.

• When a quest starts, it registers an entry, tagged with a unique ID that it tracks, that has a list of all the slots it will ever want access to, so that it can complete correctly. (Slots it could optionally use shouldn't be booked). The ID might be the quest's own FormID, but doesn't  have to be.
• When a quest intends to start, it first asks the framework for the union of all these slot bookings, and can check up-front, whether it will be able to run to completion under the current slot-booking environment. If it can't, it aborts; does not start. Otherwise, it registers its own slot bookings and starts.

 

This would allow multiple quests to run at once, as long as they won't interfere with each other.

Such a (basic) system would (for example) prevent you from starting the Chloe quest while wearing a parasite, and prevent the parasite quest from starting if you are doing the Chloe quest... assuming they used the slot booking system.

 

In fact, if quest authors wanted to be "good citizens" we could write - very quickly - a tiny standalone mod to handle the bookings, and mods could use it voluntarily, without even impacting the DD framework, which doesn't really need to know that such registrations and checks are taking place, as they have no impact on the simple business of adding and removing devices. Even Zaz based mods could use it.

 

Perhaps, if we are ever to have such a system, it shouldn't be part of DD, and could be extended to be more generally capable of handling quest contention.

 

Realistically, no old mod would support it, and many new mods wouldn't either. It still wouldn't make anything worse, but could make things better.

 

The worst that can happen is a quest doesn't use slot bookings, and starts when it shouldn't.

We already have that problem, so no change there.

[DonQuiWho]

@Kimy

 

A quick query re the 'New "Unconscious " idles', if I may?

 

I'm trying to work out what is the cause of my PC regularly collapsing to the ground in either a seated state, or a lying down curled up position

 

When this happens in the middle of a Sexlab scene, it breaks the paired animation, and one of the actors keeps doing his or her thing, but the PC just sits there

 

Sometimes it happens when the PC is mounted, and they then make it onto the horse, sometimes immediately standing straight up, and sometimes, in a crouched position.  I have so far found it impossible to remove them from the horse, even with my normally trusty solution which is to activate Field Alchemy, and break whatever animation is screwing up the PC.  That it's this 'lie down' animation is easy to check if I save the game and run it twice from the same point, as on horseback the game does the weird stuff, and if the PC goes on foot, she just sits down. 

 

Getting up from the ground requires a spacebar input to jump up

 

I can't think what else in my load order might be doing this, so the query is

 

 - does what I am describing fit any of the animation outcomes from DDi events?

 

 - if it does, any idea why it overrides normal SexLab activities

 

I'll try and get a screendump of what I see for you, in case it helps

 

TIA if you have any ideas at all - or anyone else has, for that matter ?

 

EDIT Pic now attached

[Kimy]

2 hours ago, Lupine00 said:

Realistically, no old mod would support it, and many new mods wouldn't either. It still wouldn't make anything worse, but could make things better.

Realistically...that's why the entirety of what you wrote in your post won't work. It's less likely to work than world peace, actually. Frameworks cannot assume that everyone is playing nice. They...don't.

[Lupine00]

4 hours ago, Kimy said:

Realistically...that's why the entirety of what you wrote in your post won't work. It's less likely to work than world peace, actually. Frameworks cannot assume that everyone is playing nice. They...don't.

And if there is no feature. Nobody can use it.

 

I happen to believe that most modders do not do "bad things" that hurt other mods on purpose.

While there are one or two modders who are weirdly proprietary, and throw a fit if you even suggest they make their mod more interoperable, or who are very particular about how interoperation should occur (events ONLY, for example, and not StorageUtil), they are probably a minority.

If they have to do a ton of work for no benefit, they probably won't do it, but if they make a new mod, or a new version, they might. They might just do it because they think it helps their mod.

 

Let's not just assume that we can never improve anything.

 

I'll ask a different question...

 

If I made a slot booking mod, would you use it? Because that's what this is about, really.

You've as much as said you would never make such a mod, or add such a feature to DD, but that doesn't stop anyone else from doing it.

 

A booking process has no dependency on DD, and could be used to book access to other lockable resources, whatever those might be.

Possibly follower slots, though the player can usually sack followers on demand, in the case of DF, that may not be an option.

[Inte]

@Kimy, 
So you've 'shoot down' every single one of my suggestions. 

I thought that we were having a serious discussion about the future and improvement of DDi. I had no idea you were just going through the motions to make it appear as if you cared about using DDi for anything but your personal agenda. 

[Inte]

12 hours ago, Srende said:

The current system with loads of customizable properties seems to be working well and as intended. Adding new items doesn't really require a custom script anymore, as you can block removal if needed (which has been 99% of my use cases) through the properties. Would've made things a bit simple back when first starting with DR.

My improvement solution is not intended for mods with a small number of devices. If your mod only has a couple of device types in it, then my solution does not really make that much of a difference for you.

 

My solution is intended for mods with a large number of devices, mods like DDe, CD, DCL and the like.      
Imagine if you will, that someone decides to make this really cool new set of idles that all mods just need to have. For you, it would be fairly easy to just fire up CK and input them directly into your couple of devices that would use them. The same cannot be said about the mods I’ve mentioned. Can you imagine entering say 10 new idles for each of your existing 500 items? With Kimy’s current implementation it would take you what? A month? Would you even want to do it then? With my solution it would literally take you about 5min. to change all 500 items. However, if instead you prefer to spend a month entering new idles into your devices, my solution will allow you to do that as well. 

Kimy’s answer to this is that no one will ever make any new content for DDi, or that DDi already has everything there is to have. Like I said before, with that attitude, I wander why? 

Take for example SLAL. Before its implementation there were like what, a couple of animation packs floating around for the players to use? How many are there now? What if @orxx had Kimy’s mentality and instead of making SLAL said, ‘ah, no one will ever make any more animations for SL... why the two animation packs that exist now are more than enough...’?
What is it they say, “Build it and they will come”?
 

[Kimy]

9 hours ago, Inte said:

@Kimy, 
So you've 'shoot down' every single one of my suggestions. 

I thought that we were having a serious discussion about the future and improvement of DDi. I had no idea you were just going through the motions to make it appear as if you cared about using DDi for anything but your personal agenda. 

Yes, we did, and I don't mind you starting it. But here is the thing. Your suggestion is about putting in a lot of work into a change that's basically guaranteed never to be needed. It assumes that somewhere in the future I might want add mechanics to a basic device type that's now using the base script (zad_EquipScript) and which wouldn't apply to another basic device type using the same script. That's...super unlikely to ever happen, and I don't understand why you're pressing me so hard on that. I know it's frustrating to have suggestions shot down time after time, but you tend to pick fights about stuff that doesn't matter, or stuff what would amount to the same thing implemented in a different way. Remember the version numbers?

 

If you make a lot of devices you can set yours up in this fashion if you want to. Nobody keeps you. But I don't get why you're so insistent on me making changes to the framework when they don't even concern your mod. I am not sure if this is a misunderstanding about how the framework operates, but I am shooting down your suggestion because I fail to see a good reason to implement it, and that's really all. Yes, I get your objection that the way I implemented Idles means a bit of work in case someone decides to make new ones you want to use, as they wouldn't propagate from the framework to content mods. I said that your point isn't without merit. But in all these years of developing DD, NOBODY outside of the DD team has contributed an idle, and more idles are not on our roadmap. So guess how likely it is that the potential problem you pointed out will become an ACTUAL issue! In return, my implementation gives modders full control over the existing idles WITHOUT touching code. You can make your device use a specific one if you want to, just by editing properties. That's an advantage your solution does NOT have.

 

I have a tendency of shooting down suggestions if they mean a lot of work with little or questionable return, or when they are based on mere assumptions that something will happen or change in the future that would warrant them. Most of yours fall into that category. I do future proof my code, but not when there is like a 0.1% chance that this scenario will actually happen. That makes about as much sense as bringing an umbrella to a Sahara trip.

 

PS: SLAL wasn't built on green grass in the hope that something would flourish around it. When it was made, there were more and more SL animations popping up at a quite fast rate. For the longest time they got manually added to NSAP, and SLAL got made only when that method stopped being sustainable. If one day I get so swamped in idles that I feel cannot add them manually to properties anymore, you can safely assume I will look for a solution and provide one.

[Zaflis]

Would it be possible to give all worn DD items some kind of description (EDITOR ID or something)? Anything to help identify it from glance. It's really hard to debug device problems. Basically my problem is nearly always the blindfolds and hoods. They leave remainders on player, so when trap puts one on next time it gets completely broken:

- It's not worn and when attempted to be worn it just quickly unequips itself.

- Blindfolded effect is active, making everything dark.

- I don't actually have any blindfold to unlock or struggle from.

- This is a very common and frustrating thing that has happened in multiple saves started from scratch.

- I have gone as far as trying to set SL strip settings in MCM to ignore head slot, and i think that part works, but doesn't fix the bugs.

 

 

Edit: In this case i think i solved it by removing 0A01334F. And seems that is "zadx_WTLblindfoldBlocking_scriptInstance".

 

Edit2: I did manage to make a private patch for all DDA, DDX and DCL blindfolds that adds script/render item instances a name field. I see them in console properly now, but it has a side-effect that when you search for restraints with help command, it will list them too. I think they might need a different name, just make all of them use same "__blindfold_script__" or something, to distinguish from real items. It doesn't matter what they really are, as long as player knows what to remove.

Spoiler

This will save me so much time...

 

Oh... now it appears in inventory too! That's not great.

[Zaflis]

So now that i feel more confident being able to fix it, i enabled most blindfold options. I don't mind seeing it in the inventory anymore, but this happened after Cursed Loot's dialog with innkeeper. I was already wearing blindfold before the dialog, but then she asked "oh you like lockable things, let me add some more". The blindfold effect was removed from me, i think the mod tried to just strip headgear from me? But after that the script was duplicated and blindfold was not actually equipped. In screenshot here it is equipped for a test, but as soon as i close inventory and reopen it, it won't be equipped anymore. I don't have other blindfolds/hoods on me, and it was definitely in a working state before the npc. Basically the script and the item are no longer attached, or something like that. I do not believe this is script lag issue, it happens too often to be coincidence.

 

Spoiler

 

Also the patch if you are interested in trying. It's completely safe to add or remove from existing save. DD_with_names.7z

Requires DD 4.2 and DCL 8.2. Make sure to put it after Cursed Loot in load order!

 

edit: I'm talking half-nonsense again -.- Script was not duplicated, it appears normal that the item has 3 instances in the inventory. So items remain same but they do stop functioning some way. In earlier save all 3 of them are equipped. But if i load the later save again and try "equipitem" with the other script it won't get equipped. Interacting with mouse in inventory does nothing with scripts at any point, that's as it should be.

[Lupine00]

11 hours ago, Kimy said:

NOBODY outside of the DD team has contributed an idle, and more idles are not on our roadmap.

They can't really, can they?

This is a straw man big enough to base a music festival around.

 

Gunslicer has made a huge amount of stuff that has some relevance to sex idles, but he's not making DD compatible animations.

Not only does it require a lot more work, but how would he ever get those animations into DD?

 

He can't, and with a DD team that has no animations on its roadmap - and with a system already based around on a very large set of non-optional-to-install fixed animations - DD would hardly want to add them anyway.

 

Unless DD moves to a mechanism where players can choose to load only the animations they want/need, which automatically disables the dependent "flavour" action in DD itself, nobody is going to propose adding animations to DD, when the complaint that's often being levelled is that it requires too many animations already. e.g. DD would need to be engineered to allow pluggable actions AND animations. I can see the argument against this is that nobody is queuing up to make such things. Well... it's not actually a bad argument.

 

I've tried to counter that over-exaggeration of DD's animation demands, but it's still something a lot of people believe, and there is a certain basis for it, in that there aren't many modding entities that require as many animations overall, and probably none that require as many overrides. Zaz probably has more animations (though I haven't checked) but needs fewer overrides. The squabble over that limited resource is where the whole Zaz/DD conflict pivots right now.

 

Zaz is deeply flawed in its monolithic delivery of content. It's not a model that should be emulated.

 

 

One question is, what kinds of animations do non-DD-team modders want to add to DD, if any?

I think we're talking about the mech suit again ... and the difficulty of adding new classes of device.

Just because DD team thinks they've done everything, doesn't mean they have.

Spoiler

I can imagine that CoC fans are still dreaming of bee-suits, spider-suits, tauran-outfits, and other stuff built on top of DD.

That dream has never died, despite any mod that promised them disappearing down a hole.

 

Those mods don't need DD, and they shouldn't use it, but that's just an example of "kinks Kimy doesn't care about".

 

Just because Kimy hasn't thought of it and added it doesn't mean it isn't a "thing".

 

An ideal framework wouldn't be wedded to one person's idea of what DD is, it would be open to addition to expansion.

DD has a lot of options for expansion, and also a lot of places where its tightly bound (the irony) to a certain kind of bondage content.

 

Now that Kimy has the features she wants, I think it's plain that if you want features that aren't in there, you need to look to your own resources. She's not going to do your work for you, on the off-chance you might actually make something from it. It's a little selfish, but also pragmatic. There's only so much selflessness you can reasonably expect from her - as Kimy likes to remind us  I joke, but it's true.

 

A lot is asked of Kimy, perhaps too much. But perhaps, also, it is the manner in which she refuses, rather than the refusal itself, that leads to protracted arguments.

 

It's inevitable though, if you put yourself at the centre of such a system, that you are going to be under constant pressure. Personally, I wouldn't choose to create such a centre, or such a system, and certainly wouldn't want to bear that pressure. I think there's a saying for this. "With great power comes great responsibility." If you don't want that responsibility, don't take on that power.

 

Another question is, would players be happier if they were able to only install the DD animations they want to see and not install the ones they don't want to see?

Spoiler

Maybe a player thinks that stopping every five minutes, locking the player controls, and watching a self-fondle animation gets old real fast, if you're playing a perma-chastity mod. Cool. they can diable that in the DD MCM. But they can't reclaim its animations. On the other hand, those animations are just regular old idles, and aren't using a resource that is that scarce, so maybe reclaiming them is not a huge priority.

 

 

Is there an actual scenario where I could not use (and potentially not load) override animations? I'm not so sure. Not without ruling out entire classes of device.

[Kimy]

34 minutes ago, Lupine00 said:

Not only does it require a lot more work, but how would he ever get those animations into DD?

By talking to me. Stunning thought, I know!

 

I literally stopped reading your post there.