Jump to content

Devious Devices Framework Development/Beta


Recommended Posts

6 minutes ago, VirginMarie said:

SAME scene as above, F/F scene, with the boob yoke on, but WITHOUT the belt or plug

I used a chastity belt but with permit on both holes. If you need the test with that magical belt off... well, I cant think of any way to remove the thing atm

 

Try 6:

[Virgin] Sleep with Cassia call to Sexlab. # of anims: 1

[Zad]: Animation should not be replaced. Done.

 

No flags in log. All holes were open. Boob Yoke equipped

Yoke not hidden

Cassia equips a strapon which is correct and has been happening in all the previous tests that use this one animation.

Ran flawless

Log8.log

Link to comment

@Kimy

Log has 4 tries. Testing with Bound Animations OFF

 

Tries 1,2,3

Bound Animations OFF / Wearing Boob Yoke

No flags in log. Various # of holes open

[Zad]: Animation should not be replaced. Done.

Yoke NOT hidden

No Visual Glitch from Delay. No Stuck

 

Try 4

Bound Animations OFF / No Yoke

[11/02/2020 - 12:35:56PM] [Zad]: PermitAnal TRUE
[11/02/2020 - 12:35:56PM] [Zad]: PermitVaginal TRUE
[11/02/2020 - 12:35:56PM] [Zad]: PermitBoobs TRUE
[11/02/2020 - 12:35:56PM] [Zad]: PermitOral TRUE
[11/02/2020 - 12:35:56PM] [Zad]: NoBindings TRUE
[11/02/2020 - 12:35:56PM] [Zad]: IsCreatureAnim False
[11/02/2020 - 12:35:56PM] [Zad]: HasBoundActors False
[11/02/2020 - 12:35:56PM] [Zad]: No sex-act-restricted actors present in this sex scene.

No Visual Glitch from Delay. No Stuck

 

So Bound Animations OFF, is no longer doing anything. Same result as running with it ON.

Log9.log

Link to comment

@Kimy

 

Erotic Arts randomly plays 3, 4, or 5 actors. Always the player, a male, and the rest female. I updated to use SelectValidDDAnimations.

;.......... Priestesses erotic arts, do the lovin  ;testing
Function VirginPriestessesEroticArts()
	VirginEnablePriestesses.SetValue(49)
	VirginWaitBusy()
	Hamal.EvaluatePackage()
	If PlayerRef.GetDistance(Senna) > 1000
		Senna.MoveTo(PlayerRef)
		Senna.Enable()
	EndIf
	If PlayerRef.GetDistance(Anwen) > 1000
		Anwen.MoveTo(PlayerRef)
		Anwen.Enable()
	EndIf
	If PlayerRef.GetDistance(Bodyguard) > 1000
		Bodyguard.MoveTo(PlayerRef)
		Bodyguard.Enable()
	EndIf
	VirginInitSceneStart()	
	int Random = Utility.RandomInt(1,3)
	If Random == 1
		LoveActor = new actor[5]
		LoveActor[0] = PlayerRef
		LoveActor[1] = Senna
		LoveActor[2] = Anwen
		LoveActor[3] = Hamal
		LoveActor[4] = Bodyguard
		LoveActor = SexLab.SortActors(LoveActor)
		Anims = libs.SelectValidDDAnimations(LoveActor, 5)
	ElseIf Random == 2
		LoveActor = new actor[4]
		LoveActor[0] = PlayerRef
		LoveActor[1] = Hamal
		LoveActor[2] = Anwen
		LoveActor[3] = Bodyguard
		LoveActor = SexLab.SortActors(LoveActor)
		Anims = libs.SelectValidDDAnimations(LoveActor, 4)
	ElseIf Random == 3
		LoveActor = new actor[3]
		LoveActor[0] = PlayerRef
		LoveActor[1] = Hamal
		LoveActor[2] = Bodyguard
		LoveActor = SexLab.SortActors(LoveActor)
		Anims = libs.SelectValidDDAnimations(LoveActor, 3)
	EndIf
	Debug.Notification("TESTING: # of anims found: " + Anims.Length)  ;testing
	Debug.Trace("[Virgin] Erotic Arts call to Sexlab. # of anims: " + Anims.Length)
	RegisterforModEvent("HookAnimationend_Hamal", "VirginHamalDone")	
	VirginSLStartTimeout()
	SexLab.StartSex(LoveActor, Anims, allowBed = false, hook = "Hamal")
EndFunction

		Event VirginHamalDone(int threadID, bool hasPlayer)
			UnregisterForModEvent("HookAnimationend_Hamal")
			VirginLoveCollar(Hamal)
			VirginPriestesses.SetStage(10)
		EndEvent

In this test, first 4 tries are with all but boobs blocked. Last 2 nothing blocked. No heavy bondage tried yet.

 

Try 1
[11/02/2020 - 03:42:52PM] [Zad]: Selecting SexLab animations with number of actors: 3
[11/02/2020 - 03:42:52PM] [Virgin] Erotic Arts call to Sexlab. # of anims: 2
[11/02/2020 - 03:42:56PM] [Zad]: PermitAnal False
[11/02/2020 - 03:42:56PM] [Zad]: PermitVaginal False
[11/02/2020 - 03:42:56PM] [Zad]: PermitBoobs TRUE
[11/02/2020 - 03:42:56PM] [Zad]: PermitOral False
[11/02/2020 - 03:42:56PM] [Zad]: NoBindings TRUE
[11/02/2020 - 03:42:56PM] [Zad]: Original animation (RohZima Girl Sleeping MMF) does not conflict. Done.
Flawless. no delay/reset

 

Try 2
[11/02/2020 - 03:43:43PM] [Zad]: Selecting SexLab animations with number of actors: 4
[11/02/2020 - 03:43:43PM] [Virgin] Erotic Arts call to Sexlab. # of anims: 1
[11/02/2020 - 03:43:48PM] [Zad]: PermitAnal False
[11/02/2020 - 03:43:48PM] [Zad]: PermitVaginal False
[11/02/2020 - 03:43:48PM] [Zad]: PermitBoobs TRUE
[11/02/2020 - 03:43:48PM] [Zad]: PermitOral False
[11/02/2020 - 03:43:48PM] [Zad]: NoBindings TRUE
[11/02/2020 - 03:43:48PM] [Zad]: HasBoundActors False
[11/02/2020 - 03:43:48PM] [Zad]: Original animation (Mojito FFFM foot orgy) does not conflict. Done.
no delay/reset. Stacked actors. No animation. NOT stuck

 

Try 3
[11/02/2020 - 03:45:34PM] [Zad]: Selecting SexLab animations with number of actors: 5
[11/02/2020 - 03:45:34PM] [Virgin] Erotic Arts call to Sexlab. # of anims: 0
[11/02/2020 - 03:45:40PM] [Zad]: PermitAnal False
[11/02/2020 - 03:45:40PM] [Zad]: PermitVaginal False
[11/02/2020 - 03:45:40PM] [Zad]: PermitBoobs TRUE
[11/02/2020 - 03:45:40PM] [Zad]: PermitOral False
[11/02/2020 - 03:45:40PM] [Zad]: NoBindings TRUE
[11/02/2020 - 03:45:40PM] [Zad]: Requesting actor change to 4 actors.
[11/02/2020 - 03:45:40PM] [Zad]: Solo [0]: Priestesses Bodyguard
delay/reset/Transition visual. Stacked actors. animating. STUCK

 

Try 4
[11/02/2020 - 03:47:29PM] [Zad]: Selecting SexLab animations with number of actors: 3
[11/02/2020 - 03:47:29PM] [Virgin] Erotic Arts call to Sexlab. # of anims: 2
[11/02/2020 - 03:47:34PM] [Zad]: PermitAnal False
[11/02/2020 - 03:47:34PM] [Zad]: PermitVaginal False
[11/02/2020 - 03:47:34PM] [Zad]: PermitBoobs TRUE
[11/02/2020 - 03:47:34PM] [Zad]: PermitOral False
[11/02/2020 - 03:47:34PM] [Zad]: NoBindings TRUE
[11/02/2020 - 03:47:34PM] [Zad]: Original animation (Mojito FFF foot worship triangle) does not conflict. Done.
no delay/reset. Stacked actors. No animation. NOT stuck

 

