CSV Combat Logs

Despite the .csv name, the game combat export is tab-delimited. One file can contain several tables: a battle summary, the per-event combat log, and optional Formation Armada results, rewards, and fleet-stat sections. Each section starts with its own header row. The parser identifies sections by their headers rather than assuming fixed line numbers or a fixed section order.

The combat section is the main event table. Each row has a Round and Type, then the columns relevant to that event. Common types include Attack, Officer Ability, Forbidden Tech Ability, Charging Weapons, Shield Depleted, Combatant Destroyed, hull repair, and Hyperthermic Decay. Attacker/target names and ships identify the sides; Battle Event preserves event order, and repeated attacks within a round are separated into sub-rounds by the parser. The event type is always in the Type column; no export has been seen to write it under another header.

Two rarer types carry no damage. A Taunt row is written when Taunt fires: the taunting ship is both attacker and target, and every amount column is empty. A Hyperthermic Stabilizer row naming DEFENSE PLATFORM A as both attacker and target is an export defect, not an event: the game writes it only while a Galactic Anomaly is active, so it tells a CSV that one was, and it says nothing else.

A CSV does not mark sub-rounds, so they are inferred from the order of the rows. What makes that possible is that every weapon slot leaves a trace in every round: a slot that fires writes one Attack row per shot, and a slot that is warming up or reloading writes one Charging Weapons row, whose Charging Weapons % column is that weapon’s charge (100 in the round before it fires). The raw JSON log marks each sub-round explicitly, so its sub-rounds are read rather than inferred.

The export has a defect around weapon charge. When a weapon’s charge is below zero — it is more than its reload away from firing, where a long warm-up starts the fight and a delay such as Chang’s can push a reload — the CSV writes an Attack row instead of a Charging Weapons row: not critical, with every damage column at zero, including Total Damage. A player’s row is aimed at the opponent; a hostile’s targets the hostile itself, as its Charging Weapons rows do. The first such row in a fight is followed by a Shield Depleted row for the target even though its shield is intact, and the export then never writes the real depletion, so a CSV cannot tell when that shield actually went down. The raw JSON log records the same moments correctly, as charging events with a negative charge and the shield amount on every hit. A genuine non-critical shot that lands for zero is rare (it takes an effect that negates a whole shot), so a lone zero-damage, non-critical Attack row is almost always this defect rather than a shot. The defect leaves one row per weapon slot; a run of zero-damage rows from one ship at one target, one per shot of a whole volley, is something else (seen as a hostile firing at itself) and is not a charging weapon.

No row carries a ship’s hull. The summary gives two figures per ship: Hull Health, the hull it entered the fight with (below its maximum when it arrives damaged), and Hull Health Remaining, the hull it ended with. Between them, the entering hull plus the hull repaired minus the hull damage logged comes to the end hull, so the hull after any row can be worked back from the end through the damage and repairs after it. The fleet-stat section has a Hull Health and Shield Health of its own, and for a player’s ship they are not its maximum in the fight. Set beside the raw JSON log of the same fight, a ship that entered at full had a summary Hull Health equal to the journal’s maximum, while its fleet Hull Health was 1–4% lower, by a different amount in each fight, and appears nowhere in the journal; a Borg Sphere’s fleet Shield Health of 700 million stood beside a summary Shield Health of 6.4 billion. For a hostile the fleet figures match the summary’s. So a CSV gives a player ship’s in-combat maximum only when it entered at full, where it is the summary Hull Health. What the fleet figures leave out is not yet settled. Hull repaired each round has a row of its own; shield restored during the fight has none (a Morale row says only that Morale was on), so a CSV’s shield can be followed shot by shot only while nothing has restored it. The fleet section’s Buff applied and Debuff applied columns read NO in every export, whatever the ship carried, so they say nothing. The raw JSON log writes the hull left after every shot.

The summary lists each ship’s bridge officers only. Below deck officers are not listed in a CSV export, so a full crew — and which of its seats were live — has to come from the raw JSON log (see Officer Seats).

On an Attack row, Total Damage is the standard weapon-damage pool before its mitigation chain; Total Isolytic Damage is the isolytic pool reported after any isolytic critical-mitigation cut but before Isolytic Defense; Mitigated Damage is standard mitigation; Mitigated Isolytic Damage is Isolytic Defense; Mitigated Apex Barrier is the Apex cut; Hull Damage and Shield Damage are what finally landed. Critical Hit? determines whether Critical Mitigation can contribute.

Most game CSVs provide one Mitigated Critical Damage column combining the standard and isolytic shares. Newer community-mod exports may also provide named Mitigated Standard Critical Damage and Mitigated Isolytic Critical Damage columns. Those names are CSV headers; the numeric [14] and [15] notation used in technical discussions refers only to positions in a raw JSON attack payload.

CSV is convenient but is derived output: large values can drift by a few units through float serialization, localized exports rename headers and values, and some versions contain known numerical defects. In particular, some critical-hit rows with isolytic damage add the hidden isolytic critical-mitigation share to Total Damage. The parser checks damage conservation, preserves the exported value for auditability, and corrects the working standard amount only when the affected equation matches. See Critical Mitigation for the recovery formulas.

M96 exports add Polaron Damage and Mitigated Polaron Damage columns (Infusion, under its first name), and Focused Polaron Damage and Mitigated Focused Polaron Damage (Polaron). Focused Polaron Damage is written after mitigation, unlike every other damage column; see Polaron Damage for how the parser rebuilds it, and Infusion Damage for the renamed headers.

Headers and action values may be localized. The parser detects the locale from the section headers, maps recognized fields to canonical English names, and normalizes outcomes, actions, booleans, officers, and abilities before analysis. Community mods can append version tags to headers and add columns; consumers should match names, tolerate unknown columns, and never rely on a column number.

Use CSV when sharing, reading, or doing spreadsheet analysis. Use a raw JSON combat log when exact component values, stable numeric IDs, fleet snapshots, battle context, or verification of a suspicious CSV amount matters. Both inputs are normalized into the same internal combat rows and feed the same analyzer.

See also: Raw JSON Combat Logs, Mitigation Pipeline, Critical Damage Mitigation, Isolytic Damage, Apex Barrier