Jump to content

Devious Devices - Integration 4.3a (2019-09-10)

Min

By Min,
in Downloads - SexLab Framework LE

Recommended Posts

onlytrans

onlytrans

Posted
Posted
5 hours ago, merManc said:

 

I don't know what the cause of the crashing would be, but it sounds like the menu options you're asking about are the Devices Underneath system. This is designed to allow you to have items in certain equip slots invisible when wearing something in another slot. If the SE version works the same way, you should see that slots 49, 51, 56 and 58 are listed in the four entries under slot 32 by default. This means that when wearing anything in slot 32 (the main body armour/clothing slot) anything worn in those other four slots will be invisible, so they won't clip. In devious terms, those four slots are chastity belts, nipple piercings, chastity bras and harnesses/corsets.

 

If you set 38 in any of the four entries for slot 38, it would mean that equipping something in slot 38 would make anything equipped in slot 38 invisible - including the item you just equipped.

 

As you're playing SE, you may have better luck getting help with the crashing in the DD SE support topic. Good luck!

 

Ok, ok.. So i had how this works basically backwards. I thought I needed to enable those slot to have things appear when in fact they do just the opposite. TY for that information.  Yea im not sure about the crashing, im not blaming any one thing. It just usually happens when my character has mulitple devices added to her. Game freezes and crashes, at no otherpoint does it do this.

 

but!, i will forward my issues to the other forum as not to clutter this one. tyvm for your time!

darktej

darktej

Posted
Posted
1 hour ago, onlytrans said:

 

Ok, ok.. So i had how this works basically backwards. I thought I needed to enable those slot to have things appear when in fact they do just the opposite. TY for that information.  Yea im not sure about the crashing, im not blaming any one thing. It just usually happens when my character has mulitple devices added to her. Game freezes and crashes, at no otherpoint does it do this.

 

but!, i will forward my issues to the other forum as not to clutter this one. tyvm for your time!

I maybe wrong here but anyone please correct me if I am mistaken. saying that...I think the reason why your game maybe crashing could be that you have installed high resolution textures (when it comes to the devices) and by equipping multiple restraints that is overworking the game and perhaps that is leading to the crash. this may be not optimal but could you re-install with lower textures and see whether it still crashes? 

stobor

stobor

Posted
Posted

With the new version, gags no longer retain the 'mouth open' facial expression; they start with that expression, but seldom keep it for long - and once they revert to the default expression, they never seem to go back to 'mouth open'.

WaxenFigure

WaxenFigure

Posted
Posted
10 minutes ago, stobor said:

With the new version, gags no longer retain the 'mouth open' facial expression; they start with that expression, but seldom keep it for long - and once they revert to the default expression, they never seem to go back to 'mouth open'.

Read back a few pages, the "fix" you can use until the next version is discussed.

Lupine00

Lupine00

Posted
Posted

A curiousity...

 

Kimy never uses ManipulateGenericDevice or ManipulateGenericDeviceByKeyword with equipOrUnequip set to true, only with false.

 

Does that mean that the equip path of that function is not well tested and can't really be trusted?

I guess the main ManipulateDevice with true doesn't have much room to go wrong, as it calls almost straight through to EquipDevice or RemoveDevice, but the generic device functions are more complex, with various 'optimisations' and checks.

 

 

The name of the parameter equipOrUnequip is somewhat misleading, as it suggests it toggles the item state if true, and does nothing if false.

Examination of the function code suggests otherwise though.

 

Presumably, it should have been called requiredEquipState. or something like that?

swords and sandals

swords and sandals

Posted
Posted
2 hours ago, LetheOminous said:

I don't know if I am in the right place. When my characters hands are shackled the "Fist unequipped" notification and sound keeps looping and its getting annoying.

 

That sounds like SPERG, which is listed in the Compatibility and Conflicts section. It automatically equips "fists" when you have no other weapons equipped. So, dd removes weapons when binding you, prompting SPERG to equip fists, prompting dd to remove them, prompting SPERG to equip them again, prompting dd to remove them again, and so on.

 

