Jump to content

Devious Devices Framework Development/Beta


Recommended Posts

 

 

Still getting the 'stuck animation' when the armbinder is removed.

Was with the black ebonite one from DDx, removal via dialogue and DCUR removal. Same effect. Also armbinder combat is stil enabled while the animation is stuck.

 

Running the latest build but didn't start a new game after the latest update.

This really should be impossible. The AA evaluation should fire regardless of how the device is removed. It's literally in the same event that allows it to be unequipped in the first place.

 

What dialogue are you using by the by? We disabled the DDi one.

 

Anyways could you start a new game and check? And make double sure you're running the latest build? And post your papyrus log?

 

I think the dialogue was also from DCUR, not sure about that but the removal command was deffo from DCUR. The option to remove it via DDi dialogue is gone, I checked that.

AFAIK is the removal command just the regular device removal command that iterates all equipped items/tags so I don't think that should be an issue. But I don't know for sure as the Dcur beta for the new DD system isn't released yet. Maybe Kimy could determine if that could be the issue or not.

 

 

I started a new game with a fresh zip from DDi and DDx dev repro's yesterday evening (GMT) after the 'locks' update, replacing the existing beta, reran bodyslide and FNIS.

Log from new game (2 parts, don't know what you're searching for exactly):

https://pastebin.com/C796YtzV

 

 

Hummm... it definitely worked before the locks update but it's possible the manipulation option broke it again. I'll see if I can reproduce it.

Link to comment

 

 

 

Still getting the 'stuck animation' when the armbinder is removed.

Was with the black ebonite one from DDx, removal via dialogue and DCUR removal. Same effect. Also armbinder combat is stil enabled while the animation is stuck.

 

Running the latest build but didn't start a new game after the latest update.

This really should be impossible. The AA evaluation should fire regardless of how the device is removed. It's literally in the same event that allows it to be unequipped in the first place.

 

What dialogue are you using by the by? We disabled the DDi one.

 

Anyways could you start a new game and check? And make double sure you're running the latest build? And post your papyrus log?

 

I think the dialogue was also from DCUR, not sure about that but the removal command was deffo from DCUR. The option to remove it via DDi dialogue is gone, I checked that.

AFAIK is the removal command just the regular device removal command that iterates all equipped items/tags so I don't think that should be an issue. But I don't know for sure as the Dcur beta for the new DD system isn't released yet. Maybe Kimy could determine if that could be the issue or not.

 

 

I started a new game with a fresh zip from DDi and DDx dev repro's yesterday evening (GMT) after the 'locks' update, replacing the existing beta, reran bodyslide and FNIS.

Log from new game (2 parts, don't know what you're searching for exactly):

https://pastebin.com/C796YtzV

 

 

Hummm... it definitely worked before the locks update but it's possible the manipulation option broke it again. I'll see if I can reproduce it.

 

 

Tested just now. Tried the black ebonite armbinder both with and without manipulating the lock, used the DCL free me function both times, worked like a charm and my papyrus log output all the debug messages I expected.

 

This is what your log should be saying after you remove the device:

