Oh that makes sense, I haven't started the scenario as I'm always checking first with Locoswap.
So it's a Locoswap bug. (Still using umlauts is not good. Buem is as good as Büm
I have found another slight issue with LocoSwap, valid xml being shown as corrupt but validated with any xml checker. And it puts a space before self-closing tags, so
in ScenarioProperties.xml.
Sadly the function for reporting issues on GitHub is not present for flicard/LocoSwap repo.
Edit: Can't blame LocoSwap. All RW Blueprints are declared to be UTF-8.
I've made a byte comparison, left is how the "ü" is encoded in the original scenario, right is after Locoswap, HxD showing it correctly as an UTF-8 "ü", in the original bin it's become an undefined character. Which means the filename itself is already encoded differently on the author's PC by its Operating System, and this is simply taken over by the Scenario Editor.
I've had a discussion a while ago, someone had issues with french assets not showing up. Turned out he had transferred the loose files over from a PC with a different codepage set.
So per se TS has no issues, it's been designed to work with UTF-8 encoding. It's the OS that's changing filename encoding, and TS just uses this as if it were UTF-8 being given.
Sorry for this, @EnergeticWeeb it's not your fault. It's basically a missing unique filesystem character encoding.
There's some czech assets that were showing missing textures until I renamed the references in the Geos and changed the texture names. You can't do nothing else but make asset creators aware of this issue and urge them to keep filenames Unix-like because the first 7 bits are the same across all codepages. Safe