Try 5
[11/02/2020 - 03:48:48PM] [Zad]: Selecting SexLab animations with number of actors: 3
[11/02/2020 - 03:48:48PM] [Virgin] Erotic Arts call to Sexlab. # of anims: 49
[11/02/2020 - 03:48:52PM] [Zad]: PermitAnal TRUE
[11/02/2020 - 03:48:52PM] [Zad]: PermitVaginal TRUE
[11/02/2020 - 03:48:52PM] [Zad]: PermitBoobs TRUE
[11/02/2020 - 03:48:52PM] [Zad]: PermitOral TRUE
[11/02/2020 - 03:48:52PM] [Zad]: NoBindings TRUE
[11/02/2020 - 03:48:52PM] [Zad]: No sex-act-restricted actors present in this sex scene.
Flawless. no delay/reset

 

Try 6
[11/02/2020 - 03:50:00PM] [Zad]: Selecting SexLab animations with number of actors: 5
[11/02/2020 - 03:50:00PM] [Virgin] Erotic Arts call to Sexlab. # of anims: 6
[11/02/2020 - 03:50:06PM] [Zad]: PermitAnal TRUE
[11/02/2020 - 03:50:06PM] [Zad]: PermitVaginal TRUE
[11/02/2020 - 03:50:06PM] [Zad]: PermitBoobs TRUE
[11/02/2020 - 03:50:06PM] [Zad]: PermitOral TRUE
[11/02/2020 - 03:50:06PM] [Zad]: NoBindings TRUE
[11/02/2020 - 03:50:06PM] [Zad]: No sex-act-restricted actors present in this sex scene.
Flawless. no delay/reset

 

I had tried a whole lot more before capturing a log. Knowing what I saw, I just made sure to log enough to get each problem case I've seen. I've seen each problem multiple times, its easy to recreate.

 

Summary of problems:

  1. Stacked actors that are NOT animating. When this happens they are not stuck but look to be, and the scene ends. By stacked I mean they are all standing in the same position and orientation... their starting position.
  2. Staked actors that ARE animating, but the scene IS STUCK until spacebar advance
  3. Delay/reset/Transition visual (the "visual glitch")

About the Delay/reset/Transition visual:

We consider this intended, or more like, unavoidable. I would live with it for this scene assuming no other problems coming with it. Where I say this is a show stopper is for chaotic scenes like the Love Shout. If I had the "event level" option to turn off the filter, like I've proposed, I'd use that for Love Shout, and maybe some other scenes, but I'd not use it for a scene like this one. I'd likely not make any "magical" non-blocking Virgin Devices either. 

 

 

More thoughts on the Event Level proposal:

Perhaps DD provides both SelectValidDDAnimations, and a new wrapper called DDStartSex. You could use SelectValidDDAnimations as normal, and not effect if the filter is used later on or not. Then if you want the filter, you use DDStartSex. Maybe a parameter for bound animations.  If you don't want it, you use Sexlab directly like normal and sexlab behaves like normal, not altered at all by DD, including bound animations. MAYBE you would still hide the heavy bondage. Maybe the DDStartSex would also allow DD to intervene earlier, without the need to use sexlab's modevents, and avoid the "visual glitch".

 

In this way, its "opt in", not "opt out" for the mod. There does not need to be an MCM toggle for any of it. No mods would be effected.

 

IMO, alteration of a mod's behavior, particularly a framework mod like Sexlab, caused by another mod, should be optional, or not done at all. And it should be opt in, not opt out. Users or moders should never end up unwittingly getting something they don't even understand or expect, or lose backward compatibility.  So if you DID leave the toggles, they should be OFF by default. We should get unaltered sexlab behavior by default, otherwise you are essentially doing the same thing as Sexlab Separate Orgasm, and Sexlab Utility whatever its called. You are not overwriting sexlab's source code like they do, but you ARE changing behavior, and it breaks my mod in each case (or it would if I were not around to update it).

 

 

Link to comment

@Kimy

 

"Nocturnal Teases" randomly requests Sexlab to play specific animation, non-penetrating tags. Always FF. I updated to use SelectValidDDAnimations.

;.......... Nocturnal Teases, do the lovin  ;testing
Function VirginNocturnalTease() ;testing
	int Random = Utility.RandomInt(1,4)
	If Random == 1
		Lovin = "Cunnilingus, Tribadism, FootJob"
	ElseIf Random == 2
		Lovin = "Lesbian, FF, 69, Mouth"
	ElseIf Random == 3
		Lovin = "Licking, Feet, Kissing"
	ElseIf Random == 4
		Lovin = "Spanking, Foreplay, 69"
	EndIf
	LoveActor = new actor[2]
	LoveActor[0] = PlayerRef
	LoveActor[1] = Nocturnal
	LoveActor = SexLab.SortActors(LoveActor)
	Anims = libs.SelectValidDDAnimations(LoveActor, 2, false, Lovin)  ;testing
	Debug.Notification("TESTING: # of anims found: " + Anims.Length)  ;testing
	Debug.Trace("[Virgin] Nocturnal Teases call to Sexlab. # of anims: " + Anims.Length)
	RegisterforModEvent("HookAnimationend_Nocturnal", "VirginNocturnalDone")
	VirginSLStartTimeout()
	SexLab.StartSex(LoveActor, Anims, allowBed = false, hook = "Nocturnal")
EndFunction

		Event VirginNocturnalDone(int threadID, bool hasPlayer)
			UnregisterForModEvent("HookAnimationend_Nocturnal")
			VirginInitSceneEnd()
		EndEvent

Try 1
[11/02/2020 - 09:07:42PM] [Zad]: Selecting SexLab animations with tag string: Spanking, Foreplay, 69
[11/02/2020 - 09:07:42PM] [Zad]: Selecting SexLab animations with suppress string: Vaginal,Anal,Oral,Blowjob,Yoke,Armbinder
[11/02/2020 - 09:07:42PM] [Virgin] Nocturnal Teases call to Sexlab. # of anims: 0
[11/02/2020 - 09:07:47PM] [Zad]: PermitAnal False
[11/02/2020 - 09:07:47PM] [Zad]: PermitVaginal False
[11/02/2020 - 09:07:47PM] [Zad]: PermitBoobs TRUE
[11/02/2020 - 09:07:47PM] [Zad]: PermitOral False
[11/02/2020 - 09:07:47PM] [Zad]: NoBindings TRUE
[11/02/2020 - 09:07:47PM] [Zad]: Overriding animations.
played flawless. No Delay/restart.

 

Try 2
[11/02/2020 - 09:10:29PM] [Zad]: Selecting SexLab animations with tag string: Spanking, Foreplay, 69
[11/02/2020 - 09:10:29PM] [Zad]: Selecting SexLab animations with suppress string: Oral,Blowjob,Yoke,Armbinder
[11/02/2020 - 09:10:29PM] [Virgin] Nocturnal Teases call to Sexlab. # of anims: 0
[11/02/2020 - 09:10:35PM] [Zad]: PermitAnal TRUE
[11/02/2020 - 09:10:35PM] [Zad]: PermitVaginal TRUE
[11/02/2020 - 09:10:35PM] [Zad]: PermitBoobs TRUE
[11/02/2020 - 09:10:35PM] [Zad]: PermitOral False
[11/02/2020 - 09:10:35PM] [Zad]: NoBindings TRUE
[11/02/2020 - 09:10:35PM] [Zad]: Original animation (Leito Lesbian Double Dildo 2) does not conflict. Done.
played flawless. No Delay/restart. But not acceptable animation for this scene

 

