Field reference › Check reference

Check reference

What each family of Check finding means, what actually triggers it, how to fix it, and — the distinction that matters most — whether it is one an export itself refuses, or one Check flags on its own, stricter bar.

The export gate is narrower than Check. Check sweeps the whole database and sorts every finding into one of two bars: blocking (4 of the 19 families below) and advisory — legal bytes the game loads fine, listed because it is probably not what you meant. But the export preflight itself tests a narrower, more exact condition than even the blocking half of Check does: both shipped Harpoon databases trip Check's blocking "Points at the wrong annex" family, and the game loads and plays both of them anyway. Where the two disagree, the section below says so.

One whole-database fault stops an export before any of this even runs, and is not a Check finding at all: a database file structure version the editor has no codec set for. Check only sweeps records that already loaded; if the file itself cannot be written back, the Export blocked dialog says so directly, with nothing to fix per record.

A database whose resources were stored LZH-compressed is not stopped. The editor reads that compression and does not produce it, so it writes those resources back uncompressed: the file that comes out is materially larger than the one that went in.

Neither is a database whose loadouts and multi-mounts carry four weapon slots rather than eight. A Harpoon Gold-era build wrote them that way in records of exactly the same size, so nothing in the file declares it — not even the structure version, since a 2017 database declares the same one and carries eight. The editor works it out from the data, keeps the current layout unless the evidence is decisive, and says which it used on the last line of the Overview.

Points at the wrong annex

blocks export

Triggers when a field that references another record — a mount's WepId, a platform's MntId/SensId slot, a plane's LoadId — holds an id whose top four bits name a different annex than the field is allowed to point at. The same family also covers a weapon's Dp/SubDp/ SurfDp above 30,000: above that threshold the number is not a damage figure at all, it is an id reference into I1 (nuclear warheads) or F1 (torpedo payload), and this family flags one that names a record outside I1/F1, or — for this field kind only — a value inside I1/F1's own window that names no record at all, because a damage field has no "none" sentinel to fall back on the way an ordinary reference slot does.

Fix. Open the record the finding names, and either clear the slot (set it to 65535) or repoint it at a real record of the annex the field wants — the field's own row on its annex page here names which annexes are acceptable. For a run of them, select the group on the Check screen and use Replace references….

