[James Ross]

pschlik, on 05 August 2026 - 11:12 PM, said:

Now, you'll note these offending ones are all greyed out. This is MSTSSteamLocomotive.cs, which for some reason contains an immense number of references to other namespaces that aren't even used. Not sure what went down here, but it seems this is related to PR #1214. SteamEngine.cs also has a reference to System.Runtime.Remoting.Lifetime, among many other unneeded references. Previous builds with that PR worked fine, but with .NET 6 it appears that some of this is obsolete now. That PR will need to be tidied up...

Looks like that PR has been tidied up now. I have also fixed a weird build problem (apparently "testhost.exe" cannot be signed?) so we have a new Unstable Version U2026.08.08-0338 that is running on .NET 6.

[pschlik]

Updating now, and the new builds are BIG. The zip for the build from a few days ago is around 40 megs, today's build is over 120 megs. All of this seems to be coming from the "runtimes" folder that is now included, which is 235 megs uncompressed! The runtimes seem to be for a lot of operating systems we don't necessarily need since the regular builds are meant for windows, but a lot of that file size is still coming from the various windows runtimes.

[James Ross]

pschlik, on 08 August 2026 - 01:38 PM, said:

Updating now, and the new builds are BIG. The zip for the build from a few days ago is around 40 megs, today's build is over 120 megs. All of this seems to be coming from the "runtimes" folder that is now included, which is 235 megs uncompressed! The runtimes seem to be for a lot of operating systems we don't necessarily need since the regular builds are meant for windows, but a lot of that file size is still coming from the various windows runtimes.

Good spot, it looks like we've got multiple copies of ffmpeg/ffprobe in there among other things. I will see if I can work out why and nuke them.

[James Ross]

Okay, I have it fixed locally.

Turns out, when we upgraded to MonoGame 3.8.0, which meant pre-compiling the shaders, we forgot to remove the code for loading them at runtime and thus still needed the "content pipeline" dependency (go to "Source/RunActivity/Viewer3D/Shaders.cs" and expand the diff view downwards to see it), which is what pulls in nearly every file you can see in "runtimes".

I have made the following fixes:

• Remove unused MonoGame Content Pipeline dependency
  
• Fix build to only contain Windows 64bit dependencies
  
• Remove testhost files which cannot be signed (I think this was preventing the updater from working)
  
• Switch to dotnet tool for build and test

Together, this brings the ZIP file down to just 30 MB (smaller than the pre-.NET 6 one which was 42 MB).

[cesarbl]

In the .NET 6 version, scripts fail to load because the .zip includes version 1.3.0 of Microsoft.CodeAnalysis.dll, while Orts.Simulation requires version 4.4.0.

Otherwise, this version works great also for Linux using Wine.

[engmod]

Which version of wine?

[cesarbl]

I'm using wine 11.15, but I believe the issue is not linux-related.

[James Ross]

cesarbl, on 11 August 2026 - 01:47 AM, said:

In the .NET 6 version, scripts fail to load because the .zip includes version 1.3.0 of Microsoft.CodeAnalysis.dll, while Orts.Simulation requires version 4.4.0.

Fixed in U2026.08.12-2023, that was a fun one!

Turns out that we do depend on Microsoft.CodeAnalysis 1.3.0 via Microsoft.NETCore.App 1.0.5 via SharpDX 4.0.1 via MonoGame 3.8.1. But we also explicitly depend on Microsoft.CodeAnalysis 4.4 in Orts.Simulation. Thus, different projects depend on different versions depending on whether they include MonoGame, Orts.Simulation, or neither.

So, when the build script runs `dotnet build` and builds everything, it ends up with 4.4, and when it runs `dotnet test` and builds only Tests, is ends up with 1.3.

The fix that I have applied is to stop `dotnet test` from doing a restore or build, so it uses what the build already has, i.e. 4.4.

[gpz]

This must have been an exhausting debug session 🙂

[James Ross]

#1242 - Upgrade to .NET 6 is now merged, so the Testing Version tomorrow should be running on .NET 6. If you do not already have the correct version installed, it should offer to open the download page for you.

[cesarbl]

Apparently there is another problem with scripts after the migration. The script manager fails to load the basic referenced assemblies. This is because

typeof(System.Object).Assembly.Location points to System.Private.CoreLib.dll instead of System.Runtime.dll

