Load Order: Initial Design

[LukeNexusMods]

Initial design should include manually choosing the load order.

Phase 2 will include file conflict resolution.

@captainsandypants

Please put your designs here.

1. Where will the user perform ordering?
2. What options will they have?
3. Will it be in the current mod list or somewhere new?
4. How will the user know what to do?
5. Where will they get help?
6. Does the design change for different games?
7. Do the game specific items need naming differently?
8. Does the design allow to implement in phases?

Edit:

Meeting Notes:

• Some games have multiple things that need to be ordered:
  • Cyberpunk: RedMods, ArchiveXL https://wiki.redmodding.org/cyberpunk-2077-modding/for-mod-users/users-modding-cyberpunk-2077/load-order#what-is-load-order
• Some games need a flat list as input
• Some games like StardewValley have dependencies defined in each mod manifests, there is no flat list.
• We will likely need three types of views depending on the game specific loadorder type:
  • 1. Flat Drag & Drop list
  • 2. A view or way to edit Dependencies/Rules for games that use those (e.g. SMAPI)
  • 3. A flat non interactable list to visualize the result of Dependency Graph resolution, show the user what the game will actually use.
  • 4. Optionally for some cases that take a flat list but also have dependency data (e.g. Bethesda plugins that have Loot rules data) we might want to offer both Drag&Drop flat list and Rules. What needs to be defined is how the rules would interact with the flat list:
       • Rules are enforced manually on user demand;
       • Rules are always enforced
       • Rules not enforced and just trigger warnings
       • Rules are applied after, e.g. only before running the game, but don't change the user order

Flat list Notes:

• If the game uses a flat list we can likely reuse the same page, but some parts might need to be subclassed and overridden by the game extension (different Item views, different columns, different context menus, different sorting limitations, etc).
• Lists might have locked items at the top or at the bottom that the user will not be able to change the order (game plugins, DLCs, special mods)
• User needs to be able to switch the order from top to bottom to bottom to top (communities have very ingrained preferences for this)
• Multi selection to allow dragging and dropping multiple mods, adding multiple mods to groups etc.
• Investigate names for the order column or other ways clarify to the user whether 10 is higher priority than 1 or the other way around. This should be as unambiguous as possible. Priority, Layers, Order are some examples of attempted ideas.

  Edit (04/09/2024), first demo feedback

• Load Order doesn't communicate whether low number or high number take precedence.
  • Override Sequence or similar names would convey that information.
  • Override Level or Override Layer could be better names for the priority numbers column, as they contain the information higher is better.
  • Priority is not a good name because if you say, Mod A should take priority over Mod B in the load order, this could be interpreted as either "should have higher number to make it override" or "should have lower number to take precedence in the sequence (come prior in order). We want to avoid this ambiguity.
• Groups should be collapsible (to allow users to only deal with parts of the list they are interested in).
• Should we support nested groups? People regularly ask for this in MO2.
• People will want to see this page side by side with LoadoutView and mod conflicts page a lot.

Phases breakdown:

• Phase 1: Non interactable flat list to only visualize the final order, usable for Stardew, CP and anything. Just informative.
• Phase 2: Flat list Drag&Drop ordering, usable for CP, BG3, not for SDV.
  • This could be split into further parts potentially, like adding Groups as a second part but depends on how complex the design is.
• Phase 3: A way to edit dependencies for systems like SMAPI that don't have a flat list anywhere in the process. This is further into the future.

[erri120]

Additional information:

Dependency graphs are directed graphs. Circular dependencies are usually forbidden, so the graph can be assumed to be a directed acyclic graph. Visualization and interaction of these graphs are usually very hard UI/UX problems.