Set SPERG's unarmed mode to Manual to prevent that. The side effect is that the fists will become an item in your inventory you can't drop without them being forced back in, and you will have to equip them yourself when you want to use them. Unfortunately, disabling the unarmed feature in SPERG doesn't actually seem to disable it - or didn't when I last used it, at least - so, manual is the only way around this issue if you want to use both mods.

Lupine00

Lupine00

Posted
Posted

What is the preferred (most efficient way) to lock a device (remove the manipulation that allows removal without a key) - if present - and do nothing if absent?

 

If my NPC sees the PC wandering about with some devices on, and wants to check they are properly locked on, what is the best way to go about it?

 

I don't see anything exposed for this in the main zadLibs, so you would seem to need to remove the device and re-equip it?

That's far from ideal. I can't believe that would be the intended solution.

 

I know the DCL has some functionality like this, but that's a bit of a needle+haystack search.

MariSkyrimNerd

MariSkyrimNerd

Posted
Posted
1 hour ago, merManc said:

 

That sounds like SPERG, which is listed in the Compatibility and Conflicts section. It automatically equips "fists" when you have no other weapons equipped. So, dd removes weapons when binding you, prompting SPERG to equip fists, prompting dd to remove them, prompting SPERG to equip them again, prompting dd to remove them again, and so on.

 

Set SPERG's unarmed mode to Manual to prevent that. The side effect is that the fists will become an item in your inventory you can't drop without them being forced back in, and you will have to equip them yourself when you want to use them. Unfortunately, disabling the unarmed feature in SPERG doesn't actually seem to disable it - or didn't when I last used it, at least - so, manual is the only way around this issue if you want to use both mods.

Thank you for the quick response I will try that :)

Mr Technician

Mr Technician

Posted
Posted

Does anybody know a way how to run manually script zadBQ00, can it be exucuted by inputing any console command? ?

Also please don't give reply that it should run by itself. I already know that. TY

Kimy

Kimy

Posted
Posted
10 hours ago, Lupine00 said:

A curiousity...

 

Kimy never uses ManipulateGenericDevice or ManipulateGenericDeviceByKeyword with equipOrUnequip set to true, only with false.

 

Does that mean that the equip path of that function is not well tested and can't really be trusted?

I guess the main ManipulateDevice with true doesn't have much room to go wrong, as it calls almost straight through to EquipDevice or RemoveDevice, but the generic device functions are more complex, with various 'optimisations' and checks.

 

 

The name of the parameter equipOrUnequip is somewhat misleading, as it suggests it toggles the item state if true, and does nothing if false.

Examination of the function code suggests otherwise though.

 

Presumably, it should have been called requiredEquipState. or something like that?

This function was implemented by Min years before he passed DD to me. Personally, I don't see a use-case for calling it to equip devices, so I only ever use it to unequip devices. This doesn't necessarily mean that the function is not to be trusted, it just means that Kimy doesn't see a need for it and probably would have implemented it for removing devices only. :D

Kimy

Kimy

Posted
Posted
2 hours ago, piotsze said:

Does anybody know a way how to run manually script zadBQ00, can it be exucuted by inputing any console command? ?

Also please don't give reply that it should run by itself. I already know that. TY

Why would you want to do it? Did the script stop working for you?

Lupine00

Lupine00

Posted
Posted
16 hours ago, Kimy said:

Personally, I don't see a use-case for calling it to equip devices, so I only ever use it to unequip devices.

And the question about locking manipulated devices? I know it's a different kind of manipulation :)

I guess I'll re-quote it:

On 9/27/2019 at 4:19 PM, Lupine00 said:

What is the preferred (most efficient way) to lock a device (remove the manipulation that allows removal without a key) - if present - and do nothing if absent?

 

If my NPC sees the PC wandering about with some devices on, and wants to check they are properly locked on, what is the best way to go about it?

 

I don't see anything exposed for this in the main zadLibs, so you would seem to need to remove the device and re-equip it?

That's far from ideal. I can't believe that would be the intended solution.

 

I know the DCL has some functionality like this, but that's a bit of a needle+haystack search.

Is there a way to do this efficiently via the API?

Obviously, there is a state in the object that indicates if it is really locked, or just pretend (closed, manipulated?)

I want to go through the DD API, so it doesn't create a fragile binding to code that might get changed.

 