Try 3
[11/02/2020 - 09:14:27PM] [Zad]: Actor(s) are bound. Trying to set up bound animation.
[11/02/2020 - 09:14:27PM] [Virgin] Nocturnal Teases call to Sexlab. # of anims: 1
[11/02/2020 - 09:14:31PM] [Zad]: Animation should not be replaced. Done.
Bound animations played flawless. No Delay/restart

 

Try 4
[11/02/2020 - 09:15:43PM] [Zad]: Actor(s) are bound. Trying to set up bound animation.
[11/02/2020 - 09:15:43PM] [Virgin] Nocturnal Teases call to Sexlab. # of anims: 1
[11/02/2020 - 09:15:47PM] [Zad]: Animation should not be replaced. Done.
Bound animations played flawless. No Delay/restart

 

Try 5
[11/02/2020 - 09:17:19PM] [Zad]: Actor(s) are bound. Trying to set up bound animation.
[11/02/2020 - 09:17:19PM] [Virgin] Nocturnal Teases call to Sexlab. # of anims: 1
[11/02/2020 - 09:17:23PM] [Zad]: Animation should not be replaced. Done.
Bound animations played flawless, however Bound Animations was set OFF. Yoke was not hidden. No Delay/restart

 

 

This was a very clean run. I've tried 4X this and no problems beyond the 2 below. Very nice that there was no need for the Delay/restart stuff. Would that be the case if not using SelectValidDDAnimations?

 

Problems:

  1. Try 2 requests specific non-penetrating animations, but we get penetration. From what I can tell, the filter will resort to finding animations for various reasons and will go outside of the requested tags if needed. Not a bug. But this is hard NO for this scene. The story for SLaV is that Nocturnal wants the player to keep their virginity, therefore Nocturnal would never, willingly, take the player's virginity. That includes oral and anal virginity. This is a good example, giving another reason, why a mod like SLaV must have the option to NOT use the filter.
  2. Try 5 - a case of Bound Animation toggle having no effect

Also note, it seems odd that SelectValidDDAnimations is returning 0 animations found in Try 2.

Log11.log

Link to comment
6 hours ago, VirginMarie said:

This is a good example, giving another reason, why a mod like SLaV must have the option to NOT use the filter.

SexLab have the option to don't use the filter and force the specific Animations you want. Just nobody use it.

 

The function is called SetForcedAnimations() and is used instead of the function SetAnimations()

 

In case you be asking how use it. You can as example copy the scripts from inside the StartSex() function in the SexlaFramework.psc and change the 

 

Thread.SetAnimations(Anims)

 

For

 

Thread.SetForcedAnimations(Anims)

 

 

 

Link to comment
6 hours ago, VirginMarie said:

This is a good example, giving another reason, why a mod like SLaV must have the option to NOT use the filter.

Actually, this is good example of not using framework properly. Change

Anims = libs.SelectValidDDAnimations(LoveActor, 2, false, Lovin)

to something like this:

 

Anims = libs.SelectValidDDAnimations(LoveActor, 2, false, Lovin, "Vaginal, Oral, Anal")

Basically, in the last parameter (SuppressTags) you staff all the tags that aren't suitable right now. Not using it and complaining about malfunctioning filter... Considering that filter didn't actually use bound animation in this case and used vanilla one, with SL vanilla selector...

Honestly, if you want some filter functionality - just describe it clearly, and provide solid arguments - and it it can be done, it will. Saying "filter has bugs so it must be disabled" is thinking backwards - filter has bugs BECAUSE it was always disabled - so nobody was aware of them and so they weren't fixed. Now that option isn't there anymore - it will start shaping up.

 

P.S. On that note, @Kimy - I guess, library version of filter needs some way to work with suppresstags in case bound anim is actually needed - so that if there are provided "Vaginal, Oral, Anal" for example, it will set permitVaginal=false and so on. Either that, or adding permit* as parameters for function.

Link to comment
12 hours ago, VirginMarie said:

@Kimy

 

"Nocturnal Teases" randomly requests Sexlab to play specific animation, non-penetrating tags. Always FF. I updated to use SelectValidDDAnimations.


;.......... Nocturnal Teases, do the lovin  ;testing
Function VirginNocturnalTease() ;testing
	int Random = Utility.RandomInt(1,4)
	If Random == 1
		Lovin = "Cunnilingus, Tribadism, FootJob"
	ElseIf Random == 2
		Lovin = "Lesbian, FF, 69, Mouth"
	ElseIf Random == 3
		Lovin = "Licking, Feet, Kissing"
	ElseIf Random == 4
		Lovin = "Spanking, Foreplay, 69"
	EndIf
	LoveActor = new actor[2]
	LoveActor[0] = PlayerRef
	LoveActor[1] = Nocturnal
	LoveActor = SexLab.SortActors(LoveActor)
	Anims = libs.SelectValidDDAnimations(LoveActor, 2, false, Lovin)  ;testing
	Debug.Notification("TESTING: # of anims found: " + Anims.Length)  ;testing
	Debug.Trace("[Virgin] Nocturnal Teases call to Sexlab. # of anims: " + Anims.Length)
	RegisterforModEvent("HookAnimationend_Nocturnal", "VirginNocturnalDone")
	VirginSLStartTimeout()
	SexLab.StartSex(LoveActor, Anims, allowBed = false, hook = "Nocturnal")
EndFunction

		Event VirginNocturnalDone(int threadID, bool hasPlayer)
			UnregisterForModEvent("HookAnimationend_Nocturnal")
			VirginInitSceneEnd()
		EndEvent

Try 1
[11/02/2020 - 09:07:42PM] [Zad]: Selecting SexLab animations with tag string: Spanking, Foreplay, 69
[11/02/2020 - 09:07:42PM] [Zad]: Selecting SexLab animations with suppress string: Vaginal,Anal,Oral,Blowjob,Yoke,Armbinder
[11/02/2020 - 09:07:42PM] [Virgin] Nocturnal Teases call to Sexlab. # of anims: 0
[11/02/2020 - 09:07:47PM] [Zad]: PermitAnal False
[11/02/2020 - 09:07:47PM] [Zad]: PermitVaginal False
[11/02/2020 - 09:07:47PM] [Zad]: PermitBoobs TRUE
[11/02/2020 - 09:07:47PM] [Zad]: PermitOral False
[11/02/2020 - 09:07:47PM] [Zad]: NoBindings TRUE
[11/02/2020 - 09:07:47PM] [Zad]: Overriding animations.
played flawless. No Delay/restart.

 

Try 2
[11/02/2020 - 09:10:29PM] [Zad]: Selecting SexLab animations with tag string: Spanking, Foreplay, 69
[11/02/2020 - 09:10:29PM] [Zad]: Selecting SexLab animations with suppress string: Oral,Blowjob,Yoke,Armbinder
[11/02/2020 - 09:10:29PM] [Virgin] Nocturnal Teases call to Sexlab. # of anims: 0
[11/02/2020 - 09:10:35PM] [Zad]: PermitAnal TRUE
[11/02/2020 - 09:10:35PM] [Zad]: PermitVaginal TRUE
[11/02/2020 - 09:10:35PM] [Zad]: PermitBoobs TRUE
[11/02/2020 - 09:10:35PM] [Zad]: PermitOral False
[11/02/2020 - 09:10:35PM] [Zad]: NoBindings TRUE
[11/02/2020 - 09:10:35PM] [Zad]: Original animation (Leito Lesbian Double Dildo 2) does not conflict. Done.
played flawless. No Delay/restart. But not acceptable animation for this scene

 

Try 3
[11/02/2020 - 09:14:27PM] [Zad]: Actor(s) are bound. Trying to set up bound animation.
[11/02/2020 - 09:14:27PM] [Virgin] Nocturnal Teases call to Sexlab. # of anims: 1
[11/02/2020 - 09:14:31PM] [Zad]: Animation should not be replaced. Done.
Bound animations played flawless. No Delay/restart

 

