Resource Manager Decoded

00 What this system is

If you have flown DCS for years without knowing there is a logistics model in it, that is the intended experience. It ships switched off.

Every airfield, FARP and ship in DCS carries an inventory — airframes, munitions, and four kinds of fuel. Most players never see it, because by default every warehouse is marked unlimited and the whole mechanism stays invisible. You call for rearm, and the missiles are simply there.

Clear those checkboxes and DCS turns into a supply simulator. Stock becomes finite and real. Rearming a Hornet takes actual missiles out of the airfield's holdings; refuelling draws actual kilograms of jet fuel. Spawn into a dynamic slot and you have consumed an airframe. When a base runs out of something, it quietly stops appearing in the rearm menu — no warning, no explanation.

The Resource Manager is where this is configured: in the Mission Editor, select an airfield, FARP or ship and open its warehouse. You get its stock list, and — the part this document is about — a supply graph. Any warehouse can be nominated as the supplier of any other. When a consumer's stock in some category drops past a threshold, its supplier ships the difference automatically.

That abstraction is the whole of DCS's built-in attrition model, and it is the only mechanism by which a mission can genuinely run out of something. A campaign designer who wants a front line that degrades, a FARP that can be starved, or an offensive that culminates has this system and nothing else.

It has also never been documented. The four settings that govern it — speed, periodicity, size and the operating levels — are each named misleadingly enough that the obvious reading of all four is wrong. What follows is what they actually do, measured rather than assumed.

01 The six settings

Six things are yours to set. Three of them are named after something they don't do, so read this before trusting the editor's labels.

They divide cleanly by which end of a link they belong to, and that division is the first thing to internalise, because it is not what the editor implies. A warehouse's speed, periodicity and size govern only what it sends. Nothing you set on a FARP affects deliveries arriving at it.

Initial stock

How much of each item a warehouse holds when the mission starts — set per aircraft type, per weapon type, and per fuel. It quietly does a second job: it is also the full mark. Resupply always tops a warehouse back up to this figure, and the minimum-stock percentage is a percentage of it. There is no separate capacity field, so this single number is both the opening balance and the target — and nothing stops deliveries from stacking above it.

Minimum stock, % — OperatingLevel_Air / _Eqp / _Fuel

The reorder point, and the only one of the six that the receiving warehouse controls. When a category drops below this percentage of initial stock, the warehouse asks for the difference. It is set separately for aircraft, equipment and fuel, so the three categories can reorder at different points.

Two traps. It is a percentage, not a number of items — 10 means 10%, not ten missiles. And 0 does not mean "always resupply"; it means the warehouse can never be below its threshold, so it never asks for anything at all.

The comparison is also strict. A warehouse resting exactly on its threshold is not below it and stays silent: 100 rounds at 10% sits at 10, and a consumer drained to precisely 10 was measured making no request for the length of a run. It takes one more round to start the resupply.

Suppliers

The list of warehouses permitted to feed this one, declared on the receiving end. A link is strictly one-way — naming a depot as your supplier gives you no ability to send anything back — and there is no per-category version, so a supplier offers everything it has.

List several and the nearest is drawn down first, regardless of the order you listed them in, with the rest acting as backstops as each runs dry. The list is fixed at mission load and cannot be changed by script.

Speed

How fast a delivery travels, and the only setting that behaves as its name suggests. Distance is the straight line between the two warehouses; roads, terrain and water are all ignored, though altitude difference does count.

The editor displays km/h, but the .miz stores metres per second — so hand-editing the file and typing 60 gives you 216 km/h, not 60.

Periodicity

Nothing about this is periodic. It is not a schedule, not a poll interval, and not how often resupply is checked — that check is a fixed ~5 seconds you cannot influence.

What it actually does is add a flat delay to every delivery: 18 seconds per unit, on top of the travel time. The default of 30 therefore adds nine minutes to every single delivery, which most missions are paying without knowing it. Lower is strictly better; 0 is the floor, and still costs 15 s.

Size

How quickly cargo comes off at the receiving end, in tonnes per minute. It does not cap how much gets sent — an order always dispatches in full, however large — it only meters the arrival. A heavy order therefore lands in instalments, each usable the moment it arrives.

