Devious Devices Framework Development/Beta

[DeWired]

2 hours ago, Kharos said:

Yeah... about that *gulp*... I have bad news @Kimy ?.

 

Yep, it is still not working. I could have sworn that it would work after looking at your code changes. It's not a code bug, your latest changes are perfect. I added some debug logging to figure out what the heck is going on, and it turns out that we did not fully think this through.

akActor.SetOutfit(libs.zadEmptyOutfit, false)

As we have previously found out, this will actually set the outfit of the actor base to zadEmptyOutfit, not just the outfit of the actor, right?

akActor.SetOutfit(akActor.GetLeveledActorBase().GetOutfit(), false)

Which means that here GetOutfit() will return zadEmptyOutfit, and the outfit cannot be restored. D'oh!
I don't have a good idea on how to fix that right now... 

 

Well, it seems, old outfit needs to be backed up. How about using ideas from Keyoutfitter mod, and putting outfit into StorageUtil?

For example,

Function ChangeOutfit(Actor akActor, Outfit newOutfit)
	bool isOutfitChanged = StorageUtil.GetBoolValue(akActor,"zad_isOutfitChanged",False)
	if !isOutfitChanged
		; this way, no backup is being done for already changed outfits, so we don't corrupt originals when doing double Store call without Restore.
		StorageUtil.SetFormValue(akActor,"zad_OutfitBackup",akActor.GetLeveledActorBase().GetOutfit())
	EndIf
    akActor.SetOutfit(newOutfit,false)
    StorageUtil.SetBoolValue(akActor,"zad_isOutfitChanged",True)
EndFunction

Function RestoreOutfit(Actor akActor)
	akActor.SetOutfit(StorageUtil.GetFormValue(akActor,"zad_OutfitBackup") as Outfit,false)
	StorageUtil.SetBoolValue(akActor,"zad_isOutfitChanged",False)
	StorageUtil.UnsetFormValue(akActor,"zad_OutfitBackup")
EndFunction

 

[YojimboRatchet]

4 hours ago, Kimy said:

There will be no SE beta of DD5, at least not provided by me. My assumption is that the port will happen somewhere shortly after the official release. SE specific issues will need to be sorted out in the ported version anyway.

 

damn.. i really wanted to help out in some way ...

[Kharos]

54 minutes ago, DeWired said:

Well, it seems, old outfit needs to be backed up. How about using ideas from Keyoutfitter mod, and putting outfit into StorageUtil?

For example,

Hmm... that might work ?.

 

If I understand @Kimy correctly she does not want to use storage util for NPCs because this might cause a lot of "left-over data" when lots of temporary NPCs spawn, are processed, and later despawn without a corresponding cleanup in storage util. But maybe the outfit could be stored by actor base instead of by actor, this would keep the amount of data low as many NPCs would share the same storage util slot? It would need some carefully build logic to ensure that the outfit is only stored the first time DD touches a specific actor base, otherwise we will end up with the same problem again (empty outfit stored in storage util instead of the real one).

 

[Edit] Still it's a lot of work and complex logic for such a seemingly simple feature. The whole outfit system of the Skyrim/Fallout 4 engine is a big WTF in my opinion ?.

[Kimy]

I guess I can use StorageUtil in this case, as we're using the feature only for unique characters anyway. ActorBase maps 1:1 to Actor in this case, not 1:n

[Kimy]

18 hours ago, Kharos said:

[Edit] Still it's a lot of work and complex logic for such a seemingly simple feature. The whole outfit system of the Skyrim/Fallout 4 engine is a big WTF in my opinion ?.

That's almost too polite...

 

Honestly, how they implemented certain features in that engine just reeks of the type of quick dirty hacks people might do in the middle of a year long crunch at 3am in the morning to keep their pointy-haired bosses from asking them "Is this finally done already???" every 5 minutes. :S

[Bane Master]

46 minutes ago, Kharos said:

 this might cause a lot of "left-over data" when lots of temporary NPCs spawn, are processed, and later despawn without a corresponding cleanup in storage util

Shouldn't be an issue - the StorageUtil Notes for authors states

 

" Values will stay on forms or globally until they are Unset or Cleared in case of lists. If value is set on a form and the object is deleted then value will be removed when saving game. If you are done with using a certain variable you should use Unset or Clear function to remove them but it is not required."

 

So values on temp ref actors will be deleted on save game once they are "despawned".

[indolu]

1 hour ago, YojimboRatchet said:

 

damn.. i really wanted to help out in some way ...

