Devious Devices Framework Development/Beta

[GuruSR]

I'm in the process of cleaning up dialogue in "Being a Cow" and I was doing a test play-through to see what kind of work I have to do yet.

Sadly, I didn't disable a bunch of things in Cursed Loot and got stuck inside some of the DD items, of which don't work on the mutated people (hooves going back to gloved hands, suits covering the body except the udders, hooves going to high heels), none of it seemed to work, so what I was asking is:

 

What infrastructure is needed (code, code call, faction, keyword added, etc) to block any and all DD items from being equipped (or staying equipped if present) to an already mutated actor who's no longer got hands or feet and has udders, so I would do this only at the point where the cow parts would be hindered or removed by DD items being equipped.  The other thing I would need to do is to 100% block any of other mods trying to attach DD items to the player.  So I would need to register those actors as "untouchable" (kind of like children can't be gagged, though sometimes you want to).

 

GuruSR.

[Code Serpent]

1 hour ago, GuruSR said:

What infrastructure is needed (code, code call, faction, keyword added, etc) to block any and all DD items from being equipped (or staying equipped if present) to an already mutated actor who's no longer got hands or feet and has udders, so I would do this only at the point where the cow parts would be hindered or removed by DD items being equipped.  The other thing I would need to do is to 100% block any of other mods trying to attach DD items to the player.  So I would need to register those actors as "untouchable" (kind of like children can't be gagged, though sometimes you want to).

Oddly enough, I've been thinking of how to implement something like this for DDs, since I'm thinking of making my own transformation files. I think the quickest way to take care of it would be to prevent equipping devices on slots that currently have equipment with the "SexLabNoStrip" keyword. Though, this might be to broad a restriction.

[Kimy]

10 hours ago, naaitsab said:

After disabling ZAZ in my loadorder I found the HR_HarnessBoots01HDT and HR_HarnessBoots02HDT NIF's are broken.

After some investigation I found that they still require the HDT XML's from the ZAZ data file. The HR_HarnessGlovesHDT seem to point to the right location. (meshes\devious\Zaz)

 

 

I've added the required files for those who need them until the files are NIF (and bodyslide NIF) modified

ZaZ HDT for DD.7z 487.35 kB · 2 downloads

 

Great find! Will fix this!

[Kimy]

3 hours ago, GuruSR said:

I'm in the process of cleaning up dialogue in "Being a Cow" and I was doing a test play-through to see what kind of work I have to do yet.

Sadly, I didn't disable a bunch of things in Cursed Loot and got stuck inside some of the DD items, of which don't work on the mutated people (hooves going back to gloved hands, suits covering the body except the udders, hooves going to high heels), none of it seemed to work, so what I was asking is:

 

What infrastructure is needed (code, code call, faction, keyword added, etc) to block any and all DD items from being equipped (or staying equipped if present) to an already mutated actor who's no longer got hands or feet and has udders, so I would do this only at the point where the cow parts would be hindered or removed by DD items being equipped.  The other thing I would need to do is to 100% block any of other mods trying to attach DD items to the player.  So I would need to register those actors as "untouchable" (kind of like children can't be gagged, though sometimes you want to).

 

GuruSR.

 

There is no safe way to "freeze" a given equip state on an actor on the framework level. DD content mods that equip and unequip items do expect the framework to complete the operation, if called. If I'd change the expected behavior, all sorts of things would break in all sorts of mods. Even the ability to "blacklist" actors from DD has the strong potential to break existing code not taking that possibility into consideration.

 

Blocking slots is theoretically doable by equipping invisible DD devices in them. Although the framework would think that you'd be wearing...well...invisible devices, and call periodic events involving these items. Not sure if that behavior would be desired. With wrist devices, this approach would also cause the actor assuming the bound pose for the device given.

[Code Serpent]

55 minutes ago, Kimy said:

There is no safe way to "freeze" a given equip state on an actor on the framework level. DD content mods that equip and unequip items do expect the framework to complete the operation, if called. If I'd change the expected behavior, all sorts of things would break in all sorts of mods. Even the ability to "blacklist" actors from DD has the strong potential to break existing code not taking that possibility into consideration.

Instead of changing the lock function, could a check function be added? Calling it would determine if the actor is 'blacklisted' by some mod, or has a conflicting non-DD device in the given slot. You could also combine the two to make a "safelock" function, that calls the check function before the lock function.

[Guest]

Hi @Kimy, ?

is it possible to prevent device comments from DCL to be triggered by certain custom NPCs?   