Because the budget is measured in tonnes, an item's mass sets its rate: at size = 10 that is 221 Hellfires a minute, or about two AH-64D airframes. It is also one shared budget for the whole link, so a bulk airframe order delays the fuel queued behind it.

02 The law

Everything here reduces to the block below.

03 Every field in the warehouse record

The warehouses entry in a .miz has two top-level keys: airports (keyed by airdrome id) and warehouses (keyed by the unit id of a FARP, ship or static warehouse). Both hold the same record shape.

Decoding the weapons array

Weapons carry no names, only a wsType quadruple following the hierarchy in Scripts/Database/wsTypes.lua. AGM-114K is {4, 4, 8, 39} — Weapon → Missile → AS_Missile → 39. Going the other way, getResourceMap() returns all 2,148 valid item keys with their quadruples.

04 What everyone gets wrong

Four widely held beliefs about this system are false. Each was tested; each failed.

Overturned  “size caps how much moves per delivery”

It caps nothing. Thirteen links were given an identical 1,000-unit shortfall and different size values; every one shipped the full 1,000 — including the link with size = 0.

size is a shared unload budget in tonnes per minute. At size = 10 a link delivered 221 AGM-114K per minute; at 45.4 kg each that is 10 t/min, matching to 0.3%.

Overturned  “periodicity is how often it checks”

The check interval is a fixed ~5 s regardless. Links at periodicity 0, 1 and 30 all dispatched at the same instant, 5.09 s after the shortfall appeared.

What it actually does is lengthen the journey, by 18 s per unit. At the default of 30 that is nine extra minutes on every delivery — a pure penalty most missions are paying unknowingly.

18 × periodicity holds exactly from 1 to 30, with zero a special case giving 15 s. You cannot switch the penalty off, only reduce it to its floor.

Overturned  “speed is in km/h”

The stored value is metres per second; the editor converts for display. Hand-editing a .miz and writing 60 actually sets 216 km/h. The default 16.666666 is exactly 60 km/h — the figure the DCS 1.2.5 patch note referred to.

Overturned  “distance is measured across the map”

It is the 3D straight line. Four links with an identical 2,000 m horizontal separation — two flat, two spanning 1,720 m of Elbrus relief — split by 38.5 s. A second site at a 2% relief ratio ruled out a linear elevation term: Pythagorean missed by 0.4 s, the linear alternative by 33 s.

Roads and terrain are ignored entirely — a link can cross a mountain range, a lake or open sea with no penalty — but altitude is part of the distance. Transit is symmetric: uphill and downhill arrive together.

05 How a delivery works

Stock exists nowhere during transit

The supplier is debited at dispatch and the consumer credited on arrival. In between, the goods are in neither warehouse. A supplier can look drained while the consumer is still empty — normal, and the most confusing thing to watch live.

One shared budget, not one per commodity

Each link has a single unload pipeline of size tonnes per minute, spent in order weapons, then aircraft, then liquids. A shipment of 200 AGM-114K plus 100 t of fuel delivered 200 weapons (9,060 kg) and 90,940 kg of fuel in its first minute — exactly 100 t combined — with the remaining 9,060 kg following 60 s later.

Within a category: ascending wsType

Order is by the item's wsType level-4 id — not list order, not alphabetical, not stock level. Measured with five weapon types whose orderings all disagreed:

Delivery is per-tonne, by item mass

Rate is the budget divided by the item's transport mass. Weapons match their real mass closely; aircraft use a figure a few percent below the listed M_empty, from a source that could not be identified — so use measured rates rather than a formula for airframes.

Planes and helicopters are not distinct — both sit in the same aircraft queue and obey the same ordering.

Partial deliveries are immediately usable

Each 60-second batch is live stock the moment it lands. Mid-unload, a warehouse holding 333 of an inbound 3,000 reported exactly 333, allowed 166 to be consumed, and carried on delivering from the reduced figure. Nothing is held in escrow until a shipment completes.

Top-up is always to full

OperatingLevel decides whether to ask; it never limits how much. A warehouse at 30% with a 10% threshold asks for nothing; the same warehouse with a 50% threshold asks for the entire 70% shortfall.

