Devious Devices Framework Development/Beta

[Kimy]

9 hours ago, VirginMarie said:

Test Crazy Theory for cause of Stacked

 

log29.txt

Ran through a dungeon and, around a town, then inside a tavern, wearing partial blocking devices, and Love Shouting, making 17 Tries in total. No Stacked at all. No other issues.

 

I commented out code as follows:

  Reveal hidden contents

 

Bool Function StartValidDDAnimation(Actor[] SexActors, bool forceaggressive = false, string includetag = "", string suppresstag = "", Actor victim = None, Bool allowbed = False, string hook = "")
	libs.log("StartValidDDAnimation()")
	; This function isn't threadsafe, so we need a mutex
	If Mutex
		libs.log("StartValidDDAnimation() aborted: Mutex set.")
		Return False
	EndIf
	SkipFilter = False
	Mutex = True
	sslBaseAnimation[] SAnims
	SAnims = SelectValidDDAnimations(SexActors, SexActors.Length, forceaggressive = forceaggressive, includetag = includetag, suppresstag = suppresstag)
	;/If Sanims.Length <= 0
		; no valid animations yet. Trying fallbacks: Hide bindings
		libs.log("StartValidDDAnimation(): No valid animations yet: Removing bindings")
		StoreHeavyBondage(SexActors)
		SAnims = SelectValidDDAnimations(SexActors, SexActors.Length, forceaggressive = forceaggressive, includetag = includetag, suppresstag = suppresstag)
	EndIf
	If Sanims.Length <= 0
		; Hide chastity
		libs.log("StartValidDDAnimation(): No valid animations yet: Removing belts")
		StoreBelts(SexActors)
		SAnims = SelectValidDDAnimations(SexActors, SexActors.Length, forceaggressive = forceaggressive, includetag = includetag, suppresstag = suppresstag)
	EndIf
	If Sanims.Length <= 0
		; Hide gags
		libs.log("StartValidDDAnimation(): No valid animations yet: Removing gags")
		StoreGags(SexActors)
		SAnims = SelectValidDDAnimations(SexActors, SexActors.Length, forceaggressive = forceaggressive, includetag = includetag, suppresstag = suppresstag)
	EndIf
	If Sanims.Length <= 0
		libs.log("Error: StartValidDDAnimation failed. No animations found after fallbacks. Aborting.")
		RetrieveHeavyBondage(SexActors)
		RetrieveBelts(SexActors)
		RetrieveGags(SexActors)
		Mutex = False
		Return False
	EndIf	/;
	SkipFilter = True
	SexLab.StartSex(Positions = SexActors, anims = Sanims, victim = victim, allowbed = allowbed, hook = hook) 		
	Mutex = False
	Return True
EndFunction

 

 

 

Theory I was testing, is that the Store functions, are not latent, thus the unequip could occur at the same time as sexlab is already starting the animation, and I do find that equip/unequip can screw up animating or idles. In prior versions I've seen a few times, my yoke still on when animations start and then coming off later.

 

Now that said, should be able to see the removal in the log, but I've not caught that, so this could be completely wrong. But somehow, commenting out this code, has allowed 17 consecutive flawless scenes, which is by far, the best I've seen since installing DD5. I did the very same test before that, and Stacked was about 1 in every 3 or 4.

 

I also put a trace in the Logic Function to see if it ever executed, and it did not, according to the log, which is good.

Log29 - 17 tries, no Stacked, commented out code.log 325.53 kB · 1 download

According to Papyrus specs, functions in the same script should be latent. That's why the store functions are in the BQ script. Then again, when did Papyrus ever behave the way you expect it to behave? lol

[Ryu Gabriev]

1 hour ago, Kimy said:

The Elbowbinder shouldn't really need one. It should just work for whatever body you're using.

There's pretty heavy clipping though, when I do. In contrast with the exact same bodytype (Wench Body, btw), regular Armbinder had almost no clipping at all. I should also mention that the Ropebinder, which in practice is the same thing as an elbowbinder (changes the same areas, same pose, etc.) it DOES have a bodyslide conversion and looks fine.

[hungvipbcsok]

16 minutes ago, Ryu Gabriev said:

