Walls, gates and wall towers

A wall BuildingType turns into a cell overlay when it reaches the map, and gates and wall towers stitch into the run that overlay forms.

A wall is built as a structure and stored as terrain. The BuildingType exists so that a wall can be priced, queued and placed; the moment it reaches the map it is replaced by the overlay its ToOverlay names, written into the cell, and everything afterwards — connection artwork, damage, ownership, blocking — belongs to the cell rather than to any object. Gates and wall towers are the exception: they stay real structures and connect to the overlay run around them.

A wall type and the art entry that completes it

This section introduces the two type definitions the rest of the page turns on. Anyone already writing wall sections can skip to From structure to overlay.

A wall is declared twice. One section declares the BuildingType, which is what a house prices, queues and places, and another declares the OverlayType a wall cell ends up holding; each is registered in its own list, [BuildingTypes] or [OverlayTypes]. What ties the two together is ToOverlay=, naming the overlay the building turns into, and that assignment is read from the type’s art entry rather than from its rules section.

The stock walls give both types the same ID, so one rules section and one art section serve the pair and each key is read by whichever of the two declares it. GAWALL, the GDI concrete wall, is written like this — abridged to the keys this page turns on, so the surrounding cost, prerequisite and artwork assignments are omitted:

[GAWALL] ; read once as a BuildingType and once as an OverlayType of the same ID
Wall=yes     ; building: turn into the overlay on placement. Overlay: this cell is a wall
Strength=150 ; building: never used, since it is deleted on placement. Overlay: the per-hit damage threshold
High=yes     ; overlay: stop low-flying fire crossing the cell
Sight=1      ; building: how far placement reveals the map

[GAWALL]
ToOverlay=GAWALL ; the OverlayType above, named here rather than in the rules
DamageLevels=3   ; overlay: the number of damage stages a segment passes through

A damage stage is how many hits a wall cell has taken, counted up from zero; the cell stores the figure, the artwork is drawn from it, and reaching DamageLevels removes the segment. Gates and wall towers are BuildingTypes too, but they carry neither Wall=yes nor a ToOverlay=, which is why they stay on the map as structures.

From structure to overlay

A Wall=yes BuildingType never becomes a runtime instance. When it is placed it tests the target cell once more, lays that overlay on the cell, stamps the cell with the placing house, reveals the map around it out to the type’s Sight, and deletes itself. It is never listed among the house’s buildings, has no strength of its own, and cannot be selected, repaired or captured.

The overlay then runs its own placement test, and that test is a different one from what the structure passed: it rejects any cell that already carries an overlay of any kind and requires the land type to be passable to tracked movement, rather than reading the land type’s Buildable. A cell that refuses the overlay refuses the placement outright — the structure stays in the production slot and no cell is changed.

Placement legality for the structure itself is the ordinary building test with one addition for walls. A cell already holding a brick, sandbag or Nod wall accepts a wall building whose ToOverlay matches that overlay, provided the cell is owned by the placing house and the segment has taken at least one damage stage. The damaged segment is then removed before the fresh one is laid, through the same routine as selling. That routine refuses a computer house’s own cells, so the repair works only for a player: for a computer house the old overlay stays put, and the new segment’s test then rejects the occupied cell. Rebuilding a damaged segment costs the full price of the wall and returns nothing for what it replaced.

The proximity rule that lets a wall run start away from a structure is covered by base placement and adjacency: for a wall, a scanned cell owned by the same house satisfies the check on its own, with no building standing there. WallBuildSpeedCoefficient and the sidebar side of placement are covered by production.

Filling the gap to the next wall

Placing a wall by hand also lays the segments between it and the nearest wall of the same kind already standing. The fill is triggered by the placed type having a ToOverlay that is itself a wall overlay, not by Wall=yes, so a type that lays a wall overlay without carrying the flag still triggers the fill — though what it lays in the gap cells are ordinary structures rather than wall segments.

