Jump to content

Recommended Posts

1 hour ago, Karna5 said:

Kziitd and EgoBallistic, I feel compelled to express what an amazing expression of art you made with this mod. It's way more than a replacement for Devious Devices. It's way more than bondage apparel. The detail of the meshes and textures are incredible, but it's still way more than that. From the expressive movements of each piece, from the variations with fear and anger of headgear, from the aesthetic beauty and variations of everything.

 

I mentioned this in the screen shot thread, but I think this mod opens so many doors to expressive art in Fallout 4. For instance, that Clockwork Orange headgear you made is amazing. I'm so delighted by it, and I was immediately compelled to make a film with it not as an expression of bondage but as an expression of madness and insanity. It's so wonderful! Thanks a million for sharing this mod. I mean it.

 

 

  Hide contents

 

 

 

Thanks for the compliment, but I need clarification.
Most of KFT's resources come from DAZ's resources, of which the author named DAVO is their original author. I just ported them to the game and modified/made some ropes/leather items myself. If we talk about the production ratio, between me and DAZ/any other resources it is 5 (created/modified)/5 (unchanged).
As for utilizing fo4's face tri value/body slider, that's my job.
So I'll take your compliments, but not all of them.😘

Edited by kziitd
Link to comment
5 minutes ago, kziitd said:

So I'll take your compliments, but not all of them

That's nice to know about the original meshes and textures, but as I said, your mod exceeds the quality of the meshes. You really took it to an art form of both expressiveness and humanity.

 

On a related note, I saw someone ask for male ports of this, and I had to laugh to myself because I don't think that person realized exactly how much work you put into making this fit and work exactly perfectly for Fusion Girl. I can't imagine a male port could be done as well in less than hundreds of hours. The fit, bone weighting, morphs and vertices are so precise.

Link to comment
29 minutes ago, Karna5 said:

That's nice to know about the original meshes and textures, but as I said, your mod exceeds the quality of the meshes. You really took it to an art form of both expressiveness and humanity.

 

On a related note, I saw someone ask for male ports of this, and I had to laugh to myself because I don't think that person realized exactly how much work you put into making this fit and work exactly perfectly for Fusion Girl. I can't imagine a male port could be done as well in less than hundreds of hours. The fit, bone weighting, morphs and vertices are so precise.

Yes, the focus is on the slider.
Bone weights are relatively easy.
The slider needs to be like a uniboob and remain stable without twisting/losing compression under any changes. The results of each slider in KFT's FG are not automatically applied by the OS.
There are a lot less cbbe sliders than FG, so I thought there might be time to do that. (After processing the AAF animation).
The same goes for male content, as long as it's not the bear-like body look that Ulf likes, it's easier to produce than an extreme breast size slider for female.

Link to comment

@EgoBallistic

There is an issue with the script somewhere that will cause body restraints (not gags) to un equip fully/normally or partially, ie: still rendered on the PC but standing & allowed to run, sprint access to Pip-Boy....

To replicate... good chance anyway.

KFT Settings:

Debug Unlock On
Struggle maxed out

Frogtie 100%

 

Location:

Diamond City main gate

 

Actions:

Spawn in 20 Raiders, shoot a DC Guard and a Raider so everybody is pissed.

Surrender or loose.

IF it's going to replicate the bug, at the end of a scene the PC will stand up and then back down in the restrained animation.

 

Levels of bug: 3

 

Okay Bug:

It "usually" only takes 2 scenes for the frogtie to be removed properly. ie; like manually removing it.

 

Sorta okay bug:

IF it really bugs out, your PC will stand up with the frogtie equipped between scenes.  It's un equipped "effects wise, but still rendered on the PC and can show as worn in the Pip-Boy.

 

Catastrophic Bug: Rather rare!

When you access the Pip-Boy it will get stuck trying to exit with only the bottom overlay menu showing and a paused game.

The fix is to load an earlier save. (prolly a console command to force close it dunno)

Link to comment
5 minutes ago, izzyknows said:

IF it's going to replicate the bug, at the end of a scene the PC will stand up and then back down in the restrained


What do you mean by “Scene” here?  An AAF animation?  Why is the body restraint being unequipped?

Link to comment
58 minutes ago, EgoBallistic said:

What do you mean by “Scene” here?  An AAF animation?

Sex scene... animation... round...

 

59 minutes ago, EgoBallistic said:

Why is the body restraint being unequipped?

Asking the wrong peon there bud! 🤣

Link to comment

I encountered a bug with the devices where if I struggle with it on and manage to get a key, it would succeed in unlocking the device only for it immediately reequip itself. Seems like there a bugged script where the generic unequip prevention system is erroneously triggered by the struggle script.

Link to comment
7 minutes ago, kazeha9 said:

