One tick, then another.
Production is always a tick behind.

What the list does not show you is the field that decides everything, so it is worth knowing before you press anything: every one of those resources has a Demand of 50. Not because someone chose 50 for iron and again for spices, but because 50 is the model's default and the demo never overrides it.

Hold that next to the stock column. Iron Ore has four times more stock than demand. Food Rations has three times. Luxury Spices has less stock than demand. Those three relationships are the entire plot of what happens next.

So a sim step is also a save. There is no separate "commit this run" — the tick happens and the result is on disk before you have finished reading the line.

Now look at the list again.

Iron Ore lost 93% of its value in a single tick, which looks alarming and is the most common reason someone decides the simulation is broken. It is not. Here is the whole calculation the tool performs on every resource, every tick.

Each tick, before any of the above, the tool rolls once against Shock Prob — 0.3 by default. On a hit it picks one resource at random and multiplies its stock by 0.6, then writes an Event row into the trade ledger reading “Shortage on <resource>!”.

Neither of the two ticks above rolled a shock, which is why the arithmetic came out clean. If your numbers disagree with your prediction by a suspiciously round 40%, check the ledger before you check your maths.

The list on the left rounds for display: Iron Ore reads 185 @ 0.10 while the file holds 185.375. For a first tutorial that does not matter, but the moment you start checking your own predictions it does, and the file is where the honest number is.

This is the single most common reason someone decides the trade panel is unfinished, and it is worth being precise about what is going on, because the tool is doing exactly what it was written to do and telling you nothing about it.

Buy and Sell act on a market, never on a resource. The handler's first line checks that the current selection is a market and returns immediately if it is not. There is no message on that path, so a resource selection and a broken button look identical from the outside.

Which raises the obvious question, since you never told it you wanted iron: where did Iron Ore come from?

From the market's first offer. The handler takes Offers[0] and trades that, whatever else the market carries and whatever is highlighted in the list. Frontier Outpost happens to list iron first, so iron is what you bought. Reorder the offers and the same button spends your money on something else.

Each tick, every offer moves one fifth of the remaining distance toward the market's biased view of the resource's current value. The sell side chases the same target scaled to 85%, and that gap between the two targets is where the market's spread comes from — it is not configured anywhere, it falls out of the multiplier.

That line is not a placeholder waiting on a simulation run — it is a hard precondition. Arbitrage is defined as a route between markets, so a single market can never produce one however long you run it.

The tool now compares, for each resource, the cheapest buy price across every market against the dearest sell price, discards the pairing if both fall in the same market, and subtracts the transport cost. What survives with a positive number is a route.

The bias spread did not change. The toll did not change. The price of the thing being moved changed, and that was enough to flip the route from impossible to worth 14.78 a unit.

The reason is that TransportCost is an absolute figure, not a percentage. Moving one unit of anything costs 0.50. On a resource whose entire value is 0.10 that toll is five times the goods, and no regional bias can ever recover it — the prices simply do not have room to differ by more than half a coin. On a resource worth 13.72, the same toll is less than 4% of the value and is trivially cleared.

The second row is the one worth sitting with. With only 15 ore against a batch size of 10, the recipe did not refuse to run and it did not run once — it ran one and a half times, drained the input to exactly zero, and produced 1.5 of the output.

The rate is a ceiling. What actually runs is the smallest of the rate and what each input can cover, and that quantity is a real number rather than a whole one. So a recipe never stalls for want of a full batch; it simply runs smaller and smaller as its input runs down.

The asymmetry is in the order the tool does things. It resolves every input before it commits to anything, and abandons the recipe if one of them is missing. It resolves each output only when it comes to add it, long after the inputs have already been taken away — and an output it cannot resolve is skipped rather than rolled back.

Within a single tick the tool prices everything first and produces second. The price loop reads the stock as it stood at the start of the tick, works out every resource's new value from that, and only then do the recipes move any stock around.

Measured on a recipe consuming 20 ore a tick: the ore's stock went from 100 to 77.5 during the tick, while its price was calculated from 100. The drop the recipe caused shows up in the price on the next tick.

The name comes from your mod name, lowercased and made filename-safe, so an unnamed project exports as unnamed_mod_… — set the mod name before you ship or you will hand someone a file called unnamed. The destination is the tool's output folder, beside the equilibrium folder you have been working in the whole time.

Unlike the three working files, which split the economy into resources, markets and state, the runtime export is one document containing all of it — resources, markets and their offers, the sim parameters, the player wallet, the trade ledger and your recipes. The demo economy with one recipe comes to about two kilobytes.