Devious Devices Framework Development/Beta

[DeepBlueFrog]

6 hours ago, Veladarius said:

That function references a form list and it likely was not added to it.

I added a trace on StorageUtil.FormListCount(libs.zad_DeviousYoke, "zad.GenericDevice") for that keyword and it returned 0.

 

I am getting other generic devices such as collars, so they were registered successfully at some point, but something funky is happening with Yokes apparently.

 

Edit: I tried adding a corset and boots and got an instant CTD in each case.

I will try a more exhaustive test. 

[Nazzzgul666]

On 26.12.2017 at 8:40 PM, Nymra said:

The Devious Cidhna Quest in the Pirate Ship for example requires gag talk to make the pirates finally remove your gag. 

Without it, the gag skill never is raised and the dialogue with the pirates never changes. 

So you can never get the quest to proceed to the next stage at all.

 

I downgraded back to last DD version for use with Captured Dreams, Devious Cidhna and some other mods.

With Shout like a virgin it worked fine. Slaverun I didnt test yet. 

 

Slaverun seems to be fine with gags, i only got one once at a point where it wasn't really necessary to talk i think... not 100% sure, i did it wrog and cheated a key in my inventory.

But yokes, armbinders etc get neither equipped nor unequipped, i assume because of a lack of keywords skyrimLL described? Would it be possible to give them both keywords old and new for the sake of backwards compatibility, so old mods can use old keywords and new mods the new ones?

[Veladarius]

7 minutes ago, Nazzzgul666 said:

Slaverun seems to be fine with gags, i only got one once at a point where it wasn't really necessary to talk i think... not 100% sure, i did it wrog and cheated a key in my inventory.

But yokes, armbinders etc get neither equipped nor unequipped, i assume because of a lack of keywords skyrimLL described? Would it be possible to give them both keywords old and new for the sake of backwards compatibility, so old mods can use old keywords and new mods the new ones?

It isn't as simple as that. Those devices already have both keywords but there is a controlling keyword that DDi uses specifically when equipping and unequipping them and that keyword is set in the properties in the script on the device itself and is what is used in all of the DDi functions. They had added heavybondage as a keyword when the yokes were made but used them as a reference keyword only so things could check easily if the person had their arms bound but the primary keyword was not changed.

 

V4 changed this and all of the devices still have both keywords but the primary keyword used in DDi functions was changed to HeavyBondage while keywords like armbinder , yoke and whatever new ones were made for the new devices to describe what device specifically is on them. So, v3 mods are looking for the old keywords and DD v4 is looking for the new ones.

 

Overall, this makes sense to reduce the scripting modders need to do to remove armbinders, yokes, straightjackets and any other item that comes under HeavyBondage and all of these can be removed using the exact same command where v3 required the use of a different keyword for each of the heavyBondage tupe items so the function the modder used had to be different for each (or supply a different keyword for each). It cuts down on what modders have to check for when manipulating devices.

[Nazzzgul666]

1 hour ago, Veladarius said:

Overall, this makes sense to reduce the scripting modders need to do to remove armbinders, yokes, straightjackets and any other item that comes under HeavyBondage and all of these can be removed using the exact same command where v3 required the use of a different keyword for each of the heavyBondage tupe items so the function the modder used had to be different for each (or supply a different keyword for each). It cuts down on what modders have to check for when manipulating devices.

Oh, i see. Thanks for explanation.

[Lupine00]

Doesn't GetGenericDeviceByKeyword have a somewhat misleading name?

 

If what it does, is look up an arbitrary device that has the keyword, in a global formlist cache, there are several ways it is misnamed:

It fails to mention the formlist.

It fails to mention that the list is essentially global and not specific to an actor.

It fails to mention what it does if more than one device matches the keyword, or if the implementation has even considered this issue.

It fails to mention what might get a device into that formlist, or what sort of lifespan or lifecycle the formlist has.

 

Well, it's a library call, not an actor call, so some of these might be "clear enough", but it's still not the most explicitly accurate name.

 

Wasn't DD4 a chance to fix stuff like this? It's blindingly obvious from what's being said about item removal that DD4 isn't really going to be backwards compatible, except in cases where it was explicitly tested to work with a particular behaviour of a particular mod.

[Veladarius]

1 hour ago, Lupine00 said:

Doesn't GetGenericDeviceByKeyword have a somewhat misleading name?

 

If what it does, is look up an arbitrary device that has the keyword, in a global formlist cache, there are several ways it is misnamed:

It fails to mention the formlist. Why mention the form list? the explanation clearly says it selects items registered as generic either by DD or by a mod. How it is stored has no relevance to the use of the function

It fails to mention that the list is essentially global and not specific to an actor. Since the function has no reference to an actor why would you think it would?