soo if you start SH aproach NPC always pick device from dd do we need to patch it manualy that NPC chose from KFT? or mb im doing something wrong via load order or instal )

 

Twitsted has to update its code with KFT in mind. 

Link to comment
On 3/30/2024 at 4:08 PM, EgoBallistic said:

 

Load order for this mod doesn't matter.  The mouth opening feature uses the morph functions from the LL_FourPlay library that comes with AAF.  If that is not working, either because it is missing or the version of F4SE you are using is not compatible with it, then gags won't work properly.

I have the same issue. I have AAF installed, F4SE, and all other mods work, but gags just don't affect expressions. It's fare to say that DD gags don't affect facial expressions too with your mod for this installed. I use GOG version

Link to comment
3 hours ago, izzyknows said:

Sex scene... animation... round...

 

Asking the wrong peon there bud! 🤣

 

Well, AAF and/or Violate shouldn't be stripping the devices off, because KFT includes an AAF ProtectedDevice XML so neither mod will remove the devices.

 

I tested with Violate and AAF Beta 172, with Violate configured to apply restraints at start of scene, and KFT configured with Frogtie 100% and Global Unlock On.  Everything worked as expected, meaning the devices were applied and never removed until the violation ended and I struggled out of them.

 

So that's why I ask why the body restraints are being removed in your case, because AAF and Violate can't do it as configured.  If you are seeing unexpected behavior, in order to reproduce it I need to know whether the device is simply being removed and reapplying itself (potentially with AAF trying to re-dress something it thinks it removed), or if a conflicting item is being equipped, etc.

Link to comment
43 minutes ago, Derenriche said:

I encountered a bug with the devices where if I struggle with it on and manage to get a key, it would succeed in unlocking the device only for it immediately reequip itself. Seems like there a bugged script where the generic unequip prevention system is erroneously triggered by the struggle script.

 

The unequip prevention is built into the device scripts themselves.  When a device gets the event telling it that it has been unequipped, it checks whether it should allow it to happen or whether it should re-equip itself.  In the case of a struggle, if you succeed the Global Unlock is applied, the device is removed, and the Global Unlock is turned back off after one second.

 

If you turn on the Global Unlock in the MCM Debug menu, the struggle routine skips all that and just plays the struggle animation then removes the device, without turning the Global Unlock back off afterward.

 

Could you test with the Global Unlock turned on in MCM and see if the re-equip still happens?  That should tell us if it is a timing issue or something else.

Link to comment
31 minutes ago, deoprad said:

I have the same issue. I have AAF installed, F4SE, and all other mods work, but gags just don't affect expressions. It's fare to say that DD gags don't affect facial expressions too with your mod for this installed. I use GOG version

 

Well like I told the other poster, the facial expressions use the MFG Morph routines from the LL_FourPlay library which is included with AAF.  The DD mod uses the exact same code.  So my guess is the LL_FourPlay library isn't loading, or is too old (although that would mean older than AAF Beta 103 which is truly ancient).

Link to comment
3 minutes ago, EgoBallistic said:

 

Well like I told the other poster, the facial expressions use the MFG Morph routines from the LL_FourPlay library which is included with AAF.  The DD mod uses the exact same code.  So my guess is the LL_FourPlay library isn't loading, or is too old (although that would mean older than AAF Beta 103 which is truly ancient).

I use 171 and facial expressions apply during blowjob scenes

Link to comment
27 minutes ago, EgoBallistic said:

 

The unequip prevention is built into the device scripts themselves.  When a device gets the event telling it that it has been unequipped, it checks whether it should allow it to happen or whether it should re-equip itself.  In the case of a struggle, if you succeed the Global Unlock is applied, the device is removed, and the Global Unlock is turned back off after one second.

 

If you turn on the Global Unlock in the MCM Debug menu, the struggle routine skips all that and just plays the struggle animation then removes the device, without turning the Global Unlock back off afterward.

 

Could you test with the Global Unlock turned on in MCM and see if the re-equip still happens?  That should tell us if it is a timing issue or something else.

 

I tested with global unlock turned on and it will play the animation and unequip devices, but then proceed to immediately reequip them. What does work is if I use MCM debug menu to unequip all devices.

 

I looked at the script and initially suspected timing issue as well since the onunequip event handler is asynchronous to the main script, but it looks like something else is causing this. I was going to try and debug this myself, but I don't have a convenient way of recompiling the script for test changes.

Link to comment
Posted (edited)
44 minutes ago, Derenriche said:

I looked at the script and initially suspected timing issue as well since the onunequip event handler is asynchronous to the main script, but it looks like something else is causing this. I was going to try and debug this myself, but I don't have a convenient way of recompiling the script for test changes.

 

Here are the three core scripts recompiled with debug enabled.  They have a fair bit of log output that may shed some light on this.  When I equip a set of devices and struggle out of them, I get this in the log:

 

