As I wrote in the first post, it's the larger world/map sizes that run out of memory. The smaller ones are fine.

It would only take a few lines of code to disable the large maps on 32 bit, but doing more memory optimization could take weeks.

But I agree that it is critical to prevent the out of memory crashes from ever happening.

It looks like Steamworks.Net has separate x86 and x86_64 versions (which load steam_api.dll or steam_api64.dll respectively). You'll need to figure out a way to make your EXE load the matching CPU architecture version of the Steamworks.NET dll, which in turn will load the correct steam_api*.dll.

Yes. Or I can modify the source code for Steamworks.NET to load the correct version in turn. Sadly it does not do this currently.

https://trello.com/c/Bii4RbuB/17-non-unity-portability-issues

"This is just a brain dump about the various issues of portability that Steamworks .NET currently faces.

These issues only affect Standalone, non Unity builds.

There are two major portability aspects to look at.

The first issue is x86/x64/Any CPU Portability

Steamworks .NET has some pretty large issues with Any CPU due to it's reliance on CSteamworks.dll which can not be Any CPU (C++ based).

Steamworks .NET uses DllImport (p/Invoke) to access the functions exposed by CSteamworks.

[DllImport("CSteamworks")]
internal static extern bool SteamAPI_Init();

"CSteamworks" requires a constant string. Currently both 32 bit and 64 bit versions of CSteamworks are both named CSteamworks. Resolving it would almost certianly require renaming the 64 bit version to CSteamworks64.dll."