Architecture

Basic principle

"Modular" here does not mean that players can switch individual Revamp features on or off, but that the functional areas are separated in the code in such a way that one module can be worked on without having to understand the others. Independently of that, a server admin should be able to switch certain areas (e.g. the distribution system) on or off at runtime.

Debug output first, display decision afterwards

The display of a feature is not a separate, downstream step but part of building the feature itself: when writing a feature, first write debug output to the log (following Achim's convention from his other mods: Revamp.Debug flag, Revamp.DebugText(text, ...)/Revamp.DebugTable(text, myTable, maxDepth), prefix "RevampDebug: ", output via a plain print — a Logging.info wrapper adds no value over print with its own prefix). Only once the feature demonstrably works is it decided how it is best displayed — not before, and not as a separate, later phase.

Modules

Module	Content
Recipe Core	Mix groups, alternative FillTypes, valences, FillTypeCategories, boosters, recipe switching (see below, Later)
Distribution	Prioritized distribution, output modes (Selling/Distributing/Spawn/Keep), show distribution costs separately in the statistics
Storage Extension	Bulk goods/bales/pallets in the same storage, fill level object display, manual pallet/bale spawning/unloading from the production (counterpart to PSC, see Compatibility)
Buy/Sell & Pricing	Buying/selling in the production menu
Production Modifiers	Variable production speed ("short-time work"), applies to the whole production line
Display/Visualization	Only what is independent of individual features: display whether a production runs in parallel or distributed (II/Y), display of production costs, display of building/upkeep costs. The display of each individual feature (recipes, boosters, weather status, …) on the other hand is created together with the respective feature itself, see above
Settings	Own settings menu, including an admin switch per module
Ingame-Help	References the other modules

File conventions

• One module = one Lua file
• Multiplayer events are collected in scripts/events/, one file per event, regardless of which module the event belongs to functionally
• No local function in mod Lua code — everything as a field on a global table, so that Utils.overwrittenFunction/appendedFunction can hook in from outside

Coupling rules

• Recipe Core is the only hard dependency for the other modules
• Modules (Distribution, Storage Extension, Display, …) do not know each other directly
• Touch points between modules are only allowed in the dialogs/the UI
• Each module checks its own admin switch from the Settings module itself, instead of deleting code paths

Dialog strategy

The actual recipe display (Recipe Core: mix groups, boosters, weather status) stays in the extended original production dialog as long as it can show all options clearly and usably — no replacement dialog "just in case". Modules with real controls (settings with sliders and the like) get their own sub-dialogs; this is already laid out by PSC/PST, which use their own dialogs for storage management and buying/selling (ProductionStorageDialog, ProductionBuyGoodsDialog) instead of extensions of the production menu.

A separate replacement for the production dialog itself only comes into question once a concrete limit is reached, e.g.:

• A recipe with many mix groups/alternatives breaks the row/cell height of the list despite adjustments
• A module needs an interaction that no list cell can represent (sliders, visual percentage distribution or similar)

Recipe Core: recipe switching ("combining"), Later

The FeedMixer in FS22 could switch between recipes defined differently per map, without every variant needing its own production line with its own storage/FillType reservation (one line is reconfigured for the currently active variant, FillTypes are re-registered on a switch instead of being registered permanently). The principle should later also be usable for freely written modder recipes, not just for feed mixers — but it is not a short-term goal: high complexity due to the many possible combinations, therefore on the Later list instead of Todo.

See also Compatibility for the optional loading system and the compatibility with existing companion mods.