Jump to content

Kharos

Members
  • Content Count

    529
  • Joined

  • Last visited

4 Followers

About Kharos

  • Rank
    Senior Member

Recent Profile Visitors

2,368 profile views
  1. Yes, I am trying to make my mod such that upgrading mid game is always safe. The first time when you load your game with the new version, an installer script will run and upgrade. Depending on how many NPCs are wearing handcuffs or collars, this can take up to a minute.
  2. 😂 yeah that is clearly an incompatibility, maybe you can modify cheat-terminal to ignore handcuffs...
  3. Version 0.4.10 ============== various small improvements - add quick inventory interaction (disbled by default, can be enabled in hotkeys MCM page) - put handcuffs on captives in some vanilla scenes and random encountes (only in standard edition, not in lite edition) - JB Integration: allow enslaving NPCs by equipping shock collars on them (requires confirmation by default, setting in shock collar MCM page) - fix a race condition preventing correct transfer of multiple items (e.g. handcuffs and collar) to clones - small ThirdPartApi fix and improvement The integration of handcuffs into vanilla scenes is very new, please tell me if you spot problems. This does not include the kidnap quests, but it should work with various random encounters (e.g. raiders/mutants with prisoners) and a few static scenes (e.g. prisoner in Out of the Fire quest).
  4. Cool. May I request a hopefully simple fix? There are a few situations where enslaving a NPC will break vanilla quests. Examples include the Mechanist and Nisha. The reason is that some items (key cards/passwords in this case) only spawn in the inventory of the NPC after death of the NPC. I think (I have not tested this) that you could fix this generically in CreateClone(...) by waiting a second or two after killing the original and then moving all items from the original to the clone using akTarget.RemoveAllItems(akTargetClone). If you don't want to delay CreateClone(), you could do this in a separate function and call it using CallFunctionNoWait(...).
  5. This is a misunderstanding about the functionality of "interact with NPC". This hotkey does not allow you to put handcuffs on a NPC or anything like that. In the moment it only allows you to change the pose of NPCs who are assigned to prisoner mats (I might add more functionality in the future). If you want to put handcuffs on a NPC, you will either need a way to access the inventory of the NPC so you can manually put them on the NPC. Or alternatively another mod needs to provide a way. I do not know how Crime And Punishment woks, but it is possible that it allows you to access the inventory? Reading the Freeze page it might not be compatible at the moment.
  6. What happens when you tell her that you want to trade items and try to unequip the handcuffs?
  7. What kind of Gag? I am asking because panel gags have a history of causing issues, at least for me. If I understand correctly they are technically working different, the "model" that you see is not directly from the rendered device, it is added by a magic effect (to allow different models for plug and without plug). Sometimes the magical effect can get "lost", for example in some loading screens. The armbinder has no key (e.g. the deviceKey property of zad_armBinderInventory is set to None). I have seen this previously, but I assumed it was on purpose. Can you confirm that it is on purpose @Kimy?
  8. To be fair, ZAP8+ is huge (much, much larger than ZAP 7 was). Using its keywords would make it a hard dependency for DD. Having such large dependencies is not good. It is especially not good if your mod is a framework mod that is in turn a dependency of many other mods. I think not having that dependency is technically the right decision, even if it causes issues for some other mods (e.g. PAHe not recognising DD gags).
  9. Thanks, will fix in the next release.
  10. So... it is possible that I am not making sense here with my limited knowledge, or that I am misunderstanding what you write above, or that I am misunderstanding the current implementation. But if I understand you correctly you are saying that the current implementation uses an alternate code path for NPCs that does not depend on unequip events because these events are unreliable for NPCs. My question about having two code paths was basically the other way around: If you already have an alternate code path for NPCs that does not depend on unequip events, is there a good reason to keep the code path that depends on these events for the PC? Naively thinking it would seem to be easier to have a single code path (e.g. less code == less bugs). Also if I understand you correctly the edge case is mainly because the event is happening async to the UnlockDevice()/LockDevice() call; would this mean that the NPC code path will not have the edge case?
  11. Ok, that sounds really promising. I assume that there are good reasons to keep two code paths, instead of just handling NPCs and PC identically in UnlockDevice() and fully getting rid of the event? Well... that's an obvious question so the answer is probably "yes indeed", sorry . Hmm... how do I say this in a diplomatic way... you may not intend that, but you really come over as talking down from the high horse here. In my personal experience people are usually more happy to help me when I refrain from doing that. [Edit] Reading that again I failed to be diplomatic. Basically I want to say that my first reaction reading your post was a strong feeling that it will make matters worse, not better.
  12. Yeah, I fully agree about waiting in UnlockDevice()/LockDevice(), it will make code that (un)locks multiple devices really slow which is definitively not something that we want. That's why I asked if it is possible to instead recognize the 1% case in the LockDevice that follows the UnlockDevice and do some additional corrective action (e.g. unequip the rendered device that conflicts with the new one that we want to equip). [Edit] Fixed confusing use of unlock/lock, sorry!
  13. It's not nice, but short term, you could try waiting a bit longer to catch cases with heavy script load: Bool isEquipped = true If (libs.UnlockDevice(Playerref, BellsInventory, destroyDevice = True)) isEquipped = PlayerRef.IsEquipped(BellsRender) Int waitCount = 0 While (isEquipped && waitCount < 20) ; or whatever number you are comfortable with instead of 20 Utility.Wait(0.1) isEquipped = PlayerRef.IsEquipped(BellsRender) waitCount = waitCount + 1 EndWhile EndIf If (isEquipped) ; failed to unequip (either UnlockDevice returned false, or Player.IsEquipped was true after trying 20 times) Else ; succeeded EndIf I have used similar ugly code in my FO4 mod when waiting for events doing something. [Edit] It's also very much not nice from an API POV that UnlockDevice returns true but calling LockDevice directly afterwards will then fail. This would catch me off-guard as a developer using the API. @Kimy would it be possible to detect the problem (old rendered device still equipped) in LockDevice and take corrective action there? Or is that not possible because the two cases (device not equipped but old rendered devices still equipped, device actually equipped) will look the same?
  14. Yes. The only thing RH and AAF have in common is the LL FourPlay community F4SE Plugin. In the general case you should be fine by just using the newer plugin (e.g. if there is a new AAF version with a new plugin, just override mine). In this particular case it is not a problem at all because both are using the same version of the plugin (v39).
×
×
  • Create New...