Silo

Getting started

Silo is a desktop app for managing your Farming Simulator 25 mods. It is not an in-game mod and you don't install it into the game — it's a standalone program that runs on your computer alongside FS25. It scans your existing mod library, organizes it, catches conflicts before you launch, triages crashes, and tracks updates.

Silo never edits the game itself. It works with the files FS25 already keeps in Documents\My Games\FarmingSimulator2025\, and everything it does to those files is reversible.

Installing on Windows

1. Download the latest installer from the Releases page (also linked from silo.hllmr.com). You'll find a setup .exe and an .msi — either works; the .exe is the usual choice.
2. Run it. Silo installs for your user account and doesn't need administrator rights.

The blue "Windows protected your PC" warning is expected. Silo is a free, open-source beta and the installer isn't code-signed yet, so Microsoft SmartScreen flags it as from an unknown publisher. To continue, click More info, then Run anyway. This warning goes away once signing is in place.

What happens on first run

When Silo opens it lands on the Library view and looks for your FS25 mods folder automatically — on Windows that's Documents\My Games\FarmingSimulator2025\mods. If it finds one, it starts scanning right away; a progress bar shows how many mods it has read. A cold scan of a large library takes seconds, and later scans are near-instant.

When the scan finishes you'll see your whole library, with counts for mods, maps, and scripts. You can confirm which folder Silo found under Settings (the gear icon), in the Mods folder section. If nothing was found, the list reads "No mods found yet. Point Silo at your mods folder and rescan" — check that the folder exists, then use the Rescan button.

Your files stay safe

Silo is built so it never changes your original mod files destructively. On first run it only reads and catalogs — it moves nothing until you ask. When you do organize or activate mods, Silo projects them into the game's mods/ folder using links (hardlinks or junctions), so there's no duplication and your originals are untouched. The Restore vanilla layout button in Settings undoes all of Silo's organization at any time, and your mods are never deleted.

macOS and Linux are experimental. Silo is built and tested Windows-first. It can run on macOS and Linux (via Proton), but game-file discovery on those platforms isn't fully verified yet — expect rough edges.

The library: active vs. parked

Farming Simulator loads mods from one flat folder: Documents/My Games/FarmingSimulator2025/mods/. Every .zip in there is read at startup, with no subfolders and no notion of "installed but off." Silo's core idea is to separate that dumping ground into two things: your whole curated source library — everything you own, browsable on the Library tab — and the flat mods/ folder the game actually reads, which Silo fills with only the set you want loaded.

Active vs. parked

Every mod in your library is either active (loaded by the game) or parked (kept in the library, filed away, not loaded). Each row has a dot on the left: click it to toggle. The tooltip reads "Active — click to park" or "Parked — click to activate," parked mods carry a small parked badge and dim slightly, and the detail drawer shows ● Active or ○ Parked. Use the checkbox in the toolbar to activate or park everything in the current view at once. Parking never deletes anything — it just leaves the mod out of the game's folder.

Organize

Reach for Organize when your mods/ folder is a flat pile and you want it sorted. It moves each loose .zip into mods/archive/<Category>/ — subfolders the game deliberately ignores, since it only reads the flat root. Your active mods stay loaded; nothing is duplicated. You'll find the button in the top bar (Organize N, showing how many loose mods it found) and under Settings → Library layout.

Before it touches a file, Organize shows a read-only dry run: a preview grouped by destination category (for example "12 into Vehicles, 3 into Maps"), each file with its exact archive/<Category>/… target. Nothing has moved yet — you confirm with the Organize N mods button or Cancel. Power users can tick Don't preview next time, or turn on Auto-file new mods in Settings to file new downloads automatically.

Projection at launch

Silo keeps the flat mods/ folder holding exactly your active set by projecting the archived originals back into it — .zip mods as same-volume hardlinks, unpacked mod folders as directory symlinks/junctions, with a copy fallback where links aren't permitted. Hardlinks use no extra disk and need no admin rights or Developer Mode. When you hit ▶ Launch, the game reads that folder and loads precisely the mods you marked active.

It's reversible, and it never destroys your originals. Moves are instant same-volume renames (or a safe copy-then-swap across volumes) — the original is never lost mid-operation. Restore vanilla layout (Settings, shown once anything is organized) undoes everything: it drops Silo's projections, moves the archived files back into a plain flat mods/, and removes only empty archive folders. It never deletes a file it doesn't recognize, never removes the only copy of a mod, and won't touch a file you swapped in yourself — you're always one step from stock.

Curating your library: favorites, tags & flags

Curation is your personal layer of judgment on top of the raw mod list: which mods you love, which are half-broken, which you never want to see, plus star ratings, tags, and notes. It helps you find the right mods fast in a library of hundreds. Everything here is Silo-only metadata stored in Silo's own database and keyed to each mod's internal tech-name, so it survives version updates and file moves.

None of this touches your mod files or the game. Flags, ratings, tags, and notes are stored beside your library, never written into the mod archive or your mods/ folder. Every marking is a toggle you can clear at any time, and hiding a mod never deactivates or deletes it.

The three flags

Each mod carries three independent flags, toggled from the icon buttons on its row or from the actions in its detail drawer:

• Favorite (☆ / ★) — marks the mods you reach for most.
• Hidden (⊘) — dims the row and drops it from the list by default. Use it for clutter you keep installed but rarely want to look at.
• Broken (⚠) — flags a mod as broken or unfinished so you remember not to trust it. This is your own note-to-self, separate from Silo's automatic conflict detection.

Ratings, tags, and notes

Open a mod's detail drawer to reach the rest, in the Rating, Tags, and Notes sections:

• Rating — click a star (1–5) to set it; click the same star again to clear back to unrated.
• Tags — type into the add tag… box and press Enter to attach a free-text label; duplicates are ignored. Click a tag's name to filter the whole library by it, or the ✕ to remove it.
• Notes — a free-text box for anything you want to remember. It saves when you click away.

When you clear every flag, the rating, and the note on a mod, Silo drops its curation record entirely, keeping the database tidy.

Filtering and sorting by curation

The toggles in the top bar filter the list: Favorites shows only favorites, Hidden reveals the mods you've hidden, and Flagged shows only mods you marked broken. Clicking a tag adds a #tag crumb above the list; use its ✕ to clear it. Ratings show as stars on each row, and the toolbar's Sort menu includes My rating (alongside Name, Category, Size, Recently added, and Version), with the arrow button flipping ascending/descending.

Loadouts

A loadout is a named set of active mods you can switch to in one click. If you run several playthroughs — a heavy-realism seasonal save, a lightweight co-op save, a clean vanilla-ish test — each wants a different mix of mods active. Instead of hand-toggling dozens of mods every time you change games, you save each mix once and apply it when you need it.

Loadouts store the list of active mods, not the mod files themselves. Deleting a loadout never touches your mods, and applying one never deletes anything from your library — it only changes which mods are projected into the game's mods/ folder.

Opening the panel

Click Loadouts in the top bar to open the Loadouts panel. When your current active set exactly matches a saved loadout, that button shows the loadout's name with a dot (for example ● Seasons Co-op) instead of the word "Loadouts". The panel header shows how many mods are currently active.

Saving a loadout

First activate the mods you want (toggle them in the library, or use the filter + select-all to build a set quickly). Then, in the Loadouts panel, click + Save current active set as a loadout and give it a name. The set is saved as-is. This button is disabled while nothing is active.

To update an existing loadout to match what you have active now, click its overwrite icon (⭯, "Overwrite with current active set").

Applying a loadout

Click a loadout's name to apply it. Silo makes the game's active set exactly that loadout: it links in the mods that should be active and removes the links for mods that shouldn't be. The filled dot moves to the loadout you just applied.

Applying is reversible and safe. Silo only adds or removes its own projected entries (junction, symlink, hardlink, or marked copy) in the mods/ folder — your archived source files are never moved or deleted. If it finds a file it didn't project (you swapped in your own build), or the archived copy behind a link is missing, it leaves that file alone and reports it rather than deleting it.

Building a loadout from a savegame

In the Savegames panel, click → Loadout next to a save to build a loadout from the mods that save actually used. Silo creates a loadout named after the save from the mods you have, notes any that are missing, and applies it — a fast way to bind the right mods to the right playthrough.

Exporting and importing

Click a loadout's export icon (⇪) to save it as a .silo file — a small JSON file listing the loadout's name and mod tech-names (no mod ZIPs are included). Share that file, and the recipient clicks ↧ Import a .silo file to add it as a new loadout (.silo or .json accepted). Import only creates the loadout entry; the person still needs the actual mods in their library for every mod to activate.

Deleting

The ✕ icon removes a loadout after a confirm. As the prompt says, your mods aren't affected — only the saved set is discarded.

Library health

The Health panel reports problems with your whole library — issues that exist no matter which mods you have switched on. This is different from Conflicts, which only looks at the mods in your current active set and how they collide with each other. Reach for Health when you want to know whether the library itself is sound: are any mods broken, missing something they need, or quietly unloadable by the game?

Opening it

In the status bar along the bottom, find the need attention button. The number on it is the total count of health issues; the button is highlighted whenever that count is above zero. Click it to open the Library health panel. If nothing is wrong you will see "Everything looks healthy — no problems found." Click the backdrop to close the panel.

The panel is read-only. It only inspects and reports — it never moves, renames, deletes, or rewrites any file — so opening it and reading it is completely safe and there is nothing to undo. Fixing what it finds is always a separate, deliberate action you take yourself.