Requests account for cargo already in flight

A consumer at 500 with 500 already inbound, drained to zero, requested exactly 500 more — not 1,000. Multiple shipments can share a link and arrive independently at their own transit times, but they queue through the one unload budget.

An order that can't be filled keeps its balance

When the suppliers between them hold less than the consumer asked for, they ship everything they have — and the shortfall is remembered. The consumer does not need to fall below OperatingLevel a second time; the balance is reclaimed the moment any supplier has stock again.

A consumer wanting 1,000 from a depot holding 800 took the 800 and settled at 80% — comfortably above its own 10% threshold, so no fresh trigger was possible. Restocking the depot produced a request for exactly 200 on the next cycle. A second consumer, 20 short of a 100% threshold, likewise collected precisely its missing 20.

A reclaimed balance waits its normal turn

Being owed stock earns a consumer no priority. The balance is dispatched immediately — within one cycle of stock appearing, alongside every other pending order — but it then joins the supplier's unload queue in ordinary declaration order, behind consumers that ordered later.

The practical hazard is visibility. Those 200 missiles were debited from the depot at t+7 and credited to the FARP at t+746. For twelve minutes they appeared on neither node's books — a designer watching stock levels sees the depot pay and the FARP stay flat, and reasonably concludes the delivery failed. It had not; it was queued.

06 Many links at once

A link is configured entirely from its supplying end

All three transit and throughput parameters — speed, periodicity and size — are read from the supplier. The consumer's copies are ignored. Measured by mismatching the two ends of otherwise identical 10 km links:

The size = 0 pair is decisive on its own: a zero on the supplier destroyed the cargo, a zero on the consumer was ignored completely.

Consumers are served in placement order

With a supplier holding 100 against three consumers wanting 60 each, the result is 60 / 40 / 0 — each filled completely before the next is considered, then the remainder, then nothing. No proportional sharing.

The order is the objects' order in the .miz, i.e. the order you placed them in the editor. Tested against every alternative with all four made to disagree:

Suppliers are chosen nearest-first, with fall-through

With two suppliers able to fill an order, only the nearest ships — and reversing the suppliers list changes nothing, so proximity decides, not list order. When the nearest cannot cover it, the remainder falls through exactly to the next: a 1,000-unit order split 300 / 700 between a short near supplier and a full far one, with nothing unmet.

So a rear depot is a genuine backstop. Chain suppliers by distance and the system drains the nearest first, cascading outward as each runs dry.

The split is decided in a single pass, on one tick — the consumer does not wait to see what the near supplier actually delivers before approaching the far one. Two suppliers holding 50 and 30 against a 100-unit order were both emptied on the same trace line, 5 s after the request, leaving 20 unmet and carried as a balance. Each shipment then travels its own route at its own transit time, so a split order arrives in pieces.

The pipeline is per link — two suppliers double intake

A consumer drawing from two suppliers unloads both simultaneously, each at its own size t/min. A single link measured exactly size; two links ran concurrently. Two shipments on the same link, by contrast, queue and share one budget.

Categories can come from different suppliers

There is no per-category link field, but stocking one supplier with only airframes and another with only fuel works: the consumer draws each category from whichever supplier has it, and both ship at once.

Chains cascade one hop at a time

With C supplying B supplying A, draining A makes B ship (~5 s), which drops B below its own threshold, which makes C ship to B (~5 s later). Transits do not compound — each link runs its own journey.

Two warehouses supplying each other can shuttle stock forever

Nothing prevents A from naming B as its supplier while B names A as its. There is no cycle detection, and under the right conditions the pair will trade the same crates back and forth for the rest of the mission.

The cause is that each end tops up to its own initialAmount and knows nothing about the other's needs. Two warehouses that each want 100 collectively want 200. Hold fewer than that between them and neither can ever be satisfied, so both stay permanently below threshold, and each keeps requisitioning from the other whatever just arrived.

Each shipment is individually correct. A consumer asks to be topped up; its supplier sends what it has, minus whatever is already in flight; the unfilled remainder is carried as a balance. Every rule behaves exactly as documented — the failure is emergent, which is why it is so hard to spot in the editor.

