Devious Devices Framework Development/Beta

[VirginMarie]

3 hours ago, Kimy said:

What we do know thanks to your test is that the newly equipped device needs at least 0.3 or 0.5 seconds respectively to get actually equipped after calling LockDevice(). That's interesting knowledge, but as I said, not relevant to what we want to know. We want to know if the SWAP works, not how long the non-latent part of the operation minimally takes to complete.

I was trying to test both aspects in one test:

• Part one, 15 tries, does it get swapped successfully?
• And part 2, reduce the delay until failure. Find out if there is failure if you have chained swapping for example

SLaV has no intentional chain swapping. It uses a cooldown (mutex-ish) type thing to prevent it, but that does not mean another operation can't come along and create that scenario, randomly, including from another mod.

 

Quote

The correct way to test it is using a sufficiently large delay AFTER the swap, never decrease it, and then check if the CORRECT rendered device is worn at the end of the operation

My "part 1" was already doing the delay after the swap, only. But...

 

My critical flaw in the test was not checking for success by checking for the correct rendered device, as you said, giving false results. I've updated it to do that, and the results are 100% success, with a fixed delay of only 0.2, for all 3 types of functions. See log if you are interested.

 

But...

The use case of swapping a device, to make it appear that the device morphed into a changed device, requires that it's fast.... as in the human eye does not realize it was removed and replaced.

• Imagine the armbinder (discussed in posts above) that tightens.... you'd actually replace the armbinder, but you would not want to be looking at no armbinder equipped for a full second. SwapDevices gives you that kind of delay, thus it looks like the device was removed first, thus the illusion is ruined
• SLaV does this illusion with 9 devices in total. 2 are nipple devices that become horny (a horn appears to pop out), and the rest are called melting devices, where they become semi-transparent, due to your "heat". The "morph" is based on your level of orgasm. The idea is to let devices reflect arousal level. With DD4 It's sufficiently fast enough that I never see the device gone, nor any failures, thus the illusion is intact. I'm trying to keep that with DD5. Not sure I'm there yet.

SwapDevices is not fast enough so I can rule using that out for now. It appears that the other methods are now, with your update, reliable enough, so this is good news, but I have to test more, in terms of the speed. They are much faster than SwapDevices, I know that much. My first impression is that the functions in DD4 are faster, for this use case.

 

Thanks for making all the functions handle the race condition (at least thus far tested, I cannot speak for all use cases). Off to do more testing....

Log34 - race condition, beta 13, ver 2.log

[Kimy]

There is no sane use-case for chain swaps in the SAME device slot. What's the point of swapping out a ball gag for a ring gag, and then immediately swapping out the ring gag for a panel gag? The one scenario I can see this becoming a legit problem is two mods performing swaps in the SAME device slot in the EXACT same second. This is probably less likely to happen than the sun going supernova tomorrow morning, so it's also nothing I am overly concerned with. The DD code was never proofed against that. It's a bondage framework, not a database engine, haha! There is no need for testing this, honestly. We don't need to foolproof the code against coders doing silly things, or once-in-a-million-years freak events.

 

Chain swaps using -different- device slots should work fine, though. At least the code is supposed to be able to handle it. Feel free to test that!

 

About fast-swaps: I don't believe for one second that SwapDevices() is slower than DD4 EquipDevice() with the mutex enabled. DD was never written to facilitate instant device swapping, and while this could possibly be done using an implementation based on transactions rather than consecutive unequip/requip operations, this would probably wreck backwards-compatibility in so many ways that I'd have the "But all these 5,000 year old unmaintained mods need to keep working, you evil Kimy, you!!!" crowd throw rotten tomatoes at me again. 

The one thing I could possibly try to make the function perform faster is removing the 1 second safety delay in SwapDevices(). I added that because when in doubt I prefer the function delivering expected results over a slight visual delay. Let's face it, in real life, you can't insta-swap somebody's armbinder with another one either. You have to take the old one off, and then put the new one one. There will be a non-zero amount of time the subject isn't wearing any armbinder. I do not consider this a problem, quite frankly.

 