What it reports

Issues are grouped into up to three sections, each with a count:

• Missing dependencies — a mod's modDesc.xml declares another mod it depends on, and that mod is not present anywhere in your library. Each row names the mod and the dependency it needs, marked not in your library. To fix, add the required mod (for example via the Browse tab's in-app install, or by dropping it into your library) and rescan. Note this checks whether the dependency exists in the library, not whether it is currently active.
• Ignored by the game — name starts with a digit — Farming Simulator silently refuses to load any mod whose folder or file name begins with a number, so the mod appears installed but never runs. Each row shows the offending name. To fix, rename the mod so it starts with a letter.
• Corrupt / unreadable — Silo could not read or parse the mod (for example a damaged archive or malformed modDesc.xml). The row shows the underlying error. These usually mean an interrupted or corrupted download; re-download or reinstall the mod, then rescan.

When to check it

Check Health after a batch of installs or updates, before building a loadout for a play session, or whenever a mod you expected to work simply is not appearing in-game. Because the list is derived live from the last scan, it refreshes on its own as your library changes — resolve an issue and rescan, and the corresponding row disappears.

Health flags library-wide soundness. For clashes between the mods you have enabled, use the Conflicts panel instead.

Browsing & installing mods

The Browse tab is where you find new mods without leaving Silo. It reads the SiloAPI catalog, a single index that merges the same mod across GitHub, ModHub, and Nexus Mods, so you see one card per mod instead of three scattered listings. The header shows how many mods and sources the catalog currently holds.

Finding a mod

• Search — type in the Search the catalog by title box. Results refresh as you type (after a short pause).
• Category — the All categories dropdown filters by mod category, with a count next to each.
• Sort — order by Popular, Most downloaded, Top rated, Newest, or Name (A–Z).
• More results — the grid loads 60 at a time; use Load more at the bottom to page through.

Any mod you already have shows an In library badge, so you can tell at a glance what is new.

Source buttons and versions

Each card carries one button per source the mod lives on — GH, MH, Nexus — each labelled with that source's own version, because those versions drift apart. A download arrow (⬇) means Silo can install it for you; an up-right arrow (↗) means the button opens the source's page instead.

Installing from GitHub, in-app

GitHub release mods are directly installable. Click the GitHub button (or Install ⬇ in the detail drawer) and Silo downloads the .zip straight into your mods folder, showing a live progress bar with the megabytes transferred. When it finishes you'll see Installed … and the library rescans automatically. You do not need to connect a GitHub account just to install — connecting is only for Star/Watch actions.

Installing only adds a new .zip to your mods folder; it never edits or removes anything you already have. To undo an install, remove that mod from your library like any other.

ModHub and Nexus are index-only

Silo can list ModHub and Nexus mods but cannot download them for you — those CDNs require the download to go through their own website. Their buttons read Open page ↗ and take you to the source. Grab the .zip there, drop it in your mods folder, and Silo files it automatically on the next scan.

The detail drawer

Click Details on any card to open a side drawer with the cover image, author, version, category, tech name, rating and downloads, and the full Available from source list. For a GitHub source it also shows live repo stats (stars, forks, watchers, issues) and, once you connect GitHub, Star and Watch buttons. Use Read more → to expand the full description.

Browsing without the app

You can also explore the same catalog in any web browser at silo.hllmr.com/browse. It reads the public SiloAPI directly; in-app installing still happens inside Silo.

Keeping mods updated

Silo checks your whole mod library against a canonical catalog and tells you which mods have a newer version available. It is designed to avoid a common false alarm: a mod you installed from ModHub showing as "outdated" only because a different version exists on GitHub (or the reverse). Silo compares against the latest across all known sources, so you see a real update, not a source mismatch.

Running the library-wide check

In the top bar, click ⟳ Updates. (The button appears once you have mods in your library.) While it works, the button reads Checking… and a Mod updates panel opens with a running count of how many updates are available.

Two things happen behind the scenes:

1. One request sends your whole library to the SiloAPI catalog, which answers with the latest version per mod across GitHub, ModHub, and Nexus.
2. Any mods you have personally linked to a GitHub repo are then checked directly, and that result takes precedence for those mods — your chosen source wins.

Each mod with a newer version shows its title, a source badge (for example github), and current → latest. A bottom line summarizes how many mods are Up to date and how many hit an error. If nothing in your library matches the catalog, you'll see a note that mods on GitHub can also be linked to their repo in the detail panel.

The check is read-only. Nothing on disk changes until you explicitly install an update. If the catalog can't be reached, Silo quietly falls back to checking only your linked GitHub repos.

Per-mod status in the detail drawer