Including all DLLs in TRUSTED_PLATFORM_ASSEMBLIES works, but it includes some assemblies that we wouldn't like to include (e.g. Orts.Formats.MSTS). I'll investigate if there is a clean solution that does not involve hard-coding all the required system assemblies.

[goku]

James Ross, on 19 July 2026 - 07:57 AM, said:

Filename case sensitivity is definitely an area of concern for portability. We are happy to accept fixes that preserve filename case inside Open Rails but would need to also maintain case-insensitivity for many internal systems e.g. loading deduplication of textures/models.

New TSRE has tool to fix game root dir content filenames mismatch.
Old method of making all lowercase is removed.
So, this makes using MSTS/ORTS content on Unix systems much easier.

One thing left: some files are referenced directly by code, so TSRE assumes those:
- Dir names are upper case
- Filenames are lowecase
Example:

QString path = Game::root + "/GLOBAL/tsection.dat"

So, all what could be required for ORTS compatibility is to follow this in code.
But I see ORTS does

@"\GLOBAL\TSECTION.DAT"

But if there is well defined naming scheme for fixed paths, I could modify TSRE to match it. This tool is still on design stage.

----

Regarding vs code, open rails code builds nicely in plain c# plugin, the issue is with post build resource script that want to use visual studio build tools. I don't want to install them, so I have small vs code script than builds them itself.

[goku]

Ok, so I made review for those case sensitive filenames, and it turns out that open rails is not consistent at all in it.

So, I propose this easy solution I have choosen for TSRE:
In code directories - always upper case, like: ROUTES, SHAPES etc.
In code file names - always small, like: forests.dat, tsection.dat
Referenced files keep their letter case.
If something needs to be added in code, like Shape.S -> sd, we follow extension letter case, so here it is Shape.SD

Even for Windows there is upside - code is consistent and clean.

This is easy for content creators to follow.
TSRE content sync script fixes all wrong in content file references and/or renames affected files.

Full ORTS report including TSRE proposed solution at the top:
https://github.com/G...paths-review.md

[James Ross]

goku, on 30 September 2026 - 11:56 AM, said:

So, I propose this easy solution I have choosen for TSRE:
In code directories - always upper case, like: ROUTES, SHAPES etc.
In code file names - always small, like: forests.dat, tsection.dat
Referenced files keep their letter case.
If something needs to be added in code, like Shape.S -> sd, we follow extension letter case, so here it is Shape.SD

ORMT have agreed that this is a sensible approach which has no impact on Windows but massively helps cross-platform directory/file case issues.

I'll summarise what we've agreed but it should match the report linked above:

• Fixed-in-code directory names = UPPERCASE
  
• Fixed-in-code filenames = lowercase
  
• Fixed-in-code file extensions (only base name referenced/file enumeration) = lowercase extension
  
• Filenames with replaced extensions (see example in quote above) = preserved filename case, matched extension case
  
• Everything not covered above referenced from other files = preserved case

Thanks for taking the time to think about and propose this solution, it's pretty neat IMHO.

One additional idea we had was that Open Rails could include a contributed tool that applies this case convention onto any selected content folder. At least for the fixed-in-code cases, this seems very straightforward, and I expect it could be made to work with the rest of the proposal too.

[goku]

James Ross, on 09 October 2026 - 04:47 PM, said:

ORMT have agreed that this is a sensible approach which has no impact on Windows but massively helps cross-platform directory/file case issues.
[...]
Thanks for taking the time to think about and propose this solution, it's pretty neat IMHO.

Yes, it is neat and already tested in practice. Works very well both in TSRE and ORTS. I was able to build ORTS as native linux application and run content with no issues.

Some small things had to be reimplemented, because Linux doesn't support Monogame 6, so we went with 10. Some Windows only NET libs had to be replaced with opensource alternatives (Like WinForms), but for agents that is minutes. I will share reports later when reorganized as a knowledge resource what worked well / what didn't.
It is still not perfect experience as Monogame built in OpenGL support has poor performance. On windows -15% when compared with default build. Sometimes even -20.
But it is worth looking at the other time as opens doors for native Android/Mobile experience.

James Ross, on 09 October 2026 - 04:47 PM, said:

One additional idea we had was that Open Rails could include a contributed tool that applies this case convention onto any selected content folder. At least for the fixed-in-code cases, this seems very straightforward, and I expect it could be made to work with the rest of the proposal too.

Of course you could include TSRE based tool. But it won't be minimal because the tool requires large part of TSRE for rewriting files when conflicting references occur and filename change fails to solve issue.