Try 4
[11/02/2020 - 09:15:43PM] [Zad]: Actor(s) are bound. Trying to set up bound animation.
[11/02/2020 - 09:15:43PM] [Virgin] Nocturnal Teases call to Sexlab. # of anims: 1
[11/02/2020 - 09:15:47PM] [Zad]: Animation should not be replaced. Done.
Bound animations played flawless. No Delay/restart

 

Try 5
[11/02/2020 - 09:17:19PM] [Zad]: Actor(s) are bound. Trying to set up bound animation.
[11/02/2020 - 09:17:19PM] [Virgin] Nocturnal Teases call to Sexlab. # of anims: 1
[11/02/2020 - 09:17:23PM] [Zad]: Animation should not be replaced. Done.
Bound animations played flawless, however Bound Animations was set OFF. Yoke was not hidden. No Delay/restart

 

 

This was a very clean run. I've tried 4X this and no problems beyond the 2 below. Very nice that there was no need for the Delay/restart stuff. Would that be the case if not using SelectValidDDAnimations?

 

Problems:

  1. Try 2 requests specific non-penetrating animations, but we get penetration. From what I can tell, the filter will resort to finding animations for various reasons and will go outside of the requested tags if needed. Not a bug. But this is hard NO for this scene. The story for SLaV is that Nocturnal wants the player to keep their virginity, therefore Nocturnal would never, willingly, take the player's virginity. That includes oral and anal virginity. This is a good example, giving another reason, why a mod like SLaV must have the option to NOT use the filter.
  2. Try 5 - a case of Bound Animation toggle having no effect

Also note, it seems odd that SelectValidDDAnimations is returning 0 animations found in Try 2.

 

Try 2 did not pass vaginal in the suppress tag line. If you want to prevent that, you will need to add that as a suppress tag. As others said, it's not the fault of my filter, it's because of the incorrect query passed to the API.

 

SL will consider ANY animation a match if it fits just ONE tag given, UNLESS you add requireall to the function parameters.

 

/re Try 5: The filter will NOT hide the restraints if you use SelectValidDDAnimation() and the function finds a valid one. In other words: SelectValidDDAnimation() ignores the "Use Bound Animations" setting, because it assumes that whoever used the function -wants- a fitting DD animation. Technically, this function doesn't even pass through the actual filter (which is performed in the Logic() function). It's therefore not a bug. I might need to clarify this in the DD MCM.

Link to comment
6 hours ago, DeWired said:

Actually, this is good example of not using framework properly. Change


Anims = libs.SelectValidDDAnimations(LoveActor, 2, false, Lovin)

to something like this:

I will try it, and test.

6 hours ago, DeWired said:

filter has bugs BECAUSE it was always disabled - so nobody was aware of them and so they weren't fixed. Now that option isn't there anymore - it will start shaping up

You are right about that. Its a chicken and egg problem though. It was always disabled because it has bugs, but not JUST bugs, it has "fit" and usability issues too that are bigger and don't go away by removing bugs. So people look at it thinking there is no path forward and so not worth spending the time to test and report. You need to want and believe in the feature to put time into it, particularly when not being paid :)

 

If you are saying the idea here is to remove the MCM option to opt out... to force people to test and report... well I think that is a very bad idea and could create the opposite of what is desired. However if something like my event level proposal was in place, opt in, not opt out, and tested, ready for primetime, then there is a bright future. I wish there were more DD content mod authors participating in this beta to collaborate with and test too, because the needs of SLaV alone is not enough to consider how a feature should be improved.

 

With me, your devious plan to get some testing done by taking the toggle away has worked, for beta though. Primetime would be too late. I'm here testing like crazy, desperately trying to save SLaV from being very incompatible with DD5. I'm willing to continue and work with the DD team, but there is a limit. I need to want the feature. If the end result is still going to be that my mod is incompatible, I will use my time to look for other options. I've actually seriously considered in the past, not using sexlab for any of my scenes. SLaV already does half of it's animation scenes on it's own. I removed any dependency on ZAP 2 years ago. That was a big job but worth it. Removing DD dependency is not an option due to the need to play nice with other DD mods. Another option is to just declare it game over and abandon.

 

If DD5 is going to release with no animation toggle, then for SLaV to be compatible, we likely need something like the event level feature I've proposed. AND... the testing and bug fixing has just started, is BIG, and must be of a quality for primetime. And the plan should be not just for SLaV but for other mods too. We should seek out more testers too. Can anyone think of some active DD content authors to invite here and test who are not already here?

Link to comment
1 hour ago, Kimy said:

Try 2 did not pass vaginal in the suppress tag line. If you want to prevent that, you will need to add that as a suppress tag. As others said, it's not the fault of my filter, it's because of the incorrect query passed to the API.

 

SL will consider ANY animation a match if it fits just ONE tag given, UNLESS you add requireall to the function parameters.

I will try it out. So this line of code would get me only animations that do not penetrate any hole, regards of what is blocked or permitted, including when wearing heavy bondage? 

Anims = libs.SelectValidDDAnimations(LoveActor, 2, false, none, "Vaginal, Oral, Anal")
1 hour ago, Kimy said:

 

/re Try 5: The filter will NOT hide the restraints if you use SelectValidDDAnimation() and the function finds a valid one. In other words: SelectValidDDAnimation() ignores the "Use Bound Animations" setting, because it assumes that whoever used the function -wants- a fitting DD animation. Technically, this function doesn't even pass through the actual filter (which is performed in the Logic() function). It's therefore not a bug. I might need to clarify this in the DD MCM.

I'm good with that functionality for this scene. It ran flawlessly it was just not my expectation. Like you say the way the MCM is worded would be off.

 

More testing needed with other scenes.

Link to comment

@Kimy

Do you wish for more test results? Or should I wait for a next release?

 

I've got the Love Shout and some other scenes ready to test, but seems like I should wait for other outstanding problems reported to be fixed etc. I have seen that the Love Shout has the stacked and stuck issues too, as could be expected.

 

I'd also like to know your thoughts on the event level proposal, so I can plan my time accordingly.

Link to comment

@VirginMarie

 

I am not even entirely sure what the 'event level' proposal entails. A flag passed to SelecValidDDanimations() that does...what exactly? Opt-In, as in it's off by default? If I switch the filter off by default and enable it only when a parameter passed to this function asks for it, it's basically defeating the very purpose of the filter. The idea of the filter is to make sex animations called by mods NOT aware of DD (and thus not using its API) fit to the set of devices worn by the actors and respect blocked interactions etc. If I disable it by default unless one of the handful of DD mods actually using the provided API for that explicitly requests it, I might just delete the filter from the framework entirely.

 

Also, looking at your latest test results, I kinda was under the impression that the filter now works correctly? Which part of DD5 is still incompatible with SLAV now? And why? You can make all your "fake chastity" devices work with DD5 using the permitX keywords now, can't you? And the filter, from what I saw in your reports, no longer gets stuck anywhere. I am not sure I understand what the problem at this point even is?

 

I have the feeling you're angry at me. At least the part where you threaten to pack your stuff and leave is telling me so, among things. But you have to admit that you have been designing parts of your features in glaring contrast to what DD is designed and meant to do. Restraints that don't restrain. Chastity devices that don't block intercourse. Features that you were well aware aren't working at all, unless under the assumption that DD doesn't do what it's meant to do (which is making devices feel "real"). And you solely relied on being able to (make users) disable a core feature of the framework that makes it able to do what it's meant to do, not only for your own but every other DD mod to make it happen. I am not sure laying all the blame on me now is 100% fair. I want to work with you to get your mod running with DD5, and in fact spent much of the past few days working on just that. But as with all compromises, it takes two, and the willingness to meet halfway. And maybe there are some edge cases in your mod you can adapt to work better with DD5 too, without having to rewrite the entire thing (nobody wants that), or forcing me to write the framework around one single mod using it in very unconventional ways. So far I have addressed every single problem you told me about. You can still make fake restraints. The filter is getting optimized every day, and from what I can tell, doesn't glitch out anymore. If there are other issues, by all means tell me about them and I will see what I can do. Just preferably without disabling or crippling core DD features.

 