This is the one family where the export gate is narrower than what this page reports as blocking. Both shipped Harpoon databases trip this family and the game loads and plays both, so the export preflight tolerates two shapes Check still reports here: an ordinary reference field holding plain 0 (measured: two zeroed magazine-weapon lines and a zeroed sensor slot in an extended database), and a Dp/SubDp/SurfDp id that is dangling but still inside I1/F1 (measured: hcgold's own "M51 SLBM" missile). Anything else in this family — a nonzero id whose annex nibble names the wrong annex outright — stops the export on both bars alike.

Points at a record that isn't there

advisory

Triggers when a reference slot holds an id in the annex the slot is allowed to name, and no record holds that id. The format allows it (65535 is the only value that means "nothing"), and the game skips some of these and stops on others. The sharper trouble is outside the database: a scenario or saved game that wanted that record cannot get it back. Damage-field references are reported under Points at the wrong annex, not here.

Fix. Open the record the finding names and clear the slot, or point it at another record. Or keep the reference and give a record the id it wants: Change id… on that record's page offers every id its annex is missing first.

Advisory: nothing refuses an export for it.

Will not fit in its field

blocks export

Triggers when a record holds a value its own field cannot store on disk: a whole number outside the signed or unsigned range its C type allows (a u8 over 255, an i8 under −128, and so on for every integer kind the codecs use), an array with the wrong number of elements, or a name/bytes field whose stored value is not exactly the declared number of bytes. These pack into the working project file without complaint — nothing stops a JSON edit or an imported record from carrying one — and only fail once the writer tries to pack the record into the fixed-width struct a .res record actually is.

Fix. Open the record the finding names and correct the field it points at. The record screen runs the identical test at save time, so a database edited entirely inside the editor from here on will not produce new findings in this family — they mostly turn up on data imported or hand-edited outside it.

No narrowing here: RANGE is identical on both bars. It is the first thing an export refuses, on the first record it finds one on.

Source level the game cannot hold

blocks export

Triggers when an A1, A2 or F1 record's BaseSourceLevel is above 127, or negative (the same stored byte read the other way). The game holds a source level in a signed char, so 127 is the most it can hold.

Fix. Open the record and pick a level from 0 to 127 on its ladder. A ship's or sub's active sonar at full power is 92.

Blocking for battleset 22 and higher: the export refuses until it is fixed. Below battleset 22 the game assigns its own source level, so it is reported as a rating warning instead and does not stop the export. See Ratings.

Ships and subs with no hull names

blocks export

Triggers when an A1 (ships and land units) or A2 (subs) record has no hull-name list, or its list is empty. The game names each ship or sub it places from its class's hull names.

Fix. Open the record, go to its hull names and add at least one.

Blocking: the export refuses until it is fixed.

Magazine blocks out of order

advisory

Triggers when a ship or base's magazine block breaks the shared pool's writer contract: MagCount is 0 but MagStart is not the 0 sentinel it should be, MagStart is not a whole multiple of the 5-byte magazine record, the block runs past the end of the pool, or its rows partly overlap a block another platform already owns. Two platforms on exactly the same block (the same start and count) are not a fault: they share it, and each carries the full stock.

Fix. Open the platform's record, change its magazine rows and apply, which re-saves the block. The editor's own magazine edits always keep the pool valid — it is a splice, not a free-form edit — so this only appears after a hand-edited MagStart/MagCount or a spliced-in imported block.

Advisory: nothing in the writer refuses this shape at export. It is listed because the game trusts a platform's magazine rows are exactly where MagStart says they are, and a broken block is a corrupted game state waiting to happen the moment that platform is resupplied.

Magazine pool nearly full

advisory

Triggers once the shared magazine pool has used at least 90% of its 13,107-row ceiling — 65,535 bytes, because MagStart is a 16-bit byte offset and cannot address a block starting past byte 65,535. Reported once for the whole database, not once per platform.

Fix. There is no record to open — this is a warning before the wall, not a broken one. Share identical magazines on the magazine pool's page frees the rows that platforms with the same stock hold twice, usually a large share of the pool. Past that, free rows by trimming magazine stocks that are not doing anything, or accept the risk and keep going; watch it as more magazines are added.

Advisory: the writer only refuses once the pool actually overflows past its ceiling. This fires while there is still room, as the warning before that point.

Annex nearly full

advisory

Two cases. An annex is reported once its records use more than 90% of the 4,096 disk ids its window holds (Z2 has 4,095, because 65535 means "none"), with how many are left, for example "3,912 of 4,096 ids used; 184 left". "Used" counts records, not the highest id: Add and Clone take the lowest free id, so the count is what says how much room remains. This is the same figure the Overview gauge shows. An aircraft is reported when every one of its loadout slots is taken ("32 of 32 loadouts"), which is all the file has room for.

Fix. For an annex, delete records nothing uses (the Unused tool lists them) or merge duplicates; at 100% nothing more can be added. For an aircraft, remove a loadout before adding another.

Advisory: nothing refuses an export for either. This is the warning before the wall.

Ids that collide

advisory

Triggers two ways: two records anywhere in the database share the same id (the later one in scan order is reported, naming the first it collides with), or a record's own DiskId falls outside the 4096-id window its own annex owns.

Fix. Renumber the reported record to an id inside its own annex's window that nothing else already uses.

Advisory: nothing at export enforces uniqueness or windowing. A collision just means every reference to that id silently resolves to whichever record a lookup finds first — the other record becomes unreachable by id without a single byte being wrong.

Hull-name classes nothing claims

advisory

Triggers when a hull-name class — the pool of names a ship or sub class draws its display name from — is keyed to an id that no A1 ship or A2 sub record actually carries. Usually the leftovers of a deleted class, kept in the pool but claimed by nothing.

Fix. Open the class in the Ship names list (Go → Lists) and either delete the orphaned class or point an existing ship or sub at its id.

Advisory: the names simply never get drawn in game. Export does not look at hull-name classes at all.

Description that is not there

advisory

Triggers when a ship, sub, or aircraft's TextIndex names a position past the end of the platform description pool. There is no "no text" sentinel value to fall back on — every legitimate record in the shipped databases holds an in-range index — so a value past the end is a genuine defect, not a deliberate "none".

Fix. Open the record and pick a real text entry from the pool.

Advisory: the game shows nothing for that record's platform description rather than refusing to load it, and export carries the value through unchanged either way.

Nothing where a range is needed

advisory

Triggers when every field that defines a weapon's or sensor's reach is zero at once: a gun's or missile's surface and air range together, a standoff weapon's or torpedo's max range, a radar's max range, a sonar's active and passive range together — or, for a B1 aircraft, its Runway is "none", meaning no base is too small for it to operate from. Ordnance (bombs, drop tanks) is deliberately excluded: a third of the shipped ordnance annex legitimately has zero range, so the lint would fire on ordinary content there rather than on the unfinished records it is meant to catch.

Fix. Fill in the missing range figures if the record is meant to reach anything, or leave it if it is genuinely a special case.

Advisory: a weapon that reaches nothing packs and exports fine. This is a "probably unfinished" flag, not a rule anything enforces.

Records with no name

advisory

Triggers when a record's own name field is empty — the twelve annexes that carry one. Nukes, loadouts, multi-mounts and magazine lines have no name field at all and are never flagged.

Fix. Open the record and name it, or delete it — and where a sweep turns up a run of them, open the family as a grid and use Delete on its toolbar rather than one record at a time (the Tools guide covers the verb and what it does about anything still referencing the records). A fresh record made in the editor cannot reach this state any more: saving a new record refuses a blank name outright. Saving over an existing name with an empty one is refused outright too, so what a sweep turns up here is almost always older than that, a record that arrived nameless from an import or an older database, rather than one born that way here.

Advisory: the game does not care, and neither does the writer — an empty name packs and exports like any other. It is listed because a record nothing can refer to by name is almost never what was meant.

Multi-mounts the mount editor would not make

advisory

Triggers when a Z2 multi-mount record is shaped in a way the mount editor's own save path never produces: an empty one holding no weapons at all (the editor stores an empty load as 65535 directly on the mount, never as an empty multi-mount), a single-weapon one a carrying mount could have stated inline instead, or a duplicate of another multi-mount's exact weapon-and-quantity composition (the editor reuses an existing one rather than creating a second).

Fix. Usually nothing — these are legal, and the next time that mount's weapon load is opened and saved in the editor, the shape normalises on its own. Hand-edit the Z2 record directly only if the unusual shape is deliberate and meant to persist.

Advisory: the bytes are entirely legal either way. This only flags a shape a save from the mount editor itself would never leave behind.

Battery totals in a per-mount field

advisory

Triggers on a mount record fitted in more than one copy whose tube count is exactly its rounds figure times its mount count. A mount record is one mount and the number of copies of it carried, so every other number on it describes a single copy — the rounds field says so in its own name, NumRoundsMnt. A battery entered as one record is where that gets lost: the launcher's own tubes are counted, multiplied by the number of launchers, and the product written into the field that wanted the first number. Because a canister or rail launcher carries one round per tube, that mistake lands on disk as exactly this arithmetic — and the record then reads as a launcher with several times more tubes than rounds to load into them.

Fix. Divide the tube count by the number of mounts. Or leave it, if the launcher really does fire a salvo larger than its own magazine — a rocket launcher or an ASW mortar legitimately has many tubes and one reload, and those are only reported here when the salvo also happens to match the mount count exactly.

Advisory: the bytes are legal and the export writes them unchanged. Only records with more than one mount are examined, and only the tube field — a record where the rounds figure is also the battery total is arithmetically identical to a perfectly correct pair of six-tube launchers, so it is left alone rather than guessed at.

Values no vocabulary names

advisory

Triggers when a scalar field wired to a coded vocabulary (its record page shows a picker for it) holds a value that vocabulary does not name at all — not merely a value outside what that field's own picker offers. Several fields only offer a stretch of a bigger axis (an aircraft's altitude band, a submarine's depth band, a ship's mast height are three stretches of one shared table), and a value outside a field's own stretch can still be a real row of the wider table it was cut from — that is named, and is not a finding here. This only fires when the value is unknown to the table itself.

