HD2Runtime v0.40.1 — 0.31 Application Path by Default, No game.dll Executable Writes, Unlimited Custom Stratagems

HD2Runtime 0.40.1 — the 0.31 application path by default, no game.dll executable writes, any number of custom stratagems

Released 2026-10-19. 0.40.1 pairs with the HD2R Editor 1.0.1.

0.40.1 has three parts:

• the 0.40.0 application optimizations are off by default, with a setting to turn them on;
• nothing is written into game.dll's executable pages any more (the armor class tables and damage curve are read only);
• the cap of 16 custom stratagems is gone. The CUSTOM STRATAGEMS panel shows at most 20 cards at once (five rows of
  four) and scrolls the rest with a scrollbar.

Each item says whether it was seen working in game ("live") or is covered only by the offline tests and the packaged
validation.

Faster application (0.40.0) is off by default (live, user report 2026-10-19)

Players reported the game failing to start, or closing at start, with 0.40.0, where 0.31.3 started. The cause is not
known. 0.40.1 goes back to the 0.31 application path by default, and keeps the 0.40.0 optimizations behind a setting:
F10 > Settings > Interface > Faster application (0.40.0), off by default and saved.

On, it turns on:

• discovery walks shared per address space and profile, and the decoded entity map and component index caches;
• the 2 MiB read slice (off: 1 MiB);
• sleeping ensures, where the scheduler skips an ensure's tick until its next check is due;
• the HD2R Editor's paused checks while its window is hidden;
• the per-update write-gate budget;
• the enemy capture's resource filter.

Off, back-to-back operations reuse one memory walk for 15 s, every watch ticks every frame, an Editor-owned ensure keeps verifying while the Editor is closed, and a burst of
operations is admitted in one update, as in 0.31. Both modes keep every ownership check, fingerprint, snapshot and
rollback. See runtime performance.

• The HD2R Editor's Settings switch "Optimized application" set the same thing in 0.40.0 and turned it on at every
  start. Editor 1.0.1 saves the choice through the Runtime instead
  (hd2.diagnostics.save_application_optimizations) and no longer turns it on at start. Editor 1.0.0 still turns it
  on for its session. Update the Editor along with the Runtime.
• hd2.diagnostics.application_optimizations(enabled) still changes it for the process only.
• Measured offline (the same 150 editor-style weapon edits on the retained snapshot, in the current packaged
  harness): 0.31.3 settles in 47.3 s of simulated frames with 4 memory walks; 0.40.1 with the setting off does the
  same, frame for frame, with 0.4 s more CPU once at load and about 2 ms more per operation. The 0.40.0 switch's
  "off" had disabled every shared walk (150 walks, 711 s), which would have made applying slower than 0.31.3.
• Live (user report, 2026-10-19): with the setting off, edits apply at 0.31.3's speed again. Whether it fixes the
  0.40.0 start-up crashes reported by players is not known yet.
• Tests: off by default, a sleeping watch ticks every frame, a burst is not budgeted, a paused ensure keeps verifying;
  the F10 row saves the choice and sets the mode. The optimization tests turn it on explicitly.

Game.dll executable data is read only (offline only)

The armor class tables (armor value, speed, stamina per weight) and the armor damage curve sit in game.dll pages that
are executable at run time. Since 0.30.0 they were written as "reviewed executable data". A player reported GameGuard
closing the game right after a mod wrote them. 0.40.1 writes nothing into game.dll's executable pages:

• armor_class.* and armor_damage_curve.* are editable = false with a readOnlyReason. Every change is refused
  before anything is read, with GAME_DLL_EXECUTABLE_DATA. They can still be read and described;
• the same rule covers the melee and enemy director fields that sit in such a page: their write is refused with the
  same code;
• a mod or preset that changes one of them logs the refusal; its other operations go ahead;
• kit piece weights, armor perks and the local player's armor bonus and stamina factor are ordinary data and stay
  writable;
• the HD2R Editor 1.0.1 shows the class and curve rows read only.
• Tests: tests/test_executable_data_extent.py, tests/test_armor_stats.py; scripts/validate_armor_stats_snapshot.py
  on all seven retained snapshots (every class and curve change refused, the tables unchanged); the packaged
  ArmorStatProbe scenario (its Alt+F9 curve ensure is rejected, nothing written).

Any number of custom stratagems (live, user report 2026-10-19)

• hd2.custom_stratagem.register no longer refuses the 17th custom stratagem. The caps were in
  runtime/custom_stratagems.lua (MAX, LIMITS.definitions) and runtime/virtual_stratagems.lua (MAX).
• The builder schema has no limits.definitions, and the project schema has no maxItems on stratagems.
  sdk/tools/custom_stratagem_project.py accepts any non-empty list. With an older schema that still has the limit,
  it still applies that limit.
• The Runtime text budget is the bound now. Each custom stratagem takes 3 Runtime texts (name, cased name,
  description); an expendable takes 4.
  • The budget was 256 texts in a 64 KiB table, about 64 to 85 custom stratagems across all mods. It is now 4096 texts
    in a 1 MiB table.
  • The table format is unchanged (u32 offsets; the game's own tables hold up to 7300 ids each). The game finds an id
    by binary search.
  • The table is built in Runtime-owned memory, which is never freed. A session builds at most 16 tables, as before.
• A text that does not fit is refused when it is defined. Before, a table over the byte limit failed only when it
  was written, as TEXT_BUDGET, and then no Runtime text showed at all. Now the registration that would cross the
  limit is refused at load time, with the error custom text budget reached.
• Compatibility. A mod that registers more than 16 custom stratagems needs Runtime 0.40.1. On 0.40.0 its 17th
  registration fails at load.
• Not changed:
  • The multiplayer protocol carries picked ids only (4 slots a player).
  • The registry hash covers every definition, as before.
• Not measured with many definitions:
  • Aboard the ship, the per-second availability pass allocates a carrier for every registered definition.
  • Every definition's assets and deliveries are excluded from every carrier pool. Many definitions can therefore
    leave fewer free carriers, and more of them show as unavailable.
• Tests:
  • forty custom stratagems register in order, each with its own virtual stratagem and panel entry;
  • the byte bound refuses a text at definition, and the table built from the accepted texts fits;
  • the 4096-text bound;
  • the schemas have no definitions limit.

The CUSTOM STRATAGEMS panel scrolls, at most 20 cards in view (live, user report 2026-10-19)

• The native-style panel (the one drawn right of the native details panel) shows at most five rows of four, 20
  cards (six rows before).
  • More rows scroll with the mouse wheel over the panel, a click on the scrollbar track (a page), or the F6 focus,
    which scrolls to its card.
  • The native-style scrollbar is drawn right of the grid while there are more rows than fit.
  • The panel no longer refuses more than 240 entries.
• The fallback panels scroll too:
  • the compact panel, used when the native-style panel does not fit (at most two rows of three);
  • the legacy panel (one row).
  • Before, they never scrolled, and entries past the last visible row could not be reached. They also refused more
    than 60 entries.
  • They now take the same wheel, track and focus input, and draw a scrollbar in the grid's right padding.
• Tests:
  • thirty entries: five of eight rows in view, card 20 visible and card 21 not; the wheel, a page down on the track
    and the focus scroll it;
  • 100 entries in the compact panel: two rows in view, its scrollbar inside the panel, a page down;
  • 200 entries in the legacy panel.
• Live (user report, 2026-10-19): the user tested the expansion with proof/CustomStratagemScrollTest (24 custom
  stratagems) and reported that everything worked. Which input scrolled (wheel, track or F6) and whether it was solo
  or multiplayer was not reported.