The International Simutrans Forum

 

Author Topic: A Newbie's Guide to Compiling Simutrans-Extended in Ubuntu / Debian / Linux  (Read 1601 times)

0 Members and 1 Guest are viewing this topic.

Offline Matthew

  • *
  • Posts: 335
    • Japan Railway Journal
  • Languages: EN, some ZH, DE & SQ
This is a newbie's guide because I have only done this once myself. It is adapted from Spacethingy's very helpful guide for compiling Simutrans Standard on Linux, which is what I used. Keep that handy and this will add a couple more steps.

I was using Ubuntu Desktop 18.04 LTS. I guess the procedure will mostly be the same for other *buntu and Debian distributions. I am assuming that you are not logged in as root, that you have sudoer rights, and that you have a working Internet connection. Alternative ways to complete a step are displayed as quotations.

1. Install Simutrans-Extended
You will need a fully-functioning installation of Simutrans-Extended for Linux in a place we will call your game directory. There is an installation guide in the Extended discussion forum. The .deb package is highly experimental, so you may be better off just downloading the Windows version since it contains the Linux executable (simutrans-extended, without any extension) anyway.

2. Back up your existing executable
It's a good idea to make a copy of your existing simutrans-extended file, in case your own version doesn't work.

3. Add the source repository
Open the Software & Updates application (you can search for it in the Activities menu or the Ubuntu Software Center) and select the 'Source code' button:



You will need to enter your sudo password. You should be told that "The information about available software is out-of-date": click 'Reload'. If you don't see that message, then it's a probably a good idea to open a terminal (Ctrl+Alt+T) and run:

Code: [Select]
sudo apt update
4. Get the dependencies

These are libraries that Simutrans-Extended relies on for specialist functions like graphics and compressing saves.

In Ubuntu or Debian, open a terminal and run the following:

Code: [Select]
sudo apt-get build-dep openttd
sudo apt install libbz2-dev
sudo apt install libsdl2-dev

Quote
If you are using Fedora or CentOS, you might find the following works instead:

Code: [Select]
sudo yum-builddep openttd
sudo yum install bzip2-devel
sudo yum install SDL2-devel

If you are using openSUSE, you can use the following method (kindly provided by Freahk):

Open a terminal window e.g. by pressing F4 in Dolphin, launching Konsole or pressing Ctrl+Alt+F1 and elevate to root:
Code: [Select]
su
Now refresh the repository cache and install the dependencies:

Code: [Select]
zypper ref
zypper in zlib-devel libbz2-devel libpng16-devel libSDL2-devel

Leave the root session:

Code: [Select]
exit

5. Get the Extended source code

Make a new directory, which we'll call your working directory (Spacethingy's "trunk"). The best option is download it through Git, so that you can easily keep up to date with any changes (and Simutrans-Extended changes every few days).

If you're using Git, your working directory should be on a Linux filesystem (for example, your Home directory) even on a dual-boot system, because there can be issues using Git in an NTFS directory. You must open a terminal in your working directory. In Nautilus (the Ubuntu file manager), you can do this by right-clicking in the working directory. If the right-click menu does not have this option, switch to 'icon view' so that you can see this icon:



and right-click again in a blank area.

Quote
In openSUSE, Kubuntu, and other KDE distributions, open the working directory in Dolphin and then open a terminal pane (F4 on the keyboard).

Then run:

Code: [Select]
sudo apt install git
git clone https://github.com/jamespetts/simutrans-extended.git

When Git has finished you will see the command prompt again.

Quote
If you don't want to use Git, you can just download the ZIP file from James' Github repository. Click on the green "Clone or download" button on the right to see the ZIP link:



Then extract the ZIP file into your working directory.

6. Set up your configuration file

There should be a config.template in your working directory. Make a copy of it under the name config.default and open it. This will contain the configuration settings for the compiler. To activate a setting, delete the # at the start of the relevant line. For Extended, we need:

Code: [Select]
BACKEND = sdl2
COLOUR_DEPTH = 16
OSTYPE = linux
OPTIMISE = 1

7. Compile

Open (or switch back to) a terminal in your working directory. Then run

Code: [Select]
make
Your terminal will fill with gibberish for a while. On my ancient laptop, Extended took about ten minutes to compile (which is really amazingly fast - I remember when games took hours to compile!).