Open any mod to see its own GitHub updates section. If the mod's modDesc points at a repository, Silo suggests owner/repo for you — click Link to confirm, or type your own. Then use Check for update. The result reads either Update available: <tag> (you have <version>) or Up to date, with an Open repo / View release link for context.

Applying an update

Where a downloadable asset exists, click Install in the Updates panel (or Download & install in the drawer). Silo downloads the new archive, verifies it is a valid, complete .zip, backs up your current file, and only then writes the new version in place. Afterward it rescans so your library reflects the new version.

Safety: Silo will not overwrite your file until the download is validated and a backup is made. If the write fails partway, it restores the original from that backup, so you're never left with a broken mod. Mods indexed as open-page only (typical for ModHub and Nexus) have no direct-download asset — for those, use the source link to update manually.

Mod integrity & provenance

The integrity check answers one question: is this the mod its author published, or has it been altered since? It hashes the archive you have installed and compares it to the canonical build that SiloAPI computed from the mod's own source. Reach for it when a mod came from somewhere other than its official page, when an update behaves unexpectedly, or when you simply want to confirm that what's on disk is exactly what shipped.

This is provenance, not antivirus. A Verified result proves origin and integrity — that the files match the published build. It does not judge intent, and it cannot tell you whether a mod is safe. The check only reads and hashes files; it never writes, moves, or modifies anything, so running it is always safe to do.

Running the check

Open a mod's detail drawer and find the Integrity section, then click Verify integrity. Silo hashes the archive on a background thread (you'll see Hashing & comparing…) and shows one of three verdicts. Only packaged mods can be checked — for an unpacked folder you'll see Folder mods can't be verified — there's no archive to hash.

The three verdicts

• Verified — the mod matches the published build. Either a byte-for-byte match with the exact archive, or a content match (repackaged, but every file inside is identical). The matched version is shown.
• Modified from the published build — it's the same mod, but files differ. You get a count of changed / added / removed and expandable lists naming the exact files. This tells you precisely what diverged — it does not, by itself, mean the change is malicious. Long lists are capped with a +N more line.
• Unverified — there's no hashed canonical build to compare against yet, so no conclusion can be drawn either way. You'll see why: the mod isn't in the catalog, or there's no hashed build for this exact version yet.

After a Modified or Unverified result you can click Re-check to run it again. Verified and Modified verdicts also surface as a small badge on the mod's row so you can see them at a glance.

Coverage grows over time

Coverage is popular-first and GitHub-first, and it expands continually. Canonical builds are hashed from source, so mods distributed that way are covered first; others may report Unverified until a hashed build exists. An Unverified result is never a mark against a mod — it only means Silo has nothing trusted to compare it to yet.

Conflict detection

Some mods can't coexist. Two of them may claim the same slot, or one may silently overwrite another's settings — and you won't find out until the game crashes on load or an item behaves oddly. Silo re-parses the modDesc.xml of every mod in your active set and flags these collisions before you launch, so you can fix them while it's still a two-second edit.

What Silo checks for

• Duplicate active map (critical) — more than one map enabled at once. FS loads a second map's scripts even when it isn't the one you're playing, which typically crashes on load. Keep exactly one map active.
• uniqueType collisions (critical) — two mods share a uniqueType. FS loads only one, so the others never take effect.
• Specialization / type / registration collisions (critical) — multiple mods register the same specialization, vehicle type, placeable type, input action, brand, or store category. Only one registration wins; the others may break.
• Script collisions (warning) — two mods inject a global Lua script with the same filename; they can override each other by load order. If the file is byte-identical in each mod, Silo downgrades it to info — it's a shared library, not a real fight.
• Cross-mod fillType override (warning) — two mods define the same-named fillType. Whichever loads last silently overrides the other's capacity, price, and other settings.

When every mod in a clash shares the same author, Silo treats it as likely intentional and softens the severity, so the critical list stays trustworthy.

Reading the conflicts panel

The stat bar shows a conflicts button with a live count; it turns red when any conflict is critical. Click it to open Conflicts in the active set. The header shows how many are critical. Each row lists its severity (critical, warning, or info), the kind of collision, the offending name, the mods involved, and a plain-language explanation of what breaks. Rows are ordered critical first.

To see the culprits in your library, use the ⚠ In conflict filter in the stat bar — it narrows the list to just the mods named in a conflict.

Resolving a conflict

1. Decide which mod in the clash you want to keep.
2. In the library, click the status toggle on the other mod's row to park it (an active mod reads ● Active — click to park).
3. Silo re-checks the active set automatically after any change, so the count updates on its own — no rescan needed.

Parking is fully reversible and touches no files. It only removes the mod from the set Silo will project into the game's mods/ folder at launch; the mod stays in your library, and one click reactivates it.

Crash & log triage

