Jump to content

Recommended Posts

Posted
On 1/13/2021 at 11:30 PM, Kharos said:

First option, if you installed standard edition the both collars and remotes should randomly be available at general traders (e.g. trudy, carla, myrna).

 

I feel like this should be a notice in the first post "the collars can occasionally be bought from general goods merchants"

Posted
22 hours ago, nmagod said:

 

I feel like this should be a notice in the first post "the collars can occasionally be bought from general goods merchants"

 

It does.

  

On 3/8/2019 at 12:28 PM, Kharos said:

Description:

Real Handcuffs converts the handcuffs found throughout the Commonwealth to an armor item that can be equipped to bind both the player and NPCs.

Handcuffs can be modified at the armor workbench to make them more secure, or to replace the lock with a timed lock.

You can find handcuffs and keys wherever you find handcuffs normally: Traders who trade misc items (salvage), police stations, and sometimes as random loot. You can also create them yourself, either at the chem workbench or (with the optional AWKCR compatibility plugin) at the AWKCR armor workbench.

Shock collars are now available, too. They and the remote trigger to activate them can be bought at traders, created, and modified at workbenches.

 

 

Posted (edited)
1 hour ago, cockroach666 said:

for some reason, it's causing ctd when i load the game up. this has never happened before. will this mod be updated?

Same here. Wasn't having the issue til i updated to NG.

 

*Edit* after further tweaking mine did just start working again.  In my case it seems to have been other mod dependencies not being filled. Check the notifications button in the top right hand side of MO2.  Its the red triangle.  Make sure there's no warnings except for "There are files in your overwrite directory."

Edited by Cannaisseur
Fixed issue
Posted

Hello,
I found an issue with RealHandcuffs v0.4.17 and HumanResouces. Issue does not appear when using RealHandcuffs v0.4.14. I didn't have this issue a couple years ago, but it appeared after starting to play again and upgrading all the mods to current (and compatible) versions.

I don't have copies of RealHandcuffs versions between to test for which version of RH this issue first appeared. I looked at the code for HumanResouces and the RealHandcuffs API and don't see any issues.

When a HumanResources (HR) NPC is following the player, HR calls RealHandcuffs (RH) API commands StopBoundWaitState, Create HandcuffsEquipOnActor, and SetBoundHandsFollowTarget. The HR NPC equips handcuffs and starts following the player. This part seems to work ok.
When a HR NPC is told to wait. HR calls RH API commands ClearBoundHandsFollowTarget and StartBoundWaitState. The HR NPC keeps wearing the handcuffs, goes to their knees and waits. Issue appears when the player fast travels while the HR NPC is waiting. A couple seconds after arriving at the fast travel destination, will get a CTD everytime. Have occasionally caught the HR NPC running towards the player before CTD. If the handcuffs are unlocked after telling the HR NPC to wait (NPC starts sandboxing instead of kneeling) then can fast travel without a CTD.  HR does not use the command SetPlayerTeammate, just RH API to get HR NPCs to follow the Player.

There is nothing in Papyrus logs or buffout crashlogs (spent days chasing buffout logs before finally figuring this out through testing) that give a reason for the CTD. But will get a CTD everytime a HR NPC is waiting while wearing handcuffs and fast traveling. Other people have reported CTD in similar situations in the HR forum, assuming they are using a newer version of RH based on the date of their posts. Using an older version of HR still has this issue. Changing RH to version 0.4.14 resolves the issue and can fast travel without CTD.