While it was not my intention to force people finally reporting bugs in a core feature of the framework they're using (what a shocking idea is it to report software bugs anyway?), I can't honestly say this side-effect is unwelcome. I had no idea that modders basically forced users to switch said core feature off instead of telling me what's not working right, so I could fix it. If you were in my shoes, and I discovered some feature in your mod that's not working correctly, would you rather me tell you about it, or me just advising your users to open your mod in CK and go wild with the "Delete" button? Just wondering...

 

Also, if DD content mod creators choose not to have a look at a public beta or at least the change log of a new major version of a framework they're using, I can't help them. I announced the beta testing in the regular DD support threads and even DCL's, too. This thread here is stickied, and people having a stake in DD had years of opportunity to click a button and subscribe to it, to get notified of activity here. And yes, looking at the postings and reports here, you're pretty much the only maintainer of a major DD mod who's participating. It's quite honestly their problem, not mine, or yours. If they don't test their mods with the upcoming version and their stuff breaks on release day, they will have to tell me after the fact (I am sure they will find really "polite" ways to tell me, despite it's still THEIR problem) and wait for me to get a fix out, if I can. It's not my job to hunt them down and drag them into the beta. I am not getting paid for this, either.

 

Sorry I am sounding a bit frustrated. But I am.

Link to comment
9 minutes ago, Kimy said:

@VirginMarie

 

I am not even entirely sure what the 'event level' proposal entails. A flag passed to SelecValidDDanimations() that does...what exactly?

I think you have not read part 2 of my proposal from last night where I'm suggesting a DDStartSex function, and no change to SelecValidDDanimations.

9 minutes ago, Kimy said:

 

Also, looking at your latest test results, I kinda was under the impression that the filter now works correctly? Which part of DD5 is still incompatible with SLAV now? And why? You can make all your "fake chastity" devices work with DD5 using the permitX keywords now, can't you? And the filter, from what I saw in your reports, no longer gets stuck anywhere. I am not sure I understand what the problem at this point even is?

Outstanding problems reported:

  • Stacked actors that are not animating
  • Stuck Scene
  • anims return value of 0 is suspect, for example in last tests, if I were to use 0 to go to fallback, I'd not be even calling those scenes. yet they were good scenes
  • I tested the Anims = libs.SelectValidDDAnimations(LoveActor, 2, false, None, "Vaginal, Oral, Anal") suggested fix and it has not worked. Vaginal sex was allowed, seen in the log. I can post the results if you want but I feel like should be waiting for a new release

Not Reported Yet:

  • creatures... my tests have shown its working well. Only problem found is that it consistently kills the Free Cam (likely when the device is hidden)
  • some more severe looking cases of stacked and/or stuck and (new case) misaligned actors during love shout. I think waiting for a release for other fixes first would help

Where I need to opt out on the filter:

  • I wont allow my mod to include the "visual glitch" (the Sexlab interrupt, that stops the scene and transitions into a new one), for some of my scenes, such as the love shout where this is far too significant in multi actor combat oriented chaotic scenes. Its been stated that it can't be solved and I would not expect it can
  • If there are outstanding bugs I would want to be able to opt out for all or some scenes. I'm concerned that you many not be able to fix things like stacked, mis-aligned, and stuck, particularly for group scenes, because these could be Sexlab not being able to handle it, thus you would be in a battle to fight the problem. So I guess I'm expecting some things to not be solvable, beyond the visual glitch

I cannot opt out with the permit keywords fully as other devices form other mods can be on the player or npc, thus the proposal at event level.

 

How much and on what scenes, I would opt out, depends on the outcome of what can be fixed, and what cannot be.

9 minutes ago, Kimy said:

 

I have the feeling you're angry at me. At least the part where you threaten to pack your stuff and leave is telling me so, among things.

I'm angry that I'm having to push for options to keep my mod compatible without making it worse instead of better. I feel rushed to find the bugs before its too late. And I'm angry because so far I'm spending loads of time testing, still not knowing if I will be able to opt out where I deem required.

 

As for packing up and leaving, that's a last resort, and its not all about DD. You see I've been gone almost 2 years, so in a way I was already gone. I have still supported my mod but no updates. I came back to see if its fun again to update SLaV. I was working on updates other than DD5 compatibility, then realized what's coming in DD5. It's out of pure luck that I was around enough to realize what you have cooking for DD. I only have so much time. This work to upgrade for DD5 CAN be a big improvement and thus fun for me, it depends on if I have options. In all the testing, DD5 has been very stable for me outside the filter. I'm happy about that.

9 minutes ago, Kimy said:

 

But you have to admit that you have been designing parts of your features in glaring contrast to what DD is designed and meant to do. Restraints that don't restrain. Chastity devices that don't block intercourse.

No. I don't have any chastity device that does not block other than when we have been testing this week. I don't want to have to do that. And using a bug free filter would be an improvement for many of my scenes and I would use the filter for some scenes if no bugs. I want the option to not use it in some scenes. I've been stating that I would not use the permit keyword if the proposed solution or something at an event level existed, and the bugs are gone.

 

Restraints that don't restrain? If you mean I have heavy bondage that is removed by Nocturnal appearing and removing it when you are hit a few times, then yes, but this does not mismatch the DD framework.

9 minutes ago, Kimy said:

 

The filter is getting optimized every day, and from what I can tell, doesn't glitch out anymore. If there are other issues, by all means tell me about them and I will see what I can do. Just preferably without disabling or crippling core DD features.

Not glitching out would be awesome. Glad t hear it. Outstanding problems are summarized just above. And please read part 2 of my proposal.

9 minutes ago, Kimy said:

 

If you were in my shoes, and I discovered some feature in your mod that's not working correctly, would you rather me tell you about it, or me just advising your users to open your mod in CK and go wild with the "Delete" button? Just wondering...

I understand, but its's like I've said, you have to WANT and BELEIVE in the feature to spend the time on properly reporting it. I have a distaste for mods that change the behavior of framework mods, if its not a clear opt in, or it overwrites code. But I have NOW been putting loads of time into testing your filter as you can see. And that time needs to at least double before release I think. I'm starting to WANT and BELEIVE in the feature, but will never really get there if its not got the choice to opt in. That is needed or mods that depend on a different behavior break.

9 minutes ago, Kimy said:

 

Also, if DD content mod creators choose not to have a look at a public beta or at least the change log of a new major version of a framework they're using, I can't help them. I announced the beta testing in the regular DD support threads and even DCL's, too. This thread here is stickied, and people having a stake in DD had years of opportunity to click a button and subscribe to it, to get notified of activity here. And yes, looking at the postings and reports here, you're pretty much the only maintainer of a major DD mod who's participating. It's quite honestly their problem, not mine, or yours. If they don't test their mods with the upcoming version and their stuff breaks on release day, they will have to tell me after the fact (I am sure they will find really "polite" ways to tell me, despite it's still THEIR problem) and wait for me to get a fix out, if I can. It's not my job to hunt them down and drag them into the beta. I am not getting paid for this, either.

 

Sorry I am sounding a bit frustrated. But I am.

Well I get this too, and can partly agree. I've been in software jobs where we support millions of users. Microsoft's ODBC driver for example, and you learn backwards compatibility is king, not just because users will be unhappy, but because supporting the outcome is costly. Could not think the way you are thinking in that case.

 

But this is a game. Nothing is mission critical. People's time are unpaid so we do it for the fun, hence the "we need to want and believe in the feature to spend time on it". I still think that if you have the ability to keep backwards compatibility, you should, and if you need more early adopters of a new feature, you need to get them on board first so its tested in some content mods and working, making people want to opt in.

 

The ultimate losers are the users of abandoned mods, if there is serious enough compatibility issues to break those mods. The authors don't care, its the users. I think happy users of DD mods is important for the health of all DD mods.

 

 

Link to comment

I said this a few times already, but while I really value backwards-compatibility and after all these years of almost never breaking I think I can say this with confidence, but asking me to NEVER make any change that comes with the slightest chance to break things in abandonware mods is a bit much asked for. I asked around in this thread for important DD mods currently not having a maintainer, and got provided exactly one example of one such mod that might have issues with DD5: Slaverun Reloaded. I made a change to DD5, so that people can still activate the obsolete feature it apparently needs. Which should solve that issue for the time being. As far as DD5 is concerned, that is. Ironically that mod is apparently already considered broken for reasons other than DD5 anyway, but hey. Details.

 

I have no idea why people expect to be able to install a 5 year old mod that has been unmaintained for half that time and still expect it to work. It's software. All unmaintained software components eventually outdate when their environment changes, and it always will. In 20 years from now on, you can bet on Skyrim not even running on your computer anymore, at least not without using an emulation layer the kind of we're using to run old DOS applications on modern operating systems. Is that reason enough for developers to stop working on better operating systems and better hardware? Errrm, no!

 

As for the bugs reported:

 

1. I do not consider the "startup delay" a bug (because the delay is a result of the way the feature operates, not faulty code). Therefore, I am not going to "fix" it. The filter has behaved like this since it was first written. It's not a DD5 issue. People telling me that they'd find this an "unacceptable visual eyesore", so they want the filter gone just to have to look once more at a BIGGER visual eyesore (actors having sex through chastity, or their hands popping out of their bondage during a scene) make a statement I consider ridiculous, to be open. I got bug reports about that when the filter wasn't working, so don't tell me that the "I hate the filter and it must go, go, go!" crowd is a majority here.

 

2. Stacked actors: I saw a few instances of you mentioning it, but IIRC, the log always stated that the filter wasn't even interfering with that scene and aborted. I need some evidence that this is even a filter issue in the first place, because I am honestly not sure. I can't see how and the log just shows the filter aborting and resume playing the original scene.

 

3. Stuck scenes: I am confused now. Didn't you tell me that it's fixed with the newest version of the filter (the zadBQ00.psc script I posted)? I can't remember me getting reports of the bug persisting by you or anyone else. If that's NOT the case, please point me to the report saying otherwise.

 

4: SelectValidDDAnimations() returning none: That's expected behavior when the selector cannot find any valid animations. That will ALWAYS be the case, e.g. if an animation requires bound animations but has more than 2 actors. SelectValidDDAnimations is NOT a filter per se and will NOT rearrange the actors (e.g. split up the scene). You WILL need a fallback for these cases, OR if you KNOW that the scene won't have valid animations anyway, just fire away any random animation with StartSex() and let the filter handle it (it will).

 

5. Creatures. I have no clue if that's a side-effect of hiding the restraints or not. The filter doesn't interfere with creature scenes other than hiding restraints. It's really quite minimal. It's also a REALLY well known fact that DD doesn't support creatures in any shape or fashion. If people come to the conclusion that hiding restraints isn't what they want, I can and will revert that code to the original, which is DD just terminating creature animations if the animation would be invalid (e.g. blocked interaction). I will otherwise not work on, test, or troubleshoot creature stuff.

 

Last but not least: I do NOT consider bugs, even serious ones, a valid reason to ask for an opt-out option for any feature. That's just backwards thinking I wholeheartedly disagree with. If there are bugs, let's FIX them.

Link to comment
2 hours ago, Kimy said:

I said this a few times already, but while I really value backwards-compatibility and after all these years of almost never breaking I think I can say this with confidence, but asking me to NEVER make any change that comes with the slightest chance to break things in abandonware mods is a bit much asked for.

We will have to agree to disagree on that point.

This is the not a case where you must remove the toggle. You are choosing to. You could easily keep it backward compatible.

Quote

I asked around in this thread for important DD mods currently not having a maintainer, and got provided exactly one example of one such mod that might have issues with DD5: Slaverun Reloaded.

And you have me saying SLaV is on that list. Without testing I could guess on other mods but wont as you must test test test, not just surface level. We know its not just 2 DD mods though.

Quote

1. I do not consider the "startup delay" a bug

I know. And I have not been stating it as a bug. I know its not a bug, its still a problem though.

 

We are going to have to agree to disagree on the impact of this "problem". Perhaps one day you will see its impact in SLaV on the Love Shout and understand why I will never consider it something that can be overlooked. For SLaV Its a showstopper, thus I resent and am angry you wish to force me to just accept it and use it. I wont. Unless I have a way to opt out for this scene and possibly other scenes, I have no path forward. 

 

You stated you will listen to any proposals or suggestions. Now you are not even responding to my proposed solution. I don't know if you have even read it. I proposed a wrapper for Sexlab's StartSex that maybe would allow you to actually even fix the startup delay. 

Quote

2. Stacked actors: I saw a few instances of you mentioning it, but IIRC, the log always stated that the filter wasn't even interfering with that scene and aborted. I need some evidence that this is even a filter issue in the first place, because I am honestly not sure. I can't see how and the log just shows the filter aborting and resume playing the original scene.

I don't know any way to give you more evidence, other than to just keep giving you more examples with the logs. 

 

I've stated I think there are likely problems you can't solve because its a case of Sexlab having problems, not your code. Stacked is one of those problems. This is very susceptible to timing issues, script load, the power of your computer, and god knows what else, thus I'd expect different results for different people. I can recreate stuck and stacked and some misalignments with love shout, very easily.

 

On a tougher scene like Love Shout, where it is even more susceptible than the tests I've already shown you and I NEED to be able to opt out of the filter in cases like that, or I will be forced to write code that does not even use sexlab. I don't expect you can fix the problem. Maybe you can lessen it. Maybe the optimization you have done will lessen it. 

Quote

3. Stuck scenes: I am confused now. Didn't you tell me that it's fixed with the newest version of the filter (the zadBQ00.psc script I posted)? I can't remember me getting reports of the bug persisting by you or anyone else. If that's NOT the case, please point me to the report saying otherwise.

It was fixed for the Cassia Scene. Then I reported its happening in the 5 actor Erotic Arts Scene.

 

In this post Problem #3 is outstanding

 

In this later post  Problems 1 and 2 outstanding

Quote

4: SelectValidDDAnimations() returning none: That's expected behavior when the selector cannot find any valid animations. That will ALWAYS be the case, e.g. if an animation requires bound animations but has more than 2 actors. SelectValidDDAnimations is NOT a filter per se and will NOT rearrange the actors (e.g. split up the scene). You WILL need a fallback for these cases, OR if you KNOW that the scene won't have valid animations anyway, just fire away any random animation with StartSex() and let the filter handle it (it will).

Look at the tries where I tested the Nocturnal Teases scene. They are all returning 0, yet those scenes all ran great. I did not fall back, luckily. If I had of fallen back, this would be bad. Thus it would appear to be a bug.  The bug, if I'm right about this, needs to be fixed or code will fallback needlessly.

Quote

5. Creatures. I have no clue if that's a side-effect of hiding the restraints or not.

I know its a side-effect because it's the only change I've made is going to DD5. Creature stuff is much better in DD5, but freecam breakage is there, and consistent, every time. I have much experience with FreeCam and it does not take much for it to be broken. Device manipulation while animating is one of the causes. 

 

Problem is, Sexlab is doing all the actor controls, putting the actor into a locked up state, and then the equip device can break things, and this can cause stuck, broken animations, and freecam. All of this is timing sensitive, so you might not break it if earlier or later, and thus different people may get different results. You may not be able to fix it, but you are not breaking freecam in your other sexlab interventions, so maybe you already have the code elsewhere that fixes it.

Quote

