-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Replay System
OpenRCT2 has a replay system that allows you to record and replay game actions such as placing footpath or creating an entire coaster. This system can be used to create regression tests so previous fixed bugs will be caught if they somehow manage to slip in again.
The system will record every command such as placing footpath, creating a ride, modifying its attributes etc. To start a recording, open the in-game console and type:
replay_startrecord example_recording
After pressing enter it should display a red text on the screen showing that the recording is active. Now you can start issuing commands. If you are done recording you can stop it via the console, just type:
replay_stoprecord
That should create a file in your user data folder under in a folder called "replay", the file will be located at:
Windows: %USERPROFILE%\Documents\OpenRCT2\replay\example_recording.sv6r
Linux: ~/.config/OpenRCT2/replay/example_recording.sv6r
To play a replay use the in-game console and type following:
replay_start <input_file>
If the file path is not absolute it will try to load it from your user data folder. From this point on it should play all commands back and keeps the game locked during replays, you can not interact during this stage such as placing or removing elements. The replay will automatically stop if the recording ended and you will gain full control back. To forcefully stop a replay you can use the following in-game console command:
replay_stop
Which will immediately stop the replay.
This is practical for the tests to remove all unnecessary gaps between the commands, it will invoke one command per tick to speed up things. To normalise a replay you can use following command in the in-game console:
replay_normalise <input_file> <output_file>
You can use the same output_file as input_file to overwrite the input. This process can be also used to correct pre-existing replays that will have a different sprite checksum due to game changes, running normalise on a replay will always create up to date checksums.
All pull requests are tested by running a number of replays against the new build. They will fail if the sprite checksum differs. This can happen during logic changes. To fix a failing test you will need to rerecord it by using the replay_normalise
command. If the replay that has failed in bpb1000Ticks then you will need to rerecord using replay_startrecord bpb1000Ticks 1000
with the bpb save open (bpb is available in the test data folder). To help work out what has caused the failure replay desync logs are generated when playing a replay. Check the desync folder for the report after playing a replay.
Unfortunately at this time replays x64 and x86 platforms will generate different sprite checksums. For this reason only x64 builds are checked during the CI tests. All replays in the replays repo have been recorded on x64 platforms.
- Home
- FAQ & Common Issues
- Roadmap
- Installation
- Building
- Features
- Development
- Benchmarking & stress testing OpenRCT2
- Coding Style
- Commit Messages
- Overall program structure
- Data Structures
- CSS1.DAT
- Custom Music and Ride Music Objects
- Game Actions
- G1 Elements Layout
- game.cfg structure
- Maps
- Music Cleanup
- Objects
- Official extended scenery set
- Peep AI
- Peep Sprite Type
- RCT1 ride and vehicle types and their RCT2 equivalents
- RCT12_MAX_SOMETHING versus MAX_SOMETHING
- Ride rating calculation
- SV6 Ride Structure
- Settings in config.ini
- Sizes and angles in the game world
- Sprite List csg1.dat
- Sprite List g1.dat
- Strings used in RCT1
- Strings used in the game
- TD6 format
- Terminology
- Track Data
- Track Designs
- Track drawers, RTDs and vehicle types
- Track types
- Vehicle Sprite Layout
- Widget colours
- Debugging OpenRCT2 on macOS
- OpenGL renderer
- Rebase and Sync fork with OpenRCT2
- Release Checklist
- Replay System
- Using minidumps from crash reports
- Using Track Block Get Previous
- History
- Testing