[04/01/2024 - 05:25:53PM] KZEB_API: Player has 90% chance to escape restraints, rolled 64
[04/01/2024 - 05:25:53PM] KZEB_BondageDeviceScript: actor [Actor < (00000014)>] unequipped [Form < (11000A49)>]
[04/01/2024 - 05:25:53PM] KZEB_BondageDeviceScript: actor [Actor < (00000014)>] unequipped [Form < (11000A49)>]
[04/01/2024 - 05:25:53PM] KZEB_BondageDeviceScript: actor [Actor < (00000014)>] unequipped [Form < (11000A49)>]
[04/01/2024 - 05:25:53PM] SetPlayerHandRestraints: set to [None]
[04/01/2024 - 05:25:53PM] KZEB:KZEB_DeviceBase - moved from None to [Actor < (00000014)>] actorContainer is [Actor < (00000014)>]
[04/01/2024 - 05:25:53PM] TryToUnequip [kzeb:kzeb_boundhandsdevicescript <Item 21 in container  (00000014)>] from [Actor < (00000014)>] in [Actor < (00000014)>] equipped 46.826004 sec LockState True GlobalUnlock True

 

Could you reproduce the problem with these installed and report back?  Just install with your mod manager and allow it to override the 3 scripts from KFT.

 

KFT_DebugScripts1.0b1.7z

Edited by EgoBallistic
Link to comment
1 hour ago, EgoBallistic said:

 

Here are the three core scripts recompiled with debug enabled.  They have a fair bit of log output that may shed some light on this.  When I equip a set of devices and struggle out of them, I get this in the log:

 

[04/01/2024 - 05:25:53PM] KZEB_API: Player has 90% chance to escape restraints, rolled 64
[04/01/2024 - 05:25:53PM] KZEB_BondageDeviceScript: actor [Actor < (00000014)>] unequipped [Form < (11000A49)>]
[04/01/2024 - 05:25:53PM] KZEB_BondageDeviceScript: actor [Actor < (00000014)>] unequipped [Form < (11000A49)>]
[04/01/2024 - 05:25:53PM] KZEB_BondageDeviceScript: actor [Actor < (00000014)>] unequipped [Form < (11000A49)>]
[04/01/2024 - 05:25:53PM] SetPlayerHandRestraints: set to [None]
[04/01/2024 - 05:25:53PM] KZEB:KZEB_DeviceBase - moved from None to [Actor < (00000014)>] actorContainer is [Actor < (00000014)>]
[04/01/2024 - 05:25:53PM] TryToUnequip [kzeb:kzeb_boundhandsdevicescript <Item 21 in container  (00000014)>] from [Actor < (00000014)>] in [Actor < (00000014)>] equipped 46.826004 sec LockState True GlobalUnlock True

 

Could you reproduce the problem with these installed and report back?  Just install with your mod manager and allow it to override the 3 scripts from KFT.

 

KFT_DebugScripts1.0b1.7z 16.94 kB · 0 downloads

[04/01/2024 - 04:06:31PM] KZEB_API: Player has 115% chance to escape restraints, rolled 33
[04/01/2024 - 04:06:31PM] KZEB_BondageDeviceScript: actor [Actor < (00000014)>] unequipped [Form < (10000A6D)>]
[04/01/2024 - 04:06:31PM] SetPlayerHandRestraints: set to [None]
[04/01/2024 - 04:06:31PM] KZEB_BondageDeviceScript: actor [Actor < (00000014)>] equipped [Armor < (3C01030A)>]
[04/01/2024 - 04:06:31PM] KZEB_BondageDeviceScript: actor [Actor < (00000014)>] unequipped [Armor < (3C01030A)>]
[04/01/2024 - 04:06:31PM] SetPlayerLegRestraints: set to [None]
[04/01/2024 - 04:06:31PM] KZEB:KZEB_DeviceBase - moved from None to [Actor < (00000014)>] actorContainer is [Actor < (00000014)>]
[04/01/2024 - 04:06:32PM] KZEB_BondageDeviceScript: OnEquipped from [Actor < (00000014)>]
[04/01/2024 - 04:06:32PM] KZEB:KZEB_DeviceBase - in Enabled state and equipped by [Actor < (00000014)>]
[04/01/2024 - 04:06:32PM] TryToUnequip [kzeb:kzeb_boundhandsdevicescript <Item 32 in container  (00000014)>] from [Actor < (00000014)>] in [Actor < (00000014)>] equipped 0.091995 sec LockState True GlobalUnlock True
[04/01/2024 - 04:06:32PM] SetPlayerHandRestraints: set to [Leather-Belts-frogtie(TapeHands) (10000a6d)]
[04/01/2024 - 04:06:32PM] RegisterSingleKey : Pipboy scancode = 9
[04/01/2024 - 04:06:32PM] RegisterSingleKey : Pipboy scancode = 277
[04/01/2024 - 04:06:32PM] RegisterSingleKey : QuickInventory scancode = 73
[04/01/2024 - 04:06:32PM] SetPlayerLegRestraints: set to [Leather-Belts-frogtie(TapeHands) (10000a6d)]
[04/01/2024 - 04:06:33PM] KZEB_BondageDeviceScript: refresh
[04/01/2024 - 04:06:33PM] SetPlayerHandRestraints: set to [Leather-Belts-frogtie(TapeHands) (10000a6d)]
[04/01/2024 - 04:06:33PM] RegisterSingleKey : Pipboy scancode = 9
[04/01/2024 - 04:06:33PM] RegisterSingleKey : Pipboy scancode = 277
[04/01/2024 - 04:06:33PM] RegisterSingleKey : QuickInventory scancode = 73
[04/01/2024 - 04:06:34PM] SetPlayerLegRestraints: set to [Leather-Belts-frogtie(TapeHands) (10000a6d)]

