Jump to content

Devious Devices Framework Development/Beta


Recommended Posts

2 hours ago, osmelmc said:

 

3. The only thing at my side that is one issue is the "SL Animation Load" file released apart to make the Devious Devices Animations visible on the SexLab and is the only one I responsible for. But is not the the only SLAL package with "Bound" Animations you can find because also FB, Billyys, ZaZ and few other author's have Bound Animations on his SLAL files. So the issue with the bound animations played without bound actors will be there without the "SexLab Utility Plus" or the DeviousDevice SLAL file. One of the intentions of the Utility filter is prevent that issue be filtering out the Bound related Animations before the Animation begin if none of the actors are bound but is also true that was not working as intended on some previous versions and that's another story.

First things first. Please do not be offended by my above posting. It wasn't meant to diss on your work, and I nowhere mentioned your mod anywhere in my posting. Those were general remarks, even if your mod came up every now and then in this thread.

 

But yes, let's talk about you registering DD's animations a bit, because that quite frankly IS a problem:

2 hours ago, osmelmc said:

Any way to properly test the DD I also think that the users should disable or remove the DeviousDevices SLAL file and use the "Clean System" option on the SexLab MCM. And probably remove the SexLab Utility Plus too just to be in peace.

I'm also fan of the Devious Devices and as programmer I know the hard it is try to fix something when some other programs/mod can be interfering with my work even if is not true but just the chance of interface is enough to make the development harder.

I definitely got bug reports I was able to track down to users having SUP installed. So, I am afraid it -does- interfere. I suppose the bigger problem is not your filter, but you registering DD internal animations to SexLab. Which, to be open, is a really, REALLY bad idea. Because it makes these animations available for random picking, despite they're absolutely not meant for that. They do not compare at all to the other bound animation packs available, because DD's animations do NOT feature any anim objects (e.g. restraints on the actors). They're meant to be used on conjunction with equipped DD items and only then. Otherwise you will see silly things like actors assuming bound poses, despite there are no restraints visible on these actors. I am not sure why people think I wrote that much code to AVOID having to register these animations in the general SLAL registry?

 

To be honest, yes, this is an example why I am absolutely NOT fond of people altering the intended behavior of my mods, without even talking to me. Had you asked me, I'd have told you that these animations aren't suitable for use outsides of DD. This way, I had to find out by people sending me bug reports. :S

 

2 hours ago, osmelmc said:

About the capacity of toggle the Animation Filter option on Devious Devices MCM like I explained on my first point "really don't matter" because SexLab Utility Plus is not a patch for DD and can work even better if the Animation Filter of the DD is enabled because the ActorChange function always used on the DD solve some issues related to the lack of animations I can't solve right now.

 

From one software developer to the other, I am not sure about an upstream framework (SexLab) pulling in functionality of a downstream one (DD). It just doesn't feel right to me, from a design perspective. Personally I feel DD is the best place to implement DD functionality, including its filter. Not some other component, just because its position in the software stack allows it to hook into processes and do some stuff before the downstream component even sees it. Like to hear it, or not, but your filter IS interfering with DD, by pre-processing things DD is meant to process (handling restraints). I haven't yet looked at your actual code, but depending on how you're doing it, you're keeping DD from doing what it's meant to do and superseding its functionality with your own.

 

And no, as I explained in my above posting, I am not a big fan of that.

 

I am not interested in a dispute. Honestly not. I just wanted you to understand my position here. No bad feelings. :)

Link to comment

@Kimy I'm 100% with you about the DD internal Animations even when I was the one doing that. I made it as side file for those users who keeps disabled the Animation Filter option of the DD and even remember WARNING about use it but time after that I made the mistake of include the JSON file inside the last SUP installation file without the warning about. 

 

I will not include the JSON file on the next release. But probably keep it on the support page as was first intended for the few user with the knowledge to use it without issues.

 

2 hours ago, Kimy said:

From one software developer to the other, I am not sure about an upstream framework (SexLab) pulling in functionality of a downstream one (DD). It just doesn't feel right to me, from a design perspective. Personally I feel DD is the best place to implement DD functionality, including its filter. Not some other component, just because its position in the software stack allows it to hook into processes and do some stuff before the downstream component even sees it. Like to hear it, or not, but your filter IS interfering with DD, by pre-processing things DD is meant to process (handling restraints). I haven't yet looked at your actual code, but depending on how you're doing it, you're keeping DD from doing what it's meant to do and superseding its functionality with your own.

 About the way the SUP works is basically the extension of the filters already included on the SexLab Framework.

Link to comment

Devious Devices 5 Beta 10


- Added: A new debug function "Fix Devices" was added to the MCM debug page, that can attempt to fix broken devices without removing working ones.
- Added: To improve backwards-compability with legacy mods, users can now use the "Register Devices" toggle on the MCM debug page to force registration of DDX devices to the deprecated device database. This might help some legacy mods directly picking DDX devices to continue working until they can get updated.
- Changed: More optimizations for the animation filter. Several DD animations also had some tags changed.
- Changed: Plugs and Suits now also check for zad_permitAnal and zad_permitVaginal keywords, which allows for creating devices that allow intercourse despite they'd normally block it.

 

If updating from Beta 1:

 

Devious Devices 5 LE Beta 1 to Beta 10.7z

 

If updating from Beta 9:

 

Devious Devices 5 LE Beta 9 to Beta 10.7z

 

Devious Devices 5 Beta 9 Download link (full release):
 
https://mega.nz/file/jJtw3arB#wqgkLIOs8qnCPZ0Nw-fHNMXnt0fpQsBBOxhs1JEZZgE

 

 

Link to comment

At this point I consider the latest DD5 beta pretty much a release candidate. If no further bugs are found, I am about to release the full version pretty soon. So if testers could have a final look at the changes, it would be awesome! :)

Link to comment
5 minutes ago, Kimy said:

- Changed: Plugs and Suits now also check for zad_permitAnal and zad_permitVaginal keywords, which allows for creating devices that allow intercourse despite they'd normally block it.

To elaborate, would it be correct to say that Chasity belt and Gags were already doing this?...

Describing the full functionality, each of vaginal, anal, and oral are blocked (filtered) by relevant chastity, plug, suit, and gag devices, and each can be made open with their corresponding "permit" keyword. Each device is checked and collectively impact the blocking.

 

Example:

  • player wears
    • chastity belt with permitAnal (only)
    • vaginal plug with permitVaginal
    • gag with permitOral
  • only vaginal is currently blocked. DD will filter vaginal animations
  • chastity belt is removed. Vaginal is no longer blocked with this magical plug that does not block vaginal
  • DD now does not filter any animations

This is already very clear, but writing it down serves to help think about testing it so we are all on the same page. I got this right?

 

This is going to be great. Wondering if you missed reading my last post. No worries as I bet you wanted to get this code done! :P 

Link to comment
3 minutes ago, Rogwar002 said:

 

It is no longer possible to download from mega without being charged. Thought I should mention that.

I just did a test download and I didn't notice anything different? I've not got any account, although I do have ublock so that might have blocked something.

 

But the folder came through without issue and I can unpack it and everything.

 

Is there a monthly limit maybe?

Link to comment
1 hour ago, Ursur1major said:

I just did a test download and I didn't notice anything different? I've not got any account, although I do have ublock so that might have blocked something.

 

But the folder came through without issue and I can unpack it and everything.

 

Is there a monthly limit maybe?

MEGA has a daily 5GB limit, if I remember correctly. When in doubt, you can always use a VPN to get around it.

Link to comment

Test Results #1

DD5 Beta 10

I started a new game. Not got to see much of SLaV yet as its story has not started.

  • Installer has conflicts with some DCL files
  • New Fix Devices feature not in MCM
  • "Remove QuestItems" feature does not appear to run. "Safeword" in DCL is also not able to remove my Collar. I was wearing "Whore Collar" from DCL when trying both these features. Log was captured right after trying both DD and DCL features 2 or 3 times each