Someone will do an official port at some point. You could wait till then and help out. If you don't want to wait you could always try to port it yourself.

[zarantha]

@Kimy While we're asking for things, can you add skee to the version check in zadSlaveBootsScript.psc for SE compatiblity?

That looks like the only problem script in DD for SE. Skee is the replacement for nioverride in the SE Racemenu.

 

This is what I've been doing:

 

Change this:

    if SKSE.GetPluginVersion("NiOverride") < 5 || NiOverride.GetScriptVersion() < 5

 

To this:
    if SKSE.GetPluginVersion("NiOverride") < 5 && SKSE.GetPluginVersion("skee") < 1 || NiOverride.GetScriptVersion() < 5

[Kharos]

7 hours ago, Kimy said:

I guess I can use StorageUtil in this case, as we're using the feature only for unique characters anyway. ActorBase maps 1:1 to Actor in this case, not 1:n

Yeah right, I forgot you changed it to unique actors only  ?

 

6 hours ago, Bane Master said:

So values on temp ref actors will be deleted on save game once they are "despawned".

 That's good, thanks for digging up this info!

[beerman778]

12 hours ago, zarantha said:

@Kimy While we're asking for things, can you add skee to the version check in zadSlaveBootsScript.psc for SE compatiblity?

That looks like the only problem script in DD for SE. Skee is the replacement for nioverride in the SE Racemenu.

 

This is what I've been doing:

 

Change this:

    if SKSE.GetPluginVersion("NiOverride") < 5 || NiOverride.GetScriptVersion() < 5

 

To this:
    if SKSE.GetPluginVersion("NiOverride") < 5 && SKSE.GetPluginVersion("skee") < 1 || NiOverride.GetScriptVersion() < 5

Second this, this would be awesome.

[Kimy]

20 hours ago, zarantha said:

@Kimy While we're asking for things, can you add skee to the version check in zadSlaveBootsScript.psc for SE compatiblity?

That looks like the only problem script in DD for SE. Skee is the replacement for nioverride in the SE Racemenu.

 

This is what I've been doing:

 

Change this:

    if SKSE.GetPluginVersion("NiOverride") < 5 || NiOverride.GetScriptVersion() < 5

 

To this:
    if SKSE.GetPluginVersion("NiOverride") < 5 && SKSE.GetPluginVersion("skee") < 1 || NiOverride.GetScriptVersion() < 5

Will add this!

[Kimy]

Devious Devices 5 Beta 7

 

- Added: zadSlaveBootsScript now checks for the presence of the SKEE plugin too, to enhance SE compability.
- Fixed: The outfit swapping feature now saves the original outfit via StorageUtil to prevent yet another problem with resetting the outfit.

 

Devious Devices 5 LE Beta 1 To Beta 7.7z

 

Here is the download link for the Beta 1 build:

 

https://mega.nz/file/eMEWRbJQ#YALWLvOcPo6PlgIgcLYnQdv2M86RsZTsc1WR31u49zc

 

Have fun testing!

[LazyBoot]

Looks like there might be an issue with the animation filtering now... 

DCL manages to pick bound animations just fine, but I'm seeing non-bound animations when other mods call sexlab normally while the PC is bound.

 

EDIT: Also the MCM for the filtering is blank

Spoiler

 

[DeWired]

12 minutes ago, LazyBoot said:

Looks like there might be an issue with the animation filtering now... 

DCL manages to pick bound animations just fine, but I'm seeing non-bound animations when other mods call sexlab normally while the PC is bound.

You said so much and not enough.

Namely, what bondage is in effect, who are in animation with PC (what sex, and so on), what animation was actually selected... Ideally, fragment of log can be attached for analysis.

[LazyBoot]

18 minutes ago, DeWired said:

You said so much and not enough.

Namely, what bondage is in effect, who are in animation with PC (what sex, and so on), what animation was actually selected... Ideally, fragment of log can be attached for analysis.

I mostly tested with a few different armbinders, but also chastity belt. Both male and female npcs, animations were normal sexlab animations fitting for the sex of the participants. Log shows normal sexlab scene startups. The only thing missing is DD switching out the animation for something that fits the device(s) worn.

Not sure what else to say... It ended up being a normal sexlab scene, but the arms popping out of the armbinder, and strap-ons and dicks penetrating through the chastity belt.

And no errors during the setup (or anywhere else during) the scene.

[chaimhewast]