Fix. Open the record and pick a value from the field's own list, or leave it if the value is deliberate — the game loads the record either way and reads the stored number as whatever it means to the engine.

Advisory: nothing about export or the game's loader cares what a picker can name. This is listed because a value nothing names is usually a typo, not a deliberate choice — Propulsion 53 (the ASCII character "5") on a real shipped ship looks exactly like one.

Rating out of range

advisory

Triggers when a record's RCS is above the highest its annex uses (237 for ships and subs, 200 for mobile land units and bases, 164 for aircraft, missiles and standoff ASW), or its BaseSourceLevel is above 92, a ship's or sub's active sonar at full power. Each maximum is where detect range reaches the radar's own range.

Fix. Open the record and pick a value from the ladder, or leave it if it is deliberate.

Advisory: the bytes are legal and the game loads them. A source level above 127 is a separate, blocking family. Below battleset 22 the game assigns RCS and source level itself, so this family is not reported there. The full table is in Ratings.

Country is a side-name slot

advisory

Triggers when a record's Country is one of the first 8 slots of the country table (0 to 7), in any annex that has the field. Those slots are meant for the side names (a real database has 0 "Blue", 1 "Red" and the rest empty), and using one as a record's country is highly discouraged.

Fix. Open the record and pick a real country, or leave it if it is deliberate.

Advisory: the bytes are legal and the game loads them.

Text outside plain ASCII

advisory

Triggers on any text the game reads that is not printable ASCII (0x20 to 0x7E): a record's name, a platform description, a hull-name class, a string-table entry, or the database name. The game's font only approximates the rest: an accented letter shows without its accent, and the curly quotes a word processor makes (bytes 0x91 and 0x92) show as an extremely leaning apostrophe. A finding names the item, each offending character with its count, and the first occurrence in context with the plain form it would become.

Fix. Select the findings and press Replace with plain text on the Check toolbar. Curly quotes, dashes, accented letters and similar become their plain equivalents; a character with no plain form becomes ^, a control character a space (a line break in an platform description is kept), and the old end-of-file byte 0x1A is removed. The whole batch is one entry in History and one Undo. New text typed into the editor is converted the same way when it is saved.

Advisory: the game loads the text, it just shows it wrongly.