Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Loadout Items ADR #1680

Closed
wants to merge 3 commits into from
Closed
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Final updates
halgari committed Jun 24, 2024
commit a76e7f92f90b94731b5ccbd750024e93a5f1cb45
34 changes: 32 additions & 2 deletions docs/developers/decisions/backend/0014-loadout-items.md
Original file line number Diff line number Diff line change
@@ -49,7 +49,7 @@ classDiagram

class ContainerItem {
+string Name
+bool Enabled
+marker IsDisabled
}

class DownloadedMod {
@@ -86,4 +86,34 @@ to find these items mostly becaomes `ContainerItem.FindByParentId(db, loadout)`.
### Synchronizer

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.
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.

Naturally this approach does not handle file conflicts, but it is assumed that these conflicts will be rare in most cases. When these
conflicts do occur the Synchronzier will pass the options to a `ResolveWinningFile` method that will pick which of the conflicting
files is the winner. Due to this approach it is not required that loadout items or mod be sorted, instead only the conflicting
files need to be ordered, in which case the ordering is often trivially detected based on the files and mods in question

### Mod Library

The mod library grid will look in the loadout for any loadout items with the given `DownloadMetadata` and use this to drive
the "installed" or "not installed" states in the grid.

### Diagnostics

Diagnostics likely will need to be updated to handle specific types of loadout items, the biggest changing being moving
mod referencs to container/downloaded mod items.

### Stardew Valley Updates

Stardew valley installers will need to be updated to emit a single parent container of the type DownloadedMod that contains
other containers of "SMAPI Mod" which each contain the files of the mod. In future UI updates we can decide if we want
to display all of these mods as a list, a tree, or only the top or lower levels of the tree.

## Rationale

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.
Comment on lines +117 to +120
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.