Case study 1 · High on Life · Unreal Engine 4.27, UE4SS Lua
From 19 crashes in two days to zero
The problem
Four published High on Life mods crashed the game at random: 19 crash files in two days, each with a different signature. Access violations, aborts inside the modding framework, crashes in hook parameters. No single obvious bug.
The investigation
The game ships its debug symbols (PDB), so every crash dump could be read with exact function names in WinDbg/cdb.
One stack ran from the engine's parallel animation evaluation straight into mod code. That should have been impossible: the mods only ever asked the framework to run their work "on the game thread".
The finding: in this framework build, queued "game thread" work is drained from a ProcessEvent hook on whatever thread calls ProcessEvent, including animation worker threads. Mods that polled every 25 to 50 ms through that queue were racing the real game thread. Every crash signature followed from that one cause.
The fix
A coding standard: no background loops, no timers, no queued work. All work runs inside functions the game itself calls on its game thread (the weapon tick, each shot, load and respawn), with simple parameters only.
Each mod rebuilt on that rule, reusing the developers' own cheat logic where possible. Infinite suit fuel, for example, is exactly the console variable the game's own InfiniteFuel cheat sets, found in the symbols.
An offline test harness that fakes the game's hooks and threads. The old builds fail its scenarios; the new ones pass.
Result. No new crash files after the rebuild, and all four mods confirmed working in the game. The rule became the standard for every Unreal mod since, in High on Life, Grounded and Palworld.
Case study 2 · Grounded · Unreal Engine 4, UE4SS Lua
"All Gold Cards": three hidden framework limits
The goal
Give the player all 74 gold creature cards in Grounded, and nothing else. The first version used the game's "unlock all key items" cheat, which also unlocked story items and broke a player's storyline. The rebuild had to be surgical.
What happened, test by test
Objects that die with their callback. Reading the bestiary table worked, but objects handed to the table-iteration callback were invalid afterwards. Fix: keep only the row names and look the objects up again.
Struct arguments can't hold objects. Every call to the game's add-key-item and has-key-item functions failed with "Value must be UObject or nil". Disassembling the modding framework (UE4SS) showed that its struct-argument packer checks the wrong Lua stack slot, so any struct field holding an object fails. Fix: use the game's other entry point, which takes a plain item object, and set its data with property writes.
Reading struct-array entries crashes. Checking which cards the player already had crashed the game inside the framework. Reading the game's own add function in the executable showed that it already skips duplicates, so the mod only needed the list's size.
Cards not showing. Most cards were stored but invisible. Reading the Data screen's check (IsRareDataUnlocked) and testing live showed that the game only reveals a card once you have discovered that creature, except for creatures that can't be scanned, which it reveals at once. The mod was correct; the mod page now explains it.
Result. Released as All Gold Cards 2.0.7 and confirmed by the player who reported the storyline problem. The three framework limits are now documented rules for every new mod.
Case study 3 · Grounded · Unreal Engine 4, UE4SS Lua
"Free Craft": why free crafting only half-worked
The goal
Crafting without ingredients on an existing Survival world. Grounded offers free crafting only in Custom worlds, and an existing save can't be switched to Custom.
Two approaches, two different symptoms
Version 0.1 forced the crafting menu's checks to "yes". The Craft button worked and the game said "crafted", but nothing arrived.
Version 0.2 switched the game's own rule ("recipes need ingredients") off. The game confirmed the rule was off, but the Craft button stayed grey.
First finding: two halves, from the executable
With a call graph built from the shipped executable, every function that reads the rule was traced up to the named game functions above it:
The game's own crafting (CanCraftRecipe, and RemoveProxyItemsForRecipe, which takes the ingredients) honours the rule.
The crafting menu's helpers (CanCraftRecipe, CanCraftRecipeData and GetMaxCraftable in the UI statics) decide from the player's items alone and never read the rule.
So each earlier version had fixed exactly the half the other one missed. Version 0.3.0 combined them: keep the rule change, and answer "yes" in the three menu helpers only after the game confirms the rule is off, so a pressable button always means a real, free craft.
Second finding: the world has its own copy
In the in-game test, 0.3.0 still showed "crafted" without an item. The log explained why: 0.3.0 had switched the rule off on the settings class's default object (the template), but a loaded world reads its own copy of the settings, and on that copy the rule was still on. The real craft, which runs on the server side of the game, asks the world's copy.
Version 0.4.0 sets the rule on the world's own settings copy right before every craft request, hooked on the game's own craft functions, and logs what the game answers.
Result. Free Craft 0.4.0 passed the in-game test and was released. The same lesson made the follow-up quick: Free Build uses the game's own "auto-complete buildings" switch (the one Creative mode turns on) on the world's settings copy, and passed its first in-game test.