[07/22/2017 - 05:06:34PM] [Zad]: RemoveDevice called for Black Ebonite Armbinder
[07/22/2017 - 05:06:34PM] [Zad]: Acquired mutex, removing Black Ebonite Armbinder
[07/22/2017 - 05:06:34PM] [Zad]: OnUnequipped(Nozomi: Black Ebonite Armbinder)
[07/22/2017 - 05:06:34PM] [Zad]: Detected removal token. Done.
[07/22/2017 - 05:06:34PM] [Zad]: OnEffectFinish(): Wrist Bondage
[07/22/2017 - 05:06:34PM] [Zad]: UpdateControls()
[07/22/2017 - 05:06:34PM] [Zad]: EvaluateAA([Actor < (00000014)>])
[07/22/2017 - 05:06:34PM] [Zad]: UpdateControls()
[07/22/2017 - 05:06:35PM] [Zad]: EvaluateAA: Reverting to unbound AA
[07/22/2017 - 05:06:35PM] FNIS aa SetAnimGroup mod: DeviousDevices actor: Nozomi group: _h2heqp base: 0 number: 0
[07/22/2017 - 05:06:35PM] FNIS aa SetAnimGroup mod: DeviousDevices actor: Nozomi group: _h2hidle base: 0 number: 0
[07/22/2017 - 05:06:35PM] FNIS aa SetAnimGroup mod: DeviousDevices actor: Nozomi group: _h2hatkpow base: 0 number: 0
[07/22/2017 - 05:06:35PM] FNIS aa SetAnimGroup mod: DeviousDevices actor: Nozomi group: _h2hatk base: 0 number: 0
[07/22/2017 - 05:06:35PM] FNIS aa SetAnimGroup mod: DeviousDevices actor: Nozomi group: _h2hstag base: 0 number: 0
[07/22/2017 - 05:06:35PM] FNIS aa SetAnimGroup mod: DeviousDevices actor: Nozomi group: _jump base: 0 number: 0
[07/22/2017 - 05:06:35PM] FNIS aa SetAnimGroup mod: DeviousDevices actor: Nozomi group: _sneakmt base: 0 number: 0
[07/22/2017 - 05:06:35PM] FNIS aa SetAnimGroup mod: DeviousDevices actor: Nozomi group: _sneakidle base: 0 number: 0
[07/22/2017 - 05:06:35PM] FNIS aa SetAnimGroup mod: DeviousDevices actor: Nozomi group: _sprint base: 0 number: 0
[07/22/2017 - 05:06:35PM] FNIS aa SetAnimGroup mod: DeviousDevices actor: Nozomi group: _shout base: 0 number: 0
[07/22/2017 - 05:06:35PM] FNIS aa SetAnimGroup mod: DeviousDevices actor: Nozomi group: _mtx base: 0 number: 0
[07/22/2017 - 05:06:36PM] FNIS aa SetAnimGroup mod: DeviousDevices actor: Nozomi group: _mt base: 0 number: 0
[07/22/2017 - 05:06:36PM] FNIS aa SetAnimGroup mod: DeviousDevices actor: Nozomi group: _mtturn base: 0 number: 0
[07/22/2017 - 05:06:36PM] FNIS aa SetAnimGroup mod: DeviousDevices actor: Nozomi group: _mtidle base: 0 number: 0

Are you sure you don't have any outdated mods overriding framework scripts? That's the only logical explanation left.

Link to comment

Tested just now. Tried the black ebonite armbinder both with and without manipulating the lock, used the DCL free me function both times, worked like a charm and my papyrus log output all the debug messages I expected.

 

This is what your log should be saying after you remove the device:

x

[/code]

Are you sure you don't have any outdated mods overriding framework scripts? That's the only logical explanation left.

Hmm very strange. In the MO there are 0 files overwritten or being conflicted by another mod on both DDx and DDi file level.

I also can't think of any mod that would break the equip/unequip logic like this :(

Link to comment

 

I tested the new build and I noticed I can struggle out of devices every time even though I locked it on my character. This may require more investigation.

 

I tested this and cannot confirm this. When I put devices on me, I can remove the manipulated ones right away, but not the properly locked ones, regardless in what order I equipped them.

 

 

I checked it. Character struggles out of straight jackets with 100% success rate even when set to born slave difficulty.

Does anyone else still have problems with animations getting stuck after unequipping wrist restraints?

 

Animation gets stuck but is fixed by jumping or using "player.sae hugA" in console.

Link to comment

 

 

I tested the new build and I noticed I can struggle out of devices every time even though I locked it on my character. This may require more investigation.

 

I tested this and cannot confirm this. When I put devices on me, I can remove the manipulated ones right away, but not the properly locked ones, regardless in what order I equipped them.

 

 

Apparently I am stupid. I set the success chance to 100% when testing stuffz and forgot to change it back.. :s

 

Link to comment

 

Animation gets stuck but is fixed by jumping or using "player.sae hugA" in console.

 

 

W... H... how?

 

girl_bomb_blank_stare_41175_602x339.jpg

 

Nuh uh this is not a bug report that's possible. Fixing it by jumping would indicate that an offset animation is applied. No offset animations are ever applied on the player character. I refuse, there's no way we derped that badly.

 

Could you pastebin your papyrus log for me please?

Link to comment

 

 

 