But I don't want to use that... Unless it's a StorageUtil variable, which would be super-convenient.

1
Kimy

Kimy

Posted
Posted

The manipulate lock feature is designed to offer a way for the user to wear a device for "fun", and allow them to remove it at any time. I did not design a way into the framework to allow locking such a device after the fact. If you want to write a feature doing this, you would probably need to check for the device worn, unequip it and replace with a locked version of the same device.

DayTri

DayTri

Posted
Posted

Does DDI_DeviceRemoved ModEvent send only when the player removes the device through the normal menu, or is it triggered by mods removing it too?

 

I am trying to keep a count of equipped devices without dependency by counting the equipped devices and removals. I can't seem to catch removal by cursed loot at the end of quests or when the free me debug option is used.

Reesewow

Reesewow

Posted
Posted

 

7 hours ago, Lupine00 said:

If my NPC sees the PC wandering about with some devices on, and wants to check they are properly locked on, what is the best way to go about it?

*PC who often wears required Devious Follower items with manipulated locks starts sweating profusely and eyeing her willpower stat*

5
Lupine00

Lupine00

Posted
Posted
12 hours ago, Kimy said:

If you want to write a feature doing this, you would probably need to check for the device worn, unequip it and replace with a locked version of the same device.

Urgh. That's what I was trying to avoid.

 

The remove-re-add cycle is inherently perilous - a race condition nightmare.

 

DCL runs into this problem often enough:

Devices are removed, then new ones added ... but the old ones aren't fully removed when the new ones try to fit, both devices end screwed up, one sort of fitted, the other sort of not.

In some cases even removing the devices and getting them from containers, DD panic button, and DCL free me cannot fix it.

 

I think it might be safe if I spin wait for the device to be gone, but I'm not 100% sure even that is infallible.

And what if a user sneaks in a device equip while I'm doing it? Then I spin wait until some long timeout and have to start over?

 

 

Now, I believe the DD mutex system is supposed to stop that, but it doesn't, and never has - even if people don't disable the mutex, and it's disabled by default - which is weird.

That design choice causes all kinds of bad interactions between mods because most mods use default values, so skipMutex = True for almost all API functions.

 

It should be the reverse. You should have to go to considerable trouble to avoid taking the mutex. I believe this wasn't done because it was constantly locking up, and not unlocking when it should - and that's due to errors that have probably been there since day one:
(a) common paths where it fails to get unlocked when it should get unlocked, and,

(b) it isn't actually a mutex so fails due to race conditions anyway.

 

 

The mutex is written in Papyrus, so it won't really work. Instead it just sort of helps a bit.

The test and the update are not atomic. That's why I had to write a real mutex for SLAX.

I know the Papyrus threading model is supposed to help you here, but the spin wait contains log calls, and a sleep, and a shortish timeout, and that means all bets are off.

e.g.

  EndWhile

  log("SpinLock() Completed. Cycles:" + timeout)

EndIf

DeviceMutex = false ; immediately reacquire lock

But it IS NOT immediate, you called log. This might happen 20 seconds after the EndWhile. You have no way to know how long it will be.

 

That said, even a brief perusal of the mutex logic easily finds cases where it has nasty surprises for the user, such as it isn't cleared after being taken, unless skipEvents is true or there's an actual conflict. Clearly, if it is only released in that case, then it should only be taken in that case. Or more clearly, if you take it, you must release it, and that isn't the case. Unless there's something else in play I missed, in which case, great!

 

My initial conclusion is that the mutex code is not really maintained or tested, and contains obvious hazards (you can argue whether they are outright bugs), but there can be no argument that it is not a true mutex and is subject to race condition failures, it's more like the pirate code than a reliable mechanism for preventing race-conditions or conflicts in equip.

 

 

These functions are likely old, and the bad paths and poor decisions regarding the mutex are likely historical artifacts. There hasn't been much attention given to them, or they wouldn't be like this. Perhaps it's time for a review?

 

I think fixing them properly would make a lot of other race-condition nonsense just go away.

 

Personally, I'd fix the mutex so it really works, and then clean up all the API functions so mutex is always used.

Leave the old skipMutex flag in the calls, but ignore it and mark it deprecated.

 