When Farming Simulator 25 crashes or misbehaves, it leaves an explanation in a file called log.txt — but that file is thousands of lines of engine chatter, and most of it is harmless. Silo's diagnose feature reads that log for you, tells you whether the last run actually crashed, and names the specific mod that logged errors right before it stopped. It separates the real breakage from the cosmetic noise that scares people for no reason.

No FS25 tool does this on its own. The usual community advice is to manually disable half your mods and relaunch over and over. Silo starts by simply reading the name the engine already wrote next to each error.

When to use it

• Right after the game crashes to desktop, freezes on load, or quits unexpectedly.
• When something in-game is clearly broken and you want to know which mod is complaining.
• Any time you just want a quick health check on your last session.

How to open it

In the stat bar, click the ◆ diagnose button. Silo reads log.txt from your FS25 user folder and shows a report. Use ↻ Re-read log to refresh it after another launch.

This feature only reads your log — it never edits log.txt, your mods, or any game file. There is nothing to undo. It is completely safe to run as often as you like.

How to read the result

The headline verdict comes in one of three forms:

• Healthy — the last run exited cleanly and no mod logged a real error. If anything appears, it is cosmetic only. Nothing to do.
• Exited cleanly, but… — the game closed normally, yet one or more mods logged errors worth a look. Not necessarily a crash, but worth checking.
• The last run ended abnormally — the log stops mid-session with no clean-exit marker. That is what a crash looks like.

Below the verdict, mods are grouped by severity:

• Likely culprits — mods that logged genuine errors (for example Lua script failures). Each row shows the mod's name, its error and warning counts, and a sample log line.
• Worth a look — mods with real warnings but no errors.
• A collapsed cosmetic warnings only — safe to ignore group, tucked away because missing-translation notices and the like never cause a crash.

Silo only blames a mod when the log names it directly (via its mods/ path or an in mod '…' clause) — it never guesses. Anything it can't attribute is counted as engine or base-game and reported separately, with an Open log.txt link so you can read the raw lines yourself.

If the run crashed but no mod is named, the log genuinely can't identify the cause — usually a mod interaction. In that case Silo offers Run guided bisection to isolate it automatically. See the guided bisection section for that workflow.

Guided bisection

Sometimes FS25 crashes or misbehaves and the log never names a mod. The cause is usually an interaction between mods that no single line can point to. Guided bisection automates the community ritual for these cases — disable half your mods, relaunch, see if the problem survives, and repeat — so Silo does the bookkeeping and you just play and report what happened.

Instead of testing mods one at a time, it halves the suspect list every round. A library of, say, 60 active mods is isolated in roughly six launches rather than sixty.

When to reach for it

Open the ◆ diagnose panel (Crash & log triage) after a bad run. If Silo can tie the crash to a specific mod, it lists that mod directly and you don't need bisection. If the log shows an abnormal exit but no mod logged an error first, the panel says the cause is likely an interaction and offers ◆ Run guided bisection. There's also a Run guided bisection → link for something misbehaving that the log doesn't explain even after a clean exit. You need at least two active non-map mods for the button to enable.

The loop you'll follow

1. Press Start. Silo tells you the mod count and roughly how many launches to expect.
2. Each round it applies a test half (the rest are temporarily off) and shows Round N with how many launches remain at most.
3. Press ▶ Launch FS25, load the save that was breaking, try to reproduce the problem, then quit to desktop.
4. Back in Silo, press I've quit the game →. Silo peeks at the log and hints whether it looks like another crash or a clean exit.
5. Answer the verdict: Still broken or It's fine now. Silo narrows to the guilty half and sets up the next round.