Reach and direction

The search runs north, east, south and west only; diagonals are never filled. Each direction walks outward one cell at a time for at most GuardRange cells. That value is written in cells, and the fill truncates it to a whole number, so GuardRange=5 reaches five cells and GuardRange=5.9 reaches the same five. Three stock BuildingType IDs have the value pinned at 5 cells after their sections are read and cannot be retuned this way; GuardRange names them.

What stops the run

Walking a direction ends on the first of three outcomes:

A matching anchor. The cell holds the same overlay type and is owned by the same house. Both tests must pass — a segment of a different wall type, or the same type owned by someone else, is not an anchor.
A cell that cannot be built on. The walk stops there and that direction contributes nothing, so a gap the engine could not legally close is never partially filled.
The reach running out before either happened.

An anchor found in the cell immediately next to the placement produces no fill, since there is no gap between them.

The filled segments

Each intervening cell receives a freshly created building of the placed type, which is then placed exactly as the first one was: it converts to an overlay, stamps the cell with the same house, and reveals sight around itself. Nothing charges the house for them, so a single paid wall can lay up to four runs of free segments in one placement.

The placement cursor previews the same runs before the click, using the same reach, the same four directions and the same anchor test, and is drawn only while the whole cursor sits on legal ground.

Who owns a wall

A wall’s owner is a house index stored on the cell. The overlay itself carries no owner, so two adjacent segments of the same type can belong to different houses.

Placement stamps the owner directly. Walls that come from a map’s overlay data are placed unowned, and the map pass that follows loading assigns each of them to the house whose nearest active, placed building has WallOwner=yes; a map with no such building anywhere leaves its walls unowned. Ownership decides who may sell a segment, whether the automatic gap fill treats it as an anchor, and whether an attacker sees it as a hostile target.

Connection frames

Each wall cell stores a damage stage and a connection frame together in one byte, the stage in the high half and the frame in the low half. The connection frame is four bits, one per cardinal direction, rebuilt whenever a wall in the cell or in one of its four neighbors appears or disappears. A rebuild always touches five cells — the four neighbors and the cell itself — and registers all five for redraw whether or not they hold walls.

A neighboring cell counts as a connection when it holds the same overlay type. Five structures widen that. The table gives each one the wall it continues and the directions the count is taken from; the third column is the one to read carefully, since four of the five continue a run along a single axis.

The neighbor holds, alive	Continues	From
The `WallTower` type	Brick or sandbag wall	Any of the four directions
The `GDIGateOne` type	Brick or sandbag wall	East or west only
The `GDIGateTwo` type	Brick or sandbag wall	North or south only
The `NodGateOne` type	Nod wall	East or west only
The `NodGateTwo` type	Nod wall	North or south only

Nothing here reads a flag on the type. A gate stitches into a wall run only because [General] names it in one of those four keys, and the axis it stitches along is fixed by which key names it. A Gate=yes type that no key names opens and closes normally and leaves the wall run broken at its ends. The wall tower is the only type that connects from every side, and it connects to brick and sandbag walls only, never to Nod wall.

Damage stages with no artwork

Immediately after rebuilding a frame, the engine deletes wall overlays that have reached a damage stage the shipped artwork does not cover. The test is on the stored byte as a whole rather than on the stage alone, and that is what confines it to isolated segments: the byte is the stage times sixteen plus the connection frame, so comparing it against 16, 32 or 48 can only match while the frame half is 0. A damaged segment with even one connection is passed over.

The rule is keyed to fixed positions in [OverlayTypes] rather than to anything the overlay’s own section says. The table lists the six positions it covers and the stages at which each one collapses; the conclusion to draw is that an overlay registered at any other position is never deleted this way, whatever its own DamageLevels allows.

`[OverlayTypes]` position	Stock ID	Isolated segment is deleted at damage stage
0	`GASAND`	1 or 2
1	`CYCL`	2
2	`GAWALL`	2 or 3
3	`BARB`	1
22	`FENC`	1 or 2
26	`NAWALL`	2 or 3