Then... Add a function you can call prior to do anything to disable mutex checks (you must call to re-enable after you're done) for those cases where you believe mutex checks can be skipped - and the code to turn off mutex checks would need to take the mutex, so two mods can't use it at once.

 

Another thing that's needed is that mutex release shouldn't happen until the scripts in the objects have finished.

This means that the API functions need to do something like...

  • Update an atomic counter prior to invoking the object script.
  • The object script needs to decrement that counter on completion.
  • The mutex cannot be taken if the counter is not zero.
  • StorageUtil counter on the target object should be atomic enough.

(And with timeouts for when scripts crash out etc)

This would work for the multi-operation mechanic shown above.

 

And for all the old mods that are unaware of this change, they'd get one-by-one operation with mutex, which is probably what they should have had all along.

 

 

I hadn't realised it was so in need of love, or I would have done it myself months ago. I probably have too much on my plate to care right now.

 

Kimy

Kimy

Posted
Posted

As you pointed out correctly, the mutex has never really worked well enough to justify using it, but it's a severe performance hog that will cause noticeable lag in scenarios when multiple devices are manipulated. I found that most of the time, a simple Utililty.Wait(1.5) between unequip and reeuip will do nicely, though. It's a very simple solution and a very inelegant one, but it works.

worik

worik

Posted
Posted

Probable bug report for DD4.3a

  • bound in Laura's STC yoke, harness, gag, arm+leg cuffs
  • able to gag-talk with carriage drivers
  • unable to use the carriage, the activator to "climb" into the carriage seems disabled
  • comments indicate this to be unintended and a general DD issue

 

More details:

donttouchmethere

donttouchmethere

Posted
Posted
13 hours ago, worik said:

Probable bug report for DD4.3a

  • bound in Laura's STC yoke, harness, gag, arm+leg cuffs
  • able to gag-talk with carriage drivers
  • unable to use the carriage, the activator to "climb" into the carriage seems disabled
  • comments indicate this to be unintended and a general DD issue

 

More details:

I don't think it's a bug, more like a fast travel prevention ;D

Weee that's an old one, guess it's since the DD/ZAZ split.

Heavy bondage prevents you from using furniture and carriages.

 

Main issue with that "feature" => zaz furniture can't be used and will get quest scenes stuck that need you to be in zaz furniture to continue.

 

1
Lupine00

Lupine00

Posted
Posted
18 hours ago, Kimy said:

but it's a severe performance hog that will cause noticeable lag in scenarios when multiple devices are manipulated.

I don't doubt it, though part of that may be due to it not being released when it should.

A mechanism where you could pre-lock the mutex would solve any performance issue for mods that were new enough to use it.

In that case they have to provide their own wrapping lock and unlock calls that disable mutex checks in the individual API calls.

 

I suppose it's also possible to use a bit-locking mechanic, similar to that used in SLAX that would allow you to "mask" locking based on slot masks, so devices with no conflict can get a lock immediately, and only devices with conflicting slots result in lock waits.

 

The device operation completion tracking is another issue again; that would solve all those issues we see now where slot-overlapping devices get in races with each other.

 

But I appreciate that if I don't implement it, and just expect it to magically happen, then it's just a lot of wishful thinking, so I guess I'll leave that there for now.

 

 

 

However, would be nice if the API could - one day - gain a way to modify a device's "genuinely locked" status.

I haven't looked at how hard it is, but I'd have though there was just a piece of state to flip somewhere?

 

That would be a generally useful new capability, and one that has been requested previously, I think?

While it might not have been envisaged in the design of that feature, it would still be useful.

It would be a nice additional action for NPCs to perform in DCL, as part of the "device comments" feature, for example.

And DF has immediate uses for it, which is why I brought it up.

Mr Technician

Mr Technician

Posted
Posted
10 hours ago, donttouchmethere said:

I don't think it's a bug, more like a fast travel prevention ;D

Weee that's an old, guess it's since the DD/ZAZ split.

Heavy bondage prevents you from using furniture and carriages.

 

Main issue with that "feature" => zaz furniture can't be used and will get quest scenes stuck that need you to be in zaz furniture to continue.

 

Oh... That's good to know also.

Thank You! ? 

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
Go to topic listing

  • Recently Browsing   0 members

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