About device tightening: DD doesn't support device tightening in the true sense, because it's infeasible to implement in Skyrim. All it will ever be able to do is simulate it with swaps. Yes, swaps with a slight visual delay. Not perfect. But at least DD5 supports THAT, when no older version of DD did.

 

Feel free to try SwapDevices() without the additional 1 second delay after the while loop and see if it works. If it does, I can take it out, which should make SwapDevices() about as fast as it can be, given the way DD is implemented.

[VirginMarie]

2 hours ago, Kimy said:

There is no sane use-case for chain swaps in the SAME device slot.

Agreed. I stated that SLaV does not do it.

Quote

The one scenario I can see this becoming a legit problem is two mods performing swaps in the SAME device slot in the EXACT same second. This is probably less likely to happen than the sun going supernova tomorrow morning, so it's also nothing I am overly concerned with.

Yes that is the sort of scenario I was thinking of. My testing showed that it has to catch it within a 0.3 sec window of time. So I'm not worried about it either. There is the question of what I have NOT tested yet, that could be more vulnerable. But I will not be testing all cases, not even close, just what is predominant in SLaV.

Quote

There is no need for testing this, honestly. We don't need to foolproof the code against coders doing silly things, or once-in-a-million-years freak events.

I think you misunderstand that I talking about other potential edge cases, not just the one I found. I have not found any thus far.

 

So far DD5 is handling all of the silly things SLaV does, with your update. I'm doing actual playthrough, with as many horny and/or melting devices equipped as I can, making lots of arousal changes, and watching it like a hawk, and its not breaking, and its fast enough to give the wanted illusion. This is using the depreciated functions. It WAS breaking with beta 12, so you have made it better for sure.

 

Do I need to worry about a large inventory as a use case for possible slowdown?

Quote

Chain swaps using -different- device slots should work fine, though. At least the code is supposed to be able to handle it. Feel free to test that!

Already did test that. I have a lots of use cases of this. No problems so far.

Quote

About fast-swaps: I don't believe for one second that SwapDevices() is slower than DD4 EquipDevice() with the mutex enabled.

So here's the weird thing. The trick needed for it to work flawlessly for me in DD4, was to NOT use mutex, I have just realized. I have that setting set to true, and I was mis-reading it as mutex ON, but the parameter is called SkipMutex, so its been doing the opposite of what I thought. The default was to not skip. I had to turn mutex off, and adjust my code with a cooldown, to get it working great in DD4.

 

So yes maybe DD4 with default mutex would be slower than Swap. Don't know why skipping it worked for me, but it did.

Quote

About device tightening: DD doesn't support device tightening in the true sense, because it's infeasible to implement in Skyrim. All it will ever be able to do is simulate it with swaps. Yes, swaps with a slight visual delay. Not perfect. But at least DD5 supports THAT, when no older version of DD did.

Support it or not, SLaV has been doing this very thing for years. I'd say it is capable of supporting it. And looking fine in DD5 for me at this point too.

Quote

Feel free to try SwapDevices() without the additional 1 second delay after the while loop and see if it works. If it does, I can take it out, which should make SwapDevices() about as fast as it can be, given the way DD is implemented.

If I start to find the depreciated functions are not good enough, I might try that, but at this point my feature is in good shape with no change. The other thing I might try is Lock with "forced", I mean that achieves the same as Swap, but faster. Maybe 1 second removed from Swap makes them equal.

[Kimy]

7 hours ago, VirginMarie said:

Do I need to worry about a large inventory as a use case for possible slowdown?

Good news: Absolutely not! That was one of THE reasons why I rewrote the portion of DD handling equips and unequips from scratch. The old code scaled very badly depending on how large your inventory was. The new code...doesn't care.

[VirginMarie]

7 minutes ago, Kimy said:

Good news: Absolutely not! That was one of THE reasons why I rewrote the portion of DD handling equips and unequips from scratch. The old code scaled very badly depending on how large your inventory was. The new code...doesn't care.

