Import only independently reviewed production changes. Preserve canonical physics and virtual-keyboard repairs; keep B3 and all unresolved holds out.
Record exactly four approved canary debits (6987 meaningful bytes), six Halo admissions and two revocations. Keep vendor ioinit/storage work separate. Full build, 8252-row sweep, 1318 tests, park/admission/fake audits and 621-object binding pass within approved debit bounds.
Do not publish donor research dumps or private assets. README and unrelated user research remain untouched. See frontier_publication_reconciliation_20260927.md for complete evidence limits and accounting.
The Xbox game allows 16 players on 4 machines (4 split screen players
each). The native builds raise both limits to 128, keeping 4 players per
machine, and leave the byte-matching build unchanged: every change is
under HALO_LINUX (the MSVC objects compare identical).
- Limits: every local copy of the player and machine limits, and the
bare 4s and 16s that stood for them, follow halo_port_limits.h. The
player data array, the machine-to-player table (and its reset) and the
per-tick update arrays grow with them.
- Records: the copies of struct network_game agree on the larger layout
and check it against halo_port_limits.h; maximum_player_count becomes
a byte (128 does not fit a signed char); network_player_is_valid
checks the machine against the machine limit, not the split screen
one; a machine's input carries MAXIMUM_LOCAL_PLAYERS actions (16/4
would have become 128/128).
- Protocol: a message holds at most 4095 bytes (its header has a 12-bit
length), so the 13 KB game settings record is sent in 3.5 KB pieces
that clients reassemble; the per-tick update of 128 players (3,857
bytes) fits. Buffers and the packet codec's limits grow to match, and
the game search uses protocol version 2 so these builds and the Xbox
game never see each other's games.
- Connections: the host accepts a client connection per machine (the
split screen count stood in for it), FD_SETSIZE is 256, stream writes
send all of a message or drop a peer that stops reading instead of
corrupting the stream, and the input and update queues are larger.
- Host: lobby changes are sent at most every 250 ms instead of on every
change (a full lobby would otherwise send ~650 MB), in-game joins wait
in a queue instead of being dropped, the random name and colour
pickers stop looping forever once names or colours run out, machines
get 60 s to load a map, and the debug dump lists only the slots in
use (128 empty slots took seconds to log).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Reconstruct three bounded functions in network_messages.obj against the
January target object:
initialize_network_game_packets 0x10 padded, 2 relocations
network_event 0x60 padded, 8 relocations
decode_network_game_message 0xa0 padded, 8 relocations
All three are proven exact by coff_compare.py: padded size, normalized
hash, and every relocation offset, type, resolved target and addend.
Parameter names and assert expressions are recovered from the target's
own assert strings. data_0030aa68 is declared with a named container
type following the initialize_key_agreement_packets convention, placing
the packet group at +0x830; its definition is deferred with the packet
definition table.
data_packet_group_decode_packet is declared in data_packet_groups.h,
whose parameter names come from the callee's assert strings.
data_packet_groups.h now includes cseries.h so it is self-sufficient for
translation units that include it without cseries.h first.
code_0011af00 (encode_network_game_message) is left dormant: it takes
message_struct, encoded_message and encoded_message_size in edi/ebx/esi
without saving them, so it uses a private register calling convention
that MSVC only selects with its sole caller, create_network_game_message,
present in the same translation unit.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
MrBruh