It ends one of two ways. Most likely culprit names a single mod — disable or update it, or report the pairing to its author if it only breaks alongside another mod. No single mod is at fault means every half came back clean, so the problem is a combination (or isn't mod-related). Silo reports this honestly rather than blaming an innocent mod.

Safety and reversibility

Bisection is crash-safe. Before it changes anything, Silo snapshots your exact active set. It's restored automatically when you reach a result, when you press Restore my mods & finish, or when you cancel with the ✕ (Cancel & restore). Maps and required mods stay on every round so your save still loads. If the app closes mid-run, the next time you open Silo a banner offers Restore my mod set — your originals are never lost.

Savegame & settings editing

Silo can edit two FS25 configuration files for you without launching the game: a career save's careerSavegame.xml (difficulty and gameplay rules) and the global game.xml (graphics and performance). Both are plain XML that the game normally only lets you touch through in-game menus. Reach for this when you want to dial in difficulty before you start playing, drop graphics to chase frame rate, or copy the same settings across saves quickly.

Editing a savegame's settings

Open the Savegames panel from the top bar. Each row shows the save's name, its slot and map, and how many of its mods are in your library. Click Configure to open the editor for that save.

The editor lists a curated, safe subset of fields — Save name, Economic difficulty, Growth, Fuel usage, Dirt interval, Time scale, Autosave interval, and toggles for crop destruction, plowing required, stones, weeds, lime, snow, traffic, and whether helpers buy their own fuel, seeds, and fertilizer. Two Presets, Casual and Realistic, fill several fields at once; you can still adjust anything afterward. Silo edits only the values you change and leaves the save's internal fields alone.

Editing graphics & performance

Open Settings (the gear, top right), find Graphics & performance, and click Edit game.xml ↗. Fields include Performance class, Anisotropic filtering, Shadow map size, Max shadow lights, Soft shadows, FSR upscaling, Volumetric fog, Cloud shadows, and V-Sync, with Performance, Balanced, and Quality presets. Graphics changes take effect the next time you launch the game.

Saving changes

In either editor, Save changes stays disabled until you actually change something, then writes your edits and briefly shows saved ✓. Close the panel any time with the ✕ to discard unsaved edits.

Every save is reversible. Before overwriting a file, Silo copies the original to a .bak file beside it (for example game.xml.bak) — and if that backup can't be made, the write is aborted rather than risking your file. The new file is then swapped in atomically, so a disk or permission error can't leave a half-written config. To roll back, delete the edited .xml and rename the .bak back. Writes are confined to your FS25 user folder.

For a full snapshot of a career before you experiment, use Back up in the Savegames panel. It copies the entire savegame folder into a SiloBackups folder in your FS25 user directory, timestamped, leaving the original untouched.

Editing a mod's own config

Many FS25 mods keep their own options in a small settings XML file that the game writes under modSettings/<ModName>/ in your FS25 user folder. Silo's mod-config editor lets you change those values from a form instead of hand-editing the file. This is separate from editing your savegame or game.xml graphics/game settings, which have their own editor with a curated set of known options.

Opening the editor

On a mod's row in your library, click the gear button (⚙, tooltipped Edit this mod's settings). It only appears for mods that actually have a settings file, so if you don't see it, that mod has nothing for Silo to edit yet. The panel opens with the mod's title at the top and Mod settings beneath it. If Silo finds no files, it says No settings files found for this mod yet.

The generated form

For each settings file, Silo reads the mod's typed values and builds a field per option:

• A true/false value becomes a toggle switch.
• A whole number or decimal becomes a number input.
• Anything else becomes a plain text box.

Labels come from the mod's own setting names, so they read the way the mod author wrote them. Change what you want, then click Save changes — the button stays disabled until you've actually edited something. Only the values you changed are written back; the rest of the file is re-emitted exactly as it was read. A brief saved ✓ confirms the write.

Raw XML mode

Each file has a raw XML link in its header that swaps the form for a text area of the file's exact contents; the same link (now reading form) switches back. Use raw mode when you need to edit something the form doesn't cover — Silo will tell you when it couldn't model this file as a form — use "raw XML" to edit it directly. Click Save raw XML to write your text back verbatim.

Safety and reversibility

Every save is reversible. Before writing, Silo copies the current file to <name>.xml.bak in the same folder, and that backup must succeed or the save is aborted. The new content is written to a temporary sibling file and then atomically renamed into place, so a disk or permission error can never leave you with a half-written config — if the swap fails, the original is restored from the backup. Writes are confined to your FS25 user folder. To undo a change, restore the file from its .xml.bak.

Multiplayer mod-set sync

Everyone in an FS25 session needs the same mods, at the same versions, with the same files. A mismatch is the number-one reason a join fails, and the game's error rarely tells you which mod is wrong. Silo turns that guessing game into a checklist: the host publishes a hashed list of their active set, and each joiner checks their own set against it.

Open it from the Multiplayer button in the top bar. The panel has two sides: Host — share your set and Joiner — check you match. Both act only on your current active set (the mods Silo has switched on).

This whole feature is read-only for your mods. It hashes files and writes one manifest file where you choose. It never changes your active set, your mods, or your game files — you make any fixes yourself.

Host: export your set

Click Export active set →. Silo hashes each active zip mod (recording its name, version, content hash, and size), then prompts you to save a .silomp file (default my-modset.silomp). You'll see a note like "Saved a manifest of N mods." Send that file to everyone joining — over Discord, email, or a shared folder. Re-export whenever you change your loadout so the manifest stays current.

Joiner: verify against the host's manifest

Click Verify against a manifest… and pick the .silomp file the host sent. Silo hashes your active set, compares it, and shows either "Your set matches. You're clear to join." or "Your set doesn't match yet." with a grouped fix-list:

