When a level's tags load, the VR build adds widget tags cloned from the
solo pause menu's (same font, colours, buttons and boxes): a fifth item,
VR SETTINGS, in the pause list (its button hints move under the mission
objectives to make room), and a screen of nine settings in two columns -
controls, aim, gun hand, turning, room-scale, scope, vehicle view,
steering and cutscenes. A or right steps a setting on, left back, B
returns to the pause menu; the laser pointer clicks them too.
Changes are written into config.toml (config_write_real/_string join
config_write_boolean) and the VR layer takes them up at once
(vr_reload_settings). cache_file_add_tag adds tags made in memory after
a map's own; the buttons' text and changes come through a new game data
input function and two event handler functions.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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.
Native builds only (#ifdef HALO_LINUX); the matching MSVC build keeps the
original text and stays byte-identical.
- ui_widget_game_data_input_functions.c: the local machine limit follows
HALO_PORT_MAXIMUM_NETWORK_MACHINES and the struct network_game copy holds
HALO_PORT_MAXIMUM_NETWORK_PLAYERS players; its layout is checked against
halo_port_limits.h. The pregame screen keeps its three remote machine
panels and shows the first three remote machines instead of asserting
(sizing its arrays by the machine limit read uninitialized widget
pointers). netgame_prejoin_players scans every player slot, and the
player count texts have room for three digits. network_machine_is_valid
widens the char index before comparing it with 128.
- ui_widget_event_handler_functions.c: the join/unjoin, team swap and
countdown handlers use the port's players offset and player count
instead of 0x226/0x242/0x243 and 16.
- hud.c: hud_draw_players sizes its teammate buffer by the port's player
limit and bounds the fill (more than 16 teammates overflowed the stack).
- motion_sensor.c: multiplayer tests the (horizontal) range before a unit
takes a blip slot, so distant units no longer crowd nearby ones out of
the 16 slots.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
All 100 functions were strict exact and the 934-byte .data section was
identical to January's: same payload, flags and resolved destinations
for all 228 relocations. But 98 handler functions,
event_handler_function_list and new_campaign_profile_name were external
in our source. cachebeta.pdb publics show all 100 were file-static in
January, and no other January object references them. Adding `static`
to their prototypes and definitions keeps every function strict exact.
All 452 January symbols now match, and the .bss is identical.
The object also emits the three stock D3D SDK .rdata tables. Each is
byte-identical to January's selected copy (rasterizer_xbox_decals,
progress_bar, headers) and pair-links in both orders, like the 54
already-admitted objects that emit them. The rasterizer_xbox_profile
hold additionally rests on that object's own shared-declaration debt.
One pinned entry in config/semantic_data_matches.json.
- Canonical scorer (objdiff 3.3.1): credits 934 data bytes and clears
one more revoked row (4 -> 3).
- Pinned objdiff 3.6.0: a verified no-op.
- No code bytes, no config status change.
Verification: full ninja; stable diff vs frozen 8,245-function baseline
0 gained / 0 regressions; parks 103/0/0; fake-match scan 0 -> 0;
pytest 1154 passed; git diff --check clean.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