It may be slightly faster to compile using multiple cores, if your CPU has them, using the -j option. For example, if you want to compile on two cores, you can run

Code: [Select]
make -j2
8. Play Simutrans

Your working directory should have a new subdirectory called build and a default subdirectory of that. It will look a lot like your working directory - that is not a mistake! But it will contain a freshly-minted simutrans-extended executable. Copy this to your game directory. You may not be able to run it from the desktop, but if you open a terminal in the game directory and run

Code: [Select]
./simutrans-extended
...you will hopefully see your homebrewed version of Simutrans-Extended start up!

This post is public domain, so please copy anything you find useful.

Once you have started compiling code, you may need to profile it. You can learn to do that in this post below.
« Last Edit: February 10, 2020, 01:39:35 AM by Matthew »

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19824
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Excellent - a very helpful guide! Thank you for this.

One small change that I would suggest is setting the "OPTIMISE" to 2 or 3 rather than 1, which will give better performance.

Offline Freahk

  • Devotee
  • *
  • Posts: 1073
  • Languages: DE, EN
I just came here to note that this will also apply to standard apart from one additional dependency they recently introduced.

Also, I want to add compile instructions for opensuse, feel free to add these to your post.
It should be as simple as the following:

1. Follow the first 2 steps from the Ubuntu guide.

2. Ge the dependencies
open a terminal window e.g. by pressing F4 in Dolphin, launching Konsole or pressing strg+alt+F1 and elevate to root
Code: [Select]
su
Now let's refresh the repository cache and install the dependencies:
Code: [Select]
zypper ref
zypper in zlib-devel libbz2-devel libpng16-devel libSDL2-devel

Leave the root session
Code: [Select]
exit
3. Follow the Ubuntu instructions from step 5 to step 8
Note that you most likely won't have nautilus installed, so the easyest way should be using the terminal within Dolphin again.




James, are you sure there is any difference in optimise 1, 2, 3 or even "DONT"?

I guess you confuse simutrans OPTIMISE with gccs -On flag, which is set to -O3 no matter the exact value of OPTIMISE as long as it gets set to a non-empty value.

See the makefile code:
Code: [Select]
ifneq ($(OPTIMISE),)
  CFLAGS += -O3
  ifeq ($(findstring $(OSTYPE), amiga),)
ifneq ($(findstring $(CXX), clang),)
CFLAGS += -minline-all-stringops
endif
  endif
else

Offline Matthew

  • *
  • Posts: 335
    • Japan Railway Journal
  • Languages: EN, some ZH, DE & SQ
Also, I want to add compile instructions for opensuse, feel free to add these to your post.

Thank you! I have added your instructions to the OP.

Quote
James, are you sure there is any difference in optimise 1, 2, 3 or even "DONT"?

I will let you experts work this one out before I change anything. ;) I seem to have a workable build with both 1 and commented out, anyway.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19824
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
This seems to duplicate the stickied version of this post - is this intended?

And, yes, I had confised the "OPTIMISE" flag with the "-O3" flag - my apologies.

Offline Matthew

  • *
  • Posts: 335
    • Japan Railway Journal
  • Languages: EN, some ZH, DE & SQ
This seems to duplicate the stickied version of this post - is this intended?

I made a typo in the thread title, so I immediately tried to delete it and repost with the correction. Somehow there are now two versions with the correct title. ??? Apologies. Please use your mod powers to delete the other thread, as I've now edited this one with Git instructions and Freahk's openSUSE commands.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19824
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Duly removed the duplicate. Thank you again for your work on this.

Offline Roboron

  • *
  • Posts: 63
    • Las Galácticas Aventuras de Komoyo Diga
  • Languages: ES, EN
As I mentioned in other thread, I've created a PKGBUILD in the Arch Linux User Repository which automagically does all of this. It gets the source, the dependencies, applies some configuration patches, compiles the executable and installs Simutrans-Extended system-wide. Probably users of Arch Linux/Manjaro would prefer this over manual compiling (although you maybe don't want to compile Extended every day - but you also don't have to update if you don't want to).

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19824
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
As I mentioned in other thread, I've created a PKGBUILD in the Arch Linux User Repository which automagically does all of this. It gets the source, the dependencies, applies some configuration patches, compiles the executable and installs Simutrans-Extended system-wide. Probably users of Arch Linux/Manjaro would prefer this over manual compiling (although you maybe don't want to compile Extended every day - but you also don't have to update if you don't want to).