• Get these — the host has them, you don't. Add each mod.
• Wrong version — shows "yours X → need Y". Update to the host's version.
• Same version, different file — the version matches but the bytes differ. Re-download to be safe.
• Turn these off — you have mods the host doesn't. Disable them for this session.

Work through the list, then click Verify against a manifest… again to confirm you're clear.

What Silo can and can't check

The comparison is byte-strict: a re-zip with identical contents still reads as different, so Silo errs toward "re-download to be sure" — the safe direction for multiplayer. Unpacked folder mods (dev mods) can't be byte-verified; if any are active you'll see a caveat, and they're marked unmatched in a manifest. For clean verification, use packed .zip mods on both sides.

Filltype bridge (the sugar-beet fix)

Some maps add their own fill types (a custom crop or material) that none of your equipment will touch. FS25 decides what a trailer, shovel, silo, or sell point can handle by category — a trailer takes BULK, a front loader takes SHOVEL, and so on. When a map's fill type isn't a member of any category your gear accepts, nothing can harvest, haul, store, or sell it, and there's no in-game setting to fix it.

The filltype bridge solves this without editing a single vehicle. Silo generates a tiny standalone companion mod whose only job is to add the fill type into the categories you choose. It references the fill type by name and adds nothing else — no textures, no redefinition, no balance changes. It's a data-only mod, so it's multiplayer-safe as long as everyone in the session has it.

When to reach for it

Use it when a map fill type simply won't work with equipment that should obviously handle it — your trailer won't fill, a silo won't store it, or a sell point doesn't list it. The classic case is a sugar-beet-style crop a map introduces that the base trailers ignore.

Generate one

1. Click the ⛓ bridge button in the stat bar. The Filltype compatibility bridge panel opens.
2. In Fill type name(s), type the internal name(s), space- or comma-separated (for example SUGARBEET BEETPULP). Case doesn't matter; it's usually the crop or material name in caps. The chips below echo what Silo parsed.
3. Under Add to, pick the categories, grouped as Haul & load, Store & sell, and Forage & feed. A sensible default is preselected (trailers, tippers, front loaders, farm silos, and bulk sell points).
4. Leave the Mod name as is or rename it — it must start with FS25_. This is the .zip filename.
5. Click Generate bridge mod.

Silo writes the .zip into your mods folder and rescans, so it appears in your library right away. Enable it, load your save, and the fill type should now work with the equipment in the categories you checked.

Reversible and low-risk. The bridge only adds category membership — it never changes realism or economy. If two mods both define the fill type, load order still decides its properties. To undo it completely, just disable or delete the generated .zip. Silo won't overwrite an existing file: if a bridge of the same name is already there, generation stops and tells you.

Bindings map

The Bindings map shows the complete control layout that FS25's in-game help never fully lists: every action paired with the key, mouse button, or gamepad button that triggers it. Silo reads this straight from the game's own inputBinding.xml and lays it out so you can scan it in one place.

When to reach for it

Open it when a control feels double-booked — you press a key and two things happen, or a mod's action seems to collide with a base-game one. It is the fastest way to answer "what is everything this key does?" without hunting through the settings menus one action at a time.

Opening it

1. Find the ⌨ bindings button in the stat bar near the top of the main window.
2. Click it. Silo reads inputBinding.xml from your FS25 user folder and opens the Control bindings panel.

If you have never launched FS25, there is no bindings file yet and Silo tells you so: "No inputBinding.xml found — launch FS25 at least once first." Start the game once, set your controls, and try again.

What you'll see

The header shows totals — how many actions, bindings, and devices were found. Below that, bindings are grouped by device (typically Keyboard & Mouse and Gamepad). Each device has up to two parts:

• Inputs bound to more than one action — a highlighted list of every physical input that drives two or more actions on that device, with all the actions it maps to. This is where a real clash would show up.
• All bindings — the full action-to-input list for that device.

Key names are cleaned up for reading (prefixes like KEY_ are dropped, and multi-key combinations are joined with +).

Finding a specific control

Use the Search actions or keys… box at the top of the panel. Typing filters both sections live — search by action name (for example, handtool) or by key (for example, x) to jump straight to what you care about.

It's a view, not a verdict

The reused-input section is deliberately not called a conflict list. On a normal profile the same input legitimately drives many actions in non-overlapping contexts — a mouse axis feeds a dozen contextual controls; one button is a flashlight on foot and headlights in a vehicle. Silo surfaces the reuse and lets you judge whether any of it is actually a problem.

Read-only and completely safe. The Bindings map only reads inputBinding.xml; it never edits, rebinds, or writes anything back. Silo has no binding editor — to change a control, use the settings menu inside FS25. Nothing here can alter your game files, so there is nothing to undo.

Settings & accounts

Open the Settings panel from the gear icon (⚙) in the top bar. It slides out on the right and covers appearance, your detected folders, account connections, diagnostics, and library layout. Nothing here changes your game files until you press a specific button, and the file-touching actions are reversible.

