This can avoid out-of-memory situations due to single scripts using up the entire address space.
Instead, scripts that go above the maximum are killed.
The maximum is default 1 GB per script, but can be configured by a setting.
finnish: 2 changes by hpiirai
english (us): 17 changes by Supercheese
luxembourgish: 10 changes by Phreeze
dutch: 20 changes by JanWillem
norwegian (bokmal): 2 changes by Leifbk
latin: 16 changes by Supercheese
portuguese: 3 changes by JayCity
finnish: 12 changes by hpiirai
greek: 40 changes by Jubilee
luxembourgish: 2 changes by Phreeze
dutch: 12 changes by JanWillem
french: 4 changes by romazoon
norwegian (bokmal): 12 changes by Leifbk
hungarian: 14 changes by Brumi
portuguese: 51 changes by JayCity, 11 changes by vesgo
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.
It is only an error if the invalid result is actually used. This will be silently ignored at the moment.
It is still an error if a duplicate cargo type is returned.
This change is a controlled by a game setting, located under Environment ->
Industries which allows toggling the behaviour. It defaults to enabled.
"Company stations can serve industries with attached neutral stations"
When enabled, industries with attached neutral station (such as Oil Rigs) may
also be served by company-owned stations built nearby. This is the traditional
behaviour.
When disabled, these industries may only be served by their neutral station.
Any nearby company-owned stations won't be able to serve them, nor will the
neutral station serve anything else other than the industry.
In 10 years there is no commit to change how BeOS 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), BeOS is no longer
support. SDL2 suggests to use Haiku instead of BeOS.
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 :(
Introduce a new default algorithm for town cargo generation (passengers and mail), and a game setting to choose between the new and original algorithm.
The original town cargo generation algorithm has the property of the generated amount relating to the square of each building's population, meaning large towns easily produce more cargo than can realistically be transported. The problem is excessive cargo is amplified if playing with cargodist.
The new algorithm introduced instead has a linear relation to the population. The result is that smaller towns will produce slightly more cargo, while the largest towns will produce about a fourth of what they would with the original algorithm.
Existing savegames will use the original algorithm, while new games will default to the new algorithm.
finnish: 39 changes by hpiirai
french: 4 changes by glx
hungarian: 4 changes by Brumi
russian: 3 changes by Lone_Wolf
korean: 20 changes by telk5093
croatian: 5 changes by VoyagerOne
croatian: 4 changes by VoyagerOne
korean: 4 changes by telk5093
russian: 2 changes by Lone_Wolf
german: 4 changes by smwforever45, 4 changes by ShadowCop
spanish (mexican): 2 changes by Absay
portuguese: 52 changes by vesgo
finnish: 3 changes by hpiirai
dutch: 238 changes by JanWillem
estonian: 1 change by rm87
swedish: 36 changes by Joel_A
spanish: 3 changes by SilverSurferZzZ
russian: 2 changes by Lone_Wolf
romanian: 18 changes by kneekoo
portuguese: 37 changes by vesgo
* Change: Replace checkbox in livery selection window with Default option in drop down selection.
This reduces clutter in the UI and allows for primary/secondary colours to independently follow the default scheme if desired.
* Feature: Add vehicle group liveries.
belarusian: 1 change by translators
norwegian (nynorsk): 1 change by translators
chinese (simplified): 1 change by translators
serbian: 1 change by translators
czech: 1 change by translators
esperanto: 1 change by translators
chinese (traditional): 1 change by translators
portuguese (brazilian): 1 change by translators
norwegian (bokmal): 1 change by translators
swedish: 1 change by translators
lithuanian: 1 change by translators
hebrew: 1 change by translators
croatian: 1 change by translators
bulgarian: 1 change by translators
catalan: 1 change by translators
afrikaans: 1 change by translators
vietnamese: 1 change by translators
slovenian: 1 change by translators
faroese: 1 change by translators
thai: 1 change by translators
frisian: 1 change by translators
scottish gaelic: 1 change by translators
persian: 1 change by translators
korean: 1 change by translators
greek: 1 change by translators
latin: 1 change by translators
welsh: 1 change by translators
galician: 1 change by translators
japanese: 1 change by translators
english (au): 1 change by translators
italian: 6 changes by lorenzodv, 1 change by translators
urdu: 1 change by translators
french: 7 changes by glx
malay: 1 change by translators
tamil: 1 change by translators
spanish: 4 changes by SilverSurferZzZ, 1 change by translators
slovak: 1 change by translators
basque: 1 change by translators
polish: 1 change by translators
indonesian: 1 change by translators
arabic (egypt): 1 change by translators
russian: 2 changes by Lone_Wolf, 1 change by translators
hungarian: 1 change by translators
luxembourgish: 1 change by translators
romanian: 1 change by translators
irish: 1 change by translators
latvian: 1 change by translators
german: 1 change by translators
danish: 1 change by translators
spanish (mexican): 7 changes by Absay
icelandic: 1 change by translators
english (us): 1 change by translators
turkish: 1 change by translators
portuguese: 1 change by translators
ukrainian: 1 change by translators
finnish: 1 change by translators
dutch: 1 change by translators
estonian: 1 change by translators
Change the window to use a dynamically generated string of cargoes,
instead of one of a few fixed-length lists. With up to 16 cargoes
on each list, having 16 with the only difference how many are listed
seems like a bad maintenance idea.
translators
Niels Martin Hansen
Gabda
nikolas
pnda
iigmir
peter1138
glx
Charles Pigott
Patric Stout
PeterN
Johannes E. Krause
Greg Carlin
Joan Josep
Alberth289346
Eddi-z
damfr
Oskari Leppäaho