It fails to mention what it does if more than one device matches the keyword, or if the implementation has even considered this issue. Since it is listed as one of the functions on the wiki to get a RANDOM device I think that is rather self explanitory

It fails to mention what might get a device into that formlist, or what sort of lifespan or lifecycle the formlist has. Right above the command on the wiki is the function "RegisterGenericDevice" and the formlist does not go away unless you uninstall DD

 

Well, it's a library call, not an actor call, so some of these might be "clear enough", but it's still not the most explicitly accurate name. It does exactly what it says, it gets a generic device based on the keyword and since it is listed as one of the RANDOM ways to get a device on the wiki

 

Wasn't DD4 a chance to fix stuff like this? It's blindingly obvious from what's being said about item removal that DD4 isn't really going to be backwards compatible, except in cases where it was explicitly tested to work with a particular behaviour of a particular mod. The only thing that is not backwards compatible on manipulating devices is with the armbinders and yokes due to the primary keyword change. As I said in my post a few up from this it unifies all of the devices that are considered 'heavy bondage' which is items that impair the use of the arms/hands and is better than having a bunch of different keywords to have to use in removal. All other devices will still work as usual.

 

So, in a nutshell, no it isn't misleading as it does exactly what it says.

 

 

[DeepBlueFrog]

So if I understand correctly, the current way to get a Yoke with the generic function is to use the HeavyBondage keyword and the Yoke tag?

[DeepBlueFrog]

Also, I just noticed - with great horror - that the zadEquip script now has a lot more properties.

 

Does that mean I have to go and edit all my custom devices and provide a default value for these properties? or will they inherit values from the default script?

[Lupine00]

"Must look up behaviour in the wiki" is pretty much the opposite of self explanatory, it's a prime example of having to look elsewhere for an explanation.

 

The idea of self documenting method/function names is intended to resolve the common issues of misconception of purpose, and code that becomes out of synch with its actual functionality, as has arguably occurred in this case. If you have to look up what it does, and let's be honest, a new developer would have to look this one up, they cannot magically "just know".

 

If they were reading somebody else's source they could easily get quite the wrong idea of what it might do. They certainly would not get even one single clue that there was a formlist, and a registration requirement, hidden away under the hood. Perhaps the formlist itself is an implementation detail, but the registration requirement is not.

 

I short, it's not a self documenting name. In this case, it's not even close. Allusion to the wiki only serve to prove this.

 

For example, LookupRandomRegisteredDeviceByKeyword tells us something very different to GetGenericDeviceByKeyword.

 

I guess you guys have your process, but it has been demonstrated in projects over and over that having two sources of truth (code AND documentation) is practically equivalent to no source of truth.

 

Which is the source of truth in DD4 ? The wiki, or the code?

 

I'll shut up now.

[El_Duderino]

1 hour ago, skyrimll said:

Also, I just noticed - with great horror - that the zadEquip script now has a lot more properties.

 

Does that mean I have to go and edit all my custom devices and provide a default value for these properties? or will they inherit values from the default script?

I assume you mean the new properties for the escape and struggle system (like for example DestroyKey, EscapeCooldown, LockShieldTimerMin, etc.)? If so, then yes, these fall back to default values from the zadEquipScript if they are not specified on a device's armor. You only need to fill in the properties on your own devices if you want to create that device that needs 87 keys to unlock and that has a 5,000 hours long lock shield. Or stuff like that.

 

1 hour ago, Lupine00 said:

"Must look up behaviour in the wiki"

What's wrong with this? The Wiki is very useful for modders beginning to explore DD customization. Besides, putting all this information into the script comments would make them really long and hard to find stuff in (plan text format is just so, well, plain). And trust me, novices like me would *still* require additional documentation (i.e., help!) no matter what the functions and whatnot are called. There is no such thing as "self explanatory" in a complicated environment such as DD when it comes to modding novices. Names are one thing, being told in understandable terms what stuff does and how it works is the other (and crucial) thing. The current documentation does a good job with that in my opinion.

[Princessity]

17 hours ago, skyrimll said:

Should I open an issue about it on github?

I'd prefer if you posted issues here. If you ever posted anything on Github and wondered why nobody acknowledged it, it's because I... tend not to check them very often. I use the desktop app for all my Github stuff so I don't get any notifications. But I am following this thread so I read everything that's posted here.

[Veladarius]

2 hours ago, Lupine00 said:

"Must look up behaviour in the wiki" is pretty much the opposite of self explanatory, it's a prime example of having to look elsewhere for an explanation.

 

The idea of self documenting method/function names is intended to resolve the common issues of misconception of purpose, and code that becomes out of synch with its actual functionality, as has arguably occurred in this case. If you have to look up what it does, and let's be honest, a new developer would have to look this one up, they cannot magically "just know".

 