Mutual links are not inherently broken, though. The identical topology with 1,000 rounds at A settled in a single delivery: B asked for 95, A sent it and stayed above its own threshold, and the pair went permanently quiet. The rule that separates the two cases is simply whether there is enough to go round.

A supplier serves its consumers one at a time, to completion

Outbound is serialized, not shared and not parallel. Both shipments are committed in the same tick, but the second consumer receives nothing until the first is completely unloaded — then it runs at the full rate in its turn.

So each consumer gets the full size budget, but they queue. Adding consumers to a depot does not slow any individual delivery; it puts them in line. The handover itself costs one or two 60 s ticks — measured at 120 s here and at 60 s in a separate run, a difference small enough that it has not been pinned down.

What the queue costs

Because outbound is serialized, a depot's consumers form a line. Each still gets the full size, but the nth waits for all n−1 before it. Splitting the same FARPs across two depots halves the wait, because the two queues run independently.

07 Node types & coalition

Airfields, FARPs and ships are interchangeable. Static warehouses are not.

All three airbase kinds were measured in live chains and behave identically — same ~5 s detection, same transit law, same 60 s unload batching. An airfield supplies from its getPoint() position: a link built at exactly 10,000 m produced a transit of 318.00 s against a prediction of 318.0. A ship works over open water with the same law, as supplier, consumer, or the middle of a chain.

Note the ownership mechanism differs by node type: a FARP or ship takes its side from the country it is placed under; an airfield takes it from the coalition field in its own warehouses record.

08 Capture, destruction, and change

Capture severs the chain in both directions

The test used a three-node blue chain — A supplies B, and B supplies C — with red armour driven onto B, the middle node. B flipped to red in ~22 seconds. Because B sits in the middle it is a consumer and a supplier at once, so one capture answers both halves of the question:

• B stopped being supplied. A, still blue and still full, never shipped to it again — while an identical untouched chain in the same run flowed normally throughout.
• B stopped supplying. Holding 5,000 rounds, it sent nothing to C across 32 cycles, even though C was still blue and still asking.
• Cargo already in flight from A to B was refunded to A, intact, one cycle after the capture. Nothing is handed to the enemy.

So a chain running through a captured warehouse breaks on both sides at once: C is orphaned even though A — its ultimate source — is untouched and full. There is no fallback to a more distant supplier, because links cannot change at runtime.

What "destroyed" actually means here

Worth being precise, because you cannot bomb a warehouse node out of existence. Airfields are indestructible, and a FARP pad has no damage model that removes it. Three different events get loosely called "destroying" a base, and they behave completely differently:

Only the third row is "destruction" in the sense used below, and it is a scripted despawn rather than anything a pilot can cause. It was measured by deleting a supplier FARP's underlying static object while its shipment was in transit: the consumer received the shipment in full anyway, from a supplier that no longer existed.

Cargo in transit is never simply lost. Which end receives it depends on which end went away and by what means — capture returns it to the sender, despawning delivers it to the recipient.

Bombing an airfield's buildings empties it — once

An airfield's fuel tanks and warehouse sheds are ordinary destructible scenery, and levelling them does take the stock with them. The two structure types map onto two commodity classes, cleanly and independently:

Measured by flattening only one type at each of two airfields: the one that lost its 45 fuel tanks dropped 4,000 t of fuel to zero and kept all 50,000 of its missiles, while the one that lost its 61 warehouses fell from 500 missiles to 44 and kept all 100 t of its fuel. The loss lands within about ten seconds and happens exactly once.

The supply network is untouched by any of it. A wrecked airfield keeps its links, its timings and its thresholds:

• As a supplier it goes on shipping to schedule; it simply has less to send. One shipped its surviving 366 rounds and went to zero, and its consumer took the partial fill and carried the balance like any other shortfall.
• As a consumer it is entirely unaffected — drained to zero with its fuel storage in ruins, it requested and received a full 500 rounds and 100 t, then later topped its own fuel back up on the normal threshold trigger.

One detail resisted explanation: the warehouse-bombed airfield settled on exactly 44 rounds in two independent runs, and levelling all 217 remaining structures did not move it. It is not a cap — the same base later held 1,000 — and it is not stored in any building. Treat the floor as unexplained rather than assuming it is zero.

