Touchbar support was introduced in 10.12.2. There's no need to limit
support to 10.15+, as the convenience class NSButtonTouchBarItem is
easily replicated.
A race condition happens when an IPv6 connection takes more than
250ms to report an error, but does return before the IPv4 connection
is established.
In result, an invalid socket might be used for that connection.
It turns out that having "-g" in the compile-statement causes
Emscripten to pick -g3, which makes for very big binaries. This
is very likely not your intention when building Emscripten, as
smaller really is better.
For comparison, with RelWithDebInfo the binary is ~80MB. With
Release it is ~7.4MB.
This gives user visual feedback that the refresh is still pending, and
prevents people from clicking again and again thinking nothing is
happening. This is especially true for connections that fall back to
TURN, as that takes a few seconds to kick in.
Additionally, prevent clicking on the button again while a refresh
is pending. This is only delaying a successful result.
Also the memory allocation triggering the limit was never freed.
And if the exception was thrown in a constructor using placement new, the pre-allocated memory was not freed either.
MCST e2k (Elbrus 2000) architecture has half native / half software support of most Intel/AMD SIMD
e.g. MMX/SSE/SSE2/SSE3/SSSE3/SSE4.1/SSE4.2/AES/AVX/AVX2 & 3DNow!/SSE4a/XOP/FMA4
E2K - this is VLIW/EPIC architecture, like Intel Itanium (IA-64) architecture.
Ref: https://en.wikipedia.org/wiki/Elbrus_2000
Co-authored-by: Alexander Troosh @troosh, Konstantin Ivlev @sse4 and Dmitry Shcherbakov @crypto-das
korean: 4 changes by telk5093
greek: 1 change by dionisis84
russian: 2 changes by Ln-Wolf
finnish: 1 change by hpiirai
portuguese: 1 change by azulcosta
english (us): 3 changes by 2TallTyler
greek: 3 changes by dionisis84
finnish: 3 changes by hpiirai
french: 3 changes by glx22
portuguese: 4 changes by azulcosta
It is not like we will drain the sea first, to put water back in it after.
Besides, the cost for draining the sea isn't calculated for all other cases either.
english (us): 4 changes by 2TallTyler
greek: 10 changes by dionisis84
german: 4 changes by MagnumSociety
dutch: 4 changes by Afoklala
spanish: 66 changes by MontyMontana
polish: 10 changes by pAter-exe
japanese: 30 changes by scabtert
russian: 4 changes by Ln-Wolf
finnish: 4 changes by hpiirai
catalan: 4 changes by J0anJosep
portuguese: 4 changes by azulcosta
Although several places were fixed during the PR making the change,
not all made it in this document.
While at it, removed all kinds of Markdown warnings by an excessive
usage of spacebar in this document.
If an exceptions is thrown during context creation, just declare the XAudio
driver as unusable. The driver logic will try to find an alternative for us.
spanish (mexican): 4 changes by absay
english (us): 6 changes by 2TallTyler
russian: 6 changes by Ln-Wolf
catalan: 6 changes by J0anJosep
dutch: 6 changes by Afoklala
korean: 6 changes by telk5093
hungarian: 34 changes by pnpBrumi
indonesian: 16 changes by dimaspaf14
latvian: 94 changes by lexuslatvia
polish: 2 changes by pAter-exe
The function clears all stun-handlers. This causes all of those
objects to be destroyed.
A handler can have a pending connecter, which was only killed in
case CloseConnection() was called. This is never the case when
the object is destroyed. In result, the connecter could finish
and cause a use-after-free by calling into the (now deleted)
handler.
"stations_near" wasn't updated when founding a town near
a station. As this variable is not saved, any client joining
after the town is founded has a different value for
"stations_near", potentially causing desyncs.
As the intention of this if() statement was to skip an expensive
calculation when there are clearly no stations, better to move
that check inside the function, so other places also enjoy
the speedup.
When coming across any docking tile (for example, all tiles around
an oilrig are docking tiles), it always at least added a penalty
of 3 times a normal tile, even when there are no ships on them.
In result, the pathfinder got suggested to always go around docking
tiles. This was most likely not the intention of the change made in
31db4f8d5e.
When you are query several servers at once, it is rather unclear
for which server you got a popup. Instead, show any errors on the
server itself.
This is only true for the query-part. Joining a server still gives
an error popup to tell you about any issue.
You can now still query a full server, as long as the maximum
amount of allowed connections isn't reached. This means that as
long as there are not 255 clients connected to a server, you can
always connect to query.
Old servers don't tell the GameScript they are running, so nothing
should be shown.
All values in NetworkGameInfo initialize as 0/empty, except for GS
version. Someone has to be different from the rest, I guess.
A stale link is not deleted if the link refresher finds a vehicle that still serves it.
This commit excludes vehicles stopped in depot for a very long time from the link refresher,
so that their stale links can be deleted.
Passengers usually prefer fast paths to short paths.
Average travel times of links are updated in real-time for use in Dijkstra's algorithm,
and newer travel times weigh more, just like capacities.
Adds the support to query the linecache without copying the string.
This uses a custom transparent comparator in conjunction with
a query type using a std::string_view.
chinese (simplified): 82 changes by goodspeed34
french: 2 changes by glx22
portuguese: 1 change by azulcosta
portuguese (brazilian): 2 changes by Vimerum
One question that keeps popping up: "when do we release 2.0?".
NewGRF will force that at least 1.16 will be 2.0, but to not wait
for this, let's drop the "1." and be for ever done with that
conversation.
We are following in the footstep of giants here.
"For negative a, the value of a >> b is implementation-defined (in most implementations, this performs arithmetic right shift, so that the result remains negative)."
Nobody really paid attention to the lobby window, and it completely
missed its purpose. Most people don't even wait for companies to
show up, but just hit "New Company".
This in turn means people create a lot of unneeded companies, while
they "just want to watch the game" or join another company.
Instead, "Join Game" now just joins the game as spectators.
Soon we will make "join game" join the game as spectator first,
so limiting the amount of spectators makes no sense anymore in
that context. Not sure it ever did make sense.
Currently, scripts use various heuristics to detect loaded NewGRFs that are inherently unreliable.
The list of loaded NewGRFs is easily accessible to a human player, and thus giving
scripts the same information is consistent with the current approach to not give scripts
more information than a human player.
Cargo payments were stored as unsigned integer, but cast to int64 during
application of inflation. However, then being multiplied with a uint64
making the result uint64. So in the end the payment that should have been
negative becomes hugely positive.
"my_client" wasn't always free'd when a game ended. "my_client"
keeps a reference inside the PT_NCLIENT pool. The rest of the
code assumes that when you are not in a game, it can freely
reset this pool.
In result: several ways to trigger a use-after-free.
english (us): 15 changes by 2TallTyler
korean: 12 changes by telk5093
russian: 3 changes by Ln-Wolf
portuguese: 12 changes by azulcosta
polish: 98 changes by pAter-exe
TURN is a last resort, used only if all other methods failed.
TURN is a relay approach to connect client and server together, where
openttd.org (by default) is the middleman.
It is very unlikely either the client or server cannot connect to
the STUN server, as they are both already connected to the Game
Coordinator. But in the odd case it does fail, estabilishing the
connection fails without any further possibility to recover.
INT64_MIN negated is above INT64_MAX, and would overflow.
Instead, when negating INT64_MIN make it INT64_MAX.
This does mean that -(-(INT64_MIN)) != INT64_MIN.
Before 8a2da49 the NewGRF names were synchronized using UDP packets, however
those have been removed. With this a new version of the GameInfo packet is
introduced that allows to specify the type of serialisation happens for
NewGRFs. Either only the GRF ID and checksum, or those two plus the name of
the NewGRF.
On this request for local servers will send the NewGRFs names.
The Game Coordinator will get the names on the first registration, and after
that only the GRF ID and checksum.
These were filled with "<Unknown>" (before 8a2da49) and later their name would get filled via UDP requests to the server. These UDP packets do not exist anymore, so they will always remain "<Unknown>".
Remove that logic and just use the generic translated error GRF UNKNOWN string instead.
This method doesn't require port-forwarding to be used, and works for
most common NAT routers in home setups. But, for sure it doesn't work
for all setups, and not everyone will be able to use this.
spanish (mexican): 4 changes by absay
english (us): 13 changes by 2TallTyler
korean: 5 changes by telk5093
german: 13 changes by Wuzzy2
portuguese: 4 changes by azulcosta
hindi: 6 changes by ritwikraghav14
Now you can use things like `set server_game_type public` instead of having to
guess the number, which would not be written into the configuration file nor
would it be shown when doing `set server_game_type`.
Every outgoing connection, either TCP or UDP, triggered
NetworkInitialize(), which triggered NetworkUDPInitialize() which
first closes all connections.
Now the problem was that "Search LAN games" found a server, added
it to the list, after which (over TCP) it queries the server. This
closes all UDP sockets (as that makes sense, I guess?), while the
UDP was still reading from it.
Solve this by simply stop initializing UDP every time we make an
outgoing TCP connection; instead only do it on start-up.
In this mode you do register to the Game Coordinator, but your
server will not show up in the public server listing. You can give
your friends the invite code of the server with which they can
join.
This removes the need to know a server IP to join it. Invite codes
are small (~7 characters) indentifiers for servers, which can be
exchanged with other players to join the servers.
Normally TCPConnecter will do a DNS resolving of the connection_string
and connect to it. But for SERVER_ADDRESS_INVITE_CODE this is different:
the Game Coordinator does the "resolving".
This means we need to allow TCPConnecter to not setup a connection
and allow it to be told when a connection has been setup by an external
(to TCPConnecter) part of the code. We do this by telling the (active)
socket for the connection.
This means the rest of the code doesn't need to know the TCPConnecter
is not doing a simple resolve+connect. The rest of the code only
cares the connection is established; not how it was established.
This statement was removed by accident, as it felt it could be removed.
But it is used to know if the NewGRF is from the baseset folder or
from the NewGRF folder.
OTTD_COORDINATOR_CS for the game coordinator defaults to coordinator.openttd.org:3976
OTTD_CONTENT_SERVER_CS for the content server defaults to content.openttd.org:3978
OTTD_CONTENT_MIRROR_CS for the content mirror server defaults to binaries.openttd.org:80
The C++ std::getenv is guaranteed thread-safe by the C++11 specification,
whereas the POSIX/C getenv might not be thread-safe by the C11 specification.
The outer if statement checks for 'aa' being false, so within the inner
statements anything checking aa will have a known result and the other
branch from there will be dead code.
This reduced the load on compilers, as currently for example MacOS
doesn't like the huge settings-tables.
Additionally, nobody can find settings, as the list is massive and
unordered. By splitting it, it becomes a little bit more sensible.
LoadCheck makes it sound like something is really broken while
loading savegames, while it really is perfectly normal, as most
chunks do not implement LoadCheck.
num_liveries indirectly contained the same information, but this
makes reading these things pretty difficult. So use IsSavegameVersionBefore()
like everywhere else instead.
IsSavegameVersionUntil() did a [0, N] check, not [0, N) as the
name suggests.
Until can be a confusing word, where people consider it to be
including the upperbound. Dictionary states it means "before",
excluding the upperbound. There are long debates about who is right.
So, simply remove away from this ambiguity, and call it "before"
and "before or at". This makes the world easier for everyone.
We no longer need them. If you want to remove a field .. just
remove it! Because of the headers in the savegame, on loading,
it will do the right thing and skip the field.
Do remember to bump the savegame version, as otherwise older
clients can still load the game, but will reset the field you
have removed .. that might be unintentially.
We won't be able to make it fully self-descriptive (looking at you
MAP-chunks), but anything else can. With this framework, we can
add headers for each chunk explaining how each chunk looks like
in detail.
They also will all be tables, making it a lot easier to read in
external tooling, and opening the way to consider a database
(like SQLite) to use as savegame format.
Lastly, with the headers in the savegame, you can freely add
fields without needing a savegame version bump; older versions
of OpenTTD will simply ignore the new field. This also means
we can remove all the SLE_CONDNULL, as they are irrelevant.
The next few commits will start using this framework.
We often ask people for their openttd.cfg, which now includes their
passwords, usernames, etc. It is easy for people to overlook this,
unwillingly sharing information they shouldn't.
By splitting this information over either private.cfg or secrets.cfg,
we make it more obvious they shouldn't be sharing those files, and
hint to what is inside them.
Instead of creating the object on heap and use a pointer, create
the object on stack and use a guaranteed-not-null pointer.
The size of IniFile doesn't warrent the forcing to heap.
Additionally, use a subclass instead of a function to do some
initial bookkeeping on an IniFile meant to read a configuration.
Unless invoked with -w, --warning ("print a warning for any untranslated strings") or -t, --todo ("replace any untranslated strings with '<TODO>'").
Eints normally fixes the warnings after a Pull Request, so it is not really useful information for the developer to see as a warning.
With std::variant all memory can be figured out at compile time, so the compiler needs to keep track of fewer elements. It also saves out a unique_ptr and its memory management, over a slight impact for resolving a setting.
One UpdateServiceInterval has two parameters to update the service interval for a vehicle type, the other for all vehicle types at once. Rename the latter to help with function resolution for the introduction of variants.
Rename the zero-parameter NetworkValidateClientName to NetworkValidateOurClientName to make it clearer it is performed on our client name, and to make it a non-overloaded function to aid with the variant being added a few commits later
ThreadSanitizer rightfully notices that the game-thread could
update the palette while the draw-thread is copying it for local
use. The odds of this are very small, but nevertheless, it does
carry a very good point.
It wouldn't hurt the application in any way, but it might cause
visual glitches on the screen.
The enum values still have the exact same numerical values, but the 10.12
SDK introduced more explicit names (e.g. like NSEventTypeApplicationDefined
instead of NSApplicationDefined) for several enum constants.
Use them when available.
When the game-loop is very slow, it was easily possible to start
the loop with _shift_pressed being false, but end with
_shift_pressed being true. This doesn't hurt the game as such,
but for the user this can be very weird: I pressed "Buy Vehicle",
pressed shift a bit later, and I still get a cost indication.
Creating a thread was not thread-safe. The irony.
The video-driver has a function GameLoopPause() which first checks
if the thread is the game-thread or not. For this it needs access
to this->game_thread. This variable is set in StartNewThread().
However, due to timing, it is well possible GameLoopPause() is
called from the thread well before this->game_thread is assigned.
And so we have a race-condition!
Simply solve this by preventing a thread to start till we are
done with our bookkeeping.
This makes it easier to spot chunks that have a save_proc that
is a nullptr, but also prevents confusion, where it looks like
the CH_ type of a chunk has influence on how it is being read.
It is not, it is only used for saving.
Basically it is very similar to Vehicles, where there first is
a type field, followed by data of that type. So this commit makes
it looks like how Vehicles solved that.
This removes a lot of custom "keeping track of length" stuff.
This adds two byte extra to those chunks, and might feel a bit
silly at first. But in later changes we will prefix CH_ARRAY with
a table header, and then this change shines.
Without this, we could still add headers to these chunks, but any
external reader wouldn't know if the CH_RIFF has them or not. This
way is much more practical, as they are now more like any other
chunk.
This means that during loading we can validate that what is saved
is also that what is expected. Additionally, this makes all list
types similar to how they are stored on disk:
First a gamma to indicate length, followed by the data.
The size still depends on the type.
In the end, the code was already doing the right thing, but a few
functions deep, and not really obvious. When validating what objects
can handle SLE_VAR_NULL, it is nicer to just have this obvious.
Using SL_ARR for this gives us a bit of trouble later on, where we
add a length-field to SL_ARR. This of course is not the intention
of SLE_CONDNULL. So better seperate it.
The current SaveLoad is a bit inconsistent how long a length field
is. Sometimes it is a 32bit, sometimes a gamma. Make it consistent
across the board by making them all gammas.
This helps external tooling to understand if a SL_STRUCT should
be skipped when reading. Basically, this transforms an SL_STRUCT
into a SL_STRUCTLIST with either 0 or 1 length.
This wasn't consistently done, and often variables were used that
were read by an earlier blob. By moving it next to the struct
itself, the code becomes a bit more self-contained and easier to
read.
Additionally, this allows for external tooling to know how many
structs to expect, instead of having to know where to find the
length-field or a hard-coded value that can change at any moment.
There was a lot of code duplication for no real reason. Now with
SLEG_STRUCT support, we can just re-use the code, hopefully making
it easier for future-us to make changes to this, without breaking
everything for old games.
With the new SLEG_STRUCT it is much easier to embed a struct
in a struct, where the sub-struct has limitations on when it is
being used.
This makes both the code easier to read (less magic) and avoids
the SaveLoad needing to know all these things about Stations
and Vehicles.
The commits following this will use this new functionality.
Currently, a few places do this manually. This has as drawback that
the Save() and Load() code need to be in sync, and that any change
can result in (old) savegames no longer loading. In general, it is
annoying code to maintain.
By putting everything in a description table, and use that for
both Save() and Load(), it becomes easier to see what is going on,
and hopefully less likely for people to make mistakes.
Both did not support format parameters, so in many places IConsolePrint(CC_ERROR, "message") was used with a style different from what IConsoleError would do.
If a command cannot be executed for whatever reason, it makes no sense to call it a warning. Something has been done wrong.
Also make writing of these error message consistent while changing their "type".
This may change behaviour when multiple loading/loaded stages are provided, as the various copies checked in different orders, however only one result is expected in these cases anyway.
This is extreme useful for automated testing. Without this, OpenTTD
will always look in your personal-dir (like ~/.local/share/openttd
or %USER%\Documents\OpenTTD). For most users this is exactly what
we want, that there is a shared place for all their files.
However, for automated testing this is rather annoying, as your
local development files influence the automated test. As such,
'-X' counters this, and only gives the local folders. This is
especially useful in combination with '-x' and '-c'.
You can easily mistake SlList / SL_LST to be a list of SL_VAR, but
it is a list of SL_REF. With this rename, it hopefully saves a few
people from "wtf?" moments.
Prepare the full description and send it to SlObject. This does
require some code to be able to read to a SLE_VAR_NULL, like strings
etc, as there is no way to know their length beforehand.
It was rather confusing which one was for what, especially as some
SaveLoad flags were settings-only. Clean up this mess a bit by
having only Setting flags.
It is a lovely organicly grown enum, where it started off with
GUI-only flags, and after that a few flags got added that can be
considered GUI-only (the GUI disables/enables based on them), to
only have flags added that has nothing to do with the GUI.
So be less confusing, and rename them to what they do.
Additionally, I took this opportunity to rename 0ISDISABLED to
reflect what it really does.
Basically, this changes "SaveLoad *" to either:
1) "SaveLoadTable" if a list of SaveLoads was meant
2) "SaveLoad &" if a single entry was meant
As added bonus, this removes SL_END / SLE_END / SLEG_END. This
also adds core/span.hpp, a "std::span"-lite.
This is mostly done as there are now constraints on settings.ini you might not
expected. For example, conditional settings always have to come last, as otherwise
they would influence the index.
YAPF could end up in a situation where it sets the best intermediate node
to a node whose construction is never finalized (i.e. it is never added to
the open list). The content of the node would be overwritten in the next
round, potentially sending the vehicle to an unwanted location.
When you buy-out a company, you got your shares back. This is
based on company-value, which includes values for the vehicles etc.
In other words, you not only got the vehicles, but you also got
paid to get them back.
Additionally, you also got the loan of the company, but not the
money for the loan (as that is subtracted from the company-value).
Solve this by changing the rules of a buy-out: don't sell your
shares, get the loan AND the balance and get the infrastructure.
The comments for SettingDescType; it is a byte, so not 4 bytes and since it is not a flag there are about 250 other possibilities left instead of 9.
SettingGuiFlag is uint16 so has 2 bytes allocated.
SettingDescGlobVarList and related comments imply that global vars cannot be used elsewhere, but they are used for settings just fine. Even then the type is not used anywhere else but the definition of the table.
This to prevent the default copy-assignment getting used when during the assignment also some other memory needs to be allocated as that would otherwise be freed.
Division by resize_y is already yielding an unsigned number, so when clicking in the WD_FRAMERECT_TOP you would already get a huge value, so sel would never be negative. So, leave sel an unsigned number and remove the <= check.
Due to 47a99bb the order of elements in the garbage collection chain has
changed causing the class to be finalised before the instances of that class.
Since the instance's array of member values depends on the size of the values
in the class, the class finalisation resetting that size to 0 causes not all
finalisations to run, which subsequently causes a heap use after free. So,
just set the SQObjectPtrs to 'null' during the finalisation of the SQClass
so the SQInstance can release all instance variables during its finalisation.
Practically the length of the handlers not being equal to the number of
features is the problem as it means something was forgotten when adding
a new feature, so static assert to that and let the existing check on
the feature number take care of invalid data from the NewGRFs.
Functions like localtime, gmtime and asctime are not thread safe as they (might) reuse the same buffer. So use the safer _s/_r variant for localtime and gmtime, and use strftime in favour of asctime.
This ensures that default vehicles can transport any NewGRF defined cargos, albeit with weird graphics and vehicle names.
This also changes the refittability of default vehicles with default industries.
Default vehicles now behave as if they had a cargo translation table. This fixes default vehicles carrying seemingly random cargos, if NewGRF industry sets are present.
This behavior is disabled, when a NewGRF touches any of the cargo-type or refitting properties. In that case it's up to the NewGRF to define its own cargo translation table.
* Codechange: [Network] split CloseSocket and CloseConnection more clearly
- CloseSocket now closes the actual OS socket.
- CloseConnection frees up the resources to just before CloseSocket.
- dtors call CloseSocket / CloseConnection where needed.
Susz is masculine, not neuter, so it should result in "Susz Mazowiecki",
"Susz Morski", and not "Susz Mazowieckie" or "Susz Morskie". However,
because order of the names whould not be changed, it was replaced with
Leszno, which is neuter.
In the destructors of many of the network related classes Close() is called, just like the
top class in that hierarchy. However, due to virtual functions getting resolved statically
in the destructor it would always call the empty Close() of the top class.
Document the other cases where a virtual call is resolved statically.
This as during construction the sub class has not been initialized yet, and
during destruction the sub class has already been destroyed, so the overriding
virtual function would be accessing uninitialized data.
This also changes ScriptEventVehicleAutoReplaced when replacing wagons:
The event is now only spawned, if the head engine changes, so only if the VehicleID of the consist changes.
Previously replacing wagons spawned an event with OldVehicleID==NewVehicleID.
This means that random tree generation density is higher on small maps and lower on large maps. This difference is enough to make the Lumber Mill impractical to use on large maps.
This change skips ticks on maps smaller than 256x256 and increases iterations or shortens the interval on maps larger than 256x256.
It now follows very simple rules:
0 - Fatal, user should know about this
1 - Error, but we are recovering
2 - Warning, wrong but okay if you don't know
3 - Info, information you might care about
4 -
5 - Debug #1 - High level debug messages
6 - Debug #2 - Low level debug messages
7 - Trace information
The code mixed up "client has quit but we already told everyone"
with "client lost connection, handle this".
Split up those two signals:
- CLIENT_QUIT means we told everyone and the connection is now dead
- CONNECTION_LIST means we should tell everyone we lost a client
The function fluid_player_join in the library is broken beyond compare for the
usecases it was used for (see their #872). It does not wait until it is safe
to delete the player, so it is up to the end user to ensure that.
For OpenTTD we acquire a lock before fluid_synth_write_s16 and we acquire the
same lock in the stop function. So, only one of the functions can be doing its
thing, meaning we do not need to wait for the player to be stopped as it
cannot be doing anything as we prevent that by the lock.
Since pixel dimensions in SetPadding() are scaled by GUI size, padding for inset viewports was excessive.
Instead, automatically apply padding for WWT_INSET at widget level. This applies to all widgets inside a WWT_INSET, which in all instances is a NWID_VIEWPORT.
This meant that on opening the Multiplayer window, if you had more
than one server configured, it would one by one cancel all pending
queries and send a new. Result: only the last server was updated.
The most common case never needs access to it anymore. Make the
one exception to this explicit. This means the fact that we
store it is now an implementation detail.
If the highscore/news window panel size, which is now scaled by GUI zoom, is larger than the screen size, a loop will be entered where the window is repeatedly resized.
This is resolved by removing the minimal size from the panel, as the window is always resized to cover the screen anyway. This means the screen size can never be too small.
Hostnames like "content.openttd.org" resolve into multiple IPv4 and IPv6.
It is possible that either of the IPs is not working, either due to
a poorly configured OS (having IPv6 but no valid route), broken network
paths, or a service that is temporary unavailable.
Instead of trying the IPs one by one, waiting for a 3s timeout between
each, be a bit more like browsers, and stack attempts on top of each
other with slight delays. This is called Happy Eyebells.
Initially, try the first IPv6 address. If within 250ms there is no
connection yet, try the first IPv4 address. 250ms later, try the
second IPv6 address, etc, till all addresses are tried.
If any connection is created, abort all the other (pending) connections
and use the one that is created. If all fail 3s after the last connect(),
trigger a timeout for all.
We now resolve the connection_string to a NetworkAddress in a much
later state. This means there are fewer places constructing a NetworkAddress.
The main benefit of this is in later PRs that introduce different types
of NetworkAddresses. Storing this in things like NetworkGameList is
rather complex, especially as NetworkAddress has to be mutable at all
times.
Additionally, the NetworkAddress is a complex object to store simple
information: how to connect to this server.
Split the updating in a "static" version that only needs to be called when a new map is loaded or some settings are changed, and a "dynamic" version that updates everything that changes regularly such as the current game date or the number of spectators.
english (us): 1 change by 2TallTyler
estonian: 49 changes by siimsoni
korean: 1 change by telk5093
hungarian: 45 changes by baliball
finnish: 12 changes by hpiirai
spanish: 1 change by JohnBoyFan
In FluidSynth 2.2.0 an extra state was added to denote stopping. To transition
from this state to a stopped state the rendering needs to be running. Since
04ce1f07 locking was added that skipped the rendering when something else held
a lock, so the state would never get to stopped and join would never return.
This avoids the need to custom memory management and additional members.
This also resolves use-after-free if modifying copied layouts, so presumably nobody has ever done that.
Under normal circumstances the server's ID is 32 characters excluding '\0', however this can be changed at the server. This ID is sent to the server for company name hashing. The client reads it into a statically allocated buffer of 33 bytes, but fills only the bytes it received from the server. However, the hash assumes all 33 bytes are set, thus potentially reading uninitialized data, or a part of the server ID of a previous game in the hashing routine.
It is still reading from memory assigned to the server ID, so nothing bad happens, except that company passwords might not work correctly.
If a viewport sign straddles the top of a viewport, a crash will occur if the viewport height is zero. This is resolved by simply not attempting to draw the viewport in this situation, consistent with other widgets.
Previously noted by a comment, this does not need to be guarded against as non-powers of 2 will not cause issues beyond the choice of results being reduced.
One could join a network game from within an already running network game. This would call a NetworkDisconnect, but keeps the UI alive. If, during that process the join is aborted, e.g. by cancelling on a password dialog, you would still be in your network game but also get shown the server list.
Solve all the underlying problems by falling back to the main UI when (re)connecting to a(nother) server.
Scaling is not expensive, but it does not change either, and this avoids the need for a virtual method call. This cascades back to all GetCharacterHeight(FS_xxx) and FONT_HEIGHT_xxx calls.
Replaces constant pixel values with values scaled based on font size.
This allows the industry chain to maintain a consistent look across
different sizes. Previously all except cargo line height were fixed.
YAPF was constantly measuring its performance, but only at
certain debug-levels this information was shown.
Now after years, I sincerely wonder if anyone still knows about this
feature and who still use it. Especially with the new framerate window,
this detailed performance is not as meaningful anymore as it once
was.
This means that pressing Refresh button and adding servers manually
now uses TCP.
The master-server and initial scan are still UDP as they will be
replaced by Game Coordinator; no need to change this now.
If we query a server that is too old, show a proper warning to the
user informing him the server is too old.
In case a character was encoded in multiple bytes, but required fewer bytes to be encoded, the first byte would be copied to the output leaving an invalid Utf8 encoded string. Later uses of the validated string would use the same decode logic, which would yield a question mark and just read a single byte, so nothing dangerous happened.
Furthermore, because the next byte would not be a first byte of an encoded Utf8 character, the last few valid characters could be removed by the validation as well.
* Fix: 'Cache' top and bottom lines of textfile viewer to avoid overdraw.
The text file viewer calculated the number of lines required to set the scrollbar, but did not retain this information, so this was recalculated on every draw operation. This includes overdrawing text outside the bounds of the current scroll position.
With this change the top and bottom lines for each line of text are remembered, and reflowing is avoided where possible. Text outside the current scroll bounds is not drawn.
Additionally the scroll interval is now based on text lines instead of pixel lines, which increases the text capacity depending on the font size.
* Fix: Limit text viewer to showing 64k lines.
Text files with more than 64k wrapped lines would exceed the scrollbar capacity and cause an assert. This is harder to reach now that the scrollbar counts lines instead of pixels.
This happens if the bounding dimensions are changed so that each item is the same size, as happens on the railtype/roadtype dropdown lists, as the vertical offset was calculated before this dimension is changed.
The idea is that if you query an older server that does not support
this packet yet, the client receives an error. The assumption was
that on every "illegal packet" the connection would be closed. This
turns out to be false.
Now CLIENT_GAME_INFO aligns with the old PACKET_CLIENT_NEWGRFS_CHECKED,
which does a pre-check (which fails), and an error is sent back
and the connection is closed.
This is not a nice solution, but it is the best we got.
spanish (mexican): 40 changes by absay
english (us): 1 change by 2TallTyler
korean: 3 changes by telk5093
german: 1 change by danidoedel
finnish: 1 change by hpiirai
catalan: 1 change by J0anJosep
portuguese: 45 changes by azulcosta
portuguese (brazilian): 44 changes by Vimerum
The lobby of a server requested some parts via UDP and some via
TCP. This is strictly seen fine, but for future extensions it
is a lot easier if just one protocol is used.
Currently we use default OS timeout for TCP connections, which
is around 30s. 99% of the users will never notice this, but there
are a few cases where this is an issue:
- If you have a broken IPv6 connection, using Content Service is
first tried over IPv6. Only after 30s it times out and tries
IPv4. Nobody is waiting for that 30s.
- Upcoming STUN support has several methods of establishing a
connection between client and server. This requires feedback
from connect() to know if any method worked (they have to be
tried one by one). With 30s, this would take a very long time.
What is good to mention, is that there is no good value here. Any
value will have edge-cases where the experience is suboptimal. But
with 3s we support most of the stable connections, and if it fails,
the user can just retry. On the other side of the spectrum, with 30s,
it means the user has no possibility to use the service. So worst case
we annoy a few users with them having the retry vs annoying a few
users which have no means of resolving the situation.
They are likely not working as expected on Windows, so prevent their usage.
Winsock does not set errno and strerror does not return anything useful for Winsock error numbers.
english (us): 39 changes by 2TallTyler
korean: 44 changes by telk5093
german: 43 changes by danidoedel
russian: 7 changes by Ln-Wolf
finnish: 39 changes by hpiirai
norwegian (bokmal): 4 changes by Anolitt
spanish (mexican): 3 changes by absay
japanese: 60 changes by scabtert, 38 changes by Azusa257
english (us): 3 changes by 2TallTyler
korean: 3 changes by telk5093
russian: 4 changes by Ln-Wolf
finnish: 3 changes by hpiirai
slovak: 20 changes by FuryPapaya
NewGRF spec says that base payment rate is 32 bits, but it was loaded into a 16 bit variable. This value is loaded into Money variable after inflation is applied.
Especially if there are many players online, trying to chat with
the right one can be a visual challenge. This can be solved by
highlighting the row you are on. This visual cue is often enough
for humans to find the right row.
The GUI now more clearly shows some basic information about the
server you joined, your client name (and the ability to change it),
and what players are in which company.
It also contains useful buttons to press to join companies, chat
with other people, and for admins to kick/ban people.
Additionally, renamed "advertised" to "visibility"; this has to
do with future additions, but also because it is more clear in
wording.
korean: 2 changes by telk5093
russian: 3 changes by Ln-Wolf
finnish: 1 change by hpiirai
spanish: 1 change by MontyMontana
polish: 1 change by pAter-exe
hindi: 62 changes by ss141309
* Codechange: Use std::string in console commands and aliases registration
* Codechange: Use std::map to register console commands
* Codechange: Use std::map to register console aliases
* Cleanup: Remove now unused function
This so names from other clients are known valid in the client as well, instead allowing some compromised/bad server to potentially crash clients upon certain expectations.
Unfinished translations are not auto-picked from the locale.
In release builds, unfinished translations are not offered in the GUI.
Unfinished translations are available in non-release builds, or by editing openttd.cfg.
Minigraphs did not adjust size to accomodate large text, either by font size or font zoom, leading to cropped labels.
Minigraphs and spacing are now scaled by font zoom, as this seems to behave better than gui zoom in this instance.
Line height defaults to the resize height of the relevant widget, which is
set in all cases. Therefore it is not necessary to specify this value every time.
Additionally fixes scrolled padding for the framerate window.
This struct is defined in geometry_type but not used by any geometry-related
code, only for subsidy code where both parameters are cast from int to
NewsReferenceType.
Strictly seen the comment is true, as it says 'e.g.', but it is
misleading. The server name is just that: the name of the server
as configured. No need to mention advertising.
When ever you saw this debug lines (which you never should), they
showed an empty address. It is also not very useful to have, as it
always points to a known server anyway.
The original idea was that people could find a server they could
talk in their native language on. This isn't really used in that
way. There are several reasons for removing this:
- the client also sends his "language" to the server, but nothing
is doing anything with this.
- flags are a bad way to represent languages, and over the years
we had several (rightfully) complaints about this.
- most servers have their language set to "All", and prefix the
servername with the language it is about. This is a much more
efficient way to do the same.
All in all, this feature should go back to the drawing board.
Maybe it could work in another form, but this form is not it.
The idea back in the days was nice, but it never resulted in
anything useful. Most servers either read "(loaded game)" or
"Random Map", neither being useful. It was meant for heightmaps,
so you could find a server that was using a specific one .. but
there are many things wrong with that idea. Mostly, servers tend
to save and load savegames from time to time, after which the
original heightmap used was lost.
All in all, removing map_name all together is just better.
Existing layout included a blank widget above the group list to align with the vehicle list, however since then an additional sort-by row was added.
Group list size tweaks to match normal row size (at least with normal gui and text size.)
Removed reduction of 2 rows in the group list <- main culprit of odd sizing.
Removed fill attribute on buttons which gave strange sizes, and put it on the group info widget instead.
Tweaked various soft-padding values to line up (centreing text with a 1px offset does not make centred text.)
The server information panel was scaled by GUI scale, which could result in a panel that is longer than the server list. This height difference is then maintained when the window is resized to fill the screen.
Instead, specify the minimum size by number of text lines and (summed total) padding.
norwegian (bokmal): 2 changes by Anolitt
english (us): 2 changes by 2TallTyler
korean: 3 changes by telk5093
german: 2 changes by danidoedel
romanian: 35 changes by kneekoo
finnish: 2 changes by hpiirai
spanish: 4 changes by MontyMontana
french: 3 changes by glx22
portuguese: 4 changes by azulcosta
"Hardware acceleration" was not aligned with its checkbox. So instead
of drawing the labels left and the options right, now draw settings
one by one with a spacer between label and option to get the right
spacing.
Also, use SetPIP instead of repeating a SetPadding for all but
last element.
Vsync should be off by default, as for most players it will be
better to play without vsync. Exception exist, mainly people who
play in fullscreen mode.
An invalid starting year causes all sorts of weird behaviour and crashes in map generation.
Now just set the appropriate setting via IConsoleSetSetting so the validation
and, if needed, clamping is performed on the starting year value.
Font glyphs between 33 and 39 pixels wide, in the Win32 font system, used wrong alignment and caused glyphs to appear broken.
When in the 33 to 39 pixel range, glyphs without AA were rounded down to 32 pixel pitch, instead of up to 64 pixel pitch.
Handle printable input only when the matching WM_CHAR message is incoming.
Without an edit box, do the handling in keydown as usual to support hotkeys.
english (us): 3 changes by 2TallTyler
korean: 3 changes by telk5093
russian: 32 changes by Ln-Wolf
spanish: 1 change by JohnBoyFan
french: 4 changes by arikover
portuguese: 10 changes by azulcosta
Debian now provides a default soundfont for FluidSynth via its alternatives system.
In short, FluidSynth is configured to look for `/usr/share/sounds/sf3/default-GM.sf3` as its default soundfont, and each soundfront package (FluidR3, OPL-3, MuseScore...) may provide or override this symlink. By default, FluidSynth is installed on Debian with the `TimGM6mb` soundfont by default due to its limited size.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929185 for further details.
Use status >= STATUS_AUTHORIZED as the state criteria for all cases
where updates about other clients are sent.
This avoids the case where a client is informed that another client
has joined but not informed when it later quits, resulting in
stale entries in the client list window.
Clamping each sample value to half the available range could cause
unnecessary premature clipping with lots of sounds playing. This change
does not affect the actual volume level.
swedish: 1 change by DonaldDuck313
norwegian (bokmal): 1 change by Anolitt
english (us): 1 change by 2TallTyler
chinese (simplified): 8 changes by RichardYan314
german: 1 change by danidoedel
romanian: 115 changes by kneekoo
finnish: 1 change by hpiirai
spanish: 2 changes by MontyMontana
polish: 3 changes by yazalo
The 6th is "is-stable-tag", but it is currently broken in meaning.
Betas and RCs are considered "stable", but final releases are not.
This is the reason it was working for RC1, but not for the final
release.
english (us): 23 changes by 2TallTyler
luxembourgish: 63 changes by phreeze83
ukrainian: 72 changes by StepanIvasyn
catalan: 5 changes by J0anJosep
turkish: 5 changes by nullaf
english (us): 7 changes by HAJDog247
czech: 18 changes by PatrikSamuelTauchim
luxembourgish: 99 changes by phreeze83
serbian: 4 changes by nkrs
catalan: 20 changes by J0anJosep
french: 1 change by arikover
portuguese: 30 changes by azulcosta
swedish: 30 changes by kustridaren
spanish (mexican): 1 change by absay
japanese: 13 changes by Azusa257
vietnamese: 1 change by KhoiCanDev
estonian: 12 changes by siimsoni
czech: 6 changes by PatrikSamuelTauchim, 2 changes by tomas-vl
chinese (simplified): 88 changes by clzls
arabic (egypt): 16 changes by AviationGamerX
luxembourgish: 4 changes by phreeze83
korean: 34 changes by telk5093
italian: 16 changes by AlphaJack
german: 1 change by danidoedel, 1 change by Wuzzy2
slovak: 30 changes by FuryPapaya
catalan: 35 changes by J0anJosep
tamil: 16 changes by Aswn
dutch: 32 changes by Afoklala
portuguese (brazilian): 14 changes by Greavez, 5 changes by jpsl00
Before this commit, it scaled to map-height-limit. Recently this
could also be set to "auto", meaning players don't really know
or care about this value.
This also means that if a player exported a heightmap and wanted
to import it again, looking like the exact same map, he did not
know what value for "highest peak" to use.
This opens up the true power of the TGP terrain generator, as it
is no longer constrainted by an arbitrary low map height limit,
especially for extreme terrain types.
In other words: on a 1kx1k map with "Alpinist" terrain type, the
map is now really hilly with default settings.
People can still manually limit the map height if they so wish,
and after the terrain generation the limit is stored in the
savegame as if the user set it.
Cheats still allow you to change this value.
This better reflects what it is, and hopefully removes a bit of
the confusion people are having what this setting actually does.
Additionally, update the text on the setting to better inform
users what it is doing exactly, so they can make an educated
decision on how to change it.
Next commit will introduce an "auto" value, which should be the
new default. The rename has as added benefit that everyone will
start out on the "auto" value.
This setting influence the max heightlevel, and not as the name
suggests: the height of the generated map.
How ever you slice it, it is a very weird place to add this
setting, and it is better off being only in the settings menu.
Commits following this commit also make it more useful, so users
no longer have to care about it.
This is an indication value; the game tries to get as close as it
can, but due to the complex tropic rules, that is unlikely to be
exact.
In the end, it picks a height-level to base the desert/tropic
line on. This is strictly seen not needed, as we can convert any
tile to either. But it is the simplest way to get started with
this without redoing all related functions.
Setting the snow coverage (in % of the map) makes a lot more sense
to the human, while still allowing the niche player to set (by
finding the correct %) a snow line height they like. This makes for
easier defaults, as it decoupled terrain height from amount of snow.
Maps can never be 100% snow, as we do not have sprites for coastal
tiles.
Internally, this calculates the best snow line height to approach
this coverage as close as possible.
This used to work by accident: originally the code checked if
GenerateWorld was threaded. If not, it would abort the function.
This worked for placing trees, because it was also returning false
when it was not active.
With the recent changes, that check got removed, and this crash
started to happen. So now check if we have a modal window, which
is a very solid indication we are generating the world.
chinese (simplified): 2 changes by clzls
korean: 2 changes by telk5093
slovak: 9 changes by FuryPapaya
catalan: 4 changes by J0anJosep
polish: 4 changes by pAter-exe
swedish: 1 change by kustridaren
estonian: 1 change by siimsoni
russian: 5 changes by Ln-Wolf, 3 changes by SecretIdetity
ukrainian: 7 changes by StepanIvasyn
lithuanian: 31 changes by devbotas
portuguese: 54 changes by azulcosta
english (us): 8 changes by 2TallTyler
estonian: 16 changes by siimsoni
korean: 5 changes by telk5093
italian: 32 changes by AlphaJack
german: 5 changes by Wuzzy2
danish: 15 changes by achton
lithuanian: 89 changes by devbotas
spanish: 3 changes by MontyMontana
french: 8 changes by arikover
portuguese (brazilian): 3 changes by Greavez
polish: 17 changes by yazalo, 2 changes by pAter-exe
For example, if you have a config that defines OpenGFX as baseset
but for some reason you have no basesets anymore. In that case
bootstrap downloads OpenGFX for you, but it will still show the
error that "OpenGFX was not found" after the bootstrap. This was
an error generated before the bootstrapped kicked in.
Simply muting all errors during bootstrap solves this; as we cannot
show them anyway, this is fine. Any errors that remain after
bootstrap will be generated again anyway.
There are various of ways bootstrap can fail:
- Failing network connection
- Incomplete download
- No write permissions
- Disk full
- (others I forgot)
They all result in a screen with no windows. To ensure we at least
always show something when anything bad happens, if the bootstrap
is not successful, show a screen what the next step for the human
should be.
english (us): 7 changes by 2TallTyler
estonian: 17 changes by siimsoni
hungarian: 100 changes by pnpBrumi
ukrainian: 8 changes by StepanIvasyn
dutch: 24 changes by Afoklala
spanish: 338 changes by MontyMontana
french: 29 changes by MalaGaM
portuguese (brazilian): 1 change by Greavez
This means if you execute a script from a script from a script, ..
for more than 10 times, it bails out now. This should be sufficient
for even the most complex scripts.
MaskWireBits always returns its input unchanged if the input
has only 0 or 1 track bits set.
Having only 0 or 1 track bits sets (i.e. non junction tiles)
is by far the most common case.
Examining the state of neighbouring tiles and the subsequent
masking logic is relatively expensive and can be omitted in this case.
It didn't sit well to me, how I wrote the commit initially. First
casting a variable into another, only to write it back into the
originally feels wrong.
This flow makes a bit more sense to me.
Otherwise that might cause calls to the video-driver, which are
already shut down by now. This causes, depending on the video-driver
crashes or weird effects.
Basically, modal windows had their own thread-locking for what
drawing was possible. This is a bit nonsense now we have a
game-thread. And it makes much more sense to do things like
NewGRFScan and GenerateWorld in the game-thread, and not in a
thread next to the game-thread.
This commit changes that: it removes the threads for NewGRFScan
and GenerateWorld, and just runs the code in the game-thread.
On regular intervals it allows the draw-thread to do a tick,
which gives a much smoother look and feel.
It does slow down NewGRFScan and GenerateWorld ever so slightly
as it spends more time on drawing. But the slowdown is not
measureable on my machines (with 700+ NewGRFs / 4kx4k map and
a Debug build).
Running without a game-thread means NewGRFScan and GenerateWorld
are now blocking.
gui_zoom was never clamp'd between zoom_min/zoom_max.
zoom_min controls how zoomed-in we load sprites. For a value of 1,
no quad-sizes sprites are loaded. If gui_zoom would be 0, meaning
it wants quad-sized sprites to display, it was printing random
stuff to the screen, which could or could not result in crashes.
Otherwise both the draw-thread and game-thread can do it both
at the same time, which gives rather unwanted side-effects.
Calling it from the draw-thread alone is sufficient, as we just
want to create some unpredictable randomness for the player. The
draw-thread is a lot more active (normally) than the game-thread,
so it is the best place of the two to do this.
Additionally, InteractiveRandom() mostly has to do with visuals
that are client-side-only, so more related to drawing than to
game.
v->tile for aircrafts is always zero when in the air. Only when
it starts its landing (or take-off) patterns it becomes a sane
value.
So instead, base the news on the last x/y coordinates of the plane.
english (us): 18 changes by 2TallTyler
korean: 17 changes by telk5093
german: 13 changes by danidoedel, 4 changes by Wuzzy2
finnish: 17 changes by hpiirai
catalan: 17 changes by J0anJosep
lithuanian: 33 changes by devbotas
spanish: 17 changes by MontyMontana
portuguese (brazilian): 20 changes by Greavez
polish: 9 changes by yazalo
This because video-drivers might need to make changes to their
context, which for most video-drivers has to be done in the same
thread as the window was created; main thread in our case.
This allows drawing to happen while the GameLoop is doing an
iteration too.
Sadly, not much drawing currently can be done while the GameLoop
is running, as for example PollEvent() or UpdateWindows() can
influence the game-state. As such, they first need to acquire a
lock on the game-state before they can be called.
Currently, the main advantage is the time spend in Paint(), which
for non-OpenGL drivers can be a few milliseconds. For OpenGL this
is more like 0.05 milliseconds; in these instances this change
doesn't add any benefits for now.
This is an alternative to the former "draw-thread", which moved
the drawing in a thread for some OSes. It has similar performance
gain as this does, although this implementation allows for more
finer control over what suffers when the GameLoop takes too
long: drawing or the next GameLoop. For now they both suffer
equally.
Drawing in a thread is a bit odd, and often leads to surprising
issues. For example, OpenGL would only allow it if you move the
full context to the thread. Which is not always easily done on
all OSes.
In general, the advise is to handle system events and drawing
from the main thread, and do everything else in other threads.
So, let's be more like other games.
Additionally, putting the drawing routine in a thread was only
done for a few targets.
Upcoming commit will move the GameLoop in a thread, which will
work for all targets.
The video drivers using the OpenGL backend are currently our only
accelerated drivers. The options defaults to off for macOS builds and
to on everywhere else.
Co-authored-by: Michael Lutz <michi@icosahedron.de>
chinese (traditional): 5 changes by benny30111
estonian: 1 change by siimsoni
italian: 1 change by AlphaJack
ukrainian: 4 changes by StepanIvasyn
tamil: 37 changes by Aswn
portuguese (brazilian): 19 changes by Greavez
Reworked how the screenshot command works while keeping it backwards
compatible. It can now more freely understand arguments, and has
the ability to make SC_DEFAULTZOOM screenshots.
In other words, it should only (!) return true if A comes for B.
This promise was broken for the situation where two values are
identical. It would return true in these cases too. This is of
course not possible: if two values are identical, neither come
before the other. As such, the sorter was not imposing strict
weak ordering relations.
libstdc++ handled this scenario just fine, but libc++ crashes
badly on this, as it allowed comparing of [begin, end] instead
of [begin, end).
libc++ considered this not a bug (and by specs, they are correct;
just this way of crashing is of course a bit harsh):
https://bugs.llvm.org/show_bug.cgi?id=47903
In other words, it should only (!) return true if A comes for B.
This promise was broken for the situation where two values are
identical. It would return true in these cases too. This is of
course not possible: if two values are identical, neither come
before the other. As such, the sorter was not imposing strict
weak ordering relations.
libstdc++ handled this scenario just fine, but libc++ crashes
badly on this, as it allowed comparing of [begin, end] instead
of [begin, end).
libc++ considered this not a bug (and by specs, they are correct;
just this way of crashing is of course a bit harsh):
https://bugs.llvm.org/show_bug.cgi?id=47903
english (us): 4 changes by 2TallTyler
italian: 4 changes by troccoli
serbian: 251 changes by nkrs
german: 6 changes by ebla71, 2 changes by Wuzzy2
romanian: 3 changes by ALEX11BR
russian: 11 changes by Ln-Wolf
ukrainian: 2 changes by StepanIvasyn
lithuanian: 15 changes by devbotas
spanish: 2 changes by perezdidac
The bootstrap has the _switch_mode to SM_MENU, and never leaves
this mode. Neither is it considered a modal window (while in some
sense it really is). So .. we need to add another "draw anyway"
exception, to make sure bootstrap is being drawn.
When you are downloading a map, all the commands are queued up
for you. Clients joining/leaving is done by the network protocol,
and as such are processed immediately. This means that by the
time you are processing the commands, a client that triggered
it, might already have left.
So, all commands that do something with ClientID, shouldn't
error on an invalid ClientID when DC_EXEC is set, but
gracefully handle the command anyway, to make sure the
game-state is kept in sync with all the clients that did
execute the DoCommand while the now-gone client was still
there.
Additionally, in the small chance a client disconnects between
the server validating a DoCommand and the command being
executed, also just process the command as if the client was
still there. Otherwise, lag or latency can cause clients that
did not receive the disconnect yet to desync.
Strictly seen, there are "N" people -waiting- in front of you
in the queue, but it is nicer to show "N + 1" for the person that
is currently downloading the map. Avoids it showing:
"0 clients in front of you". That just feels a bit off.
swedish: 60 changes by kustridaren
norwegian (bokmal): 12 changes by buzzCraft
czech: 82 changes by PatrikSamuelTauchim, 1 change by tomas-vl
italian: 86 changes by AlphaJack, 9 changes by federico1564S
german: 16 changes by ebla71
romanian: 10 changes by ALEX11BR
ukrainian: 3 changes by StepanIvasyn
spanish: 1 change by MontyMontana
Although for developers this doesn't change anything, for our
linux-generic binary it changes everything. Without this, the
OpenGL dynamic library is dragged in as dependency, and as it
depends on X11, that will be dragged in too. This is not
something we prefer to have, as that won't run on as many
machines as it could.
SDL2 doesn't depend on OpenGL directly, as it tries to load it
in on runtime. If found, it would work in exactly the same way
as if we would link to OpenGL ourselves. As such, this is
the best of both worlds: our linux-generics have less linked
dependencies, and developers won't notice any difference.
As a side-effect, if someone uses linux-generic on a machine
that does not have any OpenGL package installed, it will
gracefully fall back to the default backend of SDL instead.
SendError() notifies all clients of the disconnect. This calls
CloseConnection() at the end, which also notified the clients
of the disconnect. Really no need to do it twice.
The status NETWORK_RECV_STATUS_SERVER_ERROR is only set by
SendError(), so in case that is the status, don't let
ClientConnection() send another notification.
CheckCompanyHasMoney() was also executed when not using DC_EXEC,
resulting in an error about shortage of money instead of the
estimation.
This mostly is a problem for AI players, as they will have no
way to know how much it would have cost.
Basically, follow_track.hpp contains a fix for half-tiles, but
this wasn't duplicated for when trying to find a depot and in
a few other places. This makes sure all places act the same.
MainLoop() is used to bootstrap OSX, where later a callback is
done to GameLoop() to execute OpenTTD. All other video drivers
don't need that, so what is in GameLoop is in MainLoop for all
other drivers. This is rather confusing. So, instead, name
GameLoop MainLoopReal to be more in sync with the other drivers.
This makes it a bit easier to follow what is going on, and
allow future subdrivers to hook into a few of these functions.
Reworked the code slighly while at it, to return early where
possible.
When we clip the region that is only been redrawn, something
weird happens on Windows. When pushing 60 frames per second on a
60Hz monitor, it appears that the clipped region is often shown
of another frame, instead of the current.
Examples of this are:
- pause the game, move your mouse to the left, and at the right
speed it totally disappears.
- fast aircrafts seem to be in several places at once, weirdly
lagging behind.
- in title screen, moving your mouse gives you the idea it is
jumping places, instead of smooth movements.
In the end, if you do nothing, everything is correct, so it is
eventually consistent. Just when we are firing many BitBlt in
a clipped region, the in-between is not.
What goes wrong exactly, I honestly do not know. On every frame
that we push to the DC is a mouse painted, but visually it
sometimes appears like it is not. Recording with external software
shows it really is there.
It is also not our eyes playing tricks on us, as the first example
makes it really clear the mouse pointer really is not painted.
And to be clear, with the mouse this is easiest reproduceable,
as high-speed objects are influences by this most. But this happens
for all movement that redraws small regions.
Either way, not using clipped regions resolves the issue completely,
and there appears to be little to no penalty (I failed to measure
any impact of drawing the full screen). So better have a good game
than fast code, I guess?
When drawing an 8bpp screen buffer, palette resolving was done for each
dirty rectangle. In areas with high activity, this would mean a pixel might
have been resolved multiple times. Also, if too many individual updates
were queued, the whole screen would be refreshed, even if unnecessary.
All other drivers only keep one overall dirty rect, so do it here as well.
These were special settings only for the win32-drivers, and
introduced in the very first version we track.
Time kinda had caught up with those variables, so it is time to
say farewell.
force_full_redraw was most likely a debug functionality "in case
our dirty-rect fails". This should no longer be needed.
display_hz was cute, as it had a max of 120. That is kinda
out-dated information, but I also doubt anyone was really using
this.
In file included from src/settingsgen/../string_func.h:30,
from src/settingsgen/settingsgen.cpp:11:
src/settingsgen/../core/bitmath_func.hpp:34:15: error: 'uint' does not name a type; did you mean 'uint8'?
34 | static inline uint GB(const T x, const uint8 s, const uint8 n)
| ^~~~
| uint8
WM_PAINT hits when-ever Windows feels like, but always after we
marked the screen as dirty. In result, it was lagging behind,
giving a sub-60fps experience.
With the new draw-tick there is no longer a need to be driven by
WM_PAINT, so it is better anyway to drive the drawing ourself. As
an added bonus this makes the win32 driver more like the others.
For some reason I only converted one of the two modal windows we
have, and completely forgot the other.
While at it, synchronize the way those two modal windows work
in terms of "next_update".
The higher your refresh-rate, the more likely this is. Mostly you
notice this when creating a new game or when abandoning a game.
This is a bit of a hack to keep the old behaviour, as before this
patch the game was already freezing your mouse while it was changing
game-mode, and it does this too after this patch. Just now it
freezes too a few frames earlier, to prevent not drawing windows
people still expect to see.
Most modern games run on 60 fps, and for good reason. This gives
a much smoother experiences.
As some people have monitors that can do 144Hz or even 240Hz, allow
people to configure the refresh rate. Of course, the higher you
set the value, the more time the game spends on drawing pixels
instead of simulating the game, which has an effect on simulation
speed.
The simulation will still always run at 33.33 fps, and is not
influences by this setting.
Sleep for 1ms (which is always (a lot) more than 1ms) is just
randomly guessing and hoping you hit your deadline, give or take.
But given we can calculate when our next frame is happening, we
can just sleep for that exact amount. As these values are often
a bit larger, it is also more likely the OS can schedule us back
in close to our requested target. This means it is more likely we
hit our deadlines, which makes the FPS a lot more stable.
Before, every next frame was calculated from the current time.
If for some reason the current frame was drifting a bit, the
next would too, and the next more, etc etc. This meant we rarely
hit the targets we would like, like 33.33fps.
Instead, allow video-drivers to drift slightly, and schedule the
next frame based on the time the last should have happened. Only
if the drift gets too much, that deadlines are missed for longer
period of times, schedule the next frame based on the current
time.
This makes the FPS a lot smoother, as sleeps aren't as exact as
you might think.
During fast-forward, the game was drawing as fast as it could. This
means that the fast-forward was limited also by how fast we could
draw, something that people in general don't expect.
To give an extreme case, if you are fully zoomed out on a busy
map, fast-forward would be mostly limited because of the time it
takes to draw the screen.
By decoupling the draw-tick and game-tick, we can keep the pace
of the draw-tick the same while speeding up the game-tick. To use
the extreme case as example again, if you are fully zoomed out
now, the screen only redraws 33.33 times per second, fast-forwarding
or not. This means fast-forward is much more likely to go at the
same speed, no matter what you are looking at.
_realtime_tick was reset every time the diff was calculated. This
means if it would trigger, say, every N.9 milliseconds, it would
after two iterations already drift a millisecond. This adds up
pretty quick.
On all OSes we tested the std::chrono::steady_clock is of a high
enough resolution to do millisecond measurements, which is all we
need.
By accident, this fixes a Win32 driver bug, where we would never
hit our targets, as the resolution of the clock was too low to
do accurate millisecond measurements with (it was ~16ms resolution
instead).
InvalidateWindowData with mode SBI_NEWS_DELETED was called on the
status bar when checking for a new item of news to be shown in the
ticker, even if there is no news queued and no change occurs.
When there are a lot of rects to redraw, of which one of the last
ones is almost the full screen, visual tearing happens over the
vertical axis. This is most visible when scrolling the map.
This can be prevented by using less rects. To simplify the situation,
and as solutions like OpenGL need this anyway, keep a single rect
that shows the biggest size that updates everything correctly.
Although this means it needs a bit more time redrawing where it
is strictly seen not needed, it also means less commands have
to be executed in the backend. In the end, this is a trade-off,
and from experiments it seems the approach of this commit gives
a better result.
During resizing, there can still be dirty-rects ready to blit based
on the old dimensions. X11 with shared memory enabled crashes if
you try to do this. So, instead, if we resize, reset the dirty-rects.
This is fine, as moments later we mark the whole (new) screen as
dirty anyway.
The first point was counted, but also initialized as "last". As
such, it didn't add to "total", but did add to "count", which made
the "count" 1 more than the total actually represents.
korean: 2 changes by telk5093
indonesian: 11 changes by dimaspaf14
russian: 2 changes by Ln-Wolf
finnish: 3 changes by hpiirai
french: 4 changes by glx22
The zoom level suggestion is based on the DPI scaling set in Windows.
We use 150% scaling as the threshold for 2X zoom and 300% scaling
as the threshold for 4X zoom.
We never change the real screen resolution on OSX. As such, offering a list
of resolutions is pointless. Instead of that, offer the user a list of
commonly used window sizes up to the current screen size.
Many of the member variables that are used in save/load are inside types
that are not standard layout types. Using pointer arithmetics to determine
addresses of members inside types that are not standard layout is generally
undefined behaviour. If we'd use C++17, it is conditionally supported, which means
each compiler may or may not support it. And even then using it for individual
array elements is syntactically not supported the the standard offsetof function.
Unfortunately, the trickery employed for saving linkgraph settings causes quite some
clutter in the settings ini files.
Many of the member variables that are used in the oldloader are inside types
that are not standard layout types. Using pointer arithmetics to determine
addresses of members inside types that are not standard layout is generally
undefined behaviour. If we'd use C++17, it is conditionally supported, which means
each compiler may or may not support it. And even then using it for individual
array elements is syntactically not supported the the standard offsetof function.
In testing, I could find no reason why this statement is here.
The comment is rather unclear (it states what it does, but not
why it would be needed).
This line of code was introduced with f4f40448, which gives no
further insight on why it would be needed to have it here.
As such, let's remove it and see if anyone else reports any
problems with it. If so, this commit can be reverted and a more
clear comment should be added what this line of code is dealing
with (the WHY, not the WHAT).
This means the code depended that the caller did this for us
before MakePalette() is executed, which is neither a
requirement nor a promise the code makes.
On some distros allegro v5 is called allegro-5, but on some others
it is not. So this should fix for all distros that allegro v5 is
not being picked up, and only v4 is.
When the wayland SDL video driver is used, an EGL context is
created in the main thread. It is not allowed to update this
context from another thread, which is exactly what our draw-thread
is trying.
The other solution would be to move all of SDL into the
draw-thread, but that would introduce a whole scala of different
problems.
The wayland SDL backend is significantly faster than the
X11 SDL backend, but there is a performance hit nevertheless.
nielsmh nicely correct us in #8641, pointing out the old comment
is not telling a complete truth. The result is the same, but it
is better to not mislead future-us.
These bundles can be opened on any "modern" Linux machine with
a driver that SDL2 supports.
Machines needs at least glibc 2.15, which was released 10 years ago.
It is build with CentOS 7 as base, and only assumes the following
libraries are available on the system:
- libc
- libdl
- libgcc_s
- libpthread
- librt
- libstdc++
All other libraries the game depends on are bundled together with
the game, so users don't need any library installed to use this
bundle. The downside of course is that this increases the binary
size a bit: 30 MiB of libraries are in this bundle.
RPATH is used to make ld-linux find the folder libraries are
stored in; however, system libraries are always used before these,
in the assumption libraries on the user system are more up-to-date.
Using -DOPTION_PACKAGE_DEPENDENCIES=ON switches on packaging
of libraries in the "lib" folder. This requires CMake 3.16 to
be installed; otherwise it will fail.
If a server is compatible, it falls back to sorting by clients.
This used to be in reverse, so full servers are on top. With
the codechange commit, this was removed by accident, and as
such empty servers were on top. This is silly.
It now follows more what the Win32 driver does, and has far less
exceptions and special casing.
MakePalette creates the Palette and prepares surface.
UpdatePalette updates the Palette.
CheckPaletteAnim checks if UpdatePalette needs to be called and
marks the whole screen dirty so DrawSurfaceToScreen will do a
full redraw.
Sometimes it returned an usererror(), sometimes Start() failed.
Now it always fails on Start(), so nothing else has to check again
what blitter is used.
AfterBlitterChange() can never change to a 0bpp, so it is sufficient
to guard this with an assert().
Additionally, tell exactly why the font failed to load, which
glyph was missing from the font. This hopefully helps the user
a bit more in the right direction.
This makes no sense, that a free-wagon-chain could be larger than
the maximum length of a train, as you cannot put an engine in
front of that anyway. And it prevents run-away AIs making very
silly long free-wagon-chains.
The current "restart" command is now called "reload", as that is
what it does.
The old "restart" command is now called "restart", as that is what
it did.
As this has not been in any official release yet, this shouldn't
harm any kitten.
For non-NewGRF planes, "count" is never above 1. So planes can
smoothly be guided to their destination. For NewGRF planes, they
can go as quick as "count" values of 20. This easily overshoots
the target. So, calculate if the plane will overshoot, and start
nudging him to the destination earlier. You won't notice this
either way, as it all happens within a single tick.
Although meant as a funny joke towards the player, our social
standards have changed since 2004, and such "jokes" are no
longer acceptable by the community as a whole.
The only value of the message is that people are informed the
information is stored in the savegame. This is mostly useful for
us, developers, as some of those cheats can have side-effects
which people report.
While at it, styled the GUI a bit better, as the way the text
was presented was odd.
korean: 2 changes by telk5093
finnish: 2 changes by hpiirai
dutch: 49 changes by Afoklala
spanish: 16 changes by Luis45ccs
french: 7 changes by dimensi0n
polish: 2 changes by yazalo
This change allows a user to see what is available and what will become
available before it is available, instead of only disabling the button
with no further explanation. It also always allows building roads and
canals, even if no vehicles are available for road / water.
For rail/road/tram, a dropdown with available types is shown. If
none are available, it reads "None". If the type is not yet available,
it is greyed out.
For dock/airport, this always open the toolbar, but building airports,
docks, and depots buttons are disabled till vehicles are available
for those.
Road is the only exception, with the primary road always being
available. Here too, stations and depots are disabled till vehicles
become available. It does mean you can now always build roads to
for example help towns grow.
Before it was shown as a normal order, but the vehicle was skipping
it. This was rather unclear to the user. Now it is red and contains
text with some hints what is going on.
The text is prefixed rather than post-fixed, as we have many
post-fixes already.
This reverts commit c1fddb9a6a and 639cfa43d2.
access_mode "none" is only supported by GCC11, but introduced
after it branched. So there are GCC11.0s out there that do not
support it. We will have to wait for GCC11.1 to hit before we
can re-add this.
Because certain files are read-only, the "restore-cache" step
fails, as Windows tar refuses to overwrite those files (even
if they are identical). Instead of hoping upstream fixes
"restore-cache", just remove the read-only flag on these files
instead.
Without hills, not all industries can be generated, which means
that with a default configuration you get errors. This is far from
optimal, of course.
This now forces that there is at least some hills, even when you
are using very-flat. This is a stopgap solution, but a proper
solution requires a full rewrite of the terrain generator, which
is not a 2 minute (or even 2 week) job.
To make sure flat is still flat-ish, reduce the default
snow-line-height to 10, making it look a lot better on smaller maps.
This is a compromise between being able to have flat maps and
still having all industries on arctic.
This means that for rail tunnel/bridges, the rail is first sold,
and the tunnel/bridge is destroyed after. This means destroying
tunnels/ bridges now often makes you money, instead of costing.
Similar, with road/tram tracks. Destroying a road+tram
tunnel/bridge now costs the same amount of money as first
removing the tram tracks and than destroying the road
tunnel/bridge. Especially as tram tracks generate money when
removing, this is a noticeable difference.
It only considered the end-tile (or start-tile) for the bridge,
instead of both. This is obvious in the rest of the code which
constantly does "+ 2"; this being the only place that does a "+ 1".
Despite what it looked like, you could never really change the
ending-year (it was always reset to 2050 on start-up). See commit
683b65ee1 for details. As a side-effect, the variable that was
suppose to store the ending-year was just zero, never containing
a real ending-year.
MAX_YEAR is set to 5000000, but having an ending-year set to the
same meant you could bypass this, and play till the uint32 wrapped.
The game can either show highscore or wrap year, not both. When
you would do both, every year you get the highscore dialog.
By changing the maximum value of ending-year to 4999999 we prevent
this issue.
spanish (mexican): 5 changes by absay
korean: 5 changes by telk5093
finnish: 5 changes by hpiirai
latvian: 14 changes by lexuslatvia
spanish: 23 changes by SeveralCircles, 10 changes by Luis45ccs
polish: 5 changes by yazalo
The selected group was not reset when drag&drop was aborted. When
after that vehicle drag&drop was successful, group drag&drop code
was still executed, causing weird behaviour or even crashes.
When a multi-tile house is rebuild, it always used the most northern
tile to build the new house. This can very easily lead to houses
wandering off in the north-ish direction (either NW or NE).
To prevent this, pick the tile closest to town center when rebuilding
on a multi-tile house. This still means a house can be build away
from a road, but it is no longer wandering around finding another
town to call home.
This is a much better location for this button, as you send
money from one company to another company, not from player
to player.
This is based on work done by JGRPP in:
f820543391
and surrounding commits, which took the work from estys:
https://www.tt-forums.net/viewtopic.php?p=1183311#p1183311
We did modify it to fix several bugs and clean up the code while
here anyway.
The callback was removed, as it meant a modified client could
prevent anyone from seeing money was transfered. The message
is now generated in the command itself, making that impossible.
When a vehicle is cleaned up, all news that points to the news is
also removed. This was a bit evil, as it would also remove any
news related to crashed, acting like the crash never happened.
This left players a bit in the dark what was going on exactly.
This means that if you start OpenTTD with "-c" to indicate another
location to store files, it can still read the content you already
downloaded from your PERSONAL_DIR. This folder is, however,
read-only.
This is useful for situations where you downloaded OpenGFX via
the content-service, but want to run the regression or want to
run with a clean configuration. With this change, you no longer
need to download OpenGFX again.
When running with -dsl=2 it is very easy to miss important information
as there was a lot of noise in between too. This tunes the debug
levels a bit to be less noisy while keeping the important bits.
The previous fix 887e9481ff0e70df6bf93ce15a3899a03f124c50 only worked for roads and failed to consider a multiplier used for the infrastructure totals for tunnels/bridges.
Also, depots and bus/truck stops are counted as 2 road pieces on creation but were only counted as 1 road piece on conversion because the function DiagDirToRoadBits() was used, which only ever returns single-piece road segments.
Co-authored-by: A. S <admin-git@sotai.tk>
We use CMakeListsTxtAdvanced, and as such, we have to do this our
self via "-DCMAKE_BUILD_TYPE=RelWithDebInfo". Otherwise we are
producing Debug builds instead of Release builds. Oops.
Also parts of the saveload code does, and some other places. This
does slow down builds, but for most computers this will not be
measurable. At least, the ones I had access to I could not find
a difference in FPS, mainly as that is heavily limited by the Hz
of the screens of the computer.
Either way, it is better to have a full functional game than a
fast one in my opinion
You can do: "startai myai.3", which starts version 3 of "myai".
This is very useful for testing save/load code between different
versions of your AI.
However, when using this syntax, the AI got saved as "myai.3" as
name of the AI, instead of "myai". This caused several problems,
like indicating to the user the AI could not be found, but still
load the AI. But in all cases, the AI never got the chance to
load the saved data, making the whole reason this exists pointless.
By splitting the name and version already in the console command,
the code becomes simpler and AIs started this way now follow the
normal flow after initialization.
It was rather confusing that "library_name" was calculated, and
then not used to do the FindLibrary() call. Flipping those two
blocks around makes it a bit more sane to read.
When link graph jobs are cleared due to abandoning the game or exiting,
flag the job as aborted.
The link graph job running in a separate thread checks the aborted flag
periodically and terminates processing early if set.
This reduces the delay at game abandon or exit if a long-running job
would otherwise still be running.
Check if the job is still running two date fract ticks before it is due
to join, and if so pause the game until its done.
When loading a game, check if the game would block immediately due to
a job which is scheduled to be joined within two date fract ticks,
and if so pause the game until its done.
This avoids the main thread being blocked on a thread join, which appears
to the user as if the game is unresponsive, as the UI does not repaint
and cannot be interacted with.
Show if pause is due to link graph job in status bar, update network
messages.
This does not apply for network clients.
Various of PatchPacks (Spring 2013, Joker, ChillPP) used versions
slightly higher than ours. Of course, as time went by, this
caught up with us, and we are now almost pushing a new version
that would conflict with them. To avoid users creating unneeded
issues about "why can I not load my savegame", lets be ahead of
the curve and flat-out refuse to load them.
Version-wise, this is totally fine. We have ~32k versions to go
before we run out (0x8000 is masked by JGRPP; we should avoid
using that). At the rate we bump savegames, this is not going to
happen in any sane reality.
Azure Pipelines has build our releases for two years now, but we
are finally switching to GitHub Actions. This to bring the full
workflow to a single place, making it easier for people to see
what is going on and how to influence the process.
This has several ways of being triggered:
- When creating a new release via the GitHub interface. Fully
automated that will produce new binaries, upload them, and it
will even update the website to tell about the new version.
- When triggered in an automated way from OpenTTD/workflows to
start a nightly.
- Manually via the Release workflow, which accepts branches,
Pull Requests and tags to build.
Rerunning a job is safe and should be without issues. Everything
retriggers and updates what-ever might have been broken. In fact,
except for dates, it should produce identical results.
Co-authored-by: Charles Pigott <charlespigott@googlemail.com>
DOS did not have cases in filenames. Different OS interpret
them as either all-lowercase or all-uppercase. So we try both.
All-uppercase is done by the obg/obm/obs files, and if opening
fails, OpenTTD will automatically retry the all-lowercase variant.
So for those who already have the files lowercase, nothing
changes. For those that install fresh from TTO, it should now
work out-of-the-box.
Apple Clang version 12 (bundled with Xcode 12) complaints about copying
small objects in range loop (-Wrange-loop-analysis introduced by -Wall).
This warning can be easily avoided by removing the reference from
the const pointer type.
This means that for NE/NW, it should have one more in case of
freeform-edges, and in case of SE/SW it should have one less.
Reminder: freeform-edges only adds VOID tiles on X=0 and Y=0.
This is for consistency; most other objects add a # to indicate
it is the Nth of that object, except for Trains / RVs / Ships /
Aircrafts.
This becomes painfully apparent with unnamed vehicles in groups,
which do get a "#".
When a developer attaches the "preview" label, a build is created
and published on https://preview.openttd.org/. After that, new
pushes to the PR are automatically build (as long as the "preview"
label exists).
If a non-developer attaches the "preview" label, it will be
removed.
This mode doesn't wrap the mouse constantly, but requests SDL
to lock the mouse pointer. This is needed, as with Emscripten
you are not allowed to change the mouse poisition (only to lock
it into place).
Emscripten compiles to WASM, which can be loaded via
HTML / JavaScript. This allows you to play OpenTTD inside a
browser.
Co-authored-by: milek7 <me@milek7.pl>
This commit prepares for the next commit, as Emscripten needs to
have a way to trigger a single iteration of the main loop. To
keep the real changes more clear, this commit only unrolls the
loop, and makes no changes to the logic itself.
With \x, we sometimes had to do the "" trick, as the length is not
predefined. With C++11 bringing \u to the specs, which has a preset
length, we no longer need the "" trick.
We set the strings to u8, to ensure all compilers use UTF-8 encoding
for the \u characters.
This was triggered by newer CLangs, which start to warn if you
use "" in the middle of a string, wondering if that was your
intention. It is a good question. And this is our answer :)
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.
Also, while at it, make it more like the upcoming release-workflow,
so they look a lot more similar.
Functional it should be the same, except that Windows should
now also output when a test fails.
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.
Formally it was only done on exit. This means that if it crashes
changes in settings were not stored. This is often rather
frustrating. Additionally, targets (like emscripten) where people
are unlike to use "Exit Game", will never see their configuration
stored.
The drawback is that on every setting change there is some minor
I/O of writing the ini file to disk again.
If I explicitly tell the system I do not want sound, I still get
presented a nice message I do not have any BaseSounds available
on my system, and that I should download one to enjoy sound. Well,
let me tell you, with "-snull" that is really really not going to
help. So please, be quiet, and let me enjoy the game without
"boooooo" and "DING DING DING".
Thank you.
The intention of this function was that you could download
everything after a filter was applied; but this never really
took off. Instead, a select few people used this functionality
to download every available package on BaNaNaS. This is not in
the spirit of this service. Additionally, these few people were
good for 70% of the consumed bandwidth of BaNaNaS.
LZO was used before the first version we track in our version
control system, which dates back to Aug 2004. Somewhere before
that time a few savegames / scenarios exist which use LZO. No
other savegame / scenario does since then. Let's not encourage
people to install something that ancient.
There are no scenarios on BaNaNaS that require LZO.
This is, by specs, undefined behaviour. See
https://reviews.llvm.org/D67122
In cases where this is done, optimizations done by LLVM can
generate code that causes crashes.
GetVariableAddress() had two (legit) ways this could happen:
- For SaveLoad set to global
- For SaveLoad set to SLE_VAR_NULL, where sld->address is always
a nullptr, and object could or could not be a nullptr.
By default gzip embeds a timestamps which makes building it twice
not reproducible, passing -n skips this embedding behaviour.
Motivation: https://reproducible-builds.org
italian: 1 change by AlphaJack
romanian: 13 changes by ALEX11BR
finnish: 6 changes by VeeraKoo
slovak: 202 changes by FuryPapaya
spanish: 240 changes by MontyMontana
When the restart command is issued, a normal map is always spawned.
This improvement takes into account the current state of _file_to_saveload to check if a savegame/scenario/heightmap was previously loaded, and loads the same resource again.
The expected regression output files all end with a newline. As such, we have to make sure we capture the output from OpenTTD with the last newline intact.
When compiling with '-Og', GCC warns about variables that are
initialized by reference in the condition of a 'while' loop.
This commit silences the warning by explicitly initializing the
variables in question to their respective 'invalid value' markers,
which will most likely be optimized out when the compiler realizes
the values are never used.
This changes the error when you attempt to convert a road owned by a town to another road, specifying that it's owned by the town rather than simply being incompatible. As the original poster of the issue pointed out, these seemed to be the only occurences of the incompatible road string, so now it's unused, but they would be left untouched in case of future use or since changing it to a different error would do the work of removing it then. If requested, it likely wouldn't be too difficult to remove the string entirely.
I tried building a tag, and got this error:
CMake Error at cmake/scripts/FindVersion.cmake:85 (string):
string sub-command REGEX, mode REPLACE: regex "^[0-9.]*$" matched an empty
string.
In 11ab3c4e the number of cargo types was changed from 32 to 64.
The save/load of Town::cargo_accepted was not updated, such that
only half of the data structure is saved/loaded in savegame versions
199 to 218.
Discard and regenerate data from all savegame versions prior to 219.
In 63ccb36e BaseConsist::name was changed from a malloced char*
to a std::string.
OrderBackup inherits from BaseConsist.
The saveload of OrderBackup::name was not updated.
Remove static buffer form of NetworkAddress::GetAddressAsString.
This is used in multiple threads concurrently, and is not thread-safe.
Replace it with a form returning std::string.
This fixes a bug that can reproduced with these steps:
* Start openttd in fullscreen mode
* Turn off fullscreen mode
* Try to resize the window. The window can't be resized.
CPack works closely together with CMake to do the right thing in
terms of bundling (called 'package'). This generates all the
packaging we need, and some more.
CMake works on all our supported platforms, like MSVC, Mingw, GCC,
Clang, and many more. It allows for a single way of doing things,
so no longer we need shell scripts and vbs scripts to work on all
our supported platforms.
Additionally, CMake allows to generate project files for like MSVC,
KDevelop, etc.
This heavily reduces the lines of code we need to support multiple
platforms from a project perspective.
Addtiionally, this heavily improves our detection of libraries, etc.
For grfs, it now uses CMake scripts to do its job, and both grf
files are split into their own folder to make more clear what is
going on. Additionally, it no longer builds in-source (although the
resulting grf is copied back in the source folder).
For ob[msg] it now uses CMake scripts to generate the translation
files; the result is no longer stored in-source (but in the build
folder).
Although all files are available to create the GRFs and basesets, it
won't really work till CMake is introduced (which will happen in a
few commits from here)
The tst_stationlist savegame had to be changed to start the correct
AI. In the old setup, all regression AIs had the same name, which
made it impossible to run both regressions in parallel. With the new
setup this is possible.
Although all files are available to run the regression, it won't
really work till CMake is introduced (which will happen in a few
commits from here)
Initialization code for GRFFile::roadtype_map was copied from
railtype_map. But while RailType is a byte-sized enum and could thus
be initialized via memset, RoadType doesn't have a defined size.
Previously the internal content list was invalidated and sorted for
every new item added. Now the sorting is delayed until the GUI is
drawn, which means we only sort once per GUI tick.
Since the amount of incoming items per GUI tick is not controlled by
the GUI but rather by network speed, we were previously doing a lot
of duplicate work per tick, causing the mouse cursor to lag while
the list was initialized.
Allow more direct player-initiated interaction for Game Scripts, by letting the GS put push-buttons on storybook pages. These buttons can either trigger an immediate event, or require the player to first select a tile on the map, or a vehicle.
Additionally this reworks how the storybook pages are layouted and rendered, to allow for slightly more complex layouts, and maybe speeding drawing up a bit.
The presence of sdl2-config is used go determine whether to look for
sdl2 first, or just sdl1. However, when sdl2-config is *not* present,
`which` returns an empty string. Due to lack of quoting, this produces
`[ -x ]`, rather than `[ -x "" ]` and it turns out the former actually
has a succesful exit status for some reason.
This was not a problem when just running configure, because it would
then just fail to detect sdl2 and fall back to sdl1. However, when
passing `--with-sdl` (without specifying a version), this would only
attempt to detect sdl2, even when sdl2-config was not present, but sdl1
is.
Adding quotes makes the check work as intended.
Variable-length values would write threshold values with a byte too many.
System Exclusive messages would cause write to fail since the end byte was treated as part of next message.
Point out that translations should be fixed via the web translator.
Clerify that "changed NewGRFs" means after the game was started, not that any game using NewGRFs is invalid for bug reports.
Use DC_AUTOREPLACE for actions that shall be reversibe, in this case:
- Do not rearrange free wagons in test-run.
- Do not discard OrderBackups.
The latter was not triggered by actual auto-replace, since it does not set a 'user'.
Since the move to C++11, building for pre 10.7 is not possible with the native
Apple tools. Also, due to bitrot, the file doesn't even compile anymore. While
this could be fixed, it shows that this subdriver is basically never used anymore.
Since the C++11 move, getting OpenTTD to compile and run for anything
below 10.7 basically requires building a custom compiler and libc++.
Also, the QuickDraw subdriver crashes on more modern OSX version. While this
is fixable, keeping the driver around is probably pointless.
This commit adds the missing feature of allowing the server owner to
provide a reason for kicking/banning a client, which the client sees in
a pop-up window after being kicked. The implementation extends the
network protocol by adding a new network action called
NETWORK_ACTION_KICKED that is capable of having an error string, unlike
the other network error packages. Additionally, the kick function
broadcasts a message to all clients about the kicked client and the
reason for the kick.
This caused drawing areas larger than 2097151 pixels at 8x zoom to
not be subdivided into smaller chunks as required.
This resulted in pathological performance issues in the sprite sorter.
The original algorithm pays intermediate legs in feeder systems based
on the start and end stations of that particular leg.
This tends to result in large negative payments on the final leg for
journeys with many feeder legs, as the overall feeder payment increases
with the number of legs, and the final leg is penalised for discrepancies
between the previous leg payments and the actual payment for delivery
from the source to the destination.
The feeder share setting is a partial mitigation, however it is difficult
to tune as a suitable value depends on the number of legs and the network
topology, which are often not the same for all vehicles.
The new incremental algorithm pays the cargo payment from the source
station to the end station of the current leg, minus any previous
transfer feeder payments for each leg.
This prevents unbounded increase of feeder payments and therefore avoids
the issue of excessive negative payments on the final leg.
Feeder payments may be negative, e.g. in the case of poorly performing
or highly indirect legs. This is better than penalising the final leg.
This mode reduces the need to tune the feeder shares setting to the
current network.
The feeder share setting applies in the existing way.
'date -u' returns the time in UTC. 'git log' uses local time. In
result, when a machine is on for example +0100, it would generate
the changelog of 7 days 1 hour, instead of 7 days. This is a silly
oversight.
SDL_GetVideoDriver(0) returns name of first video driver included in
the library, not the driver currently used.
SDL_GetCurrentVideoDriver() does what we want here.
* Feature: GS method to allow company to use an engine before its introduction date
* Feature: GS method to retire an engine early for a specific company
If the game was started loading a savegame or scenario, auto-restart will load a new random map.
This is inconsistent with the case in which a heightmap was loaded, as in that case the heightmap is kept as a basis for a new game.
This proposal solves this heterogeneity be considering the originally loaded resource shall be kept, hence savegames & scenarios shall be reloaded
MCF Dijkstra iterations are executed for all source nodes in a round-robin order.
Source nodes typically require different numbers of MCF Dijkstra iterations
to satisfy all of their demand.
This change is to avoid performing MCF Dijkstra iterations on source nodes which
have already been fully satisfied.
In the case where multiple industries have the same name, sorting
in the industry directory window is non-deterministic.
This results in the order changing on each re-sort, and is noticeable
when the industries have different production or transported values.
Added missing keycodes mapping to `_keycode_to_name` array
to allow their use in `hotkeys.cfg`.
Also reordered them according to `WindowKeyCodes` order.
Signed-off-by: Konstantin Gribov <grossws@gmail.com>
Ensure the same coordinates are used for station/town/player signs regardless of how the landscape changes below it after the coordinates were first determined.
By keeping track of whether each ViewportSign is valid for Kdtree use (and only ever registering the viewport sign when the object is valid) a lot of code can be simplified and become more robust at the same time.
This fixes part A of #7619, but not part B.
Vehicle::x_pos and Vehicle::y_pos are not required to be within the map bounds.
See also: GetTileHeightBelowAircraft()
On TileLoop_Object, HQs are able to produce and move passengers and mail to stations, but querying the HQ tiles for cargo supplied was returning nothing. This makes it so that they return +1 to both passengers and mail.
Previously, a helicopter in the hangar of a commuter airport would have to wait until HELIPAD2 was free before it could takeoff. Now, a helicopter in the hangar can takeoff from just outside the hangar.
This function requires libSDL 2.0.5 or higher. It looks like we don't
need to use it, and can just use the original SDL_CreateRGBSurface(),
with the masks set to 0, to trigger the default 8-bit format, which is
SDL_PIXELFORMAT_INDEX8.
Closes#7785
Note: this code path is activated by using an 8-bit blitter, like:
./bin/openttd -b 8bpp-simple
This is a quick fix by @KeldorKatarn:
65e656b9d6
It has the drawback that snow is draw to the inside the depots as well, as the removed comment suggests.
Prior to this commit, the following is observed when running openttd.exe
that was compiled using mingw32 on x86_64:
> The procedure entry point ScriptBreak could not be located in the
dynamic link library GDI32.dll
The MSDN docs at the below link state that modules using Uniscribe must
first link against usp10 before gdi32 to avoid this issue:
https://msdn.microsoft.com/en-us/library/windows/desktop/dd319118(v=vs.85).aspx
Signed-off-by: Joe Stringer <joe@wand.net.nz>
Fixes the following complaints:
src/network/core/address.cpp: In member function 'const sockaddr_storage* NetworkAddress::GetAddress()':
src/network/core/address.cpp:134:55: error: 'AI_ADDRCONFIG' was not declared in this scope
this->Resolve(this->address.ss_family, SOCK_STREAM, AI_ADDRCONFIG, nullptr, ResolveLoopProc);
Signed-off-by: Joe Stringer <joe@wand.net.nz>
src/depend/depend.cpp: In constructor 'File::File(const char*)':
src/depend/depend.cpp:170:19: error: 'strdup' was not declared in this scope
this->dirname = strdup(filename);
^~~~~~
Signed-off-by: Joe Stringer <joe@wand.net.nz>
Fix the following compile errors:
In file included from openttd/src/debug.h:15:0,
from openttd/src/string.cpp:13:
openttd/src/cpu.h:35:19: error: 'uint' was not declared in this scope
bool HasCPUIDFlag(uint type, uint index, uint bit);
openttd/src/string.cpp: In function 'char* strcasestr(const char*, const char*)':
openttd/src/string.cpp:548:7: error: 'strncasecmp' was not declared in this scope
if (strncasecmp(haystack, needle, needle_len) == 0) return const_cast<char *>(haystack);
openttd/src/strgen/strgen_base.cpp: In function 'void EmitPlural(Buffer*, char*, int)':
openttd/src/core/alloc_func.hpp:136:6: error: 'alloca' was not declared in this scope
(T*)alloca((num_elements) * sizeof(T)))
Signed-off-by: Joe Stringer <joe@wand.net.nz>
Multiplayer games has the server add some flags to the cmd value during the handling.
These flags should not be included in the verification, mask them out. Without this
masking out, scripts tend to die when executing their first command in multiplayer.
If $ROOT_DIR is a linked working tree from git-worktree(1), then
$ROOT_DIR/.git is a regular file instead of a directory. Allow this
when deciding whether to use git to detect OpenTTD's version.
Drop checks for svn and hg in config.lib, because findversion.sh
hasn't used svn nor hg since 192770e6da.
The AllRules ruleset causes the VS 2019 editor to litter warning squiggles all over the place, about things that would never be fixed. Limit it to the smallest ruleset available. Warnings shown now mainly concern potential arithmetic overflows.
The 'offs_start_map' is a 'SmallMap', so its own 'Erase' function should be called instead of the underlying vector's 'erase' function.
And fix a "typo". :)
Building with FreeType is still possible and will take precedence over the GDI renderer, but
the project files don't include FreeType anymore by default. Combining GDI rendering with ICU
text layout is untested.
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.
When drag and drop a vehicle into an empty slot in the vehicle group window it tries to create the new group as the subgroup of the first group (GroupID = 0). This is failing if the dragged vehicle's type is different than the first group's vehicle type.
Road type and rail type are stored in separate locations, so this parameter does
not make make sense as it is only used for rail bridges. Instead explicitly set the
rail type in MakeRailBridgeRamp().
AIs test station catchment in reverse to how players see station catchment.
This did not take account of non-rectangular station catchment areas, so AIs
could end up placing stations in locations that did not accept/deliver cargo.
In particular this crash can be observed when using the
bootstrap GUI to download the base graphics.
In ClientNetworkContentSocketHandler::OnReceiveContentInfo
ClientNetworkContentSocketHandler::callbacks is iterated, using an iterator
cb->OnReceiveContentInfo() is called (cb is of type BootstrapAskForDownloadWindow)
This calls new BootstrapContentDownloadStatusWindow()
This inherits from BaseNetworkContentDownloadStatusWindow
The constructor of which calls _network_content_client.AddCallback(this)
This reallocates the std::vector which is being iterated in ClientNetworkContentSocketHandler::OnReceiveContentInfo
This results in iter being invalid, and an assertion failure occurs shortly
afterwards due to its use in the next iteration of cb->OnReceiveContentInfo()
Adjust all locations where ClientNetworkContentSocketHandler::callbacks
is iterated to avoid problematic behaviour
The last use was for storing a list of memory blocks. As the way these lists are accessed is very
specific, it is easier to just write an explicit destructor instead of trying to exactly match the behaviour.
DropDownListItem are strongly managed using std::unique_ptr to ensure leak-free handling. Appropriate use
of move-semantics make intent a lot clearer than parameter comments and allows the compiler to generate
copy-free code for most situations.
A conforming compiler with a valid <mutex>-header is expected.
Most parts of the code assume that locking a mutex will never fail unexpectedly,
which is generally true on all common platforms that don't just pretend to
be C++11. The use of condition variables in driver code is checked.
It is skipped when NPF is in use.
It is trivial to work around by adding and removing dummy orders.
It is mostly alleviated by the ship path cache in YAPF.
In the autoreplace window, the rail type drop down is for choosing engines
of the given time. Many rail types do not have engines specifically designed for them,
and are merely compatible with other rail types. This list is thus unwieldy and many
options have no engines available.
As this drop down is for choosing _engine_ rail type rather than compatible rail types,
we can list just the rail types explicitly listed by engines.
Linkgraph nodes require a specific order that was maintained by swapping just the last
element for the node to be removed. std::vector::erase() changed this to removing the
node is then shuffling the remain items down, which upsets other references to this
indices.
This is fixed by switching back to the original swap & pop method.
Display of industry production around tiles (as shown when placing a station)
did not take account of the station catchment changes, so still showed production
from an industry even if it was not covered by a tile.
This is fixed by making a set of nearby industries that are covered, instead of
looping over all possible industries.
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
The use of std::none_of in network/core/host.cpp is driven by the non-const
comparison operator use by NetworkAddress. A future commit should address
the const_casts in that class to ensure const-correctness.
The public and protected interface to SmallVector are unchanged
SmallVector now requires that items be default constructible
This isn't an issue since some contained items were previously created
uninitialized.
Temporary default constructors are added to the following structs
- SmallPair
- SmallStackItem
- GRFPresence
Where vector<bool> is required, transition immediately to std::vector
to avoid returning proxy object references.
Sign width was only updated when the text was changed. This seems to work for player-placed
signs as there is always a rename operation, however AIs can create a sign with text in one
go, in which case the width was never set.
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 is a C++11 feature that allows the compiler to check that a virtual
member declaration overrides a base-class member with the same signature.
Also src/blitter/32bpp_anim_sse4.hpp +38 is no longer erroneously marked
as virtual despite being a template.
Measurement tooltip was auto-closed as the hover/right-click test for tooltips was not
satisfied in this case. This is fixed by keeping the tooltip visible and instead explicitly
closing the tooltip when the PlaceObject is cancelled/completed.
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.
GetAircraftFlightLevel<Aircraft> is only used in static functions
inside aircraft_cmd.cpp. With GCC, Clang and MSVC this is not an
issue, but on ICC fails linking, because it doesn't find this
version of this template. Possibly these two pieces of information
are linked.
Explicit defining the function fixes the issue.
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.
Currently this can only be triggered by NewGRF house tiles querying for cargo acceptance history
of nearby stations (var 0x64) with a tile offset, and providing an offset that happens to point
to an industry tile. This serves no useful purpose.
_current_company is not currently logged anywhere in the crashlog.
_local_company is logged, despite being much less useful than
_current_company.
This change logs _current_company alongside _local_company.
If it was compiled with MingW, both / and \ were accepted as
path separator. On MSVC, only \ was. This is an unexpected
difference between binaries for the same platform. Remove this
discrepancy by accepting both / and \ on all platforms.
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.
By naming it in a different way, things get a bit confusing.
Especially if we are switching to CMake, which autodetects these
things, we need to use the name the authors of ICU gave it; not
our interpertation of that name.
By naming it in a different way, things get a bit confusing.
Especially if we are switching to CMake, which autodetects these
things, we need to use the name the authors of ICU gave it; not
our interpertation of that name.
It is the only library we use that calls itself with 'lib' in the
name. This might be confusing, but with the arrival of cmake a lot
of these things are automated. And detection will find 'liblzma',
not 'lzma', like with 'lzo', 'zlib', ..
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.
libtimidity was introduced with the support for PSP. PSP has been
dropped almost a year ago, but this music driver was not. This
corrects that oversight.
timidity (via extmidi) still works fine. This purely removes the
libtimidity support, which was only really available for PSP.
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
This only affects failed town generation, as towns do not delete bridges under any other circumstances.
The existing test performed badly with a large number of towns due to having to calculate the
nearest town, and also by its nature assumed a bridge was built by the nearest town, leading
to bridges of nearby large towns be removed incorrectly.
If we gain the ability to quickly retrieve the correct town (which is _not_ the nearest town) from the bridge, this change should be reviewed.
Thanks for taking the time to fill out this crash report!
- type:input
id:version
attributes:
label:Version of OpenTTD
description:Fill in below what version of OpenTTD you are using, including your OS.
placeholder:ex. 1.11.2, Windows 10
validations:
required:true
- type:textarea
id:reproduce
attributes:
label:Steps to reproduce
description:Please spend a few words if you can reproduce this problem.
placeholder:|
1. Bought a new train.
2. The game crashed.
validations:
required:true
- type:textarea
id:crashlogs
attributes:
label:Upload crash files
description:With the `crash.log`, `crash.dmp`, and `crash.sav` we can analyze the crash in detail; this way you allow us to easier triage and fix the problem.
placeholder:|
1. Zip the `crash.log`, `crash.dmp` and `crash.sav`.
# The only thing allowed after a list, is this next marker, or a newline.
ifline=="###next-name-looks-similar":
# "###next-name-looks-similar"
# Indicates the common prefix of the last list has a very
# similar name to the next entry, but isn't part of the
# list. So do not emit a warning about them looking very
# similar.
iflength!=0:
errors.append(f"ERROR: list around {name} is shorted than indicated by ###length")
common_prefix=""
else:
errors.append(f"ERROR: expected a newline after a list, but didn't find any around {name}. Did you add an entry to the list without increasing the length?")
skip=SkipType.NONE
ifline[0]=="#":
ifline.startswith("###length "):
# "###length <count>"
# Indicates the next few entries are part of a list. Only
# the first entry is possibly referenced, and the rest are
# indirectly.
iflength!=0:
errors.append(f"ERROR: list around {name} is shorted than indicated by ###length")
length=line.split("")[1].strip()
iflength.isnumeric():
length=int(length)
else:
length=LENGTH_NAME_LOOKUP[length]
skip=SkipType.LENGTH
elifline.startswith("###external "):
# "###external <count>"
# Indicates the next few entries are used outside the
# source and will not be referenced.
iflength!=0:
errors.append(f"ERROR: list around {name} is shorted than indicated by ###length")
errors.append(f"ERROR: common prefix of block including {name} was reduced to {common_prefix}. This means the names in the list are not consistent.")
elifcommon_prefix:
ifname.startswith(common_prefix):
errors.append(f"ERROR: {name} looks a lot like block above with prefix {common_prefix}. This mostly means that the list length was too short. Use '###next-name-looks-similar' if it is not.")
message(FATAL_ERROR"In-source builds not allowed. Please run \"cmake..\" from the build directory. You may need to delete \"${CMAKE_SOURCE_DIR}/CMakeCache.txt\" first.")
You can open the folder (as a CMake project). CMake will be detected, and you can compile from there.
If libraries are installed but not found, you need to set VCPKG_TARGET_TRIPLET in CMake parameters.
For Visual Studio 2017 you also need to set CMAKE_TOOLCHAIN_FILE.
(Typical values are shown in the MSVC project file command line example)
Alternatively, you can create a MSVC project file via CMake. For this
either download CMake from https://cmake.org/download/ or use the version
that comes with vcpkg. After that, you can run something similar to this:
```powershell
mkdirbuild
cd build
cmake.exe..-G"Visual Studio 16 2019"-DCMAKE_TOOLCHAIN_FILE="<location of vcpkg>\vcpkg\scripts\buildsystems\vcpkg.cmake"-DVCPKG_TARGET_TRIPLET="x64-windows-static"
```
Change `<location of vcpkg>` to where you have installed vcpkg. After this
in the build folder are MSVC project files. MSVC can rebuild the project
files himself via the `ZERO_CHECK` project.
## All other platforms
Minimum required version of CMake is 3.9.
By default this produces a Debug build with assertations enabled.
This is a far slower build than release builds.
```bash
mkdir build
cd build
cmake ..
make
```
For more information on how to use CMake (including how to make Release builds),
we urge you to read [their excellent manual](https://cmake.org/cmake/help/latest/guide/user-interaction/index.html).
## CMake Options
Via CMake, several options can be influenced to get different types of
builds.
-`-DCMAKE_BUILD_TYPE=RelWithDebInfo`: build a release build. This is
significant faster than a debug build, but has far less useful information
in case of a crash.
-`-DOPTION_DEDICATED=ON`: build OpenTTD without a GUI. Useful if you are
running a headless server, as it requires less libraries to operate.
-`-DOPTION_USE_ASSERTS=OFF`: disable asserts. Use with care, as assert
statements capture early signs of trouble. Release builds have them
disabled by default.
-`-DOPTION_USE_THREADS=OFF`: disable the use of threads. This will block
the interface in many places, and in general gives a worse experience of
the game. Use with care.
-`-DOPTION_TOOLS_ONLY=ON`: only build tools like `strgen`. Does not build
the game itself. Useful for cross-compiling.
## Supported compilers
Every compiler that is supported by CMake and supports C++17, should be
able to compile OpenTTD. As the exact list of compilers changes constantly,
we refer to the compiler manual to see if it supports C++17, and to CMake
to see if it supports your compiler.
## Compilation of base sets
To recompile the extra graphics needed to play with the original Transport
Tycoon Deluxe graphics you need GRFCodec (which includes NFORenum) as well.
@@ -5,21 +5,28 @@ Looking to contribute something to OpenTTD? **Here's how you can help.**
Please take a moment to review this document in order to make the contribution process easy and effective for everyone involved.
Following these guidelines helps to communicate that you respect the time of the developers managing and developing this open source project. In return, they should reciprocate that respect in addressing your issue or assessing patches and features.
Following these guidelines helps to communicate that you respect the time of the developers managing and developing this open source project.
In return, they should reciprocate that respect in addressing your issue or assessing patches and features.
## Using the issue tracker
The [issue tracker](https://github.com/OpenTTD/OpenTTD/issues) is the preferred channel for [bug reports](#bug-reports), but please respect the following restrictions:
* Please **do not** use the issue tracker for help playing or using OpenTTD. Please try [irc](https://wiki.openttd.org/IRC_channel), or the [forums](https://www.tt-forums.net/)
* Please **do not** use the issue tracker for help playing or using OpenTTD.
Please try [irc](https://wiki.openttd.org/en/Development/IRC%20channel), or the [forums](https://www.tt-forums.net/)
* Please **do not** derail or troll issues. Keep the discussion on topic and respect the opinions of others.
* Please **do not** post comments consisting solely of "+1" or ":thumbsup:".
Use [GitHub's "reactions" feature](https://github.com/blog/2119-add-reactions-to-pull-requests-issues-and-comments) instead. We reserve the right to delete comments which violate this rule.
Use [GitHub's "reactions" feature](https://github.com/blog/2119-add-reactions-to-pull-requests-issues-and-comments) instead.
We reserve the right to delete comments which violate this rule.
* Please **do not** open issues or pull requests regarding add-on content in NewGRF, GameScripts, AIs, etc.
These are created by third-parties. Please try [irc](https://wiki.openttd.org/en/Development/IRC%20channel) or the [forums](https://www.tt-forums.net/) to discuss these.
* Please use [the web translator](https://translator.openttd.org/) to submit corrections and improvements to translations of the game.
* Please **do not** open issues or pull requests regarding add-on content in NewGRF, GameScripts, AIs, etc. These are created by third-parties. Please try [irc](https://wiki.openttd.org/IRC_channel) or the [forums](https://www.tt-forums.net/) to discuss these.
## Bug reports
@@ -28,16 +35,16 @@ Good bug reports are extremely helpful, so thanks!
Guidelines for bug reports:
0. Please don't report issues with games where you changed NewGRFs.
0. Please don't report issues with games where you changed NewGRFs mid-game. (This can be verified with the `gamelog` console command in-game.)
1. Please don't report issues with modified versions of OpenTTD (patchpacks and similar).
1. Please don't report issues with modified versions of OpenTTD (patchpacks, unofficial ports, and similar).
2.**Use the GitHub issue search**--- check if the issue has already been
2.**Use the GitHub issue search**— check if the issue has already been
reported.
3.**Check if the issue has been fixed**--- try to reproduce it using the latest `nightly` build of OpenTTD, available from https://www.openttd.org
3.**Check if the issue has been fixed**— try to reproduce it using the latest `nightly` build of OpenTTD, available from https://www.openttd.org
4.**Isolate the problem**--- ideally create reproduceable steps with an attached savegame and screenshots. Try to use few or no NewGRFs, AIs etc if possible.
4.**Isolate the problem**— ideally create reproducible steps with an attached savegame and screenshots. Try to use few or no NewGRFs, AIs etc if possible.
A good bug report shouldn't leave others needing to chase you up for more information.
Please try to be as detailed as possible in your report.
@@ -69,13 +76,15 @@ Example:
> causing the bug, and potential solutions (and your opinions on their
> merits).
## Feature requests
Before opening a feature request, please take a moment to find out whether your idea fits with the scope and aims of the project.
Before opening a feature request, please take a moment to find out whether your idea fits with the [scope and goals](./CONTRIBUTING.md#project-goals) of the project.
It's up to *you* to make a strong case to convince the project's developers of the merits of this feature.
Please provide as much detail and context as possible. This means don't request for a solution, but describe the problem you see and how/why you think it should be fixed.
Please provide as much detail and context as possible.
This means don't request for a solution, but describe the problem you see and how/why you think it should be fixed.
For feature request we have a strict policy.
@@ -85,17 +94,21 @@ Although we really appreciate feedback and ideas, we will close feature requests
Many of those ideas etc do have a place on the [forums](https://www.tt-forums.net); and if enough people like it, someone will stand up and make it.
It's usually best discuss in [irc](https://wiki.openttd.org/IRC_channel) before opening a feature request or working on a large feature in a fork.
It's usually best discuss in [irc](https://wiki.openttd.org/en/Development/IRC%20channel) before opening a feature request or working on a large feature in a fork.
Discussion in irc can take time, but it can be productive and avoid disappointment :)
## Pull requests
Good pull requests—patches, improvements, new features—are a fantastic help.
They should remain focused in scope and avoid containing unrelated commits.
**Please ask first** before embarking on any significant pull request (e.g. implementing features, refactoring code, porting to a different language), otherwise you risk spending a lot of time working on something that the project's developers might not want to merge into the project.
Pull requests should fit with the [goals of the project](./CONTRIBUTING.md#project-goals).
Please adhere to the [coding guidelines](#code-guidelines) used throughout the project (indentation, accurate comments, etc.) and any other requirements (such as test coverage).
**Please do ask first** before embarking on any significant pull request (e.g. implementing features, refactoring code, porting to a different language), otherwise you risk spending a lot of time working on something that the project's developers might not want to merge into the project.
Every pull request should have a clear scope, with no unrelated commits.
[Code style](https://wiki.openttd.org/en/Development/Coding%20style) must be complied with for pull requests to be accepted; this also includes [commit message format](https://wiki.openttd.org/en/Development/Coding%20style#commit-message).
Adhering to the following process is the best way to get your work included in the project:
@@ -123,8 +136,8 @@ contain your feature, change, or fix:
4. Commit your changes in logical chunks. Please adhere to these [git commit message guidelines](https://wiki.openttd.org/Commit_style#Commit_message) or your code is unlikely to be merged into the main project.
Use Git's [interactive rebase](https://help.github.com/articles/interactive-rebase) feature to tidy up your commits before making them public.
4. Commit your changes in logical chunks. Please adhere to these [git commit message guidelines](https://wiki.openttd.org/en/Development/Coding%20style#commit-message) or your code is unlikely to be merged into the main project.
Use Git's [interactive rebase](https://docs.github.com/en/get-started/using-git/about-git-rebase) feature to tidy up your commits before making them public.
5. Locally rebase the upstream development branch into your topic branch:
@@ -147,17 +160,8 @@ git push
7. [Open a Pull Request](https://help.github.com/articles/using-pull-requests/) with a clear title and description against the `master` branch.
**IMPORTANT**: By submitting a patch, you agree to the [License](#license).
**IMPORTANT**: By submitting a pull request or patch, you agree to the [License](#license) and the [Privacy Notice](CONTRIBUTING.md#privacy-notice).
### Privacy Notice
We would like to make you aware that contributing to OpenTTD via git will permanently store the name and email address you provide as well as the actual changes and the time and date you made it inside git's version history.
This is inevitable, because it is a main feature of git. If you are concerned about your privacy, we strongly recommend to use "Anonymous <anonymous@openttd.org>" as the git commit author. We might refuse anonymous contributions if malicious intent is suspected.
Please note that the contributor identity, once given, is used for copyright verification and to provide proof should a malicious commit be made. As such, the [EU GDPR](https://www.eugdpr.org/key-changes.html) "right to be forgotten" does not apply, as this is an overriding legitimate interest.
Please also note that your commit is public and as such will potentially be processed by many third-parties. Git's distributed nature makes it impossible to track where exactly your commit, and thus your personal data, will be stored and be processed. If you would not like to accept this risk, please do either commit anonymously or refrain from contributing to the OpenTTD project.
### Pull request validation
@@ -165,17 +169,101 @@ Continuous integration (CI) tools monitor pull requests, and help us identify bu
The results of the CI tests will show on your pull request.
By clicking on Details you can further zoom in; in case of a failure it will show you why it failed. In case of success it will report how awesome you were.
By clicking on Details you can further zoom in; in case of a failure it will show you why it failed.
In case of success it will report how awesome you were.
## Code guidelines
Tip: [commit message format](https://wiki.openttd.org/en/Development/Coding%20style#commit-message) is a common reason for pull requests to fail validation.
[Code style](https://wiki.openttd.org/Coding_style) must be adhered to for pull requests to be accepted
## License
### Are there any development docs?
There is no single source for OpenTTD development docs. It's a complex project with a long history, and multiple APIs.
A good entry point is [Development](https://wiki.openttd.org/en/Development/) on the OpenTTD wiki; this provides links to wiki documentation and other sources.
The GitHub repo also includes some non-comprehensive documentation in [/docs](./docs).
You may also want the guide to [compiling OpenTTD](./COMPILING.md).
## Project goals
### What are the goals of the official branch?
The main goals of the official branch are:
- Stay faithful to the original gameplay from Transport Tycoon Deluxe
- Improve the user interface
- Allow extending the gameplay with add-ons / mods via supported content APIs
- Provide a (relatively) stable core for both players of the official branch, and for authors of add-ons and maintainers of patchpacks
In contrast, extending or altering the gameplay of the base game is not encouraged.
The rationale behind these goals is that people have different opinions about what OpenTTD is and what it should be.
When it comes to gameplay, there are at least these groups of people:
- *Model railway (mostly singleplayer)*: build "realistic" landscapes, roleplay a world, or even replicate historical scenarios
- *Economical challenge (mostly singleplayer)*: run a business with economical challenges
- *Transport challenge (singleplayer or cooperative multiplayer)*: build efficient track layouts with high cargo throughput and tons of vehicles
- *Competitive speed run (competitive multiplayer)*: maximize some goal in some limited amount of time
When it comes to gameplay features there are at least these groups of interests:
- *Control freak:* micromanagement like conditional orders, refitting and loading etc.
- *Casual:* automatisation like cargodist, path based signalling etc.
To please everyone, the official branch tries to stay close to the original gameplay; after all, that is what everyone brought here.
The preferred method to alter and extent the gameplay is via add-ons like NewGRF and GameScripts.
For a long time, the official branch was also open to features which could be enabled/disabled, but the corner-cases that came with some configurations have rendered some parts of the code very complicated.
Today, new features have to work with all the already existing features, which is not only challenging in corner cases, but also requires spending considerable more work than just "making it work in the game mode that I play".
The preferred method to introduce new gameplay features is to extend the content APIs, supporting ever more add-on content / mods.
This moves conflict-solving away from the codebase to content authors / players.
It is more accepted for add-ons not working together than the base game not working with certain setting combinations.
In general the game should allow anything that doesn't violate basic rules, but it should warn players if they take potentially dangerous or "stupid" actions.
For example, players are not prevented from starting vehicles without orders, but will receive a warning about vehicles having too few orders.
This lack of limitation has led to players challenging themselves to create networks where all vehicles have no orders, increasing gameplay possibilities.
### I do not agree with the goals of the official branch, what can I do instead?
Fork! There is a rich history of experimental patches for OpenTTD.
Many of these will never be accepted for core, but are creative and interesting ways to modify OpenTTD.
Sometimes patches are combined into long-running patchpacks, modified OpenTTD versions which can be downloaded by anyone, or modified OpenTTD clients for dedicated multiplayer servers.
One of the reasons to keep core relatively stable is to make life easier for patch authors and patchpack maintainers where possible.
Patchpack discussions and related topics may be found in community sites such as [TT-Forums development section](https://www.tt-forums.net/viewforum.php?f=33).
## Legal stuff
### License
By contributing your code, you agree to license your contribution under the [GPL v2](https://github.com/OpenTTD/OpenTTD/blob/master/COPYING.md).
### Privacy Notice
We would like to make you aware that contributing to OpenTTD via git will permanently store the name and email address you provide as well as the actual changes and the time and date you made it inside git's version history.
This is inevitable, because it is a main feature of git.
If you are concerned about your privacy, we strongly recommend to use "Anonymous <anonymous@openttd.org>" as the git commit author. We might refuse anonymous contributions if malicious intent is suspected.
Please note that the contributor identity, once given, is used for copyright verification and to provide proof should a malicious commit be made.
As such, the [EU GDPR](https://www.eugdpr.org/key-changes.html) "right to be forgotten" does not apply, as this is an overriding legitimate interest.
Please also note that your commit is public and as such will potentially be processed by many third-parties.
Git's distributed nature makes it impossible to track where exactly your commit, and thus your personal data, will be stored and be processed.
If you would not like to accept this risk, please do either commit anonymously or refrain from contributing to the OpenTTD project.
By contributing your code, you agree to license your contribution under the [GPL v2](https://github.com/OpenTTD/OpenTTD/blob/master/COPYING).
### Attribution of this Contributing Guide
This contributing guide is adapted from [Bootstrap](https://github.com/twbs/bootstrap/blob/master/CONTRIBUTING.md) under the [Creative Commons Attribution 3.0 Unported License](https://github.com/twbs/bootstrap/blob/master/docs/LICENSE) terms for Bootstrap documentation.
This contributing guide is adapted from [Bootstrap](https://github.com/twbs/bootstrap/blob/main/.github/CONTRIBUTING.md) under the [Creative Commons Attribution 3.0 Unported License](https://creativecommons.org/licenses/by/3.0/) terms for Bootstrap documentation.
The GDPR notice is adapted from [rsyslog](https://github.com/rsyslog/rsyslog/blob/master/CONTRIBUTING.md) under the [GNU General Public License](https://github.com/rsyslog/rsyslog/blob/master/COPYING).
# OpenTTD is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2.
# OpenTTD is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
# OpenTTD is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2.
# OpenTTD is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
# See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with OpenTTD. If not, see <http://www.gnu.org/licenses/>.
#
# Creation of bundles
#
# The revision is needed for the bundle name and creating an OSX application bundle.
# OpenTTD is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2.
# OpenTTD is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
# See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with OpenTTD. If not, see <http://www.gnu.org/licenses/>.
#
# Building requires GRFCodec.
#
# Recent versions (including sources) can be found at:
# OpenTTD is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2.
# OpenTTD is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
# See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with OpenTTD. If not, see <http://www.gnu.org/licenses/>.
# OpenTTD is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2.
# OpenTTD is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
# See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with OpenTTD. If not, see <http://www.gnu.org/licenses/>.
$(Q)./$(STRGEN)$(STRGEN_FLAGS) -s $(LANG_DIR) -d $(LANG_OBJS_DIR) $< $(LANG_ERRORS)&& cp $@$(BIN_DIR)/lang ||true# Do not fail all languages when one fails
# OpenTTD is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2.
# OpenTTD is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
# See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with OpenTTD. If not, see <http://www.gnu.org/licenses/>.
#
# Makefile for creating bundles of MSVC's binaries in the same way as we make
# the zip bundles for ALL other OSes.
#
# Usage: make -f Makefile.msvc PLATFORM=[Win32|x64] BUNDLE_NAME=openttd-<version>-win[32|64]
# or make -f Makefile.msvc PLATFORM=[Win32|x64] BUNDLE_NAME=OTTD-win[32|64]-nightly-<revision>
#
# Check if we want to show what we are doing
ifdefVERBOSE
Q=
else
Q= @
endif
AWK="awk"
ROOT_DIR:=$(shell pwd)
BIN_DIR="$(ROOT_DIR)/bin"
SRC_DIR="$(ROOT_DIR)/src"
BUNDLE_DIR="$(ROOT_DIR)/bundle"
BUNDLES_DIR="$(ROOT_DIR)/bundles"
TTD= openttd.exe
PDB= openttd.pdb
MODE= Release
TARGET:=$(shell echo$(PLATFORM)| sed "s@win64@x64@;s@win32@Win32@")
# OpenTTD is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2.
# OpenTTD is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
# See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with OpenTTD. If not, see <http://www.gnu.org/licenses/>.
# OpenTTD is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2.
# OpenTTD is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
# See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with OpenTTD. If not, see <http://www.gnu.org/licenses/>.
- most people should choose the 'stable' version, as this has been more extensively tested
- the 'nightly' version includes the latest changes and features, but may sometimes be less reliable
### 2.1) Reporting bugs
OpenTTD is also available for free on [Steam](https://store.steampowered.com/app/1536610/OpenTTD/), [GOG.com](https://www.gog.com/game/openttd), and the [Microsoft Store](https://www.microsoft.com/p/openttd-official/9ncjg5rvrr1c). On some platforms OpenTTD will be available via your OS package manager or a similar service.
First of all, check whether the bug is not already known. Do this by looking
through the file called 'known-bugs.txt' which is distributed with OpenTTD
like this readme.
For tracking our bugs we are using GitHub's issue tracker. You can find
the tracker at https://github.com/OpenTTD/OpenTTD/issues. Before actually
reporting take a look through the already reported bugs there to see if
the bug is already known. The 'known-bugs.txt' file might be a bit outdated
at the moment you are reading it as only bugs known before the release
are documented there. Also look through the recently closed bugs.
## 1.2) OpenTTD gameplay manual
When you are sure it is not already reported you should:
OpenTTD has a [community-maintained wiki](https://wiki.openttd.org/), including a gameplay manual and tips.
- Make sure you are running a recent version, i.e. run the latest stable or
nightly based on where you found the bug.
- Make sure you are not running a non-official binary, like a patch pack.
When you are playing with a patch pack you should report any bugs to the
forum thread related to that patch pack.
- Make it reproducible for the developers. In other words, create a savegame
in which you can reproduce the issue once loaded. It is very useful to give
us the crash.dmp, crash.sav, crash.log and crash screenshot which are
created on crashes.
- Check whether the bug is already reported on our bug tracker. This includes
searching for recently closed bug reports as the bug might already be fixed.
After you have done all that you can report the bug. Please include the
following information in your bug report:
## 1.3) Supported platforms
-OpenTTD version (PLEASE test the latest Git revision/nightly build)
- Bug details, including instructions how to reproduce it
- Platform (Windows, Linux, FreeBSD, …) and compiler (including version) if
you compiled OpenTTD yourself.
- The processor architecture of your OS (32-bit Windows, 64-bit Windows,
Linux on an ARM, Mac OS X on a PowerPC, etc.)
- Attach a saved game **and** a screenshot if possible
- If this bug only occurred recently please note the last version without
the bug and the first version including the bug. That way we can fix it
quicker by looking at the changes made.
- Attach crash.dmp, crash.log and crash.sav. These files are usually created
next to your openttd.cfg. The crash handler will tell you the location.
OpenTTD has been ported to several platforms and operating systems.
### 2.2) Reporting desyncs
The currently supported platforms are:
As desyncs are hard to make reproducible OpenTTD has the ability to log all
actions done by clients so we can replay the whole game in an effort to make
desyncs better reproducible. You need to turn this ability on. When turned
on an automatic savegame will be made once the map has been constructed in
the 'save/autosave' directory, see OpenTTD directories to know where to find
this directory. Furthermore the log file 'commands-out.log' will be created
and all actions will be written to there.
- Linux (SDL (OpenGL and non-OpenGL))
- macOS (universal) (Cocoa)
- Windows (Win32 GDI / OpenGL)
To enable the desync debugging you need to set the debug level for 'desync'
to at least 1. You do this by starting OpenTTD with '`-d desync=<level>`' as
parameter or by typing '`debug_level desync=<level>`' in OpenTTD's internal
console.
The desync debug levels are:
Other platforms may also work (in particular various BSD systems), but we don't actively test or maintain these.
- 0: nothing.
- 1: dumping of commands to 'commands-out.log'.
- 2: same as 1 plus checking vehicle caches and dumping that too.
- 3: same as 2 plus monthly saves in autosave.
- 4 and higher: same as 3
### 1.3.1) Legacy support
Platforms, languages and compilers change.
We'll keep support going on old platforms as long as someone is interested in supporting them, except where it means the project can't move forward to keep up with language and compiler features.
Restarting OpenTTD will overwrite 'commands-out.log'. OpenTTD will not remove
the savegames (dmp_cmds_*.sav) made by the desync debugging system, so you
have to occasionally remove them yourself!
We guarantee that every revision of OpenTTD will be able to load savegames from every older revision (excepting where the savegame is corrupt).
Please report a bug if you find a save that doesn't load.
The naming format of the desync savegames is as follows:
dmp_cmds_XXXXXXXX_YYYYYYYY.sav. The XXXXXXXX is the hexadecimal representation
of the generation seed of the game and YYYYYYYY is the hexadecimal
representation of the date of the game. This sorts the savegames by game and
then by date making it easier to find the right savegames.
## 1.4) Installing and running OpenTTD
When a desync has occurred with the desync debugging turned on you should file
a bug report with the following files attached:
OpenTTD is usually straightforward to install, but for more help the wiki [includes an installation guide](https://wiki.openttd.org/en/Manual/Installation).
- commands-out.log as it contains all the commands that were done
- the last saved savegame (search for the last line beginning with
'save: dmp_cmds_' in commands-out.log). We use this savegame to check
whether we can quickly reproduce the desync. Otherwise we will need …
- the first saved savegame (search for the first line beginning with 'save'
where the first part, up to the last underscore '_', is the same). We need
this savegame to be able to reproduce the bug when the last savegame is not
old enough. If you loaded a scenario or savegame you need to attach that.
- optionally you can attach the savegames from around 50%, 75%, 85%, 90% and
95% of the game's progression. We can use these savegames to speed up the
reproduction of the desync, but we should be able to reproduce these
savegames based on the first savegame and commands-out.log.
- in case you use any NewGRFs you should attach the ones you used unless
we can easily find them ourselves via bananas or when they are in the
#openttdcoop pack.
OpenTTD needs some additional graphics and sound files to run.
Do NOT remove the dmp_cmds savegames of a desync you have reported until the
desync has been fixed; if you, by accident, send us the wrong savegames we
will not be able to reproduce the desync and thus will be unable to fix it.
For some platforms these will be downloaded during the installation process if required.
## 3.0) Supported platforms
For some platforms, you will need to refer to [the installation guide](https://wiki.openttd.org/en/Manual/Installation).
OpenTTD has been ported to several platforms and operating systems. It should
not be very difficult to port it to a new platform. The currently working
platforms are:
- BeOS (SDL or Allegro)
- DOS (Allegro)
- FreeBSD (SDL)
- Linux (SDL or Allegro)
- macOS (universal) (Cocoa video and sound drivers)
- MorphOS (SDL)
- OpenBSD (SDL)
- OS/2 (SDL)
- Windows (Win32 GDI (faster) or SDL or Allegro)
## 4.0) Installing and running OpenTTD
Installing OpenTTD is fairly straightforward. Either you have downloaded an
archive which you have to extract to a directory where you want OpenTTD to
be installed, or you have downloaded an installer, which will automatically
extract OpenTTD in the given directory.
OpenTTD looks in multiple locations to find the required data files (described
in section 4.2). Installing any 3rd party files into a 'shared' location has
the advantage that you only need to do this step once, rather than copying the
data files into all OpenTTD versions you have.
Savegames, screenshots, etc are saved relative to the config file (openttd.cfg)
currently being used. This means that if you use a config file in one of the
shared directories, savegames will reside in the save/ directory next to the
openttd.cfg file there.
If you want savegames and screenshots in the directory where the OpenTTD binary
resides, simply have your config file in that location. But if you remove this
config file, savegames will still be in this directory (see notes in
section 4.2 'OpenTTD directories')
OpenTTD comes without AIs, so if you want to play with AIs you have to download
them. The easiest way is via the 'Check Online Content' button in the main menu.
You can select some AIs that you think are compatible with your playing style.
Another way is manually downloading the AIs from the forum although then you
need to make sure that you install all the required AI libraries too; they get
automatically selected (and downloaded) if you get the AIs via the 'Check
Online Content'. If you do not have an AI but have configured OpenTTD to start
an AI a message will be shown that the 'dummy' AI has been started.
### 4.1) (Required) 3rd party files
Before you run OpenTTD, you need to put the game's data files into a baseset/
directory which can be located in various places addressed in the following
section.
For OpenTTD you need to acquire some third party data files. For this you have
the choice of using the original Transport Tycoon Deluxe data files or a set
of free data files.
Do NOT copy files included with OpenTTD into 'shared' directories (explained in
the following sections) as sooner or later you will run into graphical glitches
when using other versions of the game.
#### 4.1.1) Free graphics and sound files
### 1.4.1) Free graphics and sound files
The free data files, split into OpenGFX for graphics, OpenSFX for sounds and
OpenMSX for music can be found at:
- https://www.openttd.org/download-opengfx for OpenGFX
- https://www.openttd.org/download-opensfx for OpenSFX
- https://www.openttd.org/download-openmsx for OpenMSX
- https://www.openttd.org/downloads/opengfx-releases/latest for OpenGFX
- https://www.openttd.org/downloads/opensfx-releases/latest for OpenSFX
- https://www.openttd.org/downloads/openmsx-releases/latest for OpenMSX
Please follow the readme of these packages about the installation procedure.
The Windows installer can optionally download and install these packages.
#### 4.1.2) Original Transport Tycoon Deluxe graphics and sound files
If you want to play with the original Transport Tycoon Deluxe data files you
have to copy the data files from the CD-ROM into the baseset/ directory. It
does not matter whether you copy them from the DOS or Windows version of
Transport Tycoon Deluxe. The Windows install can optionally copy these files.
### 1.4.2) Original Transport Tycoon Deluxe graphics and sound files
If you want to play with the original Transport Tycoon Deluxe data files you have to copy the data files from the CD-ROM into the baseset/ directory.
It does not matter whether you copy them from the DOS or Windows version of Transport Tycoon Deluxe.
The Windows install can optionally copy these files.
You need to copy the following files:
- sample.cat
- trg1r.grf or TRG1.GRF
@@ -233,607 +99,116 @@ You need to copy the following files:
- trgir.grf or TRGI.GRF
- trgtr.grf or TRGT.GRF
#### 4.1.3) Original Transport Tycoon Deluxe music
If you want the Transport Tycoon Deluxe music, copy the appropriate files from
the original game into the baseset folder.
### 1.4.3) Original Transport Tycoon Deluxe music
If you want the Transport Tycoon Deluxe music, copy the appropriate files from the original game into the baseset folder.
- TTD for Windows: All files in the gm/ folder (gm_tt00.gm up to gm_tt21.gm)
- TTD for DOS: The GM.CAT file
- Transport Tycoon Original: The GM.CAT file, but rename it to GM-TTO.CAT
#### 4.1.4) AIs
If you want AIs use the in-game content downloader. If for some reason that is
not possible or you want to use an AI that has not been uploaded to the content
download system download the tar file and place it in the ai/ directory. If the
AI needs libraries you will have to download those too and put them in the
ai/library/ directory. All AIs and AI Libraries that have been uploaded to
the content download system can be found at https://noai.openttd.org/downloads.
The AIs and libraries can be found their in the form of .tar.gz packages.
OpenTTD can read inside tar files but it does not extract .tar.gz files by itself.
To figure out which libraries you need for an AI you have to start the AI and
wait for an error message to pop up. The error message will tell you
'could not find library "lib-name"'. Download that library and try again.
#### 4.1.5) Game scripts
If you want an extra challenge in OpenTTD you can download so-called game
scripts via the in-game content downloader. These game scripts have varying
functionality, though they can generally influence town growth, subsidies, add
goals to reach or provide a different ranking system.
If you download a game script manually you have to follow the same rules as for
AIs, except that game scripts are placed in the game/ directory instead of the
ai/ directory.
### 4.2) OpenTTD directories
OpenTTD uses its own directory to store its required 3rd party base set files
(see section 4.1 'Required 3rd party files') and non-compulsory extension and
configuration files. See below for their proper place within this OpenTTD main
data directory.
The main OpenTTD directories can be found in various locations, depending on
your operating system:
1. The current working directory (from where you started OpenTTD)
For non-Windows operating systems OpenTTD will not scan for files in this
directory if it is your personal directory, i.e. '~/', or when it is the
root directory, i.e. '/'.
2. Your personal directory
- Windows:
-`C:\My Documents\OpenTTD` (95, 98, ME)
-`C:\Documents and Settings\<username>\My Documents\OpenTTD` (2000, XP)
- Versions 4.1 and earlier give bogus warnings about uninitialised variables.
- Versions 4.4, 4.6 give bogus warnings about freeing non-heap objects.
- Versions 4.6 and later give invalid warnings when lto is enabled.
- Intel C++ Compiler (ICC) 12.0.
- Clang/LLVM 2.9 - 3.0
Version 2.9 gives bogus warnings about code nonconformity.
Add-on content can also be installed manually, but that's more complicated; the [OpenTTD wiki](https://wiki.openttd.org/) may offer help with that, or the [OpenTTD directory structure guide](./docs/directory_structure.md).
The following compilers are known not to compile OpenTTD:
### 1.5.1) AI opponents
- Microsoft Visual C++ (MSVC) 2013 and earlier.
These old versions do not support modern C++ language features.
- GNU Compiler Collection (GCC) 3.2 and earlier.
These old versions fail due to OpenTTD's template usage.
- GNU Compiler Collection (GCC) 4.5. It optimizes enums too aggressively.
See https://github.com/OpenTTD/OpenTTD/issues/5513 and references therein.
- Intel C++ Compiler (ICC) 11.1 and earlier.
- Version 10.0 and earlier fail a configure check and fail with recent
system headers.
- Version 10.1 fails to compile station_gui.cpp.
- Version 11.1 fails with an internal error when compiling network.cpp.
- Clang/LLVM 2.8 and earlier.
- (Open) Watcom.
OpenTTD comes without AI opponents, so if you want to play with AIs you have to download them.
If any of these compilers can compile OpenTTD again, please let us know.
Patches to support more compilers are welcome.
The easiest way is via the 'Check Online Content' button in the main menu.
### 7.3) Compilation of base sets
You can select some AIs that you think are compatible with your playing style.
To recompile the extra graphics needed to play with the original Transport
Tycoon Deluxe graphics you need GRFCodec (which includes NFORenum) as well.
GRFCodec can be found at https://www.openttd.org/download-grfcodec.
The compilation of these extra graphics does generally not happen, unless
you remove the graphics file using '`make maintainer-clean`'.
AI help and discussions may also be found in the [AI section of the forum](https://www.tt-forums.net/viewforum.php?f=65).
Re-compilation of the base sets, thus also use of '`--maintainer-clean`' can
leave the repository in a modified state as different grfcodec versions can
cause binary differences in the resulting grf. Also translations might have
been added for the base sets which are not yet included in the base set
information files. Use the configure option '`--without-grfcodec`' to avoid
modification of the base set files by the build process.
### 1.5.2) Scenarios and height maps
## 8.0) Translating
Scenarios and heightmaps can be added via the 'Check Online Content' button in the main menu.
See https://www.openttd.org/development for up-to-date information.
### 1.5.3) NewGRFs
The use of the online Translator service, located at
https://translator.openttd.org, is highly encouraged. For getting an account
simply follow the guidelines in the FAQ of the translator website.
A wide range of add-content is available as NewGRFs, including vehicles, industries, stations, landscape objects, town names and more.
If for some reason the website is down for a longer period of time, the
information below might be of help.
NewGRFs can be added via the 'Check Online Content' button in the main menu.
Please contact the translations manager (https://www.openttd.org/contact)
before beginning the translation process! This avoids double work, as
someone else may have already started translating to the same language.
See also the wiki [guide to NewGRFs](https://wiki.openttd.org/en/Manual/NewGRF) and [the forum graphics development section](https://www.tt-forums.net/viewforum.php?f=66).
### 8.1) Translation
### 1.5.4) Game scripts
So, now that you have notified the development team about your intention to
translate (You did, right? Of course you did.) you can pick up english.txt
(found in the Git repository under /src/lang) and translate.
Game scripts can provide additional challenges or changes to the standard OpenTTD gameplay, for example setting transport goals, or changing town growth behaviour.
You must change the first two lines of the file appropriately:
Game scripts can be added via the 'Check Online Content' button in the main menu.
##name English-Name-Of-Language
##ownname Native-Name-Of-Language
Note: Do not alter the following parts of the file:
See also the wiki [guide to game scripts](https://wiki.openttd.org/en/Manual/Game%20script) and [the forum graphics game script section](https://www.tt-forums.net/viewforum.php?f=65).
- String identifiers (the first word on each line)
- Parts of the strings which are in curly braces (such as {STRING})
- Lines beginning with ## (such as ##id), other than the first two lines
of the file
### 8.2) Previewing
In order to view the translation in the game, you need to compile your language
file with the strgen utility. As this utility is tailored to a specific OpenTTD
version, you need to compile it yourself. Just take the normal OpenTTD sources
and build that. During the build process the strgen utility will be made.
### 1.6) OpenTTD directories
strgen is a command-line utility. It takes the language filename as parameter.
OpenTTD uses its own directory structure to store game data, add-on content etc.
Example:
For more information, see the [directory structure guide](./docs/directory_structure.md).
strgen lang/german.txt
### 1.7) Compiling OpenTTD
This results in compiling german.txt and produces another file named german.lng.
Any missing strings are replaced with the English strings. Note that it looks
for english.txt in the lang subdirectory, which is where your language file
should also be.
That is all! You should now be able to select the language in the game options.
If you want to compile OpenTTD from source, instructions can be found in [COMPILING.md](./COMPILING.md).
## 9.0) Troubleshooting
To see all startup options available to you, start OpenTTD with the
'`./openttd -h`' option. This might help you tweak some of the settings.
If the game is acting strange and you feel adventurous you can try the
'`-d [[<name>=]<level>]`' flag, where the higher levels will give you more
debugging output. The 'name' variable can help you to display only some type of
debugging messages. This is mostly undocumented so best is to look in the
source code file debug.c for the various debugging types. For more information
look at https://wiki.openttd.org/Command_line.
The most frequent problem is missing data files. Please install OpenGFX and
possibly OpenSFX and OpenMSX. See section 4.1.1 for more information.
Under certain circumstance, especially on Ubuntu OpenTTD can be extremely slow
and/or freeze. See known-bugs.txt for more information and how to solve this
problem on your computer.
Under Windows 98 and lower it is impossible to use a dedicated server; it will
fail to start. Perhaps this is for the better because those OSes are not known
for their stability.
With the added support for font-based text selecting a non-latin language can
result in lots of question marks ('?') being shown on screen. Please open your
configuration file (openttd.cfg - see Section 4.2 for where to find it)
and add a suitable font for the small, medium and / or large font, e.g.:
## 2.0) Contact and Community
small_font = "Tahoma"
medium_font = "Tahoma"
large_font = "Tahoma"
You should use a font name like 'Tahoma' or a path to the desired font.
Any NewGRF file used in a game is stored inside the savegame and will refuse to
load if you do not have that NewGRF file available. A list of missing files can
be viewed in the NewGRF window accessible from the file load dialogue window.
You can try to obtain the missing files from that NewGRF dialogue or – if they
are not available online – you can search manually through our
[forum's graphics development section](https://www.tt-forums.net/viewforum.php?f=66)
or [GRFCrawler](https://grfcrawler.tt-forums.net). Put the NewGRF files in
OpenTTD's newgrf folder (see section 4.2 'OpenTTD directories') and rescan the
list of available NewGRFs. Once you have all missing files, you are set to go.
## 10.0) Licensing
OpenTTD is licensed under the GNU General Public License version 2.0. For
the complete license text, see the file 'COPYING'. This license applies
to all files in this distribution, except as noted below.
The squirrel implementation in src/3rdparty/squirrel is licensed under
the Zlib license. See src/3rdparty/squirrel/COPYRIGHT for the complete
license text.
The md5 implementation in src/3rdparty/md5 is licensed under the Zlib
license. See the comments in the source files in src/3rdparty/md5 for
the complete license text.
The implementations of Posix getaddrinfo and getnameinfo for OS/2 in
src/3rdparty/os2 are distributed partly under the GNU Lesser General Public
License 2.1, and partly under the (3-clause) BSD license. The exact licensing
terms can be found in src/3rdparty/os2/getaddrinfo.c resp.
src/3rdparty/os2/getnameinfo.c.
The exe2coff implementation in os/dos/exe2coff is available under the
GPL, with a number of additional terms. See os/dos/exe2coff/copying and
os/dos/exe2coff/copying.dj for the exact licensing terms.
The CWSDPMI implementation in os/dos/cwsdpmi is distributed under a
custom binary-only license that prohibits modification. The exact
licensing terms can be found in os/dos/cwsdpmi/cwsdpmi.txt. The sources
for these files can be downloaded at its author site, at
- Marcin Grzegorczyk - For his TTDPatch work and documentation of Transport Tycoon Deluxe internals and track foundations
- Stefan Meißner (sign_de) - For his work on the console
- Mike Ragsdale - OpenTTD installer
- Christian Rosentreter (tokai) - MorphOS / AmigaOS port
- Richard Kempton (RichK67) - Additional airports, initial TGP implementation
- Alberto Demichelis - Squirrel scripting language
- L. Peter Deutsch - MD5 implementation
- Michael Blunck - For revolutionizing TTD with awesome graphics
- George - Canal graphics
- Andrew Parkhouse (andythenorth) - River graphics
- David Dallaston (Pikka) - Tram tracks
- All Translators - For their support to make OpenTTD a truly international game
- Bug Reporters - Thanks for all bug reports
- Chris Sawyer - For an amazing game!
'Official' channels
- [OpenTTD website](https://www.openttd.org)
- IRC chat using #openttd on irc.oftc.net [more info about our irc channel](https://wiki.openttd.org/en/Development/IRC%20channel)
- [OpenTTD on Github](https://github.com/OpenTTD/) for code repositories and for reporting issues
- [forum.openttd.org](https://forum.openttd.org/) - the primary community forum site for discussing OpenTTD and related games
- [OpenTTD wiki](https://wiki.openttd.org/) community-maintained wiki, including topics like gameplay guide, detailed explanation of some game mechanics, how to use add-on content (mods) and much more
'Unofficial' channels
- the OpenTTD wiki has a [page listing OpenTTD communities](https://wiki.openttd.org/en/Community/Community) including some in languages other than English
### 2.1) Contributing to OpenTTD
We welcome contributors to OpenTTD. More information for contributors can be found in [CONTRIBUTING.md](./CONTRIBUTING.md)
### 2.2) Reporting bugs
Good bug reports are very helpful. We have a [guide to reporting bugs](./CONTRIBUTING.md#bug-reports) to help with this.
Desyncs in multiplayer are complex to debug and report (some software development skils are required).
Instructions can be found in [debugging and reporting desyncs](./docs/debugging_desyncs.md).
### 2.3) Translating
OpenTTD is translated into many languages. Translations are added and updated via the [online translation tool](https://translator.openttd.org).
## 3.0) Licensing
OpenTTD is licensed under the GNU General Public License version 2.0.
For the complete license text, see the file '[COPYING.md](./COPYING.md)'.
This license applies to all files in this distribution, except as noted below.
The squirrel implementation in `src/3rdparty/squirrel` is licensed under the Zlib license.
See `src/3rdparty/squirrel/COPYRIGHT` for the complete license text.
The md5 implementation in `src/3rdparty/md5` is licensed under the Zlib license.
See the comments in the source files in `src/3rdparty/md5` for the complete license text.
The implementations of Posix `getaddrinfo` and `getnameinfo` for OS/2 in `src/3rdparty/os2` are distributed partly under the GNU Lesser General Public License 2.1, and partly under the (3-clause) BSD license.
The exact licensing terms can be found in `src/3rdparty/os2/getaddrinfo.c` resp. `src/3rdparty/os2/getnameinfo.c`.
The fmt implementation in `src/3rdparty/fmt` is licensed under the MIT license.
See `src/3rdparty/fmt/LICENSE.rst` for the complete license text.
* OpenTTD is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2.
* OpenTTD is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2.
* OpenTTD is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2.
* OpenTTD is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2.
* OpenTTD is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
* See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with OpenTTD. If not, see <http://www.gnu.org/licenses/>.
* OpenTTD is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2.
* OpenTTD is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
* See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with OpenTTD. If not, see <http://www.gnu.org/licenses/>.
* OpenTTD is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2.
* OpenTTD is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2.
* OpenTTD is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2.
* OpenTTD is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2.
* OpenTTD is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2.
* OpenTTD is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2.
* OpenTTD is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2.
* OpenTTD is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2.
* OpenTTD is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
* See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with OpenTTD. If not, see <http://www.gnu.org/licenses/>.
* OpenTTD is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2.
* OpenTTD is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
* See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with OpenTTD. If not, see <http://www.gnu.org/licenses/>.
' OpenTTD is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2.
' OpenTTD is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
' See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with OpenTTD. If not, see <http://www.gnu.org/licenses/>.
Dim FSO
Set FSO = CreateObject("Scripting.FileSystemObject")
Function GetTestList()
Dim retests, i, tests, dir
Set retests = New RegExp
Set GetTestList = CreateObject("Scripting.Dictionary")
retests.Pattern = "ai/regression/tst_*"
retests.Global = True
For i = 0 To WScript.Arguments.Count - 1
Dim test
test = "ai/regression/tst_" & WScript.Arguments.Item(i)
If FSO.FolderExists(test) Then
retests.Pattern = test
Exit For
End If
Next
For Each dir In FSO.GetFolder("ai/regression/").SubFolders
Dim name
name = "ai/regression/" & dir.Name
If retests.Test(name) Then
GetTestList.Add name, name
End If
Next
End Function
Function GetParams()
GetParams = "-snull -mnull -vnull:ticks=30000"
If WScript.Arguments.Count = 0 Then Exit Function
If WScript.Arguments.Item(0) <> "-r" Then Exit Function
GetParams = ""
End Function
Sub FilterFile(filename)
Dim lines, filter, file
Set file = FSO.OpenTextFile(filename, 1)
If Not file.AtEndOfStream Then
lines = file.ReadAll
End If
file.Close
Set filter = New RegExp
filter.Global = True
filter.Multiline = True
filter.Pattern = "0x(\(nil\)|0+)(x0)?"
lines = filter.Replace(lines, "0x00000000")
filter.Pattern = "^dbg: \[script\]"
lines = filter.Replace(lines, "")
filter.Pattern = "^ "
lines = filter.Replace(lines, "ERROR: ")
filter.Pattern = "ERROR: \[1\] \[P\] "
lines = filter.Replace(lines, "")
filter.Pattern = "^dbg: .*\r\n"
lines = filter.Replace(lines, "")
Set file = FSO.OpenTextFile(filename, 2)
file.Write lines
file.Close
End Sub
Function CompareFiles(filename1, filename2)
Dim file, lines1, lines2
Set file = FSO.OpenTextFile(filename1, 1)
If Not file.AtEndOfStream Then
lines1 = file.ReadAll
End IF
file.Close
Set file = FSO.OpenTextFile(filename2, 1)
If Not file.AtEndOfStream Then
lines2 = file.ReadAll
End IF
file.Close
CompareFiles = (lines1 = lines2)
End Function
Function RunTest(test, params, ret)
Dim WshShell, oExec, sav, command
Set WshShell = CreateObject("WScript.Shell")
' Make sure that only one info.nut is present for each test run. Otherwise openttd gets confused.
FSO.CopyFile "ai/regression/regression_info.nut", test & "/info.nut"
* OpenTTD is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2.
* OpenTTD is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
* See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with OpenTTD. If not, see <http://www.gnu.org/licenses/>.
* OpenTTD is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2.
* OpenTTD is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
* See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with OpenTTD. If not, see <http://www.gnu.org/licenses/>.
* OpenTTD is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2.
* OpenTTD is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2.
* OpenTTD is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2.
* OpenTTD is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2.
* OpenTTD is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2.
* OpenTTD is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2.
* OpenTTD is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2.
* OpenTTD is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2.
* OpenTTD is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
* See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with OpenTTD. If not, see <http://www.gnu.org/licenses/>.
* OpenTTD is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2.
* OpenTTD is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
* See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with OpenTTD. If not, see <http://www.gnu.org/licenses/>.
Feature: [GS] Ability to set some extra text in the industry window (#8576)
Feature: Show rainforest under vegetation on smallmap (#8562)
Feature: Automatically determine window size on new install (#8536)
Feature: Towns can build tunnels (#8473)
Feature: Make maximum length of town bridges depend on population (with a minimum limit of 4) (#8439)
Feature: New icons for renaming and go-to-location on GUI windows, and improve consistency of usage (#8455)
Feature: Support for ARM64 on Apple Silicon and Windows (#8340, #8577, #8583)
Feature: Add an option to disable tree growth completely (#8415)
Feature: Support for Emscripten (play-OpenTTD-in-the-browser!) (#8355)
Feature: Show group name as part of the default vehicle name (#8307)
Feature: "Frozen" economy setting that stops production changes and industry closures (#8282)
Feature: New velocity unit "tiles/day" (#8278)
Feature: Option to automatically remove signals when placing rail (#8274)
Feature: Increase max possible distance from border for oil refineries and rigs (#8237)
Feature: Improve tree planting window, and allow planting 'clumps' of trees by dragging in the scenario editor (#8234)
Feature: Indian Rupee (INR) currency (#8136)
Feature: [GS] Ability to give a company exclusive access to an industry (#8115)
Feature: Hotkeys for Land Info window, News window & close error window (#8053, #8266)
Feature: Improve rendering of large viewports (#7962)
Feature: [GS] Influence industry production changes from GameScript (#7912)
Feature: [GS] Push-buttons on storybook pages (#7896)
Feature: Option to group vehicle lists by shared orders (#7028)
Feature: Drag-and-drop vehicles in group GUI for shared order groups (#7028)
Add: [GS] A tile parameter to GSCompany::ChangeBankBalance for showing changes more visually (#8573)
Add: [NewGRF] Allow NewGRF vehicles to query the current rail/road/tram type (#8554)
Add: [Script] ScriptCargo::GetName for the human readable name of cargoes (#8544)
Add: "reload" console command to reload the current scenario or heightmap (#8527)
Add: [NewGRF] Flag to test if inflation is on or off (#8427)
Add: [Script] Native priority queue (useful for things like pathfinders) (#8091)
Add: [NewGRF] Industry behaviour flag to override second cargo production clamping for water industries when using smooth economy (#8079)
Change: [SDL2] Start game on the screen where the cursor is (#8572)
Change: Use a dark background for all profit graphs to increase contrast (#8557)
Change: Reword warning in cheat window (#8538)
Change: Enable the toolbar for road/rail/dock/airport, regardless of vehicle availability (#8521)
Change: For arctic and tropical climates, make sure at least a few hills are generated (#8513)
Change: Destroying a tunnel/bridge now sells the tracks before destroying the tunnel/bridge (#8508)
Change: Move "give money" from client-list to company window (#8500)
Change: [MacOS] Hide Dock and menu when in fullscreen mode (#8487)
Change: Improve performance for complex vehicle chains by resolving sprites less frequently (#8485)
Change: Make engine reliability independent of introduction date (#8470)
Change: Some default settings to improve gameplay for new players - default non-stop orders on, disable inflation, quick goto orders, show track reservations, and more (#8463)
Change: Converting town-owned road types now requires a positive town rating (#8457)
Change: Rework server list buttons for searching LAN/internet servers (#8426)
Change: Add some styling to GS question windows depending on the type (#8422)
Change: [Linkgraph] Speed up game exit by allowing job threads to be aborted early (#8416)
Change: Prevent towns from building dead-end road bridges (#8401)
Change: Send network error to the server before making an emergency save (#8387)
Change: Extend the allowed range for max loan setting up to £2 billion (#8386)
Change: Don't display OS name when exiting the game (#8366)
Change: Save openttd.cfg immediately on changing a setting (#8358)
Change: Autorenew now defaults to on (#8352)
Change: [NewGRF] Also use aircraft property 12 for helicopters (#8347)
Change: Service at depot also resets breakdown chance (#8317)
Change: Use key names instead of characters in hotkey.cfg (#8291)
Change: Allow command cost-estimation while paused (#8222)
Change: Always apply inflation from 1920 to 2090, no matter the game start year (#7589)
Change: Use CMake for build system (#7270)
Change: [Linkgraph] Pause the game when linkgraph jobs lag (#7081)
Change: Place "Group by" above "Sort by" in station window for consistency (#7028)
Fix #8589: Prevent desyncs with vehicle motion counters and NewGRFs (#8591)
Fix #7670: Improve pathfinder performance when lost vehicles are blocked from moving (#8568)
Fix: Inform user if a custom font failed to load due to missing glyphs (#8559)
Fix: Don't allow wagon chains (without an engine) to exceed maximum train length (#8533)
Fix #7619: Super fast NewGRF aircraft could be unable to land (#8531)
Fix: Improve connection retries for the content server in cases of broken networking (#8530)
Fix #7972: Show invalid orders to stations that don't accept the vehicle (#8516)
Fix: Error when trying to clone a vehicle with invalid orders (#8515)
Fix #8050: Various off-by-one errors in how the end-year of the game was used (#8512)
Fix #8332: Aborting vehicle group drag & drop could cause crashes (#8511)
Fix #8168: Allow relocating HQ partially over an existing HQ (#8510)
Fix #8068: Allow selling tram track regardless of bank balance (#8509)
Fix #7604: Prevent houses from wandering away from roads (#8507)
Fix: Make the "password" button the same size as the other buttons in the Company window (#8500)
Fix #7611: Keep news about vehicle accidents around after the vehicle is cleaned up (#8497)
Fix: [MacOS] Full animation in fullscreen mode was reducing the height of the window (#8491)
Fix: [MacOS] Loading custom fonts (#8484)
Fix: Network client makes emergency saves twice if the server is disconnected (#8477)
Fix #8462: Stop towns from trying to build roads on water (#8471)
Fix: [NewGRF] GetCurveSpeedLimit should use the railtype from the current tile (#8466)
Fix #8437: Crash when using certain heliports with certain rotated airports (#8458)
Fix #8437: Planes would land at the wrong height if the top corner of the airport was lowered (#8458)
- Change: Do not display a news message about old vehicles when a replacement for it is activated (#7401)
- Change: When filtering purchase list by cargo type, buy button now performs a refit if required (#7301)
- Change: Don't apply forbid 90 deg turn settings to ships, and make penalties for turns configurable (#7289, #7372)
- Change: Make the chance of an aeroplane crashing at an airport with a short runway independent of plane crash setting (#7302)
- Change: Keep town growth rate in sync with house count (#6777)
- Fix #6219: Improve helicopter's ability to takeoff from commuter and international airports (#7710)
- Fix #6407: Show snowy ground sprites for train depots (#7671)
- Fix: Power/running cost sorting algorithm was not correct when power was higher than running cost (#7561)
- Fix: Tweaks to small-map colours to make dark blue company more visible (#7436, #7450)
- Fix: [SDL] Do not offer video smaller than 640x480 (#7442)
- Fix: Incorrect display of industry production around tiles (#7426)
- Fix: Show industry name in Land Area Information window for industries with neutral stations instead of just 'Oil Rig' (#7349)
- Fix: Remove redundant and broken file lookups when loading base sets (#7348)
- Fix: Always report error when ordering a road vehicle to wrong type of road stop (#7316)
- Fix #7043, #7274: Improve performance when creating towns during world creation (#7284)
- Fix #7062: Remove ship max order distance (#7279)
- Fix #7189: Fluidsynth volume gain too high (#7253)
- Fix: Add setting for whether industries with neutral stations (e.g. Oil rigs) accept and supply cargo to/from surrounding stations to fix exploit as old as TTO (#7234)
- Fix: Properly reset dropdown menu windows after changing AI/GS settings (#7092)
- Remove: DOS, MorphOS, AmigaOS & BeOS support (#7326, #7388)
- Fix #7411: Use industry production callback (if used) on initial industry cargo generation (#7412)
@@ -186,7 +909,7 @@ Note: OpenTTD was migrated to GitHub for 1.9, so SVN revision and FlySpray numbe
- Fix: [Win32] Right mouse scrolling didn't work properly with the Windows 10 Fall Creators Update [FS#6629] (r27935)
- Fix: Forest, candyfloss forest and battery farm skipped the first animation frame [FS#6639] (r27932)
- Fix: Glyphs in range U+0020 to U+00FF may only be defined in orig_extra.grf, not in openttd.grf [FS#6620] (r27915)
- Fix: 'unban' console command was not handling IPv6 adresses properly (r27914, r27913)
- Fix: 'unban' console command was not handling IPv6 addresses properly (r27914, r27913)
- Fix: Keep the 'link' between industry chain and smallmap windows whenever possible [FS#6585] (r27905)
- Fix: When the last vehicle is removed from a shared orders group, hide the 'Stop sharing' button in the vehicle orders window [FS#6593] (r27904)
- Fix: Tooltip of 'increase service interval' said 'decrease' [FS#6606] (r27895)
@@ -292,7 +1015,7 @@ Note: OpenTTD was migrated to GitHub for 1.9, so SVN revision and FlySpray numbe
- Fix: [Build] Force sorting to be locale independent, so files are always ordered the same and by that token better diff-able (r27562, r27558)
- Fix: Typos in comments and string (r27561, r27560)
- Fix: [Build] bashism that caused different CFLAGS with bash vs dash (r27557)
- Fix: Use a more appropiate sound effect for convert-rail (r27547)
- Fix: Use a more appropriate sound effect for convert-rail (r27547)
- Fix: Remove SetFill from vehicle GUI buttons, so that the viewport is resized instead of them in case of long window titles (r27546)
- Fix: [Script] Generation of API wrappers (r27545, r27544, r27543)
- Fix: [Windows] ICU got disabled for Windows builds, breaking RTL support [FS#6427] (r27542)
@@ -1772,7 +2495,7 @@ Note: OpenTTD was migrated to GitHub for 1.9, so SVN revision and FlySpray numbe
- Fix: [NewGRF] Additional text in fund industry window is NewGRF supplied and thus should have a default colour (r22631)
- Fix: Also initialise _old_vds with newgame settings; TTD savegames do not contain these settings [FS#4622] (r22626)
- Fix: Do not zero the orders of disaster vehicles when converting savegames [FS#4642] (r22625)
- Fix: When closing an AI company the local player cheated to, we need to cheat him to another company [FS#4654] (r22624, r22623)
- Fix: When closing an AI company the local player cheated to, we need to cheat them to another company [FS#4654] (r22624, r22623)
- Fix: When closing down companies their shares in other companies must be sold even if share trading is disabled at that point of time (r22622)
- Fix: When asking the user to confirm an unsafe unpausing, there is no need to execute a command if 'no' is chosen. This also prevents crashing when clicking unpause while the confirm window is shown (r22621)
- Fix: Enforce refit orders to be 'always go to depot' orders; service-only and stop-in-depot orders make no sense with refitting [FS#4651] (r22620)
@@ -2494,7 +3217,7 @@ Note: OpenTTD was migrated to GitHub for 1.9, so SVN revision and FlySpray numbe
- Fix: Chat message caused glitch when rejoining a network game [FS#3757] (r19629)
- Fix: Desync when a command is received and in the queue while a client starts joining, i.e. save the game state. This can happen in two ways: with frame_freq > 1 a command received in a previous frame might not be executed yet or when a command is received in the same frame as the join but before the savegame is made. In both cases the joining client would not get all commands to get in-sync with the server (and the other clients) (r19620)
- Fix: Company related graphs were not updated correctly after changing the company colour [FS#3763] (r19615)
- Fix: Possible invalid read when server moves client to spectators before he finishes joining [FS#3755] (r19613)
- Fix: Possible invalid read when server moves client to spectators before they finish joining [FS#3755] (r19613)
- Fix: Crash when opening a savegame with a waypoint from around 0.4.0 [FS#3756] (r19612)
- Fix: Improve joining behaviour; kicking clients when entering passwords that was just cleared, 'connection lost' for people failing the password, access restriction circumvention [CVE-2010-0401] [FS#3754] (r19610, r19609, r19608, r19607, r19606)
- Fix: Desync debugging; false positives in the cache validity checks and saving/loading the command stream (r19619, r19617, r19602, r19601, r19600, r19596, r19593, r19592, r19589, r19587, r19586)
@@ -2849,7 +3572,7 @@ Note: OpenTTD was migrated to GitHub for 1.9, so SVN revision and FlySpray numbe
- Fix: Do not account for path reservation costs when entering a signal block via a 'block' signal. This way you will not get double penalties, both red signals and reservation costs, for the block signalled tracks [FS#2722] (r18535)
- Fix: [NewGRF] An industry NewGRF that defined a too small size for action0 prop 0A could cause a crash (r18527)
- Fix: Allegro does not like to work with extmidi, so warn the user about that [FS#3272] (r18520)
- Fix: When you pass a signal at danger, in a PBS controlled area, do not try to do the 'safe' thing and stop, but continue going; the user wanted the train to pass the signal at danger so (s)he has to suffer the consequences. Of course one can always stop the train manually [FS#2891] (r18515)
- Fix: When you pass a signal at danger, in a PBS controlled area, do not try to do the 'safe' thing and stop, but continue going; the user wanted the train to pass the signal at danger so they have to suffer the consequences. Of course one can always stop the train manually [FS#2891] (r18515)
- Fix: No error message was created for the first fatal NewGRF error [FS#3368] (r18506)
- Fix: Improve airport movement on several airports [FS#3169] (r18505)
- Fix: Autoreplace and autorenew always reset their cargo sub type to 0. Now find a sub cargo type with the exact same name and use that, otherwise fallback to 0. So cargo sub types can be maintained via autoreplace *if* the new vehicle supports the same cargo sub type [FS#3159] (r18499)
@@ -3183,7 +3906,7 @@ Note: OpenTTD was migrated to GitHub for 1.9, so SVN revision and FlySpray numbe
- Fix: Improve corner case order handling: mark order as done only when actually done, obey non-stop orders, do only stop/refit at the depot in the order (r16240, r16228, r16199, r16198, r16187)
- Fix: [NoAI] Use the stop/non-stop intermediate orderflags AIs can give for goto-depot orders (r16239)
- Fix: [NewGRF] ActionB should use the online parameters from GRFFile instead of the initial user-specified values from GRFConfig. Also use the values as they were set when the ActionB was executed, not as they are set when the message is shown (r16223)
- Fix: Possible crashes when quiting OpenTTD or forcing resizes/redraws of the screen during map generation [FS#2862] (r16220)
- Fix: Possible crashes when quitting OpenTTD or forcing resizes/redraws of the screen during map generation [FS#2862] (r16220)
- Fix: Shared orders without orders were not properly converted causing corrupt/invalid orders when loading pre 0.7 savegames [FS#2878] (r16214)
- Fix: [Squirrel] The traps variable was not restored, causing try/catch blocks to be 'forgotten' during a suspend (r16181)
@@ -3191,7 +3914,7 @@ Note: OpenTTD was migrated to GitHub for 1.9, so SVN revision and FlySpray numbe
- Fix: Forbid joining AI companies via the 'move' and 'join' console commands/multiplayer lobby (r16176, r16175)
- Fix: [NoAI] AIOrder::GetOrderDestination and AIOrder::GetOrderFlags did not work on ORDER_CURRENT when the vehicle was loading/leaving in a station (r16165)
- Fix: [NoAI] Change WAYPOINT_INVALID to 0xFFFF from -1 as that is the value the AIs got (due to casting) (r16150)
- Fix: The overflowsafe type did not like dividing by int64 larger than MAX_INT32 causing division by negative numbers and small anomolies when drawing graphs [FS#2855] (r16130)
- Fix: The overflowsafe type did not like dividing by int64 larger than MAX_INT32 causing division by negative numbers and small anomalies when drawing graphs [FS#2855] (r16130)
- Fix: Road was removed when both the Remove button was active and Ctrl was pressed [FS#2582] (r16119)
- Fix: [NoAI] Make sure AIOrder::GetDestination always returns a tile belonging to the station (16109)
- Fix: [NoAI] When giving an aircraft a goto-hangar order do not let it be a normal goto-station order (r16108)
@@ -3332,7 +4055,7 @@ Note: OpenTTD was migrated to GitHub for 1.9, so SVN revision and FlySpray numbe
- Fix: Make the join/spectate command require to be connected to a network game; in SP it could lead to crashes (r15514)
- Fix: Generating a map with the original map generator with freeform edges on resulted in a crash [FS#2641] (r15511)
- Fix: Pre-0.5 OpenTTD stored new_nonstop and full_load_any in a different way, savegame conversion was not working for them (r15500)
- Fix: Crash when opening the game options when the currently loaded base graphics pack has less than 2 valid graphics files. For example when someone replaces all his/her original base graphics with custom work (but keeps the name) or renames the dos ones to windows or vice versa [FS#2630] (r15476)
- Fix: Crash when opening the game options when the currently loaded base graphics pack has less than 2 valid graphics files. For example when someone replaces all their original base graphics with custom work (but keeps the name) or renames the dos ones to windows or vice versa [FS#2630] (r15476)
0.7.0-beta1 (2009-02-16)
@@ -3647,7 +4370,7 @@ Note: OpenTTD was migrated to GitHub for 1.9, so SVN revision and FlySpray numbe
- Fix: Inconsistent use of 8/15-bitness of NewGRF callback results with respect to TTDP's implementation of the specification (r12819, r12818, r12759)
- Fix: Possible out of bounds array access (r12809)
- Fix: Enforce autorenew values range in command (r12808)
- Fix: Vehicles could break down during loading and keep loading. The intention of the break down code is not to break down when having zero speed, therefor break downs now do not happen when loading [FS#1938] (r12795)
- Fix: Vehicles could break down during loading and keep loading. The intention of the break down code is not to break down when having zero speed, therefore break downs now do not happen when loading [FS#1938] (r12795)
- Fix: [OSX] In some rare cases when using an uncalibrated monitor the system colour space could not be retrieved. Show an error when this happens instead of just trying an assertion (r12776)
- Fix: Slope checking for NewGRFs failed (r12759)
- Fix: Check the TILE_NOT_SLOPED flag of the _north_ tile of multi-tile houses to decide if autoslope is allowed (r12717)
@@ -3755,7 +4478,7 @@ Note: OpenTTD was migrated to GitHub for 1.9, so SVN revision and FlySpray numbe
- Feature: Separate catenary transparency settings from building transparency settings (r12103)
- Feature: Allow locking individual transparency settings so they will not be changed by pressing 'x' (r12102)
- Feature: Add some missing VarAction2 variables (r12124)
- Feature: Make snow appear on rail tiles dependant on track height, not on height of the lowest part of the tile (r12098)
- Feature: Make snow appear on rail tiles dependent on track height, not on height of the lowest part of the tile (r12098)
- Feature: [NewGRF] Specify the purchase, rail and road description of a bridge (r12069)
- Feature: [NewGRF] Add support for var 12, Variational Action 2 (r12045)
- Feature: Allow trees on shore (r12029)
@@ -4036,7 +4759,7 @@ Note: OpenTTD was migrated to GitHub for 1.9, so SVN revision and FlySpray numbe
- Feature: Add support for variable snow lines in the arctic climate, supplied by NewGRF files (r9371)
- Feature: [NewGRF] Add support for newhouses (r9315)
- Feature: [NewGRF] Add support for Action 13, which allows you to translate GRF-specific texts. The translations will only be shown if you are using a language with a GRF language id and if a string has not already been set specifically for the language you are using (r9037)
- Feature: Translation dependant formatting of dates (r8906)
- Feature: Translation dependent formatting of dates (r8906)
- Feature: If an action 7/9 leads to skipping the rest of the file, disable the NewGRF if an action 8 has not been encountered yet (r8831)
- Feature: Stop loading and disable the current NewGRF if a fatal error message in Action B is encountered. Also be more strict on the values accepted (r8830)
- Feature: Build aircraft windows will no longer show aircraft that cannot use the airport in question (r8771)
@@ -4094,7 +4817,7 @@ Note: OpenTTD was migrated to GitHub for 1.9, so SVN revision and FlySpray numbe
- Fix: Switching players (using the cheat) crashed on Big Endian machines [FS#1150] (r11023)
- Fix: The canal border determination did not take oil rigs into consideration (r11022)
- Fix: Do not display income/expenses when they do not belong to a 'valid' tile, like the money cheat/giving money [FS#1175] (r11021)
- Fix: One could not give money when (s)he had too much money or rather: when casting the amount of money to an int32 becomes negative [FS#1174] (r11020)
- Fix: One could not give money when they had too much money or rather: when casting the amount of money to an int32 becomes negative [FS#1174] (r11020)
- Fix: When determining the gender of a string, do not assume that the gender is in the front of the string when there can be case switching code at that location [FS#1104] (r10792)
- Fix: Determining whether there is a tunnel going under the lowered area is only needed in two directions instead of all four, so take the directions (one for each axis) to the nearest border (along the given axis) [FS#1058] (r10686)
- Fix: Graphical glitches when the 'link landscape toolbar' patch is turned on when opening one of the construction toolbars [FS#1076] (r10685)
@@ -4155,9 +4878,9 @@ Note: OpenTTD was migrated to GitHub for 1.9, so SVN revision and FlySpray numbe
- Fix: Do not unconditionally assume that a tile has a depot (r11027)
- Fix: Give a more correct error when building some things on tile 0 [FS#1173] (r11024)
- Fix: Do not display income/expenses when they do not belong to a 'valid' tile, like the money cheat and giving money [FS#1175] (r11021)
- Fix: One could not give money when (s)he had too much money [FS#1174] (r11020)
- Fix: One could not give money when they had too much money [FS#1174] (r11020)
- Fix: Disallow buying/selling shares in your own company or a bankrupt company [FS#1169] (r11018)
- Fix: Crash when quiting the game in one of the end score windows [FS#1218] (r11071)
- Fix: Crash when quitting the game in one of the end score windows [FS#1218] (r11071)
0.5.3-RC3 (2007-08-30)
@@ -4289,7 +5012,7 @@ Note: OpenTTD was migrated to GitHub for 1.9, so SVN revision and FlySpray numbe
- Feature: Translation dependant formatting of dates (r8906)
- Feature: Translation dependent formatting of dates (r8906)
- Feature: Kick inactive initial network connections after some time [FS#115] (r9038, r9061)
- Feature: Add an extra news group for opening and closing of industries (r9097)
- Codechange: Disable shares by default and increase the default maximum distance from edge for oil refineries (r9339)
@@ -5115,7 +5838,7 @@ Note: OpenTTD was migrated to GitHub for 1.9, so SVN revision and FlySpray numbe
- Fix: Vehicles slow down under bridge if the track is on a foundation
- Fix: You can no longer change name of waypoints whom are owned by somebody else
- Fix: Shares are now also sold when a company goes bankrupt [SF#1090313]
- Fix: It is no longer possible to crash trains of other companies by building a depot close to a station; trains do no longer enter tiles that do not belong to his owner [SF#1087701]
- Fix: It is no longer possible to crash trains of other companies by building a depot close to a station; trains do no longer enter tiles that do not belong to their owner [SF#1087701]
- Fix: Crashed trains are not reported to have too few orders any more [SF#1087403]
- Fix: Backup-order-list was not closed with an OT_NOTHING, [SF#1086375]
- Fix: Docks now have a button to display the catchment area [SF#1085255]
@@ -5252,7 +5975,7 @@ Note: OpenTTD was migrated to GitHub for 1.9, so SVN revision and FlySpray numbe
- Fix: Wrong pathfinding when northern station tile is missing
- Fix: You cannot take ownership of an oilrig by building right next to it
- Fix: [Makefile] Fixed issue where sdl-config was needed even on systems without SDL
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.