It's also a REALLY well known fact that DD doesn't support creatures in any shape or fashion.

That's fine but then if you do this one thing, and cant fix the problem, I need a way to opt out, at least in the MCM. In fact it should be opt in.

I've not tested creatures enough. Like 3-somes I've not tried. There could be more problems.

Quote

If people come to the conclusion that hiding restraints isn't what they want, I can and will revert that code to the original, which is DD just terminating creature animations if the animation would be invalid (e.g. blocked interaction). I will otherwise not work on, test, or troubleshoot creature stuff.

And I would need to opt in to your termination, or you break my mod. I DO want hidden devices. I would prefer to have the choice at an event level in case it does not work in certain situations, or all situations. I can take the devices off myself, but I CANNOT stop your breaking freecam.

Quote

Last but not least: I do NOT consider bugs, even serious ones, a valid reason to ask for an opt-out option for any feature. That's just backwards thinking I wholeheartedly disagree with. If there are bugs, let's FIX them.

Agreed lets fix them. But problems (I don't call them bugs, that's for the author to conclude) that cannot be fixed ARE a valid reason for providing opt out. And changing behavior of another framework should be opt in.

 

In Conclusion

At this point, I am not willing to continue participating in the beta, if I have no choice to opt in, or at the very least, opt out, concerning the "Delayed start in sexlab intervention" and other problems that can't be solved. I would prefer at the event level instead of a global toggle. Neither of us likes the global toggle much.

 

So please let me know if we can work on a solution for that so I can choose where to put my time. Maybe read the 2nd part of my proposed solution. I think its only fair and hope you understand that I simply wont spend my time if I think the end result is something worse for SLaV, instead of something better. And we need to be thinking big picture... all the DD mods. The more DD mods that are good and working, the happier users are to use the whole family of DD mods.

Link to comment
5 hours ago, Kimy said:

4: SelectValidDDAnimations() returning none: That's expected behavior when the selector cannot find any valid animations. That will ALWAYS be the case, e.g. if an animation requires bound animations but has more than 2 actors. SelectValidDDAnimations is NOT a filter per se and will NOT rearrange the actors (e.g. split up the scene). You WILL need a fallback for these cases, OR if you KNOW that the scene won't have valid animations anyway, just fire away any random animation with StartSex() and let the filter handle it (it will).

And here goes an idea: instead of opt in, or opt out, or any other filter disable, how about creating an explicit way to call fallback with device hiding? This way, devices are hidden before animation is started and restored in the end, any animation can be called, no startup delay, no global disabling bound animations.

Also, changing MCM toggles - add sub-option "prefer bound animations for more then 2 actors". So, behavior would be

1. BA enabled, "Prefer BA for orgies" enabled - filter breaks people in groups and rearranges actors, bound animations played.

2. BA enabled, "Prefer BA for orgies" disabled - filter replaces animation for pairs and hides restraints for orgies (no animation replacement or actors rearrangement in that case).

3. BA disabled - filter doesn't use bound animations.

Also - I mentioned it before  - how about adding a switch for considering actor gender to MCM? Right now, gender checks drop out too many bound animations in FF case... Also... I didn't want to mention this before, but we have a potential blackhole of bugs hidden here - with Devices For Him as part of framework, filter will encounter many strange cases... ?

Link to comment
4 hours ago, VirginMarie said:

In this post Problem #3 is outstanding

If I am not totally mistaken, 125 is the maximum number of animations the function will return. In addition, there was no actual problem being reported since nothing at all seemed to break. I do not consider this anything I need to investigate unless further evidence of an -actual- problem is provided.

 

4 hours ago, VirginMarie said:

 

In this later post  Problems 1 and 2 outstanding

 

#1: Again, the filter didn't even do anything in your example. It evaluated the original animation as valid and terminated, without doing anything I could see. I remain unconvinced that this is a DD problem.

 

#2: That's probably a real issue. 5-actor animations are a huge edge case. For the longest time there weren't any, and even now the selection is so super small that I personally would never call one explicitly. Anyway, I will make this problem vanish by making the filter not trying to break them up anymore, so it will just hide restraints and move on, so nothing should get stuck. Be advised that you still need to make sure on your end that the 5-actor animation (there was only one possible one to pick in your report) is not otherwise invalid (e.g. by actors wearing non-fake chastity preventing that one animation in your setup...).

 

I might be able to add the code for #2 tomorrow and post a new version of the filter. Which should then solve all known and confirmed issues you reported.

 

About the thing where you used SelectValidDDAnimations() and it returned NONE, then the animation worked anyway? Well, yes, that's expected behavior, if you look at the log. SelectValidDDAnimation() uses the parameters given to pick a valid animation. If it cannot find any, it is supposed to return NONE. Now, if you don't have a fallback in your own code and call the scene anyway, SexLab will just start...something? Anything, I guess? Which makes the DD filter step in and override the animation with something that works. At least that's what apparently happened, according to the provided log. In the end: Not a bug I can see, just code producing expected results.

 

Anyway, since we have apparently reached a point where you're basically blackmailing me to give in to your demand for some sort of kill-switch for the DD filter or leave, I am not going to assume you're going to test your mod with DD5 any further. In case you change your mind and want to report new findings, you know where to find me. I still have no desire to break your mod, and so far I think I have provided a solution for every confirmed DD5-related issue that has the potential to break your mod. Except for #2 above, we seem to be in "visual glitch" territory now, not actual show-stoppers.

But to be super-open, nobody can reasonably expect a framework to never introduce changes that require updating the component using it. That's just too much asked for. Particularly when the component in question used the framework in ways it was never designed for (fake-chastity), or in contexts that are clearly unsupported and always have been (creatures), or in scenarios involving some serious edge-cases (using 5-actor animations in bondage contexts, when not a single such animation has ever been created for such a context I'd be aware of). Some of these issues I can and have solved for you. Others might perhaps require you to make a few changes of your own. But if you're unwilling to compromise at all, there is very little need for us to continue to work on this. Your call. But there will be no disabled-by-default filter or API kill-switches for it, and I believe I made this clear from the get-go.

Link to comment
12 hours ago, Kimy said:

And yes, looking at the postings and reports here, you're pretty much the only maintainer of a major DD mod who's participating.

That's a shame to hear, my simple learn-to-make-mods Mimic Clothing mod, which still is in beta, is not a major part of DD mods? ?

Spoiler: That was a joke, to lighten  up the mood here again, at least slightly ;)

 

Saying this, I read this thread and I'm thinking about a general solution how this filtering problem could be solved, yet I'm not that experienced about what works with CK and Papyrus or coding in general (only a bit of C/C++ for my studies), so I can't really help. And in this I can only assume, but I think the major part of mod creators out there has a similar background, so they probably will have similar problems ... you can't help, if you don't know how.

 

And another problem is the fact, that (in my eyes) at least half the DD mods seem to be unsupported/on hiatus/stated as finished, so nobody cares about them.


If I come up with something, I'll write it here. Also, reporting bugs, if I find some (yet they may occur because of my own mod ^^)

Link to comment
1 hour ago, Kimy said:

 I still have no desire to break your mod,

Then at the very least, please don't remove the toggle in the MCM. 

1 hour ago, Kimy said:

 so far I think I have provided a solution for every confirmed DD5-related issue that has the potential to break your mod.

You say lets fix things, but half reported are just met with disbelief and denial that they could be DD, and not investigated. or responded too. My proposed idea for a solution, also not even responded to.

 

There are problems that you cant fix, and I don't expect you to fix but you therefore need to let me opt out. If you wont do that in new features, event level, etc, then at the very least, please don't remove the toggle in the MCM.

1 hour ago, Kimy said:

Except for #2 above, we seem to be in "visual glitch" territory now, not actual show-stoppers.

They are show stoppers for me. The visual glitch, is and so are Stuck, misaligned, and stacked not animation. Just the glitch alone is in fact likely the #1 thing that have hampered adoption of the filter. If you don't agree with me on the severity of how big a problem this is, then at the very least, please don't remove the toggle in the MCM.