Links cannot be changed at runtime

The supply graph is resolved once at mission load and never revisited. A FARP spawned at runtime is a real warehouse — reachable, stockable, scriptable — but it spawns empty and can never join a chain. A consumer whose declared supplier was a unit id created later, and then stocked with 50,000 rounds, received nothing across 48 cycles while an ordinary link in the same mission shipped on schedule.

There is also no API to read or write suppliers, speed, periodicity, size or OperatingLevel — a sweep of all 1,684 mission-state globals and 2,209 GUI-state globals found nothing. Every link you will ever have must be placed in the Mission Editor.

Nothing persists automatically

The persistence mechanism is a generic named-handler hook — and the engine registers zero handlers of its own, so warehouse stock does not survive a save/load unless you save it yourself.

The read-back half does not exist, and setPersistencePassthrough / getPersistenceData named in older notes are both absent on this build.

09 What actually consumes stock

This is why dynamicSpawn and allowHotStart sit in the warehouse record beside the stock and supply settings — they are part of the same consumption mechanism.

10 Traps

11 Scripting API

The Warehouse class exposes thirteen methods. Two — getResourceMap and getCargoAsWarehouse — do not appear in the changelog that introduced the class.

getInventory() shape

Three sections: aircraft keyed by DCS type name, weapon keyed by dotted path ("weapons.missiles.AGM_114K"), and liquids keyed by integer 0–3 (jet, gasoline, MW50, diesel). Liquids are in kilograms.

Enums that don't exist

Warehouse.Liquid and Airbase.Liquid are both nil — pass raw integers. Airbase.Category does exist: AIRDROME = 0, HELIPAD = 1, SHIP = 2.

Reaching mission state from a hook

From a GameGUI hook the mission environment is net.dostring_in("server", …) — not "mission". The "mission" environment exists, succeeds, and returns normally, but holds only the standard Lua library: no world, no coalition, no Warehouse. Reads come back nil and writes go nowhere, with no error to notice.

getCargoAsWarehouse() — a crate is a warehouse

A sling-loadable cargo crate is not merely a mass on a hook: it can hold aircraft, munitions and liquids exactly as an airfield does. This is the scripting half of the dynamicCargo feature, whose own tooltip describes "packing items from warehouse into the single cargo item spawned in the world for transportation", and it is why the editor shows a Resource payload grid for any static of category Cargo.

The handle is a complete warehouse — every getter and setter works, and crates are independent of each other and of nearby airbases. Two things do not follow, though:

• Payload and physical mass are unconnected. A 2,000 kg container loaded with 5,000 missiles and 90 t of fuel still reported getCargoWeight() of exactly 2000, and still displayed as "2000 kg". If you want mass to track contents, compute it yourself.
• A crate is not a supply node. The editor writes a warehouse record only for Heliport, Warehouse and GrassAirfield statics — never Cargo — so a crate cannot supply or be supplied, and Warehouse.getByName will not find it. It is a container you move yourself.

getResourceMap() — the only reliable name check

Returns all 2,148 valid item keys with their wsType quadruples: aircraft and ground types by bare name, weapons under weapons.missiles.*, weapons.bombs.*, weapons.shells.*, weapons.nurs.* and five more namespaces. Since getItemCount silently accepts garbage, this is the only way to confirm a key is real.

12 Method & evidence

The resupply scheduler is not in Lua. Searching the shipped Scripts/ and MissionEditor/ trees finds only editor UI, .miz serialization and the in-game status dialog — the simulation is compiled into the engine. Everything here is therefore black-box measurement.

Missions were generated programmatically with independent supply links laid out as parallel lanes, since the settings are per-warehouse and invisible at runtime; draining every consumer at one instant runs a whole matrix in a single sitting. A GameGUI hook sampled stock through net.dostring_in("server", …), and a mission-side tracer recorded changes at 0.5 s resolution. MissionScripting.lua was never modified, so the multiplayer integrity check stayed intact throughout.

Every run carried an unsupplied control warehouse. It never moved in any run, so all observed movement is resupply and nothing else.