On Windows, relative folders don't work so well. So we need to
lookup the full path. This is best done in DetermineBasePaths()
and as a bonus that only sets SP_WORKING_DIR once.
Basically, with '-c' you now create a sandbox. It will still use
your personal-dir and global-dir to find files you installed there,
but all new files are stored with a base folder identical to the
folder the configuration is in.
This is a bit of an old bug, that we many have tried to solve in
various of different ways. The code has grown sufficiently complex
that it is hard to see what consequences of actions are. This is
in my opinion the most harmless solution, while increasing the
usefulness of the '-c' flag.
In essence, the problem was that empty folders were always created
in the directory where the configuration was, but as that directory
wasn't added to any searchpath, files weren't stored there, unless
by accident it was a folder already on the searchpath. For example,
if you do './openttd -c local.cfg', it did work as expected. But
in the more generic variant, it did not.
With this patch, you can run './openttd -c /new/folder/local.cfg',
and it will create and prepare that folder to receive new files.
'content_download' is also stored in the directory the
configuration is in; this was already the case. Important to
note that there is only one search-path for 'content_download'.
In other words, when using '-c', it will not look in '~/.openttd'
inside the 'content_download' folder.
This was just weird. With XDG _personal_dir was created already,
but later on it was checked if it was different from config_dir,
and the creation was skipped. All this checking and validation
makes my head spin .. let's make it a bit more simple.
This switch has been a pain for years. Often disabling broke
compilation, as no developer compiles OpenTTD without, neither do
any of our official binaries.
Additionaly, it has grown so hugely in our codebase, that it
clearly shows that the current solution was a poor one. 350+
instances of "#ifdef ENABLE_NETWORK" were in the code, of which
only ~30 in the networking code itself. The rest were all around
the code to do the right thing, from GUI to NewGRF.
A more proper solution would be to stub all the functions, and
make sure the rest of the code can simply assume network is
available. This was also partially done, and most variables were
correct if networking was disabled. Despite that, often the #ifdefs
were still used.
With the recent removal of DOS, there is also no platform anymore
which we support where networking isn't working out-of-the-box.
All in all, it is time to remove the ENABLE_NETWORK switch. No
replacement is planned, but if you feel we really need this option,
we welcome any Pull Request which implements this in a way that
doesn't crawl through the code like this diff shows we used to.
In 10 years there was no active development on DOS. Although it
turned out to still work, the FPS was very bad. There is little
interest in the current community to look into this.
Further more, we like to switch to c++11 functions for threads,
which are not implemented by DJGPP, the only current compiler
for DOS.
Additionally, DOS is the only platform which does not support
networking. It is the reason we have tons of #ifdefs to support
disabling networking.
By removing DOS support, we can both use c++11 functions for threads,
and remove all the code related to disabling network. Sadly, this
means we have to see DOS go.
Of course, if you feel up for the task, simply revert this commit,
and implement stub c++11 functions for threads and stub functions
for networking. We are more than happy to accept such Pull Request.
config.lib happens to set GLOBAL_DATA_DIR in case it is not DOS
and not OS2, but this kind of deduction is annoying to maintain.
It is better to just check if the define you want to use is set,
and leave it to config.lib to set it or not depending on the OS.
In 10 years there is no commit to change how MorphOS works, and we
have no active maintainer for it. It is unlikely it works in its
current state (but not impossible).
With the arrival of SDL2 (and removal of SDL), MorphOS is no longer
support. There is an SDL2 port for MorphOS, but it is not maintained
by upstream SDL2, and nobody can currently test it out.
If anyone wants to re-add MorphOS, please do (revert this patch,
fix the problems, and create a Pull Request). If you need any help
doing so, let us know! It is not that we don't like MorphOS, it is
that we don't have anyone fixing the problems :(