Papyrus.0.log

Link to comment

Test Results #2.

a series of tests to try Bound Animations in combination with variations of "zad_permit"

 

Test 1 - see Log1.txt attached

  • Chastity with PermitAnal. Anal Plug with no permit. Gag with no permit (all 3 holes blocked)
  • Wearing Heavy Bondage
  • 6 tries. re-loaded a save each try. tries 1 to 3, Bound Animations ON. tries 4 to 6,  Bound Animations OFF

Test 2 - Log2

  • Chastity with PermitAnal/PermitVaginal. Anal Plug with PermitAnal. Gag with no permit (Vaginal and Anal open. Oral blocked)
  • Wearing Heavy Bondage
  • 6 tries. re-loaded a save each try. tries 1 to 3, Bound Animations ON. tries 4 to 6,  Bound Animations OFF

Test 3 - Log3

  • Chastity with PermitAnal/PermitVaginal. Anal Plug removed. Gag removed (all 3 holes open)
  • Wearing Heavy Bondage
  • 2 tries. re-loaded a save each try. try 1, Bound Animations ON. tries 2, Bound Animations OFF


The Good:

  • Heavy Bondage hidden feature works well in all cases of Bound Animations OFF
  • Plays, (after sexlab re-starts the 2nd scene), only valid filtered animations as far as I could tell

Problems:

*occurred on ALL tries/ALL tests, unless otherwise noted

  1. You see an animation start (entry animation playing), then sexlab starts over with the filtered animation. Essentially Sexlab ends up playing 2 scenes and this happens slow enough that its very apparent. This is no different than past versions and not a good user experience
  2. Sexlab asked if I want to move to nearby bed, for all tries in Tests 2 and 3. This occurs after the first scene starts then aborts, making the visuals all the stranger. 
  3. [All tries in Tests 2 and 3] Log shows "PermitAnal False". That's not correct
  4. [Test 1, try 4, and ALL tries in Tests 2 and 3] Sexlab did not send a HookAnimationend event. Sexlab was stuck. Thus the quest was broken with no way to proceed. The the player ends with the heavy bondage un-hidden, and is in a freed normal idle state (which is good). The NPC is stuck permanently playing an animation
  5. Last branch of SLaV's Quest Dialog does not play. Something interrupts, the scene starting earlier than normal. This is preventing the user from seeing what the player would normally have chosen from the dialogue

 

I've used one of the simplest scenes. This is the code calling Sexlab...


	Lovin = ""
    ExcludeExhausted = True
    Anims = SexLab.GetAnimationsByTag(2, Lovin, requireAll=False)
    LoveActor = new actor[2]
    LoveActor[0] = PlayerRef
    LoveActor[1] = Cassia2
    LoveActor = SexLab.SortActors(LoveActor)
    RegisterforModEvent("HookAnimationend_Cassia2", "VirginCassia2Done")    
    SexLab.StartSex(LoveActor, Anims, allowBed = True, hook = "Cassia2")

        Event VirginCassia2Done(int threadID, bool hasPlayer)
            UnregisterForModEvent("HookAnimationend_Cassia2")
            VirginCassia2SleepEnd()
        EndEvent

 

Log1.log Log2.log Log3.log

Link to comment
17 hours ago, VirginMarie said:

Test Results #1

DD5 Beta 10

I started a new game. Not got to see much of SLaV yet as its story has not started.

  • Installer has conflicts with some DCL files

Known, but harmless. Can overwrite or ignore.

 

Link to comment
9 hours ago, VirginMarie said:

Problems:

*occurred on ALL tries/ALL tests, unless otherwise noted

  1. You see an animation start (entry animation playing), then sexlab starts over with the filtered animation. Essentially Sexlab ends up playing 2 scenes and this happens slow enough that its very apparent. This is no different than past versions and not a good user experience

