Target intelligence register
Enemies and targets
Separate confirmed target roles from assumed armor, position, and behavior before selecting an effect.
Use the enemies and targets database
This register is generated from the current validated snapshot, not copied from a competitor list. Every enemy and target row must point to a current entity version and at least one retained source. Evidence labels describe what the source can support; they are not popularity scores and they do not make an unknown field true.
Open a record to inspect its factual fields, verification date, source locator, patch scope, aliases, and related field files. Missing values remain missing. If a record is single-source, conflicted, or stale, it moves to Community Radar and cannot create an indexable detail page or feed an operational calculator.
Target intelligence begins with the role actually supported by the source. Armor, behavior, position, and recommended effects remain unknown when the evidence does not establish them.
Current snapshot
1 qualified enemies and targets records
- BunkersOfficial Enemy and target
Bunkers are confirmed hardened battlefield targets that the official store associates with armor-piercing rounds.
Also listed as: Hardened bunker, Enemy bunker
- Official shell role
- Armor-piercing
Operator method
Work with the enemies and targets register
Start from the objective you are trying to solve, then open the narrowest relevant enemy and target record. Read the summary and qualified facts before following an alias, relation, or outside source. Keep the record name, verification date, snapshot checkpoint, and any current-client value on the same note. This makes it possible to tell which part came from the public enemies and targets database and which part you observed during the present session.
Use related records as a navigation graph, not as permission to invent missing mechanics. A mission can link to an achievement, ammunition can link to a target role, and a card can link to requisition only when the retained relation states that connection. Open both records and compare their individual evidence boundaries. If a required field appears on neither page, check the current client or leave it unknown instead of carrying a number across categories.
After an official patch, review the records touched by changed names, interfaces, rules, or content. Stable descriptive facts may remain useful, but source-scoped values need a fresh check before automation republishes them. If evidence becomes stale or contradictory, the public route must fail closed and the item moves to Radar. That maintenance rule lets this enemies and targets register grow without requiring manual approval for every unchanged record.
- Open one qualified record and identify the exact supported field.
- Follow explicit relations only when they answer the current task.
- Keep session observations separate from public database facts.
- Recheck build-sensitive values after a patch checkpoint changes.