While I unfortunately don't have the time to properly test the beta, I do have a minor request/suggestion. Blindfolds are great at keeping the player from seeing, but they don't really affect NPCs. In my personal copy, I have the blindfold effect also apply the AbBlind magic effect (00052FF3) at a strength of 100 - which makes it so that they can't "see" while wearing one as far as detection is concerned.

 

I don't expect to be fighting any blindfolded NPCs, but it's just nice knowing it's there.

[Kimy]

2 hours ago, donttouchmethere said:

I have that too. I thought @osmelmc's SexlabUtility took over that part? (if you have that mod installed).

I cannot remember me delegating the filter feature to any other mod. If they did try to take that over, they did without my approval or consent or endorsement, or even knowledge. Also, registering DD's bound animations to SexLab's general registry would be a super stupid thing to do I'd wholeheartedly disagree with, because it would make the bound animations getting played in many situations when they should not. I am genuinely not sure why people think I went through all this trouble to AVOID registering the bound animations to SexLab? Seriously?

[Kimy]

4 hours ago, LazyBoot said:

I mostly tested with a few different armbinders, but also chastity belt. Both male and female npcs, animations were normal sexlab animations fitting for the sex of the participants. Log shows normal sexlab scene startups. The only thing missing is DD switching out the animation for something that fits the device(s) worn.

Not sure what else to say... It ended up being a normal sexlab scene, but the arms popping out of the armbinder, and strap-ons and dicks penetrating through the chastity belt.

And no errors during the setup (or anywhere else during) the scene.

 

Try refreshing the MCM with the appropriate console commands or by starting a new game real quick. I might or might not have forgotten to force-renew the MCM in the latest beta.

 

If you're using 3rd party mods that tamper with or override the DD filter or register its internal bound animations to SexLab, breakage is expected, gathering from the reports I have received. In particular, SexLab Utility Plus is considered incompatible with DD5 at this time. Please disable it if you're participating in the beta testing, because it will produce flawed bug reports. I got some of these already.

[Kimy]

15 hours ago, donttouchmethere said:

It's not as bad as it appears to you.

Filters on, DD only = only DD animation get played => limited animation choices from the DD system

Filters on, SL = DD animations play, but also any bondage animations of SLAL packs that would fit the situation if they have the right tag => more variation, flexible system for upcoming SLAL pack bondage animations

Filters off = player decides what gets played => animations that would fit the situation can be chosen that might not fit the DD filter systematic

 

I understand that this is bad for DD beta testing tho, there the priority lies on testing the DDi systems and not compatibility or alternatives.

It's unfortunately bad. I will explain.

 

The problem lies in how the SexLab tag system works. DD bound animations include a "DeviousDevices" tag that identifies them as bound animations, but also other, more regular tags they share with non-bound animations, e.g. "vaginal" or "oral". Now, DD-aware mods can of course select bound animations with the requireall parameter set to true and add DeviousDevices to the tag list given to make sure only bound animations are picked.

Unfortunately, it doesn't work the OTHER way around. If you want to pick a regular non-bound animation, you'd e.g. use the "vaginal" tag to pick them. That however, would potentially pick a bound animation registered to SexLab as well, as the selector doesn't care about the -additional- "DeviousDevices" tag as long as the animation matches AT LEAST the one given in the API call. The only way to avoid that would be passing "DeviousDevices" in the suppress tag line, but non-DD aware mods don't do that (because why would they, really?) So you might and will see bound animations in situations where nobody is bound.

That's the entire reason why I wrote so much code to avoid having to register DD's animation to SexLab. To make sure these bound animations get played only when it's appropriate. It looks super silly when an actor assumes the "hands in yoke" pose, when she's not wearing a yoke. Unlike the bound animations you can find in various SLAL packs, DD animations do not use anim objects. They rely on and use the actual DD restraint worn. Which is of course not present if the actor isn't bound.

 

Now, I obviously don't care about players manually switching animations using SexLab or a 3rd party mod. In that case they know what they're doing. But overriding the DD filter and/or registering its internal animations to SexLab will produce broken results, even if the system is otherwise used correctly by mod creators. And it will (and already did) lead to me getting bug reports about bound animations not working correctly, when it's actual a 3rd party mod that broke the feature. And as you can imagine, I am not the biggest fan of getting bug reports for features in my mod that worked just fine until somebody's patch broke them.

[Kimy]

14 hours ago, LazyBoot said:

the MCM for the filtering is blank

 

Bug confirmed and fixed for the next version.

[DayTri]

1 hour ago, Kimy said:

It's unfortunately bad. I will explain.

 

The problem lies in how the SexLab tag system works. DD bound animations include a "DeviousDevices" tag that identifies them as bound animations, but also other, more regular tags they share with non-bound animations, e.g. "vaginal" or "oral". Now, DD-aware mods can of course select bound animations with the requireall parameter set to true and add DeviousDevices to the tag list given to make sure only bound animations are picked.

Unfortunately, it doesn't work the OTHER way around. If you want to pick a regular non-bound animation, you'd e.g. use the "vaginal" tag to pick them. That however, would potentially pick a bound animation registered to SexLab as well, as the selector doesn't care about the -additional- "DeviousDevices" tag as long as the animation matches AT LEAST the one given in the API call. The only way to avoid that would be passing "DeviousDevices" in the suppress tag line, but non-DD aware mods don't do that (because why would they, really?) So you might and will see bound animations in situations where nobody is bound.

That's the entire reason why I wrote so much code to avoid having to register DD's animation to SexLab. To make sure these bound animations get played only when it's appropriate. It looks super silly when an actor assumes the "hands in yoke" pose, when she's not wearing a yoke. Unlike the bound animations you can find in various SLAL packs, DD animations do not use anim objects. They rely on and use the actual DD restraint worn. Which is of course not present if the actor isn't bound.

 

Now, I obviously don't care about players manually switching animations using SexLab or a 3rd party mod. In that case they know what they're doing. But overriding the DD filter and/or registering its internal animations to SexLab will produce broken results, even if the system is otherwise used correctly by mod creators. And it will (and already did) lead to me getting bug reports about bound animations not working correctly, when it's actual a 3rd party mod that broke the feature. And as you can imagine, I am not the biggest fan of getting bug reports for features in my mod that worked just fine until somebody's patch broke them.

 

Seems like it would be a good feature for Sexlab to let mods/users register tags as default excluded, instead of using an empty string as the default for tag suppression. Would be simple to implement in SL and sounds like it would remove a bunch of complexity from DD. It's not the only use case either, I'd love to be able to default suppress tags like "Hypnosis" or "FemDom" so they don't play in bizarre contexts but can still be available for mods that want them.

[Kimy]

The best way I can think of to solve this would be defining a type of tag that's considered explicit, so the animation tagged with it would never get chosen unless the tag is explicitly passed to the selector. So "vaginal" would not pick a DD bound animation tagged with it, unless "DeviousDevices" is passed as well. So non-DD mods wouldn't accidentally pick DD bound animations, even if registered to the general SexLab repository.

 

But I don't expect Ashal to ever make updates to SexLab again, and relying on 3rd party patches only a fraction of the userbase is going to install is not going to solve the problem, either.

[Asian_Ninja1]

1 hour ago, Kimy said:

The best way I can think of to solve this would be defining a type of tag that's considered explicit, so the animation tagged with it would never get chosen unless the tag is explicitly passed to the selector. So "vaginal" would not pick a DD bound animation tagged with it, unless "DeviousDevices" is passed as well. So non-DD mods wouldn't accidentally pick DD bound animations, even if registered to the general SexLab repository.

 

But I don't expect Ashal to ever make updates to SexLab again, and relying on 3rd party patches only a fraction of the userbase is going to install is not going to solve the problem, either.

Could it be possible to create a patch for this and bundle it with DD5's installer, making it mandatory? Or would that be too much work to maintain?

[Kimy]

14 minutes ago, Asian_Ninja1 said:

Could it be possible to create a patch for this and bundle it with DD5's installer, making it mandatory? Or would that be too much work to maintain?

I wouldn't consider it good practice to release unsanctioned patches against other people's mods. I don't like it when people do that with mine, so I can't do it with other's.

[LazyBoot]

13 hours ago, Kimy said:

 

Try refreshing the MCM with the appropriate console commands or by starting a new game real quick. I might or might not have forgotten to force-renew the MCM in the latest beta.

 

If you're using 3rd party mods that tamper with or override the DD filter or register its internal bound animations to SexLab, breakage is expected, gathering from the reports I have received. In particular, SexLab Utility Plus is considered incompatible with DD5 at this time. Please disable it if you're participating in the beta testing, because it will produce flawed bug reports. I got some of these already.

I did forget to mention that I did test using a completely new save, using beta 7.

And I have nothing installed that should interfere with the DD filter (nor anything that registers the animations to sexlab)

 

I'll sit down and do some testing later to see if I can reproduce the filter overriding issue with a minimal modset