If they were reading somebody else's source they could easily get quite the wrong idea of what it might do. They certainly would not get even one single clue that there was a formlist, and a registration requirement, hidden away under the hood. Perhaps the formlist itself is an implementation detail, but the registration requirement is not.

 

I short, it's not a self documenting name. In this case, it's not even close. Allusion to the wiki only serve to prove this.

 

For example, LookupRandomRegisteredDeviceByKeyword tells us something very different to GetGenericDeviceByKeyword.

 

I guess you guys have your process, but it has been demonstrated in projects over and over that having two sources of truth (code AND documentation) is practically equivalent to no source of truth.

 

Which is the source of truth in DD4 ? The wiki, or the code?

 

I'll shut up now.

 

If you can't be bothered to look up the info on the wiki then I would guess you got it from the zadlibs script.

 

This is the description in the zadlibs script for the function:

Quote

; Retrieves a random inventory device with the given keyword, returns none if no devices are available

This is from the wiki:

Quote

Returns a random device with the given keyword. The returned device can be from any mod that has registered its devices and the device is safe to manipulate with the generic functions.

There is little difference between the two descriptions and neither mentions anything involving an actor.

 

If you are just going to look at a function name and guess as to what it does you are better off not using DD.

[Dreckiger Dan]

@Kimy @Min @Inte

 

sry for this nerving question but, its planed to make an SSE Build of Devious Devices, Prison Overhaul and co ?.

 

i hearing only that the SSE better run as the SLE but i missing this mods

 

i dont know what i want to play, the SLE with your mods and my stupid modlist dat crash my game any time (i think 200 Plugins are to many for my System :-( )

or the SSE Build with low numbers of mods.

 

and good Work on this mods i love this, its in some parts strange but good

 

 

mfg Pain

[DeepBlueFrog]

Another question: 

 

I can still access my inventory when wearing a generic yoke or my custom armbinders. 

 

Is that normal?

 

6 hours ago, skyrimll said:

So if I understand correctly, the current way to get a Yoke with the generic function is to use the HeavyBondage keyword and the Yoke tag?

And the answer to my own question is Yes - that's the right way to go about it for now (I managed to restore Yokes in SD+ using that method).

 

Edit: My CTDs were caused by old bodyslides items. Refreshing Bodyslide for DD items fixed that.

[LazyBoot]

10 minutes ago, skyrimll said:

Another question: 

 

I can still access my inventory when wearing a generic yoke or my custom armbinders. 

 

Is that normal?

Yes, that's normal. Though it should block you from equipping weapons/armor/etc.

[Solatium]

Sorry if this is the wrong place to ask this - it's related to the current devious devices branch, but I guess it's more of a general Creation Kit question. If I'm overriding the script for a device and I want the newly attached script to have the same properties as the original one, is there a faster way to do this than auto-fill + manually copying each property? This process seems a bit intimidating with DD 4 (though I LOVE that the new message properties can be auto-filled - thanks to whoever made sure that was possible).

[DeepBlueFrog]

17 minutes ago, Solatium said:

Sorry if this is the wrong place to ask this - it's related to the current devious devices branch, but I guess it's more of a general Creation Kit question. If I'm overriding the script for a device and I want the newly attached script to have the same properties as the original one, is there a faster way to do this than auto-fill + manually copying each property? This process seems a bit intimidating with DD 4 (though I LOVE that the new message properties can be auto-filled - thanks to whoever made sure that was possible).

If there is a way to do that faster, I would like to know too. 

I just spent the better part of the day doing just that for custom devices in 3 of my mods (auto-fill + manually copy from screenshots of default devices because CK has a tendency to crash without saving when multiple properties windows are open at the same time).

[Princessity]

I'm sorry, I wish there was a way (and if there is I'd like to know too, yesterday ^^) During development we had to do that for hundreds of devices... several times over so I definitely feel your pain. I'm afraid there's no easy way to do it.

 

But any properties you don't fill will get default values. I think everything except struggle animations (those have to be specified for armbinders/yokes/so on, otherwise they won't play any) controller quests, key and device keyword will default to nominally useable values. You can look up the defaults at the top of zadEquipScript, where the properties are listed.

[Veladarius]

If you are creating new devices, create one item first and fill all the properties in on the inventory item. Then copy the inventory item (same type devices only) and adjust what you need to in the inventory screen and in the properties. I have done this a number of times and all of the data is copied over when you duplicate it.

[Verstort]

So in 4.0, it seems the following animations were removed from zadlibs:

 

DDZaZAPCArmBZaDS01
DDZaZAPCArmBZaDS02
DDZaZAPCArmBZaDS03
DDZaZAPCArmBZaDS04
DDZaZAPCArmBZaDS05
DDZaZAPCArmBZaDS06

 

