Forward operating bases

The record the rest of the file hangs from

The constructables file holds 34 records from game build 25937608. One of them is the forward operating base: display name Forward Operating Base, id Id.Buildable.FOB, slug forward-operating-base. Every record in the file carries an fobRelated flag. In this ingest that flag is set on every row, including pieces that are only a floor or a roof of something else.

This note does not copy the FOB's cost, max health, repair rate, or size. Those fields are on the record. Size is stored as an [x, y, z] triple in meters. There is no separate footprint field. The FOB planner is the page that should show the stored numbers. If that page is still only a missing-data state, the numbers are still not guessed here.

The FOB's own tool list is empty. Do not read an empty tool list as "bare hands," and do not fill it with the hammer tags used by a wall. Empty means the files did not store a tool.

The FOB's placement tags are Fob, SafeZone, and WithinLadderBounds. It does not carry WithinFobBounds. The pieces that must sit inside an FOB's bounds are tagged that way. The FOB record itself is not tagged as sitting inside its own bounds.

One file, separate pieces

Multi-part structures are separate records, not children hidden inside a parent. Three rows share the display name Bunker. Their ids are Id.Buildable.Bunker, Id.Buildable.Bunker.Floor, and Id.Buildable.Bunker.Roof. An air-raid shelter, its floor, and its ceiling are three rows. The recon tower and its unnamed pieces are separate rows. You cannot price "a bunker" by reading one of those rows and assuming the others share its cost or its tags. Open each record.

Two of those rows share a display name. Both are called Air Raid Shelter Floor. Their ids are Id.Buildable.AirRaidShelter.Ceiling and Id.Buildable.AirRaidShelter.Floor. The id is how you tell them apart. The parent shelter record has a different display name, Indirect Fire Shelter, and the id Id.Buildable.AirRaidShelter. Same family of ids, three different rows. Do not merge them because the English names look redundant.

Protection and obstacles

Four records carry the tag NotInsideEnemyFobBounds, and they do not carry WithinFobBounds:

• –Barbed Wire
• –Recon Tent
• –Sandbag Wall
• –Hedgehog

Their other tags are SafeZone and WithinLadderBounds. The file does not attach a distance in meters to any of those words. A tag is the whole rule the record gives us. This note will not translate NotInsideEnemyFobBounds into a radius, a faction check you cannot see in the file, or a suggestion about where to drop wire on a hill.

Where those four records list tools, the tools are hammer tags: LargeHammer, MediumHammer, and SmallHammer, in combinations that differ by row. The weapon chapter does not apply here. A hammer tag is not a weapon archetype, and a sandbag's health is not a figure this paragraph is allowed to quote. Use the FOB planner for the stored cost, health, and size of a named piece.

Walls, shelters, and towers

The records that do carry WithinFobBounds are the pieces the file ties to an existing FOB. Naming them is safe. Quoting their stats here is not.

Walls and blocks in that group include Bremer Wall, Hesco Block (Small), Hesco Wall, and Hesco Block (Large). Sandbag Wall is not among them. Its tags put it with the four obstacles above. Doors and gates are their own records, and a door's top segment and a gate's ramp are further records with their own ids. Both door records are named Door. Both gate records are named Gate. The id is what separates them.

Shelters and towers include the three Bunker rows, Indirect Fire Shelter, the two air-raid floor records already distinguished by id, and Recon Tower. Recon Tower's id is Id.Buildable.CrowsNest. MG Nest is a separate record, Id.Buildable.MGNest, with an empty tool list.

Some of these rows omit SafeZone even though they sit inside FOB bounds. Id.Buildable.Bunker.Floor, Id.Buildable.Bunker.Roof, and the air-raid floor records are among them. Door, the door's top segment, Gate, and the gate's ramp omit it as well. Do not paint the whole structure with the parent's tags. Read the row you are placing.

Stations and emplaced pieces

A second cluster is still inside FOB bounds, and several of them add the tag LimitedByFOBCondition:

• –Builder's Radio
• –Refuel Station
• –Repair Station

The file does not define that condition in prose, and it does not store a radius for it. The tag is the data. Builder's Radio lists the three hammer sizes. The refuel station and the repair station list LargeHammer only. That difference is in the tool arrays. It is not a recommendation.

Other rows in the bounds, with empty tool lists, include Loudspeaker, L81 Mortar, Talon 9K-SAM, Vanguard CIWS, and Stingray. They are constructable records with the same shape as a wall: cost, max health, size, tools, placement rules. An empty tool list stays empty. This note does not describe how a mortar fires, and it does not borrow a damage figure from the weapon chapter. Emplaced pieces are not rows in the weapon index. If a projectile id happens to resemble a weapon caliber, that resemblance is not a license to merge the two files in a paragraph.

Placement tags, as stored

These are the tags that show up on the records discussed above. Each one is a string on a row. None of them is accompanied by a meter value in the dataset.

• –Fob is on the FOB record.
• –WithinFobBounds is on pieces the file ties to an FOB's bounds. It is not on the FOB record, and it is not on the four obstacle records listed earlier.
• –WithinLadderBounds is on the records in this file, including the FOB.
• –SafeZone is on the FOB and on many pieces. It is not on every part of a multi-part structure.
• –NotInsideEnemyFobBounds is on Barbed Wire, Recon Tent, Sandbag Wall, and Hedgehog.
• –LimitedByFOBCondition is on Builder's Radio, Refuel Station, and Repair Station.

If you need a distance, the file does not have one to give you. Do not measure a screenshot and write the result back into this manual.

What the planner is not allowed to invent

Two numbers a base planner wants are absent from the dataset: the FOB placement radius, and the build-grid snap size. They are not hiding under another field name. The site's only knobs for them live in the planner config, and while a knob is null the planner stays in the missing-data state for that knob. It does not draw a ghost radius, and it does not draw a snap grid, to cover the gap.

This article does not set either knob. It does not propose a radius that "feels" like the game. The FOB planner is the page that reads the config. If both values are still null when you open it, that is the honest state of the manual, not a broken table.

The same restraint applies to repair. Records may store a repair speed multiplier. Some records leave it null. A null repair rate is not "as fast as the FOB," and it is not zero. The planner, or the constructables table when that chapter is open, can show the stored value. This note will not.

Names the files leave blank

Five records have no display name. Three are pieces of the recon tower: Id.Buildable.CrowsNest.BaseFloor, Id.Buildable.CrowsNest.FirstFloor, and Id.Buildable.CrowsNest.Roof. The other two are Id.Buildable.SV_Shelter and Id.Buildable.WoodBase. Their ids are the labels. This manual does not coin "lower platform" or "wooden pad" for them. Icon paths are null on a further set of records, and the git repository would not have contained the images anyway. A missing icon is not drawn as a box.

Where the numbers go

Use this chapter as the map of the file, then leave it.

• –Stored cost, health, size, tools, and tags for a piece: the FOB planner.
• –Why a blank cell is not a zero, and why this site will not estimate one: reading this field manual.
• –Weapons and the attachments that hang on them, which are a different file and a different page: weapons and attachments, the weapon index, and the attachment index.

A base is not a loadout. The FOB record does not have a caliber, and the M4 page does not have a placement tag. Keep the links apart, and keep the unstored radius unstored.