Another issue is when a HR NPC is assigned to a settlement and use the HR option to not remove handcuffs on assignment. Option just sets whether to automatically remove or leave Handcuffs equipped. If the handcuffs are unlocked from the HR NPC (open trade window, unequip handcuffs, use key to unlock) then the pose for wearing handcuffs is removed but the handcuffs remain equipped as braclets. If trade again and try to take the unlocked handcuffs then get a message that handcuffs are added to player inventory and a RH message saying the handcuffs are locked on the HR NPC. The HR NPC resumes the handcuff pose and checking their inventory shows a random handcuff (regular, highsecurity, etc) equipped. Occasionally, after multiple attempts, the handcuffs will finally get removed. Occasionally when trying to remove the handcuffs from the HR NPC, the handcuffs will get equipped on the player and have to attempt to unlock the handcuffs from the player. Also, after getting the handcuffs unlocked and/or removed from the HR NPC, randomly will get a RH message saying the handcuffs were reapplied.
I can not find any code in HR that forces the HR NPC to equip or lock handcuffs if the handcuffs are unlocked by trading and using a key to unlock. The only time HR calls for RH to equip handcuffs is on first creating a HR NPC and telling the HR NPC to follow the Player.
This issue does not appear when using RH version 0.4.14. Can unlock handcuffs without issues.

Is there something that needs changed or added to HumanResouces to allow this to work with RealHandcuffs v0.4.17? Or is this a bug with RealHandcuffs?

I am not using any Devious Devices mods if that matters.

Posted (edited)
On 2/15/2025 at 5:15 PM, Zeke2323 said:

Hello,
I found an issue with RealHandcuffs v0.4.17 and HumanResouces. Issue does not appear when using RealHandcuffs v0.4.14. I didn't have this issue a couple years ago, but it appeared after starting to play again and upgrading all the mods to current (and compatible) versions.

I don't have copies of RealHandcuffs versions between to test for which version of RH this issue first appeared. I looked at the code for HumanResouces and the RealHandcuffs API and don't see any issues.

When a HumanResources (HR) NPC is following the player, HR calls RealHandcuffs (RH) API commands StopBoundWaitState, Create HandcuffsEquipOnActor, and SetBoundHandsFollowTarget. The HR NPC equips handcuffs and starts following the player. This part seems to work ok.
When a HR NPC is told to wait. HR calls RH API commands ClearBoundHandsFollowTarget and StartBoundWaitState. The HR NPC keeps wearing the handcuffs, goes to their knees and waits. Issue appears when the player fast travels while the HR NPC is waiting. A couple seconds after arriving at the fast travel destination, will get a CTD everytime. Have occasionally caught the HR NPC running towards the player before CTD. If the handcuffs are unlocked after telling the HR NPC to wait (NPC starts sandboxing instead of kneeling) then can fast travel without a CTD.  HR does not use the command SetPlayerTeammate, just RH API to get HR NPCs to follow the Player.

There is nothing in Papyrus logs or buffout crashlogs (spent days chasing buffout logs before finally figuring this out through testing) that give a reason for the CTD. But will get a CTD everytime a HR NPC is waiting while wearing handcuffs and fast traveling. Other people have reported CTD in similar situations in the HR forum, assuming they are using a newer version of RH based on the date of their posts. Using an older version of HR still has this issue. Changing RH to version 0.4.14 resolves the issue and can fast travel without CTD.

Another issue is when a HR NPC is assigned to a settlement and use the HR option to not remove handcuffs on assignment. Option just sets whether to automatically remove or leave Handcuffs equipped. If the handcuffs are unlocked from the HR NPC (open trade window, unequip handcuffs, use key to unlock) then the pose for wearing handcuffs is removed but the handcuffs remain equipped as braclets. If trade again and try to take the unlocked handcuffs then get a message that handcuffs are added to player inventory and a RH message saying the handcuffs are locked on the HR NPC. The HR NPC resumes the handcuff pose and checking their inventory shows a random handcuff (regular, highsecurity, etc) equipped. Occasionally, after multiple attempts, the handcuffs will finally get removed. Occasionally when trying to remove the handcuffs from the HR NPC, the handcuffs will get equipped on the player and have to attempt to unlock the handcuffs from the player. Also, after getting the handcuffs unlocked and/or removed from the HR NPC, randomly will get a RH message saying the handcuffs were reapplied.
I can not find any code in HR that forces the HR NPC to equip or lock handcuffs if the handcuffs are unlocked by trading and using a key to unlock. The only time HR calls for RH to equip handcuffs is on first creating a HR NPC and telling the HR NPC to follow the Player.
This issue does not appear when using RH version 0.4.14. Can unlock handcuffs without issues.