Excellent, that is very helpful: thank you for this.

Offline Matthew

  • *
  • Posts: 335
    • Japan Railway Journal
  • Languages: EN, some ZH, DE & SQ
A Newbie's Guide to Profiling Simutrans-Extended in Ubuntu / Debian / Linux
« Reply #9 on: February 10, 2020, 01:12:34 AM »
After learning to compile Simutrans-Extended, you may wish to change the code and see how it affects the game. As part of this process, it can be helpful to use a performance profiler. This stops the game many times every second to see which part of the code was just processed by the CPU(s) and then summarizes the totals. In this way, you can see what parts of the code are doing the most work.

We are going to use the perf profiler, which is used for profiling the Linux kernel. Existing tutorials seem to add a lot of complex kernel-related stuff, which I have tried to skip over.

This post uses the assumptions and definitions from the first post of this thread and assumes steps 1-5 there. I am still a newbie, so corrections and suggestions are very welcome.

6. Set up your configuration file for debugging

Back up your config.default file. Now edit it by deleting the # at the start of these lines:

Code: [Select]
BACKEND = sdl2
COLOUR_DEPTH = 16
OSTYPE = linux
DEBUG = 3
OPTIMISE = 1
If you want to be able to read more debugging messages in simu.log, you can also set MSG_LEVEL = 3, but this will mean that you are profiling the debug build. In most cases you want the build that you are profiling to be as close as possible to a 'normal' build.

7. Compile a debug version

Open (or switch back to) a terminal in your working directory. If there is a /build subdirectory there, then the compiler may be distracted by old files in it, so send it to the rubbish bin using your file manager or delete it permanently using

Code: [Select]
rm -r build
Then compile the debug version using make. If you have (for example) eight cores, you can use make -j8 for speed. Either way, the debug version will take much longer to compile than the normal version.

8. Set up Simutrans-Extended

After compiling you will have a fresh /build/default/simutrans-extended file. Rename it (we will use simutrans-extended-debug) and move it to your game directory. You can play the game in the normal way using this executable, but it will run much, much more slowly.

You will need to make sure you have space (in the hundreds of megabytes) available on the same partition as your game directory.

Quote from: Freahk
You can also open a terminal in your game directory and create a symlink to the just compiled binary
Code: [Select]
cd <path to your simutrans installation>
ln -s <path to your simutrans source root>/build/default/simutrans-extended simutrans-extended-dev
This will create a symbolic link named simutrans-extended-dev linking to the place where the new binary will be placed after each compile. However, this will mean that you can only have one debug build at a time.

9. Install perf

Open a terminal and run

Code: [Select]
sudo apt install perf
If you are lucky, perf may install immediately. But in Ubuntu, you will get an error message talking about your kernel version, presumably because perf is tightly tied to the kernel. Note your kernel version: we will use 5.4 as an example. Run this command, adjusted for your version number:

Code: [Select]
sudo apt update
sudo apt install linux-5.4-tools-common
sudo apt install linux-tools-common

If that doesn't work and you are using another Debian distribution, try this instead (remembering to use your kernel version):

Code: [Select]
sudo apt install linux-perf-5.4
If you are using openSUSE, freahk recommends elevating to root and installing perf:

Code: [Select]
su
zypper ref
zypper in perf
exit

10. Use perf to measure Simutrans-Extended

Open a terminal in your game directory and run

Code: [Select]
sudo perf record -g ./simutrans-extended-debug
Simutrans-Extended will load and you can play-test your changes. As you do this, perf will measure the game's performance and generate logfiles. For reasons that will become clear later, you can only play for a short time: from my limited experience, perhaps one minute for every GiB of RAM in your system. If you want to test on a new map, it might be better to make your map before you start profiling. When you have reached your time limit, exit Simutrans-Extended in the normal way (saving if you want to).

Quote from: Freahk
If you set up a symbolic link in step 8, open a terminal in your game directory and run

