Few notes:

• the game uses Battleye Anti-Cheat - it's seemingly mandatory even if you just want to play single player. No idea if there is a launch parameter that disables it.

You can rename two .exe files in /Mount & Blade II Bannerlord/bin/Win64_Shipping_Client/

• rename "TaleWorlds.MountAndBlade.Launcher.exe" to "TaleWorlds.MountAndBlade.Launcher.exe_backup" (or something similar - it's just not allowed to keep its original name)

• rename "Bannerlord.exe" to "TaleWorlds.MountAndBlade.Launcher.exe"

to at least make the game start, see the splash screens and then I get to the point I have to interact with the game for the first time (change brightness settings) at which point my CPU and GPU go absolute haywire and I can't interact with the game at all.

I'm able to confirm that bypassing the launcher (by moving TaleWorlds.MountAndBlade.Launcher.exe out of the way and replacing it with a copy of Bannerlord.exe) does get it to at least the brightness calibration screen (or as far as the main menu if I set brightness_calibrated = 1 in $COMPATDATA/261550/pfx/drive_c/users/steamuser/My Documents/Mount and Blade II Bannerlord/Configs/engine_config.txt).

However, it looks like there's a bug with mouse input; the cursor moves and is visible, but menu options don't highlight when moving over them and the game doesn't respond to clicks (and naturally there's no keyboard navigation...). Problem persists with every permutation of V-sync, launching in a virtual desktop, disabling the Steam Overlay, etc.

Of particular interest in steam-261550.log is the spamming of fixme:win:GetMouseMovePointsEx (24 0x3c87f298 0x3c87f2b0 64 1) stub. Possibly related to Wine bug 36873?

Further discussion on TaleWorlds' forum: https://forums.taleworlds.com/index.php?threads/linux.385761/page-2 and https://forums.taleworlds.com/index.php?threads/b0-8-9-mouse-clicks-not-registered-on-linux.395650/

EDIT: tried plugging in a controller, and that allowed me to actually navigate through the menu. Gonna see how far I can get, but... progress!

For me game was still crashing on launch after running Bannerlord.exe instead of TaleWorlds.MountAndBlade.Launcher.exe. Using protontricks I've installed dotnet4.8 and vcrun2015 – the game still crashes but at least I'm able to admire the game loading screen.

Can confirm that I'm having the same problem with mouse inputs, on Manjaro with Proton 5.0-5. I was in the closed beta and the game was working fine before the very last update, so I am pretty confident that the rest of the game should be working once we manage to fix this navigation issue.

So after fumbling around getting a character created entirely via a Logitech gamepad, it looks like I've hit another roadblock in the form of a hard crash at the loading screen right after character creation (relevant entry from steam-261550.log: wine: Call from 0x7b00fc3e to unimplemented function api-ms-win-crt-private-l1-1 -0.dll._o___stdio_common_vswprintf, aborting). This persists even after running protontricks 261550 vcrun2015 and protontricks 261550 vcrun2017.

Just a quick google as I can't actually test it right now myself (still downloading) but a similar issue seemingly plagued the BNet Launcher at some point and was fixed by adding ucrtbase and the api-msi-win etc etc dll as overrides via winecfg.

Custom battles do work when you navigate to them using the gamepad, and when in the actual game you're able to use the mouse to fight.

However the game for me looked incredibly washed out and bright while playing and changing settings crashes the game half the time, along with setting everything to low crashes the game.
Here's a log for the crash when saving settings.
steam-261550.log

Edit: changing settings down from high caused customs to stop working, so avoid doing that.

Right, I did some reading, research, downloaded the game three times down, and some more research, and I believe I´ve figured it out.

Bannerlord is using Battleye, which is a Kernel Anti-Cheat software. Since Proton-Wine instance isn´t the base Linux Kernel, but the Windows Kernel, Battleye is unable to intercept the mouse input straight from the usb-port to verify that its the real deal, and then let it into the game, or is mistaking Wine´s mouse-input as an artificial program-based mouse input, which means the Anti-Cheat system kicks in.

I do recall reading somewhere that Battleye does not play nice with Linux at all, but that comment was from... 3 years ago? So I don´t actually know the current state of the anti-cheat software. So the options are, I think, to ask TaleWorlds to configure Battleye to play nice with Proton, disable it for Proton until a proper Linux version can be made, then re-enable it there, (they are using Mono for something. Looked like the launcher?) Wait until the game is properly released because chances are that they will mooost likely hold off on doing multiple OS support until later in Early Access so it´s 10 times easier to dish out updates... Or figure out how to let a Window Executable Battleye go straight into the Linux-based Kernel so it can scan everything it wants and let us do inputs into the game without trigger the anti-cheat...

So I guess we´re waiting a bit longer for Bannerlord.

Right, I did some reading, research, downloaded the game three times down, and some more research, and I believe I´ve figured it out.

Bannerlord is using Battleye, which is a Kernel Anti-Cheat software. Since Proton-Wine instance isn´t the base Linux Kernel, but the Windows Kernel, Battleye is unable to intercept the mouse input straight from the usb-port to verify that its the real deal, and then let it into the game, or is mistaking Wine´s mouse-input as an artificial program-based mouse input, which means the Anti-Cheat system kicks in.

I do recall reading somewhere that Battleye does not play nice with Linux at all, but that comment was from... 3 years ago? So I don´t actually know the current state of the anti-cheat software. So the options are, I think, to ask TaleWorlds to configure Battleye to play nice with Proton, disable it for Proton until a proper Linux version can be made, then re-enable it there, (they are using Mono for something. Looked like the launcher?) Wait until the game is properly released because chances are that they will mooost likely hold off on doing multiple OS support until later in Early Access so it´s 10 times easier to dish out updates... Or figure out how to let a Window Executable Battleye go straight into the Linux-based Kernel so it can scan everything it wants and let us do inputs into the game without trigger the anti-cheat...

So I guess we´re waiting a bit longer for Bannerlord.

I'm not buying this. If Battleye is causing the cursor issues then why wouldn't we see the same issue when using a gamepad?

Battleye is not the issue, it is an optional install and only required for multiplayer.

Battleye is not the issue, it is an optional install and only required for multiplayer.

To expand on tkamat's post, I was also in the closed beta and the game still worked for a few patches after Battleeye was patched into the beta. From what I understand they made it optional at the time, you could just ignore cancel the battle eye install on first run and it wouldnt kick you from games for not using it.

About two weeks ago there was a patch that broke a bunch of windows users ability to play as well, it apparently had something to do with having a controller or joystick plugged in while trying to play with keyboard/mouse. They hotfixed the issue a couple of days later but all the Linux users on the forum reported the no mouse input happening whether or not a controller was plugged in even after the update.

We were speculating on the forum that it might be an issue with steamplay presenting a virtual controller to the game at a driver level, but never confirmed this. As for the crash on starting a campaign we never got that far since it was a multiplayer beta.

Battleye is not the issue, it is an optional install and only required for multiplayer.

To expand on tkamat's post, I was also in the closed beta and the game still worked for a few patches after Battleeye was patched into the beta. From what I understand they made it optional at the time, you could just ignore cancel the battle eye install on first run and it wouldnt kick you from games for not using it.

About two weeks ago there was a patch that broke a bunch of windows users ability to play as well, it apparently had something to do with having a controller or joystick plugged in while trying to play with keyboard/mouse. They hotfixed the issue a couple of days later but all the Linux users on the forum reported the no mouse input happening whether or not a controller was plugged in even after the update.

We were speculating on the forum that it might be an issue with steamplay presenting a virtual controller to the game at a driver level, but never confirmed this. As for the crash on starting a campaign we never got that far since it was a multiplayer beta.

Did the game run well on Linux before battleye? I was on Windows back during the beta so never got to try it through proton.

Battleye is not the issue, it is an optional install and only required for multiplayer.

To expand on tkamat's post, I was also in the closed beta and the game still worked for a few patches after Battleeye was patched into the beta. From what I understand they made it optional at the time, you could just ignore cancel the battle eye install on first run and it wouldnt kick you from games for not using it.
About two weeks ago there was a patch that broke a bunch of windows users ability to play as well, it apparently had something to do with having a controller or joystick plugged in while trying to play with keyboard/mouse. They hotfixed the issue a couple of days later but all the Linux users on the forum reported the no mouse input happening whether or not a controller was plugged in even after the update.
We were speculating on the forum that it might be an issue with steamplay presenting a virtual controller to the game at a driver level, but never confirmed this. As for the crash on starting a campaign we never got that far since it was a multiplayer beta.

Did the game run well on Linux before battleye? I was on Windows back during the beta so never got to try it through proton.

It started working on Linux around December, crashed every once in a while but performance was acceptable after it finished compiling shaders for each map. I was also on a relatively underpowered graphics card (rx 480) at the time so I think performance-wise the game will be ok on Linux if we can get a small assist from taleworlds on fixing these issues. We did get a dev response about the mouse issue we were facing so it seems they are at the very least not hostile to considering Linux users & proton.

What a day to not be able to find my controller! I did actually get something working though! I followed the renames as above and then attempted to hook up my switch Joy-Cons using this handy driver.

When the joy-cons are recognized as a pro controller, I am able to click on things with the mouse after using the left stick to position the cursor. Mouse aim and clicking works fine in my quick test battles, so the problem may be menu related. Not sure if this will work with other controllers, or if it has something to do with the way that driver is implemented.

Just a quick google as I can't actually test it right now myself (still downloading) but a similar issue seemingly plagued the BNet Launcher at some point and was fixed by adding ucrtbase and the api-msi-win etc etc dll as overrides via winecfg.

Adding those as overrides still resulted in a crash, but I was able to brute-force it by following the steps from a similar issue re: Age of Empires 2: Definitive Edition:

cd /home/$USER/.steam/steam/steamapps/compatdata/261550/pfx/drive_c/windows/system32/
wget "https://aka.ms/vs/16/release/vc_redist.x64.exe"
cabextract vc_redist.x64.exe
cabextract a10

Which got me a lot further:

Mouse continues to be unusable for dialogs and the pause menu (you can "Click to continue" there, so it obviously recognizes the mouse clicks, but doesn't know whether or not the mouse is actually over something unless you're moving the cursor with the controller). Works fine for movement and combat. Got through a couple of the tutorial objectives before I crashed again (this time because of an eventfd: Too many open files; gonna reboot with a pumped up ulimit -Hn and try again).

EDIT re: BattlEye:

Bannerlord is using Battleye, which is a Kernel Anti-Cheat software. Since Proton-Wine instance isn´t the base Linux Kernel, but the Windows Kernel, Battleye is unable to intercept the mouse input straight from the usb-port to verify that its the real deal, and then let it into the game, or is mistaking Wine´s mouse-input as an artificial program-based mouse input, which means the Anti-Cheat system kicks in.

This seems unlikely. If it was anti-cheat-related, I'd expect the opposite of current symptoms (i.e. mouse working fine in menus/dialogs, but not for movement/combat). I would also expect keyboards and controllers to be similarly affected (which doesn't appear to be the case).

BattlEye's certainly going to put a damper on things for multiplayer, but it should be entirely unnecessary for singleplayer (and indeed, other BattlEye games with singleplayer modes work reasonably well under Proton, e.g. Conan: Exiles).

@YellowApple Could you see if the following patch fixes the crash without vcredist? (i.e. set ucrtbase and api-ms-win-crt-private-l1-1-0 to builtin when testing)

https://gist.github.com/qsniyg/4ba247c7398e3a1926988e3f6ca252ce

Would be cool if it could be fixed upstream without needing overrides :) I don't have the game at the moment, so I can't test.

@YellowApple I have tried reproducing your solution, but it is sadly not working for me, and campaign is crashing after character creation. Log files still seem to point to api-ms-win-crt-private-l1-1-0.dll._o___stdio_common_vswprintf as the issue. Did you do any other steps, like reinstalling vcrun-2017 or something else?

So bumping up my ulimit -Hn helped, and I was able to get as far as the main map, but noticed that any attempt to save the game will cause the game to temporarily freeze for a few minutes while pegging every core/thread on my CPU (certain sounds do continue to play in the background, though). I suspect there's an autosave function that's triggering similar freezes, too (happened after cheating in some inventory, and happened again when idling for awhile).

Also, it seems pop-up dialogs will cause the joystick-driven mouse cursor to disappear (haven't determined whether or not that always happens; with enough wiggling I did manage to get the "OK" button to briefly highlight, so I think the cursor's just invisible).

I can also confirm that the mouse buttons and scroll wheel fully work in the menus/dialogs; you just gotta use the controller to move the cursor to the thing you want to click or scroll. So whatever's causing that bug has purely to do with where the game thinks the mouse is pointing.

@YellowApple Could you see if the following patch fixes the crash without vcredist? (i.e. set ucrtbase and api-ms-win-crt-private-l1-1-0 to builtin when testing)

Will do @qsniyg (as soon as I get Vagrant to cooperate). Are these functions all implemented but stubbed out or something?

@YellowApple I have tried reproducing your solution, but it is sadly not working for me, and campaign is crashing after character creation. Log files still seem to point to api-ms-win-crt-private-l1-1-0.dll._o___stdio_common_vswprintf as the issue. Did you do any other steps, like reinstalling vcrun-2017 or something else?

@tkamat: Exact steps I did (to the best of my recollection):

• protontricks 261550 vcrun2015 (and ran the game; crashed)
• protontricks 261550 vcrun2017 (and ran the game; crashed)
• Added native overrides for ucrtbase and api-ms-win-crt-private-l1-1-0 via winecfg (and ran the game; crashed)
• Did the whole "smack a VC redist EXE with cabextract" thing (and ran the game; worked)

@YellowApple maybe it is a blind shot – but can you try installing dotnet 4.8 via protontricks as well? I was able to use mouse in the splash/loading screen.

@YellowApple

Will do @qsniyg (as soon as I get Vagrant to cooperate). Are these functions all implemented but stubbed out or something?

They're implemented, but windows uses these api-ms-win-... dlls which basically just import from other dlls (advapi32, kernel32, ucrtbase, etc.). I guess wine adds in the functions to those dlls in an as-needed basis in order to make sure they're correct.

It's possible the game will crash again on some other unimplemented function from one of those api dlls. Feel free to either add them in yourself or let me know. Hopefully after a bit of iteration, we'll be able to find which functions are needed, then send it in upstream to wine :)

@Yarwin @tkamat I have a hunch the protontricks installation of dotnet4.8 may be causing your issue (though it did seem to let me use the intended launcher, mouse had to be controlled via controller in the actual game). I installed that as well and could not get @YellowApple's solution to work.
I ended up deleting $COMPATDATA/2615501 altogether and went through the process of verifying files for both Proton 5.0 and Bannerlord. After that, the cabextract method worked (don't forget you'll have to edit $COMPATDATA/261550/pfx/drive_c/users/steamuser/My Documents/Mount and Blade II Bannerlord/Configs/engine_config.txt again to set brightness_calibrated = 1). This may solve your problem whatever the cause.

+1 for the hang being caused by saving. I also was able to finish the tutorial until a hang caused me to close it, now a new folder has appeared at $COMPATDATA/261550/pfx/drive_c/users/steamuser/My Documents/Mount and Blade II Bannerlord/Game Saves.

@YellowApple maybe it is a blind shot – but can you try installing dotnet 4.8 via protontricks as well? I was able to use mouse in the splash/loading screen.

Doesn't seem to have had any effect for me.

+1 for the hang being caused by saving. I also was able to finish the tutorial until a hang caused me to close it, now a new folder has appeared at $COMPATDATA/261550/pfx/drive_c/users/steamuser/My Documents/Mount and Blade II Bannerlord/Game Saves.

Yeah, I encountered that post-tutorial hang, too. Kinda kicking myself for not just waiting it out and seeing if it would've unborked itself eventually like these other save-hangs seem to do.

@ChemiKyle thanks for the tip, I just finished the tutorial but now I am stuck at the notification screen since my mouse cursor vanished. Spent a couple minutes fiddling with the joystick to see if its invisible, but its not working lol. I feel like the mouse issue shouldn't be too hard to fix in general considering controller input has been working fine. My steam logs have a warning about GetMouseMovePointsEx spammed a bunch of times, but as far as I can tell that function is already implemented in wine.

@YellowApple @tkamat I've created a hacky patch for GetMouseMovePointsEx, I haven't tested it so it could be wrong, but would you mind giving it a shot?

https://gist.github.com/qsniyg/4ba247c7398e3a1926988e3f6ca252ce#file-getmousemovepointsex-patch

It's written against wine-staging, so you may need to manually apply it.

@qsniyg Just tried a fresh prefix with both of your patches; no dice with either. Mouse input is still busted, and still crashes due to that same unimplemented function. Logs from the patched run.

EDIT: ah, looks like the patch was for vfwprintf whereas the crash is due to vswprintf. Lemme see if I can fix that up...

@YellowApple Darn, well it was at least worth a shot :) I'm quite blind as to what the issue might be, I don't own the game yet so I cannot test either. That being said, a +rawinput,+win,+cursor,+dinput,+xinput log would probably give a lot of insight into the issue (although you may need to .gz compress the log... :)

Anyways, here's the vswprintf patch: https://gist.github.com/qsniyg/4ba247c7398e3a1926988e3f6ca252ce#file-vswprintf-patch

Hot damn, that did the trick (though I patched it as _o___stdio_common_vswprintf(int64 wstr long wstr ptr ptr), since I was trying to match Microsoft's docs as close as possible; I guess a pointer's a pointer, but who knows with Wine, lol).

I'll try to get some logs with those flags so that we can hopefully get some headway on this mouse issue.

Good to know! Sent them in :)

https://source.winehq.org/patches/data/182375
https://source.winehq.org/patches/data/182376

I don't know why wine did it that way either, I just copied how they declared vswprintf from an earlier declaration in the file :)

Hi, I've added the app to the wine AppDB: https://appdb.winehq.org/objectManager.php?sClass=version&iId=38834&iTestingId=107964

@qsniyg Do you want to link the bugs to the application or should I?

@tomhobson Go right ahead! (I'm not in any way part of the wine development team, I just write patches and embarrass myself on the mailing list due to always getting something wrong haha)

@tomhobson Go right ahead! (I'm not in any way part of the wine development team, I just write patches and embarrass myself on the mailing list due to always getting something wrong haha)

If you write patches, sounds like you're part of the wine development team :)

Ok I've linked bug: https://bugs.winehq.org/show_bug.cgi?id=36873

I'm not sure how/if you link the patches back to the bug. But when they get merged we can tackle the next.

Is there any bugs I've missed?

So the "state of the art" with all the patches here is still essentially requiring a gamepad of some kind to control the menus. Is that right? Just checking that the mouse issue has never been overcome even experimentally.

@allquixotic: that is correct.

Hi guys! I'm not playing on Linux nor Wine, but I had a similar issue: gamepad was ok for mouse cursor but not real mouse.

I play on Shadow (distant computer) and when I set "capture cursor" on, the issue was just gone. I don't know how Wine works exactly, but maybe if this option is availaible too, you can try it.

Cheers

Hi guys! I'm not playing on Linux nor Wine, but I had a similar issue: gamepad was ok for mouse cursor but not real mouse.

I play on Shadow (distant computer) and when I set "capture cursor" on, the issue was just gone. I don't know how Wine works exactly, but maybe if this option is availaible too, you can try it.

Cheers

Thanks for the info. Is this capture cursor setting within bannerlord?

Thanks for the info. Is this capture cursor setting within bannerlord?

I believe he means in the streaming solution. Might be worth a try to test if allowing Wine to take exclusive control of the mouse might work.

The only settings related to the mouse in engine_config.txt appear to be the following:

invert_mouse = 0
mouse_sensitivity_coefficient = 0.5000
control_mouse_movement_y_scale = 1.5000
control_mouse_movement_max_accumulation = 40.0000
control_mouse_movement_accumulation_decay_speed = 100.0000

Unsurprisingly, modifying them does not appear to help with the issue.

Thanks for the info. Is this capture cursor setting within bannerlord?

I believe he means in the streaming solution. Might be worth a try to test if allowing Wine to take exclusive control of the mouse might work.

yep i meant exactly that.

@ElCaconym sorry if it doesn't help :(

If someone is available to test (I'm still working)

I've found something that could be useful here:
https://askubuntu.com/questions/968252/ubuntu-17-10-mouse-problem-in-wine

If someone is available to test (I'm still working)
I've found something that could be useful here:
https://askubuntu.com/questions/968252/ubuntu-17-10-mouse-problem-in-wine

That was pretty much the idea I just got. Enabling this option could potentially help,
Automatically capture the mouse in full-screen windows
as I remember other games having at least comparable issues with mouse cursors in Wine.

@tomhobson: already tried that; no luck.

The "fixme:win:GetMouseMovePointsEx" messages simply denote the stub in wine for this function; I doubt they're even related to the clicks-not-registering issue; and indeed a Taleswords dev said here:

We started using GetMouseMovePointsEx for some mouse movement inputs. Maybe that's not implemented in WINE? It's not used for mouse clicks though.

Running with +rawinput,+win,+cursor,+dinput,+xinput doesn't appear to produce any enlightening logs, at least at first glance; notably, upon clicking, you get the usual:

0014:trace:cursor:X11DRV_RawButtonEvent raw button 0 (raw: 1) up
0014:trace:cursor:X11DRV_RawButtonEvent raw button 0 (raw: 1) down

(depending on whether you use the left or right click)

@ElCaconym Could you share the log? The full log might contain more information that might help to debug the issue :)

Of course; attached. WINEDEBUG: +err,+fixme,+rawinput,+win,+cursor,+dinput,+xinput.

I'm not using proton, mind you: it's wine-staging 5.4 with all staging patches, no custom patches (not even the one referenced above - I wanted to fix the mouse issue before applying the vfwprintf/vswprintf patch), and dxvk 1.6. Winetricks: vcrun2010, vcrun2015, and dotnet48 (only the last one may be necessary).

I launched the game, and in order not to pollute the logs I avoided moving the mouse until I got to the gamma selection screen. I then moved the cursor over the "Accept" button, and left-clicked. Then, I killed the game from another term.

The file:

stderr_bannerlord.log.gz

@ElCaconym Maybe they're checking the mouse is on the screen.

This function is being used on the menu. I'd be surprised if this wasn't related to the menu issue.

Are you running multi monitor or single?

Single monitor.

@ElCaconym Huh interesting, it's also clipping the cursor every frame, like in AoT2. I wonder if this patch would help? https://source.winehq.org/patches/data/181257 It was meant to fix an issue with the mouse cursor's movement being improperly registered, not clicks, so it may be useless in this case, but who knows, it shouldn't hurt though :)

0014:trace:cursor:X11DRV_RawButtonEvent raw button 0 (raw: 1) down
0014:trace:cursor:X11DRV_EnterNotify hwnd 0x10020/7000008 pos 1116,1057 detail 1
004b:trace:cursor:X11DRV_EnterNotify hwnd 0x30052/a600001 pos 1116,1057 detail 1
004b:trace:cursor:X11DRV_ButtonPress hwnd 0x30052/a600001 button 0 pos 1116,1057
004b:trace:cursor:clip_fullscreen_window win 0x30052 clipping fullscreen
004b:trace:win:WIN_CreateWindowEx (null) L"Message" ex=00000000 style=00000000 0,0 0x0 parent=0xfffffffffffffffd menu=(nil) inst=0x140000000 params=(nil)
004b:trace:win:dump_window_styles style:
004b:trace:win:dump_window_styles exstyle:
004b:trace:win:GetWindowRect hwnd 0x20094 (0,0)-(0,0)
004b:trace:win:GetWindowRect hwnd 0x20094 (0,0)-(0,0)
004b:trace:win:WINPOS_GetMinMaxInfo 106 106 / -3 -3 / 1932 1092 / 112 27
004b:trace:win:GetWindowRect hwnd 0x20094 (0,0)-(112,27)
004b:trace:win:invalidate_dce 0x20094 parent 0x10026 (0,0)-(112,27) ((0,0)-(0,0))
004b:trace:win:invalidate_dce 0x70058: hwnd 0x30052 dcx 00000012 Cache 
004b:trace:win:invalidate_dce 0x1005a: hwnd 0x30052 dcx 00000013 Cache 
004b:trace:win:invalidate_dce 0x12004c: hwnd 0x10020 dcx 00000013 Cache 
004b:trace:win:invalidate_dce 0x33004a: hwnd 0x10020 dcx 00000013 Cache InUse
004b:trace:win:invalidate_dce 0x40041: hwnd 0x10020 dcx 00000013 Cache InUse
004b:trace:win:set_window_pos win 0x20094 surface (nil) -> (nil)
004b:trace:win:WIN_CreateWindowEx hwnd 0x20094 cs 0,0 0x0 (0,0)-(112,27)
004b:trace:win:GetWindowRect hwnd 0x20094 (0,0)-(112,27)
004b:trace:win:invalidate_dce 0x20094 parent 0x10026 (0,0)-(112,27) ((0,0)-(112,27))
004b:trace:win:invalidate_dce 0x70058: hwnd 0x30052 dcx 00000012 Cache 
004b:trace:win:invalidate_dce 0x1005a: hwnd 0x30052 dcx 00000013 Cache 
004b:trace:win:invalidate_dce 0x12004c: hwnd 0x10020 dcx 00000013 Cache 
004b:trace:win:invalidate_dce 0x33004a: hwnd 0x10020 dcx 00000013 Cache InUse
004b:trace:win:invalidate_dce 0x40041: hwnd 0x10020 dcx 00000013 Cache InUse
004b:trace:win:set_window_pos win 0x20094 surface (nil) -> (nil)
004b:trace:win:WIN_CreateWindowEx created window 0x20094
004b:trace:cursor:X11DRV_XInput2_Enable XInput2 v2.1 available
004b:trace:cursor:grab_clipping_window clipping to (0,0)-(1920,1080) win 7000001
0014:trace:cursor:clip_cursor_notify clip hwnd changed from (nil) to 0x20094
004b:trace:cursor:X11DRV_EnterNotify hwnd 0x30052/a600001 pos 1116,1057 detail 2
004b:trace:cursor:X11DRV_EnterNotify pos 1116,1057 old serial 24052, ignoring
004b:trace:win:WINPOS_WindowFromPoint scope 0x10020 (1116,1057) returning 0x30052
004b:trace:cursor:SetCursor 0x20070
004b:trace:win:WINPOS_WindowFromPoint scope 0x10020 (1116,1057) returning 0x30052
004b:trace:win:GetWindowRect hwnd 0x30052 (0,0)-(1920,1080)
004b:trace:cursor:ClipCursor Clipping to (null)

With that patch, the mouse clicks are still being ignored. And I still get the following sequence regularly, as well:

004b:trace:cursor:ClipCursor Clipping to (null)
004b:trace:cursor:ungrab_clipping_window no longer clipping

... which kinda made me doubt at first the patch was applied properly, so I recompiled wine fully from scratch (instead of using my previous compilation dir), and used another prefix (autotools install prefix I mean, not a wineprefix) just in case as well. The logs in question persist - though that may be expected ?

Ah okay, makes sense. It was a bit of a longshot haha.

Just in case, could you try with wine by itself, instead of wine-staging? Wine-staging has a rawinput patch that prevents clicking on games like Mass Effect: Andromeda. Alternatively you could just recompile wine-staging without the rawinput patch.

I'm just pulling things out of a hat here though, this might very well not work either.

Tried with wine without any staging patches: no changes. The logs change a bit of course; for example, I now get:

004c:trace:cursor:X11DRV_ButtonPress hwnd 0x3003a/a000001 button 2 pos 163,1067

... on mouse clicks instead of the previous X11DRV_RawButtonEvent lines, but beyond that, clicks are still ignored. This new test did not include your patch above, mind you (will try that now just in case).

I'm just pulling things out of a hat here though, this might very well not work either.

Of course - thanks for trying ! :-)

Could be that that patch actually might have an effect, as I believe the problem to not lie with detection of input but rather a problem with where the cursor is displayed and where the game believes the cursor is located.

If that's the case the game must think the pointer is locked in a very specific position (upper left corner maybe?) because the game doesn't appear to react at all no matter where you move the pointer. Some other games produce issues in wine where the pointer is displayed in a different place from where the game thinks it is, but there is still some correlation between where the game thinks it is and where it actually is; for example it might be shifted up by a few dozen pixels or something like that.

The "real" pointer appears to be where you left it when you last used the gamepad. If you switch from gamepad to mouse and back to gamepad, the cursor jumps to the location it was last when you used the gamepad.

If you move the cursor to a button with the gamepad, and then click with the mouse, does it register?

Tried with vanilla wine (no staging patches) _and_ qsniyg's patch and no change.

@Krypton-Nova: I can't personally test that, no gamepad. Though I imagine if there was a tool that could be used to simulate a virtual gamepad and map it to the mouse/keyboard (the reverse of something like this tool), it could work as a bypass of the mouse issue.

Edit: possibly MoltenGamepad ?

I've got a gamepad, and it worked for me. Just curious if it does for others :)

@Krypton-Nova Yeah I can confirm that moving the cursor with the gamepad and clicking with the mouse does in fact work. Seems to suggest that the problem is related to mouse tracking while moving the mouse, not the mouse clicks themselves.

The mouse alone also works while controlling the character. The game can detect mouse _motion_ but the cursor _position_ fails to update - a basic physics education suggests this problem is unsolvable. Steam has a built-in mouse capture I believe, I can try when I get off work if nobody gets to it.

Based on this, and with no gamepad plugged in, I've added logging of the second parameter passed by the game to GetMouseMovePointsEx (lppt) and it does update:

0084:fixme:win:GetMouseMovePointsEx GetMouseMovePointsEx lppt: [736][694]

And further below, while on the same screen:

0084:fixme:win:GetMouseMovePointsEx GetMouseMovePointsEx lppt: [1042][656]

This suggests that the game _does_ know where the cursor is at some level; makes it even weirder that moving the cursor with a gamepad works yet with a mouse it doesn't.

Maybe the GetMouseMovePointsEx function is used for mouse smoothing and needs a few more points returned for interpolation?
@qsniyg's hack only returned one point, someone should try with two or more points.

I can't even get the game to the main menu, just crashes when I hit the load screen.

I can't even get the game to the main menu, just crashes when I hit the load screen.

Same. I have tried all the different stock Proton releases and a couple GloriousEggroll releases.

I guess what I'm curious about is what exactly Bannerlord is doing with the result. My hunch is that - like with the OpenTk bug - the GetMouseMovePointsEx log spam is a red herring, and whatever code is handling the response (be it failure or actual returned points) is borking out silently. Hard to say without seeing the Bannerlord source code, though.

Maybe the GetMouseMovePointsEx function is used for mouse smoothing and needs a few more points returned for interpolation?
@qsniyg's hack only returned one point, someone should try with two or more points.

/***********************************************************************
 * GetMouseMovePointsEx [USER32]
 *
 * RETURNS
 *     Success: count of point set in the buffer
 *     Failure: -1
 */
int WINAPI GetMouseMovePointsEx(UINT size, LPMOUSEMOVEPOINT ptin, LPMOUSEMOVEPOINT ptout, int count, DWORD res) {

    if((size != sizeof(MOUSEMOVEPOINT)) || (count < 0) || (count > 64)) {
        SetLastError(ERROR_INVALID_PARAMETER);
        return -1;
    }

    if(!ptin || (!ptout && count)) {
        SetLastError(ERROR_NOACCESS);
        return -1;
    }

    FIXME("(%d %p %p %d %d) hack\n", size, ptin, ptout, count, res);
    FIXME("    Input: %d %d\n", ptin->x, ptin->y);

    if (count > 0) {
        POINT pos;
        GetCursorPos(&pos);

        ptout[0].x = pos.x;
        ptout[0].y = pos.y;
        ptout[0].time = GetTickCount();
        ptout[0].dwExtraInfo = 0;
        FIXME("    Output 0: %d %d\n", pos.x, pos.y);

        if (count > 1) {
            ptout[1].x = pos.x;
            ptout[1].y = pos.y;
            ptout[1].time = GetTickCount();
            ptout[1].dwExtraInfo = 0;
            FIXME("    Output 1: %d %d\n", pos.x, pos.y);
            return 2;
        }

        return 1;
    }

    SetLastError(ERROR_POINT_NOT_FOUND);
    return -1;
}

I can't even get the game to the main menu, just crashes when I hit the load screen.

@giantrat, @NovenTheHero: Can y'all add PROTON_LOG=1 to your launch options (e.g. PROTON_LOG=1 %command%) and provide the resulting ~/steam-261550.log (preferably as a link to e.g. Pastebin or Github Gist)?

Here ya go: Gist

@NovenTheHero delete your wine prefix and then follow these steps:

1. Rename Bannerlord.exe and Bannerlord_BE.exe to ManagedStarter.exe and ManagedStarter_BE.exe
2. run protontricks 261550 vcrun2015
3. run protontricks 261550 vcrun2017
4. Add native overrides for ucrtbase and api-ms-win-crt-private-l1-1-0 via winecfg
5. Execute these commands:
   cd /home/$USER/.steam/steam/steamapps/compatdata/261550/pfx/drive_c/windows/system32/
wget "https://aka.ms/vs/16/release/vc_redist.x64.exe"
cabextract vc_redist.x64.exe
cabextract a10
6. Start the game, and use a controller for menus. This should be enough to get you into custom battles and start the campaign, although you will probably run into some input issues and a freeze when saving.

@NovenTheHero If you're not already bypassing the launcher, try doing so (i.e. cd "~/.steam/steam/steamapps/common/Mount & Blade II Bannerlord/bin/Win64_Shipping_Client" && mv TaleWorlds.MountAndBlade.Launcher.exe TaleWorlds.MountAndBlade.Launcher.exe.old && cp Bannerlord.exe TaleWorlds.MountAndBlade.Launcher.exe). Alternately (if the launcher works for you and you want to use it), try just copying Bannerlord.exe to ManagedStarter.exe.

That ManagedStarter error is because TaleWorlds changed the name of the EXE without necessarily recompiling (if I understand right from when I read that on the forums).

steam-261550.log
here you go, thanks for that launch option by the way!

@giantrat Looks like you just need to either build a custom Wine/Proton with qsniyg's patch further up or else follow the native override steps (see @tkamat's comment above).

The newest update (e1.0.1) seems to have fixed the launcher problem for me. Unfortunately even after following all the steps mentioned, I can't even get the controller to work (I have a steam controller, not a typical one, could that be it?)

I also just tried my Steam Controller and it did not work. I think it is because the Steam Controller mimics a mouse.

well with tkamat's comment, the launcher now works, but I still crash after the taleworlds intro.

NVM, got to brightness calibration after running it again! Pog.

@NovenTheHero make sure your controllers left joystick is configured to joystick movement, NOT mouse movement. That should do the trick.

oh no mouse input on the brightness screen, feels bad. will try above scripts.

@tkamat assuming you're referring to the steam controller, all axes are configured as joystick movement, none are currently functioning... I've also tried every crazy axis possible on a HOTAS joystick with no result.

Adding a second identical point to GetMouseMovePointsEx's output had no effect. It's also apparent (consistent with @ElCaconym's findings) that the function's being called with valid mouse positions (i.e. the game clearly knows where the mouse is on some level); I even tried moving the mouse to each of the four corners of my screen and did indeed get results corresponding to my screen dimensions.

Wild Theory.

OpenTK, which I presume to be a library that TaleWorlds are using for the GUI, doesn´t support high DPI. This is a SLD2 issue, which is also used by winebus.sys, which is the HID interface inside the wine. My thinking is that the high default DPI is overloading SLD2/winebus with input and it isn´t able to catch up. So it´s possible that if we can change the mouse DPI in the config to something lower, then the game will pick up the mouse movement.

On an another note, running hid_test.exe (found in test.winehq.org) in cmd in the wine-prefix for Bannerlord shows that there is a Wine HID Mouse detected, and my wireless receiver, but nothing else. This could just be on my side due to udev rules, but I am wondering if, again, due to my inability to change my default mouse DPI (Damn you Asus! Make a linux config tool already!) Then, again, SLD2 is being overloaded with info. Or isn´t picking up on it.

int WINAPI GetMouseMovePointsEx(UINT size, LPMOUSEMOVEPOINT ptin, LPMOUSEMOVEPOINT ptout, int count, DWORD res) {

    if((size != sizeof(MOUSEMOVEPOINT)) || (count < 0) || (count > 64)) {
        SetLastError(ERROR_INVALID_PARAMETER);
        return -1;
    }

    if(!ptin || (!ptout && count)) {
        SetLastError(ERROR_NOACCESS);
        return -1;
    }

    FIXME("(%d %p %p %d %d) stub\n", size, ptin, ptout, count, res);

    static LPMOUSEMOVEPOINT prev;

    if (count > 0) {
        POINT pos;
        GetCursorPos(&pos);

        ptout[0].x = pos.x;
        ptout[0].y = pos.y;
        ptout[0].time = GetTickCount();
        ptout[0].dwExtraInfo = 0;
        FIXME("    Output 0: %d %d\n", pos.x, pos.y);

        if (count > 1) {
            ptout[1].x = pos.x + 1;
            ptout[1].y = pos.y + 1;
            ptout[1].time = GetTickCount();
            ptout[1].dwExtraInfo = 0;
            FIXME("    Output 1: %d %d\n", pos.x + 1, pos.y + 1);
            return 2;
        }
        return 1;
    }

    SetLastError(ERROR_POINT_NOT_FOUND);
    return -1;
}

(or maybe it was the patch that was released a couple of hours ago, I'm not sure I tested before changing the code)

EDIT: Was not due to the patch, this code indeed fixed it

Sweet! Rebuilding with that right now.

Getting some odd crashes, but managed to finish a 1v1 fight against AI, so it's looking promising.

So far so good with that adjustment. Was able to putz around with the menus, create a character, skip the tutorial, go back into the training camp, and complete all training objectives with all weapons. Only issue I've noticed so far is that rotating the map with the right mouse button only works in one direction (i.e., like an inverse Zoolander, the map will only turn left, lol).

I think the only remaining annoyance here is the long hang when saving, and I have no leads at all for figuring out what's causing that, unfortunately.

So far so good with that adjustment. Was able to putz around with the menus, create a character, skip the tutorial, go back into the training camp, and complete all training objectives with all weapons. Only issue I've noticed so far is that rotating the map with the right mouse button only works in one direction (i.e., like Zoolander, the map refuses to turn left, lol).

I think the only remaining annoyance here is the long hang when saving, and I have no leads at all for figuring out what's causing that, unfortunately.

Is the mouse working now, or are you still using a game pad?

Anyone run into this issue yet?

Assertion: should not be reached at /vagrant/mono/mono/utils/mono-threads.c:1066

Game keeps freezing on me right after the character creation with that as my only clue before I am forced to kill it.

Is the mouse working now, or are you still using a game pad?

:mouse: Game pad ain't even plugged in.

@YellowApple, you could try storing the point from the previous call of the function in a static variable and then pass it as the point at index 1. I feel like they are using the two points to calculate some sort of mouse delta.
Gonna go to sleep now.

That's definitely worth a shot. I'll putz with that code and see if I can whip up something along those lines. Long term solution would ultimately be to have a static buffer of up to 64 of these and continuously cycle through them (that is: actually fully implement the API call instead of the current hacked-together approach, lol).

This reminds me of one issue, last year (has been patched in game since), Naval Action had issues in proton where it wouldn't detect cursor placement after changing mouse parsing context (from mouselook to a menu), and if you had the menu open, alt-tab'd out and back again, it would detect it and the menu would work. Seems like a simple thing but, has anyone tried it?

I hadn't thought to try the alt-tabbing, but I just tried and it did nothing for me unfortunately. :disappointed:

Anyone know if that vagrant mono error that is freezing me is Steam related or Mount and Blade related?

@YellowApple Do you mind explaining how and where you patched that code into wine? I'm very new to compiling wine (but I've been interested in getting various games working on Linux for years now) and I don't quite get where it's supposed to go. I got a friend of mine to switch to Linux full time a couple weeks ago and she was really looking forward to this game so it would be just swell if I could get it working for her. I don't think she'll be crawling back to Windows anytime soon but I also don't want her to be disappointed about not being able to play the only game she's been looking forward to.

Changing proton version started downloading from 0% and removed 31GB download two times in row I almost got heart attack.

Okay I have struggle to even keep it on disk as Steam removes it everytime I fully install it. I am sad.

I love the brilliant collaboration that is going on here and it is keeping me from refunding it on Steam. I am not super tech savvy but I can see there is progress going on here. With the simple things above I am able to get almost all the way through character creation before the game hard locks, making me physically reboot my computer, but you all give me hope =).

For the save game hang, we might have to get Codeweavers involved (basically the core maintainers of Wine). Hopefully they notice how popular this game is and work on it. Even if we get mouse support working, the save hang is still a reason for this game to be rated Garbage.

Controller wasn't helping out, still couldn't start the game, I guess I'm waiting a day.

@giantrat Did you try the renames? The launcher that steam attempts to start by default doesn't like to work for a lot of us.

@coltondrg Source file in question is dlls/user32/input.c. You'd want to find the function definition for GetMouseMovePointsEx and replace it with the following:

/***********************************************************************
 * GetMouseMovePointsEx [USER32]
 *
 * RETURNS
 *     Success: count of point set in the buffer
 *     Failure: -1
 */
int WINAPI GetMouseMovePointsEx(UINT size, LPMOUSEMOVEPOINT ptin, LPMOUSEMOVEPOINT ptout, int count, DWORD res) {

    if((size != sizeof(MOUSEMOVEPOINT)) || (count < 0) || (count > 64)) {
        SetLastError(ERROR_INVALID_PARAMETER);
        return -1;
    }

    if(!ptin || (!ptout && count)) {
        SetLastError(ERROR_NOACCESS);
        return -1;
    }

    FIXME("(%d %p %p %d %d) hack\n", size, ptin, ptout, count, res);
    FIXME("    Input: %d %d\n", ptin->x, ptin->y);

    if (count > 0) {
        POINT pos;
        GetCursorPos(&pos);

        ptout[0].x = pos.x;
        ptout[0].y = pos.y;
        ptout[0].time = GetTickCount();
        ptout[0].dwExtraInfo = 0;
        FIXME("    Output 0: %d %d\n", pos.x, pos.y);

        if (count > 1) {
            ptout[1].x = pos.x + 1;
            ptout[1].y = pos.y + 1;
            ptout[1].time = GetTickCount();
            ptout[1].dwExtraInfo = 0;
            FIXME("    Output 1: %d %d\n", pos.x, pos.y);
            return 2;
        }

        return 1;
    }

    SetLastError(ERROR_POINT_NOT_FOUND);
    return -1;
}

If you're building the same version of Wine that Proton's using, you could instead save the following to a file (say, butterlord.patch), cd into the Wine source tree, and run git apply path/to/butterlord.patch (this also includes the patches to fix the post-character-creation crash):

diff --git a/dlls/api-ms-win-crt-private-l1-1-0/api-ms-win-crt-private-l1-1-0.spec b/dlls/api-ms-win-crt-private-l1-1-0/api-ms-win-crt-private-l1-1-0.spec
index 668b8c02fb..58f23257e0 100644
--- a/dlls/api-ms-win-crt-private-l1-1-0/api-ms-win-crt-private-l1-1-0.spec
+++ b/dlls/api-ms-win-crt-private-l1-1-0/api-ms-win-crt-private-l1-1-0.spec
@@ -150,7 +150,8 @@
 @ stub _o___stdio_common_vfprintf_p
 @ stub _o___stdio_common_vfprintf_s
 @ stub _o___stdio_common_vfscanf
-@ stub _o___stdio_common_vfwprintf
+# PATCHED:
+@ cdecl _o___stdio_common_vfwprintf(int64 ptr wstr ptr ptr) ucrtbase._o___stdio_common_vfwprintf
 @ stub _o___stdio_common_vfwprintf_p
 @ stub _o___stdio_common_vfwprintf_s
 @ stub _o___stdio_common_vfwscanf
@@ -160,7 +161,8 @@
 @ stub _o___stdio_common_vsprintf_p
 @ cdecl _o___stdio_common_vsprintf_s(int64 ptr long str ptr ptr) ucrtbase._o___stdio_common_vsprintf_s
 @ stub _o___stdio_common_vsscanf
-@ stub _o___stdio_common_vswprintf
+# PATCHED:
+@ cdecl _o___stdio_common_vswprintf(int64 wstr long wstr ptr ptr) ucrtbase._o___stdio_common_vswprintf
 @ stub _o___stdio_common_vswprintf_p
 @ stub _o___stdio_common_vswprintf_s
 @ stub _o___stdio_common_vswscanf
diff --git a/dlls/ucrtbase/ucrtbase.spec b/dlls/ucrtbase/ucrtbase.spec
index 2251f9f56a..281e2e7c9e 100644
--- a/dlls/ucrtbase/ucrtbase.spec
+++ b/dlls/ucrtbase/ucrtbase.spec
@@ -814,7 +814,8 @@
 @ stub _o___stdio_common_vfprintf_p
 @ stub _o___stdio_common_vfprintf_s
 @ stub _o___stdio_common_vfscanf
-@ stub _o___stdio_common_vfwprintf
+# PATCHED:
+@ cdecl _o___stdio_common_vfwprintf(int64 ptr wstr ptr ptr) MSVCRT__stdio_common_vfwprintf
 @ stub _o___stdio_common_vfwprintf_p
 @ stub _o___stdio_common_vfwprintf_s
 @ stub _o___stdio_common_vfwscanf
@@ -824,7 +825,8 @@
 @ stub _o___stdio_common_vsprintf_p
 @ cdecl _o___stdio_common_vsprintf_s(int64 ptr long str ptr ptr) MSVCRT__stdio_common_vsprintf_s
 @ stub _o___stdio_common_vsscanf
-@ stub _o___stdio_common_vswprintf
+# PATCHED:
+@ cdecl _o___stdio_common_vswprintf(int64 wstr long wstr ptr ptr) MSVCRT__stdio_common_vswprintf
 @ stub _o___stdio_common_vswprintf_p
 @ stub _o___stdio_common_vswprintf_s
 @ stub _o___stdio_common_vswscanf
diff --git a/dlls/user32/input.c b/dlls/user32/input.c
index 46f78cbce8..40ed0f4692 100644
--- a/dlls/user32/input.c
+++ b/dlls/user32/input.c
@@ -1280,7 +1280,30 @@ int WINAPI GetMouseMovePointsEx(UINT size, LPMOUSEMOVEPOINT ptin, LPMOUSEMOVEPOI
         return -1;
     }

-    FIXME("(%d %p %p %d %d) stub\n", size, ptin, ptout, count, res);
+    FIXME("(%d %p %p %d %d) hack\n", size, ptin, ptout, count, res);
+    FIXME("    Input: %d %d\n", ptin->x, ptin->y);
+
+    if (count > 0) {
+        POINT pos;
+        GetCursorPos(&pos);
+
+        ptout[0].x = pos.x;
+        ptout[0].y = pos.y;
+        ptout[0].time = GetTickCount();
+        ptout[0].dwExtraInfo = 0;
+        FIXME("    Output 0: %d %d\n", pos.x, pos.y);
+
+        if (count > 1) {
+            ptout[1].x = pos.x + 1;
+            ptout[1].y = pos.y + 1;
+            ptout[1].time = GetTickCount();
+            ptout[1].dwExtraInfo = 0;
+            FIXME("    Output 1: %d %d\n", pos.x, pos.y);
+            return 2;
+        }
+        
+        return 1;
+    }

     SetLastError(ERROR_POINT_NOT_FOUND);
     return -1;

That will patch up your Wine such that it's exactly identical to what I'm using.

@giantrat Did you try the renames? The launcher that steam attempts to start by default doesn't like to work for a lot of us.

yup, and now I'm getting the damn load screen crash, even after applying what helped it last time.

@YellowApple You're amazing. The patch file you pasted includes the previous patches for the crashing too, right? (nevermind, I can read) I had already managed to make a build with those patches but the game wasn't detecting the controller on my computer so I wasn't really able to get far enough to see if that was actually effective. Also I'm not sure if this makes any difference, but I've been compiling my builds using the proton-tkg script (from wine-tkg-git) so I can just drag custom patch files in and have the script spit out a nice Proton for me to drag into compatibilitytools.d. I guess that means my build has all the tkg patches as well, which I'm hoping aren't conflicting or likely to break something else.

Just wanted to update, after applying the patch from @YellowApple above, the game is now fully working for me, including mouse inputs! The first campaign save did freeze up the game for a few minutes, and it ended up crashing at the end, but after reopening the game the save loaded successfully. Subsequent saves do make the game freeze up for a few seconds, but they do not crash, so I am still able to play pretty smoothly! I have a Ryzen 2600, RX 580, and a sata SSD, so pretty midrange specs, which is also encouraging. Thanks so much to everyone in this thread who contributed to the solution, and feel free to ask me anything else :). Hopefully this can get pushed to upstream wine so we won't have to build ourselves.

