Jump to content

Devious Devices Framework Development/Beta


Recommended Posts

Based on new observations, I'm mentioning again the benefit if Devious Devices were to have at least a rudimentary self-validation check.  For example, if DD's MCM were to check ZadLib's GetVersion() function for a matching number and display a warning, that simple check alone would identify a surprising number of player self-inflicted wounds.

 

I recently added a check in Submissive Lola for DD 5.2, checking ZadLib.GetVersion().  Although I was only trying to see that players had 5.2, this has turned up two classes of bad installations.

 

1.  As mentioned earlier, some players install DD 5.2, then overwrite it with some or all of DD 4, because they have a mod that requires "DD Expansion 4.3" and all they see in their mod organizer is Devious Devices, so they think they need Expansion 4.3 too.

 

2.  Other mods will patch DD back to an older version.  For example, Sexlab Inflation Framework Patches replaces ZadLibs with a modified old version (the one I found uses a version of ZadLibs from 2018).  I'm surprised that distributing modified DD scripts like this is allowed, given the permissions on DD, but it's happening.

 

This leads to false bug reports and bogus claims that "DD is so buggy", when it's the player's installation of conflicting versions and obsolete patches of DD scripts that is bad.  A self-validation check could filter out some of that.  After I added an internal version check to Simple Slavery, the number of "doesn't work" reports dropped to zero.  Instead, players report that they got an integrity check failed message, then I have them look for overwrites or rogue patches rather than wasting my time chasing down mystery problems that I can't reproduce because the problem is in the player's installation.

Link to comment
11 minutes ago, HexBolt8 said:

Based on new observations, I'm mentioning again the benefit if Devious Devices were to have at least a rudimentary self-validation check.  For example, if DD's MCM were to check ZadLib's GetVersion() function for a matching number and display a warning, that simple check alone would identify a surprising number of player self-inflicted wounds.

 

I recently added a check in Submissive Lola for DD 5.2, checking ZadLib.GetVersion().  Although I was only trying to see that players had 5.2, this has turned up two classes of bad installations.

 

1.  As mentioned earlier, some players install DD 5.2, then overwrite it with some or all of DD 4, because they have a mod that requires "DD Expansion 4.3" and all they see in their mod organizer is Devious Devices, so they think they need Expansion 4.3 too.

 

2.  Other mods will patch DD back to an older version.  For example, Sexlab Inflation Framework Patches replaces ZadLibs with a modified old version (the one I found uses a version of ZadLibs from 2018).  I'm surprised that distributing modified DD scripts like this is allowed, given the permissions on DD, but it's happening.

 

This leads to false bug reports and bogus claims that "DD is so buggy", when it's the player's installation of conflicting versions and obsolete patches of DD scripts that is bad.  A self-validation check could filter out some of that.  After I added an internal version check to Simple Slavery, the number of "doesn't work" reports dropped to zero.  Instead, players report that they got an integrity check failed message, then I have them look for overwrites or rogue patches rather than wasting my time chasing down mystery problems that I can't reproduce because the problem is in the player's installation.

Overwriting scripts is always a bad practice. Unless it's something specifically designed to patch another mod or vanilla bug. Same goes for bundling recourses in the same folder as the resources. 

 

But aside from that general notice, if you want to make it detect both instances of the issues you outline you will need to do a script check and a esm check. This can be done using GetFormFromFile on something you know is added recently or at least available on the version you are aiming for. If that call results in null it's not found and thus the player is running another version of that ESM.

Link to comment
18 minutes ago, naaitsab said:

Overwriting scripts is always a bad practice.

 Speaking of SE-specific things ?I know OSL Aroused does that, to have it work properly with DD - considering that's a fairly popular SE mod (and, imo, one of the better choices at the moment, despite a few drawbacks), could this be somehow incorporated into DD? (maybe behind a check !ismodpresent=oslaroused.esp or something like that ?)

 

It swaps out

Spoiler

StorageUtil.SetFloatValue(akRef, "SLAroused.ActorExposure", newVal)
StorageUtil.SetFloatValue(akRef, "SLAroused.ActorExposureDate", Utility.GetCurrentGameTime())

with

Spoiler

Aroused.SetActorExposure(akRef, (newVal + 1) as int)

Link to comment
34 minutes ago, krzp said:

 Speaking of SE-specific things ?I know OSL Aroused does that, to have it work properly with DD - considering that's a fairly popular SE mod (and, imo, one of the better choices at the moment, despite a few drawbacks), could this be somehow incorporated into DD? (maybe behind a check !ismodpresent=oslaroused.esp or something like that ?)

 

It swaps out

  Reveal hidden contents

StorageUtil.SetFloatValue(akRef, "SLAroused.ActorExposure", newVal)
StorageUtil.SetFloatValue(akRef, "SLAroused.ActorExposureDate", Utility.GetCurrentGameTime())

with

  Reveal hidden contents

Aroused.SetActorExposure(akRef, (newVal + 1) as int)

The main issue I have with this is that is seems to be the 4th "arousal redux" mod around. So yes a patch can be made but if we want to keep it in the official bundle I would suggest we don't try to support all/a lot of variants of mods that technically do the same but require tweaks. Or at least put a strong emphasis on a drop-in replacement to list in the requirements section on the download page. Or we determine the best and or most modern one is the one to support? A FOmod installer with choices is a nice fix for stuff like this but the bundled patches still need to be maintained and be kept compatible with the rest. In here lies the main issue.

 

Edited by naaitsab
Link to comment
26 minutes ago, naaitsab said:

The main issue I have with this is that is seems to be the 4th "arousal redux" mod around.

Ye, but OSL A is the only one that is semi-active in development and not abandoned, i think (well, that and the newcomer SLA NG, but latter is in the alpha state and is a direct copy of SLAM atm). Plus, it's at about 160k downloads right now LL + Nexus combined, making it more popular than both SLAX and SLAM combined. So, supporting it could be beneficial, however I can see the argument against it as well ?

 

I couldn't move on from it, despite trying every other competitor - once you've tried native SKSE calculations, you just can't go back ?

Edited by krzp
Link to comment
21 hours ago, HexBolt8 said:

Based on new observations, I'm mentioning again the benefit if Devious Devices were to have at least a rudimentary self-validation check.  For example, if DD's MCM were to check ZadLib's GetVersion() function for a matching number and display a warning, that simple check alone would identify a surprising number of player self-inflicted wounds.

 

I recently added a check in Submissive Lola for DD 5.2, checking ZadLib.GetVersion().  Although I was only trying to see that players had 5.2, this has turned up two classes of bad installations.

 

1.  As mentioned earlier, some players install DD 5.2, then overwrite it with some or all of DD 4, because they have a mod that requires "DD Expansion 4.3" and all they see in their mod organizer is Devious Devices, so they think they need Expansion 4.3 too.

 

2.  Other mods will patch DD back to an older version.  For example, Sexlab Inflation Framework Patches replaces ZadLibs with a modified old version (the one I found uses a version of ZadLibs from 2018).  I'm surprised that distributing modified DD scripts like this is allowed, given the permissions on DD, but it's happening.

 

This leads to false bug reports and bogus claims that "DD is so buggy", when it's the player's installation of conflicting versions and obsolete patches of DD scripts that is bad.  A self-validation check could filter out some of that.  After I added an internal version check to Simple Slavery, the number of "doesn't work" reports dropped to zero.  Instead, players report that they got an integrity check failed message, then I have them look for overwrites or rogue patches rather than wasting my time chasing down mystery problems that I can't reproduce because the problem is in the player's installation.

 