Great to hear. My update on testing is not so good. In my continued playthrough style testing, I've now seen 2 instances of the "swap", using depreciated, fail for 2 different melting/horny devices. I'm sure if I switched to SwapDevices, it would not fail, but it would be too slow.

 

But the good news is I wrote my own variation, stripped down just for this very specific case, and of course that can be faster with many fewer things to check and do. So far it passes that same stress test.

 

Events on Horseback

Tonight I was stuck standing on a horse, because I mounted just as a DD event started. Not sure which one, it was too fast, maybe the tug on chastity belt. I'm pretty sure DD already checks for "onhorse" before triggering these, but worth maybe verifying. I've wondered how we could prevent this, when its triggering just as you mount. Its actually not so rare and I have SLaV events that can cause the same stuck. 

[Kimy]

The reason why SwapDevices() is a bit slower than a UnlockDevice()/LockDevice() chain is BECAUSE SwapDevices() is safer. You can't have the cake and eat it. If you want more speed, you will have to live with the odd case where the swap doesn't work so well. But if your own function works, fine.

 

Horses: I would also think that the event code checks for the actor being mounted, but I will double-check and fix this as needed. I don't think I can catch an actor in the progress of mounting, though.

[VirginMarie]

1 hour ago, Kimy said:

But if your own function works, fine.

My own function, if it helps (so far so good), will only be so due to it doing less, which it can since its only for this one special use case. It still relies on your brand new code in zadEquipScript, which I appreciate very much. Here's a sample of a log with my function in play...

 

[11/14/2020 - 09:53:27AM] [Zad]: OnUnequipped(Marie: Virgin Chastity Chaurus)
[11/14/2020 - 09:53:27AM] [Zad]: Starting unequip operation for [Keyword <zad_deviousbelt (0A003330)>]
[11/14/2020 - 09:53:27AM] [Zad]: OnContainerChanged()
[11/14/2020 - 09:53:27AM] [Zad]: Detected removal token. Done.
[11/14/2020 - 09:53:27AM] [Zad]: OnEquipped(Marie: Virgin Chastity Chaurus)
[11/14/2020 - 09:53:27AM] [Zad]: Checking for active unequip operation for [Keyword <zad_deviousbelt (0A003330)>]
[11/14/2020 - 09:53:27AM] [Zad]: Device Swap detected. Waiting for removal operation to complete.

[11/14/2020 - 09:53:27AM] [Zad]: OnUnequipped(Marie: Virgin Cloth Harness)
[11/14/2020 - 09:53:27AM] [Zad]: OnContainerChanged()
[11/14/2020 - 09:53:27AM] [Zad]: Starting unequip operation for [Keyword <zad_DeviousHarness (0A017C43)>]
[11/14/2020 - 09:53:27AM] [Zad]: Detected removal token. Done.
[11/14/2020 - 09:53:27AM] [Zad]: OnEquipped(Marie: Virgin Cloth Harness)
[11/14/2020 - 09:53:27AM] [Zad]: Checking for active unequip operation for [Keyword <zad_DeviousHarness (0A017C43)>]
[11/14/2020 - 09:53:27AM] [Zad]: Device Swap detected. Waiting for removal operation to complete.

 

DD is still doing the real work. Nice! Maybe I can get away with having my cake and eating it ?

1 hour ago, Kimy said:

I don't think I can catch an actor in the progress of mounting, though.

Ya I've tried to figure out how to do that in the past. Was hoping someone knows a way. Wonder if it could be killed by checking again after the event is already going. Thing is, nothing seems to be able to undo the stuck. When you get stuck on a horse, you are very very stuck.

[Rogwar002]

2 hours ago, Kimy said:

Horses: I would also think that the event code checks for the actor being mounted, but I will double-check and fix this as needed. I don't think I can catch an actor in the progress of mounting, though.

Skyrim is Skyrim. It is doing one task at a time and doesn´t like to get interupted or weird things will happen.

There is a simple choice here to prevent bad stuff happening: The charakter should stand still or in idle mode to trigger anything that is not native Skyrim or deal with the consequences of triggering events during another ongoing event.

 