There's pretty heavy clipping though, when I do. In contrast with the exact same bodytype (Wench Body, btw), regular Armbinder had almost no clipping at all. I should also mention that the Ropebinder, which in practice is the same thing as an elbowbinder (changes the same areas, same pose, etc.) it DOES have a bodyslide conversion and looks fine.

I haven't tried DD5 yet but i did have that clip problem at DD4 before. And i found that running the cosio in bodyslide fix the problem.

[Ryu Gabriev]

14 minutes ago, hungvipbcsok said:

I haven't tried DD5 yet but i did have that clip problem at DD4 before. And i found that running the cosio in bodyslide fix the problem.

cosio?

[VirginMarie]

@Kimy

 

StartValidDDAnimation, without some options, does not solve some other issues, in terms of SLaV compatibility with DD5. I'm thinking past the "Stacked", not that it can be dismissed. I'm now into "story" issues.

 

When doing those last tests above (before commenting out some code), I was losing virginity, which in prior DD versions, would not have been possible. This breaks the core questline. I will explain.

 

Problem: DD filter changes the behavior of when virginity is lost

Question: How is DD filter changing the behavior of when I am losing virginity?

• If sexlab plays a Animations.IsVaginal AND no Virgin Chastity device is present... example: If PlayerRef.IsEquipped(ChastityCageRender)... virginity is lost
• The check is done during the sexlab orgasm stage mod event
• It checks anal and oral too, giving some messaging, but only loss of vaginal can break the quest
• If the chastity device is not a Virgin one,  the player is expected to lose virginity, and the story is built around the idea that Nocturnal's belts are magical and protects in all cases, and other devices will protect only some of the time. The player is told this as they progress though the quest. Mods like DCL add to the fun since bandits can attack and take off those easy to remove basic belts (SLaV is as much about losing your virginity as it is keeping it)
  • side note: I did not have any choice to do this differently, without trying to build a very complex animation filter of my own. This was well before DD4.0 even, so please lets get past the talk of me dong unconventional things and dismissing it

When the DD hide is in play, I think the "Store" function may cause the lost virginity, although on the surface, at first I thought not. Correct me if I'm wrong. Either way it's somehow happening so if its not "Store" then its something else changing the behavior.

 

Another behavior change, effecting story - Device Hiding:

In SLaV, when heavy bondage is removed (by SLaV), Nocturnal always appears, out of the shadows (she's ghost-like), and removes the heavy bondage. This is better realism than stuff hiding, and you are not aware, and no message. In DCL, devices don't just come off, there is messaging, like "Your attacker takes the chastity belt off, puts it back on after, and takes away your key!" Removing devices as part of the DD Filter does not fit some cases for people's stories. Maybe Nocturnal should be appearing and doing it in advance etc.

 

This one is not a show stopper if a yoke, so far, but worth mentioning since could be for other mods, and I've not tested enough to be sure its ok for SLaV. For Chastity, my theory is that its the problem for the first issue above.

 

 

So let's ponder on solutions:

Note: I realize that you are auto-removing devices, in order to find an animation to play when one is not available. So if I said, could you give us the option in the API to skip the bondage hiding, we end up with no animation to play.

 

Every thing else in DD is great because we have loads of options to tailor to our mod's needs and story. StartValidDDAnimation needs options too. It's feature set is all about sexlab scenes, but since it changes the behavior of these scenes, for even mods not using DD, this needs to be handled carefully. Your feature set I think, is this:

 

• Filters for device-valid animations and auto-hides devices if needed to achieve this (I think those two can NOT be used separately?)
• Adds animations for 1 and 2 actor heavy bondage when appropriate
• Changes voice to gagged voice if wearing a gag
• Turns off the post-sexlab-scene-start filtering/performance impact (assuming the default behavior is DD Filter ON when not using this function)
• anything else?

Maybe to give options, offer parameters like these:

• A Bool for "use built in filter"
  • If False
    • the built in filter, including device hiding, is not used
    • a sslBaseAnimation[] Anims must be passed
    • Modder can use SelectValidDDAnimations, or the Sexlab one,  or do their own thing
  • If True
    • you get the very convenient built in filter (I've been enjoying the new experience of seeing device appropriate animations, its really nice)
    • you get auto hide devices as needed
    • you can optionally pass in include/suppress tags
    • A Bool parameter for using Heavy Bondage? (I'm not sure it can work well separately, but there is the MCM toggle)
      • True - ?
      • False - ?
• A Bool for using gagged voice (I have not thought of any reason I need this, just a suggestion for other mods, maybe one handling the voices already)
• In all cases, using this function Turns off the post-sexlab-scene-start filtering/performance impact (or is there ever a need to be able to turn that on?)

From a Slav perspective, I would need to opt out of the built in filter for many scenes, but I have some scenes that fit, if suppress tags work (note my outstanding problem report for that). When opting out, I could SelectValidDDAnimations first, see if I get any animation, then fall back to the default sexlab filter.

[Kimy]

@VirginMarie

 

/re: Question: How is DD filter changing the behavior of when I am losing virginity?

 

It depends on your devices. If you use "fake chastity" devices, StartValidDDAnimation() won't hide them, because they do not block access (permitVaginal/Anal = True). That's 100% the same behavior as if not using the filter at all.

 

If it's a regular device and you're hooking into OnOrgasm, the keyword-carrying device won't be present when this event fires and your code would treat the scene as if there is no chastity equipped. Which is probably NOT what you want.

Proposed solution: Make your code check for hidden belts using:

 

if StorageUtil.GetFormValue(libs.PlayerRef, "zadStoredBelt") != None

(don't fire the "lose virginity" event)

EndIf

 

/re: Another behavior change, effecting story - Device Hiding:

 

Shouldn't matter at all. The device hiding code does NOT trigger any DD device events and does not "unequip" the inventory device at any point. Your event code shouldn't trigger off this. If it does for whatever reason, also check for hidden devices, as above.

 

 

[VirginMarie]

33 minutes ago, Kimy said:

Proposed solution: Make your code check for hidden belts using:

 

if StorageUtil.GetFormValue(libs.PlayerRef, "zadStoredBelt") != None

(don't fire the "lose virginity" event)

EndIf

I'm trying to NOT use fake chastity. That's why it IS coming off with with Store function. I tested with non-fake. Are you proposing that even if it was taken off, the PC does not lose virginity? That's not what I want at all. Its far better to say the magical device protected, even though penetration happened, I mean at least the device is still there to do that.

 

Alternative is to use fake chastity, so it does not get hidden, and I already thought of that. I'd leave my check as it is now. But first I need to verify it never is hidden. And them I'm stuck using fake Chasity, not making use of your feature. 

 

Do you not see why I don't have a decent solution here? Or am I missing something?

33 minutes ago, Kimy said:

 

/re: Another behavior change, effecting story - Device Hiding:

 

Shouldn't matter at all. The device hiding code does NOT trigger any DD device events and does not "unequip" the inventory device at any point. Your event code shouldn't trigger off this. If it does for whatever reason, also check for hidden devices, as above.

My point was about the story. The visual. The removal of devices with no message, no awareness. Why did I just lose my virginity (case of a generic one)? It's easy to see the yoke come off, but actually very easy to miss that chastity came off, particularly in combat with a group sex scene and pile of bodies. 

 

 

Are you not reading what I type, just looking to figure out how to dismiss what I say, so you can get out of Filter hell? Well I'm in Filter hell too.

 

We need options. The option to have things hidden or NOT. The option to have the filter run or NOT.

 

Also currently I am not testing with device removal (the commented out code), as I continue to verify that it solves Stacked. Do you care about this, or has it been dismissed? Stacked happening about 30% of the time is fine in your books?

[Kimy]

@VirginMarie

 

I showed you a VERY easy solution to check for hidden devices while they are hidden, that you can add to your code to make sure virginity is taken away for the purposes of your mod only when needed. The code does NOT unequip the belt, it just makes it invisible for the scene. Which is NOT the same thing. As far as DD is concerned, the belt is NEVER taken off. Any imaginable problem you might have from checking for devices while they're hidden can be solved with the approach I showed you. Not sure who's not reading whose posts here, but I addressed both cases (fake chastity and regular devices in my reply). And yes, you changing your code to make the player not lose virginity if the belt is just visually hidden, is EXACTLY what I proposed. Is it ideal? Probably not. But it's not any more silly than playing a vaginal sex animation with a chastity belt locked on and characters happily shagging right through it, which is (if I am understanding it right) what was what your mod was doing all the time. At one point you will need to realize that you can't have the cake and eat it.

 

Other than that, StartValidDDAnimation() doesn't use the filter at all. I am pretty sure you either didn't read the part either, or just don't want to see it, because you're still dead set to push for that kill-switch I told you over and over already I am not going to give you back. This function IS your option not to use the filter, because it DISABLES it. There is no filter running when using that function. Read the code if you don't believe me. End of story. I gave you what you wanted. A way to bypass the filter so scenes no longer get altered or overriden. But yes. the "price" for this is that DD will make sure no nonsensical stuff is being played.

 

About the store functions: Yes, I am still interested in that. It's strange. These functions -should- have completed operation -before- calling StartSex() later on, in the same function. At least according to Papyrus language specs. If you want to explore that issue further, I am not keeping you. Try adding a slight delay between the store functions and StartSex() and tell me if that helps, because if your theory is correct, it will. If it does, I will add it to the code.

[VirginMarie]

29 minutes ago, Kimy said:

yes, you changing your code to make the player not lose virginity if the belt is just visually hidden, is EXACTLY what I proposed.

I will not do that. It's far worse. What I did was because I had no choice. Now you want to give me no choice and use a solution that is even worse.

 

29 minutes ago, Kimy said:

Other than that, StartValidDDAnimation() doesn't use the filter at all

When I say DD Filter , I would define it as selecting appropriate animations, adding bondage animations when needed, and at this point the hiding devices is included as part of that.

 

So using that definition, StartValidDDAnimation does exactly those 3 things. There is no way to opt out of those 3 things if you want or need to, correct?

 

You included those things outside of the sexlab scene, which is indeed something I suggested. This solved Stuck which is great. This made it faster which is great.  This does not change the feature's options, but solves some stability problems which is great. I've already confirmed using Trace, that your Logic function is indeed, never running past its check, and told you that I confirmed it. No misunderstanding here at all.

 

 

EDIT: I've sent you a PM to figure out path forward. May I suggest we discontinue this topic here, and do it there.

[indolu]

Forgive me if this is a stupid question, but why do you need DD at all? If you don't want to use the filter could you not just make a device that uses the same slot as DD and has the texture but none of the actual scripting behind it. The only problem I see is DD force equipping a device and replacing your pseudo-device which could be fixed if they added in a keyword system that looks at the slot they want if if there is something in that slot with that keyword, it doesn't equip. 

Again sorry if this is a stupid question, I don't really know much about the stuff behind the curtains of either mod.

 

EDIT: I just realized that you said you were continuing the conversation in PM's. You don't have to acknowledge this question.

[VirginMarie]

26 minutes ago, indolu said:

Forgive me if this is a stupid question, but why do you need DD at all? If you don't want to use the filter could you not just make a device that uses the same slot as DD and has the texture but none of the actual scripting behind it. The only problem I see is DD force equipping a device and replacing your pseudo-device which could be fixed if they added in a keyword system that looks at the slot they want if if there is something in that slot with that keyword, it doesn't equip. 

Again sorry if this is a stupid question, I don't really know much about the stuff behind the curtains of either mod.

 

EDIT: I just realized that you said you were continuing the conversation in PM's. You don't have to acknowledge this question.

A key reason to use DD, is that it takes care of all the manipulation of devices. I've created dozens of "Virgin Devices" that are based on DD. Would take hundreds of hours to make my own system to take care of that.

 

Even if I did spend the time, my mod would not be able to play friendly with other DD mods. This is very important. For example if a player is wearing a chastity device from another mod, you don't just replace it. And you might let it impact actions, effects, and outcomes in your own mod. It's called being DD aware.

[devil10188]

On 11/6/2020 at 9:37 AM, VirginMarie said:

Not pointless if the DD filter is causing Sexlab too much stress, being interrupted. This is what I believe but cannot prove.

 

Not pointless when the problems do not occur with no DD Filter. This I am sure about. Has always been the case.

 

I may be chiming in a bit late on this one, but this is empirically untrue. Stuck and stacked are sexlab issues since the original sexlab came out for the original skyrim. They have next to nothing to do with stress either - additional stress WILL make them worse, but stress does not cause them. The culprit is sexlab and some of its features. The absolute worst culprit is starting teleport, but it's not the only feature that causes it.
I can recreate stacked reliably in the third helgen keep fight using nothing but sexlab and defeat as the agressor on one of my allies, with almost no effort. Stuck takes some additional conditions, but is reproducible there as well in multi actor scenes.

[devil10188]

9 minutes ago, donttouchmethere said:

 

 

Are you staring your game with vanilla intro? o.o

With SL defeat there is no surprise that you have issues, but as long as no one is in bondage the DD filter wouldn't even effect the scene.

I'm not sure if you understand the issue here. DD filter doesn't effect normal sexlab scenes, it effects only scenes with actors in devices and only if those either prevent sex or want to call for specific animations for certain devices.

Normal sex scenes should work normal or you have issues before the DD filter even has a chance to interrupt.

I understand the issue perfectly - in fact, that's my whole point. Yes, that's a clean save with nothing but the two involved. This can occur WITHOUT the DD filter even installed. It's foolish to blame something that occurs without the filter even present on the filter.  The reason the actors stack in my instance is sexlab starting teleport. If the actor revives after you select an action but prior to the animation and the game tells them to do something else, they will - in the meantime, other actors cannot move until the actor is freed for the scene and teleported into the same location as the PC.
You can blame stacked actors animating in place on DD all you want - it won't fix the issues inherent in sexlab and Papyrus, which are the true root causes. It is entirely possible the DD filter adds to the issue, but it is not the only issue, and pretending it is won't get you anywhere.

[Kimy]

We've established beyond any reasonable doubt that the newest version of the DD filter does NOT contain any bugs causing any stacking/stuck issues. Among things because I implemented a wrapper function that COMPLETELY DISABLES it, and stacking issues STILL got reported. Also, because issues get reported in scenarios where the filter wasn't even doing anything and actors were wearing no devices. At this point, there are ZERO known or suspected bugs in the filter OR the wrapper, that could directly cause SexLab breakage.

 

We HAVE established that general load, including that caused by the DD filter, CAN break SexLab scenes. That is NOT a fault of the DD filter or the DD framework, it's a fault of SexLab not reacting well to load of any kind when running scenes, particularly scenes with multiple actors. These issues are WIDELY known and have been for a long time. Laying the sole blame for such breakage on ONE mod, when ANY could cause it, is both misleading and nonconstructive. If SexLab breaks due to ever-so-slightly increased engine load, it IS a SexLab issue, and I am tired of getting blamed and attacked for a problem in another mod. In the end, people are attacking me just because I insist on my mod doing nothing wrong, when based on everything we established, that is factually true.

 

At this point I do consider any further postings about alleged SexLab breakage caused by the DD filter just being there and doing its job to be off-topic. I will no longer react to it in any shape or fashion. Furthermore, if people think they have the right to ride continued personal attacks on me, just because they happen to disagree with my stance on this issue, I will put them on /ignore without further warning. If people find any ACTUAL bugs in the filter, they are still more than welcome to report them in a constructive and polite fashion.

 

This is the DD beta thread. Not the "Blame DD for using some engine resources" thread.

 

Thanks for understanding.

[devil10188]

1 hour ago, donttouchmethere said:

You still understand that it is only interesting if the actors are in DDs? The DD filter will have no effect on normal sexlab scenes. If they are glitched already on your game you would even see a difference.

You must be missing something.
I have no interest in interesting you.
I am merely pointing out to VirginMarie that the issues she is still experiencing occur outside of the DD framework.
As Kimy has stated above, the filter's impacts have been *clearly* minimised by work already done on the filter in the past few updates.
Any continued improvement Marie wants to make on the stacked issue, will require improvements to sexlab itself, because sexlab is the ultimate cause.
You WILL NEVER fully eliminate stacking as an issue without messing with the sexlab framework, whether devices are involved or not.

[OsmelMC]

@Kimy one of the SexLab issues users may be experiencing is related to the ActorChange function and for I know only DD and SLAA use that function.

 

I talk about this function because on the SLAA development @GenioMaestro find the solution for most of the ActorChange issues without modify the function in self. He just add few more steps after the ActorChange is used and got very good results for I know.

[Kimy]

23 minutes ago, osmelmc said:

@Kimy one of the SexLab issues users may be experiencing is related to the ActorChange function and for I know only DD and SLAA use that function.

 

I talk about this function because on the SLAA development @GenioMaestro find the solution for most of the ActorChange issues without modify the function in self. He just add few more steps after the ActorChange is used and got very good results for I know.

Sounds promising! It could help making the filter better when it's actually doing something (otherwise no call to ActorChange() will be made). What exact steps do they recommend adding?

[OsmelMC]

58 minutes ago, Kimy said:

Sounds promising! It could help making the filter better when it's actually doing something (otherwise no call to ActorChange() will be made). What exact steps do they recommend adding?

This is what I resume from his script adapted to yours:

	If NeedsRebuild
		Controller.ChangeActors(actors)
		Controller.UpdateAdjustKey()
	;	Controller.SetAnimations(anims); hi set the animations after ChangeActors but in this case probably better ignore it.
		Controller.SetAnimation()
		Controller.GoToStage(1)
	Else    
		Controller.RealignActors()
	EndIf

 

[hungvipbcsok]

On 11/8/2020 at 2:09 AM, Ryu Gabriev said:

cosio?

 

[serranna]

I do not have that Cosio option in my bodyslide and I have the same clipping issues with the elbowbinder. What mod is responsible for that option?

[zarantha]

Is there a workaround for the strict rope armbinder using human hands for beast and custom races?

Or is this something BRRF will handle in the future?

 

 

 

[OsmelMC]

6 hours ago, zarantha said:

Is there a workaround for the strict rope armbinder using human hands for beast and custom races?

Or is this something BRRF will handle in the future?

 

 

 

I see this problem before on other meshes and usually set the body Node (in this case the heads Node) as first on the Node index using the NifSkope help with the issue. But you can also force the texture on the ESP file

[Skullered]

9 hours ago, zarantha said:

Is there a workaround for the strict rope armbinder using human hands for beast and custom races?

Or is this something BRRF will handle in the future?

 

2 hours ago, osmelmc said:

I see this problem before on other meshes and usually set the body Node (in this case the heads Node) as first on the Node index using the NifSkope help with the issue. But you can also force the texture on the ESP file

I just tried moving the Hands node to index 1, with no result, tried reordered blocks sanitize, with no result, tried matching non-vertex/face/weight values from SkinPartition, SkinData and DismemberSkinInstance and ShaderTextureSet from vanilla FemaleHands, with no result.

 

Honestly, I haven't the faintest clue on how the game assigns racial texture sets to armors, every time I've had this problem I've just imported vanilla meshes and worked on it from there.

I've tried googling it, but that hasn't been very helpful. Information about this seems rather obscure.

 

 

I'm tempted to just force Argonian and Khajiit texture sets with BRRF, but that doesn't seem like a very elegant solution, since this affects any race, not just beast races.

 

 

EDIT: For now, until said "elegant solution" is found, I've attached a version of BRRF that uses the "force texture sets" method, which only supports Argonians and Khajiit.

 

-Fixed beast races having human hands with the "Strict Rope Armbinder"

 

Devious Devices - BRRF.esp

[OsmelMC]

1 hour ago, Skullered said:

 

I'm tempted to just force Argonian and Khajiit texture sets with BRRF, but that doesn't seem like a very elegant solution, since this affects any race, not just beast races.

Until now force the texture is the most effective method. Because the Node one need to be precise execute a even then is not warrantied. 

 

What I do is use the Ctrl+Up on the NiTriShape of the body until his Index be the next to the last bone for example if the last NiNode for the Bones have index 40 the NiTriShape for the hand should be Index 41.

 

After that in NifSkope I always go to Spells menu and use the Sanitize options to "Reorder Link Arrays" and "Reorder Blocks"

 

Once Sanitized I have to check the index again and probably do all again even few times in some cases until be fine.

 

My personal advise if you try this is to do it on the BodySlide Meshes and that way avoid manually modify all the Meshes

[Code Serpent]

1 hour ago, Skullered said:

I'm tempted to just force Argonian and Khajiit texture sets with BRRF, but that doesn't seem like a very elegant solution, since this affects any race, not just beast races.

You could just make additional armoraddons for Argonian and Khajiit texture sets and add those to the armor. This is how the game assigns textures to naked bodies. Look up "NakedHands" in the armoraddons tab of the Creation kit.