Publishing patches against DD scripts is explicitly disallowed by its license (unless it's for pure bugfix or development purposes, such as in this thread). The author of SLIF never asked me for permission, at least not as far as I remember. I have occasionally allowed patches against DD, but I always ask for making it absolutely clear in their download what exact version of DD the patch is for.

 

That also reminds me to take down DD4, finally! :D 

Link to comment
On 7/5/2023 at 5:08 AM, t.ara said:

Yes yes yes-I have your wishes in mind, but the HDT-PE stuff we let aside-so to stay compatible to SSE. That BALL with the weight (chain-balls) can all also be made by using SMP very easily. But it needs a serious trim so that the heavy stuff is not flying around like feathers, touched by the wind.

If you like those, we will add those- as far KIM is agreeing....we need a permission for that things,  to make it an official new release, then.

The box might become a restraint and a furniture, if wanted. But then the player is immobile.

 

I would love to have these devices in DDC, if you're willing to contribute them. :)

Link to comment
6 hours ago, Kimy said:

 

I would love to have these devices in DDC, if you're willing to contribute them. :)

As mentioned in the past, Kim: after finishing ZAP 10 (which is my final version of ZAP),  I´ll be be back here for you.

 

 

Link to comment

Hey guys, I was merely trying to get DCL rape to function properly against a bunch of Draugur while wearing a BByoke, a belt, a bra and a gag (but having a key so DCL doesn't consider it "full chastity prevents rape") and thus discovered a few issues with the way bound animations are currently handled:

 

So the first thing: DCL still uses `SelectValidDDAnimations` instead of `StartValidDDAnimation` (because it wants to check and apply a few more filtering rules on it). The problem is, `StartValidDDAnimation` has the fallback of retrying to find an animation (by calling `SelectValidDDAnimations`) while slowly storing away DD items until it can find one, but `SelectValidDDAnimations` by itself doesn't do it, and simply returns a `None` the first time it cannot find an animation, which I'll get to in a moment.

 

I'd consider it a DCL issue instead of a DD issue ("Just use `StartValidDDAnimation`"), but the first thing I did in my personal game was to rename `SelectValidDDAnimations` to `SelectValidDDAnimationsOld` and write a new `SelectValidDDAnimations` that wraps it with the same logic of `StartValidDDAnimation` that retries with storing items, and recalling the "old function" but returns it rather than starts it, then I found out that the logic fails even there (which I am going to explain thoroughly down below). Also, since the `SelectValidDDAnimations` is also exported and might be in active use in other mods, it might be worth it to either deprecate it or put some warning on it that it tries to find an animation only once.

 

 

Now, for the issues I found while trying to debug `SelectValidDDAnimations`:

 

1. In the first step, if the character is bound, it calls `GetBoundAnim` and returns None if that returns no animation. That None return casues searching for animations fail even if the function was called inside `StartValidDDAnimation`, because it checks if `Sanims.Length <= 0` to determine whenever to try again, and that throws an error on None returns.

To solve this, I simply switched all None returns in the file to empty lists instead.

 

2. At this point the BByoke was successfully removed while searching for animations, but then it found wrong animations (as in, vaginal animations while I am still wearing a chastity belt. It would then start the wrong animation, then immediatly run `Logic` which is called `OnAnimationStart` (mostly to force filtering for DD-unaware mods that started normal sex), realize the issue with the animation, and run the logic identical to that in `StartValidDDAnimation` that stores items and retries to look for an animation, so the result is: wrong animation starts (by `SelectValidDDAnimations` modified to try until it works) -> belt gets removed (`Logic`) -> another animation starts (`Logic`)

Trying that with creature filter disabled leaves me with the original wrong animation that penetrates the belt, so either way it's less than ideal. (By the way, it also raised my awarness to the fact that disabling the creature filter doesn't disable any filtering done by `SelectValidDDAnimations`, which will always end up with no animations at all without my modifications if the characer is bound. That doesn't sound intentional based on the description of the filter on the MCM)

So, trying to break down the issues, we have:

   A. Why does it pick a vaginal animation when the belt blocks it?

   B. What do we do to avoid the `Logic` filter from effectively filtering twice (I wouldn't want to disable it because DD-unaware mods would have even odder results)

 

3. So, for the solution of A, it turns out `SexLab.GetAnimationsByTags`, which is the function called by the end of `SelectValidDDAnimations` when there is no arm bondage, doesn't function properly with creatures. For some reason you do get animations, but they do not respect the tag. Changing it was not too trivial, because I couldn't find an easy way to determine if an actor is a human or creature, and checking all possible factions is nasty, so I hacked up something like this: First, we attempt to call `SexLab.GetCreatureAnimationsByActorsTags` which respects tags properly. Then if there are no animations, I make sure it was a creature by trying to call ` SexLab.GetCreatureAnimationsByActors` (without tags). I don't really use the animations returned by that function, just that if they are more than 0 then it is a creature so I return an empty list for the outer function to store away some items (like the belt) and try again, and if it is 0 I call the `SexLab.GetAnimationsByTags` because I assume it is a human. Note all that filtering logic still runs even when the creature filter is off.

 

4. At this point, finally wrong animation stopped happening, the belt got removed, and then the game softlocked.  That was because `IsBlockedVaginal` and `IsBlockedAnal` missed a None-check in cases any `Store` function moved the rendered device away, so I switched all things like `!belt.HasKeyword(libs.zad_PermitVaginal)` to `belt && !belt.HasKeyword(libs.zad_PermitVaginal)`

 

5. As for the solution for 2.B, I checked all my mods and found out that usually when `SelectValidDDAnimations` is called, there should be no path where no animation is ran, so I made it set the `SkipFilter` flag for the `Logic` function just like `StartValidDDAnimation` does, and it seems to work.

 

 

Long story short: things I had to change to get bound animations to happen:

1. Wrap `SelectValidDDAnimations` to retry with storing items, like `StartValidDDAnimation` does.

2. Change the SexLab function call for creatures

3. Fix the  `IsBlocked` functions

4. Add a `SkipFilter = true` to the end of `SelectValidDDAnimations`

 

Now, I am pretty sure there were better ways to solve some of the issues, but so far it seems to have got the job done, tested so far and human animations didn't have any issues with coming up, when I am either bound or not.

 

 

Just a few posts ago Kimy mentioned publishing patches against DD is disallowed though, and I have further alterations to the same file (it is all in `zadBQ00.psc`) because I have a personal preference for BJ animations on strapons in case the mouth is the only unoccupied hole to no animations at all in that case and stuff like that. Also, I cannot gurantee I didn't break any other DD mod that exists with that modification, I certainly clearly disrespected the option to disable MCM settings regarding filters and also my code comments are as pricky as they come when I patch things up, so I am kinda not sure about even sharing the modded psc file (not the .pex). I am only suggesting because looking at code and diff might help any of the devs here make sense of my gibberish better so you can come up with a better fix later. Tell me what you think and I can share it if you want me to.

 

 

Sorry for the headache you probably have right now XD

Link to comment

And now for something completely unrelated to my huge post up there. 2 issues I have with AE version of DD for CBBE 3BA

 

1. The rope armbinder is invisible. Just this item as far as I can tell. The character's body is visible and her arms are in place behind her back, just not the ropes themselves. The Strict rope armbinder works great. Also, not sure if that is of any indication, but I pickpocketed the rope armbinder onto some girl and there was no messagebox about me tying her up, and her arms didn't move behind her back (and it does work with all other items that are visible on me, that pickpocketing them onto NPCs functions as binding them).

 

2. I have faster-smp installed and still the chains from the frontal cuffs stutter and shake like crazy even when I stand still and are barely visible.

 

Unlike the previous post in which I might have sounded like I know what's going on, I have absolutely no clue when it comes to rendered devices and HDT. I understand only raw code.

So I obviously batch built in body slide, or else all items would be missing, and I ticked build morphs, and I chose the 3ba option whenever there was one. Besides that, any help would be appreciated XD
 

Link to comment
29 minutes ago, DonQuiWho said:

 

I'm going to go out and plant my daisies

Such comments need a suiting answer, ican´t resist ignoring that-lol.

But I wonder how pretty much ZAP is still a desired mod....with such an oldschool framework which is only a total lack of an asset-collection, degraded as a modder´s resource, just after when I started to add new asset into it.

There´s a mystical call to have zap always ready and most fast available for a more faster download, the bigger the pack is going to be-....immersive crazy!

"t.ara" is here standing for the most slow working creator, ever...LOL

You know what? ...- It´s not me, it is somebody else....!

 

Here, daisies grow up pretty fast...

Edited by t.ara
Link to comment
6 hours ago, thedarkone1234 said:

 

2. I have faster-smp installed and still the chains from the frontal cuffs stutter and shake like crazy even when I stand still and are barely visible.

 

Unlike the previous post in which I might have sounded like I know what's going on, I have absolutely no clue when it comes to rendered devices and HDT. I understand only raw code.

So I obviously batch built in body slide, or else all items would be missing, and I ticked build morphs, and I chose the 3ba option whenever there was one. Besides that, any help would be appreciated XD
 

@Predator-RJ is coincidentally currently trying some things to fix the ever lasting bug in SE with the poisoner chains. The "bungee-cord" is already fixed, but the alignment is still a bit off around the ankles and a chain pileup around the wrists. Hope those can be fixed as well.

Link to comment

I've received permission from @Kimy to post it here, so here goes:

DD to DAR for Skyrim LE

 

Installation instructions:
 

Spoiler

If you didn't have DAR before, grab one here (it's a simple SKSE plugin, install and forget about it). If you did have it installed, check what animations you've got and their priorities, DD's pack has to have the highest priority (largest number) - it's fairly high now (100 000), but I know some animators tend to set theirs priorities in the millions range, so this is worth a check (I use DAR Explorer but a manual check could also work).

 

Install the file I've attached, making sure it overwrites regular DD - so all the files in it are winning against what you've had before (in MO2 that means installing them lower in them mod panel).

 

Backup your FNIS output prior.

Re-run FNIS, so it stops looking for the movement animations to let DAR handle them (you'll also get about a 1000 more free FNIS animations spots, which is nice)

 

Activate both DAR and DD to DAR thing and play the game normally.

 

To uninstall this, delete both DAR and DD to DAR, and restore your fnis output (or just re-run it again without them, so it picks everything back up).

 

Be sure to grab the swimming add-on made by @iivanvv, there's an LE version of it.

 

Oh, and if you're up to it - help me test the newest version of the edited movement script, from my experience it runs better than the one I've included with the conversion. ?

 

Have fun.

 

P.S. Send some love to @Roggvir for coming up with the idea, and to @HexBolt8 for helping me with the LE-specific files and testing this ?

DD to DAR the big conversion LE.7z

Edited by krzp
Link to comment
13 hours ago, naaitsab said:

@Predator-RJ is coincidentally currently trying some things to fix the ever lasting bug in SE with the poisoner chains. The "bungee-cord" is already fixed, but the alignment is still a bit off around the ankles and a chain pileup around the wrists. Hope those can be fixed as well.

The other bugs require it to be essentially be remade from the ground up, which currently does not fit their project schema. But I got permission to share the "bungee rope" fix on here to be merged into the SE build. Tested it using the soft or if you don't want a lagfest a hard-requirement https://www.nexusmods.com/skyrimspecialedition/mods/57339.

 

Thanks @Predator-RJ

Predator_DD_Prisoner_Chains_SMP_FIX.7z

Link to comment

Question for the folks here: is anyone working on changing the VibrateEffect function and related functionality in DD at the moment? The code has some sort of to-do comment to rework it from someone, but I've no idea how long that's been there, nor what they've got planned. I use this functionality a fair bit and I like it, but it has some shortcomings and I'm wondering whether I should just spin my own version (also for forwards compatibility) or whether it's worth getting in touch with someone already working on it.

 

For what it's worth, I think it works quite well at the moment. But there are (for me) three pesky flaws:

  • Multiple calls to VibrateEffect seem to stack, finishing one, then the other, then the next, and so on. I think it would make more sense for calls on the same actor to interrupt and overwrite each other.
  • Related to the previous one, the function is blocking/synchronous, and I don't think there's an asynchronous way to start the effect in a script and then execute the rest of the script (short of moving the rest of the script to something that catches the DeviceVibrateEffectStop modevent). Having a blocking function is useful, because it does make it easy to do things like "VibrateEffect for 30 seconds, then do something else", but also having an asynchronous "StartVibrateEffect" might be useful.
  • I can't use it in a Scene! It calls IsValidActor, which is always false for actors in any scene, and there's no way for me to override that. So for scenes, I currently have to reproduce its functionality myself.

 

Link to comment
48 minutes ago, Frayed said:

Question for the folks here: is anyone working on changing the VibrateEffect function and related functionality in DD at the moment? The code has some sort of to-do comment to rework it from someone, but I've no idea how long that's been there, nor what they've got planned. I use this functionality a fair bit and I like it, but it has some shortcomings and I'm wondering whether I should just spin my own version (also for forwards compatibility) or whether it's worth getting in touch with someone already working on it.

 

For what it's worth, I think it works quite well at the moment. But there are (for me) three pesky flaws:

  • Multiple calls to VibrateEffect seem to stack, finishing one, then the other, then the next, and so on. I think it would make more sense for calls on the same actor to interrupt and overwrite each other.
  • Related to the previous one, the function is blocking/synchronous, and I don't think there's an asynchronous way to start the effect in a script and then execute the rest of the script (short of moving the rest of the script to something that catches the DeviceVibrateEffectStop modevent). Having a blocking function is useful, because it does make it easy to do things like "VibrateEffect for 30 seconds, then do something else", but also having an asynchronous "StartVibrateEffect" might be useful.
  • I can't use it in a Scene! It calls IsValidActor, which is always false for actors in any scene, and there's no way for me to override that. So for scenes, I currently have to reproduce its functionality myself.

 

If I recall correctly it updates the vibrate faction rank so it should stack. But maybe only with identical settings for intensity etc? But in your usecase it might be better if there was a 'stop vibrate' function. Or make it so it substracts if less than already setup for. So if it still goes for 200 seconds and you fire a 150 seconds it should not make it 350 but leave it at 200 because that is less then 150. Guess that is what you are going for?

 

And as suggested before for the 'lockactor' on the Contraptions part should also have a overwrite function to nuke the 'validactor' checks. Or at least overwrite the scene check. As now both functions don't work in scenes. While fine for non scripted, random events, it's not for DD orientated scenes. 

Edited by naaitsab
Link to comment
3 hours ago, naaitsab said:

If I recall correctly it updates the vibrate faction rank so it should stack. But maybe only with identical settings for intensity etc? But in your usecase it might be better if there was a 'stop vibrate' function. Or make it so it substracts if less than already setup for. So if it still goes for 200 seconds and you fire a 150 seconds it should not make it 350 but leave it at 200 because that is less then 150. Guess that is what you are going for?

I was looking at this recently.  There is a stop function, StopVibrating().  It removes the actor from the vibrating faction to stop the process.  Stacking effects are capped at 126 faction rank.

 

3 hours ago, Frayed said:

Related to the previous one, the function is blocking/synchronous, and I don't think there's an asynchronous way to start the effect in a script and then execute the rest of the script (short of moving the rest of the script to something that catches the DeviceVibrateEffectStop modevent).

For my own purposes, I wanted an asynchronous vibration mechanism that also uses a real time duration rather than the faction-based one that decrements with each iteration loop (because the loop's execution time will vary with the player's processor speed, so duration can be somewhat longer than the duration in seconds).  I did this with a spell that uses SetNthEffectDuration for the duration in seconds and does StopVibrating() on effect finish.  That might be something that you'd want to consider.

Edited by HexBolt8
Link to comment
21 minutes ago, HexBolt8 said:

I was looking at this recently.  There is a stop function, StopVibrating().  It removes the actor from the vibrating faction to stop the process.  Stacking effects are capped at 126 faction rank.

 

For my own purposes, I wanted an asynchronous vibration mechanism that also uses a real time duration rather than the faction-based one that decrements with each iteration loop (because the loop's execution time will vary with the player's processor speed, so duration can be somewhat longer than the duration in seconds).  I did this with a spell that uses SetNthEffectDuration for the duration in seconds and does StopVibrating() on effect finish.  That might be something that you'd want to consider.

That's an inherit issue with _a lot_ of timed functions in Skyrim. It's in some degree linked the power of your CPU for the papyrus processing speed. Like the physics system is also tied to the FPS. So the combination is quite unpredictable and I'm not certain your alternative is not effected in the same way. Perhaps a SKSE module that hooks into your PC's time as a sync source exists?

Link to comment
21 minutes ago, naaitsab said:

That's an inherit issue with _a lot_ of timed functions in Skyrim. It's in some degree linked the power of your CPU for the papyrus processing speed. Like the physics system is also tied to the FPS. So the combination is quite unpredictable and I'm not certain your alternative is not effected in the same way.

It could be.  I've never looked at the game's underlying handling for spell durations.  However, the VibrateEffect loop in zadLibs adds some degree of processing time on every iteration (on top of the one-second wait), so I wanted to get away from an effect that increases the longer the vibration continues.  My anecdotal observations, for what that's worth, have been that spell durations are pretty reliable, so I went this route for this particular use.  I just mentioned it for anyone who might be considering other approaches.

Edited by HexBolt8
Link to comment
4 hours ago, naaitsab said:

If I recall correctly it updates the vibrate faction rank so it should stack. But maybe only with identical settings for intensity etc? But in your usecase it might be better if there was a 'stop vibrate' function. Or make it so it substracts if less than already setup for. So if it still goes for 200 seconds and you fire a 150 seconds it should not make it 350 but leave it at 200 because that is less then 150. Guess that is what you are going for?

 

And as suggested before for the 'lockactor' on the Contraptions part should also have a overwrite function to nuke the 'validactor' checks. Or at least overwrite the scene check. As now both functions don't work in scenes. While fine for non scripted, random events, it's not for DD orientated scenes. 

 

1 hour ago, HexBolt8 said:

I was looking at this recently.  There is a stop function, StopVibrating().  It removes the actor from the vibrating faction to stop the process.  Stacking effects are capped at 126 faction rank.

 

For my own purposes, I wanted an asynchronous vibration mechanism that also uses a real time duration rather than the faction-based one that decrements with each iteration loop (because the loop's execution time will vary with the player's processor speed, so duration can be somewhat longer than the duration in seconds).  I did this with a spell that uses SetNthEffectDuration for the duration in seconds and does StopVibrating() on effect finish.  That might be something that you'd want to consider.

 

What prompted the first point was that in Trappings I had multiple possible sources of vibration function calls, some random, some for flavor when certain quest stages were set, some triggered by player action. These could stack, and since the vibrate function can trigger animations that disable player control while they play, it sometimes led to situations where a player just had to watch their character touch themselves for 90 seconds out of two minutes while they wanted to go solve a puzzle. But I didn't consider / realize I could use a StopVibrating() function to prevent stacking. That should already work to allow some control for now: just stop, then restart the vibration. If I need something finer I'll probably take @HexBolt8's suggestion (thanks!).

Link to comment

Not sure if this is the right place for it, but I couldn't really find a thread dedicated to the development of Cursed Loot so I figured I'd just mention this here.

 

I've been testing out the compatibility between DCL and POP, and found that everything works well enough... when combat isn't involved. Surrendering or turning one's self over to the guards means that the percentage slider under DCL's "Prison Settings" will actually function as intended, and send you off either to Dagonar or POP's wild ride based on whatever it is you configured. The issue comes when my character gets beaten to a pulp, given it'll still bring up the dialogue but it'll get very abruptly cut off by DCL's scripted defeat mechanic. Any sort of "major" crime that involves the guards means I'll get hit with that pop-up about how my PC is facing a serious offence, which is shortly followed by the next pop-up that mentions they'll be facing [x] amount of days in Dagonar. To my knowledge, there's currently no good solution within MCM to rectify this. Even flipping on vanilla prisons will trigger a pop-up, interrupt the post-combat dialogue and send you off to jail, skipping the chance for POP to properly fire anyway. 

I think a straightforward solution would be to have a toggle within the MCM to determine whether or not you're eligible to be hit with crime related pop-ups when defeated by a guard. Something to be added under "Prison Settings" along with all the other related gizmos. I'd love to see that be added as a feature for any future DCL release. Hell, if @Kimy doesn't mind, I could even see about making the necessary tweaks and compiling them myself. ?

Link to comment
12 hours ago, Shaeris said:

...

 

To just be little more exact, it is not about commiting a "major" crime but about getting defeated in any context while in proximity of any "guard" faction. You can get burned by the dragon attacking the watchtower and get prison because of the presence of the guards that help you fight it, or get defeated by anyone during the mission with Farkas and get prison because he isn't fully considered your follower and is a "guard" in enough sense. So in general, that pop-up probably needs to have it's chances and reasons sorted out a bit.

 

In general I think such things are more related to DCL support thread though. In general, all mod's support threads are usually considered also their "development threads" except for special cases where they have a separate one like DD does

Edited by thedarkone1234
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