EDIT: So after playing around an hour of the campaign, it seems that there might be a memory leak, since the game keeps using more and more ram while the performance starts degrading. This may very well be an issue with the game itself, considering I saw some windows users also complaining about performance issues. I have 8GB of ram, so might be interesting to see if this happens to people with more ram.

And here is the slightly-polished-up version of GetMouseMovePointsEx, which fixes the reverse-Zoolander-map-rotation bug and - while still rife with hackery - is likely Good Enough™ to send on upstream:

/***********************************************************************
 * GetMouseMovePointsEx [USER32]
 *
 * RETURNS
 *     Success: count of point set in the buffer
 *     Failure: -1
 */
int WINAPI GetMouseMovePointsEx(UINT size, LPMOUSEMOVEPOINT ptin, LPMOUSEMOVEPOINT ptout, int count, DWORD res) {
    static INT last_x = 0;
    static INT last_y = 0;

    if((size != sizeof(MOUSEMOVEPOINT)) || (count < 0) || (count > 64)) {
        SetLastError(ERROR_INVALID_PARAMETER);
        return -1;
    }

    if(!ptin || (!ptout && count)) {
        SetLastError(ERROR_NOACCESS);
        return -1;
    }

    if (count > 0) {
        POINT pos;
        INT out_count = 1;
        GetCursorPos(&pos);

        ptout[0].x = pos.x;
        ptout[0].y = pos.y;
        ptout[0].time = GetTickCount();
        ptout[0].dwExtraInfo = 0;

        if (count > 1) {
            ptout[1].x = last_x;
            ptout[1].y = last_y;
            ptout[1].time = GetTickCount();
            ptout[1].dwExtraInfo = 0;
            out_count = 2;
        }

        last_x = pos.x;
        last_y = pos.y;

        return out_count;
    }

    SetLastError(ERROR_POINT_NOT_FOUND);
    return -1;
}

@qsniyg: Wanna do the honors and submit it?

I don't have the game currently so I can't test, but does anyone have any crashlog output for the savegame hang? Almost sounds like that issue we had with file permissions.

@YellowApple would you mind creating a "how to make the game work from scratch for idiots" guide?

I don't have the game currently so I can't test, but does anyone have any crashlog output for the savegame hang? Almost sounds like that issue we had with file permissions.

I somewhat doubt it's a permissions issue. The game is managing to save but it's taking ~5-10 minutes to save and just hangs until it's done. It wouldn't be a showstopper for me playing except that the autosave goes off every time you start a battle, and on most other large scene changes

@YellowApple would you mind creating a "how to make the game work from scratch for idiots" guide?

The most "for idiots" friendly approach:

• Download the exact Proton build I'm using: https://yellowapple-misc.s3-us-west-2.amazonaws.com/proton_5.0-local.tar.gz
• Stick it in ~/.steam/root/compatibilitytools.d
• Extract it (cd ~/.steam/root/compatibilitytools.d && tar xvf proton_5.0-local.tar.gz)
• Restart Steam
• Right-click Bannerlord in your library, click Properties, and change the Proton version to "proton_5.0-local"
• ???
• Profit

Obviously, you do this at your own risk, with the understanding that downloading and installing and running random binaries off the Internet is a risky affair fraught with peril. Caveat emptor. You are strongly encouraged to try your hand at cloning the Proton repo, applying the patches yourself, and building Proton on your own machine (and while yes, that ain't exactly the most user-friendly approach, it's a lot safer than trusting Internet strangers to not drink from your skull, lol).

Hopefully we can get these patches upstreamed sooner rather than later so that we can avoid the need for these rinky-dink one-off custom builds, lol

Hopefully we can get these patches upstreamed sooner rather than later so that we can avoid the need for these rinky-dink one-off custom builds, lol

At the very least, as long as these patches don't break other things, mayhaps they could be put into the popular third-party Proton builds such as tkg or GE for the time being? :3 @GloriousEggroll?

@YellowApple would you mind creating a "how to make the game work from scratch for idiots" guide?

The most "for idiots" friendly approach:

* Download the exact Proton build I'm using: https://yellowapple-misc.s3-us-west-2.amazonaws.com/proton_5.0-local.tar.gz

* Stick it in `~/.steam/root/compatibilitytools.d`

* Extract it (`cd ~/.steam/root/compatibilitytools.d && tar xvf proton_5.0-local.tar.gz`)

* Restart Steam

* Right-click Bannerlord in your library, click Properties, and change the Proton version to "proton_5.0-local"

* ???

* Profit

Obviously, you do this at your own risk, with the understanding that downloading and installing and running random binaries off the Internet is a risky affair fraught with peril. Caveat emptor. You are strongly encouraged to try your hand at cloning the Proton repo, applying the patches yourself, and building Proton on your own machine (and while yes, that ain't exactly the most user-friendly approach, it's a lot safer than trusting Internet strangers to not drink from your skull, lol).

Hopefully we can get these patches upstreamed sooner rather than later so that we can avoid the need for these rinky-dink one-off custom builds, lol

The problem is that when I switch the proton version whole Bannerlord is removed and start to download again. 😤

That shouldn't happen, it should delete the compatdata folder if you downgrade Proton but it should never delete the whole game. At any rate you should be able to bypass the redownload by backing up the game files and restoring them after changing Proton version. You can accomplish this by literally making a copy of the game install folder or in Steam > Backup and Restore Games

The delay when saving the game is brutal. I can confirm that it drives CPU utilization to 100% on all 12 logical CPUs in my system for several seconds (up to about a 1 minute for me). Disk R/W during this time is low/nonexistent, so it seems to be spinning on something else. I don't see anything printed to the console when running steam from it while this is going on.. is there some other way to enable more logging from proton/wine that might help diagnose the issue here?

Currently building a patched version of GE Proton. Will report back if it works with the patch posted here :)

@YellowApple

What patches did you apply exactly ?
Applying the git patch from your post is enough ? (im still downloading Bannerlord so wasnt able to test it yet)

Also do we still need to bypass the launcher with this patch ?

YellowApple

What patches did you apply exactly ?
Applying the git patch from your post is enough ? (im still downloading Bannerlord so wasnt able to test it yet)

Also do we still need to bypass the launcher with this patch ?

@elovin

It appears that the managed starter issue has been fixed now with the most recent patch. So no.

In either case the bypassing of the launcher was unnecessary, If you renamed the Bannerlord.exe to ManagedStarter.exe the launcher would work fine.

@YellowApple @tomhobson
I can apply the patch to wine stable but not to wine master because there is now a conflicting patch (that seems to be your patch but with a different order of arguments ?),
was your patch already merged ?

EDIT:
okay the input patch is still necessary.

@YellowApple would you mind creating a "how to make the game work from scratch for idiots" guide?

The most "for idiots" friendly approach:

* Download the exact Proton build I'm using: https://yellowapple-misc.s3-us-west-2.amazonaws.com/proton_5.0-local.tar.gz

* Stick it in `~/.steam/root/compatibilitytools.d`

* Extract it (`cd ~/.steam/root/compatibilitytools.d && tar xvf proton_5.0-local.tar.gz`)

* Restart Steam

* Right-click Bannerlord in your library, click Properties, and change the Proton version to "proton_5.0-local"

* ???

* Profit

Obviously, you do this at your own risk, with the understanding that downloading and installing and running random binaries off the Internet is a risky affair fraught with peril. Caveat emptor. You are strongly encouraged to try your hand at cloning the Proton repo, applying the patches yourself, and building Proton on your own machine (and while yes, that ain't exactly the most user-friendly approach, it's a lot safer than trusting Internet strangers to not drink from your skull, lol).

Hopefully we can get these patches upstreamed sooner rather than later so that we can avoid the need for these rinky-dink one-off custom builds, lol

It works for my manjaro.

Hi All,

I waited so long for this game. Is this game is playable now?

@YellowApple would you mind creating a "how to make the game work from scratch for idiots" guide?

The most "for idiots" friendly approach:

* Download the exact Proton build I'm using: https://yellowapple-misc.s3-us-west-2.amazonaws.com/proton_5.0-local.tar.gz

* Stick it in `~/.steam/root/compatibilitytools.d`

* Extract it (`cd ~/.steam/root/compatibilitytools.d && tar xvf proton_5.0-local.tar.gz`)

* Restart Steam

* Right-click Bannerlord in your library, click Properties, and change the Proton version to "proton_5.0-local"

* ???

* Profit

Obviously, you do this at your own risk, with the understanding that downloading and installing and running random binaries off the Internet is a risky affair fraught with peril. Caveat emptor. You are strongly encouraged to try your hand at cloning the Proton repo, applying the patches yourself, and building Proton on your own machine (and while yes, that ain't exactly the most user-friendly approach, it's a lot safer than trusting Internet strangers to not drink from your skull, lol).

Hopefully we can get these patches upstreamed sooner rather than later so that we can avoid the need for these rinky-dink one-off custom builds, lol

Works on Mint 19.2. Only problem seemingly remaining at the moment is the brutal time (usually a minute for me) it takes whenever the game saves.

Hi All,

I waited so long for this game. Is this game is playable now?

@Przygi It's playable -- but the waiting time (due to saving) at the minute is diabolical. This will need improving before the game is enjoyable.

@Rogue-Factor are there any special start options for extra logging? Working on getting a log here now.

Rogue-Factor are there any special start options for extra logging? Working on getting a log here now.

@sdegrace

Within steam, if you go to the game, right click and go to properties.

Then click set launch options.

Enter PROTON_LOG=1 %command%

Start the game as normal.

A log will appear within your home directory called steam-{appid}.log.

Note to everyone, you still have rename the exe files in addition to patching proton !

• Bypassing the Launcher

  Few notes:

  the game uses Battleye Anti-Cheat - it's seemingly mandatory even if you just want to play single player. No idea if there is a launch parameter that disables it.
  

  You can rename two .exe files in /Mount & Blade II Bannerlord/bin/Win64_Shipping_Client/

  rename "TaleWorlds.MountAndBlade.Launcher.exe" to "TaleWorlds.MountAndBlade.Launcher.exe_backup" (or something similar - it's just not allowed to keep its original name)
  
  rename "Bannerlord.exe" to "TaleWorlds.MountAndBlade.Launcher.exe"
  

  to at least make the game start, see the splash screens and then I get to the point I have to interact with the game for the first time (change brightness settings) at which point my CPU and GPU go absolute haywire and I can't interact with the game at all.

• And then patching Proton

  The most "for idiots" friendly approach:

  Download the exact Proton build I'm using: https://yellowapple-misc.s3-us-west-2.amazonaws.com/proton_5.0-local.tar.gz
  Stick it in ~/.steam/root/compatibilitytools.d
  Extract it (cd ~/.steam/root/compatibilitytools.d && tar xvf proton_5.0-local.tar.gz)
  Restart Steam
  Right-click Bannerlord in your library, click Properties, and change the Proton version to "proton_5.0-local"
  ???
  Profit
  

  Obviously, you do this at your own risk, with the understanding that downloading and installing and running random binaries off the Internet is a risky affair fraught with peril. Caveat emptor. You are strongly encouraged to try your hand at cloning the Proton repo, applying the patches yourself, and building Proton on your own machine (and while yes, that ain't exactly the most user-friendly approach, it's a lot safer than trusting Internet strangers to not drink from your skull, lol).

Thank you everyone on this thread :)

@SylvainSoKette

Launcher works fine for me!

@tomhobson have you done anything specific to get it working, or just running with the patched Proton should work?

Thanks for all the work on this thread! Been dual booting since the game came out but i'm glad progress has been made here!

My tests:

• Running Manjaro 19.0.2
• Renamed exe files due to launcher issue still occurring for me.
• Followed @YellowApple guide and loaded the game with edited Proton.
• Crash when adjusting audio, however settings did save.
• Crash when leaving tutorial after successful character creation.
• Managed to skip the tutorial on the second attempt and made it to the campaign map.
• Some slight performance drops compared to Windows but runs OK all in all.
• Tested save feature and as discussed game hangs during this. CPU tops out at around 90% on my 9700k. Save took about 35 seconds.

@tomhobson have you done anything specific to get it working, or just running with the patched Proton should work?

@kelytha I used the patched proton. but I renamed Bannerlord_BE.exe and Bannerlord.exe to ManagedStarter_BE.exe and ManagedStarter.exe respectively.

Wouldn't it be better to use links named ManagedStarter.exe and ManagedStarter_BE.exe, in case they update the executables?

@Rogue-Factor new log file is more than 10GB :/ I'm going to try again in a bit.

@sdegrace it should compress quite nicely. Try gz'ing it

Hi All,
I waited so long for this game. Is this game is playable now?

@Przygi It's playable -- but the waiting time (due to saving) at the minute is diabolical. This will need improving before the game is enjoyable.

Thanks for the answer!!! Great work guys!!!

Unplayable for me sadly, crashes everytime I change the graphics settings and crashes sometimes when it needs to draw/load a complex 3d scene (menu screen or character creation screen).
"Application Crash : The application faced a problem. We need to collect necessary files to fix the problem. Would you like to upload these files now ?"

The only time I got to the character creation screen, the performance was horrendous.
But I guess that's probably a driver issue on my side, since I'm on Ubuntu 18.04 with no exotic ppa or nothing manually installed driver-wise.

Ubuntu 18.04, core i7 6700, 16go ddr4, gtx 1060 3go (nvidia-driver-435)

Something to note : I got 2 monitors, one plugged on the graphics card, the other on the motherboard output (handled by the intel hd graphics). The main monitor is plugged to the nvidia graphics card and the game is rendered on the main monitor.

Update : I managed to change the graphical settings by changing them one by one with no crash. But still crashing a lot on the character creation screen :/

Okay I build proton-tkg which uses the latest wine master which does only need the input (input.c) part of the patch provided by @YellowApple .
Then I added symlinks to get the launcher working as @tomhobson and @Krypton-Nova suggested.

The game works so far using RADV with ACO and saving does take about 15 seconds.
Changing the settings does however crash the game (at least the changes to the settings are being saved)

CPU 3700X
GPU Vega 56
RAM 32gb
SSD samsung 860 evo 1TB

Distro:
Arch Linux

Kernel:
5.5.13-zen2-1-zen

GPU Driver:
mesa-20.0.2

Update 2:

Okay after running the game for 1 hour the performance is actually quite good (compared to windows) I get about 70 fps when in the arena and very good frame times, on the world map its around 50-60pfs with frame times spikes to 50ms, in the city its about 50-60 pfs with frametimes up to 10ms and during an actual battle I get around 60-80pfs (depending on the map) with good frametimes but occasional spikes up to >100ms (probably shader compilation).

I play on WQHD with settings on "very high" by the way.

Hmm... So I tried building the patched one while I slept, it didn't work. I just tried download your version, @YellowApple, and it also doesn't work! :sob: (By doesn't work, I mean my mouse still isn't letting me move AND click on menus, haven't tried a controller yet)

Am I the only one who it didn't work for?

Can confirm the same for GE Proton working with the patch. Only problem I have is that every second launch or so the mouse will not work again. Have to restart the game one more time then for it to function properly again.

@YellowApple Great work!! :) I personally think the patch would be better suited for wine-staging rather than wine (then sending it to the forks, like proton-ge etc.), as wine is pretty strict about making sure the function works as closely as possible to windows.

To submit to wine-staging, see here: https://wiki.winehq.org/Wine-Staging_Development. Basically, attach the patch to https://bugs.winehq.org/show_bug.cgi?id=36873, explain why you think it should go to wine-staging over wine, then CC Alistair and Zebediah (wine-staging's maintainers) for them to look into it and add it to wine-staging.

In the meantime, I'll try and see if I can implement one that mirrors Windows' implementation of the function :)

@Rogue-Factor
https://www.dropbox.com/s/e25za0261pdco0t/steam-261550.log.gz?dl=0

In this log I opened Bannerlord, opened an existing save, saved the game, then saved and exited the game. Apparently there is an upper limit to the number of cores it takes when saving - for me it's 14/16. It does take a bit less than a minute for me. No other problems have been experienced yet.

YellowApple's patch works for me! Will now try out making a character and the tutorial.

Since I do seem to be the only one it isn't working for, I'm gonna do a full system update and then try building again... maybe try out GE proton. I do have an idea for a very basic keyboard to virtual controller, so I'll take a crack at that if rebuilding doesn't get my mouse working.

@elovin Can you list all of the patches required? I want to try to build proton based on YellowApple's recommendation. Not that I dont trust them, but I want to be able to do this stuff and help contribute. There were a lot of patches in the thread, so if you dont mind listing the ones you used, Ill try to do this.

@elovin Can you list all of the patches required? I want to try to build proton based on YellowApple's recommendation. Not that I dont trust them, but I want to be able to do this stuff and help contribute. There were a lot of patches in the thread, so if you dont mind listing the ones you used, Ill try to do this.

/***********************************************************************
 * GetMouseMovePointsEx [USER32]
 *
 * RETURNS
 *     Success: count of point set in the buffer
 *     Failure: -1
 */
int WINAPI GetMouseMovePointsEx(UINT size, LPMOUSEMOVEPOINT ptin, LPMOUSEMOVEPOINT ptout, int count, DWORD res) {
    static INT last_x = 0;
    static INT last_y = 0;

    if((size != sizeof(MOUSEMOVEPOINT)) || (count < 0) || (count > 64)) {
        SetLastError(ERROR_INVALID_PARAMETER);
        return -1;
    }

    if(!ptin || (!ptout && count)) {
        SetLastError(ERROR_NOACCESS);
        return -1;
    }

    if (count > 0) {
        POINT pos;
        INT out_count = 1;
        GetCursorPos(&pos);

        ptout[0].x = pos.x;
        ptout[0].y = pos.y;
        ptout[0].time = GetTickCount();
        ptout[0].dwExtraInfo = 0;

        if (count > 1) {
            ptout[1].x = last_x;
            ptout[1].y = last_y;
            ptout[1].time = GetTickCount();
            ptout[1].dwExtraInfo = 0;
            out_count = 2;
        }

        last_x = pos.x;
        last_y = pos.y;

        return out_count;
    }

    SetLastError(ERROR_POINT_NOT_FOUND);
    return -1;
}

The patch by @YellowApple works for me too, very thanks man.

Loading times are still horrible, but the game seems to work, at least somewhat. What might appear to be a crash, is sometimes just a loading screen that takes forever lol.

It works really well on manjaro, save takes like 5 - 10 secs, but shader computation seems to crash the game (about 1/5 odds) when i load a map for the first time. some settings crash, but get applied after crashing so thats fin. THANKS FOR YOUR WORK!

@elovin Can you list all of the patches required? I want to try to build proton based on YellowApple's recommendation. Not that I dont trust them, but I want to be able to do this stuff and help contribute. There were a lot of patches in the thread, so if you dont mind listing the ones you used, Ill try to do this.

I used the build script from proton-tkg (clone the tkg PKGBUILD repo) and added the patch to wine-tkg-git/wine-tkg-userpatches/bannerlord.mypatch (tkg will search for the "mypatch" file extension so yes you have to actually name it like YOUR_PATCH_NAME.mypatch)

bannerlord.mypatch only contains the patch for input.c from @YellowApple and thats the only patch