Trigger a NiOverride during walking: Stutter on the best rig you can built. Noticed this first in your DCL, Kimy. If you have the arousal body transformation effect active, during the call, the PC is stuttering for a very small period, but still noticable.

Trigger an event during anything else than walking, standing or idle: something weird will happen to your toon, from flying, hovering or clipping through the world to standing on a mount, porting to the center of your cell, get stuck in mining, walk on water... think of it and be asured, it will happen.

 

I could write books of idiotic scenes happening after a mod is triggering anything during an ongoing event, such as mounting a horse, a boat, going through a door, swimming... simple things.

 

For your animation scence you could try to stop the charakter in his tracks before the animation will happen. If it is not able to stop, like mounting a horse, the animation should not start.

 

1 hour ago, VirginMarie said:

Ya I've tried to figure out how to do that in the past. Was hoping someone knows a way. Wonder if it could be killed by checking again after the event is already going. Thing is, nothing seems to be able to undo the stuck. When you get stuck on a horse, you are very very stuck.

Having sex or fast travel to an indoor cell with the console command does sometimes help (but: sometimes this could port your toon to an empty cell...like Matrix in grey )

[Kimy]

On 11/13/2020 at 12:19 PM, zarantha said:

@Kimy  Semi-random question - Would you be willing to add in SLIF compatibility to DD and DCL in the future, if not this release?

 

These are the lines SLIF modifies in your scripts.

  Reveal hidden contents

DD / zadLibs.psc

 

Original:

Function SetNodeHidden(Actor akActor, bool isFemale, string nodeName, bool value, string modkey = "DDi")
    if value
        XPMSELib.SetNodeScale(akActor, isFemale, nodeName, 0.01, modkey)
    else
        XPMSELib.SetNodeScale(akActor, isFemale, nodeName, 1.0, modkey)
    endif
EndFunction

 

 

Modified:

Function SetNodeHidden(Actor akActor, bool isFemale, string nodeName, bool value, string modkey = "DDi")
    if Game.GetModbyName("SexLab Inflation Framework.esp") != 255
        if value
            SLIF_Main.hideNode(akActor, "Devious Devices Integration", nodeName, 0.01, modkey)
        else
            SLIF_Main.showNode(akActor, "Devious Devices Integration", nodeName)
        endif
    else
        if value
            XPMSELib.SetNodeScale(akActor, isFemale, nodeName, 0.01, modkey)
        else
            XPMSELib.SetNodeScale(akActor, isFemale, nodeName, 1.0, modkey)
        endif
    endif
EndFunction

 

 

DCL / dcur_clocktickScript.psc

 

Original:

Function SetMorphValue(Actor akActor, float value, string MorphName = "PregnancyBelly")    
    If value != 0.0
        NiOverride.SetBodyMorph(akActor, MorphName, "DCL", value)
    Else        
        ; ok, don't ask me why clearning the morph isn't working, so we're just setting it to a minimal value and carry on...
        NiOverride.SetBodyMorph(akActor, MorphName, "DCL", 0.01)
    ;    NiOverride.ClearBodyMorph(akActor, MorphName, "DCL")
    EndIf    
    NiOverride.UpdateModelWeight(akActor)
EndFunction

 

 

Updated (it was still using clearbodymorph, figured your change needed to be forwarded):

Function SetMorphValue(Actor akActor, float value, string MorphName = "PregnancyBelly")    
    If Game.GetModbyName("SexLab Inflation Framework.esp") != 255
        If value != 0.0
            SLIF_Morph.morph(akActor, "Deviously Cursed Loot", MorphName, value, "DCL")
        Else
            SLIF_Morph.unregisterMorph(akActor, MorphName, "Deviously Cursed Loot")
        EndIf
    Else
        If value != 0.0
            NiOverride.SetBodyMorph(akActor, MorphName, "DCL", value)
        Else        
        ; ok, don't ask me why clearing the morph isn't working, so we're just setting it to a minimal value and carry on...
        NiOverride.SetBodyMorph(akActor, MorphName, "DCL", 0.01)
    ;    NiOverride.ClearBodyMorph(akActor, MorphName, "DCL")
        EndIf    
        NiOverride.UpdateModelWeight(akActor)
    EndIf
