UNOFFICIAL GUIDE · Reviewed August 30, 2026 · VERSION 1.0 (1622) · BUILD 24750322 · PATCH #5
UNOFFICIAL GUIDE
An IRON NEST bearing from Spotter information starts at the origin named by the report. It is an observation constraint, not automatically the bearing your turret should fire. Identify the origin and report type, locate the target, then rebuild the firing line from the current Iron Nest.
Start every bearing at the point named in the report. A bearing gives a direction from that origin; a distance gives a range constraint. Combine enough independent information to locate the target, then measure a fresh bearing and range from the current Iron Nest before calculating the shot.
In build 24750322, the three same-name FO cards share one random bearing-or-distance flow. Position Report has another. Neither flow discloses exact probabilities.
| Field | Value |
|---|---|
| Build baseline | Version 1.0 (1622) · build 24750322 · Patch #5 · IN-GAME TEXT · build metadata |
| Task Spotter | A bearing from the named Spotter origin; task text describes Spotter bearings as within or up to 0.5° · IN-GAME TEXT · task wording; accuracy is not extended to purchasable FO cards |
| Forward Observer cards | Three same-name cards, costing 6 / 1 / 1 requisition; all are unlimited-use in the extracted definitions · IN-GAME TEXT · punchcard definitions |
| Forward Observer output | One shared random report flow returning a nearest-enemy bearing or distance · IN-GAME TEXT · direct graph references; probability not disclosed |
| Scout Plane cards | Two same-name cards: 60 requisition with unlimited use, and 15 requisition with one use · IN-GAME TEXT · punchcard definitions |
| Scout Plane structure | Both cards share a Coordinate + Bearing control / graph structure and a successful photo-strip report · IN-GAME TEXT · graph-level evidence, not a complete UI guide |
| Position Report | 3 requisition, unlimited use; random point-to-turret bearing or distance · IN-GAME TEXT · direct graph reference; probability not disclosed |
| Turret firing input | A fresh shot-specific bearing and range from the current Iron Nest to the located target · OFFICIAL + OBSERVED · workflow handoff, not a fixed solution |
The safest question is not “Which number did I get?” but “From what point does this number describe the unknown?” Keep the origin beside every copied value.
A bearing is a ray from a named point; a distance is a range constraint around one. Coordinate + Bearing describes the Scout Plane action, not the gun's final azimuth. Keep multiple origins separate with the triangulation input guide.
Start with the source named by the report, preserve the information type, then hand the located point to the firing workflow.
Copy the report's source point beside the number: a named Spotter or reference point, a Scout Plane action context, or a Position Report point. Do not replace it with the turret.
Done when: every bearing or distance in your notes has an explicit origin.
Common mistake: saving the number but losing its origin.
Treat a bearing as a direction and a distance as a range constraint. Keep Coordinate + Bearing as one Scout Plane action context, not an assumed firing line. The built-in map tools reference covers the verified tactical-table limits.
Done when: each item is classified as direction, distance, or reconnaissance action input.
Common mistake: reading every number as a bearing.
One bearing or distance leaves many candidates. Add independent information, then follow the bearing-and-distance constraint methods. Full geometry, double intersections, and chained references belong there.
Done when: the target has a defensible map location.
Common mistake: choosing the most convenient intersection.
After locating the target, measure a new bearing and range from the current Iron Nest. Moving the turret invalidates its old firing line even if the target remains still.
Done when: the crew has shot-specific input from the current turret.
Common mistake: using observation bearing as turret azimuth.
Build 24750322 contains three distinct Forward Observer records with the same visible name and description. They cost 6, 1, and 1 requisition and are unlimited-use. Internal filenames are not player-facing mechanism labels.
The decisive evidence is the direct graph reference: all three cards bind to the same Spotter report graph. That graph has a random branch leading to either a nearest-enemy bearing message or a nearest-enemy distance message. It does not support a table in which one card is “the bearing card,” another is “the distance card,” and the third has a special target mode.
The branch establishes two outputs but no percentage or sequence. It also leaves eligible-target rules, priority, friendly filtering, and no-target behaviour unknown. “Nearest enemy” is supported report wording, not a complete selector specification.
For the full card list, prices, and usage limits, see all punchcards. For the terminal process, use the Requisition console guide. Those pages own the catalogue and console; this guide owns what the report means after it arrives.
The current build has two same-name Scout Plane cards: 60 requisition with unlimited use, and 15 with one use. They share a graph and controls object but have different runtime prefab references, so not every runtime detail is proven identical.
At graph level, the action carries Coordinate and Bearing strings. A successful branch says a photo strip has been delivered to the map, and an operational-AA failure branch also exists. This is enough to keep two ideas separate:
It does not establish player-facing labels, input order, start-grid meaning, direction convention, photo count or width, hidden-target behaviour, or current-build Counter-Battery interaction. Older developer comments about coverage and Star Shell behaviour are not current-build rules.
Once the reconnaissance result gives you a target constraint or visible target point, return to the origin-first workflow. Do not copy the plane's input bearing into the turret and skip the firing-line handoff.
Position Report is a separate unlimited-use card costing 3 requisition. Its visible description says a convoy provides positional intelligence about the Iron Nest. In build 24750322, its direct graph reference leads to a random branch with two report forms: a bearing from the named point toward the turret, or a distance from that point toward the turret.
Position Report is therefore not direction-only. It can provide either constraint, with no disclosed probability. Two reports can repeat a type or form weak geometry, so they do not guarantee an exact position.
Use the same discipline as with a target report: preserve the point named by the message, classify the value, then combine it with independent information. The unknown is the current Iron Nest rather than an enemy target, but the origin rule has not changed.
Current-build mission text describes task Spotter bearings as “within” or “up to” 0.5° and warns about near-parallel or chained measurements. Keep that boundary scoped to task Spotter reports.
It does not prove that purchasable FO bearings share that error function. Their internal Spotter identifier is not a unique key. A code path, controlled observation, or developer statement is still needed to connect the rule.
In practice, avoid treating a thin crossing of two lines as exact. Shallow intersection angles and reference-point chains are fragile even when each input is close. Ask for another independent constraint when the geometry cannot support a confident point.
Reconnaissance helps locate the unknown; the gun still needs a line from the current Iron Nest to that point.
Use the triangulation firing-line handoff to make that transition explicit. Then provide the current range—and any player-recorded bearing context—to the calculator field-dependency workflow. The calculator owns range-to-elevation work; it does not discover the target or derive the observation origin.
If the Iron Nest has moved, rebuild the line. An old target point may remain useful, but an old turret bearing and range describe the previous firing position. This guide does not supply reusable coordinates, charges, elevation, or a mission firing solution because those values depend on the run and the current gun position.
Check the information chain before deciding that a card is broken:
A dated developer reply suspected the reference point in one player's case. That suggests a checking order, not a universal diagnosis. If inputs still conflict, preserve the messages and seek another independent constraint.
Need to step back from this specialist page? Use the guide chooser to return to the broader firing workflow and select the page that owns your next problem.
24750322, Patch #5.This unofficial guide does not claim author playtesting. A patch, official explanation, or reproducible observation can change these boundaries.
Start at the origin named in the report, not the current Iron Nest unless the message says so. IN-GAME TEXT: build 24750322 mission wording supports this rule.
No. It is an observation line. Locate the target, then measure a shot-specific line from the current Iron Nest; see the firing-line section.
No. All three bind to the same random bearing-or-distance graph. No percentage or sequence is disclosed; see what the cards share.
The description and report flow say nearest enemy, but eligible targets, priority, friendly filtering, and no-target behaviour remain unknown. It is report wording, not a full selector specification.
That is unverified. Task text contains the 0.5° wording, but no audited code path or developer statement connects it to every purchasable card.
No. Coordinate + Bearing belongs to the aircraft action structure. After reconnaissance locates a target, the turret needs a fresh firing line; player-facing input geometry remains unverified.
Its bound graph can return a point-to-turret bearing or distance. Probability is undisclosed, and two reports do not guarantee a unique position.
Keep the named origin and request or use another independent constraint. Then move to the constraint-method section instead of inventing a fixed intersection rule.
Reviewed August 17–30, 2026. Evidence types and dates are stated beside each claim above.
Dated public developer replies support a case-specific troubleshooting order and historical Scout Plane context; neither is generalized beyond its stated version.
Version 1.0 (1622), build 24750322, Patch #5 supplies punchcard definitions, localization, direct graph references, typed random branches, and mission Spotter wording.
One timestamped player tutorial corroborates the broad report-to-map-to-turret workflow; its machine transcript is not treated as build proof.
Community questions and third-party guides identify common origin, accuracy, and card-difference confusion; they do not establish mechanics.
Spot an error or a post-patch change? This guide follows correctable public evidence — corrections update the page and its review date.