Is there something that needs changed or added to HumanResouces to allow this to work with RealHandcuffs v0.4.17? Or is this a bug with RealHandcuffs?

I am not using any Devious Devices mods if that matters.

 

I am not aware of any change that would cause this.

 

Here is the diff between the two versions: https://github.com/RealHandcuffs/RealHandcuffs/compare/0.4.14...0.4.17
This does not show the whole story as there were changes in the plug-ins which cannot be diffed in github as they are binary files.
 

My changelogs for these versions says:
 

Version 0.4.15
==============
tweaks
- update LL FourPlay plugin to v42
- switch to slot 58 for better compatibility with devious devices
- make keeping the slot the default option in the installer
- try to fix power armor helmets being unequipped automatically because of worn collars
- try to fix explosive collar not dismembering player

Version 0.4.16
==============
fix
- change HEDR version to 1.0, this may or may not solve a rare issue with keywords
- change the place that bound workshop NPCs use for "hanging around" to their bed instead of their work place, unless the work place is a 24 hours work place

Version 0.4.17
==============
maintenance
- update LL FourPlay plugin to v46
- change installer to NOT install LL FoudPlay per default if AAF is installed to reduce the number of conflicts
- fix invisible handcuffs with servitron patch (only for the version of that patch that does not include DD changes)
- do not translate targets who's 3D is not loaded

 

Most the changes are minor fixes, but there is a big one: The slot change. I wonder if that is somehow the cause, e.g. code in HR expects the cuffs on the old slot.

 

Are you able to test with 0.4.15 and 0.4.16? This would help us further constrain the change...

Edit: Attached 0.4.15 and 0.4.16 to this post in case you do not have them anymore.

RealHandcuffs.0.4.15.7z

RealHandcuffs.0.4.16.7z

Edited by Kharos
Attachments
Posted
14 hours ago, Kharos said:

 

I am not aware of any change that would cause this.

 

Here is the diff between the two versions: https://github.com/RealHandcuffs/RealHandcuffs/compare/0.4.14...0.4.17
This does not show the whole story as there were changes in the plug-ins which cannot be diffed in github as they are binary files.
 

My changelogs for these versions says:
 

Version 0.4.15
==============
tweaks
- update LL FourPlay plugin to v42
- switch to slot 58 for better compatibility with devious devices
- make keeping the slot the default option in the installer
- try to fix power armor helmets being unequipped automatically because of worn collars
- try to fix explosive collar not dismembering player

Version 0.4.16
==============
fix
- change HEDR version to 1.0, this may or may not solve a rare issue with keywords
- change the place that bound workshop NPCs use for "hanging around" to their bed instead of their work place, unless the work place is a 24 hours work place

Version 0.4.17
==============
maintenance
- update LL FourPlay plugin to v46
- change installer to NOT install LL FoudPlay per default if AAF is installed to reduce the number of conflicts
- fix invisible handcuffs with servitron patch (only for the version of that patch that does not include DD changes)
- do not translate targets who's 3D is not loaded

 

Most the changes are minor fixes, but there is a big one: The slot change. I wonder if that is somehow the cause, e.g. code in HR expects the cuffs on the old slot.

 

Are you able to test with 0.4.15 and 0.4.16? This would help us further constrain the change...

Edit: Attached 0.4.15 and 0.4.16 to this post in case you do not have them anymore.

RealHandcuffs.0.4.15.7z 3.73 MB · 0 downloads

RealHandcuffs.0.4.16.7z 3.73 MB · 1 download

Thanks for looking into this.

As far as I can tell, HumanResouces uses the real handcuffs api to control the handcuffs. But there is a section for other outfits from Hotc. Hotc outfits would conflict with slots if using devious devices. But I am not using devices devices and don't see anything that would conflict with the change from slot 54 to 58.