There is no way to avoid that, due to the way DD hooks into SexLab. It needs to wait for an animation to start before it can intercept it.

 

9 hours ago, VirginMarie said:
  1. Sexlab asked if I want to move to nearby bed, for all tries in Tests 2 and 3. This occurs after the first scene starts then aborts, making the visuals all the stranger. 

If the scene allows for beds, that's expected behavior, no?

 

9 hours ago, VirginMarie said:
  1. [All tries in Tests 2 and 3] Log shows "PermitAnal False". That's not correct

Mind you that this flag would still be false if another character in the scene has anal sex blocked. The filter does not just check for the player, but -all- actors in a scene.

 

9 hours ago, VirginMarie said:
  1. [Test 1, try 4, and ALL tries in Tests 2 and 3] Sexlab did not send a HookAnimationend event. Sexlab was stuck. Thus the quest was broken with no way to proceed. The the player ends with the heavy bondage un-hidden, and is in a freed normal idle state (which is good). The NPC is stuck permanently playing an animation

Ok, that's weird, because that shouldn't be an issue specific to DD5, but for all prior DD versions as well. I didn't change that mechanic one bit.

 

9 hours ago, VirginMarie said:
  1. Last branch of SLaV's Quest Dialog does not play. Something interrupts, the scene starting earlier than normal. This is preventing the user from seeing what the player would normally have chosen from the dialogue

Not sure I can test that on my end. If you can track this down to a specific DD issue, I can have a look at it.

 

Link to comment
On 10/29/2020 at 3:22 PM, VirginMarie said:

Use Bondage Animations

