NPC reset bug (Clothing reverts to default) - NOT the equipitem bug.

[PJMail]

I often do a disable-enable as a 'soft' reset of an NPC it seems to reset thier outfit but not their inventory. Are you sure your NPC is NOT using any templates? I found that having a traits or stats template caused my NPC to eventually reset everything including inventory. You need to set them up like a companion - everything fixed, including clothing, face, etc. nothing else worked.

[hereami]

So, Disable (or unload/load perhaps?) is normal to provoke resets? Pity. And it looks like i've misunderstood, for me sounded like Templates help to prevent reset.

Yes, no templates, even no skin (hm, maybe that matters too and game tries to "fix" missing essential data by resetting everything else? but he must have no visual appearance at all). On other side, in my case still might be exploited to discourage from storing extra items inside - they all go vanished, bit rough, but npc inventory doesn't have a filter List like Containers, unfortunately.

[PJMail]

It seems everything has to be a certain way for inventory reset NOT to happen, and I still don't know what that list is. Larannkiar discovered a lot, but even following their advice I still had issues. For instance, adding items to an NPC inventory via script does NOT stop resets, but manually via the trade gui does help. That is just crazy. This is such a dodgy system.

[LarannKiar]

14 hours ago, PJMail said:

It seems everything has to be a certain way for inventory reset NOT to happen, and I still don't know what that list is. Larannkiar discovered a lot, but even following their advice I still had issues. For instance, adding items to an NPC inventory via script does NOT stop resets, but manually via the trade gui does help. That is just crazy. This is such a dodgy system.

It's quite limited when it comes to inventory handling unfortunately.

Now that I familiarized myself with Starfield's inventory system.. it appears OnItemAdded and OnItemRemoved received a new parameter: Int aiTransferReason.

This parameter is not new, Fallout 4 uses this too. It should've been exposed to AddItem() and to the other functions to pass custom "transfer reason" to the inventory event whose behavior is currently hardcoded. (Not like AddItem() has been changed in Starfield, it's still doesn't support this. The event parameter is used for example for Contraband). The hide/show the Spacesuit 3D, Contraband (which is usually an inventory item) detection and lot of quest items weren't enough to make them implement proper inventory handling in Papyrus. But sorry I'm going off-track...

As far as I remember, valid transfer reasons in Fallout 4 are dropping, stealing, non-crime taking, storing in containers and storing in "teammate's inventory". The UI has a game code set AS3 variable (it was something like iMode) that "mixes" the transfer reason with the menu target, e.g., Equip/Take all button if teammate/workshop workbench. Most certainly scripted item transferring is not in "teammate mode".

It might be possible to change the normal 3D reset procedures for actor references.. there is an enum class which keeps of track body regions and such (Skeleton, Model, Face, Outfit) that is required to get reset upon receiving the next event. A bitwise operator should be able to tell if editing those really works..

On 11/27/2023 at 7:08 AM, hereami said:

So, Disable (or unload/load perhaps?) is normal to provoke resets? Pity. And it looks like i've misunderstood, for me sounded like Templates help to prevent reset.

Yes, no templates, even no skin (hm, maybe that matters too and game tries to "fix" missing essential data by resetting everything else? but he must have no visual appearance at all). On other side, in my case still might be exploited to discourage from storing extra items inside - they all go vanished, bit rough, but npc inventory doesn't have a filter List like Containers, unfortunately.

Yes, that resets most part of the reference's 3D. When I started making EquipNthItem() for Garden of Eden Papyrus SE, I managed to crash the game several times and in many cases the "remedy" was (to keep the game running to get actual debug info) was to equip items on NPCs while they were disabled. When they got enabled, the game always "refreshed" their 3D data... and handled the equip slot and biped object instead of me . It took a while to figure out how to properly implement it..

The closest thing to the item filter FormList is the "Gift Filter" which hasn't been used ingame but could be restored through F4SE.

Edited November 29, 2023 by LarannKiar

[hereami]

On 11/29/2023 at 4:15 AM, LarannKiar said:

The closest thing to the item filter FormList is the "Gift Filter" which hasn't been used ingame but could be restored through F4SE.

Aha, as i understand, it displays only filtered items on both sides, similar to Power Armor? Damn, that's how Container filter should work too.

In regard of PowerArmor transfer dialogue filtering is probably fully hardcoded then? Looks like there is no filter to set in Furniture, so we could easily make it store miniguns etc..

[LarannKiar]

8 hours ago, hereami said:

Aha, as i understand, it displays only filtered items on both sides, similar to Power Armor? Damn, that's how Container filter should work too.

In regard of PowerArmor transfer dialogue filtering is probably fully hardcoded then?

Yes, as far as I remember it's due to one of the Power Armor keywords, which flags the Furniture form as a Power Armor frame.

[LarannKiar]

On 11/28/2023 at 3:06 AM, PJMail said:

For instance, adding items to an NPC inventory via script does NOT stop resets, but manually via the trade gui does help. That is just crazy. This is such a dodgy system.

I don't intend to revive these old topics but after discovering a few things about the template code, native AddItem(), Enable() and the like they all may reset the NPC's inventory (unexpectedly).

As for ContainerMenu, code uses a shared function for both Pip-Boy and Container Menu called equip/unequip. The parameters that EquipObject() receives is distinguised by an if Player condition. If actor == Player, then call EquipObject(), else call EquipObject( abLockEquipState = true ). So, the difference comes from the fact that BGS tried to remedy the "rather reset everything than miss anything" design by hardcoding the equip state lock.

That being said, Papyrus Actor.EquipItem( abPreventRemoval = True ) behaves pretty much differently for NPCs... I'm not saying one should always set this parameter when calling EquipItem on an NPC but it's worth giving a try. It won't cause the item get stuck unlike for the player because ContainerMenu Unequip) releases the lock (unlike selecting an item in the Pip-Boy).