There an option to prevent unequip items in HR, but I am fairly certain I tested with that enabled and disabled. I can try and test again to be sure.

 

I did not have the other versions of RealHandcuffs. I will see about testing with those versions.

Posted (edited)
On 2/16/2025 at 2:46 PM, Kharos said:

 

I am not aware of any change that would cause this.

 

Here is the diff between the two versions: https://github.com/RealHandcuffs/RealHandcuffs/compare/0.4.14...0.4.17
This does not show the whole story as there were changes in the plug-ins which cannot be diffed in github as they are binary files.
 

My changelogs for these versions says:
 

Version 0.4.15
==============
tweaks
- update LL FourPlay plugin to v42
- switch to slot 58 for better compatibility with devious devices
- make keeping the slot the default option in the installer
- try to fix power armor helmets being unequipped automatically because of worn collars
- try to fix explosive collar not dismembering player

Version 0.4.16
==============
fix
- change HEDR version to 1.0, this may or may not solve a rare issue with keywords
- change the place that bound workshop NPCs use for "hanging around" to their bed instead of their work place, unless the work place is a 24 hours work place

Version 0.4.17
==============
maintenance
- update LL FourPlay plugin to v46
- change installer to NOT install LL FoudPlay per default if AAF is installed to reduce the number of conflicts
- fix invisible handcuffs with servitron patch (only for the version of that patch that does not include DD changes)
- do not translate targets who's 3D is not loaded

 

Most the changes are minor fixes, but there is a big one: The slot change. I wonder if that is somehow the cause, e.g. code in HR expects the cuffs on the old slot.

 

Are you able to test with 0.4.15 and 0.4.16? This would help us further constrain the change...

Edit: Attached 0.4.15 and 0.4.16 to this post in case you do not have them anymore.

RealHandcuffs.0.4.15.7z 3.73 MB · 1 download

RealHandcuffs.0.4.16.7z 3.73 MB · 2 downloads

Started new game with RH 0.4.15
Use HR to capture an NPC.
Leave NPC waiting, handcuffs on, kneeling.
Fast travel and CTD
Tested multiple times reloading save and fast traveling.
Unlock handcuffs with a key.
Fast travel with no CTD.
Created an esp patch and changed the handcuff slots back to 58.
Started a new game and repeated tests. Still would CTD.

Created a new profile in MO2.
Loaded base requirements for a working AAF. Loaded RH 0.4.15 and HR.
Tested as above and no CTD.
Upgraded RH to 0.4.16
Reloaded a save and no CTD
Upgraded RH to 0.4.17
Reloaded a save and no CTD

So seems the issue is not between RH and HR. Something else in my load order is causing a CTD when an NPC is bound and waiting.

Is Papyrus logging supposed to work with RH? I enabled debugging. Set both to information. I see messages on the screen for debugging but nothing appears in the Papyrus logs for RH.

Is there a way to call RH functions from console? I tried cf commands for RH api functions but it said something about the object not being correct for the function.

Working on eliminating mods from my load order to see which may cause the issue. Papyrus logs for RH would help if I can get them working.
Edit: appears that enabling debug trace in fallout ini allows for the Papyrus logs.

Edited by Zeke2323
Posted
17 hours ago, Zeke2323 said:

Started new game with RH 0.4.15
Use HR to capture an NPC.
Leave NPC waiting, handcuffs on, kneeling.
Fast travel and CTD
Tested multiple times reloading save and fast traveling.
Unlock handcuffs with a key.
Fast travel with no CTD.
Created an esp patch and changed the handcuff slots back to 58.
Started a new game and repeated tests. Still would CTD.

Created a new profile in MO2.
Loaded base requirements for a working AAF. Loaded RH 0.4.15 and HR.
Tested as above and no CTD.
Upgraded RH to 0.4.16
Reloaded a save and no CTD
Upgraded RH to 0.4.17
Reloaded a save and no CTD