The deletion clears the cell’s overlay, stored byte and owner, and detaches everything that referred to the cell. It runs without any damage being applied, so an isolated segment can vanish the moment a neighbor is removed and its connection frame drops to zero. Reordering [OverlayTypes] moves these rules onto whichever overlays land on those positions.

Taking damage

Whether a hit lands

Strength on a wall overlay is a per-hit threshold, not a pool of hit points. Damage at or above the figure always advances the wall by one stage. Damage below it advances the wall only when a random integer from zero through the figure comes out below the damage, and a hit that fails that roll accumulates nothing — the next hit starts from the same threshold. A damage value of -1 is the instruction to advance the stage unconditionally, and every hit lands unconditionally during scenario initialization.

Five sources reduce a wall. The table sets each one against the damage it hands the threshold test above; what to take from it is that only the first three carry a figure a rules file can move, because the last two are fixed at 200 in the engine.

Source	Damage applied
An explosion whose warhead is `Wall=yes`, or `Wood=yes` against an overlay with wood armor	The explosion’s own damage
A wave weapon sweeping the cell	The weapon’s `AmbientDamage`
A crusher vehicle driving over a `Crushable=yes` overlay	`-1`, which destroys the segment outright
The cascade described below, against each neighbor at stage zero	`200`
A wall tower taken off the map, against each undamaged wall in the four cardinal cells	`200`

Stepping through the stages

A landed hit advances the stage by one and then checks two things.

When the new stage is one below DamageLevels and DamageLevels is above 2, each of the four cardinal neighbors holding the same overlay type at stage zero is hit for 200 damage. Any wall whose Strength is 200 or less therefore advances a full stage from that hit, and if that pushes the neighbor to the same stage the cascade continues along the run. A wall with DamageLevels=1 or DamageLevels=2 never cascades at all.

The segment is then removed under any of:

the damage was -1;
the new stage has reached DamageLevels;
All of: the new stage is one below DamageLevels, and the connection frame is zero.

The last of the three is what makes an isolated segment die one stage before a connected one. With DamageLevels=1, the default, the first landed hit takes the stage to 1 and removes the segment immediately.

Removal clears the cell’s overlay, stored byte and owner, recalculates the cell, rebuilds the movement zones and radar background, rebuilds the connection frames of the four cardinal neighbors, and detaches everything that referred to the cell. An explosion that removed a wall additionally clears the cell from every object that was targeting it.

Crushing, clearing and selling

A crusher vehicle driving onto a wall overlay marked Crushable=yes destroys the segment, plays the overlay’s CrushSound and rocks the vehicle forward. This ignores ownership and damage stage entirely.

The sell cursor offers a sale over a cell meeting all of:

it is neither shrouded nor fogged;
it holds a wall overlay;
its stored owner is a house under player control.

The sale itself then needs all of, in this order:

the cell’s stored owner is a house a human is playing;
the cell holds a wall overlay;
All of: at least one BuildingType in the rules names that overlay in its ToOverlay, and the first such type declared is not Unsellable=yes.

The two ownership tests are not the same test. They coincide in a campaign game; outside one, the cursor asks whether the cell belongs to the local player’s own house, while the sale asks only whether it belongs to a house some human is playing.

Only that first BuildingType is consulted, so where several of them lay the same overlay, the one declared earliest decides whether the overlay is sellable at all. The sale then clears the cell and rebuilds the connection frames around it.

Gates

A gate is a real structure that stands in the wall line and opens for anything friendly wanting to cross it. Gate=yes supplies the door behavior; the four [General] keys in the table above supply the wall connection, and the two are independent.

Placing a gate

Placement clears the footprint first. Every cell of the gate’s foundation that is owned by the placing house and holds a brick, sandbag or Nod wall has that wall removed, and any laser fence section of the same house in those cells is folded into the gate.

