* Use std::vector of quadrants
* Prevent ptr invalidation issues
* Remove next_in_quadrant
* Make review changes
* Rebuild next_in_quadrant for S6Export
* Fix formatting
* Constexpr where possible
* Increment network version and update replays
* Implement EntityLists
* Remove dead code
* Use alternative name for iterator
* Add comments
* Increment network version
* Update replays
* Remove further dead code
* Update replays again
* Move type field into sub structures
* Use type for misc_type
* Use type for l_type
* Rename to SubType
* Rename SpriteGeneric to MiscEntity
* Rename generic to misc
* Add extra nullptr checks for compilers that cant understand
* Make review changes
* Increment network version
* Update replays
* Fix#13409: Clamp peep distances from path centers
The debunch-peeps improvement did not account for the fact that peeps may change direction when they are only at the very edge of a tile - it's not entirely clear to me why this happens, but it does. The previous code would push these peeps back towards the center line over time, but the new behaviour allows them to keep walking along these very edge-y lines, which means they sometimes appear to be walking on the wrong sides of benches, railings, etc.
To fix the problem, do not simply keep the target coordinate constant for the direction the peep is moving in, but clamp it, so that peeps in these outlier positions will get pulled back to a more acceptable position within one tile. Peeps who are already debunched within the reasonable center area of the path are unaffected.
* Update replays for change
* Add changelog entry
* Fix broken hashes
Co-authored-by: duncanspumpkin <duncans_pumpkin@hotmail.co.uk>
* Stop guests from being forced to the center line of a path over time
Change the way we apply randomness to peep destinations when moving from one tile to the next, to allow peeps that are moving along a straight path to maintain their perpendicular offset relative to the path direction, instead of being (eventually) forced back to the center line.
* Update test expectations
The changes to guest movement mean that the number of steps taken for these expected paths are now slightly different to before.
* Make all game actions take an ObjectEntryIndex where applicable
* Update replays for parameter size change
Co-authored-by: duncanspumpkin <duncans_pumpkin@hotmail.co.uk>
This speeds up CMake recompilation significantly.
The default behaviour is to search for CCache and use it if
available; this can be disabled explicitly by setting
OPENRCT2_USE_CCACHE=OFF in CMake.
* Increase randomness when handyman is on queue path
* Add myself to contributors
* Refactor hex variable probabilities
* Add check if queue is connected to a ride
* Update changelog
* Bump network version
* Update replays
Co-authored-by: duncanspumpkin <duncans_pumpkin@hotmail.co.uk>
Error messages produced by MinGW look like:
```
In file included from ../src/openrct2/world/Banner.cpp:10:0:
../src/openrct2/world/Banner.h:29:8: error: potential null pointer dereference [-Werror=null-dereference]
struct Banner
^~~~~~
```
- Ensure static CRT is used when compiling.
- Allow Ninja generator to work (remove use of CMAKE_VS_PLATFORM_NAME).
- Move CMakeSettings.json to new standard location for VS.
If OpenRCT2 is compiled without GUI (for example as a dedicated server),
it does not make sense to install the desktop and icon files.
Signed-off-by: Conrad Kostecki <conrad@kostecki.com>
For a package maintainer, it should be possible to disable the support
for discord-rpc and google benchmark, as it currently always includes them,
when the library if found.
duncanspumpkin