So seems the issue is not between RH and HR. Something else in my load order is causing a CTD when an NPC is bound and waiting.

Is Papyrus logging supposed to work with RH? I enabled debugging. Set both to information. I see messages on the screen for debugging but nothing appears in the Papyrus logs for RH.

Is there a way to call RH functions from console? I tried cf commands for RH api functions but it said something about the object not being correct for the function.

Working on eliminating mods from my load order to see which may cause the issue. Papyrus logs for RH would help if I can get them working.
Edit: appears that enabling debug trace in fallout ini allows for the Papyrus logs.

 

Ok, so it looks like 0.4.15 is incompatible with another mod (not clear which one) while 0.4.14 is working. The changes from 0.4.14 to 0.4.15 are not that large: https://github.com/RealHandcuffs/RealHandcuffs/compare/0.4.14...0.4.15.

 

One of the changes is the LLFP version, that reminds me: Make sure that you are NOT installing LLFP with RealHandcuffs as doing so might overwrite the one from AAF (and these old versions are outdated). The other changes are the slot change, and a few shock/explosive collar fixes which should in theory not cause issues with handcuffs. Maybe it is the slot change after all? You write that you made a patch to revert it, did you catch all places where it needs to be changed (e.g. both Armor and Armor Addon)?

 

I see you figured out logging, yes you need to enable it in MCM and then also enable it in the ini files.

 

About calling RH functions from console: If I remember correctly you need to user the cqf console command to run RH api functions as RealHandcuffs:ThirdPartyApi is a Quest script, using the RH_MainQuest as <Quest> argument. However if you just need an NPC to wait, you can also put a follower into cuffs and then command them to wait. Maybe you can reproduce the crash like that.

 

 

Posted
4 hours ago, Kharos said:

 

Ok, so it looks like 0.4.15 is incompatible with another mod (not clear which one) while 0.4.14 is working. The changes from 0.4.14 to 0.4.15 are not that large: https://github.com/RealHandcuffs/RealHandcuffs/compare/0.4.14...0.4.15.

 

One of the changes is the LLFP version, that reminds me: Make sure that you are NOT installing LLFP with RealHandcuffs as doing so might overwrite the one from AAF (and these old versions are outdated). The other changes are the slot change, and a few shock/explosive collar fixes which should in theory not cause issues with handcuffs. Maybe it is the slot change after all? You write that you made a patch to revert it, did you catch all places where it needs to be changed (e.g. both Armor and Armor Addon)?

 

I see you figured out logging, yes you need to enable it in MCM and then also enable it in the ini files.

 

About calling RH functions from console: If I remember correctly you need to user the cqf console command to run RH api functions as RealHandcuffs:ThirdPartyApi is a Quest script, using the RH_MainQuest as <Quest> argument. However if you just need an NPC to wait, you can also put a follower into cuffs and then command them to wait. Maybe you can reproduce the crash like that.

 

 

Yeah I looked over the changes in github, doesn't look like anything major.

 

I haven't dug enough into your script to fully understand all the functions. I can fumble my way through the functions but am by no means an expert on coding.

 

I only have LLFP through AAF. I did download LLFP 46 for a test but it didn't resolve any issues so I removed it. Would there be anything in LLFP that could cause this? Really seems to be something conflicting with the repositioning of the bound NPCs. At least that is when the CTD happens.

 

Yes I compared 0.4.14 and 0.4.15 in xedit then made a patch off both armor and armor addon.

 

Will try the console command, not sure I need it as it doesn't seem like an issue with HumanResouces. Thought was to try and get HumanResouces out of the equation.

 

Thanks for the assistance. This one has me really stumped. Fun mods so I don't want to give up trying.

Posted (edited)
6 hours ago, Zeke2323 said:

Yeah I looked over the changes in github, doesn't look like anything major.

 

I haven't dug enough into your script to fully understand all the functions. I can fumble my way through the functions but am by no means an expert on coding.

 

