A guide on how to play Train Simulator 2019 on Linux.

[Goliathfan]

It seems from Proton 4.2-7 the game might just work for you without workarounds. So try the game first, if that doesn't work check the guide.

Also the rendering issues are seemingly resolved from Proton 4.11-2.

The guide can be found at:

https://steamcommunity.com/sharedfiles/filedetails/?id=1537164153

[Oktoras]

Thanks

[Goliathfan]

I'm glad you like the guide Oktoras, and thank you for saying thanks. It's appreciated.

[Nexus]

"396.51 or newer" - works fine with default 390.48 shipped with Ubuntu 18.04 (no need to install unofficial packages from unofficial sites : )

[Goliathfan]

Well I'm going by the Valve recommendations in the Proton quickstart Github. I'll update the guide though. Thanks for the report.

[Nexus]

"The Steam Play installer doesn’t unpack .ap files." - installer works fine and install everything - the problem is the Proton Engine (probably some non standard library is missing - I still hope I will work without this workaround in the future)

And you could include description how to run scenarios from workshop :

#!/bin/sh
cd
cd .local/share/Steam/steamapps/common/RailWorks/
find ../../workshop/content/24010 -name "*_legacy.bin" -exec unzip '{}' ';'

(the code unpacks all workshop items and install them in place into railworks game directory as a standard/career scenario - didn't test workshop routes yet)

sorry for poor coding : ) but it works : )

[Nexus]

And one thing - your scripts works only if they are run from home directory (they will fail from any other directory) - sorry again for my poor coding but "cd" command is needed before : )

[Goliathfan]

Ah I see, you're right, you do need to be in the home directory first before doing the find commands. I'll fix the instructions in the guide then.

[Nexus]

unzip '{}' ';'

could be changed to:

unzip -u '{}' ';'

to avoid confirmations (I prefer to confirm overwrites by hand)

[Goliathfan]

The man page for the unzip command says that the timezone needs to be correctly set, for the -f and -u options to work properly. I'm not quite sure what the implications of this are. Is this something we need to consider?

I'm not sure if timezone settings could be a problem with the .ap files or the workshop files? There are after all people from all over the world using the workshop to upload stuff, and those files might have different timezones?

For reference, here are the relevant sections of the unzip command man page:

       -f     freshen  existing  files,  i.e.,  extract  only those files that
              already exist on disk and that are newer than the  disk  copies.
              By  default  unzip queries before overwriting, but the -o option
              may be used to suppress the queries.  Note that under many oper‐
              ating  systems,  the  TZ (timezone) environment variable must be
              set correctly in order for -f and -u  to  work  properly  (under
              Unix  the  variable  is usually set automatically).  The reasons
              for this are somewhat subtle but have to do with the differences
              between  DOS-format file times (always local time) and Unix-for‐
              mat times (always in GMT/UTC) and the necessity to  compare  the
              two.   A  typical  TZ value is ``PST8PDT'' (US Pacific time with
              automatic adjustment  for  Daylight  Savings  Time  or  ``summer
              time'').

and

       -u     update  existing  files  and  create  new  ones if needed.  This
              option performs the same function as the -f  option,  extracting
              (with  query) files that are newer than those with the same name
              on disk, and in addition it extracts those  files  that  do  not
              already  exist on disk.  See -f above for information on setting
              the timezone properly.

[Nexus]

This (-u option) works without any problems - I've just liked to confirm any overwrites on disks by hand

But it's better to overwrite (not update) files - and moving files between windows and linux was always a little tricky

for example a few workshop scenarios have creation date in 1979 (so they will not update anything newer than 1979)


for compatibility best options is to NOT use -u

but when you have hundreds of DLCs and Workskop items confirm everything could be annoying.. and "-u" option is convenient (when you know about its limitations)


I still think that this is only temporary solution - fixing this in Proton engine should be easy : ) this is just one function missing (or poorly implemented) - we should test if this is needed after each new version of Proton and update this guide when this bug will be fixed

[Goliathfan]

If you don't want to confirm overwriting things, you could use unzip with the -o option. This doesn't require the timezone to be correct. You just clobber/overwrite all previous files when extracting the never updated files.

       -o    overwrite existing files without prompting.  This is a dangerous
              option,  so  use  it with care.  (It is often used with -f, how‐
              ever, and is the only  way  to  overwrite  directory  EAs  under
              OS/2.)

Maybe the best way is to mention those -o and -u options in the guide, with a good explanation on what those options do, so the user can decide for themselves what’s best for their use-case.

I'm still a bit foggy on the -u option though, so I'm unsure what the correct explanation would be there.

I agree with you though, this is getting complicated; you need to find and unzip .ap files, then find and unzip workshop files. And then when things update, you need to do the whole lot of operations yet again.

It would be much better if Proton figures all of this out itself, or if Proton uses the correct libraries to process these files within the game.

Testing if this whole shebang is still needed after updates would be a good thing to do.

[Nexus]

One more thing - At least until that unpack bug will be fixed we could save a lot of space by deduplicate files (or use filesystem with deduplication and/or compression like ZFS)

on my limited set of DLSs (mosty US mountain routes: Canadian Mountain Passes, Stevens Pass, Marias Pass, Feather Canyon, Donner Pass, Cajon Pass, Sherman Hill, Soldiers Summit plus a lot of related locomitives):

RailWorks$ fdupes -Srm .
9861 duplicate files (in 3538 sets), occupying 3825.7 megabytes

total: 136063 files / 26G space

So 15% saved : )

deduplication stats divided into routes and assets:

RailWorks/Content/Routes$ fdupes -Srm .
886 duplicate files (in 531 sets), occupying 4.9 megabytes

total: 60908 files / 3,8G space

RailWorks/Assets$ fdupes -Srm .
8935 duplicate files (in 2979 sets), occupying 3801.9 megabytes

total: 73224 files / 21G space

I will dig deeper in this and post a working deduplication script later

[Goliathfan]

Hmm, seems that deduplication would be saving some space then.

However, are we sure that those duplicates can be safely removed?
Does the game really only use one copy of each file?

[Nexus]

No No No, I used fdupes only to find duplicates, not to replace them with hardlinks : ) (fdupes cannot do that)

deleting files will break the game for sure - but replace duplicates with hardlinks should be safe (and save a lot of space)

[Goliathfan]

There are some utilities, that can do the whole softlink to hardlink conversion.

But this is definitely in the realm of advanced user stuff, so we might put your script in the guide, but mention its for advanced users only, and to be very careful not to delete other files.

Take the flist utitily (has a GUI interface) for example:
when using the find function recursiviely on ~/.steam/steam/steamapps/common/RailWorks it went out of the “confinement” and into other directories… So it listed files which were above the folder Railworks in the file-tree. So it's easy to accidentaly convert more than what you wanted.