A gate’s cell test is not the ordinary building one. It takes the branch a laser fence post takes, and that branch differs from the ordinary one in a single term: where an ordinary building refuses a cell holding any object at all, this one accepts a cell whose only object is a LaserFence=yes structure belonging to the placing house. Anything else in the cell — a vehicle, an infantryman, a terrain object, any other structure — refuses it. Both branches then require the cell’s standing places to be free: none of them occupied, none of them the destination of something on its way, and no vehicle holding the cell in reserve as it crosses.

After placement, and again when the gate is taken off the map, the connection frames of the two cells capping its run are rebuilt — the cell one step before the gate’s origin and the cell three steps after it, along the axis the naming key fixed. Those offsets are fixed in the engine and assume a three-cell gate; a gate with a different foundation updates the wrong cells.

Opening

Infantry, walkers, hovercraft and driven vehicles all ask whatever stands in the cell ahead of them to open as they come up on it. The answer depends on what stands there:

An allied gate is put onto its opening mission and answers no until the door reports itself fully open, so the asker waits in place.
An enemy gate is never asked to open. The asker’s own cell test reports it as destroyable — or as impassable when the asker carries nothing that can bring a wall down — unless it already stands open.
Anything that is not a gate answers yes at once and reports itself permanently open, which is what keeps every other structure out of this path.

Infantry standing in a gate’s cell scatters away unless the gate is open.

Holding and closing

The door travel in each direction takes DeployTime game minutes. Once open, the gate arms a timer of GateCloseDelay game minutes; when it expires the door starts closing and the gate returns to idle once it is shut. GateDown plays as the door opens and GateUp as it closes.

The close timer is reloaded from scratch on every pass while anything other than the gate itself stands anywhere in its footprint, so a gate holds open indefinitely while traffic is crossing and only begins to close once the footprint is completely clear. A close already in progress is reversed in place if the gate is asked to open again.

The door frame drawn while the gate is moving is its completion fraction scaled by GateStages; the frame details, the damaged block and the reversed buildup animation belong to that key and to production.

A structure that is not a gate

A building put onto the open mission without Gate=yes does not run any of this. It assigns itself Guard on the next pass and carries on as an ordinary structure.

Wall towers

The wall tower is whichever single BuildingType [General] WallTower= names. It stays a real structure instead of converting to an overlay, and every behavior below follows from that one name being matched rather than from any flag on the type.

For a house a human is playing, placing one on a friendly brick or sandbag wall removes that wall first, quietly and without refund; a computer house’s tower is placed on top of the surviving segment. The tower may be placed there even on an undamaged segment, which no ordinary wall building may do. Once placed it forces the four cells around it to rebuild their connection frames, and from then on it reads as a wall connection from every direction.

Removing one reverses both halves. The four cardinal neighbors rebuild their frames, and each of them still holding an undamaged wall is then hit for 200 damage — so pulling a tower out of a finished wall line damages the run it was holding together, and can start the cascade described above.

Where the computer places towers, and the defense pairing that puts one in front of each planned base defense, are covered by AI base planning.

Walls in combat and movement

A wall overlay gives its cell the land type its Land names — the stock wall overlays leave that at Clear and block through Wall=yes alone — and marks the cell blocked for pathfinding, or crushable when the overlay is Crushable=yes. What a vehicle or an infantryman reads at that cell then depends on what it is carrying, and the table gives the pairing. Each row names the thing entering: the first five rows are a wall cell and the last three a gate’s, because a wall and a closed gate answer the same question differently.

