VER
1.0 — FULL RELEASE
ROADMAP
◆ SINGLE-SOURCE VERIFIED
LAST VERIFIED
2026-08-17
MULTIPLAYER
◇ CONFIRMED · NO DATE

FIELD DATA // REFERENCE HUB

IRON NEST Field Data

UNOFFICIAL REFERENCE · All tables read from build 24750322 — Version 1.0 (1622), Patch #5, August 15, 2026 · Extracted August 17, 2026

What Field Data means here

Field Data is the part of this site that answers "what is this value in this build" rather than "how do I do this". Every table in this section is read directly out of the game's own files, tied to a specific build, and dated.

The split is deliberate. How to fly a mission belongs with the campaign missions. What a shell costs, what a medal requires, and what a punchcard does are values — they change when the game changes, and they are only useful if you know which version they describe.

The build these tables come from

Everything in this section was read from game build 24750322. That build is Version 1.0 (1622), shipped as Patch #5 to the public branch on August 15, 2026, and it is the latest live build as of August 17, 2026. The values were extracted on August 17, 2026.

Why we print a build id at all. Nearly every reference for this game carries a "last updated" date and nothing else. A date tells you when somebody wrote a page. It does not tell you which version of the game they were looking at — and for this game that gap is not academic: published shell counts, medal counts and punchcard counts disagree with each other today, and most of those disagreements dissolve the moment you ask which build each number came from. A build id makes our numbers checkable, and it makes them falsifiable. That is the point.

Values from the demo build are kept separately and are never mixed into these tables.

How to read the labels

Every claim in this section carries one of five labels.

Evidence labels used on this page
Label What it means
BUILD DATA Read directly from the game build and cross-checked. The value is reliable; its unit or meaning is not automatically known.
IN-GAME TEXT The game's own English wording, quoted. Authoritative for how the game describes something. Not a numeric promise.
SITE-GROUPED A grouping, ordering or piece of advice we wrote. It is not a rule that exists in the game.
COMMUNITY A claim from players or a third-party site that the developers have not confirmed.
UNVERIFIED We have no reviewable evidence yet, and we say so rather than filling the gap.

Two limits apply everywhere in this section:

We do not convert engine values into real units. The numbers inside the build are the game engine's own quantities. Unless we have a documented way to translate one — and mostly we do not — we print it as it is. You will not find a shell's speed given in metres per second or a blast radius given in metres on these pages, because we cannot yet show our work for either.

We do not base these pages on our own playtesting. Our boundary is publicly traceable material plus fields read from the build. Anything that only in-game testing could settle is marked UNVERIFIED, with a note on what would settle it.

Three things that make this data easy to get wrong

These are the traps we fell into, written down so you can check whether a source has fallen into them too.

  1. The internal identifiers are not unique

    Two medal entries collide outright on theirs, three punchcards in the same family share one, and a couple of the game's strings carry trailing spaces that are part of the data rather than an artefact of reading it. Anything keyed on those identifiers silently loses rows — and it loses them quietly, which is worse than failing. We key on asset names, which are unique.

  2. The numbers in the internal asset names are not the values

    Several assets still carry ranges from development that no longer match what the entry actually scores. A medal whose internal name says one range can be scoring an entirely different set of numbers. We publish the field values and ignore the names.

  3. One concept can have several legitimate counts

    "How many medals" has three defensible answers depending on whether you count names, threshold sets, or assets. "How many punchcards" depends on whether you count cards you cannot buy. Neither answer is wrong; a page that does not say which one it is using is. Each page in this section states its basis in plain words.

What's in Field Data right now

  1. Shell types — every shell in the current build with the game's own description of it, the build values, and what its punchcard costs; a guide to which shells suit which targets, grouped from the in-game wording; and what changed between the demo and 1.0, including how to spot a shell list that predates the release.

  2. Medals — every medal, organised by name so you can look one up directly, with its full bronze, silver and gold conditions rather than just the gold number; a mission-by-mission index; and a straight answer on how medals differ from Steam achievements.

  3. Requisition console — every punchcard you can buy, with the game's description and its cost; how requisition credits are earned and lost; when the console becomes available; and what to do when you run out of shells.

How these tables are produced

We read the definition assets out of the game's installed data files and write them out field by field as structured data, which the pages are then generated from. The extracted files live in this site's repository, so the numbers on these pages can be checked against the same data we used.

What that method proves: that these entries and these field values exist in that build.

What it does not prove: what a field's unit means, how the value behaves at runtime, whether some other system overrides it, or whether the next patch will change it. Reading a number out of a file is the beginning of a claim, not the end of one.

One failure worth keeping on the page. On August 17, 2026 we found that our extraction had been reading only one of the game's asset files and had been missing entries in another — which meant our medal and punchcard counts were both too low, and we had wrongly assumed that a third-party site listing entries we lacked was padding its data. It was not; we were incomplete. After the fix, the gap between our data and theirs closed to nothing. We are leaving this here because a reference section is only worth as much as its willingness to say when it was wrong.

Coverage and known gaps

What this section does not cover yet, and what each one is waiting on.

Coverage and known gaps
Gap What it is waiting on
Map and icon reference The extraction contains no map or icon data, and the rights position on screenshots is unresolved.
Real units for ballistics Muzzle speed, dispersion and the powder-charge curves exist as engine-internal quantities. Until they are calibrated against in-game measurements, we will not publish any firing-solution value with a unit attached.
Which medals appear in which mission The build's mission graphs do not carry medal payloads. The attribution we have comes from a single third-party source and is known to be incomplete.
Unlock conditions for shells and punchcards We can show that an unlock system exists. We cannot show what unlocks what.
Requisition earning rates The game's own text gives the values for destroying hostile and friendly targets. The rules behind mission objective rewards are not established.

These are gaps, not a roadmap. Each one is waiting on specific evidence, and we would rather leave the space empty than fill it with a plausible guess.

When this data goes stale

When the game's build id changes, every value in this section is stale by definition. Not "possibly out of date" — stale, because the thing it described no longer exists in that form.

When that happens we re-extract from the new build and update the version anchor rather than patching individual values, and the change is recorded in each page's change log. Between builds, the version strip at the top of every page in this section is the same one you see above.

What we are promising you: every number in Field Data can be traced to a build id and an extraction date. If you find one that cannot, that is a defect on our side and we want to know.

Corrections. Tell us the build id and what you are seeing. Corrections that arrive with a build id are the ones we can act on immediately.

Sources

Version anchor and extraction baseline: The build-id ↔ version map fixes build 24750322 as Version 1.0 (1622), Patch #5; the extraction baseline defines what the extracted fields can and cannot prove.

Method records and shared data: Method snapshots, the publish-blocker handoff and the public data directories back the hub's method, gaps and freshness sections.