EndFunction

 

Not sure, tbh. While this is a soft-dependency for users, it's not a soft dependency for me, or anyone else trying to compile DD/DCL, as the SLIF scripts have to be present to compile DD/DCL, if that code goes in.

 

I will think about it, but I will make no promises. Right now, it's a "probably not". I don't consider SLIF to be very high priority, tbh.

 

Generally, the time to add new features to DD5 is pretty much over, so all requests for new things will probably go on the DD5.1 to-do list. The beta test has been going on for a while now, and we seemed to have squashed every bug that reasonably can be squashed. At this point, I am pretty determined to release DD5 sooner, rather than later.

[VirginMarie]

2 hours ago, Rogwar002 said:

Having sex or fast travel to an indoor cell with the console command does sometimes help (but: sometimes this could port your toon to an empty cell...like Matrix in grey )

Need a way to to script an unstuck ?

If scene managed to start, and now you are on a horse after it started, execute magical un-stuckage procedure. Along these lines..

            Game.Setplayeraidriven(false)
            Game.EnablePlayerControls()
(but this does not work for stuck on freaking horse)

 

I check for, and don't trigger animation scenes if:

• combat
• dialogue menu open
• fighting or movement controls disabled
• DCL's busy state in StorageUtil
• Camera State... any cam state that is not first person, or third person (Game.GetCameraState). This catches horse / dragon mounted /  furniture / other freaky states
• Swimming

Re. the Camera State, I've just updated that part to include all the freaky states to test it that way. Note that one of them is labelled "Free" and this means FreeCam. Another is called "Transition" hmmm

 

 

EDIT: @Kimyas part of the above, I've tested checking with DD's Libs.IsAnimating in the past, but it gets me in trouble because it seems to not always be correct. I should maybe be reporting that as a problem to check into but I've never been sure about it.

[zarantha]

1 hour ago, Kimy said:

Not sure, tbh. While this is a soft-dependency for users, it's not a soft dependency for me, or anyone else trying to compile DD/DCL, as the SLIF scripts have to be present to compile DD/DCL, if that code goes in.

 

I will think about it, but I will make no promises. Right now, it's a "probably not". I don't consider SLIF to be very high priority, tbh.

 

Generally, the time to add new features to DD5 is pretty much over, so all requests for new things will probably go on the DD5.1 to-do list. The beta test has been going on for a while now, and we seemed to have squashed every bug that reasonably can be squashed. At this point, I am pretty determined to release DD5 sooner, rather than later.

Fair enough, and I wasn't really expecting it this release even if you were willing. Just thought I'd ask since I wasn't sure it had been brought up before.

Thank you for thinking about it, whatever you decide.

[VirginMarie]

On 10/27/2020 at 3:37 PM, Kimy said:

Fixed: Removing restraints from dead NPCs no longer causes them to become reanimated in funny ways.

Wondering if you could share how you fixed this. I've always had reanimated (sometimes), or more like, floating in the air, NPCs after killed by the Love Shout.

[Nymra]

So it was brought to my attention that DD 5 will no longer have a toggle for the animations filter?
Is that correct? 

 

[Richard1234]

1 hour ago, Nymra said:

So it was brought to my attention that DD 5 will no longer have a toggle for the animations filter?
Is that correct? 

 

That’s correct.

[Nymra]

2 hours ago, Richard1234 said:

That’s correct.

Ah damn....  

I really do not even dare to ask why....

The filter was off for me all the time for a variety of reasons. Not beeing able to disable the filter would really make DD experience a lot worse than before

Is there really no chance that this feature will remain? 

[indolu]

4 hours ago, Nymra said:

Ah damn....  

I really do not even dare to ask why....

