Compatibility issue with Useful Houses mod(22.7+)

[BouncyWouncyWoo]

Recent versions of OBSE appear to have an issue with the mod Useful houses by theNiceOne. I've tried running it with several different versions and the last compatible version was 22.6.1. The mod uses OBSE to alter some of the properties of repair hammers and the players repair efficacy depending on whether or not they are in a player or faction owned cell.

With the 22.7 and over versions of OBSE the mod breaks player repair entirely, any attempt repair will cause the durability number to go up, but then it will reset if another item is selected for repair, and after closing the repair menu, non of the changes will be applied to the weapons or armours repaired.

[llde]

Hi @BouncyWouncyWoo, this is in fact a regression from fb0ad1a980b91f42bfce2739f53b3204147b66ea.

A workaround is to put bWriteAllRefInventoryReference to 0 inside the obse.ini in Data\OBSE

[llde]

I think I'm understanding what the issue is.

The mod have 2 udf, one initial that create IR of specific objects using GetInvRefsForItem and another script cycling the inventory using a for loop. When the IR from the for loop is modified its content is immediatly copied to the original container, at element change. GetInvRefsForItem IRs instead are only processed at frame end. Before 22.7 this wasn't a problem, these kind of IRs changes weren't copied back to the original item by default, only when one of the "terminal" IR commands were used (RemoveIR, CopyIR,etc). After 22.7 all IR have the extra data copied to the original container. The problem is, the GetInvRefsForItem IR have the previous status of the element, causing the changes to revert back. So the flow become: IR is created by GetInvRefsForItem, IR is created by for loop, IR for from loop is modified, IR changes are mirrored to original container, IR from GetInvRefsForItem are Released at frame end, mirroring it's content to the original container, reverting all changes made.

Solutions: The proper solution would be to have the full processing of the IR at script level, #204, however this should be handled with care, as IRs are used in Events and some "last" commands (like the one to get the last absorbed soul gem), and also some UDF may generate an IR to send to it's caller.

Another solution may be to update all IR referring to an item, when a mirroring call is made.

[llde]

Proper per Script IR are to complex to implement for this release. This is becouse while the actual implementation isn't complex, it have quite the interactions with other part of the code, as User defined functions, that could return or have passed as argument IRs in some way. We will need a way to properly track the lifetime of what is passed between UDFs and their caller script. Also some IRs are used inside event handlers, and so they need their special handling.

Second solution is incorrect. If the engine alter the xData of a reference it's transparent. What we can do here, is to have a "backup" ExtraDataList, freezed from the container state, and check with it to see if it's edited.

[llde]

fixed by c51dbb815911de707d543b26cb7356f7ac870b90 and eeb4e4c