diff --git a/dlls/user32/input.c b/dlls/user32/input.c
index 46f78cbce8..40ed0f4692 100644
--- a/dlls/user32/input.c
+++ b/dlls/user32/input.c
@@ -1280,7 +1280,30 @@ int WINAPI GetMouseMovePointsEx(UINT size, LPMOUSEMOVEPOINT ptin, LPMOUSEMOVEPOI
         return -1;
     }

-    FIXME("(%d %p %p %d %d) stub\n", size, ptin, ptout, count, res);
+    FIXME("(%d %p %p %d %d) hack\n", size, ptin, ptout, count, res);
+    FIXME("    Input: %d %d\n", ptin->x, ptin->y);
+
+    if (count > 0) {
+        POINT pos;
+        GetCursorPos(&pos);
+
+        ptout[0].x = pos.x;
+        ptout[0].y = pos.y;
+        ptout[0].time = GetTickCount();
+        ptout[0].dwExtraInfo = 0;
+        FIXME("    Output 0: %d %d\n", pos.x, pos.y);
+
+        if (count > 1) {
+            ptout[1].x = pos.x + 1;
+            ptout[1].y = pos.y + 1;
+            ptout[1].time = GetTickCount();
+            ptout[1].dwExtraInfo = 0;
+            FIXME("    Output 1: %d %d\n", pos.x, pos.y);
+            return 2;
+        }
+        
+        return 1;
+    }

     SetLastError(ERROR_POINT_NOT_FOUND);
     return -1;

OK, for future intrepid folks, note that @elovin method does have the following requirement (per the TKG page)

"PKGBUILDs will only work on distros with access to pacman and makepkg" so this may not be suitable for debian-based distro unless you are willing to go further to customize this.

Im going to try without it.

I bought the game and installed, and used the method in the description (downloading the special proton, yeah, I know, not secure, but testing), set it to use the new -local one, and still won't get to launcher.
I see other folks have the launcher working without renaming anything to skip it...but maybe they have other fixes applied from earlier, this is a fresh one. what am I missing (and can we add that to the workaround-so-far at the top)

@aradapilot There's still renaming needed as far as I'm aware, at least for most people, but it's not the first renaming to bypass the launcher anymore.
This renaming still use the launcher:
Rename Bannerlord.exe and Bannerlord_BE.exe to ManagedStarter.exe and ManagedStarter_BE.exe.

Note to anyone interested : I finally managed to make it "work" with the renamed exe and updated proton. Turns out nvidia-driver-440 was mandatory as nvidia-driver-435 resulted in crashed almost 95% of the time in the character creation screen. Performances are still horrendous though, but I haven't tried on Windows yet, so I don't know if it's linux related or just my computer that is total garbage :)

To submit to wine-staging, see here: https://wiki.winehq.org/Wine-Staging_Development. Basically, attach the patch to https://bugs.winehq.org/show_bug.cgi?id=36873, explain why you think it should go to wine-staging over wine, then CC Alistair and Zebediah (wine-staging's maintainers) for them to look into it and add it to wine-staging.

Done. Thanks!

In the meantime, I'll try and see if I can implement one that mirrors Windows' implementation of the function :)

Sweet. I did a little bit of digging on it earlier, but I'm having trouble wrapping my head around exactly how Wine gets its mouse input (and where that could be stored in a way that's useful to GetMouseMovePointsEx). I'm also not entirely sure if X11 (or Wayland or Quartz or the myriad other display systems used with Wine) have equivalent functionality.

Performance is quite OK for me with Mesa 20.0, RADV+ACO on AMD RX 580 graphics (some stuttering e.g. when moving to a new scene, but it clears up fast). The only issue I've run into with this so far after patching to make mouse input work is the save game lag.

@craftyguy How much RAM do you have? The game works fine for me for around 30 mins, but after that performance starts degrading rapidly and RAM usage starts increasing. I only have 8 GB, so trying to find out if that is the problem.

@tkamat I've noticed that the "steady state" for the game's RAM usage seems to be around ~19-20GB on my machine (which has 32GB). This is regardless of graphics settings (tried both absolute highest and absolute lowest).

OK, for future intrepid folks, note that @elovin method does have the following requirement (per the TKG page)

"PKGBUILDs will only work on distros with access to pacman and makepkg" so this may not be suitable for debian-based distro unless you are willing to go further to customize this.

Im going to try without it.

You can run makepkg inside an arch linux docker container (maybe I will make a simple script for this) and then unpack the proton version from the resulting tar ball (arch packages are just tar balls).
I unpack the proton version myself and do not install it system wide.

@tkamat I second @YellowApple's comment. I also have 32GB, and have noticed that it gets to about 20GB utilization while running the game.

So it seems like your performance issues are related to available RAM. This seems off-topic since it's likely a problem with the game itself and not specific to proton/wine..

So it looks like protontricks 261550 dotnet48 significantly improves the save hang (the game hangs for a few seconds instead of multiple minutes). Thanks to reddit user /u/TheCaconym for the report!

Also, at some point Steam updated the game and blew away my renames, but the launcher worked out of the box nonetheless. Didn't even have to do a Bannerlord.exe → ManagedStarter.exe rename.

We're less than a week into Harvesting Season™ and Bannerlord is already at close to parity between Linux and Windows. Huzzah!

Once those patches are in, the butter shall flow freely.

@YellowApple

I'm having trouble wrapping my head around exactly how Wine gets its mouse input

It sends it to the server, usually through send_hardware_message in dlls/user32/message.c, and the cursor position will eventually get sent to update_desktop_cursor_pos. This is probably where we should add the implementation, maybe in a new function (probably using a static ring buffer to store the 64 entries?).

The annoying part would be to declare a new server request to retrieve the cursor positions. I haven't done this before, but I guess it's a matter of creating it in queue.c+request.h, stating it in protocol.def, and then running tools/make_requests?

Then comes the question of should the task of filtering the cursor positions be delegated to the server, or in userspace? I would personally go for the latter, but since it is quite a few entries (probably ~1KB or so of data to send), and the filtering code wouldn't be too complex, it might be worth doing it in the server instead.

I can confirm that dotnet48 speeds up saving.
I was one of the lucky ones where saving only took about 10 seconds, but with it it now takes around 2 seconds.

@albin-engstrom is it installed on a SSD or HDD for you? Noticed some really long loadtimes between scenes sometimes. Currently installing dotnet48.

Performance degrades a lot for me the longer I play. Hopefully it is just a bug in the game.

Performances degrading as you play is an issue for now on Windows, too (memory leaks - acknowledged by the devs IIRC).

@nilleairbar On a NVMe SSD, so it's fairly fast. But it does not seem like at least the save time is due to reads or writes, it's rather the CPU that does work. It went from around 30% load while playing to 60% while saving.
So it may be more a powerful CPU (3900X) that led to the short save times to some extent.

@albin-engstrom that may be it. With dotnet48 and a i7 8700K, saving takes under two seconds here too.

I'm on a 1700X and now after installing dotnet48 saving takes about 20 to 30 seconds instead of 2 to 3 minutes but now performance tanks for a while after saving.

I'm getting similar results on an older i5, about 30 seconds to save now

So now I'm suddenly getting a crash (wine: Unhandled page fault on execute access to 00000000007501C8 at address 00000000007501C8 (thread 0042), starting debugger...) as soon as I get to the Prisoners screen after a battle. Not sure yet if it's a result of using dotnet48. Also not sure yet if it's affecting all battles or just ones with this specific group of Looters (or with Looters in general). Once I narrow things down I'll put up some logs.

@YellowApple I have fought multiple battles against looter's and that did not lead to a crash for me. (dotnet 48 is not installed yet)

The most "for idiots" friendly approach:

• Download the exact Proton build I'm using: https://yellowapple-misc.s3-us-west-2.amazonaws.com/proton_5.0-local.tar.gz
  ....

I did these exact steps, the game launches, however when it asks me to slide brightness sliders at the very first launch, it doesn't register any input (besides mouse movement)....

Game runs fine until I try to toggle the "show attack direction" setting in the menu.
Game crashes immedeitely after closing the menu, the steam "you've encounted an error please upload your logs" message appears. When the window closes Steam still thinks the game is running so I can't launch again via steam.

I'm using https://yellowapple-misc.s3-us-west-2.amazonaws.com/proton_5.0-local.tar.gz for proton

System info:
KERNEL: 5.5.13-arch2-1
OS: Arch Linux
CPU: AMD Ryzen 7 3700X 8-Core
GPU: AMD NAVI10
GPU DRIVER: 4.6 Mesa 20.0.2
RAM: 32 GB

Game runs fine until I try to toggle the "show attack direction" setting in the menu.
Game crashes immedeitely after closing the menu, the steam "you've encounted an error please upload your logs" message appears. When the window closes Steam still thinks the game is running so I can't launch again via steam.

I'm using https://yellowapple-misc.s3-us-west-2.amazonaws.com/proton_5.0-local.tar.gz for proton

System info:
KERNEL: 5.5.13-arch2-1
OS: Arch Linux
CPU: AMD Ryzen 7 3700X 8-Core
GPU: AMD NAVI10
GPU DRIVER: 4.6 Mesa 20.0.2
RAM: 32 GB

I had multiple crashes in the beginning when changing video settings, just kill the process and start the game again.

Report: Game is running fine and saving in about 1 minutes time on my machine. Using the workaround and renames to "Managed". At the brightness screen, I selected good settings for me and then exited the game on main menu. Then I went through tutorial, changed some additional settings, and most graphics settings are on high+ still. Performance is so-so (probably around 30-40 FPS). I have not experienced any crash so far, but have only just exited the tutorial and encountered refugees. Thanks to everyone, dev, testers, Valve and Taleworlds for getting us here.

System info:
OS: Debian 10 (buster)
RAM: 16GB
CPU: Ryzen 2700X
GPU: AMD 580X
Driver: Debian 10 (Mesa 18.3.6)

Game runs fine until I try to toggle the "show attack direction" setting in the menu.
Game crashes immedeitely after closing the menu, the steam "you've encounted an error please upload your logs" message appears. When the window closes Steam still thinks the game is running so I can't launch again via steam.
I'm using https://yellowapple-misc.s3-us-west-2.amazonaws.com/proton_5.0-local.tar.gz for proton
System info:
KERNEL: 5.5.13-arch2-1
OS: Arch Linux
CPU: AMD Ryzen 7 3700X 8-Core
GPU: AMD NAVI10
GPU DRIVER: 4.6 Mesa 20.0.2
RAM: 32 GB

I had multiple crashes in the beginning when changing video settings, just kill the process and start the game again.

I killed the steam process and started bannerlord again, suprisingly the setting I changed remained changed.

@elovin Just tried against a group of Mountain Bandits and it crashes at the same spot. Logs for reference: steam-261550.log (excludes +seh because with dotnet48 that was spamming all sorts of stuff).

Gonna try a fresh prefix with the same save and without dotnet48 and see if the issue persists. If it doesn't, then I guess we're either gonna have to troubleshoot .NET buggery or we're back to the drawing board with those long save times.

@onodera-punpun If you can add PROTON_LOG=1 to your launch options and provide the resulting ~/steam-261550.log, that'd be helpful.

@YellowApple https://camille.sh/rAM1.log

@YellowApple after installing dotnet48 with winetricks I get a message upon loading my last game "Load game saved with different modules" or something like that so maybe a new game works.

The save time didn't improve for me its still about 15 seconds and no crashes so far fighting looters

@elovin that's the standard message after loading a 1.0.0 save after an update to 1.0.1; maybe that's the origin (only relevant if it turns out you loaded a 1.0.0 save after dotnet48 though, and you've already updated to 1.0.1) ?

@YellowApple for what it's worth, with my dotnet48 prefix I'm not getting any crash when getting to the prisoners screen after a battle (did numerous battles with many prisoners). Most of my battles thus far were with looters though, no mountain bandits yet.

@onodera-punpun Weird, nothing sticks out. You don't happen to have any controllers plugged in or anything else that might interfere, right?

@elovin I think that has to do with updated game versions (1.0.2 just dropped).

@ElCaconym That's good to know. The same save under a fresh non-dotnet48 prefix crashes under the same conditions, so at least I can rule that out. Probably just a corrupted save (which seems to be a common issue even on Windows, if the forums are anything to go by). (EDIT: and indeed, under a new game with dotnet48 I'm able to take prisoners without crashing, for now at least)

@YellowApple I thought it might have been my window manager, so I tried running the game in a X instance without any WM, but that didn't fix the issue. I just have a normal USB keyboard and mouse, nothing else.

EDIT: I set brightness_calibrated in the engine config to 1 to skip straight to the menu, and there too clicking doesn't do anything.

EDIT2: I turned off enable steam play for all other titles, this seemed to fix it. Somehow this overwrote the use of my forcibly set custom proton....

Does anybody else experience the unsuccessful logging in issue on any attempt on running multiplayer? It just keeps throwing those "login failed" messages at me after long periods of wait.

@YellowApple @ElCaconym Yes you are right its because of the update.

Does anybody else experience the unsuccessful logging in issue on any attempt on running multiplayer? It just keeps throwing those "login failed" messages at me after long periods of wait.

I haven't heard any reports of anyone being able to run multiplayer since they added Batlleye early on in the beta.

What are the odds that we ever get multiplayer running on Bannerlord? I used to play Warband all the time online in Ubuntu back in the day.

sooo I saw the note about dotnet48 and installed it, at the same time I noticed steam had updated the game to 1.0.2, and now it's stuttering on anything over min graphics (got a 1070) and crashing constantly just moving in open world. annnnd because two variables here I can't tell whether it was the patch or the dotnet thing that caused it. any clue on what to look for? or how to reset my proton env without dotnet to test?

@aradapilot: I'm running fine on dotnet48 + 1.0.2 (been playing for 30 minutes or so without issue). Possibly a save corruption issue ? maybe try a new game temporarily to confirm ? 1070 here as well.

@aradapilot yeah I just did some testing, and it seems that while dotnet48 does dramatically reduce save time, it also introduces a huge amount of stuttering after saving, and this lasts until you restart the game. Whereas without dotnet48, the game runs very smooth for me before and after saving. IDK if this problem will only affect people with less powerful systems/only 8 GB of RAM, but yeah its super weird.

Okay after a pc restart the game crashes when at the end of any fight and the loading times are better now, does the wine-server not exit if you exit the game ?

@tkamat got 32G here, not short on memory, or anywhere hardware wise. I need to figure out how to un-protontricks the game now, my saves weren't THAT slow before, but no manpage and -h doesn't say anything about removal

@aradapilot I have the same issue
@ElCaconym Are there any other modifications made other than renames, the hackish patch and adding dotnet480?
@tkamat Yes, the first time entering the game before the first save it runs as expected. I have a powerful 32 GB system and it still begins to stutters on very low settings so I don't think your system is causing this

@tkamat I've noticed that, too. Seems to be primarily confined to the map view; fights, walking around in towns/villages, etc. seem to be better.

@elovin Interesting. Was this an existing save or a new campaign?

@aradapilot There's unfortunately no easy way to reverse something installed via protontricks. Best bet is to backup your saves, delete or rename ~/.steam/steam/steamapps/compatdata/261550, run the game once to regenerate everything, and copy your saves back over.

@elovin wineserver _should_ stop eventually; occasionally it doesn't (especially when a crash occurs / an application hangs upon exiting). Doing "killall wineserver" or alternatively "wineserver -k" (with the right WINEPREFIX defined in the later case) can be used to make sure of it.

@simi2525 nothing that comes to mind; clean wine prefix, only using dotnet48. I'm using wine directly instead of proton but that shouldn't have an impact.

Does anybody else experience the unsuccessful logging in issue on any attempt on running multiplayer? It just keeps throwing those "login failed" messages at me after long periods of wait.

I haven't heard any reports of anyone being able to run multiplayer since they added Batlleye early on in the beta.

What are the odds that we ever get multiplayer running on Bannerlord? I used to play Warband all the time online in Ubuntu back in the day.

The game worked for a few patches after battleye was added because they still let you join games without it enabled. The last two weeks is when the closed beta stopped working on Linux probably coinciding with them making battleye mandatory. I think the best we can hope for short of a Linux native release is taleworlds overriding the battleeye check for wine installs or switching to VAC. Battleye proton compatibility is probably not in the cards since it does some kernelspace witchery.

@YellowApple it was an existing save, I started a new game now and now it does not crash anymore.

Any idea where the save files are at, haha?

@NovenTheHero .steam/steam/steamapps/compatdata/261550/pfx/drive_c/users/steamuser/My\ Documents/Mount\ and\ Blade\ II\ Bannerlord/Game\ Saves/Native/

I wrote a couple quick scripts to automate the various tinkerings discussed here and on ProtonDB, making sure to give credit (via URL) for each tweak.

• config-bannerlord-for-linux.bash
• config-steam-for-bannerlord.bash (@YellowApple)

@YellowApple WineHQ thinks that this is the cause of the input issue; if this is what you've fixed, can you cross-post there?
EDIT: Nevermind, seems you already have. :)

Mouse cursor fix is now in wine-staging.

Before people go removing their proton prefixes, make sure that no game is set to use said prefix as, if I recall correctly, that will cause issues.

Thank you all for your work on this. It is great to see how the Linux community is able to quickly troubleshoot issues and send patches upstream! I've compiled a modified proton version based on an earlier posted tutorial and it works out great.

For me saving also took awhile without dotnet48, while installing that library fixed that for me as well. I did run into some performance issues as discussed by others already. Last night I did notice that my xorg-session.log file was growing excessively, up to 25GB. I haven't been able to test if this issue is related to Bannerlord. Will test more in the evening.

I wrote a couple quick scripts to automate the various tinkerings discussed here and on ProtonDB, making sure to give credit (via URL) for each tweak.

