Airports are similar two stations and industries, both of which have the town as related object.
Airport tiles are similar to industry tiles, which have the industry as related object.
This seems a sensible structure, so let's make it Airport Tile -> Airport -> Town.
During b0e73277 we removed loaded_at_xy, but I kinda forgot that
it was a union with next_station. Now next_station wasn't copied
anymore, or checked in AreMergable.
The nlohmann-json header file includes assert.h, which rudely resets
the assert macro to what that header thinks is right. As we set the
assert macro to be active with release builds when WITH_ASSERT is
active, this means that every file including nlohmann-json has their
asserts disabled (for release-builds) but files that don't do no.
Let's avoid this issue, by telling nlohmann to not include assert.h.
For stations with many flows and/or small cargo packets,
due to accumulated inaccuracies in DivideApprox.
The displayed total should match GoodsEntry::TotalCount().
This simplifies processing nwidget parts as, unlike the remaining length, the pointer to the end of the list never changes. This is the same principle as we use(d) for tracking end instead of length for C-style strings.
And this removes 160~ instances of the lengthof() macro.
Having a library with files with the same name isn't supported in CMake's Xcode project file generation: https://gitlab.kitware.com/cmake/cmake/-/issues/20501. One of the files is renamed to work around this bug.
When changing a Game Option and pressing Exit Game, the changes
were not actually stored. This because the post-mainloop code
was never executed for Emscripten.
Heap is out of the question, as it might be corrupted.
Allocating this much on stack is silly.
So instead, allocate virtual pages to write the information in.
As mentioned in the comment, we only did it ourselves as we once
were compatible with versions before 10.5. But that time has long
gone. So let's update the code to a bit more modern approach.
english (au): 1 change by krysclarke
finnish: 3 changes by hpiirai
danish: 1 change by bscargo
french: 1 change by glx22
portuguese (brazilian): 1 change by pasantoro
Only Windows implemented this, and it opens the files to read them
to get a CRC. Doing this in a crash-handler is strange at best.
Lastly, nobody has actually ever used this information to come to
some sort of conclusion. The module-list is used in combination
with the crash.dmp, but this information is already embedded in
there.
It only contains pointers, which nobody can decipher anyway.
So instead, just report "Not supported", like other targets do
when they can't print a sane stack trace.
The define kCGBitmapByteOrder32Host changed (around SDK 12?)
into an enum, which means an old #ifndef was triggering,
overwriting the value to 0. Sadly, 0 means Order16Big, causing
RGBA to become GRAB, which results in strange colours.
As we no longer support PPC, drop that piece of code completely.
It was TileOrStationID, most likely to make sure both types in
the union are identical. But as TileIndex is a StrongTypeDef
that becomes a bit weird. So instead, still make sure they are
of equal size, but define their individual types better.
This value is not changed when the date cheat is used, which caused issues with changing properties based on service date.
Co-authored-by: Peter Nelson <peter1138@openttd.org>
english (au): 4 changes by krysclarke
english (us): 4 changes by 2TallTyler
vietnamese: 2 changes by KhoiCanDev
russian: 21 changes by Ln-Wolf
finnish: 37 changes by hpiirai
portuguese: 24 changes by azulcosta
portuguese (brazilian): 6 changes by pasantoro
english (au): 19 changes by krysclarke
vietnamese: 12 changes by KhoiCanDev
danish: 19 changes by bscargo
portuguese: 20 changes by azulcosta
portuguese (brazilian): 19 changes by pasantoro
norwegian (bokmal): 1 change by buzzCraft
chinese (traditional): 1 change by wpi3
spanish (mexican): 1 change by absay
english (us): 3 changes by 2TallTyler
vietnamese: 13 changes by KhoiCanDev
russian: 3 changes by Ln-Wolf
dutch: 23 changes by Afoklala
lithuanian: 1 change by devbotas
portuguese: 6 changes by azulcosta
polish: 3 changes by pAter-exe
By forcing it only happens once, the first time you upgrade to
a newer client, means you are free to jump between older and newer
versions after that. As they will not resync, the newer setting
can take on any of the (newer) values, without breaking the old
client. And when going to an old client and back, it doesn't
change it back to the converted value anymore.
english (us): 21 changes by 2TallTyler
korean: 3 changes by telk5093
catalan: 27 changes by J0anJosep
turkish: 12 changes by densxd
french: 13 changes by Lishouuu
english (au): 20 changes by krysclarke
swedish: 2 changes by SkogisREAL
japanese: 2 changes by fmang
welsh: 1 change by Ansbaradigeidfran
english (us): 2 changes by 2TallTyler
galician: 2 changes by pvillaverde
vietnamese: 2 changes by KhoiCanDev
korean: 8 changes by telk5093
hungarian: 1 change by PstasDev
indonesian: 1 change by ecolortest
italian: 2 changes by Rivarossi
german: 2 changes by Wuzzy2
russian: 9 changes by Ln-Wolf
finnish: 2 changes by hpiirai
catalan: 2 changes by J0anJosep
turkish: 2 changes by densxd
danish: 2 changes by bscargo
dutch: 2 changes by Afoklala
french: 2 changes by ZarTek-Creole
portuguese: 28 changes by azulcosta
esperanto: 2 changes by legoscia
portuguese (brazilian): 2 changes by ericandradex
polish: 2 changes by pAter-exe
* Change: Use consistent window title format for industry/cargo chains
* Change: Don't capitalize dropdown entry for cargo flow legend
* Change: Use consistent window titles for AI and GS settings
* Change: Use consistent window title for company value graph
* Change: Use consistent window title for industry funding
* Change: Use consistent button title to display industry chain
* Change: Use consistent button capitalization for local authority button on town window
* Fix: Don't capitalize random words in vehicle list management dropdown
* Fix: Use title case for Frame Rate window caption
* Fix: Use title case for Detailed Performance Rating window caption
Now, exclusive transport rights can only be bought if no company
currently owns them. A successful bribe will void any exclusive
transport rights that any *other* company currently has in the town.
In the old days, content.openttd.org and bananas-server.openttd.org
ended up on the same route. But with a recent migration, they do not.
content.openttd.org only serves the custom TCP protocol, and
bananas-server.openttd.org only serves the HTTP(S).
Websockets use HTTPS, and as such, should be routed via the latter.
Otherwise some compilers, e.g. MSVC, do not pick up that these are temporaries
and as such it will pass the temporaries to `const std::string &` instead of
the wanted `std::string &&`
english (au): 2 changes by krysclarke
italian: 14 changes by Rivarossi
russian: 2 changes by Ln-Wolf
finnish: 2 changes by hpiirai
tamil: 8 changes by merni-ns
Set a higher default value for this setting.
Use the higher of this and existing commands per frame limit
setting for server-originating commands, e.g. GS.
This is to support the GSAsyncMode class.
This also avoids undue throttling when more than one
script is in operation (e.g. AIs).
english (au): 1 change by krysclarke
russian: 1 change by Ln-Wolf
turkish: 1 change by BeratSJ
french: 1 change by glx22
portuguese (brazilian): 4 changes by pasantoro
norwegian (bokmal): 1 change by buzzCraft
chinese (traditional): 1 change by wpi3
spanish (mexican): 1 change by absay
lithuanian: 1 change by devbotas
portuguese (brazilian): 3 changes by Greavez
Most languages stick with the 3-letter latin currency codes in the name
string, however some translations are... clever... and use the currency
symbol instead. Whilst this may look nice, it can cause issues with fonts
as some scripts have a specific limited set of fonts which do not include
these symbols.
Instead, hard code the currency code list and add it when drawing the
currency name.
Having to choose between DropDownListStringItem, DropDownListCharStringItem, and DropDownListParamStringItem depending on whether to draw a StringID, a raw string, or a StringID with extra parameters was needlessly complex.
Instead, allow passing a StringID or raw string to DropDownListStringItem. This will preformat the StringID into a raw string, and can therefore accept parameters via the normal SetDParam mechanism.
This also means that strings no longer need to be formatted on every draw.
english (au): 2 changes by krysclarke
vietnamese: 3 changes by KhoiCanDev
russian: 2 changes by Ln-Wolf
dutch: 5 changes by Afoklala
french: 2 changes by Lishouuu
portuguese: 2 changes by azulcosta
esperanto: 51 changes by legoscia
polish: 3 changes by pAter-exe
SDL needs to see the header files when compiling to enable those
drivers runtime. It doesn't actually link against them: it just
needs to see the headers.
Since dropdown menus now get closed if they lose focus, 'instant close' dropdowns (i.e. the toolbar dropdowns) should no longer execute their action to avoid unintended actions.
english (au): 1 change by krysclarke
korean: 1 change by telk5093
russian: 1 change by Ln-Wolf
french: 1 change by Lishouuu
portuguese: 1 change by azulcosta
english (au): 2 changes by krysclarke
korean: 2 changes by telk5093
russian: 2 changes by Ln-Wolf
french: 2 changes by ottdfevr
portuguese: 2 changes by azulcosta
portuguese (brazilian): 2 changes by ericandradex
polish: 2 changes by pAter-exe
This replaces/simplifies testing for a closebox to allow closing a window with right-click, and testing for specific window classes when closing all windows by hotkey.
This allows right-click closing of dropdowns and the high-score window.
Clicking and releasing on the query toolbar icon is meant to select the land-info tool.
This did not work as during closing a window, OnFocusLost() is called, which then closes the window again. These two calls toggled the land-info tool one and off in the same action.
Resolve by not calling Window::Close in OnFocusLost() if the window is already closing.
On Windows in fullscreen you cannot reach the top with
the cursor for the halve of the height of your toolbar.
Additionally, on Win10 in fullscreen you can see the actual toolbar.
Since dropdowns self-close, the detection of re-clicking a dropdown
button no longer worked, as the dropdown is already closed.
Instead set (and then test) a flag on the parent widget to indicate that
the dropdown closed. This method avoids looping windows on every click.
korean: 2 changes by telk5093
russian: 2 changes by Ln-Wolf
finnish: 2 changes by hpiirai
turkish: 2 changes by EndChapter
french: 2 changes by glx22
portuguese: 2 changes by azulcosta
`IniGroup::GetItem()` returns nullptr if the item does not exist, but does not if the create parameter is set to true. Resolve CodeQL warnings with `GetOrCreateItem()` which returns a reference to the item instead.
Hotkeys are now initialized inline, and use std::vector instead of
separate static C-arrays and std::string instead of char *. The list end
marker is no longer required.
Solution is to not focus any tooltips, so that the dropdown doesn't lose focus. Tooltips don't accept any input so this does not change their behaviour.
Wayland doesn't support mouse warping, X11 only for native
systems (so not for remote desktop, WSLg, etc), and emscripten
neither without complications. All these cannot offer a
mouse-lock.
Basically, we drop RelativeMode completely, and use the same trick
as used by the Windows driver: read all motion events till the last
one, and use that as value.
Basically, we haven't been a good neighbour. Turns out you shouldn't
actually call FcFini when you are done, as some library might still
want to use FontConfig. And they use a shared instance for their
administration.
The idea is that you call FcInit once, and use FcConfigReference
after that to get an instance, you can release. This entry is
ref-counted, and things happen automatically based on that.
At least, I think.
It turns out, for Windows and Linux having the exact memory allows
for easy tracing of an individual. That is exactly against the idea
of the survey. And honestly, we don't need this precision.
Not all instances need to be initialized as often they are copied or
written to, but doing all ensures no surprises.
Move the ^= operator to MD5Hash while we're at it.
Use a array of struct for each cargo instead of an array for each statistic.
This makes iterating for acceptance and production much simpler.
pct_transported is now calculated when needed.
The fmt code pushes a pragma option, and later pops is. The intrinsics code
interacts with it via the __OPTIMIZE__ macro. This has been set by the pragma
option push, but not unset/reset to the original with the pop.
Since the pragma is only used for the GCC compiler (not Clang, not MSVC, not
ICC) and in debug mode, just remove the whole pragma handling for it.
That it works for the version we have packaged it pure coincidence, as that is
one of the few versions that due to a bug allow it. So add the appropriate
template specialisations to support it out-of-the-box within OpenTTD.
This simplifies retrieving the correct data for each row when data is
filtered. The background FileList is left intact so that savegame data
does not have to be rescanned when the filter is changed, and sorting
still remains the task of the background FileList.
This map is used store socket and address together, and, other than
checking that the address does not already have a socket, the data layout
does not seem particularly important.
However, as address is the key, technically it should not be modified,
and address may self-modify itself during comparisons.
english (au): 14 changes by krysclarke
english (us): 14 changes by 2TallTyler
vietnamese: 14 changes by KhoiCanDev
korean: 19 changes by telk5093
italian: 14 changes by Rivarossi
russian: 14 changes by Ln-Wolf
finnish: 14 changes by hpiirai
danish: 22 changes by bscargo
portuguese: 14 changes by azulcosta
polish: 14 changes by pAter-exe
GetScrolled*FromWidget took line height from the widget's resize_y value,
however not all widgets are resizable, resulting in a division-by-zero.
Allow passing line height explicitly in cases where a widget is not
resizable.
On first start-up, the game will ask if you want to participate
in our automated survey. You have to opt-in, and can easily opt-out
(via the Options) at any time.
When opt-in, whenever you exit a game, a JSON blob will be send
to the survey server hosted by OpenTTD. This JSON blob contains
information that gives a global picture of the game just played:
- What settings were used
- How many humans vs AIs
- How long the game has been played
- Basic information about the OS / CPU
All this information is kept very generic, so there is no
chance we send private information to our survey server.
Nothing in the JSON blob could identify you as a person; it
mostly tells about the game played. At any time you can see
what the JSON blob includes, by pressing the "Preview Survey
Results" button in-game.
Technically unlikely to happen, though uint16 * uint16 get promoted to int and
then stored as uint64; similarly uint * uint16 remains uint and gets stored as
uint64. In both cases the value can get truncated before the change to uint64.
We are planning to allow things like freezing the calendar, which
makes this variable a bit problemetic. So instead, suggest to the
user how many ticks there are in a calendar day, and let them figure
out how many ticks they want.
Additionally, use a TimeoutTimer for this, instead of an end-date
variable which is checked in an IntervalTimer.
Add NEW_STATION to the nearby station list to indicate that a new
station should be built. This removes special-casing for a non-existant
list item and keeps the list count and scrollbar count the same.
This meant you could have the following situation:
- You start a profile on a GRF with no events, for N days.
- The days pass, the profile should stop. It doesn't.
- The profile will never stop, even if the GRF start generating events.
- There is no real way to discover this, so .. byebye memory? :)
In many instances the clicked row position is 'manually' calculated
instead of using the GetScrolledRowFromWidget helper function, with
variations on checks. Replace with the two helpers where possible.
This function returns an iterator, either to the selected item or the
container's end.
This makes handling the result more robust as indices are not used.
english (au): 4 changes by krysclarke
english (us): 4 changes by 2TallTyler
russian: 4 changes by Ln-Wolf
portuguese: 4 changes by azulcosta
polish: 8 changes by pAter-exe
This allows force to passed as is and avoid premature rounding.
The AI function "GetMaxTractiveEffort" still needs to return kN to avoid breaking the API.
Previously the decimal_places member was mostly ignored except for
specific conversions. {DECIMAL} with 0 is the same as {COMMA} so there
is no downside to allowing any conversion to have decimals.
Unit conversion is only performed for display purposes, this does not
affect lock-step mechanics.
This replaces the old multiply and shift algorithm which relies on
choosing a multipler and shift combination that gets close. Some of these
multiply/shift combinations were quite inaccurate. We can just
use (close-to) real-world numbers instead.
It was already possible to define more than 256 per class, but not possible
to use them as the index used in GUI and passed through commands was limited
to a byte.
They all now access a std::string_view, instead of a "const char *"
or std::string (in some cases).
Additionally, GetCharAtPosition and friends now return an index
instead of a "const char *", as it makes for a more clear interface.
Clusters from harfbuzz are indexed from the start of the buffer,
not from the start of the run analyzed. This confuses other parts
of the code that do assume they are from the start of the run.
This to prevent compilation issues between runs with and without precompiled
headers. Also remove the headers from the rest of the code base as they are
not needed there anymore, although they do relatively little harm.
* Remove left-over code that treated an invalid list selection as 'fund
many', which is actually implemented as a separate button.
* Manual list management replaced with std::vector.
* Enabled state is only needed for the current selection.
* Selected index is not required only selected type.
english (au): 5 changes by krysclarke
english (us): 5 changes by 2TallTyler
korean: 5 changes by telk5093
italian: 5 changes by Rivarossi
russian: 5 changes by Ln-Wolf
finnish: 5 changes by hpiirai
turkish: 5 changes by densxd
portuguese: 5 changes by azulcosta
This can be done because previous the value 0xFF (which indicates an
extended byte) was reserved for this purpose. Other features which may
not have mentioned reserving 0xFF do not allow this many IDs anyway.
This makes Action 3 consistent across all features. The allowable limits
for each feature do not change.
english (au): 14 changes by krysclarke
korean: 14 changes by telk5093
italian: 14 changes by Rivarossi
russian: 15 changes by Ln-Wolf
finnish: 14 changes by hpiirai
turkish: 14 changes by densxd
portuguese: 16 changes by azulcosta
This means we have RTL support again with ICU 58+. It makes use of:
- ICU for bidi-itemization
- ICU for script-itemization
- OpenTTD for style-itemization
- harfbuzz for shaping
italian: 4 changes by Rivarossi
russian: 4 changes by Ln-Wolf
finnish: 4 changes by hpiirai
turkish: 4 changes by densxd
dutch: 6 changes by Afoklala
portuguese: 4 changes by azulcosta
By default, GitHub adds all arguments of the matrix between ().
This is fine sometimes, but in other times it becomes a very
lengthy line.
With this commit, we decide what is between those (), making it
a lot more readable.
There are two fundamental issues with autosave:
- When fast-forwarding, it saves way too often
- When paused, it never saves
Both makes no sense. Autosaves are meant to prevent you from
accidentally losing your work. The emphasis on "your" work.
To solve both issues, the autosave now works on real time. You
can select every 10 / 30 / 60 / 120 minutes, which are similar to
what the setting was in game-months.
When you pause, autosaving will stop. Unless you make any change
to the game; then it will continue to make autosaves, even so
the game is paused. Unpausing / pausing resets this mechanism.
Trying to update text widgets with free flowing multiline text during
UpdateWidgetSize(), as the final width is not yet known and so the
calculated height being incorrect, usually resulting in one or more
empty text lines.
The solution is to update the widget heights afterwards during
OnResize(), at which point the final widths are known. The window is
then resized if needed.
(Note this technique needs more attention if width can also change.)
english (au): 1 change by krysclarke
english (us): 1 change by 2TallTyler
galician: 36 changes by pvillaverde
korean: 14 changes by telk5093
italian: 1 change by Rivarossi
russian: 1 change by Ln-Wolf
turkish: 2 changes by densxd
english (au): 1 change by krysclarke
english (us): 1 change by 2TallTyler
vietnamese: 4 changes by KhoiCanDev
italian: 1 change by Rivarossi
russian: 1 change by Ln-Wolf
turkish: 1 change by EndChapter
portuguese: 1 change by azulcosta
english (us): 5 changes by 2TallTyler
vietnamese: 1 change by KhoiCanDev
russian: 1 change by Ln-Wolf
turkish: 33 changes by densxd
dutch: 5 changes by Afoklala
Technically the 0X vs 0x is not a big problem, just not pretty. However, the
length also including the 0x results in unexpected behaviour, so it probably
better to not use it.
english (au): 1 change by krysclarke
german: 1 change by SecretIdetity
russian: 1 change by Ln-Wolf
finnish: 5 changes by hpiirai
slovak: 15 changes by legitalk
portuguese: 1 change by azulcosta
The per-AI "start_date" is a lot of custom code, and was rarely
used in the way it was meant.
While at it, also ported this part over to the new timer system.
IntervalTimer and TimeoutTimer use RAII, and can be used to replace
all the time-based timeouts, lag-detection, "execute every N" we
have.
As it uses RAII, you can safely use it as static variable, class
member, temporary variable, etc. As soon as it goes out-of-scope,
it will be safely removed.
This allows for much easier to read code when it comes to intervals.
Towns currently don't build disallowed roadtypes, however they should
also not extend disallowed roadtypes as well.
If the roadtype that cannot be extended happens to be the roadtype that
the town was going to build then this restriction is ignored.
Previously, on a straight line of a one corner up slope with the adjacent
steep sloop the Z would increase one step every two sub pixels, except for one
case where one sub pixel is skipped. Similarly, a steep slope with two
adjacent one corner up slopes, would have a bump in the height line along the
diagonal whenever it enters/leaves the steep slope tile.
When the direction of a RV changes the Z-position update logic was called,
which did nothing to the Z-position because that is only changed every other
step. By chance/luck this never triggered with RV's turning around, until
making the partial Z calculations consistent and moving the locations where
the Z-position is changed, causing the Z-position to be changed twice for
the RV that stayed at the same location.
Previously it checked the position in non-driving direction to "guess" whether
a ground vehicle was using the function, so on tunnels/bridges it could either
return the Z of the (virtual) ground compared to the Z of the path the vehicle
would take.
* If loading fails, it usually returns SL_REINIT which doesn't trigger check
* If savegame has NewGRFs, it complains NewGRFs are not allowed in intro game
vietnamese: 1 change by KhoiCanDev
korean: 3 changes by telk5093
german: 30 changes by Wuzzy2
slovak: 14 changes by legitalk
dutch: 12 changes by Afoklala
The music-set does not need to be selected for this to occur.
Resolved by using std::string instead of fixed buffer for song names,
which avoids manual string copying and removes the length limit.
When a game script is in company mode, it pretends to be another company. When
that company disappear (bankruptcy/merger), the game script still uses that
company and it keeps calling functions as if it is that company.
For example, ScriptEngine::IsBuildable internally dereferences Company without
checks, causing a null dereference for any ScriptEngine function when called
from a company scope of a company that has disappeared.
Guard against this by extending the ScriptCompanyScope::IsValid check to also
check for the company still being active.
Command functions are those that call ScriptObject::Command, and functions
with company access are any that call ScriptObject::GetCompany. This is a bit
over-protective, but having the check everywhere makes it easier to validate
that no check is missing automatically instead of by review.
Command functions are those that call ScriptObject::Command, and functions
with company access are any that call ScriptObject::GetCompany. This is a bit
over-protective, but having the check everywhere makes it easier to validate
that no check is missing automatically instead of by review.
These are functions that either use ScriptObject::Command or ScriptObject::GetCompany.
This is a bit over-protective, but having the check everywhere makes it easier to
validate that no check is missing automatically instead of by review.
At this moment these checks will not do anything useful, as either IsValid or
IsDeity from ScriptCompanyMode returns true, but that will change later.
Direct 1:1 replacements in the code, and comments now refer to either
GSCompanyMode::IsValid or GSCompanyMode::IsDeity instead of several variations
on "company mode active" or "no company mode active".
vietnamese: 2 changes by KhoiCanDev
italian: 2 changes by Rivarossi
russian: 2 changes by Ln-Wolf
turkish: 3 changes by EndChapter
portuguese: 2 changes by azulcosta
Lately we had a few times that people pushed to their PR branch
a few times to make small changes. Sadly, this triggers all CIs
every time, which takes ~20 minutes. As we are limited in the
amount of runners we get assigned to us, this means all other CI,
even for other repositories within OpenTTD, are delayed too.
We can avoid this by simply cancelling old runs when a new PR is
pushed. There is a downside: sometimes people already push a new
commit, but still want to know if the old one passed. That will
no longer be possible with this change.
Class templates allow using partial template specialization, which is useful in
case one wants to have a type conversion on a type that is itself templated.
When a road vehicle is already running on a multi level crossing, and a train shows up ahead, don't make the road vehicle crash on the side of the train.
Otherwise this chain of events can happen:
- You already have a (partial) file downloaded
- You start the download, and HTTP fails
- This resets the download progress to the current size of the file
- The TCP download starts at a very large value (UINT32_MAX - filesize)
It now resets to 0% done when any negative value is being given.
As added bonus, we no longer have to query how much was already
downloaded.
With a thread, we can just run curl_easy_perform() and let CURL
and threads handle the blocking part.
With async solution there are too many things to keep track of,
and it makes "when to update the GUI" tricky. By using a thread
that all gets a lot simpler, as the game-thread and download-thread
run side-by-side.
This is similar to how the WinHttp backend already works.
swedish: 3 changes by joeax910
italian: 1 change by Rivarossi
russian: 1 change by Ln-Wolf
ukrainian: 1 change by serg-bloim
latvian: 7 changes by lexuslatvia
This requires the use of WinHTTP (for Windows) or libcurl (for all
others except Emscripten). Emscripten does not support http(s)
calls currently.
On Linux it requires ca-certificates to be installed, so the HTTPS
certificate can be validated. It is really likely this is installed
on any modern machine, as most connections these days are HTTPS.
(On MacOS and Windows the certificate store is filled by default)
Reminder: in case the http(s):// connection cannot be established,
OpenTTD falls back to a custom TCP-based connection to fetch the
content from the content-service. Emscripten will always do this.
english (au): 2 changes by krysclarke
estonian: 107 changes by RM87
romanian: 2 changes by bnegrut
finnish: 8 changes by hpiirai
dutch: 4 changes by Afoklala
portuguese: 2 changes by azulcosta
polish: 2 changes by pAter-exe
english (us): 2 changes by 2TallTyler
estonian: 110 changes by RM87
czech: 5 changes by jacobczsk
italian: 11 changes by Rivarossi
russian: 2 changes by Ln-Wolf
english (au): 1 change by krysclarke
english (us): 1 change by 2TallTyler
vietnamese: 2 changes by KhoiCanDev
luxembourgish: 5 changes by phreeze83
catalan: 3 changes by J0anJosep
french: 11 changes by ZarTek-Creole, 5 changes by glx22
english (au): 4 changes by krysclarke
swedish: 16 changes by joeax910
english (us): 2 changes by 2TallTyler
chinese (simplified): 2 changes by XiaoJi-Game
hebrew: 3 changes by Boltyansky
romanian: 10 changes by kneekoo
russian: 5 changes by Ln-Wolf
portuguese: 2 changes by azulcosta
polish: 4 changes by pAter-exe
And set the minimum maximum loan to the value of loan interval, so there is
always an amount of money to lend. Compared to being allowed to set max loan
to 0 and never be allowed to lend any money.
This adds the Exxx and Fxxx blocks to the usable range for NewGRF
local strings. TTDPatch uses these ranges for internal strings, but as
we don't support any of them anyway, it is "free" real estate for us.
Currently they had a name that the rest of our system cannot
deal with correctly. "cert.pfx" is also not very descriptive from
a system as a whole.
As such, we now name it like any other file, so it can be published
safely to the CDN.
* Change: Store "all time" and "since minimum age" last year profits on groups
* Fix: Update last year profit for groups when copying vehicle statistics on autoreplace
* Codechange: Refactor profit last year
* Change: Rename some group related items for clarity
* Change: Reorder the fields in GroupStatistics
That way less memory gets wasted.
For bridges, a max speed of 0xFFFF (i.e. no effective limit)
is no longer displayed as a limit in the UI.
A max speed of 0 is also considered unlimited, for similarity to the
roadtype and railtype interface.
english (au): 6 changes by krysclarke
chinese (simplified): 3 changes by XiaoJi-Game, 1 change by ZZY2357
arabic (egypt): 11 changes by AviationGamerX
korean: 3 changes by telk5093
indonesian: 8 changes by K4smun1
english (us): 6 changes by 2TallTyler
catalan: 6 changes by J0anJosep
spanish: 5 changes by MontyMontana
portuguese: 4 changes by azulcosta
polish: 4 changes by pAter-exe
* Fix #10363: CargoDist setting helptext shouldn't suggest symmetric distribution for diamonds in subtropic
* Fix: Always capitalize the first word of a sentence, even if a quoted setting name
Though where similar calls are checked for nullptr as in those instances of
the use of that function it can actually return nullptr. In other words, write
down the assumption that the function never returns nullptr in an assert.
swedish: 18 changes by joeax910
chinese (simplified): 2 changes by HansKaffee
romanian: 3 changes by ALEX11BR
slovak: 15 changes by legitalk
tamil: 21 changes by Aswn
That fills an instance variable that is only read from the Game Options window
and that is overwritten when the video driver is started. Since you cannot get
into the Game Options window without starting the video driver, it is just
pointless and wrong code that would never be noticed by the end user.
Modulo on a signed number returns negative values for negative values, so
i % 2 == 1 will only return true for positive odd numbers, whereas i % 2 != 0
returns true for both positive and negative odd numbers.
In these cases technically they are false positives, however dismissing the
alerts when the underlying code may make them true positives does not seem
like the safest solution.
When disabling/enabling elrail, there is an assumption that `engclass` of 2
means the engine will run on elrail. While this holds for default engines,
NewGRFs can do other things.
To resolve this we store the intended railtype so that toggling elrail will
restore to the correct type.
swedish: 33 changes by joeax910
arabic (egypt): 11 changes by AviationGamerX
luxembourgish: 3 changes by Gubius
greek: 85 changes by SStelioss
indonesian: 55 changes by indrabagus, 20 changes by K4smun1
serbian: 527 changes by nkrs
latvian: 82 changes by lexuslatvia
polish: 2 changes by pAter-exe
swedish: 39 changes by DonaldDuck313, 9 changes by joeax910
chinese (traditional): 62 changes by wpi3
greek: 8 changes by SStelioss
indonesian: 29 changes by indrabagus
serbian: 528 changes by nkrs
ukrainian: 82 changes by StepanIvasyn
turkish: 4 changes by jnmbk
french: 19 changes by glx22
swedish: 9 changes by joeax910
norwegian (bokmal): 7 changes by buzzCraft
chinese (traditional): 48 changes by wpi3
galician: 98 changes by pvillaverde
vietnamese: 13 changes by myquartz
czech: 42 changes by vladoschreiner, 40 changes by PatrikSamuelTauchim, 19 changes by adamek0202, 3 changes by LubosKolouch
chinese (simplified): 52 changes by HansKaffee
luxembourgish: 148 changes by phreeze83
hungarian: 50 changes by PstasDev, 23 changes by baliball
german: 69 changes by Wuzzy2, 4 changes by Luensche
romanian: 3 changes by kneekoo
ukrainian: 45 changes by StepanIvasyn
catalan: 12 changes by J0anJosep
turkish: 9 changes by Anceph
french: 1 change by Athozus
portuguese (brazilian): 9 changes by ericandradex
Most are very unlikely to ever be triggered in our codebase; two
stand out: linkgraph and money cheat. Those, potentially, could
wrap earlier than expected.
english (au): 10 changes by krysclarke
italian: 3 changes by Rivarossi
russian: 3 changes by Ln-Wolf
finnish: 3 changes by hpiirai
spanish: 15 changes by MontyMontana
portuguese: 6 changes by azulcosta
portuguese (brazilian): 2 changes by DiogoMCampos
italian: 10 changes by bagnacauda
romanian: 91 changes by bnegrut
russian: 6 changes by Ln-Wolf
finnish: 9 changes by hpiirai
portuguese: 8 changes by azulcosta
Grouped engines are collapsed by default but can be expanded. This allows
similar engines to be grouped together to avoid cluttering the list.
Suggested uses for this are e.g.:
* Liveries; same stats but different paint job.
* Re-gearing; engine design is mostly the same but different stats.
... but avoiding complex hidden cargo subtype refit systems.
Grouped engines are otherwise separate, so can be independently
autoreplaced, even between variants.
* Fix #10150: Force FS_SMALL for small viewport signs.
This is a workaround for string widths being different with mixed
font-sizes.
* Fix: Flag small sign shadow as small text.
(This method of drawing shadows is hilarious and needs replacing, but
this is a quick fix.)
* Fix: Use width of caret symbol '_' for text entry.
This replaces an arbitrary pixel width with the space actually required.
* Fix #8971: Update QueryString sizes with interface scale change.
Before variable-scaling, the padding was always 1x1 pixel. This was
changed to be scaled, except using the wrong dimension of 2x1 pixels
instead of 1x1 pixel.
Dropdowns which are taller than the main window should automatically have
a scrollbar added. This did not work for toolbar dropdown as the location
near the top of the window resulted in an unsigned underflow.
* Fix: Missing extra padding when drawing tooltip text.
This padding is included when calculating the size of the tooltips, the
difference caused a mismatch in height for some tooltips.
* Codechange: Don't draw grey panel underneath tooltip.
This removes the default framerect padding so it is now added explicitly.
SetMinimalSize is also removed as this is overridden in UpdateWidgetSize
anyway.
chinese (simplified): 13 changes by XiaoJi-Game
russian: 4 changes by Ln-Wolf
slovak: 7 changes by legitalk
catalan: 77 changes by J0anJosep
turkish: 7 changes by EndChapter
polish: 7 changes by pAter-exe
* Fix: Scale object gui margin by interface scale.
* Fix: Improve padding on object info text.
* Fix #10021: Resizing for 1/2/4 object views didn't account for interface scale.
As halving and doubling padding is problematic due to rounding, it is now
added on lower view counts instead of removing on higher view counts.
english (au): 3 changes by krysclarke
english (us): 7 changes by 2TallTyler
korean: 52 changes by telk5093
russian: 4 changes by Ln-Wolf
spanish: 6 changes by MontyMontana
portuguese: 3 changes by azulcosta
Depot lists internal layout was not handled well. This is improved by
throwing more Rects at it:
- Vehicle images are now be vertically centred in the rect.
- Image clipping is relaxed to cover the rect, improving larger sprites.
- Outline highlight is now aware of bevel thickness.
Industry production used to be indented, although a different amount than
the industry accepts list. This is now added back, with the standard indent
width.
Additionally the cheat-mode production modifier buttons now support RTL and
the list height now takes account of the button height.
english (au): 3 changes by krysclarke
spanish (mexican): 3 changes by absay
english (us): 3 changes by 2TallTyler
russian: 2 changes by Ln-Wolf
french: 11 changes by ZarTek-Creole
portuguese: 3 changes by azulcosta
polish: 28 changes by pAter-exe
english (au): 20 changes by krysclarke
spanish (mexican): 7 changes by absay
korean: 20 changes by telk5093
russian: 13 changes by Ln-Wolf
spanish: 74 changes by MontyMontana
english (au): 18 changes by krysclarke
spanish (mexican): 23 changes by absay
english (us): 18 changes by 2TallTyler
korean: 33 changes by telk5093
russian: 18 changes by Ln-Wolf
french: 31 changes by glx22
Progress bars are drawn differently depending on when it was added, with
different layouts and sizes.
This change adds a standard padding size to use, and makes all progress
bars visually similar, with scaled padding.
english (au): 12 changes by krysclarke
spanish (mexican): 24 changes by absay
english (us): 12 changes by 2TallTyler
russian: 12 changes by Ln-Wolf
french: 1 change by glx22
portuguese: 16 changes by azulcosta
english (au): 16 changes by krysclarke
english (us): 16 changes by 2TallTyler
korean: 14 changes by telk5093
hungarian: 15 changes by PstasDev
french: 18 changes by glx22
portuguese: 16 changes by azulcosta
polish: 22 changes by pAter-exe
english (au): 1 change by krysclarke
english (us): 1 change by 2TallTyler
russian: 1 change by Ln-Wolf
portuguese: 1 change by azulcosta
polish: 3 changes by pAter-exe
frisian: 33 changes by Bouke
spanish (mexican): 10 changes by absay
english (us): 4 changes by 2TallTyler
korean: 7 changes by telk5093
dutch: 3 changes by Afoklala
On HiDPI screens the zoom level is increased for detailed rendering. This causes hard-coded zoom levels to be off by this adjustment. To fix these default zoom levels, we scale the zoom level based on `_gui_zoom` to get the scaled zoom level.
frisian: 17 changes by Bouke
english (au): 1 change by krysclarke
russian: 1 change by Ln-Wolf
dutch: 4 changes by Bouke
portuguese: 4 changes by azulcosta
Terraforming through objects placed on water didn't properly remove docking tiles as expected.
By moving some logic regarding removal of docking tiles into DoClearSquare, the issue is solved, while also simplifying code, avoiding repetition elsewhere.
An AI company may have four different share owners, but the company information window is limited to display a max of three. This commit increases that limit.
Script::HasRoadType was only checking if the tile had the same RoadTramType as that of the RoadType provided.
Now it really checks RoadType against RoadType.
Tick() is a noop for all but front-engine / crashed vehicles. Starting a framerate is rather cheap, but not free, and introduces a lot of overhead for such close loops.
This means we no longer need to manually calculate the size of other
widgets in the window to determine how much space we need, as the widget
system will automatically fill as much as possible.
Resize step is normally allocated equally amongst all resizable widgets.
With this flag, we allocate as much as possible from the largest
resize step first.
Use of zero-sized plane causes the window size calculation to change
depending on which plane is displayed. Instead use an empty plane so
that largest of the planes is taken into account for sizing.
The face window previously drew the buttons of face settings itself.
Instead we can provide parameters for each widget and let the widget
system draw the buttons.
Only discard sprite zoom levels when a suitable higher zoom level is
defined in the same colour mode
This is to avoid placeholder or empty sprites being used, causing
visual artefacts
Hover highlight was visible even if the mouse pointer was in a different
window, and the window refreshed itself every frame if the mouse pointer
was not over its matrix widget.
Resolved by using OnMouseOver() instead of OnMouseLoop(), and only
redrawing if the hover position has changed.
The value 0x2110000 probably originated from a mixup between callback 14 (sprite layout) and 24 (tile layout).
The latter does indeed use a var10 value like that.
1. Built-in checks on industry level.
2. Built-in checks on industry tiles.
3. NewGRF-defined checks on industry level.
4. NewGRF-defined checks on industry tiles.
If a NewGRF assigned neither "power" nor "dual-headed" properties,
then "railveh_type" defaulted to "singlehead-engine", while "power=0" said "it's a wagon".
Basically, you could setup an auto-replace in a group for trains
to replace a ship with another ship.
Most of the code is surprisingly okay with this, it is only the
group statistics that doesn't like this.
You could give a wagon in the chain to reverse (which makes no
functional sense ofc). In result, only parts of the vehicle were
reversing, leading to weird crashes.
The bug comes in two slices:
1) the functions never actually checked if "tile" was a depot tile.
This allowed executing the function on tile 0, where are the
things like shadows of aircrafts are.
2) BuildDepotVehicleList() first checked if a vehicle is in a depot
before checking if it was a primary vehicle. This is invalid
for aircraft.
Fixing the first hides the second, and fixing the second makes the
first non-exploitable. But, fixing both felt like the best thing
to do.
Height was a unsigned 32bit integer, where TileAddWrap uses a
signed 32bit integer for the height. In result, there was an
implicit cast from unsigned to signed, messing things up.
But looking at it from a functional perspective, allowing such
large values is not sensible. In fact, width is restricted to
just a 8bit integer. By changing height to a 8bit integer too,
the implicit cast will never make a positive value negative anymore.
It first checked if the vehicle was in the depot, which for some types
is only a valid action for the primary vehicle. Afterwards, it checked
if the vehicle was a primary vehicle.
Although it was checked that RoadType was not 63 (INVALID_ROADTYPE),
and all values lower than 63 are fine, it also allowed values higher
than 63. As the RoadType is a "byte", it could contain values up
to 255.
When you don't type an Enum, it is a signed value. To validate
if an Axis is valid, it is checked to be lower than AXIS_END. Which
is the case for any value below 0.
swedish: 7 changes by translators
norwegian (bokmal): 1 change by translators
spanish (mexican): 41 changes by translators
japanese: 28 changes by translators
english (us): 4 changes by translators
vietnamese: 7 changes by translators
estonian: 60 changes by translators
korean: 9 changes by translators
greek: 4 changes by translators
hungarian: 2 changes by translators
indonesian: 5 changes by translators
italian: 12 changes by translators, 1 change by Rivarossi
german: 33 changes by translators
romanian: 11 changes by translators
russian: 4 changes by translators
finnish: 2 changes by translators
ukrainian: 5 changes by translators
slovak: 9 changes by translators
catalan: 14 changes by translators
turkish: 1 change by translators
danish: 1 change by translators
latvian: 5 changes by translators
dutch: 5 changes by translators
spanish: 98 changes by translators
portuguese: 6 changes by translators
portuguese (brazilian): 2 changes by translators, 1 change by marlondantas
polish: 13 changes by translators
english (us): 2 changes by 2TallTyler
italian: 2 changes by Rivarossi
russian: 5 changes by Ln-Wolf
dutch: 2 changes by Afoklala
french: 25 changes by glx22
portuguese: 2 changes by azulcosta
This is useful to provide a feature-agnostic, stable random value that differs between games.
One of the possible uses is to e.g. use it to create pseudo-random regions for towns or industries.
* Add: `zoomto` console command for main viewport
Similar in spirit to `scrollto`, `zoomto` takes an absolute zoom level
from the user and sets the main viewport to that level while respecting
both the absolute minimum and maximum zoom levels supported by the game
and any limitations imposed by the local client settings.
* Add: optional `instant` flag for `scrollto` command
Using this flag has two effects:
- if the user has smooth scrolling enabled, the scroll action will take
place as if it were not enabled
- the viewport is redrawn immediately, so any successive `screenshot`
command will actually work correctly
The original positional arguments are processed like same before.
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.
docs/admin_network.md promised that information in an admin packet
is never removed. It does allow the possibility of using a new packet type
for changed data in combination with a bump of the admin port version.
As the recent command handling changes modified the contents of
ADMIN_PACKET_SERVER_CMD_LOGGING, do exactly that.
If the arguments of the callback proc don't match with the command parameters,
we can't do the proper command execution anyway. As such, don't even generate
an unpack function in the first place, saving a bit of unnecessary code bloat.
Validate on receive that the cmd/callback combination is supported, rejecting
clients that try to send invalid values.
The data will be transmitted as the length followed by the serialized data. This allows the command
data to be different for every command type in the future.
This is accomplished by changing it to a single member struct with the
appropriate operator overloads to make it all work with not too much
source modifications.
This is using a non-intrusive type-traits like templated system, which
allows compile-time validation that the command table and the command
enum match up.
swedish: 1 change by joeax910
chinese (traditional): 160 changes by Tetrapod1206
galician: 21 changes by pvillaverde
irish: 5 changes by temuchie
polish: 2 changes by pAter-exe
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.
english (us): 2 changes by 2TallTyler
arabic (egypt): 49 changes by AviationGamerX
korean: 17 changes by telk5093
catalan: 2 changes by J0anJosep
danish: 4 changes by nielsmh
french: 2 changes by glx22
portuguese: 2 changes by azulcosta
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.
hungarian: 4 changes by pnpBrumi
indonesian: 41 changes by bsuseno
italian: 28 changes by CoderLel
romanian: 46 changes by kneekoo
slovak: 18 changes by ApplePie420
danish: 279 changes by nielsmh
japanese: 18 changes by akaregi, 10 changes by clzls
slovenian: 17 changes by Matej1245
czech: 33 changes by CzechRepublic98
chinese (simplified): 27 changes by clzls
arabic (egypt): 17 changes by AviationGamerX
luxembourgish: 99 changes by phreeze83
hungarian: 24 changes by pnpBrumi, 6 changes by baliball
serbian: 107 changes by nkrs
romanian: 16 changes by kneekoo, 2 changes by ALEX11BR
irish: 229 changes by temuchie
ukrainian: 113 changes by StepanIvasyn
latvian: 8 changes by lexuslatvia
lithuanian: 41 changes by devbotas
polish: 1 change by yazalo
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
swedish: 8 changes by Abbin44
norwegian (bokmal): 14 changes by Anolitt
chinese (traditional): 6 changes by SiderealArt
slovenian: 4 changes by Matej1245
vietnamese: 14 changes by KhoiCanDev
luxembourgish: 24 changes by phreeze83
hungarian: 1 change by baliball
serbian: 29 changes by nkrs
german: 1 change by SecretIdetity
russian: 2 changes by SecretIdetity, 1 change by Ln-Wolf
catalan: 1 change by J0anJosep
turkish: 1 change by ahmetlii
french: 1 change by glx22
# Only feasible way is to move away from fopen; fopen_s is optional C11 and not implemented on most platforms.
- cpp/world-writable-file-creation
# Basically OpenTTD's coding style for adding things like ..._INVALID to enumerations
- cpp/irregular-enum-init
# Our GUI code tends to use switches for OnClick handlers, DrawWidget, and UpdateWidgetSize. Sometimes GUIs just don't have many elements, but we want to keep consistency.
This project is an open source project. To get open source working as intended, many people should be able to comprehend the code. This implies that there is a well documented and uniform flow of code.
That does not necessarily mean that a contributor should not write optimised yet cryptic code - one should always care about performance. However, other developers need to understand the code which means complicated parts of code **must** have good documentation.
**Why we require that EVERYTHING is documented**<br>
What is simple to some might appear very complicated to others. Documentation helps these others. Anyone should be able to improve the code. But the main reason is, that when patch contributors want their patches added to the common codebase, the code needs to be reviewed by one or more developers. Documentation makes reviewing much easier.
## Coding style for OpenTTD
### Functions
* Function names use [CamelCase](http://www.wikipedia.org/wiki/Camelcase) without underscores.
* Opening curly bracket **{** for a function starts on the next line.
* Use Foo() instead of Foo(void).
```c++
void ThisIsAFunction()
{
}
```
### Variables
* Variable names are all lowercase, and use "_" as separator.
* Global variables are preceded by an underscore. ("_") Use descriptive names because leading underscores are often used for system / compiler variables.
* Own members of classes should always be referenced using "this->"
* Pointers and references should have their reference symbol next to the name (compatibility with current code).
* Variables that are declared below one another should have their type, name or reference operator, and assignment operator aligned by spaces.
* There are set names for many variables. Those are (but not limited to): Vehicle *u, *v, *w; Station *st; Town *t; Window *w; Engine *e.
* For multiple instances, use numbers "*t1, *t2" or postfixes "*st_from, *st_to".
* Declare variables upon first usage.
* Declare iterators in their loop.
* There is a space between '*' and 'const' in "const pointers"
```c++
int number = 10;
Vehicle *u_first_wagon = v->next;
int value = v->value;
uint32 _global_variable = 3750;
static const char * const _global_array[] = {
"first string",
"second string",
"another string",
"last string followed by comma",
};
protected:
char protected_array[10];
for (int i = 0;;);
```
* Give the variables expedient names, this increases the readability of the code
```c++
bool is_maglev_train = true;
if (!is_maglev_train) DoSomething();
```
* Some people like to introduce copies of variables to increase readability, which can waste memory. However, in some cases, especially in code pieces which are often called, it makes sense to cache some calculated variables.
* The used value of foo is calculated outside the loop.
*/
const uint32 bar = (foo * 4) % 5 + 6;
for (uint8 i = 0; i < 100000; i++) {
/* Do something */
if (value_to_check == bar) DoSomething();
/* Do something else */
}
```
### Enumerations / static consts
* Enumerations store integers that belong logically together (railtypes, string IDs, etc.).
* Enumeration names also use CamelCase.
* Unscoped enumerators are all caps with "_" between the words.
* Scoped enumerators are use CamelCase.
* Enums are not used to store single numbers.
* Enums have consecutive numbers OR
* Enums have consecutive powers of two. Powers of two (bits) are written in hex or with the shift operator.
* Enums may have special enumerators: "_BEGIN", "\_END", and "INVALID\_"). See example.
* The invalid always has 0xFF, 0xFFFF, 0xFFFFFFFF as a value.
* Other special values are consecutively less than the invalid.
* Variables that hold enumerators should have the type of the enumeration.
```c++
enum DiagDirection {
DIAGDIR_BEGIN = 0,
DIAGDIR_NE = 0,
DIAGDIR_SE = 1,
DIAGDIR_SW = 2,
DIAGDIR_NW = 3,
DIAGDIR_END,
INVALID_DIAGDIR = 0xFF,
BROKEN_DIAGDIR = 0xFE,
};
enum {
DEPOT_SERVICE = (1 << 0),
DEPOT_MASS_SEND = (1 << 1),
DEPOT_DONT_CANCEL = (1 << 2),
DEPOT_LOCATE_HANGAR = (1 << 3),
};
DiagDirection enterdir = DIAGDIR_NE;
```
* Numbers that store single or uncorrelated data are static consts. Those may use the naming conventions of enums.
Example:
```c++
static const int MAXIMUM_STATIONS = 42;
```
* Enums are useful in GUI code: When widgets are enumerated, they are easier to access during many operations. Additionally changes caused by modified widget sequences require less code adapting. If a widget is used like this, its enum name should be present in a comment behind the corresponding widget definition.
```c++
/** Enum referring to the widgets of the build rail depot window */
enum BuildRailDepotWidgets {
BRDW_CLOSEBOX = 0,
BRDW_CAPTION,
BRDW_BACKGROUND,
BRDW_DEPOT_NE,
BRDW_DEPOT_SE,
BRDW_DEPOT_SW,
BRDW_DEPOT_NW,
};
/* ... */
/** Widget definition of the build rail depot window */
* Comments on the enum values should start with "///<" to enable doxygen documentation
```c++
enum SomeEnumeration {
SE_BEGIN = 0, ///< Begin of the enumeration, used for iterations
SE_FOO = 0, ///< Used for xy
SE_BAR, ///< Another value of the enumeration
SE_SUB, ///< Special case for z
SE_END, ///< End of the enumeration, used for iterations
};
```
### Control flow
* Put a space before the parentheses in **if**, **switch**, **for** and **while** statements.
* Use curly braces and put the contained statements on their own lines (e.g., don't put them directly after the **if**).
* Opening curly bracket **{** stays on the first line, closing curly bracket **}** gets a line to itself (except for the **}** preceding an **else**, which should be on the same line as the **else**).
* When only a single statement is contained, the brackets can be omitted. In this case, put the single statement on the same line as the preceding keyword (**if**, **while**, etc.). Note that this is only allowed for if statements without an **else** clause.
* All fall throughs must be documented, using a **FALLTHROUGH** define/macro.
* The NOT_REACHED() macro can be used in default constructs that should never be reached.
* Unconditional loops are written with **`for (;;) {`**
```c++
if (a == b) {
Foo();
} else {
Bar();
}
if (very_large_checks &&
spread_over_two_lines) {
Foo();
}
if (a == b) Foo();
switch (a) {
case 0: DoSomethingShort(); break;
case 1:
DoSomething();
FALLTHROUGH;
case 2:
DoMore();
b = a;
break;
case 3: {
int r = 2;
DoEvenMore(a);
FALLTHROUGH;
}
case 4: {
int q = 345;
DoIt();
break;
}
default:
NOT_REACHED();
}
for (int i = 0; i < 10; i++) {
Foo();
Bar();
}
```
### Classes
* Classes names also use CamelCase.
* Classes should have "public", "protected", and "private" sections.
* Within these section the order is: types, static const members, static members, members, constructors / destructors, static methods, methods.
* Deviations from above order are allowed when the code dictates it (e.g. a static const is needed for a typedef)
* Methods and members ought to be grouped logically.
* All those sorting rules sometimes conflict which one another. Please use common sense what increases legibility of the code in such a case.
* The method implementation should indicate if it is virtual or similar by using a comment.
* Very short methods can have one-line definition (if defined in the class scope).
```c++
class ThisIsAClass {
public:
typedef Titem_ *ItemPtr;
private:
static const int MAX_SIZE = 500;
int size;
ItemPtr *items;
public:
explicit ThisIsAClass();
~ThisIsAClass();
int GetSize() { return this->size; }
virtual void Method();
};
/*virtual*/ void Class::Method()
{
this->size *= 2;
}
```
### Templates
Templates are a very powerful C++ tool, but they can easily confuse beginners. Thus:
* Templates are to be documented in a very clear and verbose manner. Never assume anything in the documentation.
* the template keyword and the template layout get a separate line. typenames are either "T" or preceded by a "T", integers get a single capital letter or a descriptive name preceded by "T".
```c++
template <typename T, typename Tsomething, int N, byte Tnumber_of_something>
int Func();
```
* If you are writing one or more template class in the dedicated header file, use file.hpp for its name instead of file.h. This will let others know that it is template library (includes also implementation), not just header with declarations.
### Other important rules
* Put a space before and after binary operators: "a + b", "a == b", "a & b", "a <<= b", etc.. Exceptions are ".", "->" and "[]" (no spaces) and "," (just space after it).
* Put parenthesis where it improves readability: "*(b++)" instead of "*b++", and "if ((a & b) && c == 2)" instead of "if (a & b && c == 2)".
* Do not put external declarations in implementation (i.e. cpp) files.
* Use const where possible.
* Do not typedef enums and structs.
* Don't treat non-flags as flags: use "if (char_pointer != nullptr && *char_pointer != '\0')", not "if (char_pointer && *char_pointer)".
* Use "free(p)" instead of "if (p != nullptr) free(p)". "free(nullptr)" doesn't hurt anyone.
* No trailing whitespace. The Github workflows will not allow tabs or space on the end of lines.
* Only use tabs to indent from the start of the line.
* Line length is unlimited. In practice it may be useful to split a long line. When splitting, add two tabs in front of the second part.
* The '#' of preprocessor instructions goes into the first column of a line. Indenting is done after the '#' (using tabs again).
* Use /* */ for single line comments.
* Use // at the end of a command line to indicate comments.
** However, use /* */ after # preprocessor statements as // causes warnings in some compilers and/or might have unwanted side effects.
* C++ is defined using the ASCII character set. Do not use other character sets, not even in comments.
* OpenTTD includes some Objective-C sources (*.mm, used by OSX), which has a special object method invocation syntax: "[ obj doStuff:foo ]". Please use spaces on the inside of the brackets to differentiate from the C array syntax.
## Documentation
We use [Doxygen](http://doxygen.org/) to automatically generate documentation from the source code. It scans the source files for *recognizable* comments.
* **Make your comments recognizable.**
Doxygen only comments starting with the following style:
```c++
/**
///<
```
Use /** for multi-line comment blocks. Use ///< for single line comments for variables. Use //!< for single-line comments in the NoAI .hpp files.
For comments blocks inside a function always use /* */ or //. Use // only if the comment is on the same line as an instruction, otherwise use /* */.
### Files
* Put a @file command in a JavaDoc style comment at the start of the file, followed by a description.
```c++
/**
* @file
* This is the brief description.
* This is the detailed description here and on the following lines.
*/
```
> ### Warning
> If a file lacks a **file comment block** then NO entities in that file will be documented by Doxygen!
### Functions
* The documentation should be as close to the actual code as possible to maximise the chance of staying in sync.
* Comments for functions go in the .cpp file.
* Comments for inlines go in the .h/.hpp file.
* Small inlines can have a short 3 or 4 line JavaDoc style comment.
* Completely document larger functions.
* Document obvious parameters and return values too!
```c++
/**
* A brief explanation of what the function does and/or what purpose it serves.
* Then follows a more detailed explanation of the function that can span multiple lines.
*
* @param foo Explanation of the foo parameter
* @param bar Explanation of the bar parameter
* @return The sum of foo and bar (@return can be omitted if the return type is void)
*
* @see SomeOtherFunc()
* @see SOME_ENUM
*
* @bug Some bug description
* @bug Another bug description which continues in the next line
* and ends with the following blank line
*
* @todo Some to-do entry
*/
static int FooBar(int foo, int bar)
{
return foo + bar;
}
```
### Classes
* Document structs similarly to functions:
```c++
/**
* A short description of the struct.
* More detailed description of the its usage.
*
* @see [link to anything of interest]
*/
struct foo {
}
```
### JavaDoc structural commands
This table shows the commands you should use with OpenTTD. The full list is [here](http://www.stack.nl/~dimitri/doxygen/commands.html).
| Command | Action | Example |
| ------- | -------- | ------- |
| **@attention** | Starts a paragraph where a message that needs attention may be entered. The paragraph will be indented. | @attention Whales crossing! |
| **@brief** | Starts a paragraph that serves as a brief description. For classes and files the brief description will be used in lists and at the start of the documentation page. For class and file members, the brief description will be placed at the declaration of the member and prepended to the detailed description. A brief description may span several lines (although it is advised to keep it brief!). | @brief This is the brief description. |
| **@bug** | Starts a paragraph where one or more bugs may be reported. The paragraph will be indented. Multiple adjacent @bug commands will be joined into a single paragraph. Each bug description will start on a new line. Alternatively, one @bug command may mention several bugs. | @bug Memory leak in here? |
| **@note** | Starts a paragraph where a note can be entered. The paragraph will be indented. | @note Might be slow |
| **@todo** | Starts a paragraph where a TODO item is described. The description will also add an item to a separate TODO list. The two instances of the description will be cross-referenced. Each item in the TODO list will be preceded by a header that indicates the origin of the item. | @todo Better error checking |
| **@warning** | Starts a paragraph where one or more warning messages may be entered. The paragraph will be indented. | @warning Not thread safe! |
| | <small>**Function related commands**</small> | |
| **@return** | Starts a return value description for a function. | @return a character pointer |
| **@param** | Starts a parameter description for a function parameter with name <parameter-name>. Followed by a description of the parameter. The existence of the parameter is checked and a warning is given if the documentation of this (or any other) parameter is missing or not present in the function declaration or definition.<br><br>The @param command has an optional attribute specifying the direction of the attribute. Possible values are "in" and "out". | @param n The number of bytes to copy<br>@param[out] dest The memory area to copy to.<br>@param[in] src The memory area to copy from. |
| **@see** | Starts a paragraph where one or more cross-references to classes, functions, methods, variables, files or URL may be specified. Two names joined by either :: or # are understood as referring to a class and one of its members. One of several overloaded methods or constructors may be selected by including a parenthesized list of argument types after the method name. [Here](http://www.stack.nl/~dimitri/doxygen/autolink.html) you can find detailed information about this feature. | @see OtherFunc() |
| **@b** | Displays the following word using a bold font. Equivalent to <b>word</b>. To put multiple words in bold use <b>multiple words</b>.| ...@b this and @b that... |
| **@c / @p** | Displays the parameter <word> using a typewriter font. You can use this command to refer to member function parameters in the running text. To have multiple words in typewriter font use <tt>multiple words</tt>. | ... the @p x and @p y coordinates are used to... |
| **@arg / @li** | This command has one argument that continues until the first blank line or until another @arg / @li is encountered. The command can be used to generate a simple, not nested list of arguments. Each argument should start with an @arg / @li command. | @arg @c AlignLeft left alignment.<br>@arg @c AlignCenter center alignment.<br>@arg @c AlignRight right alignment |
| **@n** | Forces a new line. Equivalent to and inspired by the printf function. |@n |
### More on Doxygen and JavaDoc
Doxygen knows two different kinds of comments:
* *Brief descriptions*: one-liners that describe the function roughly ([example](http://docs.openttd.org/annotated.html))
* *Detailed descriptions*: as the name suggests, these contain the detailed function/purpose of the entity they describe ([example](http://docs.openttd.org/structBridge.html))
You can omit either one or put them into different places but there's only one brief and one detailed description allowed for the same entity.
Doxygen knows three modes for documenting an entity:
* Before the entity
* After the entity
* In a different file
The latter is a little harder to maintain since the prototype of the entity it describes then is stored in several places (e.g. the .h file and the file with the descriptions). Also while it makes the code easier to read it also makes it easier to omit the important step of updating the description of an entity if it was changed - and we all know why that shouldn't happen ;)<br>
Because of those reasons, we will only use the first two documentation schemes.
Doxygen supports both Qt and JavaDoc comment styles:
* Qt style example: **int i; //!< The counter for the main loop**
* JavaDoc style example: **int i; /*\*< The counter for the main loop \*/**
It also supports more comment styles but those two are the ones which are standardized. For OTTD we'll be using the JavaDoc style. One of the reasons is that it has a feature that the Qt style doesn't offer: JavaDoc style comment blocks will automatically start a brief description which ends at the first dot followed by a space or new line. Everything after that will also be part of the detailed description.
The general structure of a JavaDoc style comment is
```c++
/**
* This is the brief description. And this sentence contains some further explanations that will appear in the detailed description only.
*/
```
and the resulting descriptions of that block would be:
* *Brief description*: This is the brief description.
* *Detailed description*: This is the brief description. And this sentence contains some further explanations that will appear in the detailed description only.
The distinction between the brief and detailed descriptions is made by the dot followed by a space/newline, so if you want to use that inside the brief description you need to escape the space/newline:
```c++
/**
* This is a brief description (e.g.\ using only a few words). Details go here.
*/
```
If you're doing a one-line comment, use:
```c++
int i; ///< This is the description.
```
Also in the comment block you can include so-called structural commands which tell Doxygen what follows. In general, their area of effect begins after the command word and ends when a blank line or some other command is encountered. Also, multiple occurrences of the same structural command within a comment block or the referring entity will be joined in the documentation output usually.
## Commit message
To achieve a coherent whole and to make changelog writing easier, here are some guidelines for commit messages.
There is a check-script on the git server (also available for clients, see below) to make sure we all follow those rules.
* Add, Feature: Adding new stuff. Difference between "Feature" and "Add" is somewhat subjective. "Feature" for user-point-of-view stuff, "Add" for other.
* Change: Changing behaviour from user-point-of-view.
* Remove: Removing something from user-point-of-view.
* Codechange, Cleanup: Changes without intentional change of behaviour from user-point-of-view. Difference between "Codechange" and "Cleanup" is somewhat subjective.
* Fix, Revert: Fixing stuff.
* Doc, Update: Documentation changes, version increments, translator commits.
* Prepare: Preparation for bigger changes. Rarely used.
If you commit a fix for an [issue](https://github.com/OpenTTD/OpenTTD/issues), add the corresponding issue number in the form of #NNNN. Do it as well if you implement a feature with a matching entry.
In the case of bugfixes, if you know what revision the bug was introduced (eg regression), please mention that revision as well just after the prefix. Finding the trouble-causing revision is highly encouraged as it makes backporting/branching/releases that much easier.
To further structure the changelog, you can add sections. Example are:
* "Network" for network specific changes
* "NewGRF" for NewGRF additions
* "YAPP", "NPF", for changes in these features
* "OSX", "Debian", "win32", for OS-specific packaging changes
Further explanations, general bitching, etc. don't go into the first line. Use a new line for those.
Complete examples:
* Fix: [YAPF] Infinite loop in pathfinder.
* Fix #5926: [YAPF] Infinite loop in pathfinder.
* Fix 80dffae130: Warning about unsigned unary minus.
* Fix #6673, 99bb3a95b4: Store the map variety setting in the samegame.
* Revert d9065fbfbe, Fix #5922: ClientSizeChanged is only called via WndProcGdi which already has the mutex.
You can open the folder (as a CMake project). CMake will be detected, and you can compile from there.
@@ -69,7 +77,7 @@ 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"
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
@@ -97,7 +105,7 @@ 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
significantly 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.
@@ -14,7 +14,7 @@ In return, they should reciprocate that respect in addressing your issue or asse
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/en/Development/IRC%20channel), or the [forums](https://www.tt-forums.net/)
Please try [irc](https://wiki.openttd.org/en/Development/IRC%20channel), [Discord](https://discord.gg/openttd), 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.
@@ -23,7 +23,7 @@ Use [GitHub's "reactions" feature](https://github.com/blog/2119-add-reactions-to
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.
These are created by third-parties. Please try [irc](https://wiki.openttd.org/en/Development/IRC%20channel), [Discord](https://discord.gg/openttd), 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.
@@ -94,8 +94,8 @@ 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/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 :)
It's usually best to discuss on [Discord](https://discord.gg/openttd) before opening a feature request or working on a large feature in a fork.
Discussion can take time, but it can be productive and avoid disappointment. :)
## Pull requests
@@ -108,7 +108,7 @@ Pull requests should fit with the [goals of the project](./CONTRIBUTING.md#proje
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).
[Code style](./CODINGSTYLE.md) must be complied with for pull requests to be accepted; this also includes [commit message format](./CODINGSTYLE.md#commit-message).
Adhering to the following process is the best way to get your work included in the project:
@@ -136,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/en/Development/Coding%20style#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](./CODINGSTYLE.md#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:
@@ -172,7 +172,7 @@ 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.
Tip: [commit message format](https://wiki.openttd.org/en/Development/Coding%20style#commit-message) is a common reason for pull requests to fail validation.
Tip: [commit message format](./CODINGSTYLE.md#commit-message) is a common reason for pull requests to fail validation.
### Are there any development docs?
@@ -212,8 +212,8 @@ 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.
To please everyone, the official branch tries to stay close to the original gameplay; after all, that is what brought everyone here.
The preferred method to alter and extend 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".
@@ -265,5 +265,5 @@ If you would not like to accept this risk, please do either commit anonymously o
### 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).
@@ -77,9 +77,9 @@ For some platforms, you will need to refer to [the installation guide](https://w
The free data files, split into OpenGFX for graphics, OpenSFX for sounds and
OpenMSX for music can be found at:
- https://www.openttd.org/downloads/opengfx-releases/ for OpenGFX
- https://www.openttd.org/downloads/opensfx-releases/ for OpenSFX
- https://www.openttd.org/downloads/openmsx-releases/ 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.
@@ -116,35 +116,6 @@ Most types of add-on content can be downloaded within OpenTTD via the 'Check Onl
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).
### 1.5.1) AI opponents
OpenTTD comes without AI opponents, 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.
AI help and discussions may also be found in the [AI section of the forum](https://www.tt-forums.net/viewforum.php?f=65).
### 1.5.2) Scenarios and height maps
Scenarios and heightmaps can be added via the 'Check Online Content' button in the main menu.
### 1.5.3) NewGRFs
A wide range of add-content is available as NewGRFs, including vehicles, industries, stations, landscape objects, town names and more.
NewGRFs can be added via the 'Check Online Content' button in the main menu.
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).
### 1.5.4) Game scripts
Game scripts can provide additional challenges or changes to the standard OpenTTD gameplay, for example setting transport goals, or changing town growth behaviour.
Game scripts can be added via the 'Check Online Content' button in the main menu.
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).
### 1.6) OpenTTD directories
@@ -162,8 +133,9 @@ If you want to compile OpenTTD from source, instructions can be found in [COMPIL
'Official' channels
- [OpenTTD website](https://www.openttd.org)
- [OpenTTD official Discord](https://discord.gg/openttd)
- 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
- [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
@@ -202,12 +174,14 @@ 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.
The catch2 implementation in `src/3rdparty/catch2` is licensed under the Boost Software License, Version 1.0.
See `src/3rdparty/catch2/LICENSE.txt` for the complete license text.
The icu scriptrun implementation in `src/3rdparty/icu` is licensed under the Unicode license.
See `src/3rdparty/icu/LICENSE` for the complete license text.
* 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/>.
*/
AILog.Info("12 API compatibility in effect.");
/* 13 really checks RoadType against RoadType */
AIRoad._HasRoadType <- AIRoad.HasRoadType;
AIRoad.HasRoadType <- function(tile, road_type)
{
local list = AIRoadTypeList(AIRoad.GetRoadTramType(road_type));
* 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 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/>.
*/
GSLog.Info("12 API compatibility in effect.");
/* 13 really checks RoadType against RoadType */
GSRoad._HasRoadType <- GSRoad.HasRoadType;
GSRoad.HasRoadType <- function(tile, road_type)
{
local list = GSRoadTypeList(GSRoad.GetRoadTramType(road_type));
* 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/>.
Fix: Validation of various internal command parameters that could have allowed a rogue client to crash servers (#9942, #9943, #9944, #9945, #9946, #9947, #9948, #9950)
Fix #9937: Station industries_near incorrect after removing part moved sign (#9938)
Fix: [Script] ScriptRoad::HasRoadType really check for RoadType (#9934)
Fix #9363: Rebuild client list on reinit event (#9929)
Fix #9925: Industry tile layout validation for layouts of only one tile (#9926)
Fix #9918: Reset industy last production year on scenario start (#9920)
Fix #9914: Prevent more useless pathfinder run for blocked vehicles (#9917)
Fix: List a max of four share owners instead of three (#9905)
Fix: [NewGRF] Industry layouts with zero regular tiles should be invalid (#9902)
Fix #9869: Remove docking tile when doing a clear square (#9898)
Fix: New player companies use favorite manager face, if saved (#9895)
@@ -203,7 +203,7 @@ the array so you can quickly see what is used and what is not.
<tdclass="bits"><spanclass="usable"title="Graphics index">OOOO O</span><spanclass="used"title="Graphics index: 00 (exit towards NE), 01 (exit towards SE), 02 (exit towards SW), 03 (exit towards NW), 04 (drive through X), 05 (drive through Y)">XXX</span></td>
This guide is for OpenTTD developers/maintainers, to release a new version of OpenTTD.
## Step 0: Branch or Backport
* If this is a beta version release, skip this step.
* If this is an RC1 (first Release Candidate) build, create a new branch `release/nn` where `nn` is the major version number, then apply changes similar to [PR#9573](https://github.com/OpenTTD/OpenTTD/pull/9573). You also need to forwardport the changelog, as in [PR#10113](https://github.com/OpenTTD/OpenTTD/pull/10113).
* Update CMakeLists.txt
* Add a new (empty) AI compatibility script in bin/ai/
* Add the new version to CheckAPIVersion in src/ai/ai_info.cpp + src/game/game_info.cpp
* Add the new version to src/script/api/ai_changelog.hpp + src/script/api/game_changelog.hpp
* Update the version of regression in bin/ai/regression/regression_info.nut
* Add a note to src/saveload/saveload.h about which savegame version is used in the branch.
* If this is a later RC or release build and the release branch already exists, you'll need to backport fixes and language from master to this branch, which were merged after the branch diverged from master. You can use these two helper scripts: https://github.com/OpenTTD/scripts/tree/main/backport
## Step 1: Prepare changelog documentation
1. Update the [changelog](../changelog.txt) with new changes since the last release.
* Changelog entries are typically PR titles, but can be edited to be more helpful without context.
* Don't include fixes to things which haven't previously been released (like fixes to features which are in the same changelog).
* Order the entries by importance: `Feature > Add > Change > Fix`, then numerically by PR number.
2. Create a changelog PR, get approval, and merge.
* For beta releases, target master, otherwise target the release branch.
## Step 2: Prepare website release announcement
1. Go to https://github.com/OpenTTD/website/new/main/_posts and write a new announcement post. See a [previous example](https://github.com/OpenTTD/website/pull/238) for a template.
2. Create a new branch for this post and open a PR for it.
3. Write announcement text for socials like Forum/Discord/Twitter/Reddit and include it in the PR.
4. Create a Steam news image for that post and include it in the PR.
5. Check the website post (preview link via checks page) and make corrections. We usually just use the GitHub web interface for this and squash the result later.
6. Get this PR approved, but do not merge yet.
## Step 3: Make the actual OpenTTD release
1. Go to https://github.com/OpenTTD/OpenTTD/releases/new and create a new tag matching the release number. For the body of the release, see any older release. "Set as a pre-release" for a beta or RC, set as latest for a real release.
2. Merge website PR.
3. Wait for the OpenTTD release checks to be complete.
4. Check that website links to the new release are working and correct, using the [staging website](https://www-staging.openttd.org/).
5. If this is a full release, ask orudge to update the Microsoft Store and TrueBrain to move the release from the "testing" to "default" branch on Steam.
## Step 4: Tell the world
1. Tag and create a website release to trigger the actions that update the website.
2. After the website is live, make announcements on social media. You may need to coordinate with other developers who can make posts on Twitter, Reddit, Steam, and GOG.
For all official releases, OpenTTD collects the Breakpad Symbols (SYM-files) and Microsoft's Symbols (PDB-files), and publishes them on our own Symbol Server (https://symbols.openttd.org).
These symbol files are needed to analyze `crash.dmp` files as attached to issues by users.
A `crash.dmp` is created on Windows, Linux, and MacOS when a crash happens.
This combined with the `crash.log` should give a pretty good indication what was going on at the moment the game crashed.
## Analyzing a crash.dmp
### MSVC
In MSVC you can add the above URL as Symbol Server (and please enable MSVC's for all other libraries), allowing you to analyze `crash.dmp`.
Now simply open up the `crash.dmp`, and start debugging.
### All other platforms
The best tool to use is `minidump-stackwalk` as published in the Rust's cargo index:
```bash
cargo install minidump-stackwalk
```
For how to install Rust, please see [here](https://doc.rust-lang.org/cargo/getting-started/installation.html).
// 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/>.
// 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/>.
//
-1 * 0 0C "One way road graphics"
-1 * 3 05 09 06
-1 sprites/oneway.png 8bpp 34 8 24 16 -12 -8 normal
-1 sprites/oneway.png 8bpp 66 8 24 16 -12 -8 normal
-1 sprites/oneway.png 8bpp 98 8 24 16 -12 -8 normal
-1 sprites/oneway.png 8bpp 130 8 24 16 -12 -8 normal
-1 sprites/oneway.png 8bpp 162 8 24 16 -12 -8 normal
-1 sprites/oneway.png 8bpp 194 8 24 16 -12 -8 normal
-1 * 3 05 09 12
-1 sprites/oneway.png 8bpp 34 8 24 16 -10 -9 normal
-1 sprites/oneway.png 8bpp 66 8 24 16 -13 -7 normal
-1 sprites/oneway.png 8bpp 98 8 24 16 -12 -8 normal
-1 sprites/oneway.png 8bpp 130 8 24 16 -15 -10 normal
-1 sprites/oneway.png 8bpp 162 8 24 16 -12 -9 normal
-1 sprites/oneway.png 8bpp 194 8 24 16 -11 -8 normal
-1 sprites/oneway.png 8bpp 34 40 24 16 -13 -10 normal
-1 sprites/oneway.png 8bpp 66 40 24 16 -12 -8 normal
-1 sprites/oneway.png 8bpp 98 40 24 16 -12 -9 normal
-1 sprites/oneway.png 8bpp 130 40 24 16 -11 -8 normal
-1 sprites/oneway.png 8bpp 162 40 24 16 -9 -10 normal
-1 sprites/oneway.png 8bpp 194 40 24 16 -10 -9 normal
-1 sprites/oneway.png 8bpp 34 72 24 16 -8 -11 normal
-1 sprites/oneway.png 8bpp 66 72 24 16 -11 -5 normal
-1 sprites/oneway.png 8bpp 98 72 24 16 -12 -8 normal
-1 sprites/oneway.png 8bpp 130 72 24 16 -12 -5 normal
-1 sprites/oneway.png 8bpp 162 72 24 16 -14 -10 normal
-1 sprites/oneway.png 8bpp 194 72 24 16 -12 -8 normal
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.