Loadout Items ADR #1680
Loadout Items ADR #1680
Conversation
| The primary motivation for this change is to move questions of what a specific object is from code-time to runtime. Displaying | ||
| items in a grid or a tree, or projecting parts of the loadout item tree into a list all now become runtime concerns and | ||
| we are free to project the data in any way required. New file or container types can be added to this process and existing | ||
| grids and lists should work as-is. |
There was a problem hiding this comment.
The section can be expanded to include one of the main aspects of this: optimized for reading. The goal is to easily grab any data in the correct view. The SMAPI diagnostic emitters are a great example, most of them don't care about anything but SMAPI manifest files and SMAPI mods.
There was a problem hiding this comment.
I think we should clearly define some models in this ADR. Specifically, what you refer to as ContainerItem. This model is going to replace what we currently refer to as a "Mod" and I want us to get it right, as it's going to be the centerpiece for almost everything else.
I'm not married to the term ContainerItem yet, but for now, here's a shortlist of things we need to somehow deal with (this is not a complete list):
- Game Files
- "Override"
- Nexus Mods Collections
- SMAPI Mods, where each mod has its own manifest file. One archive might contain three SMAPI Mods, even though they came from the "remote mod" (using this generic term to represent a Nexus Mods mod page, open to change)
- SMAPI config files
One pain point I want to avoid with Loadout Items is figuring out what goes into the beginner-friendly Loadout grid. Sure, we can have some expert view that shows every single Loadout Item, but design wants a simple view that "shows mods", which is why the entry on the left menu says "Mods" and not "Loadout Grid".
As mentioned many times before, the term "Mod" is overloaded, and we need to find something else. I want us to find that term, and create a clear definition with this ADR.
| The Synchronizer will need to be updated to handle the new model, flattening a loadout becomes a matter of finding all `File` | ||
| items that point to the loadout, then walking all those items to make sure each parent is enabled. Stated another way, the | ||
| loadout is flatted down by grouping all loadout items by `To` that are not an ancestor of a item that has the `Disabled` marker | ||
| attribute. |
There was a problem hiding this comment.
This bottom up approach, while more intuitively easy to parallelize, would require performing a walk up the tree for every single file to check if all parents are enabled.
Would it not be more efficient to walk down the tree of only the branches that are enabled?
Skipping, in this manner, large chunks of files as top level items exclude them.
Pretty simple stuff, just documenting the plans we've had for awhile about loadout items (#1336).