I only have LLFP through AAF. I did download LLFP 46 for a test but it didn't resolve any issues so I removed it. Would there be anything in LLFP that could cause this? Really seems to be something conflicting with the repositioning of the bound NPCs. At least that is when the CTD happens.

 

Yes I compared 0.4.14 and 0.4.15 in xedit then made a patch off both armor and armor addon.

 

Will try the console command, not sure I need it as it doesn't seem like an issue with HumanResouces. Thought was to try and get HumanResouces out of the equation.

 

Thanks for the assistance. This one has me really stumped. Fun mods so I don't want to give up trying.

 

My usual approach at resolving crashes or other errors is:

  1. Try to find steps that are as simple as possible to reproduce the problem (I do not usually play with HR so if you can reproduce without it that would help, e.g. by commanding a follower to wait while cuffed, or by using console commands)
  2. Try to find a minimal set of mods that is necessary to trigger the problem (hopefully activating/deactivating a single mod will make the crash disappear/reappear, but sometimes it is a combination of multiple mods; I usually try to deactivate roughly half of my mods, then in the half that crashes again roughly half, etc. until I find the culprits)
  3. Once I have that I can try to analyze the mods, make changes, etc. No simple recipe at this stage...

Please do tell me if you manage steps 1 & 2, I am currently not playing Fallout 4 so I cannot make any promises but if I have time I may try to figure out what is going on.

Edited by Kharos
Posted
On 2/19/2025 at 1:32 AM, Kharos said:

 

My usual approach at resolving crashes or other errors is:

  1. Try to find steps that are as simple as possible to reproduce the problem (I do not usually play with HR so if you can reproduce without it that would help, e.g. by commanding a follower to wait while cuffed, or by using console commands)
  2. Try to find a minimal set of mods that is necessary to trigger the problem (hopefully activating/deactivating a single mod will make the crash disappear/reappear, but sometimes it is a combination of multiple mods; I usually try to deactivate roughly half of my mods, then in the half that crashes again roughly half, etc. until I find the culprits)
  3. Once I have that I can try to analyze the mods, make changes, etc. No simple recipe at this stage...

Please do tell me if you manage steps 1 & 2, I am currently not playing Fallout 4 so I cannot make any promises but if I have time I may try to figure out what is going on.

So few attempts where I thought I found the mod causing the CTD issue, but turned out that mod wasn't really the culprit. I finally found the mod causing issues. Rusty Face Fix. Disabling the mod or turning off the option streaming_mode

Stopped the CTD. Though in testing, I found that Rusty Face Fix with streaming_mode does not seem to effect every NPC. Seems to be affected by mods that change an NPC. Even though HR basically changes the NPC by copying the NPC to a new NPC, it must be something with the face being copied that triggers Rusty Face Fix. Was primarily using Raiders for testing as there are several spawn spots near vault 111. The single raider at the junkie shack north of Sanctuary wasn't affected but the 4 raiders at the electrical tower south of vault 111 were affected based on the mods I have.

 

So I retested version 0.4.14 and found it would CTD with those raiders and Rusty Face Fix. I hadn't used those in previous play throughs or testing to realize there was an issue.

 

I am able to use version 0.4.17 now. I am not sure if the issue with the handcuffs re-equiping was also caused by Rusty Face Fix but there is no issue now.

 

On another note, through testing, I noticed that NPCs from Wastland Dairy would give a message that RH unequipped handcuffs and removed the wait marker after fast traveling away then added them back when moved back towards the NPC. Is this a function of RH? Seems to make sense that a waiting NPC only needs the waitingforplayer property and stick to a pose when the player is in the same area. Then again, Wasteland Dairy may be able to regenerate the marker only because that is where the NPC spawned. 

Unlocking and relocking the handcuffs would remove the waitingforplayer property and the pose. Fast traveling would then not trigger the fixing position so wouldn't cause the CTD.

 

Would be nice to be able to use the Streaming_mode with Rusty Face Fix, but understand if that conflict is not fixable in RH.

 