I tested the new build and I noticed I can struggle out of devices every time even though I locked it on my character. This may require more investigation.

 

I tested this and cannot confirm this. When I put devices on me, I can remove the manipulated ones right away, but not the properly locked ones, regardless in what order I equipped them.

 

 

Apparently I am stupid. I set the success chance to 100% when testing stuffz and forgot to change it back.. :s

 

 

 

Meh. It happens.

Link to comment

 

 

Animation gets stuck but is fixed by jumping or using "player.sae hugA" in console.

 

 

W... H... how?

 

girl_bomb_blank_stare_41175_602x339.jpg

 

Nuh uh this is not a bug report that's possible. Fixing it by jumping would indicate that an offset animation is applied. No offset animations are ever applied on the player character. I refuse, there's no way we derped that badly.

 

Could you pastebin your papyrus log for me please?

 

 

I don't know how to do this. I am a potato you will have to help me.

Link to comment

@princess, updating USLEEP from 2 releases ago to the latest seems to have fixed the issue..

I started 3 new games and now the Ebonite armbinder equip -> unequip via DCUR works as intended every time.

 

Took a while to find it out and not sure why USLEEP would interfere with DDi like this. As I can't find any overlap

Link to comment

 

 

 

Animation gets stuck but is fixed by jumping or using "player.sae hugA" in console.

 

 

W... H... how?

 

girl_bomb_blank_stare_41175_602x339.jpg

 

Nuh uh this is not a bug report that's possible. Fixing it by jumping would indicate that an offset animation is applied. No offset animations are ever applied on the player character. I refuse, there's no way we derped that badly.

 

Could you pastebin your papyrus log for me please?

 

 

I don't know how to do this. I am a potato you will have to help me.

 

 

Where papyrus logs are located and how to generate one is explained in detail here (under the Sexlab Troubleshooting Instructions section).

 

Also, I'm going to need some more information. Exactly what restraints did you have equipped at the time? Were you using an old save and/or devices spawned before that session or did you spawn new instances? What other ZAP, Sexlab and DD mods do you have installed?

Link to comment

@princess, updating USLEEP from 2 releases ago to the latest seems to have fixed the issue..

I started 3 new games and now the Ebonite armbinder equip -> unequip via DCUR works as intended every time.

 

Took a while to find it out and not sure why USLEEP would interfere with DDi like this. As I can't find any overlap

 

Ohh? That's... super weird but thank you for letting us know!

 

I don't know why USLEEP would affect anything but if the latest version fixed that then... I guess I'm relieved it's not on our end?

 

But just to let me sleep at night, could you please run a few more tests to confirm? ^^ I'd like to eliminate the possibility that it's a random race condition tied to either game performance, multithreading or papyrus load.

Link to comment

 

@princess, updating USLEEP from 2 releases ago to the latest seems to have fixed the issue..

I started 3 new games and now the Ebonite armbinder equip -> unequip via DCUR works as intended every time.

 

Took a while to find it out and not sure why USLEEP would interfere with DDi like this. As I can't find any overlap

 

Ohh? That's... super weird but thank you for letting us know!

 

I don't know why USLEEP would affect anything but if the latest version fixed that then... I guess I'm relieved it's not on our end?

 

But just to let me sleep at night, could you please run a few more tests to confirm? ^^ I'd like to eliminate the possibility that it's a random race condition tied to either game performance, multithreading or papyrus load.

 

Do you have any preference on what to test? I got the new game running so I can test a few things.
Link to comment

 

 

@princess, updating USLEEP from 2 releases ago to the latest seems to have fixed the issue..

I started 3 new games and now the Ebonite armbinder equip -> unequip via DCUR works as intended every time.

 

Took a while to find it out and not sure why USLEEP would interfere with DDi like this. As I can't find any overlap

 

Ohh? That's... super weird but thank you for letting us know!

 

I don't know why USLEEP would affect anything but if the latest version fixed that then... I guess I'm relieved it's not on our end?

 

But just to let me sleep at night, could you please run a few more tests to confirm? ^^ I'd like to eliminate the possibility that it's a random race condition tied to either game performance, multithreading or papyrus load.

 

Do you have any preference on what to test? I got the new game running so I can test a few things.

 

 

The same thing. Try unequipping different wrist restraints manually and via scripted means.

