Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Record/replay input logs #1096
This PR lets you record and replay a log of all the input given to Player.
This moves towards #646.
Record a log with
and then replay it with
If you also use the same
The intention is that this could eventually be used for automated regression testing, as bug reporting data, to confirming bugs still exist, etc. If Ghabry's event tracer can be rigged to give compatible output it could also be used for compatibility testing with RPG_RT. Right now, you could technically use it to look for changes between Player versions by comparing save files (ie. record a playthrough where you save, modify Player, replay the log, diff the
Input Log Format
The input log is plain-text. There is one line for each call to
The format is really just proof-of-concept and we'll probably want something more efficient and robust. If the general idea of this PR looks good and there's no bugs, I can open an issue afterwards to talk about a good format for this.
Thx for the PR, will take a look later.
And the replays will not sync on different platforms because "rand()" depends on the used libc. This can be resolved by replacing rand() everywhere with Utils::GetRandomNumber() which uses std::mt19937 which generates the same output on all platforms (at least the standard says so, untested).
Combined with a way to take screenshots during recording and to compare them during replay this feature could be also used to test parts of the Player that can't be tested using event tracing e.g. detecting of rendering regressions (only regression tests are possible because you need a screenshot of the correct state :D).
Yeah, you definitely need to restore the save files to reproduce a run. Even ignoring that desync, the saves have a
I have a branch with the relevant fixes for
Now that I think of it, there might also be an issue with the BGM ticks. Do you know how reproducible those are? It looks like they depend on the audio implementation.
edit: The screenshot button is recorded in the log too! Like with save files, you'd have to record, move them to a different folder, replay, then compare.
For this prototype implementation it's good enough for me when you document that savegames must be part of the movie. Can be fixed later using a different movie format / movie folder which somehow stores the savegames together with the movie.
Okay, then I ignore rand for now.
The timestamp is a design flaw in liblcf. Not liblcf should set the timestamp but the caller of liblcf. This is a problem in lcf2xml, too because the timestamp gets updated when converting back and forth :/. If you want you can submit a patch to liblcf which removes the "GenerateTimestamp" call and put it at an appropriate spot in Player.
BGM_Ticks doesn't return the correct value by now. When BGM_Ticks ever gets fixed it should return the same output on any platform and the only game I know which depends on BGM_Ticks is one of the "Mother" games which has the combo system implemented in an acustic way (not working in EasyRPG yet).