Resource Extraction Data

[budak7273]

Allow mods that implement new resources to offer information about the resource's nodes for use by other mods.

Mods define data assets that specify this information

SML BPFL will allow lookup of details from an FGResourceDescriptor class

Interface allows items to supply a data asset to be returned when they are looked up

Base-game items can't be made to implement the interface, so SML will redirect their calls to return data assets that SML defines for these

https://discord.com/channels/555424930502541343/562722670974599227/1124783052971847761

[budak7273]

Started on resource-extraction-data branch a519908

[Th3Fanbus]

I thought aloud for a bit about this in https://discord.com/channels/555424930502541343/555505343031934979/1218211168401883217 and Robb pointed me to this issue. The wall of text, assembled together:

(About handling modded resource node meshes/materials for a dynamic, mod-aware https://ficsit.app/mod/BuildableResourceNodesRedux extension): Yeah, that's what I'd need to work on:

• Absolutely initial approach is to do nothing (make all nodes look the same). It's not very cool-looking, but at least it gets the job done.
• A more visually appealing but hideously unmaintainable approach is to have a table of hardcoded names/paths (detect the resource descriptors at runtime, match them against the table of names, use fallback mesh/material if not found). That would work best for custom resource nodes that need more complex stuff (e.g. a base game resource well with a reddish decal on top). However, it would break rather often.
• A more complex but smarter approach is to implement some sort of fuzzy search using the Asset Registry (querying the AR to get the paths of derived subclasses of some base class is pretty quick), which would try to find stuff that matches the resource descriptor's name. Main problem is that the chosen meshes/materials wouldn't be stable (they could change after a mod gets updated, for example). It would also fail to solve modded resource nodes that reuse base game meshes/materials.
• For resource node actors that have a static mesh component, one could automatically pull the data at runtime. Problem is, that would be after loading a save, so it may be too late to set meshes/materials on the fly.

IMHO, the most optimal way to deal with this would be to "standardize" resource nodes. What I mean is to have a list of resource node types in SML, and have mods register the resource node types they add in the Mod Content Registry. I would also recommend adding some additional information in the registry entries:

• resource node type: Can be one of [resource node, fracking node (resource well), custom]. Not sure if custom nodes exist (behaviour for the nodes I've seen is either resource node or fracking node), but things like Aerated Crude Oil from https://ficsit.app/mod/PneumaticFrackingMachine could be listed as a custom node with help text.
• compatible extractors: The things that can be placed on a node to extract resources from a given node, e.g. miners, extractors, generators... (mainly for custom nodes).
• meshes and materials: The things that make a resource node show up in the world as such.
• weight: A magnitude that correlates with how abundant this kind of resource is, expressed in (e.g. number of impure/normal/pure nodes in the base game map).
• rarity: Rare, more valuable resources are found in more difficult map areas, and away from spawn points. This is NOT about the total amount of a resource (see weight).
• enabled: Whether a given kind of resource node exists in the world. The point is to allow disabling resource node types without removing them from the registry. Ideally, it should be set automatically (most mods want their resource nodes to be available by default).
• mod reference: Which mod(s) make this resource (un)available (e.g. Satmonium would be registered by SatisfactoryPlus even though its assets are in KLib because the mod making use of Satmonium is SatisfactoryPlus). SatisfactoryPlus should also be listed here when making resource nodes from other mods unavailable (so that "why does resource X not show up in my world?" is easy to answer).

This approach contemplates several use-cases:

• Making (buildable) resource nodes out of other mods' resources dynamically, without having to hard-depend on other mods.
• Allowing custom maps to spawn in modded resource nodes automatically, by designating "resource node slots" (or even flesh out node spawning into SML itself).
• With some additional work to handle base game resource nodes, it could aid in making resource node randomizers (e.g. https://ficsit.app/mod/RandomOreLocations would have the means to update resource node meshes/materials).
• When viewing recipes for things in the Codex, show "recipes" for resources so that players know how to obtain them.
• Handling the (relatively rare) situation where a mod (cough https://ficsit.app/mod/SatisfactoryPlus cough) overwrites/removes other mods' content in a way that's easy to keep track of (and gets reflected to all other users of this system, i.e. the rest of bullet points in this section).

However, this approach requires making a few concessions:

• We would need to release a new (minor) version of SML, and update all the mods to use this system (should we enforce it in SML?).
• Mods have to be adapted to register resource node types through SML, otherwise this beautiful resource node registry is pointless.

But I believe the advantages are worth it in the long run:

• No need to dynamically search for resource node information at run-time (which is slow and error-prone).
• Mods that want this information don't need to reinvent the wheel.
• Provided that mods overwriting/removing content behave properly, changes are reflected in the registry in a traceable way (it's possible to know which mods changed/removed something).
• SML already has a Mod Content Registry, so I believe most of the infrastructure is already in place.

Addendum:

To be very clear, the only bits I would add to SML would be the API for "resource node descriptors", which boils down to a data structure (see ⁠above for the information it would contain, some fields might need to be sub-structures) and a few functions to manipulate the content registry (e.g. "add resource node descriptor", "get all resource node descriptors"...)

The use-cases listed above would be implemented by other mods. They're use-cases I've considered when drafting this idea in order to make the proposed SML API as general as possible.