Skip to content

fix: prevent BUTRInputManager orphan crash on game v1.4.4+ - #140

Open
w1r3dh4ck3r wants to merge 1 commit into
BUTR:devfrom
w1r3dh4ck3r:fix/v1-4-4-input-manager-cleanup
Open

fix: prevent BUTRInputManager orphan crash on game v1.4.4+#140
w1r3dh4ck3r wants to merge 1 commit into
BUTR:devfrom
w1r3dh4ck3r:fix/v1-4-4-input-manager-cleanup

Conversation

@w1r3dh4ck3r

Copy link
Copy Markdown

Problem

When BLSE v1.6.5 runs on game v1.4.4 (build 114449), it falls back to the v1.4.0 LauncherEx binary (the highest compiled version below 1.4.4, selected by ModuleInitializer.ResolveLauncherExAssemblies).

In that binary, LauncherUIPatch.Enable() applies patches in this order:

  1. LauncherUI.Initializesucceeds (res1 = true)
  2. LauncherUI.Updatesucceeds (res2 = true) — installs BUTRInputManager
  3. LauncherUI.AdditionalArgsfails (res3 = false) — AdditionalArgs was removed or renamed in v1.4.4

Enable() returns false after step 3, but Manager.Enable() ignores the return value. The result: BUTRInputManager is installed by the Update postfix, but the AdditionalArgs postfix (which restores the original input manager) never fires.

When the user clicks Play and the game starts in the same process, the native engine initializes its input subsystem and immediately crashes inside GauntletVideoPlaybackScreen::HandleResume because BUTRInputManager is still the active Input.InputManager.

Observed crash point from rgl_log_*.txt:

TaleWorlds.MountAndBlade.GauntletUI.GauntletVideoPlaybackScreen::HandleInitialize
TaleWorlds.MountAndBlade.GauntletUI.GauntletVideoPlaybackScreen::HandleActivate
TaleWorlds.MountAndBlade.GauntletUI.GauntletVideoPlaybackScreen::HandleResume
[crash — no further output]

Confirmed via watchdog_log_*.txt: game version is v1.4.4 build 114449, GPU AMD Radeon RX 9070 XT. Vanilla (no BLSE) and BLSE with only base modules both work correctly.

Fix

Reorder the patch calls in LauncherUIPatch.Enable() so that AdditionalArgs (the cleanup) is patched before Update (the install). If AdditionalArgs is not found in the current game version, Enable() returns false before BUTRInputManager is ever installed. The game then starts with its original input manager intact.

The Initialize postfix (launcher UI setup) is still applied regardless — it does not interact with the input manager.

Behaviour change

Scenario Before After
Game version with AdditionalArgs (e.g. v1.4.0, v1.3.x) Full input enhancement Unchanged
Game version without AdditionalArgs (e.g. v1.4.4) Crash on game start Launcher keyboard input silently disabled; game starts cleanly

Long-term note

The correct long-term fix is to add a GameAPIVersion entry for v1.4.2+ in Bannerlord.BLSE.Shared.csproj once Bannerlord.ReferenceAssemblies.Core v1.4.4 is published, so a properly targeted LauncherEx binary exists for v1.4.4. This PR is the defensive fallback that prevents the crash in the meantime.

When BLSE runs on game versions newer than any compiled LauncherEx
binary (e.g. v1.4.4 falls back to the v1.4.0 binary), the
LauncherUI.AdditionalArgs property may no longer exist. The old patch
order was: Initialize → Update → AdditionalArgs. If AdditionalArgs
failed, Enable() returned false — but the Update postfix was already
applied, leaving BUTRInputManager installed with no cleanup path. On the
next frame the game loaded, this orphaned input manager caused a native
crash at GauntletVideoPlaybackScreen::HandleResume.

Fix: patch AdditionalArgs (cleanup) before Update (install). If the
cleanup target is missing, we bail before ever installing BUTRInputManager,
so the game starts with its original input manager intact.
@Aragas
Aragas changed the base branch from master to dev May 16, 2026 12:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant