Elemental Fracture 6.2.1 – Patch Notes

A stability release. No new features, no balance changes, nothing to relearn. 6.2.0 shipped a lot of new machinery at once and a few things came back with it, so this is a cleanup pass that stabilizes the game.

The random menu crash

This update fixes the “Fatal error” while just clicking around the main menu. Thanks to your contributions with crash dumps, we were able to trace it back to the garbage collector, walking the object graph on a background thread, following a pointer to something that had already been destroyed. Six crash reports, six identical register states, all faulting on the exact same field: the field was the header bar’s FRIENDS tab button.

Microstutter in online lobbies and matches

This issue arose when we re-implemented Clash. The Clash HUD needs to know whether you’re in a Clash match. The way it asked that question was to search the game’s entire object table, which on a live server means several hundred thousand objects, each one type-checked through a Windows call that Wine turns into a syscall. One of those searches costs about a frame of work. It ran when the answer was “no.” Which is every Battle Royale, Dominion and TDM match. From a per-frame hook. Across the roughly 27 HUD widgets that tick every frame. Clash itself was fine, because there the answer was “yes” and it took the cached path. Everything else paid for it.

Same shape of problem in the shared object-lookup helper: when it found nothing, it re-searched on every single call with no throttle at all. Not finding something is the normal case, not a rare one. No local player controller while you’re sitting in the menu, no Clash components in a BR match. Now a failed search can happen at most once every quarter second, and a successful one still costs no search at all.

Last one: the Clash HUD was building a fresh text object for the alive count, the score and the timer on every tick of every HUD widget. That’s a constant drip of allocations and the collector churn that follows it, which you feel as frame-time jitter. Those writes now only happen when the value actually changes.

Cosmetics you don’t own anymore

Equipping and owning were tracked separately, which meant taking an item away from an account never actually took it off the character. People were walking around in staff-only cosmetics, and worse, in items whose art doesn’t exist in the client at all, which is its own crash. Equipped is now held to the same standard as owned. If your account doesn’t have it, it comes off.

In this patch, there’s a one-time sweep on this update that resets everyone’s equipped cosmetics, so accounts that piled up bad equips before this existed start clean. You’ll need to re-pick your look once. Sorry about that, it’s the only way to be sure.

While fixing this we found that seven of the game’s own starter cosmetics were missing from our catalog entirely, so nothing was granting them: the default run and drop trails, the Breaker badge, the wave triumph, and the yes/no/wave emotes. Everyone owns those now, properly.

Also in this build

• The Clash HUD’s game state lookup self-checks a few times a second instead of trusting a cached pointer forever, so a state recycled into the same memory can’t go unnoticed.
• Fixed an off-by-one in how we walk the engine’s object table. Past the first 64K objects, every lookup was landing on the neighbor, so scans were visiting some objects twice and never seeing others.
• The cached fallback icon we substitute when a cosmetic’s icon fails to resolve is now pinned so the collector can’t reclaim it, and re-checked before every use. It was quietly a second source of the same crash it existed to prevent.