The filter was off for me all the time for a variety of reasons. Not beeing able to disable the filter would really make DD experience a lot worse than before

Is there really no chance that this feature will remain? 

Yeah no chance. Essentially people would turn it off, then submit bug reports about it not working.

[Code Serpent]

@Kimy

 

I'm curious if you've tried the escape minigame I made in Devious Lore, and if you'd be interested in me implementing a version of it for the framework? Normally, I'd pm you this, but I thought it was worth posting it here to allow others to chime in on which escape mechanics they like.

[Zaflis]

44 minutes ago, Code Serpent said:

I'm curious if you've tried the escape minigame I made in Devious Lore, and if you'd be interested in me implementing a version of it for the framework? Normally, I'd pm you this, but I thought it was worth posting it here to allow others to chime in on which escape mechanics they like.

DL minigame when combined with devices escape chance would be ok. And instead of using stamina, a new internal stat could also be introduced; one that would increase on every struggle. Escapalogy skill would have say 10 levels, each taking twice longer than the previous level to max, and at max level you would get some 50-100% bonus to the filling rate of escape bar.

[tamai]

4 hours ago, Code Serpent said:

I'm curious if you've tried the escape minigame I made in Devious Lore, and if you'd be interested in me implementing a version of it for the framework

I second this the escape system is the best

[DeWired]

3 hours ago, Zaflis said:

DL minigame when combined with devices escape chance would be ok. And instead of using stamina, a new internal stat could also be introduced; one that would increase on every struggle. Escapalogy skill would have say 10 levels, each taking twice longer than the previous level to max, and at max level you would get some 50-100% bonus to the filling rate of escape bar.

Using stamina have a nice benefit - you can do meta-optimization for it using existing perks and buffs. Maybe even downing potion of fortify stamina regen before trying to escape a device. But, it also is a problem - current version can be severely broken with some mod/perk combination, like, for example, Respite perk + Bondage Witch mod. Overall, using stamina would require massive rebalancing. Also, maybe add last chance for escape on minigame loss, depending on device difficulty.

 

But - I'm all for bringing minigame into framework. It even can be added to furniture - and actually make it more interactive.

 