Link to comment

The same thing. Try unequipping different wrist restraints manually and via scripted means.

Tried the yoke from DDi, ebo armbinder from DDx, steel handcuffs from DDx and yoke from DDx (DCUR one, wich BTW does not equip properly)

On all items it works as intended now :)

Link to comment

The new hoods seemed to be fixed in the new patch but the ebonite mask still looks like it was made for a horror mod.

 

 

Edit: Also the long gloves won't equip when wearing the catsuit.

 

Thanks! Headless gasmask and invisble long gloves should both be fixed with today's DDx update.

 

Link to comment

Here's my first somewhat more detailed test of the new DDi NPC sandboxing thing (sorry, don't quite know how to name it)...from the GitHub page:

 

Experimental fix for bound NPCs executing sandbox packages breaking their animations.

Needs -thorough- testing!

 

I started a new game (LAL) and went to Whiterun, added armbinders, handcuffs, yokes or straitjackets to every NPC in town (the Manipulator Mod is very useful for this, it allows quick and easy access to any character's inventory in the game). Then I observed what the NPCs did:

 

1) NPCs that usually use objects in their daily routines (lean on furniture, sit, use cookpots, etc.) stop doing that as soon as equipped with wrist restraints. Instead they walk to a nearby spot and idle around there. Hulda would walk a few feet from the bar and stand there, then walk to and fro occasionally. NPCs at the market acted similarly.

 

2) When interacting with NPCs (I asked Hulda to rent a room), they seem to do what they're supposed to while staying bound. Hulda walked up to the first floor and back downstairs without breaking the bound anims.

 

3) In the inn, when the Bard starts to sing and the NPCs gather around cheer and drink, that seems to break the wrist restraint override and they still get their hands free and do the drinking/hands clapping/drunk dancing anims. It's so far the only occurance that I've seen where that happens for non-follower NPCs. I'll keep looking for others.

 

4) NPCs that are scheduled to walk around town seem to stop doing that, besides Ysolda and Danica I also tested that on two of the hydra captives that are being walked through town by a guard. They stopped following the guard and remained in the spot where I had equipped them with the restraints.

 

5) When going through a load door, all restrained NPCs start at their usual locations (like Hulda with her hands on the bar counter, Saadia using the cook pot etc.), but they immediately stop doing whatever they are doing and return to the restrained idling from 1)

 

6) Followers are a slightly different issue. When they are not allowed to sandbox, they remain tied up all the time while following the player around. With sandboxing enabled though (custom followers, sandboxing through EFF, AFT etc.), they start approaching their sandboxing destination when the player stands still, then begin using it and immediately stop it again like as if a battle between the sandboxing and the restraints was going on. Example: follower walks to a chair, still tied up -- hands flip out of bound anim as follower sits down -- follower stands right back up again and reverts to bound anims.

So there's an easy fix/workaround here on the user's side: just disable follower sandboxing.

 

7) Log is clean it seems, all I see are numerous entries like these:

[07/25/2017 - 06:29:12PM] [Zad]: ApplyBoundAnim()
[07/25/2017 - 06:29:14PM] [Zad]: ApplyBoundAnim()
[07/25/2017 - 06:29:17PM] [Zad]: ApplyBoundAnim()
 

Link to comment

Odd, I thought I excluded followers from the override. I will check into it. But glad to hear that it otherwise seems to work, mostly. :)

 

Come to think of it: I'm not sure if it has been like that before or not, so please don't read too much into my statement regarding followers. In my "normal" gameplay, I only very rarely have a follower wearing an armbinder by my side (unless DCL just sprang a trap on us, lol) and usually play with follower sandboxing switched off in EFF, so it's possible that what I described above has been normal DD+follower behavior for ages.

Link to comment

I came back from testing and I found my character became opaque when wearing the transparent zipsuit (catsuit) UUNP HDT. The new catsuit boots are now called gloves when taking them off which is silly. I noticed that the catsuit ballet boots sounded too normal so I checked TES5 Edit and noticed that none of the new boots in the Armor add-on have a footstep sound set up for it yet.

post-816100-0-20075000-1501112166_thumb.jpg

post-816100-0-93841700-1501112198_thumb.jpg

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