I was using them to manually force the player to animate for a short 'scene'.

 

Is there anything to replace these animations that would allow me to manually make an NPC animate? I'm not seeing one in libs but that's probably my failings

[Princessity]

30 minutes ago, Verstort said:

So in 4.0, it seems the following animations were removed from zadlibs:

 

DDZaZAPCArmBZaDS01
DDZaZAPCArmBZaDS02
DDZaZAPCArmBZaDS03
DDZaZAPCArmBZaDS04
DDZaZAPCArmBZaDS05
DDZaZAPCArmBZaDS06

 

I was using them to manually force the player to animate for a short 'scene'.

 

Is there anything to replace these animations that would allow me to manually make an NPC animate? I'm not seeing one in libs but that's probably my failings

I don't think we have these specific animations anymore but since they were taken from ZAP in the first place, you can probably still find them in ZAP (minus the DD prefix)

 

Also I recommend debug.SendAnimationEvent instead of PlayIdle for playing animations. It appears to be more responsive and less prone to failing and you don't need to create properties for animations called this way, just refer to them by their FNIS names as strings.

[LazyBoot]

I found a bug in zadEquipScript.psc (on line 370) preventing the removal of anal plugs from npc NOT wearing an open-backed belt.

Current code:

if npc.WornHasKeyword(libs.zad_DeviousBelt) && DeviceRendered.HasKeyword(libs.zad_DeviousPlugVaginal) || (DeviceRendered.HasKeyword(libs.zad_DeviousPlugAnal) && !npc.WornHasKeyword(libs.zad_PermitAnal))

Looks like some missing ()s is causing the "zad_permitanal" keyword to be required in order to remove any anal plugs from npcs.

 

I'm fairly certain the code should look like this for the intended result:

if npc.WornHasKeyword(libs.zad_DeviousBelt) && (DeviceRendered.HasKeyword(libs.zad_DeviousPlugVaginal) || (DeviceRendered.HasKeyword(libs.zad_DeviousPlugAnal) && !npc.WornHasKeyword(libs.zad_PermitAnal)))

 

 

EDIT: After thinking about it some more... What this code is trying to accomplish is actually completely inconsistent with how open belts work in other situations.

You can't add either type of plug to npcs as long as they are belted, regardless of "zad_permitanal" or not. Same goes for the player character, with removal also blocked for both types of plugs (also regardless of "zad_permitanal" keyword)

[a626943491]

Some equipment texture missing occurred when I upgraded DDI DDX and cursed loot 4.0 and started a new game.It never happened in the old version.Help please...

[Princessity]

7 hours ago, LazyBoot said:

I found a bug in zadEquipScript.psc (on line 370) preventing the removal of anal plugs from npc NOT wearing an open-backed belt.

Current code:

if npc.WornHasKeyword(libs.zad_DeviousBelt) && DeviceRendered.HasKeyword(libs.zad_DeviousPlugVaginal) || (DeviceRendered.HasKeyword(libs.zad_DeviousPlugAnal) && !npc.WornHasKeyword(libs.zad_PermitAnal))

Looks like some missing ()s is causing the "zad_permitanal" keyword to be required in order to remove any anal plugs from npcs.

 

I'm fairly certain the code should look like this for the intended result:

if npc.WornHasKeyword(libs.zad_DeviousBelt) && (DeviceRendered.HasKeyword(libs.zad_DeviousPlugVaginal) || (DeviceRendered.HasKeyword(libs.zad_DeviousPlugAnal) && !npc.WornHasKeyword(libs.zad_PermitAnal)))

 

 

EDIT: After thinking about it some more... What this code is trying to accomplish is actually completely inconsistent with how open belts work in other situations.

You can't add either type of plug to npcs as long as they are belted, regardless of "zad_permitanal" or not. Same goes for the player character, with removal also blocked for both types of plugs (also regardless of "zad_permitanal" keyword)

Weird, I thought we fixed it ages ago. Okay we'll look into it again.

2 hours ago, a626943491 said:

Some equipment texture missing occurred when I upgraded DDI DDX and cursed loot 4.0 and started a new game.It never happened in the old version.Help please...

"Some textures missing" is not helpful at all n_n Please be more specific?

[a626943491]

1 hour ago, Princessity said:

Weird, I thought we fixed it age ago. Okay we'll look into it again.

"Some textures mising" is not helpful at all n_n Pleae be more specific?

Well,for instance,the initial belt acquired in cursed loot LAL add-on start , heavy gag and obsidian equips.It occurred not only in old version save game,but also in newly started game.

 

Should I reinstall NetImmerse Override and try again?