Code: [Select]
sudo perf record -g ./simutrans-extended-dev -use_workdir
-use_workdir will tell simutrans to look for paksets and so on in the current working directory instead of the directory where the binary is placed.

It is common for Simutrans-Extended to crash when you are testing new code. When you are using perf, you may not be able to close a crashed program in the usual ways. If your build has "simutrans" in its name, then you can close the crashed Sim-Ex using this command:

Code: [Select]
sudo pkill -9 simutrans
Once this is done, perf will save its logs and close.

11. Convert the perf logs into an ASCII graph

We now need to convert those logs into something humans can understand. This conversion requires very large amounts of RAM, hence the one minute of play per 1 GiB of RAM rule of thumb. You may need to shut down your browser and other RAM-hungry programs during the conversion.

The traditional approach is to analyze the results as an ASCII graph. To do this, run the following in your game directory:

Code: [Select]
sudo perf report -g graph,0.05 --stdio > graph
After several minutes, this will generate a text file called graph that can be opened in any text editor. It's possible to stop here. However, the graph is difficult to read, so the following steps will describe how to create an alternative called a flamegraph. But I recommend making an ASCII graph once to check that perf is working correctly, and that you have enough RAM, before you continue.

12. Install Perl and flamegraph

Most Linux distributions install the Perl programming language by default, but if you don't have it for some reason, then

Code: [Select]
sudo apt install perl
Now download these Perl scripts to your game directory: stackcollapse-perf.pl and flamegraph.pl, which were written by Brendan Gregg and are distributed under the CDDL.

13. Convert the perf logs into a flamegraph

Open a terminal in your game directory and run:

Code: [Select]
sudo perf script | ./stackcollapse-perf.pl > out.perf-folded
sudo grep -v cpu_idle out.perf-folded | ./flamegraph.pl > debug.svg

Again, this conversion will take several minutes, though it requires less RAM than the traditional method.

Those commands should exclude functions which are stalled while waiting for I/O, so the results are biased towards ordinary play and away from the start-up process (especially if you are using a traditional hard drive). If loading and saving paksets or savegames is the part of Simutrans that you are interested in, then you may need to adjust this step.

14. Open your flamegraph

Open a new tab in a web browser (Firefox/Chrome) and load debug.svg from your game directory. Scroll down, and you should see a brightly-coloured graph. Although image viewers can also open SVG files, you need to use a browser to access the interactive elements.

The X axis shows how much time your CPU is spending on each function. For example, if half the X axis is used by main, then your CPU is spending half its time running that function. Note that the X axis is not chronological: it is showing you 'how much', not 'when'.

The Y axis shows the relationship of different functions to each other. For example, the only real job of main() to call sysmain, which is therefore stacked on top of it.

You can hover over functions to see the exact percentage of CPU time that they used. You can click on functions to zoom in on them; you can zoom out again in the top left-hand corner. You can find particular functions using Ctrl+F or the 'Search' text in the top-right hand corner (click on 'ic' to toggle case sensitivity). This is essential for many Sim-Ex functions. Some functions are called by multiple functions (especially the _tpl templates), so use Search to make sure that you have identified all the calls. You can reset Search in the top right-hand corner of the graph.

Footnote: Sharing flamegraphs

For good security reasons, you will not be able to share SVG flamegraphs on this forum by the usual methods (forum attachments, Github, Imgur or Simutrans-Germany). It can be done, but it is a complex process that needs its own tutorial.
« Last Edit: February 11, 2020, 07:46:05 PM by Matthew »

Offline Roboron

  • *
  • Posts: 63
    • Las Galácticas Aventuras de Komoyo Diga
  • Languages: ES, EN
Re: A Newbie's Guide to Compiling Simutrans-Extended in Ubuntu / Debian / Linux
« Reply #10 on: February 11, 2020, 12:53:26 PM »
Wow, that's a very detailed and helpful explanation. I think it would be of great value if it were added to the Simutrans Wiki.

Offline Freahk

  • Devotee
  • *
  • Posts: 1073
  • Languages: DE, EN
Re: A Newbie's Guide to Compiling Simutrans-Extended in Ubuntu / Debian / Linux
« Reply #11 on: February 11, 2020, 03:53:38 PM »
Thanks, that's a good tutorial I guess.