1 hour ago, Kimy said:

But to be super-open, nobody can reasonably expect a framework to never introduce changes that require updating the component using it. That's just too much asked for.

All I'm asking for, is that you please don't remove the toggle in the MCM. 

 

The component I'm using is a direct call to Sexlab, NOT DD. Please don't force a behavior change, upon sexlab, that I can't opt out of. You can do that in elegant ways, or at the very least, please don't remove the toggle in the MCM. 

1 hour ago, Kimy said:

Particularly when the component in question used the framework in ways it was never designed for (fake-chastity)

As already stated, 2 times before, I'm not going forward with a fake chastity. That was your idea as a solution which we later realized is not a full solution in the first place.

1 hour ago, Kimy said:

or in contexts that are clearly unsupported and always have been (creatures),

I've never asked for, expected, or wanted DD to support creatures or anything that changes the behavior I expect, and count on, from Sexlab.

 

I expect sexlab to behave, unaltered by DD, unless I opt in to a feature I want, but you refuse to allow that and force this feature upon me.

 

At the very least, give us a toggle in MCM to disable whatever it does. What I do with creatures is between me and sexlab. Please don't interfere with that, it was working fine without your help. If you offer something that improves it, and I can opt in, I gladly will.

1 hour ago, Kimy said:

or in scenarios involving some serious edge-cases (using 5-actor animations

Again, that is between me and sexlab. Don't force change the behavior of sexlab. My mod works just fine without your intervention. Don't break my mod by forcing something I did not opt in for. If your feature is an improvement, let me opt in if I want to use it, and I gladly will. 

1 hour ago, Kimy said:

 if you're unwilling to compromise at all

The only thing I'm unwilling to compromise on, is having no choice to use a feature, or not to use it.

I was very willing to update my mod, and test your feature like crazy. I still think we have the chance to turn this into an improvement, where I don't just turn the entire thing off, but not if I don't have an opt in event level choice, where my edge case cannot not be handled, etc.

1 hour ago, Kimy said:

there will be no disabled-by-default filter or API kill-switches for it

If not a disabled-by-default, then at least please give us the MCM toggle unaltered, where you have to opt out. Would need to include the creature feature.

 

I was not asking for an API kill switch. I was asking for the opposite but maybe you have not read my proposal yet? The proposal is to opt in by using a DD wrapper for Sexlab's StartSex. I think you'd then be able to solve the visual glitch too, since you are not doing a delayed interrupt, thus you wont have any chances of the stuck, stacked, or alignment problems either.

1 hour ago, Kimy said:

I believe I made this clear from the get-go.

You also made it clear that you would find a solution for me. So I spent the time to test. Since we are not coming to a solution, then at the very least, please don't remove the toggle in MCM.

Link to comment

@VirginMarie

 

A fix for the 5-actor animation will be coming today. If we can agree on me no longer having to waste my time on beating dead horses, that is.

 

The stacked actor thing you can accuse me to be in denial of if you wish, but the log is quite clear on this NOT getting caused by the filter. So unless you provide me with some conclusive follow-up theory why this even could be a problem of my mod at all, I am also not going to waste my time on this.

 

I will try one more thing with the creature-feature hiding restraints. But if it doesn't work, the creature thing is -definitely- a problem with SexLab because DD doesn't interfere with the animation at all. It just hides its OWN restraints, which is DD's darn right to do, as much as it's your right to use 5-actor animations whenever you want.

 

And yes, I promised solutions to keep your mod running, and so far I delivered on each and every issue you reported that could be confirmed to be a DD problem. What I did NOT promise is to tailor DD to your personal preference.

 

I can also promise you that the toggle will NOT be back and I can promise you that the filter will NOT default to off. I have no idea how often I will need to repeat myself and explain the reasoning behind this. But one thing I have a track record of not reacting to well is if I say no to a request and people just keep pressuring me for it because they can't accept no for an answer. You will not change my mind on this. You are welcome to keep working with me on getting your mod to run with DD5, and from what you told me and your reports, I think we're mostly there. If you cannot accept that in the future your mod will have to accept and work with the DD filter being on and doing its job, you will have to do what you feel is best for you.

 

On a personal note: You more or less abused the toggle by deliberately designing features that rely on it being set to off. By doing so, you forced your personal decision on EVERY other user and EVERY other DD mod out there, as soon as your mod was installed. Some of these users and authors might have appreciated the filter to be on and working as intended. I think you realize very well that the toggle wasn't meant for mod authors to cripple framework functionality from their end, but you did it anyway. It was meant as a end-user choice. Just in case you wonder why my determination to never bring back this toggle is now firmer than ever.

Link to comment
7 hours ago, VirginMarie said:

If not a disabled-by-default, then at least please give us the MCM toggle unaltered, where you have to opt out. Would need to include the creature feature.

 

I was not asking for an API kill switch. I was asking for the opposite but maybe you have not read my proposal yet? The proposal is to opt in by using a DD wrapper for Sexlab's StartSex. I think you'd then be able to solve the visual glitch too, since you are not doing a delayed interrupt, thus you wont have any chances of the stuck, stacked, or alignment problems either.

 

Yeah, I know I might just add further fuel to the fire. Sorry if that is the case.

 

I can see Kimy's point here that the MCM toggle is bad. I would want to remove it too if I were in her shoes. Mainly because it is that toggle is a global effect. If you @VirginMarie tell the users of your mod to use that toggle, your mod might work correctly, but at the same time any other situation involving a combination of DD and Sexlab will break. This includes a other mods that are depending on that filter!

Technically it would be better if @Kimy would provide you with a DD api where you can tell DD "I am now starting a sexlab scene, please do not interfere with this single scene (do not replace animations, do not hide devices, etc.)". Because in that case, the effect would be constrained to that single scene started by your mod, without affecting anything else. Also since such an API would be part of DD, only DD aware mods would be using it, in situations where their author hopefully knows what they are doing.

Please note that I am confused after trying to follow this thread whether such an API is already provided or not, and if not about the reasons.

 

10 hours ago, Kimy said:

About the thing where you used SelectValidDDAnimations() and it returned NONE, then the animation worked anyway? Well, yes, that's expected behavior, if you look at the log. SelectValidDDAnimation() uses the parameters given to pick a valid animation. If it cannot find any, it is supposed to return NONE. Now, if you don't have a fallback in your own code and call the scene anyway, SexLab will just start...something? Anything, I guess? Which makes the DD filter step in and override the animation with something that works. At least that's what apparently happened, according to the provided log. In the end: Not a bug I can see, just code producing expected results.

This surprised me, so I am asking for clarification to improve my understanding. My expectation was that the filter will internally also use SelectValidDDAnimations() to find "something that works", so if the filter did find something that worked, why was SelectValidDDAnimations() returning NONE in the first place? Or did the filter do something that SelectValidDDAnimations() could not do, e.g. splitting up the scene?

Link to comment
8 minutes ago, Kharos said:

This surprised me, so I am asking for clarification to improve my understanding. My expectation was that the filter will internally also use SelectValidDDAnimations() to find "something that works", so if the filter did find something that worked, why was SelectValidDDAnimations() returning NONE in the first place? Or did the filter do something that SelectValidDDAnimations() could not do, e.g. splitting up the scene?

Both the filter and SelectValidDDAnimations() use the same internal function to pick bound animations, but the filter-fallbacks are not available to SelectValidDDAnimations(). SelectValidDDAnimations() is designed to find actually valid animations, and thus will return NONE if there aren't any for the requested situation. If the filter can't find valid animations, it will try a range of fallbacks to make the animation work anyway (such as hiding restraints, or breaking up the animation). Which is why it was able to make something work in VirginMarie's test, even when there were no valid animations for the scenario she requested it for.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. For more information, see our Privacy Policy & Terms of Use