Thanks for the great mod and the support.

Posted (edited)
15 hours ago, Zeke2323 said:

So few attempts where I thought I found the mod causing the CTD issue, but turned out that mod wasn't really the culprit. I finally found the mod causing issues. Rusty Face Fix. Disabling the mod or turning off the option streaming_mode

Stopped the CTD. Though in testing, I found that Rusty Face Fix with streaming_mode does not seem to effect every NPC. Seems to be affected by mods that change an NPC. Even though HR basically changes the NPC by copying the NPC to a new NPC, it must be something with the face being copied that triggers Rusty Face Fix. Was primarily using Raiders for testing as there are several spawn spots near vault 111. The single raider at the junkie shack north of Sanctuary wasn't affected but the 4 raiders at the electrical tower south of vault 111 were affected based on the mods I have.

 

So I retested version 0.4.14 and found it would CTD with those raiders and Rusty Face Fix. I hadn't used those in previous play throughs or testing to realize there was an issue.

 

I am able to use version 0.4.17 now. I am not sure if the issue with the handcuffs re-equiping was also caused by Rusty Face Fix but there is no issue now.

 

On another note, through testing, I noticed that NPCs from Wastland Dairy would give a message that RH unequipped handcuffs and removed the wait marker after fast traveling away then added them back when moved back towards the NPC. Is this a function of RH? Seems to make sense that a waiting NPC only needs the waitingforplayer property and stick to a pose when the player is in the same area. Then again, Wasteland Dairy may be able to regenerate the marker only because that is where the NPC spawned. 

Unlocking and relocking the handcuffs would remove the waitingforplayer property and the pose. Fast traveling would then not trigger the fixing position so wouldn't cause the CTD.

 

Would be nice to be able to use the Streaming_mode with Rusty Face Fix, but understand if that conflict is not fixable in RH.

 

Thanks for the great mod and the support.

 

I have no idea how Rusty Face Fix even conflicts with RH, as it is mainly a F4SE plug in; the esp only adds a single perk. So I cannot help there.