Appearance

Under Appearance, pick system, light, or dark. System follows your OS theme; the other two force that look. Your choice is saved and reapplied on the next launch.

Folders

Mods folder and Game show the paths Silo detected, each with an Open ↗ link to reveal it in your file manager. If the game install isn't found, the Launch button is hidden. When your user directory is known, Graphics & performance offers Edit game.xml ↗ to tune presets (Performance / Balanced / Quality) without starting the game.

Diagnostics — Export report

Export report ↗ writes a shareable Markdown file (silo-report.md) summarizing your environment, library counts by category, active set, detected conflicts, and health issues. Reach for it when asking for help or comparing setups. It only reads your library and saves a text file — it changes nothing.

Auto-file new mods

This toggle is off by default. When on, Silo moves newly-downloaded .zip mods into your library on load and keeps them active, so you skip the manual Organize step. Leave it off if you prefer to review new downloads first. The setting is remembered between sessions.

Library layout & maintenance

Under Library layout:

• Organize sorts your .zip mods into mods/archive/<Category>/ subfolders (which the game ignores) and projects the active set back via hardlinks — no duplication, fully reversible.
• ↻ Rebuild categories re-scans every mod from scratch. Use it after a Silo update improves categorization so existing mods pick up the better categories.
• Restore vanilla layout appears only when mods are organized. It moves every mod back out of archive/ and removes all links, returning you to a plain flat mods/ folder. You'll confirm first.

Restore vanilla does not delete any mods — it only undoes Silo's organization. If some files can't be moved, Silo reports the errors rather than leaving things half-done.

Connecting GitHub

Under GitHub account, press Connect GitHub. A browser opens to github.com/login/device; enter the code Silo shows and authorize. Connecting gives faster update checks (5,000 requests/hour) and access to private repos, and it enables in-app GitHub installs from the Browse tab. By default the connection is read-only; use Enable actions to grant the public_repo scope so Star and Watch land on your account. You can Disconnect anytime, or use a Personal Access Token instead via the token option.

Connecting Nexus Mods

Under Nexus Mods account, press Connect Nexus, then paste your personal API key (there's a Get your key ↗ link to your Nexus account page). The key stays on this machine. Once connected, you can endorse mods from their detail cards. Disconnect removes the key.

The panel footer shows your installed Silo version.

Troubleshooting & FAQ

Windows SmartScreen (or macOS Gatekeeper) warns on first launch

Expected. Silo is open source and its builds are unsigned, so the operating system doesn't recognize the publisher yet. It is not a sign anything is wrong.

• Windows: click More info, then Run anyway.
• macOS: right-click the app and choose Open from the menu.

If you'd rather not take our word for it, you can read or build the source yourself from the GitHub repository.

Do I need Developer Mode or administrator rights?

Almost never. When you organize your library, Silo tucks each mod into a mods/archive/<Category>/ subfolder (the game only reads the flat root, so it ignores these) and projects the active set back into the root:

• Packed .zip mods project as hardlinks — same volume, no admin, no Developer Mode, and no second copy on disk.
• Only unpacked folder-mods use a directory junction/symlink, and if that isn't available Silo falls back to a plain copy.

Since most mods are zips, most people never hit an elevation prompt.

Is my library safe? Can I undo this?

Yes. Projection is fully reversible. Open Settings and use Restore vanilla layout to move every mod back into a plain flat mods/ folder and clear Silo's bookkeeping.

Silo never deletes a file it doesn't recognize and never removes the only copy of a mod. If you swap your own build into the mods folder, Silo detects that it isn't the file it projected and leaves it untouched. Config edits are backed up to a .bak first.

Where does Silo store its data?

Your mods stay in your game's mods folder — Silo only rearranges them. Silo's own database (silo.db: the library index and cache) lives in the app's per-user data directory. Any account tokens go into your OS credential store (Windows Credential Manager, macOS Keychain, Linux Secret Service), not in plain text.

Why does a mod show "Unverified"?

The Integrity check in a mod's detail drawer compares your file against the trusted build SiloAPI hashed from its source. Unverified means there's no trusted build to compare against yet — usually because that mod isn't in the catalog. It is not a warning about the mod. Folder mods can't be verified at all (there's no archive to hash). This is a provenance check, not a virus scan.

Connecting GitHub or Nexus accounts

Both are optional and live in Settings.

• GitHub account → Connect GitHub: a browser opens to github.com/login/device; type in the code shown. This raises update-check limits to 5,000/hr and enables Star/Watch on mod pages.
• Nexus Mods account → Connect Nexus: paste your personal API key to endorse mods from their cards.

Credentials stay on your machine, and a Disconnect button removes them at any time.