What is entering, and what it carries	What it reads at the cell
A crusher vehicle, at a `Crushable=yes` wall	Passable, and an allied wall is additionally reported as friendly and destroyable
A vehicle whose primary warhead is `Wall=yes`, or `Wood=yes` against wood armor	Destroyable, or friendly and destroyable when the wall’s house is allied
Infantry whose primary weapon has a `Wall=yes` warhead	The same pair of results, with no wood alternative
Infantry of any kind, at a wall whose stored damage stage equals `DamageLevels`	A hole, walked through with no further test — what the infantry carries is never consulted
Anything else at a wall, including anything unarmed	Impassable
A vehicle or an infantryman, at a closed allied gate	Reported as a closed gate, which is what sends it to ask the gate to open
An armed vehicle or infantryman, at a closed enemy gate	Destroyable
An unarmed vehicle or infantryman, at a closed enemy gate	Impassable

A vehicle or infantryman whose weapon can bring the wall down targets the cell itself, which is how one ordered through a wall ends up shooting it. One that reads the cell as flatly impassable attacks nothing and simply routes around. The computer’s automatic search for walls to shoot, and the difficulty setting that switches it off, are covered by target selection.

An overlay marked High=yes also stops fire crossing it: a projectile that is not itself High=yes and is flying below height 100 detonates on reaching the cell. A man set on fire refuses to run into a cell whose land type is Wall or which holds a wall overlay at all.

Filter keysRuntime effect

23 of 23

Key	Description	Value	When omitted
`Wall`BuildingType, OverlayType, WarheadType	Turns a BuildingType into a wall segment, marks an OverlayType as wall, or lets a WarheadType destroy walls.	boolean	`no`
`ToOverlay`BuildingType	The cell overlay a wall structure turns into when it is placed.	class	`none`
`GuardRange`AircraftType, BuildingType, InfantryType, UnitType	The distance in cells an object scans for targets while guarding, overriding its weapon range.	distance (cells)	`0`
`WallOwner`HouseType	Whether the country's buildings can claim ownership of nearby walls placed with the map.	boolean	`yes`
`Strength`No effect in some scopes12 applicable types	The maximum strength of most object types; wall overlays use it as a per-hit damage threshold.	integer	Partially documented
`DamageLevels`OverlayType	The number of damage stages a wall overlay passes through before it is removed.	integer	`1`
`Land`OverlayType	The land type a cell reports while this overlay is on it.	landtype	`Clear`
`High`BulletType, OverlayType	Marks an overlay tall enough to stop low-flying fire, or a projectile that flies over such an overlay.	boolean	`no`
`Crushable`No effect in some scopes12 applicable types	Lets a crusher vehicle drive over the object or overlay and destroy it.	boolean	Varies by type
`CrushSound`No effect in some scopes12 applicable types	The sound played when a crusher vehicle flattens the object or overlay.	sound	`none`
`Wood`WarheadType	Lets the warhead damage terrain objects, and wall overlays whose armor is wood.	boolean	`no`
`Unsellable`BuildingType	Prevents the BuildingType from being sold.	boolean	`no`
`Gate`BuildingType	Makes the BuildingType a gate that opens for a unit wanting to pass.	boolean	`no`
`GateStages`BuildingType	The number of door frames a gate animates through.	integer	`9`
`GateCloseDelay`BuildingType	The time in game minutes a gate stands open once its footprint is clear.	floating point	`0`
`DeployTime`AircraftType, BuildingType, InfantryType, UnitType	The time in game minutes a door takes to travel from shut to fully open, or back.	floating point	`0`
`GateUp`global rules	The sound played at a gate as its door starts closing.	sound	`none`
`GateDown`global rules	The sound played at a gate as its door starts opening.	sound	`none`
`GDIGateOne`global rules	The BuildingType that joins a brick or sandbag wall running east to west.	class	`none`
`GDIGateTwo`global rules	The BuildingType that joins a brick or sandbag wall running north to south.	class	`none`
`NodGateOne`global rules	The BuildingType that joins a Nod wall running east to west.	class	`none`
`NodGateTwo`global rules	The BuildingType that joins a Nod wall running north to south.	class	`none`
`WallTower`global rules	The BuildingType that joins a brick or sandbag wall run from any direction.	class	`none`