One more thing - it also is desirable to add something for getting devices off NPCs besides the keys. Not struggling, but cutting and picking locks should be available options (when PC isn't bound too much and can do those).

[Nymra]

4 hours ago, indolu said:

Yeah no chance. Essentially people would turn it off, then submit bug reports about it not working.

That sounds like you break your mod for half of the users to fix that a handful of people is using it wrong. 

I really really understand that there is an effort to make a mod smooth and easier to use and understand, but especially with a framework like DD I think this is basically mod armageddon. 

The DD filter built in DCL, DD, even Sexlab Adventures is one of the single most annyoing features I am facing in kinky Skyrim and I went on to just dont use mods anymore that have it. 
DD has too little animation variety and no chance to change them or manipulate them, so it makes Sex very repetetive. I am spending hours on hours to increase the amount of Animations in Sexlab so I dont see the same animations over and over. With DD now forcing the same 12 animations on me now would be a nightmare. 
 

Especially since there are now concerted efforts of @osmelmc to improve the animation filter in Sexlab I think it is a really bad decision to remove the Filter Toggle from a Framework mod like DD5. 
 

Kimy, I really understand your reasoning for the Filter in DCL (while I do not necessarily understand the necessity of it having no toggle), but with DD5 I think it is something entirely different. 

 

You seem to be a professional in terms of software, well, I am a professional in terms of concept and useabilty. Skyrim mods need MCM toggles to improve compatibility with other mods and increase user experience. Fetishes, gameplay approaches and mod builds are so different and all over the place (which is very good and necessary for the community to even exist). 
Forcing a single way to play on the users cant be your goal, no? I mean DD framework is a must have mod these days, you cannot really play without since many important (and old) mods need it. Having an easier time to support the mod alone seems not a very good trade off here, at least in my eyes

Just my example of using DDs:

- I control VERY strict which mod is allowed to put a yoke or an armbinder on my char, so I can control when I see the like a dozen yoke or armbinder animations. 
- I allow DD mods to only equip Steel Manacles and Prisoner Chains most of the time because those are compatible with MOST of the animations out there that are non-DD. 
- I am not allowing plugs to restrict sex scene types because I hate chastity play
- for the same reason I never allow mods to equip chastity items. 

So as user experience from many games and modding Skyrim-> Options, Options, Options, Options -> gaming paradise. 

I even would suggeste MORE Filters and more elaborate ones.
Like the ability to toggle the filter for several device types:

- filter for Yoke yes/no
- filter for Armbinder yes/no
- filter for plugs yes/no
- filter for gags...

etc.

Like in Windows 10 you could hide all cool options in a "Developer" mode or "advanced user options" MCM toggle. I ve seen that with other mods.
That way "normal" users might not find the toggle easily. 
Also, description of features could be improved, issuing also a "WARNING: Toggling this filter might prevent DD from working as intended"

Ok, sorry for the wall of text, but this really is a very big issue and I have to say that I am not alone with this, not even close. 
ALOT of people are using DD and have the same problem. Of course its hard to get statistics here and I dont know if we can make surveys in this board or if DD development would respect them. 

I really would hate to see the community split between old DD 4 and new DD 5. There are already so few mods that really work well and reducing that amount more seems not desireable

Just on a sidenote: I am really looking forward to DD 5 and its content, but the filter alone would be a big no-no for using it sadly and sticking with DD 4.X (hoping that at least other mods with DD as dependency can maintain backwards compatibility with DD 4. 

 

[Nymra]

5 hours ago, Code Serpent said:

@Kimy

 

I'm curious if you've tried the escape minigame I made in Devious Lore, and if you'd be interested in me implementing a version of it for the framework? Normally, I'd pm you this, but I thought it was worth posting it here to allow others to chime in on which escape mechanics they like.

I would really love to see different escape mechanics. 
To be honest I did not like the mini game, but I like the general Idea and many people too I think.

What I would love to see as a mini game would be something more animation based and less gamey/pop up intensive.

 

I already suggested a one hotkey/no pop up escape game that is giving us a nice visual experience.

1. press Hotkey
2. struggle out of hands/wrist bondage first (logical first step almost all of the times)

3. struggle out of gag (obvious second choice)
4. struggle out of ankle chains
5. struggle out of chastity items 
6. etc.

The order could be customized in MCM, while I think it might be logical to keep hand/wrist struggle on place 1. 
 

The PC would automatically choose the best option (struggle/cut/key) depending on the chances of sucess without the necessity for a pop up. 

So in effect we would press a hotkey and directly see a suitable struggle animation and then a message telling us the outcome (ideally in upper left as debug, pop ups are so immersion breaking). 

 

[DeWired]

2 hours ago, Nymra said:

Spoiler

That sounds like you break your mod for half of the users to fix that a handful of people is using it wrong. 

I really really understand that there is an effort to make a mod smooth and easier to use and understand, but especially with a framework like DD I think this is basically mod armageddon. 

The DD filter built in DCL, DD, even Sexlab Adventures is one of the single most annyoing features I am facing in kinky Skyrim and I went on to just dont use mods anymore that have it. 
DD has too little animation variety and no chance to change them or manipulate them, so it makes Sex very repetetive. I am spending hours on hours to increase the amount of Animations in Sexlab so I dont see the same animations over and over. With DD now forcing the same 12 animations on me now would be a nightmare. 
 

Especially since there are now concerted efforts of @osmelmc to improve the animation filter in Sexlab I think it is a really bad decision to remove the Filter Toggle from a Framework mod like DD5. 
 

Kimy, I really understand your reasoning for the Filter in DCL (while I do not necessarily understand the necessity of it having no toggle), but with DD5 I think it is something entirely different. 

 

You seem to be a professional in terms of software, well, I am a professional in terms of concept and useabilty. Skyrim mods need MCM toggles to improve compatibility with other mods and increase user experience. Fetishes, gameplay approaches and mod builds are so different and all over the place (which is very good and necessary for the community to even exist). 
Forcing a single way to play on the users cant be your goal, no? I mean DD framework is a must have mod these days, you cannot really play without since many important (and old) mods need it. Having an easier time to support the mod alone seems not a very good trade off here, at least in my eyes

Just my example of using DDs:

- I control VERY strict which mod is allowed to put a yoke or an armbinder on my char, so I can control when I see the like a dozen yoke or armbinder animations. 
- I allow DD mods to only equip Steel Manacles and Prisoner Chains most of the time because those are compatible with MOST of the animations out there that are non-DD. 
- I am not allowing plugs to restrict sex scene types because I hate chastity play
- for the same reason I never allow mods to equip chastity items. 

So as user experience from many games and modding Skyrim-> Options, Options, Options, Options -> gaming paradise. 

I even would suggeste MORE Filters and more elaborate ones.
Like the ability to toggle the filter for several device types:

- filter for Yoke yes/no
- filter for Armbinder yes/no
- filter for plugs yes/no
- filter for gags...

etc.

Like in Windows 10 you could hide all cool options in a "Developer" mode or "advanced user options" MCM toggle. I ve seen that with other mods.
That way "normal" users might not find the toggle easily. 
Also, description of features could be improved, issuing also a "WARNING: Toggling this filter might prevent DD from working as intended"

Ok, sorry for the wall of text, but this really is a very big issue and I have to say that I am not alone with this, not even close. 
ALOT of people are using DD and have the same problem. Of course its hard to get statistics here and I dont know if we can make surveys in this board or if DD development would respect them. 

I really would hate to see the community split between old DD 4 and new DD 5. There are already so few mods that really work well and reducing that amount more seems not desireable

Just on a sidenote: I am really looking forward to DD 5 and its content, but the filter alone would be a big no-no for using it sadly and sticking with DD 4.X (hoping that at least other mods with DD as dependency can maintain backwards compatibility with DD 4. 
 

 

Well. I think this is misunderstanding on your side. Filter is always on now, yes, but it doesn't mean it would always result in same set of animations. There is a switch "Enable bound animations" - when it's on, filter would replace original animation with compatible bound animation. If switch is off - filter would hide restraints for the time of animation. Just use this if you like variety. And honestly - all this talk about switch just solidifies idea that dropping it was a right choice - when it was there, nobody understood what it did.

[Richard1234]

2 hours ago, Nymra said:

Just my example of using DDs:

- I control VERY strict which mod is allowed to put a yoke or an armbinder on my char, so I can control when I see the like a dozen yoke or armbinder animations. 
- I allow DD mods to only equip Steel Manacles and Prisoner Chains most of the time because those are compatible with MOST of the animations out there that are non-DD. 
- I am not allowing plugs to restrict sex scene types because I hate chastity play
- for the same reason I never allow mods to equip chastity items. 

Maybe I’m missing the point here... but what’s the problem with the DD filter? From your usage of DDs:

- Yoke/armbinder: DD filter steps in and selects proper animation, just like you want.

- Manacles/chains: i don’t know what the filter does here. I guess nothing? In that case it does what you want.

- Plugs: you don’t use them so filter doesn’t step in, like you want.

- Chastity: same as plugs.

 

So... what’s the problem?

[Mister X]

Heyho, something very small, many here may not even think about anymore: I just skimmed through the zadlibs code, and found this snippet (line 1146-ff as of beta 13):

; Not sure how to detect auto-walk: Tap 'forward' to disable it if it's active.
; Unfortunately this work-around causes a CTD for some players, so let's just disable it...
; Input.TapKey(Input.GetMappedKey("Forward"))

 

I really don't know if that is the case, but maybe the CTD happens, while "tapping" the key, even if the player still holds the key to walk manually. It would interfere, as controls are still enabled. So how about testing that first?

Int iForwardKey = Input.GetMappedKey("Forward")
If !Input.IsKeyPressed(iForwardKey) ; check for manual movement
	Input.TapKey(iForwardKey)
EndIf