When I think through this, with SLaV in mind, and other mods, I think the ideal wrist restrained/heavy bondage loving behavior is...

  • If 1 actor... play normal valid animations, letting Sexlab pick, and hide the device (unless there are already several bound DD animations for solo?)
  • If 2 actors... play bound animations, no hiding
  • If > 2 actors... play normal valid animations, letting Sexlab pick, and hide
  • If Creature (any # of actors)... always play normal and hide

Use Bound Animations ON = do the behavior above

Use Bound Animations OFF = always hide and let Sexlab do it's thing

 

Maybe this is already how it works lol, but if not, its an idea. If working this way, then, for SLaV, any combination of the Aggressive and Bound settings will work fine. I'd personally keep them both ON. SLaV will also be fine with the Animation Filter no longer disable-able as we already established.

As of DD5, DD automatically hides restraints when there are creatures in a scene. When there are more than 2 actors in a scene requiring bound animations, and "Use Bound Animations" is unchecked, DD attempts to break up the scene into smaller ones. For one actor it will play belted or bound solos if it can.

 

On 10/29/2020 at 3:22 PM, VirginMarie said:

Is "Use Bondage Animations" working fine in current DD release? 

It should.

 

On 10/29/2020 at 3:22 PM, VirginMarie said:

I want to test with it (just preliminary test). Has it changed for beta?

It's odd that I feel as though I've not ever seen the hiding, but maybe I've not watched closely enough. I usually test with Use Bound Animations set off. I had assumed I don't see hiding because SLaV devices are mostly tagged with QuestItemblock_Generic.

 

[EDIT: I forgot... SLaV only uses block_Generic, I can't remember why I opted not to use QuestItem. Maybe because I decided that situations like your DCL prison, are fine to be removed and replaced]

The function hiding restraints for scenes is quest item safe. It should make no difference.

 

On 10/29/2020 at 3:22 PM, VirginMarie said:

Regarding Creature loving :P:

(Not my favorite topic, or thing to test. My husband made me put the support in SLaV, I swear!)

 

In my testing with DD current release 4.3a (I've got all the latest of all dependencies, latest FNIS, Skeleton, etc.)...

  • When I test Animation Filter ON, Aggressive OFF, Bound OFF.... creatures flip flop around a bit, start off not aligned, may flip into aligned and back, and spin around the Z axis. Sometimes all 4 of these, sometimes 1 or 2, but almost always at least 1 of these. It can be subtle sometimes, and other times just very wacked
  • When I test with all filters OFF...  creatures behave normally

So the Animation Filter appears to have some impact on creatures in prior release. Wondering if anyone seeing this in DD5? I will eventually test in DD5 too.

Prior to DD4, DD would force-abort the scene if it needed bound animations and involved creatures. As of DD5 it will always hide the restraints and let the original scene continue.

 

On 10/29/2020 at 3:22 PM, VirginMarie said:

FNIS update may have impacted entry animations

I upgraded from v7.2 to 7.6. Some SLaV furniture items aligned with actor fine with 7.2. With 7.6 I've been having to compensate. Seems like something changed after 7.2 to cause this. They are old original ZAP items that I integrated. The effected animations are the ones that trigger when you activate the furniture with Activate(ObjectReference) and I'm having to remove use of Activate, and align with TranslateTo instead. I thought it might be worth mentioning in case anybody else is having trouble. Anybody? Makes me wonder if there is any other impact from FNIS.

 

I have no clue, but the new FNIS version seems to cough some errors into the log I can't remember logging in the past. I did not look into this any further though, and did not observe any breakage, either.

 

 

Link to comment
18 hours ago, VirginMarie said:
  • "Remove QuestItems" feature does not appear to run. "Safeword" in DCL is also not able to remove my Collar. I was wearing "Whore Collar" from DCL when trying both these features. Log was captured right after trying both DD and DCL features 2 or 3 times each

Can anyone confirm this? Because it seemed to work when I tested it.

Link to comment
1 hour ago, Kimy said:

Can anyone confirm this? Because it seemed to work when I tested it.

DCL's safeword removes that collar and all devices i had on, tried twice. DD's "Terminate DD quests" did nothing though.

 

Also during the "whore collar" at Whiterun inn i had some issues with animations. The innkeeper put me rope armbinder so that's the only filterable thing. Twice i tried to solicite with the female follower sitting there, both times she invited friend (seemed also female i think). No animation started for me or NPC's on either times. While waiting for animation to start on the first attempt i had then another npc approach for sex and that worked.

 

Save quality is that it's not new game, i've been upgrading incrementally and loading same save. Not refreshed sexlab MCM if that'd do anything, don't think so. I always redo Bodyslide for DD groups and FNIS though.

Link to comment

@Kimy After reading some of VirginMarie's posts I decided to test the bound animation filter again with Beta 10. The filter works fine it just wasn't "dyanmic" enough. With the way it's coded you could have a scene where vaginal and oral are allowed but not anal and you would only see the vaginal animations. Or have oral blocked but only vaginal animations would play despite anal also being allowed. The coding checks for and plays vaginal first followed by oral then anal.

 

This is the current coding for the Pet Suit in Beta 10 (my changes posted a while back):

	If HasPetSuit(a)
		if !b.WornHasKeyword(libs.zad_DeviousHeavyBondage)
			; free partner
			;check if partner is a male
			If b.GetLeveledActorBase().GetSex() == 0
				if permitVaginal
					i = Utility.RandomInt(0,1)			
					If i == 0
						return SexLab.GetAnimationObject("DD_B_PS_Miss")	
					ElseIf i == 1
						return SexLab.GetAnimationObject("DD_B_PS_Doggy")
					EndIf
				ElseIf permitOral	
					return SexLab.GetAnimationObject("DD_B_PS_DT")	
				ElseIf permitAnal	
					return SexLab.GetAnimationObject("DD_B_PS_DoggyA")
				EndIf
			Else
				if permitVaginal
					i = Utility.RandomInt(0,1)			
					If i == 0
						return SexLab.GetAnimationObject("DD_B_PS_Miss")	
					ElseIf i == 1
						return SexLab.GetAnimationObject("DD_B_PS_Doggy")
					EndIf
				ElseIf permitAnal	
					return SexLab.GetAnimationObject("DD_B_PS_DoggyA")
				EndIf
			EndIf
		EndIf
	EndIf	

 

It works fine but is ultimately very limited. If your character isn't wearing any blocking devices you would still only get the two vaginal animations and not see the oral and anal animations.

 

So I added more conditional checks:

	If HasPetSuit(a)
		if !b.WornHasKeyword(libs.zad_DeviousHeavyBondage)
			; free partner
			;check if partner is a male
			If b.GetLeveledActorBase().GetSex() == 0
				if permitVaginal && permitOral && permitAnal	
					i = Utility.RandomInt(0,3)			
					If i == 0
						return SexLab.GetAnimationObject("DD_B_PS_Miss")	
					ElseIf i == 1
						return SexLab.GetAnimationObject("DD_B_PS_Doggy")
					ElseIf i == 2
						return SexLab.GetAnimationObject("DD_B_PS_DT")	
					ElseIf i == 3
						return SexLab.GetAnimationObject("DD_B_PS_DoggyA")
					EndIf
				ElseIf permitVaginal && permitOral
					i = Utility.RandomInt(0,2)			
					If i == 0
						return SexLab.GetAnimationObject("DD_B_PS_Miss")	
					ElseIf i == 1
						return SexLab.GetAnimationObject("DD_B_PS_Doggy")
					ElseIf i == 2
						return SexLab.GetAnimationObject("DD_B_PS_DT")	
					EndIf		
				ElseIf permitVaginal && permitAnal
					i = Utility.RandomInt(0,2)			
					If i == 0
						return SexLab.GetAnimationObject("DD_B_PS_Miss")	
					ElseIf i == 1
						return SexLab.GetAnimationObject("DD_B_PS_Doggy")
					ElseIf i == 2
						return SexLab.GetAnimationObject("DD_B_PS_DoggyA")
					EndIf				
				ElseIf permitOral && permitAnal
					i = Utility.RandomInt(0,1)			
					If i == 0
						return SexLab.GetAnimationObject("DD_B_PS_DT")
					ElseIf i == 1
						return SexLab.GetAnimationObject("DD_B_PS_DoggyA")
					EndIf
				ElseIf permitVaginal
					i = Utility.RandomInt(0,1)			
					If i == 0
						return SexLab.GetAnimationObject("DD_B_PS_Miss")	
					ElseIf i == 1
						return SexLab.GetAnimationObject("DD_B_PS_Doggy")
					EndIf
				ElseIf permitOral
					return SexLab.GetAnimationObject("DD_B_PS_DT")	
				ElseIf permitAnal	
					return SexLab.GetAnimationObject("DD_B_PS_DoggyA")
				EndIf
			;not a male
			Else
				if permitVaginal && permitAnal	
					i = Utility.RandomInt(0,2)			
					If i == 0
						return SexLab.GetAnimationObject("DD_B_PS_Miss")	
					ElseIf i == 1
						return SexLab.GetAnimationObject("DD_B_PS_Doggy")
					ElseIf i == 2
						return SexLab.GetAnimationObject("DD_B_PS_DoggyA")
					EndIf
				ElseIf permitVaginal
					i = Utility.RandomInt(0,1)			
					If i == 0
						return SexLab.GetAnimationObject("DD_B_PS_Miss")	
					ElseIf i == 1
						return SexLab.GetAnimationObject("DD_B_PS_Doggy")
					EndIf		
				ElseIf permitAnal	
					return SexLab.GetAnimationObject("DD_B_PS_DoggyA")
				EndIf
			EndIf
		EndIf
	EndIf		

 

With this code the animation is more dynamic and you can see all the available animations for heavy bondage barring any blocking devices. I've tested in-game and it works well now.

 

Is this too many If/ElseIf conditions, though? Could it be done better or more efficient somehow? I'm not sure how to do so, I'm no script writer.

 

If this code is acceptable then I'll complete the rest of the heavy bondage filters and send the source file.

Link to comment
You see an animation start (entry animation playing), then sexlab starts over with the filtered animation. Essentially Sexlab ends up playing 2 scenes and this happens slow enough that its very apparent. This is no different than past versions and not a good user experience

There is no way to avoid that, due to the way DD hooks into SexLab. It needs to wait for an animation to start before it can intercept it.

Some people prefer the alternative of no filter, and unrealistic animations played. I strive to avoid at all cost, this kind of user experience because too many users would think its broken and blame SLaV, or Sexlab if they are not experienced with LL mods. If this can't be fixed, which is not surprising to me as this is very hard, then I think as a framework, you need to offer it as optional.

 

Sexlab asked if I want to move to nearby bed, for all tries in Tests 2 and 3. This occurs after the first scene starts then aborts, making the visuals all the stranger. 

If the scene allows for beds, that's expected behavior, no?

The expected behavior is that sexlab does not prompt for the bed. I have a bed there and I've told sexlab to silently use it. That's what normally happens when the DD filter is not engaged. Note that it's not prompting in all uses cases either. My point however, was more to do with how this adds to the problematic visual in the issue above. The prompt for bed coming after already animating makes no sense to a user and they will think SLaV or Sexlab is broken.

 

[All tries in Tests 2 and 3] Log shows "PermitAnal False". That's not correct

Mind you that this flag would still be false if another character in the scene has anal sex blocked. The filter does not just check for the player, but -all- actors in a scene.

Yes my mistake. I had not considered what the NPC is wearing. She was wearing a vaginal blocking belt. I've retested with it removed and the log now shows "true" instead. Does DD consider this on an individual actor basis? Like for example, in these tests, when the NPC had blocked vaginal, she could still throw on a strap on and take the player vaginally. Not suggesting it needs to work this way, but would be good to know.

 

[Test 1, try 4, and ALL tries in Tests 2 and 3] Sexlab did not send a HookAnimationend event. Sexlab was stuck. Thus the quest was broken with no way to proceed. The the player ends with the heavy bondage un-hidden, and is in a freed normal idle state (which is good). The NPC is stuck permanently playing an animation

Ok, that's weird, because that shouldn't be an issue specific to DD5, but for all prior DD versions as well. I didn't change that mechanic one bit.

I think my tests show that it's specific to DD. I also think this problem has existed in prior versions. Can you have a look further?

 

Last branch of SLaV's Quest Dialog does not play. Something interrupts, the scene starting earlier than normal. This is preventing the user from seeing what the player would normally have chosen from the dialogue

Not sure I can test that on my end. If you can track this down to a specific DD issue, I can have a look at it.

I think the tests show it has to be related to DD and its a tricky timing issue but maybe unique to my particular scene. In "Test #4" (results posted below), the issue goes away for one test case. I've been able to verify that I can compensate with a Utility.Wait so don't worry about it unless you think it could be significant for other mods. I will watch for it as I test other scenes and let you know if its widespread in SLaV or not.

 

--------------

 

Continuance of Test Results #3 from previous post

 

Test 4 - Log4

  • Player.. all 3 holes open as in prior test
  • NPC... devices removed (all 3 holes open)... I failed to consider the NPC in previous cases
  • Player wearing Heavy Bondage only in some cases
  • 7 tries. re-loaded a save each try. Try 1,2,3, and 5 Bound Animations ON and wearing Heavy Bondage. Tries 4,6,7, Bound Animations ON, heavy bondage removed

Good:

  • [cases with heavy bondage removed] It's very apparent that no filtering was involved. No "Sexlab interrupt and restart visual". No stuck scene. No interrupted/shortened dialogue. All problems listed in prior post do not occur :)
  • Log shows "PermitAnal True". My mistake to not consider other actors. This confirms the log was actually correct in the previous post

 

Problems:

  1. [cases with heavy bondage only] The "Sexlab interrupt and restart visual" (#1 in prior post) occurs as expected, we can say as intended, but still a problem
  2. [cases with heavy bondage only] The "stuck scene" (#4 in prior post) occurs but differently. In these cases the player is the one consistently stuck instead. The player plays an animation forever, until the user presses the space bar many times (sexlab advance hotkey. SLaV has the same hot key so not sure which one is getting the stuck state to advance, but I'd think its sexlab's). The endscene event DOES get sent from sexlab after using the hotkey

 

Summary

 

At this point of my early testing, there's 2 main things to contend with:

  • I don't want to allow any situation where the DD Animation Filter is engaged, because I want to avoid "Sexlab interrupt and restart visual"  (which you can't fix) and "Stuck Scenes" (which maybe you CAN fix?)
    • I can do this in part with permit keywords on all virgin devices, but since the player and NPCs can have non-virgin devices, this is not a complete solution. We did not think about this previously. I can only handle the majority of cases. Thus I request that the Animation Filter be brought beck, or some other solution. Wish I could think of a solution :(
  • I don't want to allow any sexlab scene to start without SLaV, removing on it's own, any heavy bondage, since there are problems regardless of state of "Use Bondage Animation" which include "Sexlab interrupt and restart visual" (which you can't fix)
    • To do this, its a lot of work, and I will NOT remove generic or quest items, making it impossible for me to do this in all cases. Thus I don't really have a complete solution to this either. Not even bringing back the Animation Filter would fix in the current design, unless turning off the Animation Filter would also turn off DD taking action for heavy bondage

Note that I have much more testing to do before I could say this summary is complete, its just where I'm thinking I'm at now. I need to test more cases, and many different scenes, and creatures. I've only tested that one scene. I feel I need your thoughts on this before I put the effort into it.

Log4.log

Link to comment
16 minutes ago, VirginMarie said:
You see an animation start (entry animation playing), then sexlab starts over with the filtered animation. Essentially Sexlab ends up playing 2 scenes and this happens slow enough that its very apparent. This is no different than past versions and not a good user experience

There is no way to avoid that, due to the way DD hooks into SexLab. It needs to wait for an animation to start before it can intercept it.

Some people prefer the alternative of no filter, and unrealistic animations played. I strive to avoid at all cost, this kind of user experience because to many users would think its broken and blame SLaV, or Sexlab if they are not experienced with LL mods. If this can't be fixed, which is not surprising to me as this is very hard, then I think as a framework, you need to offer it as optional.


I am not going to bring back that toggle. Honestly, while it's a slight imperfection, I don't think it's really that bad. Can't make everyone happy all the time, anyway.

 

Sexlab asked if I want to move to nearby bed, for all tries in Tests 2 and 3. This occurs after the first scene starts then aborts, making the visuals all the stranger. 

If the scene allows for beds, that's expected behavior, no?

The expected behavior is that sexlab does not prompt for the bed. I have a bed there and I've told sexlab to silently use it. That's what normally happens when the DD filter is not engaged. Note that it's not prompting in all uses cases either. My point however, was more to do with how this adds to the problematic visual in the issue above. The prompt for bed coming after already animating makes no sense to a user and they will think SLaV or Sexlab is broken.

 

So the scenario was a SexLab scene called with beds disallowed, and the filter replaced it with one using beds? If that's the case, I need to look into that. Indended behavior is the bed status being preserved with the filter needs to replace a scene.

 

[Test 1, try 4, and ALL tries in Tests 2 and 3] Sexlab did not send a HookAnimationend event. Sexlab was stuck. Thus the quest was broken with no way to proceed. The the player ends with the heavy bondage un-hidden, and is in a freed normal idle state (which is good). The NPC is stuck permanently playing an animation

Ok, that's weird, because that shouldn't be an issue specific to DD5, but for all prior DD versions as well. I didn't change that mechanic one bit.

I think my tests show that it's specific to DD. I also think this problem has existed in prior versions. Can you have a look further?

 

I have never seen this issue occurring, ever. Including previous versions of DD. Can anyone confirm this problem?

 

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