Investigate support for Campfire containers

[DavidJCobb]

I've been informed that Campfire containers are not supported: the "container" that one would spawn with HearthCraft or similar is actually an activator, with a Papyrus property that links to a container in a holding cell. Obtaining the container TESObjectREFR works like this in Papyrus:

if(Game.GetModByName("Campfire.esm") != 255)
   CampPlaceableContainer campContainer = currentObject as CampPlaceableContainer
   if(campContainer)
      return campContainer.Required_LinkedContainerRef
   endif
endif

I assume the purpose of this is to allow for containers whose inventories are accessible from any campsite.

Looping over every activator in the loaded area and checking its Papyrus data could slow down the cell search. We may be able to mitigate that if we do the distance check before the Papyrus check. We could potentially mitigate that further if we exclude Skyrim.esm forms by form ID (i.e. if !(form->formID & 0xFF000000)) on the assumption that there is no sensible reason for a mod to turn a pre-existing vanilla activator into one that opens a Campfire container.

Alternative solutions include:

• We could see if there's a way to identify the underlying container refs directly, and then just retain a list of them in memory. That would allow you to pull crafting items from them regardless of where you are, and regardless of whether any Campfire "container" activators are nearby. This may or may not be a desirable behavior.

  • On startup, we could identify all activator base forms that have the relevant Campfire script attached, and (if there aren't too many of them / if the script is specifically for these containers and not a general-purpose interface) cache a list of their form IDs. Then, during the cell search, if a reference is an activator, then we can check its form ID against this list before then looking for Papyrus data.

Research is still needed (and desirable in general) for retrieving script data from a form, i.e. accessing variables and such. Reverse-engineering of the SV and SQV console commands would be worthwhile. This research could benefit other projects as well.

[DavidJCobb]

The same person who reported this issue has also found that some containers near Legacy of the Dragonborn's "crafting area" work similarly, and has suggested providing a Papyrus API to allow mod and patch authors to register container references with the DLL.

Registration should not require a co-save. Mods with predefined remotely-accessible containers would be able to register them on load; mods that allow players to create an arbitrary number of remotely-accessible containers would hopefully be maintaining a list of these containers somewhere, and so should also be able to register them on load.

Registering just the containers would not be sufficient for carrying out a distance check, so we'd have to make them accessible from everywhere. Registering the containers and the activators would enable distance checks against the activators. We could consider allowing registration to take the container and an arbitrary "facade" reference (e.g. the activators), with us performing distance checks against facades when they are provided, and always granting access to containers for which no facades were provided.

[DavidJCobb]

Registered containers with no facade would have to be retained in memory using an RE::refr_ptr; we need them to always be loaded so that we can always check their contents.

Registered containers with a facade could just store the container form ID and the facade form ID. Presumably the facade would refer to the container via a Papyrus property, meaning that when the game loads the facade, it also loads the underlying container.