Some additions that might be helpful:
In step 6 note that profiling should always be done on the optimized binary, as close as possible to the one you would "release".
Thus,
set MSG_LEVEL=0 to prevent simutrans spamming more than it would do in a non-debug build without explicitly set MSG_LEVEL and
set DEBUG=1, which will add debug symbols and defines the DEBUG macro variable but nothing more.
One could even argue about dropping the definition of the DEBUG macro, as there might be paths in the code that are only accessed #ifdef DEBUG, however my IDE couldn't find any, so it's fine.

Instead of step 8, navigate to yor simutrans installation dir and create a symlink to the just compiled binary
Code: [Select]
cd <path to your simutrans installation>
ln -s <path to your simutrans source root>/build/default/simutrans-extended simutrans-extended-dev
This will create a symbolic link names simutrans-extended-dev linking to the place where the new binary will be placed after each compile.

In step 9, using opensuse, simply elevate to root and install perf.
Code: [Select]
su
zypper ref
zypper in perf
exit

In step 10, in the terminal navigate to your simutrans installation dir again.
run
Code: [Select]
sudo perf record -g ./simutrans-extended-dev -use_workdir-use_workdir will tell simutrans to lok for paksets and so on in the current working directory instead of the directory where the binary is placed in.
You might not need sudo. That depends on your systems kernel.perf_event_paranoid settings.
I am btw. kind of surprrided sudo works properly with the x window system, here it doesn't but su will do the job.

opensuse users, don't use sudo, you won't need it at all (at least I guess the default setting allows this, not sure if I had changed it some day)
If it does not work without sudo, use su
Code: [Select]
su
perf record -g ./simutrans-extended-dev -use_workdir


About the proces killing I am not quite sure what is going on.
Quote
When you are using perf, you will not be able to close a crashed program in the usual ways.
On my machine simutrans will simply crash, a coredump will be written and the process will terminate after it.

However, generally looking up the pid and killing the process as described will work. However, there is an easyer way to do so and I am not quite sure why you cose the -7 signal, which is SIGBUS in linux x86, telling the process it had attempted to access a memory address that the hardware (cpus memory controller) physically cannot access.
For a list of signals see "kill -l"
I assume what yo are looking for is SIGKILL (-9) or SIGINT (-2)

The mentioned easyer way is using pkill instead of kill.
pkill will accept a process name pattern. Note that by default it will only match the first 16 chars of of the name. That's fine for us, we will simply kill any preceses that match simutrans.
Code: [Select]
pkill -9 simutrans
Further I want to recommend installing and using htop instead of top.
« Last Edit: February 11, 2020, 04:32:19 PM by Freahk »

Offline Matthew

  • *
  • Posts: 335
    • Japan Railway Journal
  • Languages: EN, some ZH, DE & SQ
Re: A Newbie's Guide to Compiling Simutrans-Extended in Ubuntu / Debian / Linux
« Reply #12 on: February 11, 2020, 05:35:00 PM »
Wow, that's a very detailed and helpful explanation. I think it would be of great value if it were added to the Simutrans Wiki.

This is a good idea; I will reply to you privately about it.

Thanks, that's a good tutorial I guess.

Thank you for the kind words.

Quote
Some additions that might be helpful:
In step 6 note that profiling should always be done on the optimized binary, as close as possible to the one you would "release".
Thus,
set MSG_LEVEL=0 to prevent simutrans spamming more than it would do in a non-debug build without explicitly set MSG_LEVEL and
set DEBUG=1, which will add debug symbols and defines the DEBUG macro variable but nothing more.
One could even argue about dropping the definition of the DEBUG macro, as there might be paths in the code that are only accessed #ifdef DEBUG, however my IDE couldn't find any, so it's fine.

I am very new to this, so thank you for these suggestions. For example, now you have taught me about it, I can see we should not try not to change the binary. I wrote DEBUG = 3 MSG_LEVEL = 3 because it's suggested in config.default. So I had a look at the Makefile and it says

Code: [Select]
ifdef DEBUG
ifndef MSG_LEVEL
MSG_LEVEL = 3
endif

So I think the MSG_LEVEL is going to be 3 for any Linux debug build, right? The Makefile also explains how the DEBUG setting relates to compiler options and I tried to understand this before I wrote the post, but the advice that I found assumed that perf was only used with the kernel and therefore special debug packages were pre-compiled. I know DEBUG=3 appears to work; I think I should test other settings before I edit the tutorial. That can wait until I need to do profiling again.