* [config-bannerlord-for-linux.bash](https://github.com/MilesBHuff/Misc-code/blob/master/code/setup/wine/config-bannerlord-for-linux.bash)

* [config-steam-for-bannerlord.bash](https://github.com/MilesBHuff/Misc-code/blob/master/code/setup/wine/config-steam-for-bannerlord.bash) (@YellowApple)

Wouldn't the brightness screen be fixed with the mouse cursor fix? It was for me at least.

Maybe someone can test this but right now, visiting any smithy results in a corrupted savegame so that I get an average 15 fps but only on the campaign map, everything else works fine.

Edit: This persists after restarting the game or computer.

I did visit a smithy and nothing noticeable happened.
(Using yellowapple's proton build and have 32GB of RAM)

EDIT2: I turned off enable steam play for all other titles, this seemed to fix it. Somehow this overwrote the use of my forcibly set custom proton....

Holy crap... That was my issue the whole time! Now the patches are working for me! I even let my files validate overnight to get rid of my renames, and even the launcher works.

I've tried YellowApple's Proton, installing dotnet48 but it's still crashing my WM after character creation.

/edit
Here's the WM crash error I found relating to to it. The times it doesn't crash my WM, entire system freezes. i5-3570k, AMD RX 580 and 32GB RAM

kernel: [34245.701791] [drm:amdgpu_job_timedout [amdgpu]] ERROR ring gfx timeout, but soft recovered

I can confirm that adding dotnet48 fixed my save time issue. It went from 60s at the beginning to 90s+ after a few hours of play at maxed CPU usage down to <20 seconds and the CPU is no longer maxed out while saving.

Now there is a persistent microstutter in the campaign map that wasn't there before, battles seem to have no issues however. Annoying but definitely playable in this state. 32GB RAM / 1070ti, it's presumably not specs but I'll try playing around with some options later.

@evopls that's basically the same issue I'm facing. Bad fps and microstutter on the campaign map with all other scenes having basically no problems. I'm on a 1070 with 16GB RAM.

Edit: Okay, did a new Proton version via wine-tkg with the patch included in wine-staging, works out of the box now. Without dotnet48 installed everything is buttery smooth, except for saving (the already discussed issues). Will install dotnet48 now to see if this is the culprit for the stuttery experience on the campaign map.

@nilleairbar I noticed for me the stuttering is gone when I restart the game but then the very first time saving (manually or via autosave) triggers it again. Performance options made no difference.

@ekaats

Wouldn't the brightness screen be fixed with the mouse cursor fix? It was for me at least.

Yeah, it is. The three config lines I modify with config-bannerlord-for-linux.bash were from before the input fix was available. I'll comment the deprecated portions of the script.

Thanks for the script @MilesBHuff , really useful and it does get me to the main menu.
I've tried to gather info around, it is impossible to play Campaign yet right? Some people managed to do it, is it about the latest patches?

@Haywire-dev it is completely possible to play Campaign. Biggest issue is the savegame "bug" that causes saving to take up to several minutes. Installing dotnet48 via protontricks or similar aleviates that but possibly leads to some performance issues on the campaign map (see my or evopls' posts).

Edit: Oh and forgot to mention, of course you need a Proton version that either includes the wine patch mentioned in this issue or is based on the most recent wine-staging version that comes with the patch applied.

@nilleairbar

Edit: Oh and forgot to mention, of course you need a Proton version that either includes the wine patch mentioned in this issue or is based on the most recent wine-staging version that comes with the patch applied.

I'm sure I'll get flak for this, but how exactly do I make sure I have the right Proton? I've gotten as far as character creation before game/WM/computer crashes. I'm guessing the 5.0-local from OP/YellowApple does NOT have that included (yet)?

I'm getting occasional crashes too while browsering the menus / character creation. It ultimately seems to work, in a pretty shaky way, and mouse isn't working obviously, atleast in the menus. Didn't tested in game yet.

I'm sure I'll get flak for this, but how exactly do I make sure I have the right Proton? I've gotten as far as character creation before game/WM/computer crashes.

Right now the easiest version would be using the version of Proton @YellowApple shared. Safest option would be to build it yourself by using something like https://github.com/Frogging-Family/wine-tkg-git

Right now the easiest version would be using the version of Proton @YellowApple shared. Safest option would be to build it yourself by using something like https://github.com/Frogging-Family/wine-tkg-git

Yeah, I'm currently using YellowApple's Proton and have renamed the two .exe's, but still can't get past character creation. I'm looking into the wine-tkg stuff now though, maybe that'll help.

Otherwise, I'm just keeping an eye out here for anything else to try.

@evopls in case you're interested, did some testing just now and the stutter is seemingly caused by dotnet48. I'll play without it for now and have rather long saving times instead of that stutter on the campaign map.

Dotnet48 completely wrecks it for me... Can't even start the game anymore. I've uninstalled but I'm still facing the same campaign screen issues as the others.

Just out of curiosity @Foobar1923 what graphics driver are you using ?

I got an nvidia card, so that may different for you, but I had to update my graphics card driver, even though the one I was using was fairly recent. I went from total crash most of the time to playable but with framerate issue on some screens (all the screen where you have a close-up on a character, maybe it's subsurface scattering related ?).

@SylvainSoKette

I'm using stock amdgpu. I've updated my wine/winetricks/wine-staging etc and mesa (should) be up to date as well as vulkan.

Any guesses as to how long it'll be until these patches get pulled into Proton, now that some of it is starting to hit upstream wine?

@CrafterSvK Pretty sure that's the default as of Proton 5.0, no?

@CrafterSvK Pretty sure that's the default as of Proton 5.0, no?

Yeah I forgot. Anyway, everytime I click continue at the end of battle the game crashes.

Also I see no mention of safe mode in this thread. My game crashes whenever I open the "party" menu, but when restarting it asks me if I want to start in safe mode, and if I say yes it no longer crashes.

Does everyone else here use safe mode ?

I've yet to try safe mode; what does it actually do? My assumption would be that (like most games) it'd just crank down the graphics settings, but now you've got me wondering if it's also doing some extra exception handling or runtime safety checking.

EDIT: went ahead and tried it. Looks like it just resets engine_config.txt to defaults. Doesn't even disable mods.

Also I see no mention of safe mode in this thread. My game crashes whenever I open the "party" menu, but when restarting it asks me if I want to start in safe mode, and if I say yes it no longer crashes.

Does everyone else here use safe mode ?

I'd give it at least a try, but I don't get that option. Just the WM/PC crash.

I've been tesing some things and so far I've come to the same conclusions as the rest. dotnet48 seems to solve the saving issue but makes the rest of the game a lot less stable.

With dotnet48 I've had crashes when saving, loading, entering battles and towns. Some of these were crashes to desktop, some hang the process.

Without dotnet48 I've actually been able to play without many additional problems, just when saving the CPU usage goes to 100% for 1:40 minutes (on a Ryzen 1700). Afterwards everything is back to normal and I can continue just fine.

Note that the game saves on some specific moments. I've noticed it saves when going into battle (before showing the screen where you choose to battle yourself or let the dice decide), sometimes also after leaving a town or when handing in a quest.

Now I am testing with Redistributable for Visual Studio 2017 installed. So far it does not seem to matter in any way.

My graphical settings are the highest and safe mode does not change them.
I see no difference other than the lack of crash.
(i'm not using dotnet48 as the game wouldn't even launch)

Well it crashes the same with safe mode on my machine.

@Xxdzs I have those too since I'm using dotnet48, but only if I immediately open the menu after loading. If I play for a bit first it feels very stable.

Overall the slight stutter on the campaign map feels much better to me than the increasingly long save times without dotnet48, but that's probably personal preference. Not sure which of those two issues would be easier to fix.

Did some testing without dotnet48 and bypassing launcher.

Definitely some menus crashing still, saving on occasion still crashes after taking more than 45 seconds. Campaign map works great, little to no lag, though there's definitely something funky going on when the game is loading certain assets and menus. Had a friend try it as well on his Intel CPU and we both see small spikes in CPU usage trying to access certain menus along with the usual delays.

Disabling Subspace Scattering seems to help certain areas with dotnet48 though having this fix definitely seems more stable when compared to without dotnet48.

EDIT: Welp, nevermind, while helping mildly with stability, the game is still an unstable mess for me for the most part. After about 4-5 ingame dialogues the game locks up and crashes.

41819.290:0035:00c4:trace:seh:dump_unwind_info     handler 0x64478533758 data at 0x64478648688
41837.875:0035:00c6:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet
41837.875:0035:00cb:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet
41837.876:0035:00c9:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet
41838.732:0035:00c7:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet
41838.733:0035:00c1:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet
41838.829:0035:00bd:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet
41838.830:0035:00ca:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet
41838.925:0035:00c2:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet
41838.925:0035:00be:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet
41839.022:0035:00cc:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet
41839.023:0035:00bf:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet
41839.023:0035:00c3:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet
41839.119:0035:00cd:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet
41839.122:0035:00c5:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet
41839.122:0035:00ce:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet
41839.312:0035:00ba:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet
41839.312:0035:00c4:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet
41839.313:0035:00bc:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet
41839.313:0035:00c8:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet
41849.393:0024:0028:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\drivers\\WineUsd.sys" : builtin
41849.396:001c:0020:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\drivers\\winehid.sys" : builtin
41849.396:001c:0020:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\hidclass.sys" : builtin
41849.397:001c:0020:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\drivers\\winebus.sys" : builtin
41849.521:007b:007c:fixme:ntdll:EtwEventUnregister (deadbeef) stub.
41849.541:0074:0075:fixme:ntdll:EtwEventUnregister (deadbeef) stub.
pid 155001 != 155000, skipping destruction (fork without exec?)

2nd EDIT:

After changing some stuff around and patching from tkg, working rather well in stability, though my performance in the campaign map is in the teens with severe stuttering 80% of the time no matter what lower graphical settings are chosen.

Looks like things have quieted down here, which must mean most of us are enjoying the game. I'm running on a fairly beefy rig without dotnet48, and other than ~30 second save times, I haven't experienced a single crash.

Must be nice, from what I've seen though, there's loads of people that are either getting severe stuttering in the campaign map, dialogue menus/saving are causing CTD's and corrupt saves and a select few can't enter the smithy at all.

For myself, talking with the bandits results in a CTD 10% of the time, I get severe stuttering in the campaign map, but the battles run smoother than my friend's Windows machine with the exception of hiccuping from time to time.

Things should hopefully get ironed out as time goes on though, with it being in early access. After all, we're seeing a bunch of these issues in Windows as well. So I'm surprised that Bannerlord even runs as well as it does on WINE as it does now.

The game runs well but I get stuck infinite loading screens and get this error

Looks like things have quieted down here, which must mean most of us are enjoying the game. I'm running on a fairly beefy rig without dotnet48, and other than ~30 second save times, I haven't experienced a single crash.

Must be nice, from what I've seen though, there's loads of people that are either getting severe stuttering in the campaign map, dialogue menus/saving are causing CTD's and corrupt saves and a select few can't enter the smithy at all.

For myself, talking with the bandits results in a CTD 10% of the time, I get severe stuttering in the campaign map, but the battles run smoother than my friend's Windows machine with the exception of hiccuping from time to time.

Things should hopefully get ironed out as time goes on though, with it being in early access. After all, we're seeing a bunch of these issues in Windows as well. So I'm surprised that Bannerlord even runs as well as it does on WINE as it does now.

Have you tried testing with a completely clean proton environment? You can by running protontricks 261550 annihilate. It won't remove your saves. My excuses if this advice is akin to 'have you tried turning it off and on again', it did help for me though.

I haven't ran into crashes while playing without dotnet48, except for when trying to change settings, which lead to an immediate crash.

@mjm2000 The game has a lot of bugs of it's own. I've faced infinite loading screens on windows 10 too

@montyubuntu is the game patched to the latest version? Issues with ManagedStarter were only appearing for me and others (I believe) on version e1.0.0.0

@montyubuntu is the game patched to the latest version? Issues with ManagedStarter were only appearing for me and others (I believe) on version e1.0.0.0

I've just checked and the mouse fix is now included in wine-staging. The launcher still does not work for me so I did need to replace the launcher executable for the actual game executable.

I recommend asking on forums for help - let's keep this issue to investigating issues with the game only, not support as well. Quite a few people have it working now, so it's likely that something is different with your setup.

Interestingly, there's this reported known issue (on Windows I mean) on the official taleworlds forums:

Stuttering camera movement on the Campaign Map is under investigation.

Which may suggest the issue some people get with dotnet48 is not - or not entirely - related to wine. There are also numerous reports of the game stuttering more as a campaign is in progress, especially if you save and reload often; up until 1.0.2, reloading and saving 45 times would also ensure any further reload of the save concerned would crash the game. While 1.0.3 is supposed to have fixed that savegame bloat/corruption issue, there are also many report it hasn't (a given campaign lasts a bit longer with 1.0.3 but that's it, apparently).

Okay, so it might be that I found the fix for the campaign stutter. Would of course need a larger sample size than just me. Here's how I fixed it on a new prefix:

• Build my own Proton version (tkg) from source with the newest wine-staging build that includes the mouse cursor fix
• Installed dotnet40 via protontricks
• Installed vcrun2015 (see https://steamcommunity.com/app/261550/discussions/0/2149847049318759493/)
• Installed dotnet48
• Installed vcrun2017 (again see https://steamcommunity.com/app/261550/discussions/0/2149847049318759493/)

Now I don't have stutter on the campaign map, a fixed mouse cursor and saving takes a few seconds. Might be worth a shot for anyone else to try it.

Okay, so it might be that I found the fix for the campaign stutter. Would of course need a larger sample size than just me. Here's how I fixed it on a new prefix:

• Build my own Proton version (tkg) from source with the newest wine-staging build that includes the mouse cursor fix
• Installed dotnet40 via protontricks
• Installed vcrun2015 (see https://steamcommunity.com/app/261550/discussions/0/2149847049318759493/)
• Installed dotnet48
• Installed vcrun2017 (again see https://steamcommunity.com/app/261550/discussions/0/2149847049318759493/)

Now I don't have stutter on the campaign map, a fixed mouse cursor and saving takes a few seconds. Might be worth a shot for anyone else to try it.

I tried this, with 1.0.3, and performance was worse in some areas, better in others.

after updating to 1.0.4, the whole game runes flawlessly, it's incredible.

@nilleairbar Just tried this, and the all the stuttering is gone for me, with < 3 second saves! You are a genius, thanks for finding this out. Weirdly enough, I had all these packages installed on my last prefix, but I hadn't used proton-tkg and installed them in a different order, so maybe one of those things makes the difference. Either way, this has been one of the weirder problems I've seen in a while, and hopefully these fixes can get pushed to upstream wine/proton eventually.

Okay, so it might be that I found the fix for the campaign stutter. Would of course need a larger sample size than just me. Here's how I fixed it on a new prefix:

• Build my own Proton version (tkg) from source with the newest wine-staging build that includes the mouse cursor fix
• Installed dotnet40 via protontricks
• Installed vcrun2015 (see https://steamcommunity.com/app/261550/discussions/0/2149847049318759493/)
• Installed dotnet48
• Installed vcrun2017 (again see https://steamcommunity.com/app/261550/discussions/0/2149847049318759493/)

Now I don't have stutter on the campaign map, a fixed mouse cursor and saving takes a few seconds. Might be worth a shot for anyone else to try it.

I tried this, with 1.0.3, and performance was worse in some areas, better in others.

after updating to 1.0.4, the whole game runes flawlessly, it's incredible.

How do you install 2017 after 2015? I get errors in the 2017 installer saying that another version is already installed. I'm not even sure how to uninstall 2015 now.

It looks like Steam (at least via Proton) preinstalls the 2015 and 2017 VC runtimes. I get those errors now, too (though it's been awhile since I've tried).

On another note, it looks like for me the update to 1.0.4 made things substantially worse in terms of map framerate (EDIT: forgot to clarify it's only when time is progressing; when paused it runs at around 30fps). Seems to be something broken with multithreading; GPU's at 1% utilization according to the DXVK HUD, and only one core seems to be pegging at a time. Also, apparently htop reports the game using 1.2TB of RAM now, which is both horrifying and fascinating:

Might be a mod, though (since I've been testing those). Might also just be something wonked with my save game again. Logs don't show any particular smoking guns there.

EDIT: turns out the stutter was from the ClanTweaker mod. Some other people complained about framerate drops, too, though not nearly to the degree I experienced.

1.2 TB virtual memory size is slightly concerning and may indicate a memory leak, but almost none of that is actually _mapped_ to physical pages (i.e., actual RAM) -- you are only using 17 out of 32 GB of RAM. So in some ways this is harmless, unless the process keeps requesting more virtual memory, then it might run out of 64-bit addresses and crash.

It looks like Steam (at least via Proton) preinstalls the 2015 and 2017 VC runtimes. I get those errors now, too (though it's been awhile since I've tried).

On another note, it looks like for me the update to 1.0.4 made things substantially worse in terms of map framerate. Seems to be something broken with multithreading; GPU's at 1% utilization according to the DXVK HUD, and only one core seems to be pegging at a time. Also, apparently htop reports the game using 1.2TB of RAM now, which is both horrifying and fascinating:

Might be a mod, though (since I've been testing those). Might also just be something wonked with my save game again. Logs don't show any particular smoking guns there.

I just noticed this comment on reddit:

"Yeah, it happened to me as well, it switched to my intel instead of Nvidia (and even that gives me like 128 MB of power only, like wtf?) and I can't change it back.
So sorry to hear it happens to you too, mate, but on other hand, I feel really better then my Nvidia didn't burn out xD."

It seems like the game is trying to use the integrated graphics on this user's processor. Interesting

This machine doesn't have an integrated GPU at all, so that doesn't seem like a likely culprit in my case, alas.

* Build my own Proton version (tkg) from source with the newest wine-staging build that includes the mouse cursor fix

My lack of linux-knowledge is showing, but this solution is for arch users only, right? The only thing I found for "Proton version (tkg)" what this and it refers to PKGBUILDS which are an arch thing, right? Is there a way to do the same thing on kde neon (ubuntu 18.04 base)?

* Build my own Proton version (tkg) from source with the newest wine-staging build that includes the mouse cursor fix

My lack of linux-knowledge is showing, but this solution is for arch users only, right? The only thing I found for "Proton version (tkg)" what this and it refers to PKGBUILDS which are an arch thing, right? Is there a way to do the same thing on kde neon (ubuntu 18.04 base)?

Yeah, it's an arch thing. I did notice on the readme that he did say it was possible without arch, just maybe a bit more involved.

Also, as of a couple hours ago, there was a bug with proton-tkg making it unable to build anyways.

* Build my own Proton version (tkg) from source with the newest wine-staging build that includes the mouse cursor fix

My lack of linux-knowledge is showing, but this solution is for arch users only, right? The only thing I found for "Proton version (tkg)" what this and it refers to PKGBUILDS which are an arch thing, right? Is there a way to do the same thing on kde neon (ubuntu 18.04 base)?

Yeah, it's an arch thing. I did notice on the readme that he did say it was possible without arch, just maybe a bit more involved.

Also, as of a couple hours ago, there was a bug with proton-tkg making it unable to build anyways.

It is an arch thing, but the executable only creates a tarball that you can extract where you want (e.g. in the directory suggested in the main comment, under "current workaround"). If you have arch it can do that automatically for you, but that's not a big step. The problem with it was resolved within an hour and it now builds fine.

hi,
thanks to the work of @YellowApple , i was able to compile a working proton-tkg on ubuntu, followed the steps of @nilleairbar and can play the game.

nvidia gtx 1070 gets me about 30fps at 3840x2160 on overland and on small skirmishes, conversations inside taverns or villages etc.

larger fights about 20vs20, conversations on the overland map, shops, smithing, sometimes inventory stutter at about 2~3 fps

crashes do still happen for me, but rarely

edit: setting the settings to medium resolves the 2~3 fps problem, saving takes about 3 seconds max

* Build my own Proton version (tkg) from source with the newest wine-staging build that includes the mouse cursor fix

My lack of linux-knowledge is showing, but this solution is for arch users only, right? The only thing I found for "Proton version (tkg)" what this and it refers to PKGBUILDS which are an arch thing, right? Is there a way to do the same thing on kde neon (ubuntu 18.04 base)?

Yeah, it's an arch thing. I did notice on the readme that he did say it was possible without arch, just maybe a bit more involved.
Also, as of a couple hours ago, there was a bug with proton-tkg making it unable to build anyways.

It is an arch thing, but the executable only creates a tarball that you can extract where you want (e.g. in the directory suggested in the main comment, under "current workaround"). If you have arch it can do that automatically for you, but that's not a big step. The problem with it was resolved within an hour and it now builds fine.

Are there any new changes in wine-stable that seem to benefit Bannerlord? I already have a custom build with only YellowApple's changes, just wondering if it would be worth making a new one from staging.

Okay, so it might be that I found the fix for the campaign stutter. Would of course need a larger sample size than just me. Here's how I fixed it on a new prefix:

• Build my own Proton version (tkg) from source with the newest wine-staging build that includes the mouse cursor fix
• Installed dotnet40 via protontricks
• Installed vcrun2015 (see https://steamcommunity.com/app/261550/discussions/0/2149847049318759493/)
• Installed dotnet48
• Installed vcrun2017 (again see https://steamcommunity.com/app/261550/discussions/0/2149847049318759493/)

Now I don't have stutter on the campaign map, a fixed mouse cursor and saving takes a few seconds. Might be worth a shot for anyone else to try it.

I tried this but now the game seems to want to a use an intel intergrated graphics I dont even have? Game is veryyyyy slow and there doesnt seem an option to change graphics card.

Okay, so it might be that I found the fix for the campaign stutter. Would of course need a larger sample size than just me. Here's how I fixed it on a new prefix:

• Build my own Proton version (tkg) from source with the newest wine-staging build that includes the mouse cursor fix
• Installed dotnet40 via protontricks
• Installed vcrun2015 (see https://steamcommunity.com/app/261550/discussions/0/2149847049318759493/)
• Installed dotnet48
• Installed vcrun2017 (again see https://steamcommunity.com/app/261550/discussions/0/2149847049318759493/)

Now I don't have stutter on the campaign map, a fixed mouse cursor and saving takes a few seconds. Might be worth a shot for anyone else to try it.

I tried this, with 1.0.3, and performance was worse in some areas, better in others.
after updating to 1.0.4, the whole game runes flawlessly, it's incredible.

How do you install 2017 after 2015? I get errors in the 2017 installer saying that another version is already installed. I'm not even sure how to uninstall 2015 now.

I have the same issue. The game however runs quite fine apart from some freezes every now and then. I am running on a 1080ti on arch.

Okay, so it might be that I found the fix for the campaign stutter. Would of course need a larger sample size than just me. Here's how I fixed it on a new prefix:

• Build my own Proton version (tkg) from source with the newest wine-staging build that includes the mouse cursor fix
• Installed dotnet40 via protontricks
• Installed vcrun2015 (see https://steamcommunity.com/app/261550/discussions/0/2149847049318759493/)
• Installed dotnet48
• Installed vcrun2017 (again see https://steamcommunity.com/app/261550/discussions/0/2149847049318759493/)

Now I don't have stutter on the campaign map, a fixed mouse cursor and saving takes a few seconds. Might be worth a shot for anyone else to try it.

I tried this, with 1.0.3, and performance was worse in some areas, better in others.
after updating to 1.0.4, the whole game runes flawlessly, it's incredible.

How do you install 2017 after 2015? I get errors in the 2017 installer saying that another version is already installed. I'm not even sure how to uninstall 2015 now.

I've had the same problem from the get-go. Just use protontricks 261550 uninstaller.
Sadly dotnet makes the game perform much worse for me, but save time is indeed faster, takes around 30 seconds.

You need a fresh prefix (not created by Steam) to install vcrun2015 and vcrun2017 (and dotnet40?). I installed those and then dotnet48 as instructed but the faster saves (still) come at the price of annoying framerate instability (rapid stuttering). To me I almost prefer to take a break while it's saving and go do something else to suffering performance issues, but that's just me.

Is anyone else getting very frequent crashes when doing anything involving a siege? It seems less likely if the AI is leading the siege, but when I am attacking or especially defending it is very likely the game crashes (multiple times). I can upload some logs later, just wanted to know if this was something other people were experiencing too.

Is anyone else getting very frequent crashes when doing anything involving a siege? It seems less likely if the AI is leading the siege, but when I am attacking or especially defending it is very likely the game crashes (multiple times). I can upload some logs later, just wanted to know if this was something other people were experiencing too.

Yes; well, i'm getting more frequesnt crashes since e1.0.4, and sieges seem to be a trigger. For me; AIs lead all the segies because i am too small

Is anyone else getting very frequent crashes when doing anything involving a siege? It seems less likely if the AI is leading the siege, but when I am attacking or especially defending it is very likely the game crashes (multiple times). I can upload some logs later, just wanted to know if this was something other people were experiencing too.

I have a savegame in the middle of a siege and it crashes after a couple of seconds 100% of the time. The same save game plays fine on windows. After loading a previous save though, I went through a couple of sieges as part of an army and it didn't crash

Haven't gotten any crashes during sieges, but when you start and are deploying one the mouse is wonky, flickering constantly and doesn't register clicks. Alt-tabbing in and out makes it register a click though, so you can get past the deploy screen.

Is the pre-compiled patch in the original post no longer working?

@Ryan-Vablet It works, at least it should as far as I'm aware. Although some seem to have a better experience with their own complied version of proton-tkg (and other things mentioned in this comment).

The notable thing is that installing dotnet48 makes saving much faster, something that takes minutes for some, but cause performance issues in some cases. The other things in the comment might sort out the performance issues, yet again in some cases.

But in the end we don't know of any specific thing with proton-tkg that would help or if it really does, it's more up to date though, so there may very well be something useful in it. Up to date rarely hurts at least.

For the crashes, it seems, we do not have any solid fixes. But it's possible that that is simply issues with the game itself, that may be the case with some of the performance issues as well.

I installed Bannerlord today (e1.0.5) and played it with proton-tkg for 5 hours. This is my experience:

First I tried playing Bannerlord without installing the dotnet packages. I had a lot of stuttering and also really long save times as expected. I also experienced long loading times.

Then I installed dotnet40 and dotnet48 packages via protontricks. Save times and loading times significantly reduced. Stuttering was also reduced slightly. Game was pretty much playable at this point. I also tried installing vcrun2015 and vcrun2017, but couldn't because they were already installed (probably automatically by steam).

However after a few hours I started having more and more frequent crashes, usually when waiting in town. Based on what I've read here so far I think the crashes are related to that I only have 8 GB of ram. Choosing the medium setting preset seems to have fixed it (haven't had crashes since) and also resulted in less stuttering.

OS: Arch Linux
KERNEL: 5.5.13-arch2-1
CPU: AMD Ryzen 5 2600 Six-Core
GPU: Radeon RX Vega 56
GPU DRIVER: 4.6 Mesa 20.0.4
RAM: 8 GB

update as far as 1.0.5 goes (ubuntu 19.10)
it runs perfectly, no performance issues or crashing, with the managedstarter renames, but without any protontricks; using yellowapple's custom proton (in the issue description)
if I install dotnet40+48 to get around the saving issue, performance is crap and the game isn't really playable. I'd love to try this tkg workaround, but apparently that's an arch-only thing? both vcruns are installed by default.

I was able to get through a siege or two (led by the AI) on the newest patch with the steps described by YellowApple above. Will edit this comment when I play next and do a player led siege.

After updating to 1.05 (using YellowApple proton, no dotnet installs), I started crashing at the loot screen after fighting looters and at the start of a large field battle. The former happened about 3 times, the latter once (I stopped trying after). There were a couple new errors in the log, and after crashes the game still showed as playing (also the crash reporter crashed):

[000000000000004A:] EXCEPTION handling: System.IO.FileNotFoundException: Could not load the file 'TaleWorlds.PSAI.XmlSerializers'.
...
[000000000000003F:] EXCEPTION handling: System.PlatformNotSupportedException: System.Management currently is only supported for Windows desktop applications.

Update:
I restarted my computer, won a fight on a previous save, reloaded the one that had been crashing and got in a different fight with no issue.

update as far as 1.0.5 goes (ubuntu 19.10)
it runs perfectly, no performance issues or crashing, _with_ the managedstarter renames, but _without_ any protontricks; using yellowapple's custom proton (in the issue description)
if I install dotnet40+48 to get around the saving issue, performance is crap and the game isn't really playable. I'd love to try this tkg workaround, but apparently that's an arch-only thing? both vcruns are installed by default.

@aradapilot The proton-tkg build script works fine on non arch systems as well. Just be sure to install wine-tkg's dependencies.

I've gotten somewhat setup using @YellowApple 's Proton build. I did install dotnet40 and then dotnet48 (which seems to replace the older version), which I think sped up saving but performance was so-so especially on the campaign map. An interesting note, I tried to uninstall the dotnet verbs, but then the game let me know that it required at least dotnet 4.0. Reinstalling dotnet40 was not enough to get the game to launch properly, and somehow leaves protontricks thinking that the 4.8 version is still installed. I uninstalled dotnet40 but that did not fix it. In the end I annihilated the environment and did not install dotnet, which has much better performance at least, though my settings are low for my specs I think. Saving takes maybe 60 seconds rather than 30 seconds with dotnet.

Another thing to watch out for is the frame limiter! I thought I was stuttering even on low settings, but it turned out my framerate was higher than my monitor (60 Hz) but very choppy. Capping to monitor refresh rate helped a lot.

Specs:
R5 2600
RX 580 4gb
16 gb RAM
Linux Mint 19.3 with 5.5 kernel
Mesa 20.1 from Oibaf PPA

EDIT: Things also seem significantly more stable without dotnet so I think I will stick with it. Also, safe mode just seems to reset the brightness test and the graphics settings and I didn't notice any stability improvement so I wouldn't bother enabling it after a crash.

So I don't know if it was protontricks 261550 vcrun2019 or using the latest Proton-GE, but either or both of those have almost entirely eradicated any remaining stuttering for me. Manual saves take a few seconds, while autosaves seem to be instantaneous; neither cause any sort of residual lag. I'm also getting 10× the FPS in the Inventory screen (was previously pretty atrocious).

So yeah, for anyone else still using my build: go grab GloriousEggroll's instead; it should work at least as well as mine, if not better (given that it incorporates a whole slew of other enhancements for other games, too), and is substantially less likely to drink from your skull or eat your liver. And also consider trying protontricks 261550 vcrun2019 if you're still getting dotnet48-related stuttering.

Do you use vcrun2019 with or without dotnet48?

Do you use vcrun2019 with or without dotnet48?

With.

My exact order of operations for the current prefix I'm using:

• Ran the launcher at least once under my build (to generate a prefix)
• protontricks 261550 uninstall and uninstall everything
• protontricks 261550 dotnet40
• protontricks 261550 vcrun2015
• protontricks 261550 dotnet48
• protontricks 261550 vcrun2017
• Ran the game again at least once under my build
• Switched to Proton 5.5-GE-1
• protontricks 261550 --force vcrun2019 (since it technically conflicts with vcrun2015)
• Ran the game again and observed a marked improvement

I haven't tested the simpler path of protontricks 261550 doetnet48 && protontricks 261550 vcrun2019 on a fresh prefix yet. My hope is that it works like a charm.

Since I can't seem to get out of dependency hell for compiling the tkg builds these prebuilds are a blessing for me personally.

My previous approaches:

• Use YellowApples' custom Proton build
  ---> Smooth game, but 60s save times for a new game. ~90s after 10h or so in the savegame.

• Install dotnet48
  ---> Small stutter on the campaign map and ~30s save times. Absolutely playable for me.

I just swapped to Proton 5.5-GE-1 and made no further modifications, everything worked right out of the box. Stutter on the campaign map is gone and save times are ~3s.

All that being said I still experience crashes here and there (the game for example crashed while I alt-tabbed and wrote this comment) but that might just be early access related. Time to hope this works as flawlessly for everyone else. <3

@evopls Might be the same issue I had:
https://www.reddit.com/r/linuxquestions/comments/fun9qr/did_i_bork_protontkg/

After building my proton I had ~5 sec save times, haven't fully played around with the new 5.5 GE-1 save time yet, but man is this game still crashing a crap ton from random things later in the game. Even on Windows it's a genuine mess, still there's hope since it's early access and we're essentially playing a (what seems like an early) beta version.

I'm actually really impressed that despite the bugginess, the game runs very well. The last patch seems to of handled the instant CTD for certain dialogues and entering the smithy and the patch before that significantly helped the stuttering in the campaign map.

I still have issues with only dotnet48 with Proton-GE or not but with vcrun2019 its mostly stable.

I didn't need the other steps Proton-GE + dotnet48 + vcrun2019 works for me

protontricks 261550 dotnet48

protontricks 261550 --force vcrun2019

vcrun2019 alone wasn't enough I needed both dotnet48 + vcrun2019

I don't seem to have vcrun2019 available to install. I just reinstalled protontricks-git from aur, so it should be the most recent version. How do i get vcrun2019 installed and/or available to install from protontricks?

@yarbelk Its from winetricks, update winetricks with

# protontricks will pass --self-update to winetricks
protontricks 261550 --self-update

edit: I dont think I had to do the update when I reinstalled the prefix, maybe try and reinstall that with steam

--self-update will grab the latest from git/master see
https://github.com/Winetricks/winetricks/blob/master/src/winetricks#L1148

The latest winetricks is 20191224 (https://github.com/Winetricks/winetricks/releases) which is what I have installed. I'm on NixOS so winetricks --self-update doesn't work (thus neither would protontricks). I still have no vcrun2019 available.

The latest winetricks is 20191224 (https://github.com/Winetricks/winetricks/releases) which is what I have installed. I'm on NixOS so winetricks --self-update doesn't work (thus neither would protontricks). I still have no vcrun2019 available.

Why does being on NixOS prevent winetricks --self-update from working? Maybe run it as root -- I'm on Ubuntu and sudo winetricks --self-update worked.

Anyway, you can grab the latest code from winetricks git. The version that has vcrun2019 for me is 20191224-next - sha256sum: 472eba29dbf056c87afd39a70426886064040e0bc2c3b63c17baf469b0bf2be2. It appears vcrun2019 is not in any released version of winetricks, but --self-update definitely does grab the latest (from git, not from the releases).

Here is the commit in the "-next" version (currently unreleased) that has vcrun2019: https://github.com/Winetricks/winetricks/commit/94edaddc039c205a98c2a620399a741c7a70ce02

Why does being on NixOS prevent winetricks --self-update from working? Maybe run it as root -- I'm on Ubuntu and sudo winetricks --self-update worked.

It's because NixOS is a declarative OS and doesn't use the standard Unix file system hierarchy. It uses a special chroot environment for applications like Steam which make presumptions and wants to control its own environment. The winetricks package is installed in a read-only path in /nix/store/ where all packages are isolated based on their hash. It's impossible for it to update itself.

Anyway, you can grab the latest code from winetricks git

I'll try to update the package revision and see if that works. Thanks!

Edit: It worked insofar as that vcrun2019 exists, but trying to install it I get wrong checksum:

sha256sum mismatch! Rename /home/ludvig-new/.cache/winetricks/vcrun2019/vc_redist.x86.exe and try again.

@lboklin if you don't feel like removing things back up the cached dir

mv ~/.cache/winetricks/{,bak.}vcrun2019

then try and install

@lboklin if you don't feel like removing things back up the cached dir

mv ~/.cache/winetricks/{,bak.}vcrun2019

then try and install

Tried that without success, but I ran it with wine (I think that installed it correctly? I set all the env variables I could think of), but I digress. This is specific to my system and I don't want to clutter this thread. I'll figure it out.

I keep getting this now:

d3d_device_->CreateTexture2D at
rglGPU_device::create_texture_from_image
failed!
Invalid parameter.

Last Executed Marker: Only supported with nVidia
Gpus and Windows 10.

(bizarre line wraps added for extra verisimilitude)

I am running dotnet48 vcrun2019 (thanks @chrisrhayden), and the ge-5.5 proton

i have a 1080ti, which i strongly suspect qualifies as nVidia.

It's weird because anyone who's getting this error on Windows is disabling Nvidia/Radeon Sharpening for a possible fix, the only thing I know of that's remotely close in our Nvidia Panel is Conformant Texture Clamping for borderless 2d textures, which is not at all being used AFAIK.

Some are saying to drop back to e1.0.3 to avoid the issue for now, you can select this by Properties->BETAS->Select e1.0.3 from the dropdown menu. I'd say try it, I've been getting weirder and weirder errors since the last update, whereas I played for 3 whole hours the previous patch. Not saying that _is_ the cause, but it doesn't hurt to check.

Tried out the most recent GE release both with and without dotnet48 and vcrun19. It seems to get stuck on the first loading screen with these errors:

[0405/100010.058616:ERROR:frame_sink_video_capturer_impl.cc(206)] Invalid resolutions constraints: 0x0 must not be greater than 0x0; and also within media::limits.
eventfd: Too many open files

Sometimes either the GE or YellowApple builds will let me know this:

But after dismissing the dialog 2-3 times the game still launches and runs as normal. Saying yes doesn't seem to provide any additional information?

Going back to the YellowApple build with those two verbs installed has good performance and ~10-15 second saves, I've not tested stability much yet but I think I will go with it for now.

I can no longer install dotnet48 while I was able to previously... I get this popup:

Why would this happen now?

Edit: Creating a new prefix manually and then installing dotnet48 and 2019 before launching via Steam worked.

Hello @Gyrfalcon5, please run ulimit -Hn and verify it gives you a high value and not 4096.

Hello @Gyrfalcon5, please run ulimit -Hn and verify it gives you a high value and not 4096.

That gives me 4096. Is that a problem? I think I saw something on here about raising a value like that but I'm not sure.

Yes, please give https://github.com/zfigura/wine/blob/esync/README.esync a read.

I used YellowApple's instruction above and the game runs fine, but I still don't have a functioning mouse cursor. Is there an essential step I missed perhaps? I was resigned to just use my controller for menus, but as soon as I get to the map after character creation I get a notification that I can not click away with my controller.

I used YellowApple's instruction above and the game runs fine, but I still don't have a functioning mouse cursor. Is there an essential step I missed perhaps? I was resigned to just use my controller for menus, but as soon as I get to the map after character creation I get a notification that I can not click away with my controller.

On another system it works sometimes and sometimes not. Restarting the game has fixed it. shrug

I used YellowApple's instruction above and the game runs fine, but I still don't have a functioning mouse cursor. Is there an essential step I missed perhaps? I was resigned to just use my controller for menus, but as soon as I get to the map after character creation I get a notification that I can not click away with my controller.

Yeah for some reason the mouse does not work on my system either the first time I launch the game after logging into Steam. If I relaunch the game it starts working.

I used YellowApple's instruction above and the game runs fine, but I still don't have a functioning mouse cursor. Is there an essential step I missed perhaps? I was resigned to just use my controller for menus, but as soon as I get to the map after character creation I get a notification that I can not click away with my controller.

Yeah for some reason the mouse does not work on my system either the first time I launch the game after logging into Steam. If I relaunch the game it starts working.

What the heck? Alright, yeah. It's just the first time after starting Steam. How curious.

Update: I had to delete and recreate the prefix manually without Steam in order to install dotnet48 and vcrun2019. I could then launch via Steam and both performance and saving seems to work well (tested only for a minute so far). This is with Proton-GE and winetricks built from this revision.

Yes, please give https://github.com/zfigura/wine/blob/esync/README.esync a read.

Followed the directions there and Proton GE is working with much better performance! Stability could use some work though, I had a crash when looking up a character after a minute or two. May try clearing out my prefix and reinstalling stuff to see if that helps, although I know the game itself if pretty unstable right now.

EDIT: Looking up a character is a super consistent crash, with the following output when I run Steam from the command line:

mesa: for the   --simplifycfg-sink-common option: may only occur zero or one times!
mesa: for the   --global-isel-abort option: may only occur zero or one times!
ERROR: ld.so: object '/home/roland/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
>>> Adding process 5460 for game ID 261550
ERROR: ld.so: object '/home/roland/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
>>> Adding process 5468 for game ID 261550
wine: Unhandled page fault on execute access to 000000001E770198 at address 000000001E770198 (thread 0035), starting debugger...
ERROR: ld.so: object '/home/roland/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.

EDIT2: Further information about the crash from a fresh Proton-GE environment:

=================================================================
    Native Crash Reporting
=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.
=================================================================

=================================================================
    Managed Stacktrace:
=================================================================
domain required for stack walk
=================================================================

EDIT 3: Trying out dotnet48 again to see if that will resolve the extra information error.

EDIT 4: Complaint about mono is gone, but stability issues with the encyclopedia as well as the arena standings are persistent. I think it has something to do with the extra dialog coming over the campaign map but I'm not sure.

How does one install vcrun2019 ? when I run protontricks 261550 vcrun2019
I always get "Unknown arg vcrun2019"
(im using the latest protontricks)

How does one install vcrun2019 ? when I run protontricks 261550 vcrun2019
I always get "Unknown arg vcrun2019"
(im using the latest protontricks)

Have you also updated winetricks? I think people were having trouble with protontricks being up to date but talking to an outdated winetricks earlier. It should be sufficient to just do winetricks --self-update, you may need sudo.

Getting a lot of crashes with proton-GE, dotnet48 and vcrun2019.
Output in terminal:

wine: Unhandled exception 0xe0434352 in thread 3f at address 000000007B00FDCE (thread 003f), starting debugger...

Edit:
I think enabling safe mode (it asks you when you launch again after it crashed) helped avoid an otherwise unavoidable crash in my campaign (some event probably triggered it).

Edit 2:
Zooming far out on the campaign map often causes a crash (happened at least 3 times in the last hour).

Edit 3:
It's basically unplayable. Had 5+ crashes in the last half hour. Not seeing anything useful in the output; just

wine: Unhandled exception 0xe0434352 in thread 74 at address 7B00DE67 (thread 0074), starting debugger...

Edit 3:
Ok, now I crashed in the settings menu:

wine: Unhandled page fault on execute access to 0000000000000000 at address 0000000000000000 (thread 003b), starting debugger...

Because the game would suddenly forget and refuse to save my settings I added read-permissions of the saves and settings directory to group (I keep it symlinked to outside of the prefix so I don't accidentally wipe it). After that the game remembered my settings. May be related to the last crash in the settings menu.

@lboklin
I also have crashes every few minutes 5-30 when using dotnet48 and vcrun2019 and its always on the world map.
proton-GE and proton-tkg have this issue, proton-GE did not improve anything for me.

@craftyguy Except if you want winetricks to update itself, then depends on how you originally installed it.

$ winetricks --self-update
------------------------------------------------------
You don't have the proper permissions to run this command. Try again with sudo or as root.
------------------------------------------------------

If you got it from your package manager, then it most likely resides in /usr/bin, and you _do_ need root access to update it there.

Just a suggestion. If anyone is requiring root permissions to update winetricks. Use sudo -E to preserve your environment.

@lboklin

I'll try to update the package revision and see if that works. Thanks!

Hello fellow nixos user - how'd you do this?

"how to update winetricks" on your distro of choice seems off-topic here. Go ask in your distro's public forum, or install winetricks locally for your user.

@lboklin

I'll try to update the package revision and see if that works. Thanks!

Hello fellow nixos user - how'd you do this?

While I agree it's offtopic, I'll just take a moment to respond to save you some time.

1. clone the nixpkgs repo
2. cd into it
3. edit pkgs/misc/emulators/wine/sources.nix as below
4. nix-env -f . -iA winetricks

diff --git a/pkgs/misc/emulators/wine/sources.nix b/pkgs/misc/emulators/wine/sources.nix
index 0e3eb2ce698..aeb0cdef883 100644
--- a/pkgs/misc/emulators/wine/sources.nix
+++ b/pkgs/misc/emulators/wine/sources.nix
@@ -56,10 +56,10 @@ in rec {

   winetricks = fetchFromGitHub rec {
     # https://github.com/Winetricks/winetricks/releases
-    version = "20191224";
-    sha256 = "07q3zh2i3xqzpg46ljarhq3a4ha9zwpc6jqzvly0kfglkh3b3v66";
+    version = "20191229";
+    sha256 = "0vzb9fxnrmbv1x86q7ri0xx4slvmbyjsf59y9hl48gxyr5kld68q";
     owner = "Winetricks";
     repo = "winetricks";
-    rev = version;
+    rev = "94edaddc039c205a98c2a620399a741c7a70ce02";
   };
 }

I've got a fresh system with:

Bannerlord freshly installed from steam
wine freshly installed
winetricks freshly built from source
protontricks fresh install using the above winetricks

❯ wine --version
wine-5.0
❯ winetricks --version
20191224-next - sha256sum: f183161a93a92f2fe38ec90b723055d5a2ca691c85400874879b0ef779a7f46e
❯ protontricks --version
protontricks (1.4.1)
❯ rm -rf ~/.steam/steam/steamapps/compatdata/261550
❯ rm -rf ~/.wine

I've installed the 5.5-GE-1 version of proton, and moved it to .steam/root/compatibilitytools.d

Then I've run:

❯ steam # Launched game from steam with Proton-5.5-GE-1 selected
...
Proton: Upgrading prefix from None to 5.5-GE-1 ($HOME/.local/share/Steam/steamapps/compatdata/261550/)
...
Unhandled Exception:
System.IO.FileNotFoundException: Could not load file or assembly 'ManagedStarter, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies.
File name: 'ManagedStarter, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'
[ERROR] FATAL UNHANDLED EXCEPTION: System.IO.FileNotFoundException: Could not load file or assembly 'ManagedStarter, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies.

❯ cp ~/.steam/steam/steamapps/common/Mount\ \&\ Blade\ II\ Bannerlord/bin/Win64_Shipping_Client/Bannerlord.exe ~/.steam/steam/steamapps/common/Mount\ \&\ Blade\ II\ Bannerlord/bin/Win64_Shipping_Client/ManagedStarter.exe
❯ cp ~/.steam/steam/steamapps/common/Mount\ \&\ Blade\ II\ Bannerlord/bin/Win64_Shipping_Client/Bannerlord_BE.exe ~/.steam/steam/steamapps/common/Mount\ \&\ Blade\ II\ Bannerlord/bin/Win64_Shipping_Client/ManagedStarter_BE.exe

At this point the game launches

❯ killall wineserver
❯ protontricks 261550 dotnet48
------------------------------------------------------
You are using a 64-bit WINEPREFIX. Note that many verbs only install 32-bit versions of packages. If you encounter problems, please retest in a clean 32-bit WINEPREFIX before reporting a bug.
------------------------------------------------------
Using winetricks 20191224-next - sha256sum: 21f89159ef089f5e8c70568b34c40973f6cdc7de04832f3d79c9b74fcbfc32ed with wine-5.0 and WINEARCH=win64
Executing w_do_call dotnet48
# ..... fails

Do I need to somehow tell the version to be 32 bit? The directory is created by steam, do I need to manually create it with winecfg using WINEARCH=win32? It appears bannerlord is 64 bit, so I'm not sure how that would work?

@TannerYoung looks like you are running version 1.0.0 of the game.

You can either update the game to the latest version or rename ManagedStarter.exe to ManagedStarter.exe.old (or anything really) and then copy/symlink/rename Bannerlord.exe to ManagedStarter.exe to fix your issue.

To the people still having crash issues after installing the various vcrun versions, double check your windows version in winecfg. Mine got set to WinXP during one of the installs and changing back to windows 10 fixed a lot of my crashes.

I've had a lot of luck so far with dotnet472 and not dotnet48:

protontricks 261550 dotnet472

I'm using Proton from Valve (@ proton_5.0-next tag), with @YellowApple's patch from wine-staging applied, and not these random Proton builds that people are distributing. I also did not install vcrun2019.

Saves are around 5 seconds for me, and the game hasn't crashed for me since using this configuration (I'm running the latest patched version of game with today's hotfix).

It's worth pointing out that the game dependencies posted on the forum by Taleworlds are .NET 4.7.2, vcrun 2015 & 2017: https://forums.taleworlds.com/index.php?threads/installing-missing-necessary-dependencies.407126/

There's nothing about having .NET 4.8 or vcrun 2019..

@craftyguy: thank you so much for this ! with dotnet48 the game was running mostly fine but every campaign would eventually end up crashing/freezing eventually, to the point where playing further along was close to impossible. With dotnet472, this issue seems to be solved completely. Also, I'm now seeing notifications to the right of the screen (like when someone is raising an army somewhere), which wasn't the case with dotnet48 - didn't even know the feature existed.

I'm also not seeing stuttering on the map (though I never did even with dotnet48).

Can confirm @craftyguy's findings; Proton 5.5-GE-1 and protontricks 261550 dotnet472 is enough to fix both the stuttering and the long save times. Nice catch!

I'm noticing that I'm getting a consistently-reproducible crash when viewing the encyclopedia page for a town in an existing save and intermittent crashes in the inventory screen, both on my previous prefix (with vcrun201(5|7|9) and dotnet48) and the current (with just dotnet472). Gonna try a new game (sigh) and see if it persists.

I'm not sure what to make of what's going on, on my end. I feel like I'm back at square one, where mouse input is completely non-functional no matter proton version I run, no matter what windows packages I install. Even YellowApple's old build, which was working just fine before, doesn't function.

Going to have to try this dotnet472, see if it helps solve my issues with these random crashes on a new game. Figure my old game is just borked, since it's gone through several updates now. I had it playing for a few hours and some of my friends on Windows are reporting the same crashes on older saves.

With dotnet472 I can also confirm that saving is fast, but I crashed before being able to make any any substantial observations about performance, so it seems about as unplayably crashy as with vcrun2019 and dotnet48.

Update:
It performs well and saving is fast as noted but indeed the stability is not great. Plenty of crashes on campaign map.

Offtopic, but I want to quickly help any NixOS user by sharing this script for my current prefix setup: https://gist.github.com/lboklin/c735c867a00fbb2d30bb89dbcd910c03

Should've mentioned: my no-crashing game was only after starting a new campaign on 1.0.5 (before the following hotfix but after the actual 1.0.5 update). I've also noticed slightly longer (+~50%) loading times between scenes with dotnet472 compared to dotnet8, which is really not a big deal given the vastly increased stability.

@Ampsersanddd other people have mentioned this but it is common for the game to not respond to mouse input even after the fix on first launch for some reason; restarting it fixes it. Maybe that's your issue ?

dotnet472 crashes with save files from 1.0.4 (it took however around 10 minutes while I was in the town menu) but also delivers very good performance (tested with proton-GE) . I will test later if this is also true for a new game using 1.0.5.

UPDATE:

I played around 30 minutes with a new game until it crashed when opening the town menu.

Even with a new campaign it's pretty crashy for me. Most of the time I get exception code 0000000c, though the latest crash (plus one earlier today) was exception code 6ba.

On the upside, though, at least I was able to confirm that the clipboard works (by using bannerlord.party to make a cool banner). So you know, can't be all bad.

Has anyone figured out a way to get a game generated log? There's mention of log files (namely rgl_log.txt or somesuch) on the forums, but I can't seem to find them anywhere. The crash report tool also seems entirely borked, and the Proton logs don't give any meaningful stacktraces.

I think it might be useful to know how to completely remove a prefix for proton. I know its a bit off topic, but given how many times people are doing this it may cut down on bug reports that are caused by kruft.

I know i'm not sure what I'm doing: but I'm deleteing the ~/.steam/steam/steamapps/compatdata/261550/ directory and running the game again to recreate it. is this sufficent?

I know i'm not sure what I'm doing: but I'm deleteing the ~/.steam/steam/steamapps/compatdata/261550/ directory and running the game again to recreate it. is this sufficent?

Yep, that's all there is to it. I personally like to rename instead, so that I can switch between prefixes and quickly test things (and also to make it easier to pull out my saves and configs), but you do you.

And speaking of that: it looks like a fresh prefix (without any protontricks at all) is less crashy for me, but still has the multiple-minute-long-save bug, and reintroduces a bit of stuttering in the campaign map. You win some you lose some, I guess, lol

Several things:

1) I'm now in an odd state that with a fresh prefix i can't even get the launcher to launch any more. I'm also suspecting that some resources are not cleaning up correctly when it crashes (due to a suspicious growth in memory usage which I haven't tried to actively debug beyound ps aux | grep Mount and ps aux | grep wine and trying to get them to exit cleanly. Will restart the system but want to write this out before i do that.

2) when installing the donet and vcrun packages, i keep seeing 'it doesn't appear mono is installed', which it is (6.4 ,arch linux); is this something breaking in protontricks or expected behaviour?

3) don't type while protontricks is runnig. you will hit enter right when it asks 'install this thing it took forever to get to' and you will cancel out of it.

4) @YellowApple i could have sworn I saw a log go from you it had dxvk in the output: are you using a specific version of said dxvk? Given the wierd need nvidia card bugs when i'm running an nvidia card... I wonder if there is something there I'm missing.

@yarbelk The "need nvidia card or windows 10"-issue was easily fixed for me by changing the windows version in winecfg back to windows 10 as described here: https://github.com/ValveSoftware/Proton/issues/3706#issuecomment-609480224

That being said I'm now also getting the frequent campaign map crashes. The only things I changed was the above setting and the M&B patch itself. Not sure if it was 1.0.3 or 1.0.4 where it worked fine but these campaign crashes are completely new for me. Dotnet472 or dotnet480 made no difference there either.

For folks who are getting tons of weird instability issues, I think you just need to delete your Bannerlord wine prefix, verify the game files (make sure you're updated), and install vcrun2019 and dotnet48. Also make sure you don't have the global override for SteamPlay set (Steam main Settings page -> SteamPlay) and use the latest Proton-GE build.

If you do all this and are still having problems, also update your graphics driver. For Nvidia you should be running the latest binary release from nvidia.com; if this is packaged for your distro already, great. For AMD you should either be running the latest Catalyst binaries or a recent git version of mesa/libdrm/the AMD DDX and a recent Linux kernel.

The game is running great with no major issues at all for me. I get 1-2 second hitches the first time a combat animation or new outfit gets loaded in the field, but it pauses the entire game so it's not like I fight at a disadvantage when it happens, and it doesn't recur if I keep fighting the same enemies. Some kind of shader caching related to realistic cloth effects, probably.

Also post what GPU you have when you report issues. I'm on a 2080 Ti. I was able to play non-stop for 4 hours without a crash and with good performance.

@YellowApple

Game logs are found in the wine prefix here: </261550 prefix>/pfx/drive_c/ProgramData/Mount and Blade II Bannerlord/logs/

e.g. ~/.steam/steam/steamapps/compatdata/261550/pfx/drive_c/ProgramData/Mount and Blade II Bannerlord/logs

If the crash uploader worked (which is really unfortunate that it doesn't...), it seems like it would upload the artifacts found here: <261550 prefix>/pfx/drive_c/ProgramData/Mount and Blade II Bannerlord/crashes/

It looks like the game creates a directory in the crashes dir every time it crashes, and includes a few different logs + the save game from the crash.

Well, I've gotten further with the most recent Proton-GE build and installing dotnet472 (which retro-actively installed about 5-6 previous versions).

I get the launcher now, but game is still freezing entire computer after creating character. I can hear music/sounds in the background, but nothing. I've let it sit for awhile, thinking it just needed to catch up. Nothing. Hard shutdown is the only fix.

Well, I've gotten further with the most recent Proton-GE build and installing dotnet472 (which retro-actively installed about 5-6 previous versions).

I get the launcher now, but game is still freezing entire computer after creating character. I can hear music/sounds in the background, but nothing. I've let it sit for awhile, thinking it just needed to catch up. Nothing. Hard shutdown is the only fix.

What distro, GPU, and graphics driver version?

Ubuntu 18.04, RX 580 and stock/default amd drivers. I also have wine/winetricks/mesa/vulkan up to date.

It's only this game, currently, that doesn't run, but that doesn't mean it's not my system, just throwing it out there.

Ubuntu 18.04, RX 580 and stock/defautl amd drivers. I also have wine/winetricks/mesa/vulkan up to date.

It's only this game, currently, that doesn't run, but that doesn't mean it's not my system, just throwing it out there.

Ubuntu 18.04 is using rather old Mesa (open source) drivers now. Can you try switching to the AMD Adrenaline (previously known as Catalyst, or fglrx) drivers?

If you want to stick with the open source graphics stack, you can also try oibaf's graphics PPA: https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers

The open source graphics stack ages very poorly. This is largely due to the extremely rapid pace of improvements. A 1 year old open source graphics driver is like an 80 year old car. Completely and utterly obsolete. At this point I am seriously thinking the fault is with the open source graphics stack for your problem.

I'm on Ubuntu 20.04 (which is mostly similar to 18.04 in most respects, actually) and the main difference is I'm running the Nvidia binary drivers. The game runs great. If the open source graphics stack update from oibaf doesn't fix it for you, I would try the binary Adrenaline driver.

The open source graphics stack ages very poorly.

Don't blame Mesa for a shitty distro (ubuntu) shipping old versions of it. There are public PPAs which will allow you to install a newer Mesa on your old outdated distro.

I'm running a RX 580 on Mesa 20.0 (and even Mesa master branch) with no graphical lockups like they described.

I'm running a RX 580 on Mesa 20.0 (and even Mesa master branch) with no graphical lockups like they described.

I show to be on Mesa 20.0.0-devel, but if that's the wrong version and there's a different/better one, I'm not one to disregard advice from others. I'm also checking out the other PPA, because I thought I had it before, but might have removed it awhile back.

The open source graphics stack ages very poorly.

Don't blame Mesa for a shitty distro (ubuntu) shipping old versions of it. There are public PPAs which will allow you to install a newer Mesa on your old outdated distro.

I'm running a RX 580 on Mesa 20.0 (and even Mesa master branch) with no graphical lockups like they described.

Oh, I'm not blaming Mesa at all. The fact of the matter is just that Mesa from today is 1000% better (more functional and feature-complete) than Mesa of a year ago. This has been true for every year of the open source graphics stack's existence. I was simply justifying why it's not OK to rely on whatever "stable" (aka _stale_) version of Mesa an LTS distro happens to ship, while trying to play high-end games.

Edit: Then again, I've never had much success running "real" games (i.e. anything with more graphical detail than Stellaris or Team Fortress 2) with the open source graphics stack. I tried a March git master build from oibaf's PPA with a Radeon VII with Kingdom Come: Deliverance, Elder Scrolls Online, PULSAR: Lost Colony, Stellaris, and several other games. The performance was acceptable on ESO and Stellaris but unplayably slow on the others (5 fps or worse). I switched out the eGPU from a Radeon VII to a 2080 Ti and used the Nvidia binary driver, and suddenly performance is well over 60 fps in all scenes and 100+ often. Night and day.

If you're using the open source graphics stack, you're pretty much limited to playing whichever games it happens to support well, which is probably about 20-50% of all games in existence (rough estimate). If you're using the Nvidia binary drivers, more like 95% of games run well. I hope the open source drivers get to the point where they're as good or better than the binaries someday, but that's not today.

So I noticed this, in the support section of the forums saying that sometimes steam isn't installing all the needed deps.

I don't know if .net Core is included (or supposed to be) with dotnet472, but I used the link to from that post to install that specific version and it seems like most of my crashes are gone! I do still get the occasional hang, especially when things like textures are loading for the first time each session, but I can even pull up the notorious arena leaderboard without crashing now!

For those that would like to try it out I did something like the following:

$ wget https://download.visualstudio.microsoft.com/download/pr/cd223083-8c0e-4963-9fcd-fcf01a55e56c/15500e764899442ed6e014687caa34e9/dotnet-runtime-2.1.17-win-x64.exe

$ export STEAM_COMPAT_DATA_PATH=/games/steamapps/compatdata/261550/

$ cd ~/.steam/steam/compatibilitytools.d/proton_butterlord/

$ ./proton run ~/dotnet-runtime-2.1.17-win-x64.exe

where the compatdata path would be the path to your bannerlord compatdata folder and the cd is to whichever directory the proton you are using is contained.

If you want to stick with the open source graphics stack, you can also try oibaf's graphics PPA: https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers

Well holy shit, if re-installing those didn't seem to do the trick! I actually got to the first dialogue after character creation! I'm going to test more, but just wanted to throw it out there, that might have been the fix (knock on wood).

/edit
Would just like to add a thank you from a random internet stranger to everyone who has been troubleshooting and coming up with solutions for this!

@Aliervo - So after the last command and it seems to fail with this -

ProtonFixes[12023] INFO: Running protonfixes
ProtonFixes[12023] INFO: Running checks
ProtonFixes[12023] INFO: All checks successful
ProtonFixes[12023] INFO: No protonfix found for UNKNOWN (261550)

@yarbelk The "need nvidia card or windows 10"-issue was easily fixed for me by changing the windows version in winecfg back to windows 10 as described here: #3706 (comment)

That being said I'm now also getting the frequent campaign map crashes. The only things I changed was the above setting and the M&B patch itself. Not sure if it was 1.0.3 or 1.0.4 where it worked fine but these campaign crashes are completely new for me. Dotnet472 or dotnet480 made no difference there either.

Unfortunatly; setting windows 10 didn't stop the nvidia crash for me (with empty prefix too)
on start of new game before character creation: nvida crash. restart. right after winning the tornement: nvidia crash (10 minutes).

@jake-hedges Did it drop to prompt after that? I recall seeing those, but after a second it ran and popped up the installer.

Edit: Just gave it another go in a clean prefix, I got

ProtonFixes[32252] INFO: Running protonfixes
ProtonFixes[32252] INFO: Running checks
ProtonFixes[32252] INFO: All checks successful
ProtonFixes[32252] INFO: No protonfix found for UNKNOWN (261550)
ProtonFixes[32252] INFO: Creating MS Core font links in /games/Steam/steamapps/compatdata/261550/pfx/drive_c/windows/Fonts

but then, after a few seconds, the installation dialog did pop up and it allowed me to install.

Double check /your/path/to/compatdata/261550/pfx/drive_c/Program\ Files/ for a dotnet folder in case it did a silent install. If there is nothing there, try running it again and just let it sit for a minute or two to see if the installation window appears.

@Aliervo - So after the last command and it seems to fail with this -

ProtonFixes[12023] INFO: Running protonfixes
ProtonFixes[12023] INFO: Running checks
ProtonFixes[12023] INFO: All checks successful
ProtonFixes[12023] INFO: No protonfix found for UNKNOWN (261550)

I got this error too, but it worked adding "pfx/" to the end

$ export STEAM_COMPAT_DATA_PATH=/games/steamapps/compatdata/261550/pfx/

This didn't do anything for me though. Getting the same random crashes.

Edit: NVM I misspoke. I thought that fixed it, but I misread
Error when using 261550/

ProtonFixes[25930] INFO: Running protonfixes
ProtonFixes[25930] INFO: Running checks
ProtonFixes[25930] INFO: All checks successful
ProtonFixes[25930] INFO: No protonfix found for UNKNOWN (261550)

Error when using 261550/pfx/

./proton run ~/dotnet-runtime-2.1.17-win-x64.exe Proton: Upgrading prefix from None to 5.5-GE-1 (/run/media/m/850EVO/Games/SteamLibrary/steamapps/compatdata/261550/pfx//)
ProtonFixes[25999] INFO: Running protonfixes
ProtonFixes[25999] INFO: Running checks
ProtonFixes[25999] INFO: All checks successful
ProtonFixes[25999] INFO: No protonfix found for UNKNOWN (261550)
ProtonFixes[25999] INFO: Creating MS Core font links in /run/media/m/850EVO/Games/SteamLibrary/steamapps/compatdata/261550/pfx/pfx/drive_c/windows/Fonts
For some reason it added the MS Core font links when I used pfx, but the installer didn't start.

Without dotnet472 or dotnet48 the launcher won't work, and I have to rename the game .exe like suggested early in the thread to launch the game without the launcher, but every save save takes 30-90 seconds. Seems a bit more stable though, but the game autosaves way too often, forcing me to wait over a minute every 5-10 minutes, especially early game.

With dotnet the launcher works, and saving takes 1-5 seconds, but it might crash randomly on the game map or before starting conversations or battles. It's mostly playable though. Every now and then I'm able to play an hour or more before either my FPS falls down to .5 in conversations an battles (which a restart fixes) or it crashes.

@EmquCC Double check the windows version your prefix is set to.

One of the vcrun scripts sets it to XP and one sets it to 7. I recall crashing a lot when my prefix was set to XP and there are reports on the forums of issues with Windows 7, so I recommend going with 10.

Also, 1.0.6 just dropped so I'm going to roll a fresh prefix and make sure everything is still working.

@EmquCC Double check the windows version your prefix is set to.

One of the vcrun scripts sets it to XP and one sets it to 7. I recall crashing a lot when my prefix was set to XP and there are reports on the forums of issues with Windows 7, so I recommend going with 10.

Also, 1.0.6 just dropped so I'm going to roll a fresh prefix and make sure everything is still working.

Thanks:) I changed to Windows 10 yesterday, but forgot to check it today. I edited my post, as I misread. When I added pfx it made some links for the MS Core fonts, but the installer didn't start. I'm gonna make a fresh prefix and try again with 1.0.6, and I will get back to you

Edit: New RC for Proton 5.0.6 dropped at the same time as 1.0.6. I don't see any changelog for it yet, but I'll give this a try too. For those who wants to try Proton test builds, right click Proton 5.0 in the steam library > properties > Betas > opt in to "next -"

. For those who wants to try Proton test builds, right click Proton 5.0 in the steam library > properties > Betas > opt in to "next -"

Unless they added the mouse input patch in 5.0.6, you'll need to patch it yourself or you'll lose the ability to click around with the mouse..

@craftyguy Yeah, had to give it a try since there's no changelog for Proton 5.0.6 RC2 yet. Mouse input patch has not been added in RC2.

@Aliervo @jake-hedges I was still unable to install dotnet-runtime-2.1.17-win-x64 with that command. However, I managed to install it by using protontricks --gui, then "Run explorer" and run the .exe from explorer. I'll test it out now

Edit: Now my game crashes before hitting the menu screen. Restarting with a fresh prefix again^^

Edit 2: Loaded now on a new prefix with dotnet-runtime installed. Was probably a user-error from my side:)

Just a heads-up, the latest Proton-GE, 5.5-1, already merged the mouse fixes from wine-staging.

Just a heads-up, the latest Proton-GE, 5.5-1, already merged the mouse fixes from wine-staging.

Using these fixes, I still am only getting mouse control maybe 1 out of every 10 launches.

Just a heads-up, the latest Proton-GE, 5.5-1, already merged the mouse fixes from wine-staging.

Using these fixes, I still am only getting mouse control maybe 1 out of every 10 launches.

That's really strange, after patching wine a while back I get mouse control 100% of the time. Anyone else experiencing this same issue where the patches don't work?

@jaynus: did you try using a fresh prefix (run protontricks 261550 annihilate)? It shouldn't make any difference, but maybe you have some weird overrides from before, or ??

Just a heads-up, the latest Proton-GE, 5.5-1, already merged the mouse fixes from wine-staging.

Using these fixes, I still am only getting mouse control maybe 1 out of every 10 launches.

That's really strange, after patching wine a while back I get mouse control 100% of the time. Anyone else experiencing this same issue where the patches _don't_ work?

@jaynus: did you try using a fresh prefix (run protontricks 261550 annihilate)? It shouldn't make any difference, but maybe you have some weird overrides from before, or ??

Yep! I've been deleting the entire prefix and starting fresh, it's still very sporadic

Had a chance to test a bit on a new prefix now. Had exactly 2 crashes. One when I changed the settings right away (same as before, it crashed but saved the settings changes). The other was when I tried to switch from my inventory screen to my party screen. When I tried to reproduce it, the screens changed fine, with just a slight hang for things to load in, so I am assuming it was a one time loading error.

I also paid more attention to what installing vcrun2019 actually does, the installer that pops up says it is the 2015-2019 redistributable, so odds are it doesn't do anything better than installing vcrun2015 and vcrun2017 independently, it just makes for a convenient one-step.

Adding in the .net Core that I linked earlier (either using the command line as I posted or protontricks 261550 --gui followed by "Run Explorer" as @EmquCC pointed out) completes our list of required dependencies as listed here, so theoretically, most of the remaining crashes are caused by bugs in the game itself and will soon be patched!

so theoretically, most of the remaining crashes are caused by bugs in the game itself and will soon be patched!

I don't know, there's a long bloody history of windows components failing on wine for various reasons, so I wouldn't rule out entirely that there's not more wine bugs here.

It's really unfortunate the game crash uploader doesn't seem to work. There could be class(es) of game bugs that only affect us under Wine that Taleworlds might address, if only they knew about them!

It's really unfortunate the game crash uploader doesn't seem to work. There could be class(es) of game bugs that only affect us under Wine that Taleworlds might address, if only they knew about them!

Don't suppose there's a convenient way to debug that is there? :stuck_out_tongue_closed_eyes:

I noticed something weird, every time I close the game, or it crashes, if I'm to launch it again, I need to also restart steam, otherwise nothing happens.

OK, so what i've done so far on a fresh prefix is:

• vcrun2019
• the dotnet core extra depends
• dotnet48

Running debian busters 18.3 mesa I played for about an hour before I had crash engaging mountain bandits. Game was otherwise pretty smooth and really enjoyable. Completely got rid of the save wait times, which I think im ok with. Just need to get in the habit of saving more often just in case.

Im good with this setup for now!

Been playing for 3 hours now, and "only" had 3 crashes, using the same setup as what @jake-hedges just wrote. Dotnet core + 1.0.6 seems to have taken care of most of the problems.
Crashed once after I won a tournament, and twice in a row when checking out the same page in the encyclopedia.The second time I won the tournament it didn't crash, and the encyclopedia didn't crash the game when I tried accessing it at a different place and time in the game.

I'm pretty happy with the setup myself. Haven't had any long-lasting FPS drops yet either

I am also running smoothly, although I still have some minor hangs every now and then. Pretty sure that is only because I do silly things like enable transparent compression on my drives and play off an hdd instead of an ssd.

I'll be around here or the forums if something starts to break... Until then, happy harvesting!

Running protontricks 261550 dotnet472, which installed .NET 4.0, 4.5, 4.6, 4.6.1, 4.6.2, and 4.7.2, reduced the save times to a few seconds, it also doesn't seem to improve stability in anyway.

@ptkato Try installing dotnet Core (see https://github.com/ValveSoftware/Proton/issues/3706#issuecomment-609959973 and https://github.com/ValveSoftware/Proton/issues/3706#issuecomment-610022040 for ways to do this).

Also, double check that your prefix didn't get set to WinXP or Win7, as both have known issues. I recommend Windows 10 for the prefix.

After following the current workaround (Proton 5.5-GE https://github.com/GloriousEggroll/proton-ge-custom/releases/tag/5.5-GE-1 + protontricks 261550 dotnet472, prefix set to Windows 10) the game runs smoothly, even in large battle sizes (400+).

However, whenever i enter a siege, the game stutters and freezes like crazy. Anyone else having this? (You can quickly test sieges from Custom Battle and changing the battle type). Installing dotnet core didn't help.

@dufuspaelli I had the same issue with stuttering. For me it was related to thermal throttling of the GPU, by lowering the frame cap I got much better smoothness. (Might or might not be the same for you).

Any help for crashing on start with nothing but the following error to show for it? Well at least it's what is logged right before a massive stacktrace.

  218 38705.528:0030:0031:fixme:reg:GetEnabledXStateFeatures
  219 38705.531:0030:0031:trace:loaddll:load_native_dll Loaded L"C:\\windows\\Microsoft.NET\\Framework64\\v4.0.30319\\clrjit.dll" at 0x1a7e0000: native
  220 38705.532:0030:0031:fixme:ntdll:EtwEventRegister ({319dc449-ada5-50f7-428e-957db6791668}, 0x1a8c2bc0, 0x1a8eb8a0, 0x1a8eb8c0) stub.
  221 38705.532:0030:0031:fixme:ntdll:EtwEventSetInformation (deadbeef, 2, 0x1a8d7e91, 28) stub
  222 38705.535:0030:0031:fixme:path:parse_url failed to parse L"TaleWorlds.Library"
  223 38705.537:0030:0031:fixme:path:parse_url failed to parse L"netstandard"
  224 38705.540:0030:0031:trace:loaddll:load_so_dll Loaded L"C:\\windows\\system32\\bcrypt.dll" at 0x7f0bfdf90000: builtin
  225 38705.542:0030:0031:trace:loaddll:load_so_dll Loaded L"C:\\windows\\system32\\crypt32.dll" at 0x7f0bfde90000: builtin
  226 38705.542:0030:0031:trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\rsaenh.dll" at 0x66500000: PE builtin
  227 38705.556:0030:0031:fixme:path:parse_url failed to parse L"System.Core"
  228 38705.566:0030:0031:fixme:path:parse_url failed to parse L"TaleWorlds.TwoDimension.Standalone"
  229 38705.567:0030:0031:fixme:path:parse_url failed to parse L"ManagedStarter"

Running proton-5.5-GE-1 with protontricks 261550 dotnet472 and win10.

After following the current workaround (Proton 5.5-GE https://github.com/GloriousEggroll/proton-ge-custom/releases/tag/5.5-GE-1 + protontricks 261550 dotnet472, prefix set to Windows 10) the game runs smoothly, even in large battle sizes (400+).

However, whenever i enter a siege, the game stutters and freezes like crazy. Anyone else having this? (You can quickly test sieges from Custom Battle and changing the battle type). Installing dotnet core didn't help.

Okay after trying out different graphics settings I figured it out.

This might be helpful to people running on high+ settings and encountering lag / stuttering on large battles: Lower your Texture Streaming Budget setting in the games settings.

On my RTX 2060 a large Castle siege (400+ units) eats up around 4,7 gigs of VRAM when Texture Streaming Budget is set to low. So basically, going for a higher streaming budget eats up all of my VRAM and thus results in huge stutters. I'm not sure if this is a bug or expected behavior from this setting.

@Evilbits My gut says maybe something got corrupted, would you mind sharing the full log?

Also, you might not be on the latest version of the game. I saw ManagedStarter in there which I believe has been removed in one of the more recent updates.

@dufuspaelli I believe this is the intended behavior. Basically the Texture Streaming Budget tells the game how much vram to save for putting all the textures on all the things, so if you set it too high, you run out of vram for things like showing animations and thus get stuttering while those things try to render.

So by some miracle the crash reporter started working for me (w/ dotnet472 and that .NET Core download):

Not sure if it actually successfully sent the report, or if TaleWorlds would be able to do anything useful with it even if it did (short of actually actively supporting us Proton-using butterlords, which would be a surprise, but a welcome one), but hey, can't hurt to try it out, right?

Anyway, so at least one source of continued instability for me (and what led to that incidental discovery) seems to be a System.AccessViolationException that wrecks System.Text.RegularExpressions.RegexRunner.Scan when trying to show/refresh a party's nameplate (I'm assuming, based on the method name SandBox.ViewModelCollection.Nameplate.PartyNameplateVM.RefreshDynamicProperties). Normally I'd write this off as "well something else is probably clobbering memory and this function happened to be in the wrong place at the wrong time", but this is the second time this exact method has popped this exact memory access exception, which is therefore a bit suspicious.

Not sure yet what next steps might be to troubleshoot this (aside from throwing +heap in my WINEDEBUG, which sounds like it'll be painful performance-wise).

Anyway,
here's steam-261550.log, rgl_log_42.txt, and rgl_log_errors_42.txt, for posterity's sake.

@Yarwin

I noticed you edited the top initial comment to recommend installing some random Proton build to 'work around' this issue, but I don't think it's a great idea to be recommending random Proton builds from random people on the internet, without getting into a big debate about the (de)merits of running binaries from random people (e.g. wine has filesystem access to your entire home directory, for one). It's also probably unhelpful for Valve if the 'workaround' is running some forked Proton thing with a large number of changes to it.

The current workaround for input issues is to build Proton from this repo with the upstream wine-staging patch applied.

@YellowApple, trying to recreate your crash, but I've got nothing so far... When you say nameplate, are you referring to the world map plate with the army name and troop info?

Seeing it go through all the localization stuff before hitting Sandbox.ViewModelCollection.Nameplate.PartyNameplateVM.RefreshDynamicProperties reminded me of this thread. It's a long shot, but you could try removing the Chinese localization data as described there.

@craftyguy, for what it's worth, GloriousEggroll is a contributor to both wine-staging and lutris. I don't personally consider that a "random internet person," but I see your point. Perhaps a disclaimer is more appropriate with additional info for those that would feel better building their own.

Finally, @Yarwin, since the OP has been mentioned, you might consider adding the new .net Core stuff since it seems to reduce crashes and we now have one report of the crash reporter working after it was installed!

@Yarwin

I noticed you edited the top initial comment to recommend installing some random Proton build to 'work around' this issue, but I don't think it's a great idea to be recommending random Proton builds from random people on the internet, without getting into a big debate about the (de)merits of running binaries from random people (e.g. wine has filesystem access to your entire home directory, for one). It's also probably unhelpful for Valve if the 'workaround' is running some forked Proton thing with a large number of changes to it.

The current workaround for input issues is to build Proton from this repo with the upstream wine-staging patch applied.

GloriousEggroll isn't "random" any more than Proton itself is random, or Mozilla Firefox, or any open source software on the Internet that is provided for free without warranty or indemnification.

Spending 15 minutes reading the commit diffs of GloriousEggroll's repository shows very clearly that he is doing great work to provide the latest fixes and features of a Proton build incorporating the latest wine development code and many game-specific fixes that haven't yet made it into Wine. He is not some "random" black hat providing binaries-only with the intent of mining your data or running a rootkit on your system. He puts in a ton of work to maintain a very good fork of Proton.

Most Linux gamers honestly don't have the technical ability or patience to build all their software from source. And even if you do, unless you're also auditing that code, it's not _really_ better than downloading binaries. If you're truly paranoid, you should game on an isolated system that has no personal data and no access to any privileged network resources, or a similarly configured VM. Closed-source games themselves have been known to upload a creepy amount of data about their users to the game developer, and running them under wine is unlikely to change that.

Overall I think you are grossly overreacting about considering GE to be unreliable or "random." If you're seriously paranoid you should only be running truly free and open source software (which by definition excludes M&B II: Bannerlord!) which you have manually audited every source line of code. Oh and don't run a proprietary BIOS either -- that means you have to go buy a CPU and motherboard that have open microcode.

As for Valve, they don't seem to be super involved in working with the community of Proton users to help improve Proton. I can only assume that their position is either (a) we don't care about Proton in general, or (b) we only care about issues that _we_ care about, not what our users complain about. I haven't seen any Valve employees participating in this bug report, have you?

Valve is probably content to allow the community around this very popular game to find solutions for Bannerlord and get them upstreamed into _Wine_. Honestly, that's less work for them, so it makes sense. Unless there is something specific to what _Proton_ does that can't be fixed upstream in _Wine_, they are almost definitely just going to ignore this issue report and wait for Wine to fix the problem.

The Proton-GE build is the most expedient way to play Bannerlord today for not-very-technical Linux gamers. For those who don't trust the build but lack the skills to compile from source, they're welcome to wait until Valve updates the stable release of SteamPlay from the official Steam client with a version of Wine that contains the Bannerlord fixes. Based on past experience, this could take several weeks to several months.

GloriousEggroll isn't "random" any more than Proton itself is random, or Mozilla Firefox, or any open source software on the Internet that is provided for free without warranty or indemnification.

Mozilla and Valve are a hell of a lot more trustworthy than some individual providing binaries on the internet. The former are accountable companies, the later is not.

And again, it almost certainly helps Valve less if the data they have for this game is using some Proton fork that isn't even close to what they are releasing. Because let's not kid ourselves, the point of this issue in this repo is to further the goal of having this game work with Valve's release of Proton, not eggroll or anyone else's fork of Proton. And this is not a general game support forum (there is one on Taleworld's website).

For me (Fedora 32 KDE Beta) the .exes still need to be renamed. Cannot get into game with just current workaround (5.5-GE-1 + protontricks 261550 dotnet472).
So renaming Mount & Blade II Bannerlord/bin/Win64_Shipping_Client/
Bannerlord.exe
to
TaleWorlds.MountAndBlade.Launcher.exe

@craftyguy He is literally a wine-staging contributor. You arguing from a position of ignorance. And this is also not your blog.

GloriousEggroll isn't "random" any more than Proton itself is random, or Mozilla Firefox, or any open source software on the Internet that is provided for free without warranty or indemnification.

Mozilla and Valve are a hell of a lot more trustworthy than some individual providing binaries on the internet. The former are accountable companies, the later is not.

And again, it almost certainly helps Valve _less_ if the data they have for this game is using some Proton fork that isn't even close to what they are releasing. Because let's not kid ourselves, the point of this issue in this repo is to further the goal of having this game work with Valve's release of Proton, not eggroll or anyone else's fork of Proton. And this is not a general game support forum (there is one on Taleworld's website).

There are forks of Proton specifically because getting contributions accepted into these upstream projects (Proton and Wine) is historically difficult and a very slow and labor-intensive process.

• Valve isn't responsive to the community. When major new titles come out, they make no effort to engage with the community, to announce "we're working on it" or "help us out and we'll incorporate your fixes into Proton" or anything of the sort. Proton is very much run as an "ivory tower" commercial open source GitHub repository. Pull requests sit for months or years with little or no feedback.
• Valve (and often, upstream Wine) sometimes decline practical, useful contributions and instead insist on a "perfect" solution that is much more difficult to develop. When trying to get a game or a piece of software running, it's often easy to make a "quick fix" that solves the immediate problem. You can even scope this fix to a specific process name to prevent it from affecting other software. But the upstreams we're dealing with -- Valve/Proton and Wine -- are often reluctant to accept these contributions, instead insisting that the underlying code be completely redesigned or reworked to perfection before a contribution can be accepted. These major refactorings are often out of the skillset of the people who can contribute quick fixes; even if they are within their abilities, it can take months or years to complete such major changes. In the meantime, we'd have no compatibility with the broken software/game without a quick fix. This is why fix builds to Proton (and Wine before it) are so popular and useful.
• The companies that work on this software are sometimes pretty hypocritical about workarounds. One of the major companies involved in Wine/Proton is Codeweavers. They distribute a paid, commercial distribution of Wine called CrossOver Linux (and CrossOver Mac, too). While these are heavily based on upstream Wine, it's not uncommon for them to implement hacks, workarounds and other such "practical" measures to fix a major title or major piece of software (most often Microsoft Office) in their commercial product, while not merging the same workaround to the upstream, open source code. So workarounds are fine if it makes their product look better, but not fine if others are contributing the workarounds.
• The upstreaming is already happening! There is an earlier post in this thread with direct evidence that the mouse cursor fix for Bannerlord has been accepted by wine-staging, which is Proton's upstream. The only thing preventing that patch from getting pulled into a stable release of Proton, is time. Lots and lots of time -- weeks or months, probably. So there is no real work left to be done to get this stuff upstreamed now. My earlier points about the difficulty of getting stuff upstream are mostly pertaining to other games and other types of workarounds that aren't as clear-cut as this one was. GE's fork of Proton contains many practical fixes for games that may not hit wine upstream for months, if ever.

@YellowApple I get that exception if I use the ACO shader compiler backend for mesa,
since I switched back to llvm the crashes have been less frequent and instead of this exception the game just freezes (I have been to lazy so far to log whats happening there but I will in the next few days).

Used software:
latest proton-ge
dotnet472
mesa git (llvm 9)
linux-zen 5.6.2

Used Hardware:
Vega 56
3700X

Update:
I was wrong switching to llvm only seemed better.

I am following the current work around of: Proton 5.5-GE + protontricks 261550 dotnet472, ensuring that I have set Win 10 as the OS.

I am encountering a crash every few minutes, with roughly the same modules loaded. I'm not able to fully understand the log, hoping someone will.
backtrace.txt

1060Ti 6GB (nvidia 440 driver) with Ryzen 1800x CPU

Great work everyone on troubleshooting this issue and getting it somewhat playable for the masses!

@Demannu Try installing dotnet Core if you haven't. I made a fresh prefix yesterday, and went from crashing every few minutes to every 1-2 hours. It did crash twice in a row when I started the game this morning, but it worked on the third try.

How to install: Protontricks Terminal / Protontricks GUI

Also make sure that your prefix is set to Windows 10 and not WinXP, which apparently one of the dotnet scripts changes to.

The only things I've done to my fresh prefix is;

• Use Proton 5.5-GE-1
• Install dotnet48
• Install vcrun2019
• Install dotnet Core manually
• Made sure the prefix is set to Windows 10

I used protontricks --gui to install everything and set the prefix to Win10.

Edit: If you're using mods, be sure to check for updates every day too, and try disabling them if you're crashing. After 1.0.6 was released, my game started crashing in the arena, but it turns out it was the arena mods I was using

So as an update:

With a fresh prefix, setup in this order:

• Start Bannerlord once with Proton-5.5-GE-1 set as compat layer in steam
• protontricks 261550 vcrun2019
• Install the dotnet core via the GUI method and download in this thread
• protontricks 261550 dotnet48

I still appear to have the following issues still:

• Mouse still appears to not work maybe 70% of hte time. I have to restart repeatedly until it works. This is not the case on my laptop, only my desktop.
• dotnet472 and dotnet48 don't seem to be solving the save hang issue. It still seems I'm taking 90+ seconds to save. How was it determined if this was .NET? What should I dig in to to see why this still isn't working?

On a different topic, has anyone started poking around on the multiplayer side of the game? I know Battleye is going to be difficult, but there are reports of Battleye games working on Linux.

The current error is something like:
Error 31: Driver error

On a different topic, has anyone started poking around on the multiplayer side of the game? I know Battleye is going to be difficult, but there are reports of Battleye games working on Linux.

The current error is something like:
Error 31: Driver error

BattleEye these days installs a kernel driver and service for anticheat. Both of which just aren't possible with wine, really.

On a different topic, has anyone started poking around on the multiplayer side of the game? I know Battleye is going to be difficult, but there are reports of Battleye games working on Linux.

The current error is something like:
Error 31: Driver error

Multiplayer has always been working perfectly for me, matchmaking and custom servers. I just canceled the BattleEye installation when prompted.

On a different topic, has anyone started poking around on the multiplayer side of the game? I know Battleye is going to be difficult, but there are reports of Battleye games working on Linux.
The current error is something like:
Error 31: Driver error

Multiplayer has always been working perfectly for me, matchmaking and custom servers. I just canceled the BattleEye installation when prompted.

Wow you are right, I hadn't even tried multiplayer due to the aforementioned BattleEye, but yeah it has been working fine for me as well after cancelling the installation at the beginning. They must have disabled it for now, and I am sure it will stop working at some point in the future, but for now everything does seem to be working.

In regards to singleplayer, my current setup involves using dotnet48, vcrun2019, and installing the dotnet core exe, along with setting the prefix to Windows 10. I am still getting crashes every hour or so, and sometimes more frequently, especially right after loading a save. I also have been getting the same error as @YellowApple involving a System.AccessViolationException with the party nameplate.

Finally, @Yarwin, since the OP has been mentioned, you might consider adding the new .net Core stuff since it seems to reduce crashes and we now have one report of the crash reporter working after it was installed!

Thanks for your input – I'll add .net core to workaround mini-guide.
List of requirements if anybody is curious: https://forums.taleworlds.com/index.php?threads/installing-missing-necessary-dependencies.407126/ (vcruns are installed by default by steam and it looks like that they work fine)

On a different topic, has anyone started poking around on the multiplayer side of the game? I know Battleye is going to be difficult, but there are reports of Battleye games working on Linux.
The current error is something like:
Error 31: Driver error

Multiplayer has always been working perfectly for me, matchmaking and custom servers. I just canceled the BattleEye installation when prompted.

I had no idea it was working. That's hilarious.

Probably the only person trying to run on CentOS 8 but...no matter what I do I can't seem to get through the initial loading screen on startup, it doesn't freeze but the loading screen never ends.

Current Build is Proton-5.5-GE-1 with dot472 (tried dot48 as well) under win10.

I see people suggesting vcrun2019, I am not able to install it, I only see up to vcrun2017 as an option for me.

Any suggestions?

Probably the only person trying to run on CentOS 8 but...no matter what I do I can't seem to get through the initial loading screen on startup, it doesn't freeze but the loading screen never ends.

Current Build is Proton-5.5-GE-1 with dot472 (tried dot48 as well) under win10.

I see people suggesting vcrun2019, I am not able to install it, I only see up to vcrun2017 as an option for me.

Any suggestions?

It's definitely going to be something on your system then. I'm running that exact same setup with literally no issues. The only time I use CentOS is at work. I'm sure it can be done, but I can't imagine gaming on it.

Arch Linux or Manjaro seem to be the way to go for Proton gaming.

Probably the only person trying to run on CentOS 8 but...no matter what I do I can't seem to get through the initial loading screen on startup, it doesn't freeze but the loading screen never ends.
Current Build is Proton-5.5-GE-1 with dot472 (tried dot48 as well) under win10.
I see people suggesting vcrun2019, I am not able to install it, I only see up to vcrun2017 as an option for me.
Any suggestions?

It's definitely going to be something on your system then. I'm running that exact same setup with literally no issues. The only time I use CentOS is at work. I'm sure it can be done, but I can't imagine gaming on it.

Arch Linux or Manjaro seem to be the way to go for Proton gaming.

I figured that would be the case. Guess it's time to learn pacman...

So, just to confirm the behaviour.

If the game crashes, I need to manually kill its process in the task manager. However, if I try to launch it again on Steam, nothing happens. It'll only launch again if I restart steam altogether.

So, just to confirm the behaviour.

If the game crashes, I need to manually kill its process in the task manager. However, if I try to launch it again on Steam, nothing happens. It'll only launch again if I restart steam altogether.

This was happening to me as well throughout my testing

It'll only launch again if I restart steam altogether.

This seems a bit odd. After killing the process, is the wineserver still running, or does that end itself?

So, just to confirm the behaviour.

If the game crashes, I need to manually kill its process in the task manager. However, if I try to launch it again on Steam, nothing happens. It'll only launch again if I restart steam altogether.

I've found that there's often a lingering explorer.exe (among other things) running (especially if it popped up with a Wine error dialog). Killing that is usually enough to clear out everything else (I generally keep htop running with a .exe filter specifically to catch these should they stick around).

You'll also need to murder any lingering wineserver processes.

Just attempted to add the .NET core that we need to winetricks. Hopefully it will be accepted and we can simplify our workaround to protontricks dotnet472 and protontricks dotnetcore2

Probably the only person trying to run on CentOS 8 but...no matter what I do I can't seem to get through the initial loading screen on startup, it doesn't freeze but the loading screen never ends.
Current Build is Proton-5.5-GE-1 with dot472 (tried dot48 as well) under win10.
I see people suggesting vcrun2019, I am not able to install it, I only see up to vcrun2017 as an option for me.
Any suggestions?

It's definitely going to be something on your system then. I'm running that exact same setup with literally no issues. The only time I use CentOS is at work. I'm sure it can be done, but I can't imagine gaming on it.
Arch Linux or Manjaro seem to be the way to go for Proton gaming.

I figured that would be the case. Guess it's time to learn pacman...

Or just scroll up in this giant thread (I know; it's a lot of reading) and see where folks have mentioned the fix to "can't find vc2019 in winetricks/protontricks" multiple times.

GloriousEggroll isn't "random" any more than Proton itself is random, or Mozilla Firefox, or any open source software on the Internet that is provided for free without warranty or indemnification.

Mozilla and Valve are a hell of a lot more trustworthy than some individual providing binaries on the internet. The former are accountable companies, the later is not.
And again, it almost certainly helps Valve _less_ if the data they have for this game is using some Proton fork that isn't even close to what they are releasing. Because let's not kid ourselves, the point of this issue in this repo is to further the goal of having this game work with Valve's release of Proton, not eggroll or anyone else's fork of Proton. And this is not a general game support forum (there is one on Taleworld's website).

There are forks of Proton specifically because getting contributions accepted into these upstream projects (Proton and Wine) is historically difficult and a very slow and labor-intensive process.

* **Valve isn't responsive to the community.** When major new titles come out, they make no effort to engage with the community, to announce "we're working on it" or "help us out and we'll incorporate your fixes into Proton" or anything of the sort. Proton is very much run as an "ivory tower" commercial open source GitHub repository. Pull requests sit for months or years with little or no feedback.

* **Valve (and often, upstream Wine) sometimes decline practical, useful contributions and instead insist on a "perfect" solution that is much more difficult to develop.** When trying to get a game or a piece of software running, it's often easy to make a "quick fix" that solves the immediate problem. You can even scope this fix to a specific process name to prevent it from affecting other software. But the upstreams we're dealing with -- Valve/Proton and Wine -- are often reluctant to accept these contributions, instead insisting that the underlying code be completely redesigned or reworked to perfection before a contribution can be accepted. These major refactorings are often out of the skillset of the people who can contribute quick fixes; even if they are within their abilities, it can take months or years to complete such major changes. In the meantime, we'd have no compatibility with the broken software/game without a quick fix. **This is why fix builds to Proton (and Wine before it) are so popular and useful.**

* **The companies that work on this software are sometimes pretty hypocritical about workarounds.** One of the major companies involved in Wine/Proton is Codeweavers. They distribute a paid, commercial distribution of Wine called CrossOver Linux (and CrossOver Mac, too). While these are heavily based on upstream Wine, it's not uncommon for them to implement hacks, workarounds and other such "practical" measures to fix a major title or major piece of software (most often Microsoft Office) in their commercial product, while not merging the same workaround to the upstream, open source code. So workarounds are fine if it makes their product look better, but not fine if others are contributing the workarounds.

* **The upstreaming is already happening!** There is an earlier post in this thread with direct evidence that the mouse cursor fix for Bannerlord has been accepted by wine-staging, which is Proton's upstream. The only thing preventing that patch from getting pulled into a stable release of Proton, is time. Lots and lots of time -- weeks or months, probably. So there is no real work left to be done to get this stuff upstreamed now. My earlier points about the difficulty of getting stuff upstream are mostly pertaining to other games and other types of workarounds that aren't as clear-cut as this one was. GE's fork of Proton contains many practical fixes for games that may not hit wine upstream for months, if ever.

I agree with most of this, but I think 'hacky' workarounds and those scoped specific to process name should be minimized as much as possible in the main repos. Everything is fine the way it is right now, with community providing fixes for latest releases while upstream only containing commits which take the broader picture into consideration. I don't think either of the projects or their maintainers should be blamed for not including such workarounds, as it'll eventually lead to massive technical debts. The mouse cursor fix for this game is already upstreamed in wine-staging, so it's not like they are ignoring 'non-hacky' fixes

Proton 5.5 GE doesn't work with my setup. Crashes on it instantly in battle or after 2 minutes in map.

I am following the current work around of: Proton 5.5-GE + protontricks 261550 dotnet472, ensuring that I have set Win 10 as the OS.

I am encountering a crash every few minutes, with roughly the same modules loaded. I'm not able to fully understand the log, hoping someone will.
backtrace.txt

1060Ti 6GB (nvidia 440 driver) with Ryzen 1800x CPU

Great work everyone on troubleshooting this issue and getting it somewhat playable for the masses!

I was having these random crashes on an otherwise working system and finally figured out, 99%, sure that it was the wrong versioned autosave. For example upgrading a 1.0.6 save to 1.0.7 would crash in 1-15 minutes without me doing anything special. Deleting the autosave (1.0.6) fixed this. I tried this with earlier version changes too. This eliminated 90% of my crashes. Hope it helps someone here.

I am following the current work around of: Proton 5.5-GE + protontricks 261550 dotnet472, ensuring that I have set Win 10 as the OS.
I am encountering a crash every few minutes, with roughly the same modules loaded. I'm not able to fully understand the log, hoping someone will.
backtrace.txt
1060Ti 6GB (nvidia 440 driver) with Ryzen 1800x CPU
Great work everyone on troubleshooting this issue and getting it somewhat playable for the masses!

I was having these random crashes on an otherwise working system and finally figured out, 99%, sure that it was the wrong versioned autosave. For example upgrading a 1.0.6 save to 1.0.7 would crash in 1-15 minutes without me doing anything special. Deleting the autosave (1.0.6) fixed this. I tried this with earlier version changes too. This eliminated 90% of my crashes. Hope it helps someone here.

I'll give this a test, I have been keeping my saves around so I'll wipe them out and try again. Thank you!

I use proton-5.5-GE-1, have dotnet472, vcrun2019 and dotnetcore2 installed. When I start the game it seems to be running fine. However I get random crashes and when after some crashes I can't restart the game anymore. If this happens opening protontricks 261550 gives the following error:
/home/krulvis/.cache/protontricks/proton/Proton-5.5-GE-1/bin/wine cmd.exe /c echo '%AppData%' returned empty string, error message ""
Did anyone have similar experiences or possibly knows what is going on?

I noticed a pattern, if I only automatic resolve battles with the "Send troops!" option, the game crashes a lot more often compared to only going to the field and battling manually.

@Krulvis I have exactly the same issue sometimes... A system restart always solves it for me. That being said, I haven't experienced it recently. It probably has something to do with lingering processes.

I use proton-5.5-GE-1, have dotnet472, vcrun2019 and dotnetcore2 installed. When I start the game it seems to be running fine. However I get random crashes and when after some crashes I can't restart the game anymore. If this happens opening protontricks 261550 gives the following error:
/home/krulvis/.cache/protontricks/proton/Proton-5.5-GE-1/bin/wine cmd.exe /c echo '%AppData%' returned empty string, error message ""
Did anyone have similar experiences or possibly knows what is going on?

Yeah I had this. I used original build of proton provided by @YellowApple and it works

https://forums.taleworlds.com/index.php?threads/known-issues-will-be-updated-soon.401168/

Some of our players might experience the game not launching at all, crashing after launcher, and crashing after the loading screen. We are investigating this issue. It is crucial if you use the crash uploader after all crashes. You can try a possible workaround for this issue here. Please note that we are working very hard to fix this not launching issue!

https://forums.taleworlds.com/index.php?threads/possible-workaround-for-game-not-launching-issue.407128

The game not launching is a Windows issue as well.

Probably the only person trying to run on CentOS 8 but...no matter what I do I can't seem to get through the initial loading screen on startup, it doesn't freeze but the loading screen never ends.
Current Build is Proton-5.5-GE-1 with dot472 (tried dot48 as well) under win10.
I see people suggesting vcrun2019, I am not able to install it, I only see up to vcrun2017 as an option for me.
Any suggestions?

It's definitely going to be something on your system then. I'm running that exact same setup with literally no issues. The only time I use CentOS is at work. I'm sure it can be done, but I can't imagine gaming on it.
Arch Linux or Manjaro seem to be the way to go for Proton gaming.

I figured that would be the case. Guess it's time to learn pacman...

Or just scroll up in this giant thread (I know; it's a lot of reading) and see where folks have mentioned the fix to "can't find vc2019 in winetricks/protontricks" multiple times.

I'm new to github so when I originally ran a ctrl-f "vcrun2019" I didn't see anything.

Thank you for putting your name on your profile so I know to avoid you in a professional environment.

Probably the only person trying to run on CentOS 8 but...no matter what I do I can't seem to get through the initial loading screen on startup, it doesn't freeze but the loading screen never ends.
Current Build is Proton-5.5-GE-1 with dot472 (tried dot48 as well) under win10.
I see people suggesting vcrun2019, I am not able to install it, I only see up to vcrun2017 as an option for me.
Any suggestions?

It's definitely going to be something on your system then. I'm running that exact same setup with literally no issues. The only time I use CentOS is at work. I'm sure it can be done, but I can't imagine gaming on it.
Arch Linux or Manjaro seem to be the way to go for Proton gaming.

I figured that would be the case. Guess it's time to learn pacman...

Or just scroll up in this giant thread (I know; it's a lot of reading) and see where folks have mentioned the fix to "can't find vc2019 in winetricks/protontricks" multiple times.

I'm new to github so when I originally ran a ctrl-f "vcrun2019" I didn't see anything.

Thank you for putting your name on your profile so I know to avoid you in a professional environment.

Huh? I wasn't being sarcastic. It really _is_ a lot of reading. If you're going to avoid someone for genuinely trying to help, that's your prerogative, I guess.

The reason you wouldn't have found it when you did a ctrl+f is because of this thing hidden in the middle of this page: https://i.imgur.com/nxX7Qz4.png

I've never worked in an issue this big before, myself, so I didn't notice it until I actually looked. TIL! Sorry for any misunderstanding.

@allquixotic All that being said, after a pretty thorough search of this issue I haven't found anything that actually explains how to install vcrun2019, and I am having the same problem... Would you mind an explaining? I've tried the --force option and googling.

I decided to take a look at the log generated when using the PROTON_LOG flag, and surprisingly, it generated a 274MB file with millions of lines, is it supposed to be like that? Note that I deleted the previous log before launching the game.

@ptkato I had a 8GB log-file once because I enabled PROTON_LOG=1. That was with e1.0.4 and stock proton and a _longer_ session (around 30minutes). Apparently those log-files do get big fast.

@allquixotic All that being said, after a pretty thorough search of this issue I haven't found anything that actually explains how to install vcrun2019, and I am having the same problem... Would you mind an explaining? I've tried the --force option and googling.

From what I found up top vcrun2019 doesn't seem to do anything different except install both vcrun2015 and vcrun2017. Although personally I tried to install both and the install failed saying it was already installed...

@ptkato I had one completely fill my hard drive yesterday... Some 340GB

@allquixotic All that being said, after a pretty thorough search of this issue I haven't found anything that actually explains how to install vcrun2019, and I am having the same problem... Would you mind an explaining? I've tried the --force option and googling.

vcrun2019 seems to be a recent addition to winetricks. In arch it's found in the winetricks-git package but not winetricks.

Wanted to give an update;
I'm running:

• Proton-5.5-GE-1
• protontricks 261550 dotnet472
• proton --gui workaround to install dotnet core
• Windows 10 in winecfg
• Delete all previous autosaves from previous patches of the game

I was able to play an hour and a half session with only 1 crash when changing video settings (I got greedy). Otherwise, I havn't encountered one yet.

Things tested:

• Arena
• Raiding village
• Siming battle and actual battle
• Joined a battle already in progress
• Talked to numerous people
• Paused at almost any time I could think of
• Tried to esc mash out of conversations and battles
• Tabbed like a maniac during battles and after battles
• Alt+Tab pretty much from any spot in the game

An updated guide can be found here

Let me try to put it all together then...

Thanks to VictorRogers, YellowApple, Metal079, allquixotic, lboklin for their great suggestions and corrections and all the others in helping getting Bannerlord to work!

Getting everything you need

Proton-5.5-GE-1

• download the release from here.
  
  
  
  • there's an "Assets" button at the end of each release post
  
  
• extract the content of the .tar.gz file in /home/<your-name>/.steam/compatibilitytools.d/
  
  
  
  • if that folder does not exist, create it
  
  
  • you should now have a subfolder in that folder named Proton-5.5-GE-1
  
  
• restart steam if it is already running
• right-click on Bannerlord and go to "Properties"
  
  
  
  • in the "General" tab at the bottom tick the option "Force the use of a specific Steam Play compatability tool"
  
  
  • you should be able to select the option "Proton-5.5-GE-1"
  
  
• if you don't see the option in the properties, try moving the "Proton-5.5-GE-1" folder into the following location: ~/.local/share/Steam/compatibilitytools.d (create the folders if they don't exist) as was recommended here
  
  
  
  • restart steam and check if the option exists now
  
  

protontricks

• sadly there seems to be no other "easy" way to get protontricks other than using the pipx installation method
• installation instructions can be found here
• according to this post, Arch users may have another alternative by using pamac install protontricks-git

dotNet core

• on the official forums they recommend using the version 2.1.17 of .NET core
• the latest version from Microsoft seems to be version 3.1.3
• _I downloaded and installed both (first the 2.1.17 then 3.1.3)_
  
  
  
  • _it is quite possible that 2.1.17 is enough_
  
  

winetricks with vcrun2019

• it is a good idea to install the latest version of winetricks, because many repositories distribute old versions of winetricks that don't know how to handle vcrun2019
• winetricks is just a binary file that you need to download and make executable:
  
  
  
  • I compiled the instructions from this and this source
  
  

cd "${HOME}/Downloads"
wget  https://raw.githubusercontent.com/Winetricks/winetricks/master/src/winetricks
chmod +x winetricks

• if you want to install it for the current user:

mkdir "${HOME}/bin"
mv winetricks "${HOME}/bin"

• if you want to install it systemwide:

sudo mv winetricks /usr/bin/

• you will have to re-login to see the command in the console

Getting Bannerlord to work

• make sure you have the prerequisite proton version and protontricks installed
• go to /home/<your-name>/.steam/steam/steamapps/compatdata/ and rename the folder "261550" to something like "Backup_261550"
  
  
  
  • copying is not enough, as you actually want start with the initialisation of y completely fresh wine-prefix
  
  
  • copying the folder will backup your savegames, your settings and your whole wine-prefix in case you want to retrieve or test things later on
  
  
• run the game once
  
  
  
  • this is to let steam install some dependencies
  
  
  • starting a new campaign is not necessary
  
  
• exit the game
• open a console and run protontricks 261550 dotnet472
  
  
  
  • it will run through several installations of older versions of dotnet
  
  
  • when the installer asks, choose to "Restart now" (won't actually restart your PC)
  
  
• when it is done, run protontricks 261550 vcrun2019
  
  
  
  • _I am not a hundred percent sure if this is needed, but I did it and my setup seems to work fine_
  
  
• when that is done, run protontricks 261550 --gui
  
  
  
  • select "Select the default wineprefix"
  
  
  • check in the window title if the correct prefix is selected, it should be /home/<your-name>/.steam/steam/steamapps/compatdata/261550/pfx
  
  
  • select "Run explorer"
  
  
  • open the "/" device and go to where you downloaded the dotnet-core file and double-click it to let it install
  
  
  • _as I had two "dotnet core" files, I installed both this way_
  
  
  • close the explorer when the installation has finished
  
  
  • select "Run winecfg"
  
  
  • in the "Applications" tab at the bottom set "Windows version" to Windows 10
  
  
  • _I am not a hundred percent sure if this is needed. I have it at Windows 7 and everything seems to work fine_
  
  
  • close winecfg with the "OK" button and leave the protontricks gui by pressing "Cancel" until it closes
  
  
• start Bannerlord through steam
• start a new campaign
  
  
  
  • you have no other choice, because your old savegames are only in the backup
  
  
  • you can try to recover your old savegames, but only if you made them with the same game-version as the one you are using now
  
  
  • I haven't tested this yet, so...report back if it works.
  
  

Troubleshooting

If things still don't work, there are a few things that were mentioned in the very long github issue that you can try to do.

You are running an AMD GPU and the game doesn't work

• you can try updating to the latest MESA drivers
• a good option for this is the oibaf ppa

You are running NixOS and want to install winetricks

• installation procedures for NixOS are different, so installing winetricks is a bit more complicated. I don't use it, but a script was provided that can be used to install the latest winetricks

The game crashes and I can't restart it

• this might be because of a stuck wineserver process. Check the taskmanager of your OS and kill it if necessary.

I want to debug the game, but the logfiles are HUGE

• proton assumes a set of debug settings, but you can change that. See this post for explanation

@Tercus

extract the content of the .tar.gz file in /home/<your-name>/.steam/compatibilitytools.d/

• you should now have a subfolder in that folder named Proton-5.5-GE-1

I seem to be stuck on this step, theres no compatibilitytools folder there for me and if I create one and extra the folder there, I dont get the option to use it as a proton version

Let me try to put it all together then...

Good guide! A few suggestions:

• Make this a GitHub Gist so it can be linked to rather than having to hunt through this issue (your post will get buried at this rate). Link to it in a comment here. The rest of us can just link to your issue whenever anyone asks a question (in this GitHub issue or elsewhere) that is already covered by your guide.

• Since your instructions include vcrun2019 you should also include the troubleshooting steps for how to fix the situation where the user does not have vcrun2019 available in their winetricks install because it's too old. I and a few other posters included this step a few days ago in this thread, but the crux of it is to run sudo winetricks --self-update. You could also note that this does not work for "NixOS" because of NixOS's unique way of packaging software, but another user kindly contributed a workaround for NixOS users! Hopefully you can find that post too in this thread.

• Another workaround: if the user does not see the directory ~/.steam/compatibilitytools.d then they should run mkdir -p ~/.local/share/Steam/compatibilitytools.d and then copy the Proton-GE folder into there. Thanks to @Metal079

• Another user reported that the game reliably crashed early and often with the AMD open source graphics drivers on Ubuntu 18.04, but when he updated to the oibaf PPA's latest git master open source graphics stack, the game started working. So I guess another known issue would be if you are running an old Ubuntu install using the AMD open source graphics drivers that you need to upgrade them using oibaf's PPA.

@allquixotic Figured out the issue! I needed to create the compatibilitytools.d folder at /home/USERNAME/.local/share/Steam

Make sure the folder name is correct (the ".d" at the end) and also restart steam after you have extracted the proton version. Check if the proton archive accidently extracted one level deeper, such as "Proton-5.5.0-GE-1/Proton-5.5.0-GE-1/"

@allquixotic Figured out the issue! I needed to create the compatibilitytools.d folder at /home/USERNAME/.local/share/Steam

Oh, nice. Not sure what's up with that path being different than the usual ~/.steam. Edited my suggestions for Tercus's guide above!

Wanted to add something, I was having a lot of crashing as well with the solution described above (Proton-GE, dotnet472, dotnet core, and windows 10), and what fixed it for me was switching to the ACO mesa driver rather than the default (I am running Manjaro with Mesa 20.0.4 and a Radeon RX 580). Before switching, I was getting crashes every few minutes (could sometimes play up to an hour without crashing), but after switching to the ACO driver the game hasn't crashed yet after playing for about 2 hours. Hopefully this can help people that are still having issues.

Wanted to add something, I was having a lot of crashing as well with the solution described above (Proton-GE, dotnet472, dotnet core, and windows 10), and what fixed it for me was switching to the ACO mesa driver rather than the default (I am running Manjaro with Mesa 20.0.4 and a Radeon RX 580). Before switching, I was getting crashes every few minutes (could sometimes play up to an hour without crashing), but after switching to the ACO driver the game hasn't crashed yet after playing for about 2 hours. Hopefully this can help people that are still having issues.

I'm using ACO and it didn't seem to improve in any way.

So far I can get about 3 to 4 hours in to a save before I start consistently crashing on all the fixes, and that's if I'm lucky. Often I can only get about an hour. Refreshing the pfx seems to maybe get me an hour on an old save with the same game version. So far I have only gotten past the first few hours without dotnet* but the save times make it a hard thing to test.

@allquixotic
~/.steam should be a sym-link to ~/.local/share/Steam

linux 5.6.2.arch1-2
mesa-aco-git 20.1.0_devel | mesa 20.0.4-1
AMD Ryzen 5 3600X 6-Core Processor
AMD Radeon RX 580

I use proton-5.5-GE-1, have dotnet472, vcrun2019 and dotnetcore2 installed. When I start the game it seems to be running fine. However I get random crashes and when after some crashes I can't restart the game anymore. If this happens opening protontricks 261550 gives the following error:
/home/krulvis/.cache/protontricks/proton/Proton-5.5-GE-1/bin/wine cmd.exe /c echo '%AppData%' returned empty string, error message ""
Did anyone have similar experiences or possibly knows what is going on?

@Krulvis There's very likely a stuck wineserver process that needs killed. I encountered the same thing and killing that stuck wineserver fixed it.

I decided to take a look at the log generated when using the PROTON_LOG flag, and surprisingly, it generated a 274MB file with millions of lines, is it supposed to be like that? Note that I deleted the previous log before launching the game.

@ptkato Yeah, that's normal with protontricks'd .NET versions. You can cut down on that by passing a custom WINEDEBUG variable in your launch options. By default Proton assumes WINEDEBUG=+timestamp,+pid,+tid,+seh,+debugstr,+loaddll,+mscoree; the +seh is what's generating those lines, so that's what you'd want to take out.

You can also set this by creating a user_settings.py in Proton's installation folder, e.g. ~/.steam/steam/compatibilitytools.d/$PROTON_VERSION/ or ~/.steam/steam/steamapps/common/$PROTON_VERSION/ (there should be a user_settings.sample.py in there as a template). This is the way Valve seems to recommend doing it, but I personally prefer to set these things on a per-game basis.

when that is done, run protontricks 261550 --gui dlls

@Tercus You can also just run protontricks 261550 --gui and use that "select the default prefix" option (which is automatically selected). Should get you to the same place (even if that option's misleadingly named, given that the "default" protontricks sets is indeed the one in compatdata/261550/pfx instead of e.g. ~/.wine).

So far I can get about 3 to 4 hours in to a save before I start consistently crashing on all the fixes, and that's if I'm lucky. Often I can only get about an hour. Refreshing the pfx seems to maybe get me an hour on an old save with the same game version. So far I have only gotten past the first few hours without dotnet* but the save times make it a hard thing to test.

This is now my behavior as well. I can get a few hours into a save before I just start crashing consistently. Going to try to look a little more closely at some logs and see what I can find. Im dyin over here! :)

So far I can get about 3 to 4 hours in to a save before I start consistently crashing on all the fixes, and that's if I'm lucky. Often I can only get about an hour. Refreshing the pfx seems to maybe get me an hour on an old save with the same game version. So far I have only gotten past the first few hours without dotnet* but the save times make it a hard thing to test.

@allquixotic
~/.steam should be a sym-link to ~/.local/share/Steam

linux 5.6.2.arch1-2
mesa-aco-git 20.1.0_devel | mesa 20.0.4-1
AMD Ryzen 5 3600X 6-Core Processor
AMD Radeon RX 580

Yeah the ACO thing was a false flag, and after loading my save later today I have been getting the same behavior. Have been looking at the logs, and it seems like the crash is due to the same error every time, which should be encouraging at least:

 Unhandled Exception: System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that othe

TaleWorlds.Localization.TextProcessor.Tokenizer.FindTokenMatches(String text, Int32 beginIndex, Int32 endIndex, List`1 tokenMatches)
   at TaleWorlds.Localization.TextProcessor.Tokenizer.FindTokenMatchesAndText(String text)
   at TaleWorlds.Localization.TextProcessor.Tokenizer.<Tokenize>d__2.MoveNext()
   at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
   at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)
   at TaleWorlds.Localization.MBTextManager.Process(String query, TextObject parent)
   at TaleWorlds.Localization.MBTextManager.ProcessText(TextObject to)
   at TaleWorlds.Localization.MBTextManager.ProcessText(TextObject to)
   at TaleWorlds.Localization.TextObject.ToString()
   at SandBox.ViewModelCollection.Nameplate.PartyNameplateVM.RefreshDynamicProperties(Boolean forceUpdate)
   at System.Threading.Tasks.Parallel.<>c__DisplayClass17_0`1.<ForWorker>b__1()
   at System.Threading.Tasks.Task.InnerInvokeWithArg(Task childTask)
   at System.Threading.Tasks.Task.<>c__DisplayClass176_0.<ExecuteSelfReplicating>b__0(Object )
   at System.Threading.Tasks.Task.Execute()
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task& currentTaskSlot)
   at System.Threading.Tasks.Task.ExecuteEntry(Boolean bPreventDoubleExecution)
   at System.Threading.ThreadPoolWorkQueue.Dispatch()

@ptkato Yeah, that's normal with protontricks'd .NET versions. You can cut down on that by passing a custom WINEDEBUG variable in your launch options. By default Proton assumes WINEDEBUG=+timestamp,+pid,+tid,+seh,+debugstr,+loaddll,+mscoree; the +seh is what's generating those lines, so that's what you'd want to take out.

Thanks, that helped, the log now follows:
steam-261550.log

Unhandled Exception: System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that othe
TaleWorlds.Localization.TextProcessor.Tokenizer.FindTokenMatches(String text, Int32 beginIndex, Int32 endIndex, List`1 tokenMatches)
at TaleWorlds.Localization.TextProcessor.Tokenizer.FindTokenMatchesAndText(String text)
at TaleWorlds.Localization.TextProcessor.Tokenizer.d__2.MoveN
...

@tkamat Sorry if this this is noise but what log is that from, couldn't find anything similar in 261550/pfx/drive_c/ProgramData/Mount and Blade II Bannerlord/logs/ or from WINEDEBUG=+timestamp,+pid,+tid,+seh,+debugstr,+loaddll,+mscoree

@allquixotic @Tercus I would state that Proton tricks can be installed via AUR "pamac install protontricks-git" I believe IIRC (Not at my desk currently to double-check the package name)

Did multiplayer stop working for anyone? I'm getting couldn't receive login results from server errors now. :(

I have updated my small guide and included the suggestions. The gist can be found here. You can comment there for changes to it. Thank you all for the great work. So short after release and the game is playable under linux!

@ptkato Looked through the log, only thing I noticed was

4307.340:002a:0032:err:winediag:SECUR32_initNTLMSP ntlm_auth was not found or is outdated. Make sure that ntlm_auth >= 3.0.25 is in your path. Usually, you can find it in the winbind package of your distribution

I can't be sure this is what's causing your crashes, but it's an easy one to fix; you are missing a Linux package! If your are on Debian/Ubuntu based distros it'll be winbind like the error message says, if you're running something Arch based, it'll be samba.

Give it a go and see if that fixes anything!

I've figured out what it was that, at least for me, made my saving times much faster than some others.
Without dotnet my saving times were around 10 seconds and with dotnet it took around 2 seconds. Some others had similar numbers.
Where for most, it seems, the numbers where more around 2-3 minutes and 30 seconds respectively.

The reason, for me, is fsync. With it enabled I get the fast saving times, with it off I get the slow saving times.

For me dotnet seems to be the cause of a lot of seemingly random crashes, I've tried all combinations of fixes here as well as things I've come up with myself with no improvement. The performance issues some had with dotnet never seem to happen for me, so crashes are the only issue with dotnet I've had.

So my best experience, currently, is to not do any protontricks tweaks/installs but make sure fsync is working, which it already was. I rather have 10 second saves and no/much fewer crashes than 2 second saves and lots of crashes. I have not tried it long enough to tell just how crash free I am, but at the very least it has significantly improved.

I do need dotnet for the launcher to work though, so I use the new intended workaround to bypass the launcher TaleWorlds introduced in a recent patch, to launch Bannerlord.Native.exe instead. Rename it to TaleWorlds.MountAndBlade.Launcher.exe and I'm good to go.

Edit: A drawback with the alternative exe is that the launcher handles mod loading, so mods are not loaded if the launcher is bypassed. It can be handled by doing what's mentioned here, so it manageable but not ideal.

@albin-engstrom Hmm, the game running better with fsync makes me think that esync could be a problem, as it has been for other games. Has anyone tried running the game with PROTON_NO_ESYNC=1?

@tkamat I've tried all combinations of fsync and esync on or off. But only with dotnet.
With esync and fsync off the crashing was the same as any other combination as far as I could tell. As that was what I was testing at the time I didn't specifically note how the saving times where, but if they were notably slower I assume I would have noticed that.

@tkamat @albin-engstrom I also tested the game with esync, fsync and without both and without dotnet the saving times are always around 15 seconds (with a ryzen 3700x cpu and samsung 860 evo ssd).

UPDATE:
@albin-engstrom When using your suggestion (Bannerlord.Native.exe symlinked to TaleWorlds.MountAndBlade.Launcher.exe) my save times improve by about 50% e.g. I now get save times around 7.5 seconds (when not running any winetricks command).

Did multiplayer stop working for anyone? I'm getting couldn't receive login results from server errors now. :(

Checked again this morning and it's working now! Woo!

I also tested the game with esync, fsync and without both and without dotnet the saving times are always around 15 seconds (with a ryzen 3700x cpu and samsung 860 evo ssd).

@elovin That's interesting. It may be that there's some kind of issue fsync solves/workround in my case but in other cases the issue may not be present and fsync does not change things as much. And I have a Ryzen 3900X and a 970 Evo, so fairly similar stuff so that would be unlikely to be the difference for us.

When using your suggestion (Bannerlord.Native.exe symlinked to TaleWorlds.MountAndBlade.Launcher.exe) my save times improve by about 50% e.g. I now get save times around 7.5 seconds (when not running any winetricks command).

That's great, the reason may be that it seems to load things differently. When i first tried that I had dotnet installed and short save times and the exe rename seem to disable/not load dotnet. I had the long savetimes once I did it.
It may be that dotnet is only specifically needed for the launcher and loaded with it so when the launcher is bypassed dotnet isn't loaded.
It's possible there are some other things that aren't loaded as well that might be the reason of your results.

@albin-engstrom Well I finally finished compiling an fsync enabled kernel (I used linux-tkg), and I can confirm that save times without dotnet or any other protontricks went down from ~2 minutes to only about 10 seconds! I haven't played for long enough to make any definitive conclusions about stability, but I have not had any crashes so far with this configuration, while all of the dotnet solutions I tried ended up crashing eventually.

To reiterate, here are the steps I followed:

1. Install an fsync enabled kernel (again I would recommend linux-tkg).
2. Symlink Bannerlord.Native.exe to TaleWorlds.MountAndBlade.Launcher.exe
3. Select Proton-5.5-GE-1, delete previous prefix, and launch the game.
4. Thats it! No protontricks or other stuff required.

While the save times are a bit longer with this method, I think the vastly increased stability makes up for the few second difference, and I will be using this until someone manages to debug the dotnet crashes. Would be great to see if this works for anyone else, and yeah thanks to @albin-engstrom for figuring out the fsync thing.

@tkamat Great to hear it works well for someone else as well, I've now played for about 3 hours with this configuration without a single crash where before I had at least a few an hour, sometimes much more and sometimes much fewer. But 3 hours without crashes have been unheard of.

I'm also using linux-tkg and can recommend that, it's a great help for compiling your own kernel while not doing it entirely on your own. I do it for various reasons, fsync being one.
But if one does not want to compile their own there likely are some precompiled ones available on one's distribution of choice.

In my case I'm also using proton-tgk as well as tkg's scripts for compiling dxvk.

@albin-engstrom Well I finally finished compiling an fsync enabled kernel (I used linux-tkg), and I can confirm that save times without dotnet or any other protontricks went down from ~2 minutes to only about 10 seconds! I haven't played for long enough to make any definitive conclusions about stability, but I have not had any crashes so far with this configuration, while all of the dotnet solutions I tried ended up crashing eventually.

To reiterate, here are the steps I followed:

1. Install an fsync enabled kernel (again I would recommend linux-tkg).
2. Symlink Bannerlord.Native.exe to TaleWorlds.MountAndBlade.Launcher.exe
3. Select Proton-5.5-GE-1, delete previous prefix, and launch the game.
4. Thats it! No protontricks or other stuff required.

While the save times are a bit longer with this method, I think the vastly increased stability makes up for the few second difference, and I will be using this until someone manages to debug the dotnet crashes. Would be great to see if this works for anyone else, and yeah thanks to @albin-engstrom for figuring out the fsync thing.

Have you led any sieges in game yet? I have noticed participating in sieges, but especially leading the siege is a very crash prone activity.

@vahtos I have not led any, but I've participated in 3 without any crashes.

@vahtos I just tried leading a siege and it did not crash. Might have to do with your specs, maybe try lowering your graphics. I noticed setting the texture budget to low was pretty helpful to me.

@tkamat Thanks. I will try your setup then. I don't think it is a texture budget issue, as I crash on the campaign map when setting up the siege or building siege engines. I have never actually made it into battle in a siege that I am leading.

I just tested the game in a fresh prefix with none of the protrontricks fixes, while having fsync enabled, and I didn't have a single crash. Apart from trying to fiddle with the game settings, which still crashed the game, the game is very stable to the point of being totally playable.

@albin-engstrom Well I finally finished compiling an fsync enabled kernel (I used linux-tkg), and I can confirm that save times without dotnet or any other protontricks went down from ~2 minutes to only about 10 seconds! I haven't played for long enough to make any definitive conclusions about stability, but I have not had any crashes so far with this configuration, while all of the dotnet solutions I tried ended up crashing eventually.
To reiterate, here are the steps I followed:

1. Install an fsync enabled kernel (again I would recommend linux-tkg).
2. Symlink Bannerlord.Native.exe to TaleWorlds.MountAndBlade.Launcher.exe
3. Select Proton-5.5-GE-1, delete previous prefix, and launch the game.
4. Thats it! No protontricks or other stuff required.

While the save times are a bit longer with this method, I think the vastly increased stability makes up for the few second difference, and I will be using this until someone manages to debug the dotnet crashes. Would be great to see if this works for anyone else, and yeah thanks to @albin-engstrom for figuring out the fsync thing.

Have you led any sieges in game yet? I have noticed participating in sieges, but especially leading the siege is a very crash prone activity.

I tried participating in one one particular siege about six times, which froze about two seconds into the loading screen on all but one occasion. I haven't tried sieging any other towns yet.
This is with a 5700XT, using the open source drivers, with the proton build original posted by @YellowApple , and no other tweaks.

I've gone back to Warband but it looks like good progress has been made here so I might jump back on the wine-debugging-bandwagon this weekend.

Fedora 32, Kernel 5.6.3
Ryzen 2700 at 4ghz
AMD Rx580
Proton-5.5-GE-1

I did install DotNet 4.72 using Winetricks. The launcher works fine if you do this. However, performance is not so good. I then tried replacing the launcher with Bannerlord.Native.exe. This actually improved performance significantly. But saving the game now takes ~2 minutes. Additionally, there will be moments the game hits 100% cpu usage and appears to freeze up. After a couple minutes it will go back to normal and be playable again.

Performance is somewhat good. It feels a little stuttery, and freezes occasionally.

Edit: A drawback with the alternative exe is that the launcher handles mod loading, so mods are not loaded if the launcher is bypassed. It can be handled by doing what's mentioned here, so it manageable but not ideal.

Might be worth trying to pass 'em in as launch options; it looks like the .exe takes a list of them in its arguments if my rgl_log is anything to go by:

Command Args: /singleplayer _MODULES_*Native*SandBoxCore*CustomBattle*Sandbox*StoryMode*BannerLogger*CalradiaFutureWarfare*CharacterTrainer*DeveloperConsole*XorberaxYell*zzBannerlordTweaks*zzCharacterCreation*_MODULES_ /anticheat

I installed XanMod kernel for Ubuntu 19.10 and I can confirm save times dropped from a minute or two to a couple of seconds with fresh prefix without protontricks.

@DeathTBO Try an fsync enabled kernel, that should speed up saving to about 10 seconds or less. It has done for some at least. I don't know if a precompiled one is available for Fedora though, but I'd assume there is at least one. Otherwise you may have to compile your own.
And the freezes you mention are just the autosaves so those would be much faster as well.

Might be worth trying to pass 'em in as launch options; it looks like the .exe takes a list of them in its arguments if my rgl_log is anything to go by:
Command Args: /singleplayer _MODULES_*Native*SandBoxCore*CustomBattle*Sandbox*StoryMode*BannerLogger*CalradiaFutureWarfare*CharacterTrainer*DeveloperConsole*XorberaxYell*zzBannerlordTweaks*zzCharacterCreation*_MODULES_ /anticheat

@YellowApple I'll give that a shot later, if it works it's a better approach as the other approach requires copying the mod files into the other modules instead of keeping them separated as intended.

Tried the game with only proton GE and it runs very nice. Unsurprisingly the main problem is the long saves but I would tolerate it if the game wasn't autosaving before every fight... is there a way to disable those aumatic saves ? I rather make a few (long) saves when I want than running a different kernel.

Install dotnet472, it makes the game save almost instantly and a friend of mine who played Warband regularly told me that you will want to save very frequently because it crashes often (even on Windows). It also fixes the launcher, but that's not terribly special since symlinking Bannerlord.exe to ManagedStarter.exe does the same.

Install dotnet472, it makes the game save almost instantly and a friend of mine who played Warband regularly told me that you will want to save very frequently because it crashes often (even on Windows). It also fixes the launcher, but that's not terribly special since symlinking Bannerlord.exe to ManagedStarter.exe does the same.

I tried with dotnet but the game crashed quite a few time so I rather run the game with proton GE alone if it is possible to disable autosaving.

@Zouizoui78 As far as I know there is no known way of disabling autosave unfortunately.

I installed the liquorix kernel (which I guess is fsync enabled) on Linux Mint 19.2, used a fresh prefix, and now getting about 10 second saves. So far seems stable, only had about an hour play session but no crashes except when I initially changed my settings (seems to always happen).

Performance noticeably worse than before (stutters on loading textures or the first time I go in combat, main menu had massive fps drops on default/max graphical settings), but bumping it down to medium seems mostly fine.

Just a heads-up, the latest Proton-GE, 5.5-1, already merged the mouse fixes from wine-staging.

Using these fixes, I still am only getting mouse control maybe 1 out of every 10 launches.

That's really strange, after patching wine a while back I get mouse control 100% of the time. Anyone else experiencing this same issue where the patches _don't_ work?

@jaynus: did you try using a fresh prefix (run protontricks 261550 annihilate)? It shouldn't make any difference, but maybe you have some weird overrides from before, or ??

@craftyguy Using a fresh prefix, I'm getting mouse clicks every other lauch. I'm using proton-5.5-GE-1, and protontricks dotnet472 and vcrun2019

Using a fsync enabled kernel + fresh prefix has made the game very stable for me now.
Earlier I have had crashes every 10 / 15 min and even more frequently in some areas.

I installed linux-zen which has fsync already patched in.
On Arch linux the prebuilt zen kernel is in the official repository, so it's super easy to install.
I made a new prefix, running proton-tkg 5.5 and did not install any additional libraries.

Game is very stable and I played for over 1 hour with no crashes. Save times are a bit slow (10 seconds) but it is a good trade off for stability.

I recommend everyone to try the linux-zen kernel.

I installed the liquorix kernel (which I guess is fsync enabled) on Linux Mint 19.2, used a fresh prefix, and now getting about 10 second saves. So far seems stable, only had about an hour play session but no crashes except when I initially changed my settings (seems to always happen).

Performance noticeably worse than before (stutters on loading textures or the first time I go in combat, main menu had massive fps drops on default/max graphical settings), but bumping it down to medium seems mostly fine.

Performance drops when loading textures/scenes for the first time is normal, these should start to disappear the more you play as the shader cache does its thing.

I recommend everyone to try the linux-zen kernel.

I've been reading for some hours now on this new kernel. I can't seem to find a rollback option. I am looking at liquorix in particular. Let's say there is some issue with the kernel, is it difficult to go back to debian's default?

I installed the liquorix kernel (which I guess is fsync enabled) on Linux Mint 19.2, used a fresh prefix, and now getting about 10 second saves. So far seems stable, only had about an hour play session but no crashes except when I initially changed my settings (seems to always happen).
Performance noticeably worse than before (stutters on loading textures or the first time I go in combat, main menu had massive fps drops on default/max graphical settings), but bumping it down to medium seems mostly fine.

Performance drops when loading textures/scenes for the first time is normal, these should start to disappear the more you play as the shader cache does its thing.

Seems like it, after playing for a few hours didn't really notice anything. All in all a 5 hour session without a single crash.

@jake-hedges Normally, when I want to experiment with different kernels, I configure my bootloader to have a menu option to boot the experimental kernel, while leaving the stable / mainline as a default option. That way you don't lose the fallback option.

I recommend everyone to try the linux-zen kernel.

I've been reading for some hours now on this new kernel. I can't seem to find a rollback option. I am looking at liquorix in particular. Let's say there is some issue with the kernel, is it difficult to go back to debian's default?

Try asking on debian's IRC or some other support channel for your distro. This is off-topic here..

And a warning to others: don't download random kernels or mess around with experimenting with kernels if you don't know how to recover, or lack the motivation to figure it out. People are generally quick to recommend things that might break your system, but slow to help you fix things when they break.

Try asking on debian's IRC or some other support channel for your distro. This is off-topic here..

This is 180 degrees rotation coming from user who soapbox about using random developers workarounds in a troubleshooting thread.

Sorry, but I believe if workarounds are suggested that may impact your entire system, discussing a rollback is just good practice. It may not fit _your_ scope of this thread, but it sounds like this option is very attractive to many people right now. Why you decide to suddenly become pseudo moderator is comedic.

Try asking on debian's IRC or some other support channel for your distro. This is off-topic here..

This is 180 degrees rotation coming from user who soapbox about using random developers workarounds in a troubleshooting thread.

Sorry, but I believe if workarounds are suggested that may impact your entire system, discussing a rollback is just good practice. It may not fit _your_ scope of this thread, but it sounds like this option is very attractive to many people right now. Why you decide to suddenly become pseudo moderator is comedic.

@jake-hedges maybe you aren't paying attention (hint: you aren't) but I never suggested you use some random kernel, someone else did. I'm suggesting that all this "omg I bricked my system trying some kernels!" discussion go elsewhere, it has nothing to do with the topic here.

Why you decide to suddenly become pseudo moderator is comedic.

The signal:noise ratio in this issue is super high, so those of us who actually care about tracking the issues with this game have to wade through comments by assclowns like you who would rather talk about how to fix your distro install that you fucked up trying suggestions that you don't understand.

So, go ask for support fixing your linux installation elsewhere (that you evidently broke, lol), this is not a debian support forum.

While installing another kernel as a workaround is of interest to us who want to play now, it isn't really relevant to getting the game to work properly since Steam is not about to install a new kernel to make a game run properly with proton. So with @craftyguy's logic no further discussion should happen around it. The other option is to allow some brief guides (not support) on how to do this for various distros.

While I'm already commenting on this I might as well add that for NixOS there is no zen kernel in nixpkgs, but it's very easy to add the patch to your configuration.nix like so:

boot.kernelPatches = [
      { name = "fsync-support"; patch = ./linux-v5.4-fsync.patch; }
    ];

where linux-v5.4-fsync.patch is taken from here. That's all there is to it. It took a while to compile the kernel and I had to limit the number of cores to use or it would lock up my system for some reason.

Kernel workaround is wrong in many ways. Don't use it unless you really want to play game with less crashes when it's in early access state. IMHO it works okay on stable kernel on ArchLinux with Proton 5.5 GE + dotnet472 and dotnet core from comments earlier. I have 13 hour gameplay with occasional 1 to 2 hour no problem gameplay. Just save it frequently and you will be okay. And also, take it easy it's just a game.

@CrafterSvK My understanding is that the motivation for using a kernel with Valve's fsync patch is not reducing crashes. The game seems to use some Windows synchronization primitives which have a parallel in Linux (eventfd) but are not quite identical. The Proton devs wrote a kernel patch to allow a thread to wait on multiple futexes in the exact same way it is done on Windows, but it hasn't yet passed Linux's high standards and thus is not merged upstream.

I surmise the lack of these primitives forces Wine to emulate them in an extremely inefficient way, and produces a brutal hang in the game every time it saves, which is very often. I've played numerous hours with it and it is playable but painful. I will be experimenting with the zen kernel later today, and if it works it would be worth booting into just to play this game. "Save frequently" is exceptionally bad advice because the problem being addressed here is that saving the game takes upwards of 2 minutes.

I'm seeing suggestions for symlinking to skip the launcher, but a cleaner solution that doesn't require you to repeat the process every patch is to tell Steam to run the right binary to begin with in the launch options. Here's mine: echo %command% && exec /usr/share/steam/compatibilitytools.d/proton-ge-custom/proton waitforexitandrun "/home/$USER/.local/share/Steam/steamapps/common/Mount & Blade II Bannerlord/bin/Win64_Shipping_Client/Bannerlord.exe"

In case you're using a different Proton directory, you can get the real %command% Steam is running by launching the game with echo %command% > ~/cmd.

@CrafterSvK My understanding is that the motivation for using a kernel with Valve's fsync patch is not reducing crashes. The game seems to use some Windows synchronization primitives which have a parallel in Linux (eventfd) but are not quite identical. The Proton devs wrote a kernel patch to allow a thread to wait on multiple futexes in the exact same way it is done on Windows, but it hasn't yet passed Linux's high standards and thus is not merged upstream.

I surmise the lack of these primitives forces Wine to emulate them in an extremely inefficient way, and produces a _brutal_ hang in the game every time it saves, which is very often. I've played numerous hours with it and it is playable but painful. I will be experimenting with the zen kernel later today, and if it works it would be worth booting into just to play this game. "Save frequently" is exceptionally bad advice because the problem being addressed here is that saving the game takes upwards of 2 minutes.

I am saving in 1-2 seconds with GE version of proton so my advice is based on experience.

@KimmoKM which version of XanMod are you using? I tried XanMod and (after I fixed the totally borked nvidia drivers) things are decidedly worse on my end.

Looks like the FUTEX_WAIT_MULTIPLE kernel patches had a pretty good impact on a fresh non-protontricks'd build for me, too (using the patch from linux-tkg, combined with a modified version of Slackware64-current's kernel-generic.SlackBuild). Performance and savetimes are still noticeably worse than with dotnet472 (still lots of stuttering, especially on the campaign map), but savetimes are significantly better than with a default prefix and no FUTEX_WAIT_MULTIPLE (to the point where "save often" is actually viable, since saving takes around 10-30 seconds instead of multiple minutes), and it's infintely less crashy than with dotnet472 (just played for multiple hours straight with zero crashes, whereas before I'd be lucky if I made it an hour).

I'm seeing suggestions for symlinking to skip the launcher, but a cleaner solution that doesn't require you to repeat the process every patch is to tell Steam to run the right binary to begin with in the launch options.

If you're just doing the ManagedStarter.exe → Bannerlord.exe and ManagedStarter_BE.exe → Bannerlord_BE.exe symlinks, those should survive patches and still get the launcher working (or at least both have been true in my case, through pretty much every patch over the last couple weeks and dozens of prefixes both with and without any version of dotnet). If you're indeed bypassing the launcher entirely, then yeah, launch options are a clean way to do it.

@KimmoKM which version of XanMod are you using? I tried XanMod and (after I fixed the totally borked nvidia drivers) things are decidedly worse on my end.

5.5.15-xanmod1 from this repository. I'm using AMD GPU.

@KimmoKM that's the same version I pulled...
$cat /proc/version
Linux version 5.5.15-xanmod1 (root@mascote) (gcc version 9.3.0 (Debian 9.3.0-8)) #0 SMP PREEMPT Thu Apr 2 10:37:55 -03 2020

Perhaps Nvidia/AMD could be the problem. I'm using GloriousEggroll's Proton 5.5-1. After the change the game launcher works fine, but when I try to launch the game, it opens to a white screen then immediately crashes. The crash uploader works now though somehow.

@KimmoKM that's the same version I pulled...
$cat /proc/version
Linux version 5.5.15-xanmod1 (root@mascote) (gcc version 9.3.0 (Debian 9.3.0-8)) #0 SMP PREEMPT Thu Apr 2 10:37:55 -03 2020

Perhaps Nvidia/AMD could be the problem. I'm using GloriousEggroll's Proton 5.5-1. After the change the game launcher works fine, but when I try to launch the game, it opens to a white screen then immediately crashes. The crash uploader works now though somehow.

If I'm not mistaken, the fix is documented here: https://gist.github.com/Tercus/3db75788df3c7e1efee06904bb985419 under Troubleshooting.

@allquixotic Unfortunately not... I'm using Nvidia drivers, not AMD. Things were generally working for me albeit with frequent crashes. xanmod kernel seems to have broken my setup. I'll play around some more and see if I can get it to work, but I may just have to revert.

AMD® Ryzen threadripper 1900x 8-core processor × 16
NVidia 2060
Ubuntu 19.10 with xanmod kernel (5.5.15-xanmod1)

EDIT

Fixed: Turns out Nvidia drivers were still the problem, looks like you can't install new drivers with the Ubuntu GUI after switching to the new kernel... One more try with command line and everything is up and running easily.

After more vigorous testing today, I retract my previous statement. Performance is better with Dotnet 4.7 installed and using the launcher. Dotnet also speeds up save times to just a few seconds, as well as loading areas. General performance could use some work, but I think that's related to the game itself.

@YellowApple Loading mods through launch options work.

So for people that bypass the launcher by launching Bannerlord.Native.exe instead and have mods they want to load can use this as a launch option in Steam.

%command%
 _MODULES_
*Native*SandBoxCore*CustomBattle*Sandbox*StoryMode*TheNameOfAMod*
_MODULES_

@allquixotic Unfortunately not... I'm using Nvidia drivers, not AMD. Things were generally working for me albeit with frequent crashes. xanmod kernel seems to have broken my setup. I'll play around some more and see if I can get it to work, but I may just have to revert.

AMD® Ryzen threadripper 1900x 8-core processor × 16
NVidia 2060
Ubuntu 19.10 with xanmod kernel (5.5.15-xanmod1)

EDIT

Fixed: Turns out Nvidia drivers were still the problem, looks like you _can't_ install new drivers with the Ubuntu GUI after switching to the new kernel... One more try with command line and everything is up and running easily.

I'm using the latest Nvidia drivers with the Xanmod LTS kernel (the latest 5.4.x stable) and it's working well here, too.

@allquixotic Unfortunately not... I'm using Nvidia drivers, not AMD. Things were generally working for me albeit with frequent crashes. xanmod kernel seems to have broken my setup. I'll play around some more and see if I can get it to work, but I may just have to revert.

AMD® Ryzen threadripper 1900x 8-core processor × 16
NVidia 2060
Ubuntu 19.10 with xanmod kernel (5.5.15-xanmod1)

EDIT

Fixed: Turns out Nvidia drivers were still the problem, looks like you _can't_ install new drivers with the Ubuntu GUI after switching to the new kernel... One more try with command line and everything is up and running easily.

I'm experiencing the same crash where it just shuts down at the white screen with a crash report. I'm using Ubuntu 18.04.4 on a MBP with an Intel GPU and I haven't managed to get past this white screen crash yet. As far as I know you seem to be the only one in this thread that experienced this crash, so I'm assuming it is a driver issue. My question is were your drivers working with Bannerlord before using xanmod? If so then I know that's what I have to look into unless anyone has other helpful thoughts.

There's definitely something the launcher does that have an impact on savetimes.
I don't have dotnet installed as it cause crashes and fsync enabled to get decent savetimes.

As the launcher does not launch without dotnet I can either bypass it by renaming Bannerlord.Native.exe to TaleWorlds.MountAndBlade.Launcher.exe which make Steam launch that instead. One can also symlink or use launch options to achieve this.

Or I can rename Bannerlord.exe and Bannerlord_BE.exe to ManagedStarter.exe and ManagedStarter_BE.exe respectively to make the launcher work, I'm don't know why it does, it may have been explained at some point in this thread. The symlink or launch option approach may work there as well.

When doing the former and bypassing the launcher I get around 9 second savetimes, when using the latter approach to use the launcher I get around 16 second savetimes.

@remosasso Yes my drivers were working before using xanmod. If you go to the about section in the settings you should see your graphics listed... Before updating the drivers it did not identify my card as NVidia... I updated with the following:

$ sudo add-apt-repository ppa:graphics-drivers/ppa
$ sudo apt update
$ sudo apt-get install nvidia-driver-440

Reboot

@remosasso Yes my drivers were working before using xanmod. If you go to the about section in the settings you should see your graphics listed... Before updating the drivers it did not identify my card as NVidia... I updated with the following:

$ sudo add-apt-repository ppa:graphics-drivers/ppa
$ sudo apt update
$ sudo apt-get install nvidia-driver-440

Reboot

Thanks. However, it seems like my drivers are installed well and all so no luck for me there. Have you encountered anyone else with the white screen crash problem? I get the same crash no matter which Proton I use, whether I use dotnet 472 or changing any .exe files. The drivers seem like the logical problem, then but they don't appear to be.

I am facing the same white screen crash on nvidia. The autosave was created while running on linux and it crashes a few seconds after loading the autosave. The game works fine from the same save on windows

Has anyone done any performance comparisons between Proton and Windows yet?

I'm unable to find games in multiplayer in 1.1 beta branch and reverting to stable branch I'm unable to login. Anyone else able to play mp?

Edit:
It seems mp is broken for everyone (unconfirmed) on beta branch: https://forums.taleworlds.com/index.php?threads/e1-1-0-cant-test-new-patch-because-cant-find-a-match.413059/

I'll try stable branch again and see if I can log in now.

I'm unable to find games in multiplayer in 1.1 beta branch and reverting to stable branch I'm unable to login. Anyone else able to play mp?

Edit:
It seems mp is broken for everyone (unconfirmed) on beta branch: https://forums.taleworlds.com/index.php?threads/e1-1-0-cant-test-new-patch-because-cant-find-a-match.413059/

I'll try stable branch again and see if I can log in now.

I was just able to log in to multiplayer on the stable branch. I did have an issue about two nights ago where I was unable to log in, but it resolved itself the next day.

I'm unable to login on stable branch right now. Maybe something gets messed up when reverting from beta?

I'm unable to login on stable branch right now. Maybe something gets messed up when reverting from beta?

It happened to me several nights ago before the beta even existed. I thought they had finally found out that I wasn't on Windows and banned me. It started working again the next day.

It's working for me now, and I was playing SP on the beta earlier before reverting back to stable for MP.

Using PROTON_LOG=1 option I find this in the log:

[000000000000006F:] EXCEPTION handling: System.Net.Sockets.SocketException: Connection reset by peer.
...
[000000000000006F:] EXCEPTION handling: System.IO.IOException: Unable to read data from the transport connection: Connection reset by peer.
...
[000000000000006E:] EXCEPTION handling: System.Net.Sockets.SocketException: Error looking up error string
[000000000000006E:] EXCEPTION handling: System.IO.IOException: Unable to write data to the transport connection: Error looking up error string.
[0000000000000067:] EXCEPTION handling: System.IO.IOException: The authentication or decryption has failed.
...
[0000000000000073:] EXCEPTION handling: System.Net.WebException: Error: SecureChannelFailure (The authentication or decryption has failed.)
...
[0000000000000073:] EXCEPTION handling: System.AggregateException: One or more errors occurred. (Error: SecureChannelFailure (The authentication or decryption has failed.))
...
[0000000000000066:] EXCEPTION handling: System.Net.WebException: The operation has timed out.
...

I should add that this is on the default prefix running on an fsync-enabled kernel. I've tried with and without VPN.

New beta version 1.1.0 seems to fix more crashes. I even get back a corrupted save from 1.0.10. I'm using "vanilla" proton-gtk. I'm still notice some performance issues sometimes, a saving time around 10~12 seconds and random crashes after 3-4 hours but it's clearly playable.

I've put 60+ hours into this game on linux. Lived with the 30+ second save time for a while, but using Proton 5.5-GE with dotnet472 and dotnetcore have reduced my save times to less than 5 seconds.

.NET core is open source, maybe wine/proton should consider bundling it as an optional component the way they do with gecko.

My game crashes during launch. I'm on version e1.1.0 - Beta with Proton-5.5-GE-1

❯ rm -rf ~/.steam/steam/steamapps/compatdata/261550
❯ # Launch the game
❯ protontricks --version
protontricks (1.4.1)
❯ winetricks --version
20191224 - sha256sum: 1582b249d827074bb4c456b6ee5f55293a5fea5a66245f5cbe474f771c65e820
❯ protontricks 261550 dotnet472 2&>1 > log

------------------------------------------------------
You are using a 64-bit WINEPREFIX. Note that many verbs only install 32-bit versions of packages. If you encounter problems, please retest in a clean 32-bit WINEPREFIX before reporting a bug.
------------------------------------------------------
Using winetricks 20191224 - sha256sum: 7b91df1f0a0c7be5e085edce2737ea9d8cea60b6ed891e04f041a46e61242131 with wine-5.0 and WINEARCH=win64
Executing w_do_call dotnet472
------------------------------------------------------
You are using a 64-bit WINEPREFIX. Note that many verbs only install 32-bit versions of packages. If you encounter problems, please retest in a clean 32-bit WINEPREFIX before reporting a bug.
------------------------------------------------------
Executing load_dotnet472 
------------------------------------------------------
This package (dotnet472) may not fully work on a 64-bit installation. 32-bit prefixes may work better.
------------------------------------------------------
Current Wine does not have Wine bug 42170, so not applying workaround
Executing w_do_call remove_mono
------------------------------------------------------
You are using a 64-bit WINEPREFIX. Note that many verbs only install 32-bit versions of packages. If you encounter problems, please retest in a clean 32-bit WINEPREFIX before reporting a bug.
------------------------------------------------------
Executing load_remove_mono 
uninstaller: The application with GUID '{8938A429-407D-5208-903D-37777470D766}' was not found
------------------------------------------------------
Working around wine bug 34803 
------------------------------------------------------
reg: The system was unable to find the specified registry key or value
reg: The system was unable to find the specified registry key or value
reg: The system was unable to find the specified registry key or value
Executing rm -f /home/tanner/.steam/steam/steamapps/compatdata/261550/pfx/dosdevices/c:/windows/system32/mscoree.dll
Executing rm -f /home/tanner/.steam/steam/steamapps/compatdata/261550/pfx/dosdevices/c:/windows/syswow64/mscoree.dll
Executing w_do_call dotnet462
------------------------------------------------------
You are using a 64-bit WINEPREFIX. Note that many verbs only install 32-bit versions of packages. If you encounter problems, please retest in a clean 32-bit WINEPREFIX before reporting a bug.
------------------------------------------------------
Executing load_dotnet462 
------------------------------------------------------
This package (dotnet462) may not fully work on a 64-bit installation. 32-bit prefixes may work better.
------------------------------------------------------
Executing w_do_call remove_mono
------------------------------------------------------
You are using a 64-bit WINEPREFIX. Note that many verbs only install 32-bit versions of packages. If you encounter problems, please retest in a clean 32-bit WINEPREFIX before reporting a bug.
------------------------------------------------------
Executing load_remove_mono 
------------------------------------------------------
Mono does not appear to be installed.
------------------------------------------------------
Executing w_do_call dotnet461
------------------------------------------------------
You are using a 64-bit WINEPREFIX. Note that many verbs only install 32-bit versions of packages. If you encounter problems, please retest in a clean 32-bit WINEPREFIX before reporting a bug.
------------------------------------------------------
Executing load_dotnet461 
------------------------------------------------------
This package (dotnet461) may not fully work on a 64-bit installation. 32-bit prefixes may work better.
------------------------------------------------------
Executing w_do_call remove_mono
------------------------------------------------------
You are using a 64-bit WINEPREFIX. Note that many verbs only install 32-bit versions of packages. If you encounter problems, please retest in a clean 32-bit WINEPREFIX before reporting a bug.
------------------------------------------------------
Executing load_remove_mono 
------------------------------------------------------
Mono does not appear to be installed.
------------------------------------------------------
Executing w_do_call dotnet46
------------------------------------------------------
You are using a 64-bit WINEPREFIX. Note that many verbs only install 32-bit versions of packages. If you encounter problems, please retest in a clean 32-bit WINEPREFIX before reporting a bug.
------------------------------------------------------
Executing load_dotnet46 
------------------------------------------------------
This package (dotnet46) may not fully work on a 64-bit installation. 32-bit prefixes may work better.
------------------------------------------------------
Executing w_do_call remove_mono
------------------------------------------------------
You are using a 64-bit WINEPREFIX. Note that many verbs only install 32-bit versions of packages. If you encounter problems, please retest in a clean 32-bit WINEPREFIX before reporting a bug.
------------------------------------------------------
Executing load_remove_mono 
------------------------------------------------------
Mono does not appear to be installed.
------------------------------------------------------
Executing w_do_call dotnet45
------------------------------------------------------
You are using a 64-bit WINEPREFIX. Note that many verbs only install 32-bit versions of packages. If you encounter problems, please retest in a clean 32-bit WINEPREFIX before reporting a bug.
------------------------------------------------------
Executing load_dotnet45 
------------------------------------------------------
This package (dotnet45) may not fully work on a 64-bit installation. 32-bit prefixes may work better.
------------------------------------------------------
Executing w_do_call remove_mono
------------------------------------------------------
You are using a 64-bit WINEPREFIX. Note that many verbs only install 32-bit versions of packages. If you encounter problems, please retest in a clean 32-bit WINEPREFIX before reporting a bug.
------------------------------------------------------
Executing load_remove_mono 
------------------------------------------------------
Mono does not appear to be installed.
------------------------------------------------------
Executing w_do_call dotnet40
------------------------------------------------------
You are using a 64-bit WINEPREFIX. Note that many verbs only install 32-bit versions of packages. If you encounter problems, please retest in a clean 32-bit WINEPREFIX before reporting a bug.
------------------------------------------------------
Executing load_dotnet40 
------------------------------------------------------
This package (dotnet40) may not fully work on a 64-bit installation. 32-bit prefixes may work better.
------------------------------------------------------
------------------------------------------------------
dotnet40 does not yet fully work or install on wine.  Caveat emptor.
------------------------------------------------------
Current Wine does not have Wine bug 42701, so not applying workaround
Executing w_do_call remove_mono
------------------------------------------------------
You are using a 64-bit WINEPREFIX. Note that many verbs only install 32-bit versions of packages. If you encounter problems, please retest in a clean 32-bit WINEPREFIX before reporting a bug.
------------------------------------------------------
Executing load_remove_mono 
------------------------------------------------------
Mono does not appear to be installed.
------------------------------------------------------
Executing w_do_call winxp
------------------------------------------------------
You are using a 64-bit WINEPREFIX. Note that many verbs only install 32-bit versions of packages. If you encounter problems, please retest in a clean 32-bit WINEPREFIX before reporting a bug.
------------------------------------------------------
Executing load_winxp 
The operation completed successfully
Setting Windows version to winxp
Executing /nix/store/rq1ra5a2fki62dmw2yc3d3750q0avisw-wine-wow-5.0/bin/wine regedit C:\windows\Temp\set-winver.reg
Executing /nix/store/rq1ra5a2fki62dmw2yc3d3750q0avisw-wine-wow-5.0/bin/wine64 regedit C:\windows\Temp\set-winver.reg
------------------------------------------------------
Running /nix/store/rq1ra5a2fki62dmw2yc3d3750q0avisw-wine-wow-5.0/bin/wineserver -w. This will hang until all wine processes in prefix=/home/tanner/.steam/steam/steamapps/compatdata/261550/pfx terminate
------------------------------------------------------
Executing cd /home/tanner/.cache/winetricks/dotnet40
Unhandled exception: C++ exception(object = 0x0032f594, type = 0x1009be00) in 32-bit code (0x7b032c45).
Register dump:
 CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
 EIP:7b032c45 ESP:0032f494 EBP:0032f4f8 EFLAGS:00000212(   - --  I   -A- - )
 EAX:0032f4a0 EBX:e06d7363 ECX:0032f490 EDX:0032f4b4
 ESI:100187cc EDI:00000000
Stack dump:
0x0032f494:  0032f534 0000000c 7bc75a1c e06d7363
0x0032f4a4:  00000001 00000000 7b032c45 00000003
0x0032f4b4:  19930520 0032f594 1009be00 0032fe18
0x0032f4c4:  00641a00 0032f4e8 00860000 00641a58
0x0032f4d4:  0032f4e8 0032f500 00110000 00000000
0x0032f4e4:  00000000 0032f528 7bc769e5 0032f510
Backtrace:
=>0 0x7b032c45 RaiseException+0x50(code=<couldn't compute location>, flags=<couldn't compute location>, count=<couldn't compute location>, args=<couldn't compute location>) [Z:\build\wine-5.0\dlls\kernelbase\debug.c:319] in kernelbase (0x0032f4f8)
  1 0x100814f2 in setupengine (+0x814f1) (0x0032f540)
  2 0x10066a29 EntryPoint+0xffffffff() in setupengine (0x0032f5b0)
  3 0x100636d8 EntryPoint+0xffffffff() in setupengine (0x0032f5d0)
  4 0x10061338 EntryPoint+0xffffffff() in setupengine (0x0032f608)
  5 0x10035a14 EntryPoint+0xffffffff() in setupengine (0x0032f678)
  6 0x1006b498 EntryPoint+0xffffffff() in setupengine (0x0032fdd8)
  7 0x1005fa6e EntryPoint+0xffffffff() in setupengine (0x0032fe48)
  8 0x10058323 EntryPoint+0xffffffff() in setupengine (0x0032fe9c)
  9 0x00402928 EntryPoint+0xffffffff() in setup (0x0032ff30)
  10 0x7b454c52 call_process_entry+0x11() in kernel32 (0x0032ff48)
  11 0x7b455070 start_process+0xdf(entry=<couldn't compute location>, peb=<couldn't compute location>) [Z:\build\wine-5.0\dlls\kernel32\process.c:153] in kernel32 (0x0032ffd8)
  12 0x7b454c5e __wine_start_process+0x9() in kernel32 (0x0032ffec)
0x7b032c45 RaiseException+0x50 [Z:\build\wine-5.0\dlls\kernelbase\debug.c:319] in kernelbase: addl  $12,%esp
Unable to access file 'Z:\build\wine-5.0\dlls\kernelbase\debug.c'
Modules:
Module  Address         Debug info  Name (112 modules)
PE    400000-  415000   Export          setup
PE  10000000-100c8000   Export          setupengine
PE  6cd00000-6cd24000   Deferred        sqmapi
ELF 7b000000-7b0e0000   Dwarf           kernelbase<elf>
  \-PE  7b020000-7b0e0000   \               kernelbase
ELF 7b400000-7b510000   Dwarf           kernel32<elf>
  \-PE  7b420000-7b510000   \               kernel32
ELF 7bc00000-7beb6000   Deferred        ntdll<elf>
  \-PE  7bc30000-7beb6000   \               ntdll
ELF 7c000000-7c006000   Deferred        <wine-loader>
ELF 7ccd2000-7cceb000   Deferred        kerberos<elf>
  \-PE  7cce0000-7cceb000   \               kerberos
ELF 7cceb000-7cd2a000   Deferred        uxtheme<elf>
  \-PE  7cd00000-7cd2a000   \               uxtheme
ELF 7cd2a000-7cd33000   Deferred        libxfixes.so.3
ELF 7cd33000-7cd40000   Deferred        libxcursor.so.1
ELF 7ce40000-7ce55000   Deferred        libxi.so.6
ELF 7ce55000-7ce5a000   Deferred        libxcomposite.so.1
ELF 7ce5a000-7cedb000   Deferred        setupapi<elf>
  \-PE  7ce70000-7cedb000   \               setupapi
ELF 7cedb000-7cf0a000   Deferred        libxcb.so.1
ELF 7cf0a000-7d05d000   Deferred        libx11.so.6
ELF 7d05d000-7d100000   Deferred        winex11<elf>
  \-PE  7d080000-7d100000   \               winex11
ELF 7d124000-7d133000   Deferred        libxrandr.so.2
ELF 7d133000-7d141000   Deferred        libxrender.so.1
ELF 7d141000-7d149000   Deferred        libxxf86vm.so.1
ELF 7d149000-7d15f000   Deferred        libxext.so.6
ELF 7d15f000-7d17c000   Deferred        libz.so.1
ELF 7d17c000-7d1bc000   Deferred        libpng16.so.16
ELF 7d1bc000-7d1cf000   Deferred        libbz2.so.1
ELF 7d1cf000-7d295000   Deferred        libfreetype.so.6
ELF 7d2ca000-7d2e3000   Deferred        libresolv.so.2
ELF 7d2e3000-7d311000   Deferred        iphlpapi<elf>
  \-PE  7d2f0000-7d311000   \               iphlpapi
ELF 7d311000-7d356000   Deferred        netapi32<elf>
  \-PE  7d320000-7d356000   \               netapi32
ELF 7d356000-7d394000   Deferred        secur32<elf>
  \-PE  7d360000-7d394000   \               secur32
ELF 7d394000-7d3b4000   Deferred        jsproxy<elf>
  \-PE  7d3a0000-7d3b4000   \               jsproxy
ELF 7d3b4000-7d3f9000   Deferred        winhttp<elf>
  \-PE  7d3c0000-7d3f9000   \               winhttp
ELF 7d3f9000-7d40f000   Deferred        psapi<elf>
  \-PE  7d400000-7d40f000   \               psapi
ELF 7d40f000-7d429000   Deferred        userenv<elf>
  \-PE  7d420000-7d429000   \               userenv
ELF 7d429000-7d449000   Deferred        bcrypt<elf>
  \-PE  7d430000-7d449000   \               bcrypt
ELF 7d449000-7d4ff000   Deferred        crypt32<elf>
  \-PE  7d460000-7d4ff000   \               crypt32
ELF 7d4ff000-7d53a000   Deferred        wintrust<elf>
  \-PE  7d510000-7d53a000   \               wintrust
ELF 7d53a000-7d55d000   Deferred        odbccp32<elf>
  \-PE  7d540000-7d55d000   \               odbccp32
ELF 7d55d000-7d579000   Deferred        mspatcha<elf>
  \-PE  7d560000-7d579000   \               mspatcha
ELF 7d579000-7d595000   Deferred        imagehlp<elf>
  \-PE  7d580000-7d595000   \               imagehlp
ELF 7d595000-7d5b2000   Deferred        sxs<elf>
  \-PE  7d5a0000-7d5b2000   \               sxs
ELF 7d5b2000-7d5da000   Deferred        cabinet<elf>
  \-PE  7d5c0000-7d5da000   \               cabinet
ELF 7d5da000-7d602000   Deferred        imm32<elf>
  \-PE  7d5e0000-7d602000   \               imm32
ELF 7d602000-7d651000   Deferred        usp10<elf>
  \-PE  7d610000-7d651000   \               usp10
ELF 7d651000-7d7a7000   Deferred        comctl32<elf>
  \-PE  7d680000-7d7a7000   \               comctl32
ELF 7d7a7000-7d7e5000   Deferred        ws2_32<elf>
  \-PE  7d7c0000-7d7e5000   \               ws2_32
ELF 7d7e5000-7d80d000   Deferred        mpr<elf>
  \-PE  7d7f0000-7d80d000   \               mpr
ELF 7d80d000-7d88c000   Deferred        wininet<elf>
  \-PE  7d820000-7d88c000   \               wininet
ELF 7d88c000-7d933000   Deferred        urlmon<elf>
  \-PE  7d8b0000-7d933000   \               urlmon
ELF 7d933000-7da62000   Deferred        msi<elf>
  \-PE  7d960000-7da62000   \               msi
ELF 7da62000-7db99000   Deferred        oleaut32<elf>
  \-PE  7da90000-7db99000   \               oleaut32
ELF 7db99000-7dc34000   Deferred        rpcrt4<elf>
  \-PE  7dbc0000-7dc34000   \               rpcrt4
ELF 7dc34000-7dda0000   Deferred        ole32<elf>
  \-PE  7dc70000-7dda0000   \               ole32
ELF 7dda0000-7ddc8000   Deferred        shcore<elf>
  \-PE  7ddb0000-7ddc8000   \               shcore
ELF 7ddc8000-7de2d000   Deferred        shlwapi<elf>
  \-PE  7dde0000-7de2d000   \               shlwapi
ELF 7de2d000-7e7d6000   Deferred        shell32<elf>
  \-PE  7de60000-7e7d6000   \               shell32
ELF 7e7d6000-7e8b1000   Deferred        msvcrt<elf>
  \-PE  7e800000-7e8b1000   \               msvcrt
ELF 7e8b1000-7e8c8000   Deferred        version<elf>
  \-PE  7e8c0000-7e8c8000   \               version
ELF 7e8c8000-7ea14000   Deferred        gdi32<elf>
  \-PE  7e8f0000-7ea14000   \               gdi32
ELF 7ea14000-7ec46000   Deferred        user32<elf>
  \-PE  7ea50000-7ec46000   \               user32
ELF 7ec46000-7ecca000   Deferred        advapi32<elf>
  \-PE  7ec60000-7ecca000   \               advapi32
ELF 7eeff000-7f000000   Deferred        libm.so.6
ELF f7afe000-f7b6a000   Deferred        msxml3<elf>
  \-PE  f7b10000-f7b6a000   \               msxml3
ELF f7bb0000-f7bb8000   Deferred        libxdmcp.so.6
ELF f7bb8000-f7bbd000   Deferred        libxau.so.6
ELF f7bc1000-f7bc7000   Deferred        libdl.so.2
ELF f7bc7000-f7da7000   Deferred        libc.so.6
ELF f7da7000-f7dc9000   Deferred        libpthread.so.0
ELF f7dc9000-f7f7d000   Dwarf           libwine.so.1
ELF f7f81000-f7fab000   Deferred        ld-linux.so.2
ELF f7fae000-f7fb0000   Deferred        [vdso].so
Threads:
process  tid      prio (all id:s are in hex)
00000008 dotNetFx40_Full_x86_x64.exe
    00000028    0
    00000009    0
0000000e services.exe
    00000025    0
    0000001c    0
    00000015    0
    00000010    0
    0000000f    0
00000011 plugplay.exe
    00000019    0
    00000018    0
    00000012    0
00000013 explorer.exe
    00000022    0
    00000021    0
    0000001f    0
    00000014    0
0000001a winedevice.exe
    00000020    0
    0000001e    0
    0000001d    0
    0000001b    0
00000023 winedevice.exe
    00000027    0
    00000026    0
    00000024    0
0000002c (D) C:\9121dba59fb375d0b974\Setup.exe
    00000030    0
    0000002d    0 <==
System information:
    Wine build: wine-5.0
    Platform: i386 (WOW64)
    Version: Windows XP
    Host system: Linux
    Host version: 4.19.108
Using native override for following DLLs: mscoree
Executing /nix/store/rq1ra5a2fki62dmw2yc3d3750q0avisw-wine-wow-5.0/bin/wine regedit C:\windows\Temp\override-dll.reg
Executing /nix/store/rq1ra5a2fki62dmw2yc3d3750q0avisw-wine-wow-5.0/bin/wine64 regedit C:\windows\Temp\override-dll.reg
The operation completed successfully
The operation completed successfully
The operation completed successfully
Setting Windows version to default
Executing /nix/store/rq1ra5a2fki62dmw2yc3d3750q0avisw-wine-wow-5.0/bin/wine regedit C:\windows\Temp\set-winver.reg
Executing /nix/store/rq1ra5a2fki62dmw2yc3d3750q0avisw-wine-wow-5.0/bin/wine64 regedit C:\windows\Temp\set-winver.reg
------------------------------------------------------
Running /nix/store/rq1ra5a2fki62dmw2yc3d3750q0avisw-wine-wow-5.0/bin/wineserver -w. This will hang until all wine processes in prefix=/home/tanner/.steam/steam/steamapps/compatdata/261550/pfx terminate
------------------------------------------------------
------------------------------------------------------
dotnet40 install completed, but installed file /home/tanner/.steam/steam/steamapps/compatdata/261550/pfx/dosdevices/c:/windows/Microsoft.NET/Framework/v4.0.30319/ngen.exe not found
------------------------------------------------------

The error from the actual game launch apperas to be:

ERROR: ld.so: object '/home/tanner/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.

I'm still unable to log in to multiplayer on stable branch (e1.0.10).

@agates you didn't have problems launching the game after restart?
I'm reinstalling it to see if it fixes the settings. Last night it ran ok, but today it didn't launch
I have to run protontricks 261550 dotnetcore to get it installed after dotnet472?

@agates you didn't have problems launching the game after restart?
I'm reinstalling it to see if it fixes the settings. Last night it ran ok, but today it didn't launch
I have to run protontricks 261550 dotnetcore to get it installed after dotnet472?

Any problems I've had have been related to mods, so far.

dotnetcore isn't in winetricks, so have to install manually. @Aliervo showed how to do so in a comment above.

@YellowApple
We made the news! Thanks for the fix!

@Aliervo @agates I'm getting this output:

./proton run ~/dotnet-runtime-2.1.17-win-x64.exe
ProtonFixes[19625] INFO: Running protonfixes
ProtonFixes[19625] INFO: Running checks
ProtonFixes[19625] INFO: All checks successful
ProtonFixes[19625] INFO: No protonfix found for UNKNOWN (261550)

I'm missing something?

@Aliervo @agates I'm getting this output:

./proton run ~/dotnet-runtime-2.1.17-win-x64.exe
ProtonFixes[19625] INFO: Running protonfixes
ProtonFixes[19625] INFO: Running checks
ProtonFixes[19625] INFO: All checks successful
ProtonFixes[19625] INFO: No protonfix found for UNKNOWN (261550)

I'm missing something?

Is the file dotnet-runtime-2.1.17-win-x64.exe in your home directory?

I get that exact output when the specified location doesn't exist.

Mine is at ~/Downloads/dotnet-runtime-2.1.17-win-x64.exe, for example.

@agates yeah, everything in place, maybe it's because I have it installed already?

Tests

Plans

I tried testing out some of the suggestions we've seen so far. I will try some more combinations tomorrow, which might include using an fsync enabled kernel. I will also try to extend testing on some of the more promising solutions, such as changing graphics settings without crashing and general gameplay stability. I will update this post, but it can also be viewed in this gist.

The setup

My current way of testing is incredibly basic. I create a new prefix and run the game once to get steams basic setup done. Then I add the components I want to test. If the new test includes the previously tested components, I skip the creation of a new prefix (no new prefix when I changed from vcrun2019 to vcrun20190 + dotnet472). I then start the game, start a new campaign, run around in the training area, leave it, run around in the world-map and lastly save the game once. I will extend the testing for the most promising solutions.

System:    Host: tobias-X570 Kernel: 5.5.0-050500rc5-generic x86_64 bits: 64 Desktop: KDE Plasma 5.18.4
           Distro: KDE neon User Edition 5.18
Machine:   Device: desktop System: Gigabyte product: X570 AORUS MASTER v: -CF serial: N/A
           Mobo: Gigabyte model: X570 AORUS MASTER v: x.x serial: N/A
           UEFI: American Megatrends v: F11 date: 12/06/2019
CPU:       8 core AMD Ryzen 7 3800X (-MT-MCP-) speed/max: 1897/3900 MHz
Graphics:  Card: Advanced Micro Devices [AMD/ATI] Device 7340
           Display Server: x11 (X.Org 1.19.6 ) drivers: ati,amdgpu (unloaded: modesetting,fbdev,vesa,radeon)
           Resolution: [email protected]
           OpenGL: renderer: Radeon RX 5500 XT (NAVI14, DRM 3.36.0, 5.5.0-050500rc5-generic, LLVM 9.0.1)
           version: 4.6 Mesa 20.1.0-devel (git-089e1fb 2020-04-09 bionic-oibaf-ppa)

Be advised

While my testing may show some promising results, they don't show how stable the game is in the long run. All I did in my tests was opening the game and starting a new campaign, leaving the testing grounds and save the game.

The results (so far)

| Game Version | vcrun 2019 | dotnet 472 | dotnet 480 | .Net-Core 2.1.17 | .NET-Core 3.1.3 | FPS training ground | FPS world-map | Save time | Slow streaming* |
|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|
| 1.1.0 | 🔲 | 🔲 | 🔲 | 🔲 | 🔲 | 45-50 | 56-72 | 1:12 | no |
| 1.1.0 | ☑️ | 🔲 | 🔲 | 🔲 | 🔲 | 45-50 | 56-72 | 1:28 | no |
| 1.1.0 | ☑️ | ☑️ | 🔲 | 🔲 | 🔲 | 69-74 | 65-75 | 0:02 | no |
| 1.1.0 | 🔲 | ☑️ | 🔲 | 🔲 | 🔲 | 69-74 | 66-79 | 0:02 | no |

* this refers to the effect of a laggy game while all the objects are loaded when entering a new area

@matheo you should get an installer window even if it's already installed. Maybe double check your STEAM_COMPAT_DATA_PATH and compatibilitytools.d folder.

Has anyone gotten surround sound (e.g. 5.1) to work properly?

I ran into the following issue with the recommended Proton-5-5-GE version whenever I'm trying to launch a window in it (like the Bannerlord window or protontricks explorer):

000b:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded.
000b:err:winediag:nodrv_CreateWindow The explorer process failed to start.

Interestingly launching e.g. the dotnet core installer with wine-staging works fine so it seems to be specific to this Proton version. Any idea what could be the cause of this or how to solve it?

I swapped my (steam default) prefix for one with dotnet472 and dotnetcore2 and now I can login to multiplayer on stable branch. I dunno if vcrun2015 and vcrun2017 are installed; they're not listed when running protontricks 261550 list-installed.

It's strange though how I can login on 1.1 beta with a default pfx (although there are no servers available to actually play).

I ran into the following issue with the recommended Proton-5-5-GE version whenever I'm trying to launch a window in it (like the Bannerlord window or protontricks explorer):

000b:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded.
000b:err:winediag:nodrv_CreateWindow The explorer process failed to start.

Interestingly launching e.g. the dotnet core installer with wine-staging works fine so it seems to be specific to this Proton version. Any idea what could be the cause of this or how to solve it?

Have you tried to remove compatdata/261550/ folder aand install all the dependencies including dotnet472 and dotnetcore? That made it work on my system.

Have you tried to remove compatdata/261550/ folder aand install all the dependencies including dotnet472 and dotnetcore? That made it work on my system.

I've tried removing the folder and installing dotent472 again but it didn't seem to help. I was unable to install dotnetcore in this case since the installer doesn't seem to start due to the same error. I also tried the same thing with the 5.6-GE-1 release from 2 hours ago but ran into the same issues.

I dunno if vcrun2015 and vcrun2017 are installed; they're not listed when running protontricks 261550 list-installed.

I have not installed vcrun at all in my current setup.

Can confirm that I'm getting great performance, ~5-10sec save times, and very rare crashes with Proton-GE, the zen kernel (for fsync patches), and a normal proton prefix created and provisioned by steam.

For anyone else on a NixOS system load the following file in your configuration.nix to build and install the zen kernel: https://gist.github.com/hjones2199/11b45917a2944b692dac40015ea0fd41 You'll probably also need to disable your current boot.kernelPackages expression to avoid conflicts.

For anyone else on a new kernel (I'm running xanmod): I've also installed dotnetcore and so far it seems to be the best of both worlds - I haven't experienced a single crash yet and the performance is very good. Occasionally battles will lag very badly, but a restart seems to fix it, and campaign map stuttering is gone entirely.

Still crashing when changing video settings with dotnet472 installed (and a lot of other random crashes), unless I somehow installed it improperly? Is there a way to check? (I've used protontricks 261550 list-installed and dotnet 472 does appear).

Occasionally battles will lag very badly, but a restart seems to fix it, and campaign map stuttering is gone entirely.

The Windows side has similar performance issues and memory leaks etc, so sounds like it's working great :).

I ran into the following issue with the recommended Proton-5-5-GE version whenever I'm trying to launch a window in it (like the Bannerlord window or protontricks explorer):

000b:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded.
000b:err:winediag:nodrv_CreateWindow The explorer process failed to start.

Interestingly launching e.g. the dotnet core installer with wine-staging works fine so it seems to be specific to this Proton version.
I've tried removing the folder and installing dotent472 again but it didn't seem to help. I was unable to install dotnetcore in this case since the installer doesn't seem to start due to the same error. I also tried the same thing with the 5.6-GE-1 release from 2 hours ago but ran into the same issues.

I tried other "vanilla" Proton versions as well now (5.0-5 and even 4.2-9) and get exactly the same error in the logs so it doesn't seem to be specific to the GE builds.

Edit: After some more searching I found #2878 which indicates this is a NTFS specific issue - moving the game to my ext4 SSD solved the problem

Can confirm that I'm getting great performance, ~5-10sec save times, and very rare crashes with Proton-GE, the zen kernel (for fsync patches), and a normal proton prefix created and provisioned by steam.

For anyone else on a NixOS system load the following file in your configuration.nix to build and install the zen kernel: https://gist.github.com/hjones2199/11b45917a2944b692dac40015ea0fd41 You'll probably also need to disable your current boot.kernelPackages expression to avoid conflicts.

This issue is near-impossible to browse so I don't blame you for missing it but I already provided an easy solution to this by just adding a patch to ones current kernel and it's very straight forward: https://github.com/ValveSoftware/Proton/issues/3706#issuecomment-612160300

Basically, add the patch to your configuration.nix like so:
boot.kernelPatches = [{ name = "fsync-support"; patch = ./linux-v5.4-fsync.patch; }];
where linux-v5.4-fsync.patch is taken from here. It can take a while to compile though.

Right now if I try to enter a siege, the interface kinda of locks up and I can't anything, the game is running fine, but it seems that the mouse goes unresponsive; I can still move the mouse around, but it's flickering very fast. I also need to press Esc and Alt + Tab in and out of the game to make the escape menu to appear.

Edit, that with only fsync and no protontricks fixes. If I also use the protontricks fixes, the game comes crashing again like before.

Latest patch (1.0.11) broke the game for me (tested with a clean wine prefix) whenever I try to go to the screen with the savefiles I get this exception:

Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object

I can however start a new campain but I when selecting the "Save as" option I get the same exception.

Update:
@agates The beta branch works thank you

@elovin Have you tried the beta branch (e1.1.0)?

Looks like Bannerlord doesn't work with primusrun right now, but I've managed to get it running on a laptop with nvidia switchable graphics using nvidia-xrun.

Looks like Bannerlord doesn't work with primusrun right now, but I've managed to get it running on a laptop with nvidia switchable graphics using nvidia-xrun.

Well nothing really works that great through bumblebee and primus. I had to switch to xrun to get half of the games working.

Should work with PRIME Render Offloading too.

Okay, I guess this probably isn't strictly related to Bannerlord, but then again, just maybe the libraries Steam installs to the prefix or some other Bannerlord-specific factor change something (I wouldn't know), so I guess I might as well ask here: I am trying to run protontricks for dotnet472, but that results in a crash as "Extracting files" dialog opens and progress bar finishes. dotnet48 protontricks fails in similar manner. Console output

Any pointers?

hello, I am having a hard time getting bannerlord running on arch, i have tried proton 5.5-GE and 5.6-GE-2. so far I have got a window to open and display the cursor once before crashing!

• my steam library is on a HDD (ntfs), which is now mounted properly and symlinked (from that library) to point to my linux compatdata folder

• i've removed the compatdata folder and launched, then done protontricks 261550 dotnet472 - this is how i first got my game window pop up and cursor visable for a few seconds

here is the log from steam/proton: https://gist.github.com/hadallen/336ffcf1f8ae7e73024898306bb6ac01

and the crash report from windows/wine when it starts and crashes. I can't get the cursor and window to show up again, the crash comes up first. afterwards bannerlord is apparently still 'running' in steam, I can't stop it. https://gist.github.com/hadallen/d7b00c97e492195f360b8589c5d67685

I'm worried it's just a dumb error on my part somewhere, but don't know what to do here

edit1: i finally went through this thread far enough to find the guide that Tercus wrote up. I just went through that again and still have the same issue

edit2: I was almost ready to give up, i reinstalled bannerlord in steam

1. protontricks 261550 dotnet48 to start. I really didn't want to wait the 30 minutes for dotnet472 to install, so I tried this alone and it worked --Ran in steam; crashed
2. installed vcrun2019 and the 2 dotnetcore (as per Tercus' write up) --Ran again; STARTED! but very slow and no mouseinput, crashing after leaving settings.. sounded like it wasn't using the updated proton
3. That was weird, as bannerlord had proton 5.6-GE-1 selected. this gave me the idea to disable "Enable Steam Play for all other titles" in steam settings, and _voila_; it is working very nicely!

Since dotnetcore still seems to be helpful, I'll mention here that my PR was accepted and it is now in winetricks!

Run winetricks --self-update (as root if you installed with your package manager) to get the latest version, then you can use winetricks dotnetcore2!

Pro tip: On any winetricks install, add -q to put it into unattended mode and not have to click "Install" on a bunch of windows. So the above would be winetricks -q dotnetcore2

@Aliervo I get a wine error:
https://docs.microsoft.com/en-us/dotnet/framework/install/application-not-started?version=(null)&processName=rundll32.exe&platform=0009&osver=3&isServer=0&shimver=4.0.30319.0
and then this one:

is it normal for 64 bits installations?

@matheo, not sure about the error, but winetricks will install both the 32 and 64 bit versions of .Net Core. That much is expected.

It also checks that it installed corrected, so if you don't see an error message after the two installers, we'll know that the first error didn't affect anything.

I have very slow save times (1 min +) with dotnet472 with or without vcrun2019. Does anyone know if the fsync kernel patch is essential for reduce save times/other good ideas to improve save times?

@rgreenblatt
Fsync does notably speed up savetimes for almost everyone as far as I know, so it may be worth a try if you are comfortable with running custom kernels and/or compiling you own.

Another thing to do is to bypass the launcher if you are not already. As in starting Bannerlord.Native.exe instead of TaleWorlds.MountAndBlade.Launcher.exe. It can be done by renaming them or symlinking them or setting which to launch in the Steam launch options.

For unknown reasons the launcher being used roughly doubles my savetimes when I use fsync and no other protontricks tweaks. I don't know if it applies in any other scenario, but it could be worth a shot either way.

My best experience have been with fsync, that rename and no protontricks at all. Relatively few crashes and about 7-8 second savetimes. Dotnet would shorten the savetimes to around 2 seconds but introduce a lot more crashes.

@rgreenblatt from what I've seen in the rest of this thread, dotnet was the fix for long save times, at the expense of some instability. As albin-engstrom said, fsync had much worse save time performance. All that being said, I've found the game all but unplayable without an fsync enabled kernel, and can't recommend it enough.

To everyone else, has multiplayer been working for anyone else? I have not been able to sign in for nearly a week. I get to the login page, and I get the spinning circle of doom for a few minutes before it tells me it can't log in. This on Beta and Stable branches.

Is there any difference between Bannerlord.exe and Bannerlord.Native.exe? (apologies if this is somewhere in the thread above, I couldn't find a way to search over github comments)

I was able to reduce save times to less than 10 seconds (from over a minute) by installing https://liquorix.net/ (which I think has fsync patches) and by using Bannerlord.Native.exe instead of Bannerlord.exe. I am not sure which change was helpful. I might do more scientific testing later.

@rgreenblatt Liquorix has fsync as far as I'm aware, so it's likely that had the most impact and running Bannerlord.Native.exe helped a little bit more. At least that has been my experience.

As to it's difference from Bannerlord.exe I don't really know. Running the native one is the official way to bypass the launcher, so I've been using that. My guess would be that it's tweaked to be run alone whereas the non-native one is intended/only works when being run by the launcher.

There's a bunch of arguments the launcher appends when running the exe, so perhaps it does not work properly without them.

Related to that, among those arguments are the mods to load, which the launcher normally handles, so when bypassing the launcher any mods would have to be manually added as arguments through the Steam launch options.

I've explained how that is done somewhere in the comments above, but there is indeed no good way to search github comments, so if you want to know how to do it I can explain it again. It'll take much less time than looking for an old comment would.

To everyone else, has multiplayer been working for anyone else? I have not been able to sign in for nearly a week. I get to the login page, and I get the spinning circle of doom for a few minutes before it tells me it can't log in. This on Beta and Stable branches.

I'm able to play on stable branch but I was unable to for about one patch before 1.1. I got it to work again by installing dotnet472 and/or dotnetcore2 (I don't know which made the difference).

For me, dotnet solution caused crashes every 5-10 mins of gameplay, worse than the 2min save times.
I'm going to try it with liquorix, but I have some questions re above comments about skipping launcher. without dotnet, the launcher does not come up at all, game just exits immediately. How do I configure it in launch options to go to native?

I tried setting it to "Bannerlord.Native.exe" or "bin/Win64_Shipping_Client/Bannerlord.Native.exe" but I may be going in the wrong direction here

@aradapilot Someone somewhere in this thread has said how to do it through the launch options, but I don't do it so I don't know exactly how it's done.
I personally rename Bannerlord.Native.exe to TaleWorlds.MountAndBlade.Launcher.exe and remove or rename the original launcher exe. It has to be redone after most game updates, symlinking should also work and might not have to be redone.

I do the mod loading commands in the launch options, but not this part.

well, can't find it, but some progress.
I set launch options to just
echo "%command%" > /tmp/cm

then after that, the file had
wraymond@shelob:~$ cat /tmp/cm
'/home/wraymond/.steam/compatibilitytools.d/Proton-5.6-GE-1'/proton waitforexitandrun '/home/wraymond/.steam/steam/steamapps/common/Mount & Blade II Bannerlord/bin/Win64_Shipping_Client/TaleWorlds.MountAndBlade.Launcher.exe'

from CLI
wraymond@shelob:~$ PROTON_LOG=1 '/home/wraymond/.steam/compatibilitytools.d/Proton-5.6-GE-1'/proton waitforexitandrun '/home/wraymond/.steam/steam/steamapps/common/Mount & Blade II Bannerlord/bin/Win64_Shipping_Client/Bannerlord.Native.exe'
Proton: No compat data path?

so I figured it had some env set, however env/set/printenv > /tmp/steamenv - leaves empty file, it has no env set. no idea where it's getting compatdata dir from, what mechanism steam uses.

and of course, because life is hard, setting that string in launch options does nothing
PROTON_LOG=1 '/home/wraymond/.steam/compatibilitytools.d/Proton-5.6-GE-1'/proton waitforexitandrun '/home/wraymond/.steam/steam/steamapps/common/Mount & Blade II Bannerlord/bin/Win64_Shipping_Client/Bannerlord.Native.exe'
-- no log file created
-- nothing launches, dies immediately

so still stuck there. i'll try some renaming/symlinking, but I was hoping for a way that i wouldn't need to redo every patch

hah I renamed the launcher exe, and copied the native exe to that path. the game launched, but now again no mouse input (with proton-GE 5.5 or 5.6).
I'm gonna try the managedstarter rename since that has worked in the past, but that goes through the launcher, so it might screw my save times...ahhhhhhh
update that doesn't help either. no mouse input, I can't get past the calibration screen. I'm at a loss.

As per: https://github.com/ValveSoftware/Proton/issues/3706#issuecomment-612178492
echo %command% && exec /home/USERNAME/.steam/compatibilitytools.d/Proton-5.6-GE-2/proton waitforexitandrun "/PATH/TO/steam/steamapps/common/Mount & Blade II Bannerlord/bin/Win64_Shipping_Client/Bannerlord.exe"