If it isn't yet, could you add something like a keyword to DD (yes DD, not DCL) for it?

I'm working with @Prime66 on "The Facility" mod and we'd rather not ad DCL as a requirement. ?

Cheers ?

 

[Zaflis]

18 minutes ago, Racoonity, Serah said:

Hi @Kimy, ?

is it possible to prevent device comments from DCL to be triggered by certain custom NPCs?   

If it isn't yet, could you add something like a keyword to DD (yes DD, not DCL) for it?

I'm working with @Prime66 on "The Facility" mod and we'd rather not ad DCL as a requirement. ?

Cheers ?

 

Do you have already prevention for cursed traps and the rape feature?

[Guest]

7 minutes ago, Zaflis said:

Do you have already prevention for cursed traps and the rape feature?

 

Yes, we managed to prevent that already with the provided code. ?

We also added dialogue blocking to prevent other mods to add lines to our npcs, but DCL comments trigger in a very peculiar way and we can't manage to disable them. ?

[Prime66]

So what I am suggesting is making a Keyword that can be attached to Quest-relevant NPC's that other mods can check.

As an example, and since it's relevant to us at the moment, a way to suppress Cursed Loot Device comments. Adding said Keyword to DD and Attaching the Condition:

HasKeyword zaz_QuestNPC = 0 (just an example) would prevent the comments from firing. At least that's my assumption from quickly glancing over Cursed Loots Dialogue. 

 

I should note since it might be relevant. I did add our NPC's to Cursed Loot's No Solicitation List. This removed some dialogue but not the Gag talk and Device comments which have the most potential to break Quest mods. 

[GuruSR]

On 3/31/2021 at 1:03 AM, Kimy said:

There is no safe way to "freeze" a given equip state on an actor on the framework level. DD content mods that equip and unequip items do expect the framework to complete the operation, if called. If I'd change the expected behavior, all sorts of things would break in all sorts of mods. Even the ability to "blacklist" actors from DD has the strong potential to break existing code not taking that possibility into consideration.

So we could say, have DD's framework equip on children?  Or are there checks for that?  Sadly, the only way I can deal with that would be to require DD for it (which I can't) and/or detect it and include a full body slot item that is marked as it can't be unequipped?  Would that work?

 

On 3/31/2021 at 1:03 AM, Kimy said:

Blocking slots is theoretically doable by equipping invisible DD devices in them. Although the framework would think that you'd be wearing...well...invisible devices, and call periodic events involving these items. Not sure if that behavior would be desired. With wrist devices, this approach would also cause the actor assuming the bound pose for the device given.

So a full body block as I suggested above, with all the slots in use for DD items (and leaving things out that are used by the mod itself (milking equipment slots), I could conceivably mark them all as in use?  If so, what would be required for the object?

 

GuruSR.

[El_Duderino]

9 hours ago, GuruSR said:

So a full body block as I suggested above, with all the slots in use for DD items (and leaving things out that are used by the mod itself (milking equipment slots), I could conceivably mark them all as in use?  If so, what would be required for the object?

 

I think you can set up the .nif as you want and then assign the ArmorAddon slots as needed for your "blocker" item. Just watch out that the priority is sufficiently high to override other models/devices that you want to be hidden. Or it might not even need the slots but merely the keywords. I did some tests in my game a longer while ago (just playing around) where I added some extra devious keywords to a DeviousSuit item (which had only slot 32) and that seemed to stop the equipping of the other keyworded items too as far as I could tell in my admittedly very limited testing. This might be worth a try, especially if you also assign QuestItem which should make it even more robust against other mods' interference.

[Kimy]

On 4/1/2021 at 9:03 PM, GuruSR said:

So we could say, have DD's framework equip on children?

 

If I see or get notified of a mod deliberately equipping DD devices on children, I will ban that mod from the framework with absolute abandon, and make sure it will never exist in the same load-order with DD ever again.

 

On 4/1/2021 at 9:03 PM, GuruSR said:

So a full body block as I suggested above, with all the slots in use for DD items (and leaving things out that are used by the mod itself (milking equipment slots), I could conceivably mark them all as in use?  If so, what would be required for the object?

 

Just make an object occupying all possible DD slots and tag it will the corresponding keywords.

[Kimy]

On 3/31/2021 at 12:42 PM, Racoonity, Serah said:

Hi @Kimy, ?

is it possible to prevent device comments from DCL to be triggered by certain custom NPCs?   

If it isn't yet, could you add something like a keyword to DD (yes DD, not DCL) for it?

I'm working with @Prime66 on "The Facility" mod and we'd rather not ad DCL as a requirement. ?

Cheers ?

 

 

There are some formlists in DCL you can add NPCs to, to prevent certain DCL features from triggering on them. Tbh, I'd have to check if the device comments are a part of it. I remember me implementing it for solicitation.

 

If needed, I will add such a feature for the device comments. Let me know if it's needed! But it will be a DCL feature, not DD. DD is content mod agnostic. I try my very best not to interfere with any DD content mod from the framework end, including my own!

[naaitsab]

@Kimy did you get the chance to look at my code proposal a few pages back? While working on the Spriggan quest mod the regular events are bit immersion breaking   so if it could work that would be great  

 

 

 

[Prime66]

On 4/3/2021 at 7:50 AM, Kimy said:

 

There are some formlists in DCL you can add NPCs to, to prevent certain DCL features from triggering on them. Tbh, I'd have to check if the device comments are a part of it. I remember me implementing it for solicitation.

 

If needed, I will add such a feature for the device comments. Let me know if it's needed! But it will be a DCL feature, not DD. DD is content mod agnostic. I try my very best not to interfere with any DD content mod from the framework end, including my own!

 

Thanks,
At the moment, the only dialogue that I am aware of that still pops up are device comments and the Gag dialogue. I know this isn't the Cursed Loot thread, but I should still mention it. The Cursed Loot Gag dialogue never shuts down, even if the rest of the mod is. 

 

 

I would also like to rephrase my suggestion since I might have put an unfair focus on Cursed Loot. But I think this could be something useful for the Framework to make DD mods play better with each other. 
So the idea is to make a Faction and or add Keywords that can be added to NPC's and Locations to Exclude them from Random events added by other mods. As I suggested above, adding the Keyword: QuestActor (or similar) to DD would allow you or even us to check for this condition to avoid clashing with other mods if we add a random event. Even better, if a new Mod comes out that adds new dialogue to every NPC and or does random events, the only thing they need to do to make their mods compatible with others would be to check for the Quest actor and or Location Keyword. 

 

Edit: I am not suggesting for DD to interfere with Content mods directly but rather add stuff so content mods can interact with each other without the need to make a dependency on each other / the need for scripting. 

[GuruSR]

On 4/3/2021 at 1:43 AM, Kimy said:

If I see or get notified of a mod deliberately equipping DD devices on children, I will ban that mod from the framework with absolute abandon, and make sure it will never exist in the same load-order with DD ever again.

Not what I meant.  Most of the time when I am writing code to interact with some other library or code segment, I'm used to having to validate everything first, the pointer, the memory, the access of the thread to access the memory the function wants, that sort of stuff, so I thought that DD (as a framework) would have a similar means of testing for certain things by default.  Like "is this a child?", "Is access to this actor denied?", etc.  I'm guessing no on all fronts.

 

On 4/3/2021 at 1:43 AM, Kimy said:

Just make an object occupying all possible DD slots and tag it will the corresponding keywords.

I was looking for a wiki to get those keywords and slots, but Google is being... "useful" as usual.  Where is the wiki for it, Assets I presume?  Sadly, I doubt I can inject a keyword onto an existing object without a hard requirement of DD, something I was hoping to avoid, or are there keywords available to avoid that (vanilla ones)?

 

Also was trying to track down a list of the devices so I could see what I was needing for something, but I couldn't find a wiki for that either (github wasn't useful either in that either, like Google, hopefully MS does something about that).

 

GuruSR.

[Zaflis]

An idea for blindfolds: a one-handed "spell" that is called something like "Peek blindfold". It wouldn't do any casting but when it's equipped on left or right hand it would greatly illeviate the blindfold effect. On that note the effect could normally be stronger some way too, assuming the difficulty slider still exists in MCM. If it's equipped by both hands its effect would be same as with 1 hand i guess.

 

It would also need a new keyword that prevent this kind of peeking if they are that secure, for example hoods. Say "zad_noBlindfoldPeek".

 

It might also be great if the spell is only added when you have a blindfold and removed when you don't. But this is totally optional.

 

And why i think it would be great is because you get an actual chance to fight while blindfolded, but only with 1 hand. That won't work for bows and 2-handed weapons but does for spells and some simple blades.

[OsmelMC]

On 4/3/2021 at 1:50 AM, Kimy said:

 

There are some formlists in DCL you can add NPCs to, to prevent certain DCL features from triggering on them. Tbh, I'd have to check if the device comments are a part of it. I remember me implementing it for solicitation.

 

If needed, I will add such a feature for the device comments. Let me know if it's needed! But it will be a DCL feature, not DD. DD is content mod agnostic. I try my very best not to interfere with any DD content mod from the framework end, including my own!

Probably better add one keyword to DDi that can be used by modders to prevent general comments on specific devices. For example SexLab Parasites from @DeepBlueFrog add living armors treated as devices because have the same properties but the rest of the Mods apply dialogues out of place based on the current keyword array like rape dialogues or chastity belt related dialogues. I not sure how is seeing by the rest of the users but who NPC on his right main will wish to rape a woman with worms getting out of his vagina.

 

 

The only way to prevent situations like that, right now, is adding unwanted dependency to the mods or patching them. But if the DDi include some keyword to deal with this is easy for modders ignore the devices with the keyword and let his treatment for the original mod only. A keyword like "IgnoreMe" don't solve the issue perse but make posible deal with this.

[Roggvir]

7 hours ago, osmelmc said:

Probably better add one keyword to DDi that can be used by modders to prevent general comments on specific devices. For example SexLab Parasites from @DeepBlueFrog add living armors treated as devices because have the same properties but the rest of the Mods apply dialogues out of place based on the current keyword array like rape dialogues or chastity belt related dialogues. I not sure how is seeing by the rest of the users but who NPC on his right main will wish to rape a woman with worms getting out of his vagina.

 

 

The only way to prevent situations like that, right now, is adding unwanted dependency to the mods or patching them. But if the DDi include some keyword to deal with this is easy for modders ignore the devices with the keyword and let his treatment for the original mod only. A keyword like "IgnoreMe" don't solve the issue perse but make posible deal with this.

If i understand this correctly, you are basically saying:
Add one more keyword check into the DD framework and ALL related mods.

That means adding another condition in every DD related topic branch, in every mod that adds some dialogues reacting to devices.
One more condition to check inside various functions in the DD framework, and sometimes in other mods too.
Conditions that will be checked on EVERY procesed device, to solve what really is an edge-case happening with very few rarely used items.
This seems completely backwards to me.

Shouldn't this be handled by the mod that adds such "device"?
as in: if it isn't supposed to work as devious device, don't make it one?

If such situations are to be resolved by the framework, it should do it in a way separate from handling devices.
Add some means that modders can use whatever functionality they need without making their item into a devious device when its not supposed to be one.
 

[OsmelMC]

1 hour ago, Roggvir said:

If i understand this correctly, you are basically saying:
Add one more keyword check into the DD framework and ALL related mods.

That means adding another condition in every DD related topic branch, in every mod that adds some dialogues reacting to devices.
One more condition to check inside various functions in the DD framework, and sometimes in other mods too.
Conditions that will be checked on EVERY procesed device, to solve what really is an edge-case happening with very few rarely used items.
This seems completely backwards to me.

Shouldn't this be handled by the mod that adds such "device"?
as in: if it isn't supposed to work as devious device, don't make it one?

If such situations are to be resolved by the framework, it should do it in a way separate from handling devices.
Add some means that modders can use whatever functionality they need without making their item into a devious device when its not supposed to be one.
 

The keyword Is just to add the opportunity to ignore some devices without add extra dependency.

If modders use it or not depends just of them and is not really big deal because will be used mainly on some hello dialogues and few devices.

Right now the framework have one keyword for Quest Devices that is also used on a similar way by some Mods.

[naaitsab]

While making a scene involving the pump plugs I made some sound files. Perhaps somethings for the framework as I read the new pump gag wil also get some love?

 

They are royalty free (source: https://freesound.org/people/Tomlija/sounds/101434/)

Pumps.7z

 

[Murphiee]

So, i wanted some easy to purchase devices, so i added devices to the khajiiit caravan vendors by creating a new leveled item list, and removing the NoVendor tag from related items.

But whenever i equip a bought Gag device, a bunch of other devices are automatically equipped.

Adding items directly from additem menu works fine tough.

Anyone have any idea what i could have messed up? Included below is the esp in question, built for SSE.

Devious Vendor.esp

[jbezorg]

A proposal. I think this needs to be added.

function Masturbate(actor a, bool feedback = false) in zadLibs seems to be called directly a lot and it pretty immersion breaking and comical / annoying when combat stops.

 

      General Tullius! The battle has stopped!

      Is it over? Did we win? Have we defeated Ulfric?!

      No.....

      By the divines........

      It's not that!

      What is it then!

      The Dragonborn needed to rub one out and everyone is standing around watching. 

 

Meanwhile. Two bandits picking over the bodies of dead Imperial and Stormcloak soldiers

 

      B1: So, I'm keeping an eye on the battle over at Whiterun and the Dragonborn comes out of nowhere casting fireballs everywhere.

 

      B1: I don't know what got into her head but suddenly she starts rubbing one out right in the middle of the battle.

 

      B2: What the hell? What'd they do to her? The Stormcloaks must have ripped her to shreds!

 

      B2; By the way, this guy ain't got nothing on him. Like 10 septims and a... milk bucket? Who the hell carries around a milk bucket?

 

      B1: Ugh, damnit! Anyway, they didn't do nuthin to the her. I think they were as confused as I was. Get this. She was wearing a chasity belt.

      ......

 

zadLibs @line 1644

function Masturbate(actor a, bool feedback = false)	
	; ADD THIS? --v
	; don't execute this function if the character is in combat. Nobody in their right mind starts playing with herself if there are people trying to kill her.
	; Events that otherwise would call this function are responsible for providing alternatives as desired.
	if a.IsInCombat() 
		return -2 ; or false?
	Endif
	; ADD THIS? --^

	sslBaseAnimation[] Manims 
	If a == PlayerRef && feedback
		NotifyPlayer("You can not resist your urges anymore!")
	Else
		If a.GetLeveledActorBase().GetSex() == 1 && feedback
			NotifyPlayer(a.GetLeveledActorBase().GetName() + " can't resist her urges anymore...")
		ElseIf a.GetLeveledActorBase().GetSex() == 0 && feedback
			NotifyPlayer(a.GetLeveledActorBase().GetName() + " can't resist his urges anymore...")
		Endif
	EndIf	
	If a.WornHasKeyword(zad_DeviousArmbinder) || a.WornHasKeyword(zad_DeviousArmbinderElbow)
		Manims = New sslBaseAnimation[1]
		Manims[0] = SexLab.GetAnimationObject("DDArmbinderSolo")				
	elseIf a.WornHasKeyword(zad_DeviousYoke)
		Manims = New sslBaseAnimation[1]
		Manims[0] = SexLab.GetAnimationObject("DDYokeSolo")			
	Elseif a.WornHasKeyword(zad_DeviousBelt) || a.WornHasKeyword(zad_DeviousHarness) && !a.WornHasKeyword(zad_DeviousHeavyBondage)
		Manims = New sslBaseAnimation[1]
		Manims[0] = SexLab.GetAnimationObject("DDBeltedSolo")		
	Elseif a.WornHasKeyword(zad_DeviousHeavyBondage)
		; play bound animation for other restraints
		PlayHornyAnimation(a)	
		return
	Else
		If a.GetLeveledActorBase().GetSex() == 1
			Manims = SexLab.GetAnimationsByTag(1, "Solo", "F", requireAll=true)
		Else
			Manims = SexLab.GetAnimationsByTag(1, "Solo", "M", requireAll=true)
		Endif
	Endif
	actor[] tmp = new actor[1]
	tmp[0] = a    
	SexLab.StartSex(tmp, Manims)
EndFunction

[naaitsab]

4 hours ago, jbezorg said:

A proposal. I think this needs to be added.

function Masturbate(actor a, bool feedback = false) in zadLibs seems to be called directly a lot and it pretty immersion breaking and comical / annoying when combat stops.
 

 

I could be mistaken but doesn't that come down to the modder to check for combat and is already done in DD? AFAIK the device events check for combat and mods like Crused Loot also do before firing the function. But a extra check non the less couldn't hurt. As it's a bit daft in a combat situation  

[jbezorg]

11 hours ago, naaitsab said:

 

I could be mistaken but doesn't that come down to the modder to check for combat and is already done in DD? AFAIK the device events check for combat and mods like Crused Loot also do before firing the function. But a extra check non the less couldn't hurt. As it's a bit daft in a combat situation  

I think it may also be a case or script lag. It was the battle of Whiterun after all in a long play-through. I don't think putting multiple checks in is a bad idea either for the reason you stated. Especially in a long chain of functions given how Skyrim prioritizes the execution of scripts based off the priority of the quest they're associated with and will wait for a response from other scripts/quests/frameworks which are also prioritized.