I am currently not playing Fallout 4, but looking at my last load order I was using Rusty Face Fix 2.0.2 (https://www.nexusmods.com/fallout4/mods/31028) without any crashes, though without streaming mode. The ini file was set to:

facegen_player = 1
facegen_npcs = 1
streaming_mode = 0
fast_mode = 0
refresh_equipment = 0
excluded_races = DLC05ArmorRackRace
debug_mode = 0

If I remember correctly it mostly worked; for the few situations where I did get rusty faces, I just used the rff console command to fix them if it bothered me.

 

> On another note, through testing, I noticed that NPCs from Wastland Dairy would give a message that RH unequipped handcuffs and removed the wait marker after fast traveling away then added them back when moved back towards the NPC. Is this a function of RH?
 

Nope, if you set a NPC to wait then that should persist even after traveling away, otherwise they might start going into your direction again. This sounds like an actual compatibility problem, for example maybe Wasteland Diary is resetting NPC's inventory when the player is away?

 

[Edit] Need to explain the last part better. If the message is from RH then it acted because it detected an unexpected situation. This can be caused by other mods resetting the inventory of NPCs or otherwise doing things with them that I did not anticipate while writing RH.

Edited by Kharos
Posted
3 hours ago, Kharos said:

 

I have no idea how Rusty Face Fix even conflicts with RH, as it is mainly a F4SE plug in; the esp only adds a single perk. So I cannot help there.

I am currently not playing Fallout 4, but looking at my last load order I was using Rusty Face Fix 2.0.2 (https://www.nexusmods.com/fallout4/mods/31028) without any crashes, though without streaming mode. The ini file was set to:

facegen_player = 1
facegen_npcs = 1
streaming_mode = 0
fast_mode = 0
refresh_equipment = 0
excluded_races = DLC05ArmorRackRace
debug_mode = 0

If I remember correctly it mostly worked; for the few situations where I did get rusty faces, I just used the rff console command to fix them if it bothered me.

 

> On another note, through testing, I noticed that NPCs from Wastland Dairy would give a message that RH unequipped handcuffs and removed the wait marker after fast traveling away then added them back when moved back towards the NPC. Is this a function of RH?
 

Nope, if you set a NPC to wait then that should persist even after traveling away, otherwise they might start going into your direction again. This sounds like an actual compatibility problem, for example maybe Wasteland Diary is resetting NPC's inventory when the player is away?

 

[Edit] Need to explain the last part better. If the message is from RH then it acted because it detected an unexpected situation. This can be caused by other mods resetting the inventory of NPCs or otherwise doing things with them that I did not anticipate while writing RH.

Yes that is the version of rusty face fix that I was using. From what I read in the posts and bugs of the mod, the settings streaming_mode and refresh_equipment can cause issues or CTD. Seemed like the conflict is with RH waiting. When fast traveling the NPC seems to teleport to you then the RH script catches them and moves them back. Since the NPC is in the same cell, rusty face fix with streaming_mode tries to refresh the NPC. I believe both the refresh and the move happening at the same time are causing the CTD. I had a couple test cases where a message box from another mode appeared after fast travel, I could see the waiting RH bound NPC at the edge of the screen behind the message box. The NPC would disappear after closing the message box. This did seem to delay some things to allow one function to finish and I wouldn't CTD, but fast traveling again would cause a CTD when no message box appeared.

 

That is what lead to my other question. Seems like the property WaitingforPlayer triggers the game to teleport the NPC with the player when fast traveling. If the WaitingforPlayer property is removed when the player leaves the area then hopefully the NPC doesn't teleport with the player and just stays where they are. Then add the WaitingforPlayer property when the player comes back to where the NPC is located. That would remove the potential conflict. No clue if that would effect or break other parts if RH though. Just a thought if you get back to Fallout and decide to work on updating RH.

 

For now I am good with leaving streaming_mode off in Rusty Face Fix.

  • 1 month later...
Posted
12 minutes ago, Dang3ru5 said:

i have an errorwhen equipping the handcuffs on an npc:

"Unable to find MT animation Keyword for FF04881A"

does anyone know what the problem is?

image.thumb.jpeg.a2320e39f2d54e855a959c53dd1622ab.jpeg

i have the newerst AAF installed and the Real Handcufs are without LLFP

Posted
4 minutes ago, killa124 said:

so i need help bcuz everytime i install this mod it just crashes my game and i cant seem to figure it out

sooooooooo, after turning off the devious device compatibility esp and only starting with the realhandcuffs esp it worked no more crashes

Posted (edited)
On 3/31/2025 at 8:58 AM, Dang3ru5 said:

i have the newerst AAF installed and the Real Handcufs are without LLFP


I appear to have the same issue.  I also have the latest AAF installed.  Any assistance would be appreciated.

 

Edit:  I have noticed that my AAF is stuck at 80% initializing.  Not sure if the reason it isn't working or not but will do a reply to the quote above if it turns out to be the cause.

Edit 2:  After updating to the latest AAF via the Discord, the problem persists.

Edited by jaketagret
Posted
38 minutes ago, Limbic2Node said:

Hello.

Any way to stop being handcuffed as player? Any scripts I could remove etc. Thank you.

Real Handcuffs doesn't handcuff you, that is done via other mods like Violate and Sexual Harassment, for example.

So you can stop using mods that handcuff you. Or adjust their restraint settings.

  • 3 weeks later...
Posted (edited)
On 12/23/2024 at 7:34 AM, Gravidx said:

Okay scratch that I really wish I knew how to delete comments even if there was a way so I didn't type out 3 separate responses I'm sorry lol. Anyway found the hacker guy in the Dugout Inn and can get mine off no problem, but what about my companions? 

Is that the only way? I got the collar from harrasment and know who approached me but he doesn't have the code. Who has it then?

Edited by xyzxyz

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...