Quote
Instead of step 8, navigate to yor simutrans installation dir and create a symlink to the just compiled binary

I can see why this makes sense and will add it. Actually config.default allows you to place the result anywhere you want. My method assumes something I didn't say: if you are profiling, you are probably comparing executables from different branches, so you'll want to have different names for them. Right now I have about 30 executables in my game directory......

Quote
In step 10, in the terminal navigate to your simutrans installation dir again.
run
Code: [Select]
sudo perf record -g ./simutrans-extended-dev -use_workdir-use_workdir will tell simutrans to lok for paksets and so on in the current working directory instead of the directory where the binary is placed in.

Good point, I forgot that not everybody has simutrans in /home.

Quote
You might not need sudo. That depends on your systems kernel.perf_event_paranoid settings.

I am not happy with running this process as root, especially since I am asking people to download scripts from some random URL (though I stalked Brendan Gregg and think he is probably trustworthy). But after an hour of trawling through docs for kernel devs, I gave up. Yesterday I learned a way to set this up and it works, but I am not sure what is worse for us newbies: running random scripts as root, or messing about with a file containing critical kernel settings. I will maybe add it as an option, along with using su.

Quote
About the proces killing I am not quite sure what is going on.On my machine simutrans will simply crash, a coredump will be written and the process will terminate after it.

However, generally looking up the pid and killing the process as described will work. However, there is an easyer way to do so and I am not quite sure why you cose the -7 signal, which is SIGBUS in linux x86, telling the process it had attempted to access a memory address that the hardware (cpus memory controller) physically cannot access.
For a list of signals see "kill -l"
I assume what yo are looking for is SIGKILL (-9) or SIGINT (-2)

I could not get ordinary methods to work and this post suggested -7, which seemed to work. But....

Quote
The mentioned easyer way is using pkill instead of kill.
pkill will accept a process name pattern. Note that by default it will only match the first 16 chars of of the name. That's fine for us, we will simply kill any preceses that match simutrans.
Code: [Select]
pkill -9 simutrans

Thank you, I never knew about pkill before!

Quote
Further I want to recommend installing and using htop instead of top.

Happily, newbies don't need to worry about PIDs now that you have taught me about pkill!

Offline Freahk

  • Devotee
  • *
  • Posts: 1073
  • Languages: DE, EN
Re: A Newbie's Guide to Compiling Simutrans-Extended in Ubuntu / Debian / Linux
« Reply #13 on: February 11, 2020, 06:41:03 PM »
So I think the MSG_LEVEL is going to be 3 for any Linux debug build, right?
Not really.
ifdef will check if a variable is defined, ifndef will check if a values is not defined.
Not defined means either there is no declaration of the variable at all (line commendet out or does not exist at all) or an empty declaracion (VAR=).
Anything else, including VAR=0 is defined.
Thus, the MSG_LEVEL will be 3 if the line is commented out but you can explicitly enforce any other value, e.g. MSG_LEVEL=0

The point in not using DEBUG levels above 1 is that these will disable some optimisations. DEBUG=3 will finally effectively ignore your OPTIMISE setting, overriding the -O3 optimisation flag with -O0.
When profiling such a binary, you will likely find bottlenecks in the code that actually aren't bottlenecks in the optimised release build.


Good point, I forgot that not everybody has simutrans in /home.
-use_workdir is not about simutrans being placed in home or not. It will also work without that flag if the whole simutrans installation is placed in e.g. /bin/simutrans (DONT! DO! THIS!)
The point about -use_workdir is that although the symlink you launced is placed next to the paksets, simutrans will be quite unhappy when launching it through this symlink because its friends, the paksets and so on are not around. The -use_workdir will tell simutrans to look for these in the current working directory, so set the working directory to your simutrans install e.g. using cs, use the -use_workdir flag and simutrans will be happy, no matter if actually sitting next to its friends or in a scrapyard of build trash.

Happily, newbies don't need to worry about PIDs now that you have taught me about pkill!
Whenever looking for a really good linux "taskmanager", you should have a look at htop nevertheless ;)