This pull request is spun off from Unify Speed #16692 for ease of review, as well as making it easier to address some future features independent of Unify Speed.
This PR separates the OperationSettings field of RTD into 3 new fields, since the OperationSettings struct was bloated with things that are not operation settings.
This PR implements legacy and non-legacy ("modern") booster setting fields. In preparation for Unify Speed, the legacy properties are set to match the values as they stand. Separating legacy from modern allows the modern values to be changed in accordance with #21752 while preserving backwards-compatibility.
Unify Speed or a spun-off subset PR will implement a vehicle flag to switch between legacy and modern behavior, which all older parks will import with, while new rides will use the non-legacy "modern" behavior. Unify speed or a spin-off will implement enforcing brake and booster speeds.
This consists mostly of using `TrackPaintUtilDiagTilesPaint()` where appropriate, as well as cleaning up some duplicate constants in the monorail/miniature railway paint code.
* Remove dependency on StringIds.h from Localisation.h
* Include Language.h in UTF8.cpp for function declarations
* Rename tests/Localisation.cpp to tests/LocalisationTest.cpp
FixedVector class requires use of algorithm include, one of C++'s
heaviest, while in practice it is used only in handful of places.
See #21947 for methodology
372-266=106 #include <algorithm>s fewer
* Part of #21421: refactor TUNNEL_MAX_COUNT
* Part of #21421: deleted unused OBJECT_SELECTION_NOT_...
* Part of #21421: refactor MAX_SERVER_DESCRIPTION_LENGTH
* Part of #21421: refactor EXPENDITURE_TABLE_MONTH_COUNT
* Part of #21421: refactor FINANCE_GRAPH_SIZE
* Part of #21421: refactor NETWORK_STREAM_VERSION and _ID
* Part of #21421: MONEY_STRING_MAXLENGTH
* Part of #21421: deleted MAX_USER_STRINGS
* Part of #21421: refactor USER_STRING_MAX_LENGTH
* Part of #21421: deleted USER_STRING_END
* Part of #21421: refactor REAL_NAME_START
* Part of #21421: refactor REAL_NAME_END
* Part of #21421: deleted FONT(X) and FONT_OPENRCT2_SPRITE
* Part of #21421: refactor CURRENCY_SYMBOL_MAX_SIZE
* Part of #21421: refactor CURRENCY_RATE_MAX_NUM_DIGITS
* Part of #21421: refactor SCROLLABLE_ROW_HEIGHT
* Part of #21421: refactor ADD_CLAMP_BODY
* Part of #21421: applied clang-format to Util.cpp
* Part of #21421: incorporate feedback from #21760
* Part of #21421: revert to nbsp in Currency.cpp
* Part of #21421: fix merge conflict
* Part of #21421: fix more merge conflict
* Part of #21421: apply clang format
* Part of #21421: using std::numerics for finding bounds
* Part of #21421: fix reference to kAddClampBody
* Part of #21421: improved on comments about AddClamp func
* Part of #21421: apply correct network stream version number
* Part of #21421: apply clang-format
In order to transition staff costumes to objects, we must further disentangle staff from regular peeps. This has many advantages, such as making custom entertainers or even handymen costumes. However, this means putting some restrictions on what costumes can be assigned to staff in the mean while.
We are aware of plug-ins allowing staff to be decorated like normal peeps, though, e.g. using @Manticore-007's Peep Editor. Splitting staff from peeps will mean breaking such functionality. We can do our very best to reverting 'invalid' staff to their normal outfits instead of them outright disappearing. However, in the mean time, we should disallow peep costumes from being assigned to staff to prevent further disappointment down the line.
Once we get to actually adding custom staff costumes, I plan to add a new plug-in API to get available costumes for a particular staff type. This would apply to entertainers, but also other staff types. This should make it easier for plug-in authors to tap into custom costumes in the future.
Aaron van Geffen