What this guide can confirm
Counter-Battery is one of the mission titles documented in the current public gold-medal guide. Players also report uncertainty about finding a second enemy artillery wave and managing the counter-battery timer. Those are community observations, not an official specification of every trigger. This battery guide therefore focuses on preparation, information control, calculation order, and result handling. It does not publish unverified enemy coordinates, exact timer rules, or a scripted battery solution.
The battery workflow follows the official gameplay loop: read reports, plot targets, solve firing data, operate the turret, fire, and review reconnaissance. Time pressure changes how the battery work is staged, not the need for correct origins and transfer checks. The best way to gain time is to prepare multiple battery calculations before firing and to keep each target on its own card. Guessing under pressure usually spends more ammunition and produces less useful evidence.
Prepare the battery desk
Before the battery mission begins, open a clean worksheet and the Operator Console. Record the current Nest position, map north, mission name, and one blank row for each expected target report. Add columns for report source, observer position, bearing, distance, target coordinate, Nest bearing, Nest range, shell, charge, elevation, and observation. This battery structure prevents the first target's values from leaking into a later wave.
Keep the current game calculator available and leave shell-specific fields blank until the battery target is plotted. The official store confirms a combined total of ammunition types and abilities but not a verified shell count, so this guide does not prescribe a universal battery round. Read the ordered effect and current interface. If the Nest position changes, invalidate every range and bearing derived from the old battery origin, then recalculate before transfer.
- Mark the Nest position and map north before the first battery report.
- Create a separate source, plot, and firing row for every target.
- Leave shell, charge, and elevation blank until current calculation.
- Open the Console and select the mode that matches each report.
Build a target queue
Treat incoming battery reports as a queue rather than isolated interruptions. Give each source a short label such as A, B, or FDC 1. Record priority and time received without assuming that arrival order equals firing order. Plot every battery target that has sufficient information, then compare mission priority, confidence, and readiness. A completed solution can wait in the queue while an incomplete report remains visibly blocked.
Never overwrite a battery row when a second wave arrives. New observer data gets a new row even if the target description sounds similar. If a report supersedes earlier coordinates, mark the old battery row stale and preserve it for after-action review. This avoids firing a clean solution at an old location. The private Console history can keep up to twenty records, which is enough to preserve several battery attempts without a server account.
Solve battery spotter reports
A spotter bearing begins at the spotter, not at the battery Nest. Enter Nest coordinates, spotter coordinates, spotter bearing, and positive distance in Spotter vector mode. The Console projects the battery target, then calculates a new bearing and range from the Nest. Confirm cardinal direction before using decimals. A 90-degree report should place the target east of that observer, regardless of where the Nest sits.
If two battery observers provide bearings without distances, use Cross bearings. Each observer ray must point forward toward the same intersection. Parallel or nearly parallel rays are unstable and the Console rejects them. An intersection behind either observer is also rejected. These errors mean the selected battery geometry cannot support a safe location. Recheck report direction and positions or wait for stronger information instead of forcing a precise target.
Treat timer rules as evidence-sensitive
Community discussion shows that players are unsure when the counter-battery timer pauses, extends, or becomes harder to manage. This page does not turn those questions into timer facts. Observe the current build, record when the battery timer changes, and keep that session note separate from public guidance. A popular comment can reveal demand for an explanation, but interaction does not verify the mechanic or its conditions.
Plan as though a battery delay is expensive without claiming an exact rule. Complete map calculations before entering a firing sequence, keep cards in priority order, and verify controls without unnecessary movement. If the current client visibly changes the timer after a specific action, that is useful private session evidence. Publishing a durable battery timing rule still requires repeatable current-client proof with build context or a direct developer statement.
Calculate several targets before firing
When reports permit, solve the battery queue before the first shot. Calculate target coordinates and the final Nest vector for each ready row. Then use the current calculator to add shell, charge, and elevation. A battery card is ready only when all transfer fields belong to the same target and calculator pass. Mark incomplete cards blocked so time pressure cannot make an old charge look current.
Precalculation reduces turret switching and keeps the battery sequence deliberate. It also exposes impossible or unstable reports before ammunition is committed. Do not calculate disputed game elevation with a community shortcut merely to save seconds. Public formulas conflict in scale, so the Console stops at transparent geometry. The current game interface remains the source for battery charge and elevation until stronger evidence resolves that conflict.
Run the battery turret sequence
At the turret, announce or point to the active battery label. Transfer shell, charge, bearing, and elevation in the same order every time, then compare visible controls with the card. If interrupted, restart the transfer check from the beginning. Fire one documented battery solution and preserve its controls until reconnaissance arrives. A remembered adjustment made between card and turret destroys the record's diagnostic value.
After impact, classify the battery result as hit, short, long, left, right, wrong effect, or unobserved. Save a new private record if you correct the shot. A large miss reopens source, coordinate, convention, and gross transfer checks. A centered impact with wrong effect reopens shell choice. An unobserved battery result does not support a numeric correction. This keeps limited time from turning into random walk adjustments.
Recover from common battery failures
Failure one is using a spotter bearing at the Nest. Replot from the observer. Failure two is carrying the first wave's firing row into the second battery target. Create a new row and label it. Failure three is changing shell without refreshing dependent values. Return to the current calculator. Failure four is treating a timer rumor as fact. Record current behavior and keep uncertainty visible. Failure five is correcting an unobserved shot. Wait for evidence.
If the second battery wave cannot be found, reread every new report and compare its source with the existing queue. Confirm whether the Nest moved, whether the map layer changed, and whether a newer observer report superseded the old one. Do not copy an unverified public coordinate. The mission may vary by state or build, and a false battery coordinate would create confident failure. Use the mission hub and missed-shot ladder when the problem cannot be isolated.
Keep the battery evidence boundary
The official source supports the broad operator loop. The current community mission guide supports the Counter-Battery title. Steam discussion supports only the fact that players report difficulty with a second artillery wave and battery timing. None of those sources provides a verified universal target table. This page paraphrases source scope, links the evidence, and avoids copying a competitor database or player solution verbatim.
Future battery updates should follow the same rule. An official patch can trigger review. Multiple independent current reports can raise investigation priority. Current-client captures can verify visible labels and behavior with build context. Low-confidence social material can enter a private candidate queue, but it should not automatically rewrite the public battery procedure. That evidence gate is how the site stays largely unattended without becoming a rumor amplifier.