tehAon’s Fuel On Demand – Fuel Saver – Forge and Campfire Auto Off (Server-Side)

Remove 0Harmony.dll

Required if you are on game V3.0.1. Every earlier version throws an error on every
workstation tick.
- Fixed: on game V3.0.1 the mod threw "MissingMethodException: Method not found:
Recipe RecipeQueueItem.get_Recipe()" on every workstation tick. V3.0.1 changed
RecipeQueueItem.Recipe from a property into a plain field, and the mod had been
compiled against the property. The mod never needed that member, so it no longer
reads it at all - one build now runs on game V3.0.0 and V3.0.1 alike. Fuel
behaviour is unchanged.
- The mod now gets out of the way instead of breaking your game. If a future update
moves something else out from under it, it checks at startup that every game
member it reads still exists and refuses to patch if not, and if something still
throws mid-game it disables itself after the first exception instead of spamming
one per station per tick. Either way your workstations fall back to vanilla
behaviour and the game keeps working.
- The mod now tells you which game version it is for, in your server log:
"[FuelOnDemand] 0.2.3 - for game V3.0.0-V3.0.1; built against V 3.0.0 (b259),
running on V 3.0.1 (b4)". The game has no way to warn you that you installed a
build for the wrong version, so the mod checks for itself. The download filename
carries the game version too.
0.2.2
- Fixed: a workstation whose work finished while a player had its window open would
never go out again - not when they closed it, not when they walked away. It burned
until someone switched it off by hand.
Why: the game runs the workstation's tick on the CLIENT while its window is open,
and that client is vanilla (this is a server-side mod). So the mod could not act at
the moment the work finished, and the "work just finished" signal was recomputed
from scratch every tick, so it was gone by the time the window closed. The signal
is now remembered until it can be acted on.
- What you will see: while a player stands in the open window the station keeps
burning, as in vanilla - that tick…

- **Verified on game 3.1 — `GAME_VERSIONS` widened from `V3.0.0-V3.0.1` to `V3.0.0-V3.1`.** The old label
meant "the last version anyone got round to checking", not that 3.1 was known bad. Anyone on
3.1 was being told to skip a mod that works. Three checks, none of which needs the mod to be
played: every external member the DLL binds to resolves against 3.0.0, 3.0.1 and 3.1; a
headless 3.1 dedicated server loaded the mod, applied its Harmony patches and reached
`StartGame done` with no exceptions and no dropped XML patch.
- **`package.sh` now refuses to build a zip whose label it cannot back up.** New
`tools/check_game_versions.py` reads `GAME_VERSIONS`, finds a game build for each version
named, and resolves every reference in the DLL against all of them — a claimed version with
no build available fails too, rather than quietly passing. It also compares `GAME_VERSIONS`
against the same claim spelled in C#, so the zip name and the line the mod prints at startup
cannot drift apart.
This is the check that would have caught DroneAutomation v0.7.3, which shipped labelled
`V3.0.0-V3.1` and could not run on 3.0.0 at all: it was built against a newer game, which
moved `AddItem` onto a base class 3.0.0 does not have. Build against the **oldest** version
you claim — a reference made on a derived type still resolves on newer builds, but one made
on a base type introduced later resolves on nothing older.
- **No behaviour change.** The only difference inside the DLL is the label string it logs at
startup. The disable gate has always been `Compat.Missing()` — a live reflection check for the
members the mod actually reads — so v0.2.3 already ran correctly on 3.1; it just announced itself
as "for game V3.0.0-V3.0.1" while doing it, and the Nexus file row said the same. Nobody on 3.1
was broken. They were told not to bother.

NEW: Config/fuelondemand.xml. Three settings, all ON by default — and ON is exactly what every earlier version did, so a server that never opens the file runs the mod it already ran. Nothing changes unless you change it.
- CapFuelToWork — ON: fuel each tick is capped at the work remaining. OFF: vanilla, a full tick of fuel however little work was left.
- ExtinguishWhenDone — ON: the fire goes out when the craft queue and the raw material run out. OFF: vanilla, it burns until a player switches it off.
- PauseWhenJammed — ON: a station whose output or melted-unit slot is full stops eating fuel. OFF: vanilla, it burns a stack of wood having smelted nothing.
The common case this answers: "cap the overburn but leave my forges lit" — CapFuelToWork true, ExtinguishWhenDone false. It also lets a server running another fuel mod hand over one behaviour instead of choosing between the two mods.
YOUR SETTINGS SURVIVE UPDATES: fuelondemand.xml is overwritten by every download, which is how new settings and their documentation reach you. Put only the lines you changed into Config/fuelondemand.local.xml — it ships in no download and is deleted from the release zip at packaging time, so nothing can write over it.
A typo costs you the setting, not the server. A value that is not true/false, an unknown setting name, or a malformed file each log one line naming what could not be read, and keep the default. The settings in force are printed at startup:
INF [FuelOnDemand] config: capFuelToWork=on extinguishWhenDone=on pauseWhenJammed=on
No behaviour change with the defaults, and no new code on the fuel path — each setting gates a branch that already existed. The self-test grew nine assertions covering both states of every toggle and every parse failure; 46/46 pass on a headless V3.1.0 dedicated server with no exceptions.
Game versions unchanged: V3.0.0, V3.0.1 and V3.1 — one build covers all three. Built against 3.0.0.

- **New setting `ExtinguishWhenJammed`, on by default.** A stalled station puts its fire out, and
lights it again by itself once the output can take the result.
`PauseWhenJammed` already stopped the burn, but it did it silently — the forge sat there lit,
looking like it was working, consuming nothing. That is indistinguishable from a broken mod, and
it is what people report as one. A dark forge says "I cannot work" in the only language the game
has.
It only ever relights a fire **this mod** put out; one you turned off by hand stays off. That is a
latch, not a recomputed "is it dark and jammed" test, precisely so the two cannot be confused.
Order with `SkipJammedCrafts` needs no coordination and falls out of the tick: `SkipJam.Consider`
runs in `UpdateTick`'s prefix and the fire decision in its postfix, so the skip is always tried
first and a station only goes dark once nothing in the queue could deposit. On a mixed queue you
get the reorder; on a single-recipe queue you get the fire going out.
The decision is one pure function, `Station.DecideJamFire`, with ten self-test cases covering the
window-open, feature-off, kill-switch, no-fuel and not-ours-to-relight paths.
- **New setting `SkipJammedCrafts`, on by default.** When the item being crafted has nowhere to go,
the station moves a later queue entry to the front and works on that instead of stopping dead.
The queue keeps its relative order otherwise; nothing is cancelled, refunded or lost, and the
skipped entry keeps the craft time it had already spent.
**Read this before relying on it — it helps in one case and not the common one.** The game will
put a finished item in *any* empty output slot, whatever the item is. So a station that jammed has
already proved it has no empty slot: if it had one, the item that jammed would have gone there.
The only way anything else can fit is by stacking onto a part-filled stack of its own exact item
type, with room for the whole batch at once.
- Helps: five capped stacks and one…

- **Verified on game 3.2 — `GAME_VERSIONS` widened to `V3.0.0-V3.2.0`.** The old label meant "the newest
version anyone had checked", not that 3.2 was known bad; anyone on 3.2 was being told to skip a
mod that works. Checked on a real **V3.2.0 (b10)** dedicated server — the build the public Steam
branch serves, and the one a default client is on: the mod loaded, applied its patches, and the
server reached its start with no exceptions, no missing members and no dropped XML patch.
Every external member the DLL binds to resolves against every version claimed, and the DLL is
built against the oldest of them so nothing can bind to a type newer than that build.

- Works on game 3.3. Game 3.3 turned the item-stack fields this mod reads into properties. Every earlier build threw an error the first time a forge ticked on 3.3, switched itself off, and left stations burning fuel the vanilla way. Those reads are now resolved by name at startup, so the same build runs on V3.0.0 through V3.3.0.
- The startup check now covers those item members too: on a game version that moves them again the mod says so at load and patches nothing.
- Checked on real dedicated servers of V3.0.0, V3.0.1, V3.1, V3.2.0 and V3.3.0 (b18). No setting changed and nothing in a save is touched: drop the new folder over the old one.