v1.36.1

1.36.1: write characters in CoGM's order on subject-first layouts

CoGM reads a kill line's character pair as (otherChar, subjectChar).
get_logs_string emits the two leftover columns in ascending order, which
matches most layouts but not 720100fe1a (col1 ours, col2 theirs, measured
on the 16.08 and 13.08 captures) or 2e03010003 (normalized with our side
in the killer columns). Those joined 670100e111 in SUBJECT_FIRST_CHARS,
so every kill on them had each side's character stored on the other
family. 640100bb17, 6b01003f0e and 6c0100aa19 are enemy-first and
unchanged.

UI-only: 1.36.0 installs take the resources swap, older ones still get
the full installer.

v1.36.0

1.36.0: decode the SEA kill packet and keep Thai names

BDO moved the SEA/TH node-war kill record to opcode 670100e111
(2026-09-23). The registry now pins it: col3 subject family, col4 enemy
family, col1 enemy guild, kill flag at hex char 393. Checked against
three alliance warscores from the same war.

Thai family and character names were dropped at both ends. The engine's
extract_string only took UTF-16 units with a 00 high byte and the name
regex was ASCII, so a name like Jสmbสng came back Unknown or the whole
kill was lost (19 of 379 in that war). The UI then re-read every name a
byte at a time, which dropped any line with a Thai enemy (81 of 360).
Both sides now accept Thai letters, marks and digits through a strict
path (terminator plus zero padding, Thai/ASCII only) that only runs when
the ASCII read fails, so ASCII wars decode exactly as before. Engine
lines with Thai go to stdout as UTF-8 so a cp1252 pipe cannot end the
capture.

Also:
- 670100e111 lists its characters subject first, so they are written
  back in CoGM's (other, subject) order.
- The Open page parses saved .log files with \S+ names like CoGM does,
  and no longer writes "(undefined,undefined)" for lines without
  characters.
- Installer version string was stuck at 1.20.0.

Minor bump: the capture engine changed, so installs need the new binary.

v1.35.2

1.35.2

v1.35.1

1.35.1: ignore junk packets before the first real kill

v1.35.0

1.35.0: keep kills when a character slot fails to decode

The capture engine required all five name columns to pass a strict regex,
so a garbled character name dropped the whole engagement even when killer,
victim, and guild were sitting in the other columns. Equinox 06.09 lost
about 150 kills that way.

The engine now learns the five-column layout from the first clean record
and slots incomplete hits onto it. The UI still emits the line if killer
and victim decoded; coords and character names can be missing. Compiled
registry gains 6c0100aa19 (families col4/col3, guild col2, flag hex 395).

Ships as a minor on purpose: live_capture.py is inside logger.exe, and a
patch-level update swaps resources.neu only.

v1.34.0

1.34.0: record hotkey, session history, New war split, quit guard, Np…

v1.33.1

1.33.1: decode the real post-patch war kill record (720100fe1a)

Tonight's wars proved the marker-pair records from the patch-day capture are
the channel-wide ticker of OTHER guilds' fights, not the recorder's own war:
a full war pcap contained 1072 marker pairs with zero of the recorder's
families, while their own kills rode a separate record. That record is tag
72 01 00 fe 1a, identical on NA and SA: subject-centric with five fixed name
fields (enemy guild, subject char, enemy char, subject family, enemy family),
a clean 0/1 direction flag at byte 67, and the kill position. Every 'new
opcode' the calibration intake flagged tonight (5101000000 SA, 6701000000,
5b01000000, 5001000000, 5901000000) was this same record mis-anchored a few
bytes early by the loose identifier regex.

The engine now anchors on the exact 10-hex tag (widening the byte0 class
instead admitted stray anchors that disturbed multi-match disambiguation
around real kills in the July control war). The registry maps killer=col3,
victim=col4, guild=col0, flag hex 135, served compiled and from cogm.app.

Validated: 208 kills recovered from tonight's war pcap that 1.33.0 recorded
zero from, kill-direction correlation r=0.82 against the in-game result
board with both extremes exact; July pre-patch control field-identical.
The marker-pair detector stays: its records orient against the roster and
third-party ticker kills are dropped before stats or upload.

v1.33.0

1.33.0: decode the 2026-08-13 kill format

The Aug 13 game update replaced the 5-name fixed-offset kill packet with
marker-based observer records (signature 2e0301000301020000, two a70000ae1c
identity blocks with a variable gap). The engine now runs a second detector
alongside the old one: marker scan over a consuming per-source buffer, names
at fixed offsets within each block, emitted as the same 8-field line with
normalized hex so every column keeps a constant offset.

These records are a global zone feed, not kills involving our guild, so the
UI orients each one against the alliance roster before it reaches stats or
upload: ours-as-killer stays, ours-as-victim swaps the identity fields and
flips the direction nibble, third-party kills are dropped.

Validated offline against a real post-patch war capture (both ground-truth
kills recovered, incl. under 37-byte fragmentation and full retransmission)
and against a 203k-packet pre-patch war (old detector byte-identical).

v1.32.0

1.32.0: hand patch updates to the installer when the in-place swap fails

The patch-level update path swaps resources.neu in place via updater.install().
Installed builds live in Program Files, where the unelevated app can never
write, so the swap fails on every installed machine and the banner blamed the
user's connection. Nobody noticed until 1.31.1, the first patch-only bump:
installed users got a Retry button that could never succeed while recording
stayed gated.

The installer path elevates through UAC and every installed user has already
been through it, so a failed in-place swap now hands over to it instead of
dead-ending. Portable builds run from a writable folder and keep the quick
in-place path.

Shipped as a minor bump on purpose: 1.31.x users take the full-installer path
to get here, which is the one that works.

Claude-Session: https://claude.ai/code/session_013HgsuHq835dUWsFQP2Cbud

v1.31.2

Claude-Session: https://claude.ai/code/session_01TxWF5D8iD41Tus7ASXDU4T