Choose a shell without guessing

What is verified about the arsenal

The current official Steam description advertises a combined total of thirty ammunition types and abilities across the game. It does not publish a verified split showing exactly how many are shell items and how many are abilities. Public community databases publish different totals. This shell guide therefore does not convert a competitor count into fact, reproduce an external shell database, or claim complete current statistics without current-client evidence.

That boundary still leaves a useful operator method. A shell choice can be checked against the mission's requested effect, the target description, the visible shell label, and the current game interface. Record the shell exactly as displayed, keep the shell with the charge and elevation from the same calculator pass, and judge the shell after reconnaissance. The goal of this page is not to invent a perfect shell tier list. It is to prevent unsupported shell claims and reduce selection mistakes during a firing solution.

Use a five-question shell check

First ask what effect the order requires. Destruction, suppression, area denial, illumination, and support are different jobs even when the target location is identical. Second ask what the report actually confirms about the target. Do not add armor, movement, or composition that the report never states. Third inspect the current shell labels and descriptions in the game. Fourth check whether the selected shell is compatible with the intended charge and firing data. Fifth record the shell result after impact so the next decision uses evidence instead of intuition.

A shell decision should be explainable in one sentence: 'Selected this shell because the objective requests this effect and the current interface describes this role.' If the sentence depends on a remembered community statistic, mark it as an assumption and recheck the current client. The current-client shell label is more valuable for play than an old unsourced spreadsheet. Evidence-first does not mean avoiding every choice. It means keeping the shell reason visible, narrow, and easy to revise after a patch or reconnaissance result.

1. Read the requested target effect before opening the shell list.
2. Match only confirmed target traits, not imagined traits, to a shell role.
3. Read the current shell label and description in the live game client.
4. Keep shell, charge, and elevation together on one firing card row.
5. Record the observed shell effect before changing the next solution.

Keep shell data attached to the firing card

A correct target plot can still fail if a shell selection is transferred incorrectly. Write the full shell label rather than an abbreviation that could refer to several rounds. Place shell, charge, and elevation next to each other because those values form one firing configuration. If you change the shell, run the current game calculator again when required and create a new row. Do not edit the old shell row in place, because the old result is needed to understand what changed.

At the turret, point to the shell line, select that shell, and then verify the visible control. Continue with charge, bearing, and elevation. If the mission interrupts the transfer, restart the check at the shell line. This deliberate sequence is faster than diagnosing an accidental shell after impact. When ammunition is limited or a counter-battery timer is active, preserving a clean shell card is even more important because every undocumented attempt consumes both time and evidence.

Read shell results without overclaiming

Separate location quality from shell effect. A shell can land at the intended point but fail to create the requested outcome. That is primarily an effect problem. A shell can also produce the expected effect in the wrong location, which is primarily a plotting or firing problem. Record impact location and observed effect as separate fields. This prevents a wrong target bearing from being misdiagnosed as a weak shell, and it prevents an unsuitable shell from being misdiagnosed as poor accuracy.

One observed result is a session observation, not a universal shell statistic. Map state, target state, difficulty, patch level, and incomplete observation can all affect interpretation. Repeat only when the mission allows and when the result will answer a specific question. If changing the shell, keep the target geometry and firing solution stable where possible. If correcting location, keep the shell stable where possible. Changing one category at a time makes the next reconnaissance report useful.

• Location field: short, long, left, right, centered, or not observed.
• Effect field: objective achieved, partial effect, no confirmed effect, or unknown.
• Change field: shell role, target plot, firing transfer, or no change yet.
• Evidence field: current client, official source, community report, or unverified assumption.

Why this is not a copied shell database

A large shell table looks authoritative even when the labels, counts, or values are stale. Current research found conflicting public totals, while the official description provides only a combined ammunition-and-abilities claim. Publishing a complete shell database from competitor pages would create two problems: the data would lack independent current-client proof, and the presentation could copy protected selection or expression. This site instead publishes the source boundary and an actionable shell workflow.

A future arsenal record must include its current visible name, role text, version context, evidence source, verification date, and any conflict. Numeric damage, radius, cost, unlock, or timing fields require direct current-client evidence before appearing as fact. Missing information stays missing rather than being filled from another wiki. This policy keeps the shell guide focused, and it makes each published statement inspectable. The sources page shows the exact evidence labels used throughout the site.

• AP shell: Armor-piercing ammunition code documented by a community guide. Status: stale; verify in the current client.
• HE shell: High-explosive ammunition code documented by a community guide. Status: stale; verify in the current client.
• HCHE shell: HCHE ammunition code documented by a community guide. Status: stale; verify in the current client.
• SMK shell: Smoke ammunition code documented by a community guide. Status: stale; verify in the current client.
• STAR shell: Illumination ammunition code documented by a community guide. Status: stale; verify in the current client.

Common shell selection errors

The most common ammunition error is choosing by a remembered name before reading the objective. Another is carrying the previous target's shell into a new firing card. A third is changing the shell but keeping charge or elevation from an earlier calculator pass. A fourth is treating an ineffective result as a location miss without checking where the shell landed. A fifth is trusting a community table after a patch without checking the current shell interface.

Use a fast recovery: stop, preserve the incorrect row, create a new shell row, restate the ordered effect, read the current shell description, recalculate dependent firing values, and transfer the full card again. If the next shell lands in the same location with a different effect, you learned about shell selection. If it lands elsewhere, inspect the firing card and control transfer. The missed shot guide provides a wider error ladder when shell and geometry may both be involved.

Shell field template

Use this compact line for each attempt: target label, required effect, confirmed target trait, selected shell label, reason, charge, elevation, bearing, range, impact location, observed effect, and next change. Keep each shell attempt on a separate line. If a value is not known, write unknown rather than leaving an ambiguous blank. If a reason comes from community advice, label it community until the current client confirms the relevant behavior.

Link the shell line to the map line by using the same target label. The firing planner can store the shell label, charge, and elevation inside a private browser card after geometry is calculated. Those values are not transmitted to GA4 or a server. The planner deliberately does not recommend a shell or calculate game elevation. It helps with transcription and geometry while leaving the current game interface as the source for shell-specific firing values.