Link to comment
49 minutes ago, Derenriche said:

[04/01/2024 - 04:06:31PM] KZEB_BondageDeviceScript: actor [Actor < (00000014)>] equipped [Armor < (3C01030A)>]
[04/01/2024 - 04:06:31PM] KZEB_BondageDeviceScript: actor [Actor < (00000014)>] unequipped [Armor < (3C01030A)>]

 

What is a 3C01030A ?  It looks like it got equipped and unequipped right at the same time as the KFT device.  I think the timing on that that might be triggering the logic that makes KFT items re-equip themselves if an NPC equips another wearable item.

Link to comment

It's from the mod High Heel Training. I think there is a conflict there where it is attempting to auto equip it's own feet model after being stripped by KFT and this is causing a conflict here. I disabled the mod and things work properly now.

 

I think the unequip system needs to be reworked a bit as the current iteration is a bit problematic even if we don't take into account timing issues. What about having a map of devices stored in the main quest script with key of actor+device to be stored with a boolean value of true when flagged to be unequipped? If flagged as legitimate removal the value will be found in the map by the tryunequip function and then it will allow the unequip while removing the value from the map. This removes the dependency on a global variable shared across many potential condition checks.

Edited by Derenriche
Link to comment
2 minutes ago, Derenriche said:

It's from the mod High Heel Training. I think there is a conflict there where it is attempting to auto equip it's own feet model after being stripped by KFT and this is causing a conflict here. I disabled the mod and things work properly now.

 

Interesting, thank you.  I'll install that mod and play around with it.  I think there will be other mods that equip items on the player when the player unequips a conflicting device, so I will need to make a general fix for this.  Thinking about it, I am not sure if the KFT re-equipping code that is being triggered here is necessary on the player, so the solution may simply be to add a condition so it only happens on NPCs.

 

Thanks again for helping debug this.

Link to comment
16 minutes ago, EgoBallistic said:

 

Interesting, thank you.  I'll install that mod and play around with it.  I think there will be other mods that equip items on the player when the player unequips a conflicting device, so I will need to make a general fix for this.  Thinking about it, I am not sure if the KFT re-equipping code that is being triggered here is necessary on the player, so the solution may simply be to add a condition so it only happens on NPCs.

 

Thanks again for helping debug this.

Can confirm that it was High Heel Training on my side as well

Link to comment

New Version 1.0 Beta 2 Uploaded

Main File and Compatibility Patches have been updated, Bodyslide and Texture files are unchanged.

  • Added MCM options to disable/enable restraints by material type (leather, metal, rope, etc.)
  • Fixed race condition in unequip code that could cause restraints to be re-equipped after player struggled out of them if another wearable item was equipped at the same time the restraints were being unequipped
  • Fixed Leather Leg Cuffs Stocking Version missing Leg Underarmor slot
Link to comment

I'm just going to say that I adore the mod concept and I absolutely love seeing modders see the potential fun and joy in having this being compatible with their mods. Watching this in real-time is genuinely uplifting. I love this community. :classic_smile:

Link to comment
8 hours ago, EgoBallistic said:

I think there will be other mods that equip items on the player when the player unequips a conflicting device, so I will need to make a general fix for this.

 

 

I think Combat Stip Lite damaged body sections causes a fight between the remove/add scripts of the two mods if you overlap body parts covered by both mods. My PC was caught in a perma equip-unequip loop, that I could break by force curing all damaged body parts in CSL, during the loop. The safe bet is probably to only allow CSL to damage body parts not covered by the new framework, which I am guessing I can find in Xedit (or you have a handy list...).

 

Have to say, when I saw my character end up in tape on her knees and started crawling, I was also tempted to copy her and fall to my knees in praise of you all.

Edited by Nuka Cherry
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
×
×
  • 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