New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
EVENTRECORDER: fixes for keymapper custom engine events #3085
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Thank you for looking into this. Answering your question. No, it was not intended. The custom events were introduced later, and since the event recorder is not enabled by default, nobody noticed that it is not processing them. You do not really need to bump the version, because the feature was not used, so it is safe to keep it a v1 for now. |
mgerhardy
force-pushed
the
pr/eventrecorder
branch
2 times, most recently
from
June 24, 2021 17:39
2aa1b98
to
8708260
Compare
mgerhardy
force-pushed
the
pr/eventrecorder
branch
2 times, most recently
from
July 7, 2021 17:23
094554e
to
185aeaf
Compare
the custom engine events were missing and the default event manager transforms the backend events . Which means that the event recorder is not persisting the low level key press/release events but the already transformed custom engine events of the keymapper
they are running as event source and would bring the event recorder into an out-of-sync state
This might also become a return to launcher, but I've somehere read the hint that the event recorder was only meant to play back one game per session. We'll see.
…sMillis() If for some reason getMillis() was called in any of the functions that are called inside of processMillis() the getNextEvent would skip events. To prevent this we detect recursive calls to processMillis() now and assume that no further millisecond has passed since the initial call.
due to the fact that we aborted every event that wasn't a key-repeat event, we never filled the event queue
mgerhardy
force-pushed
the
pr/eventrecorder
branch
from
July 8, 2021 09:01
f0559d7
to
7818358
Compare
Thanks! Merging. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The record file format is changed. But the version wasn't bumped because the old state wasn't working anyway.
This added the custom engine events from the key mapper to the serialization of the event recorder.
With this change I can record a play in twine.
During a playback there is currently no interaction possible as all event sources except the recorder are disabled. I don't consider this a problem atm - as I see the main benefit on running the recorded plays on the buildbot - but if someone needs to have this back, I would consider doing this in a future PR.
Follow up tasks:
https://www.youtube.com/watch?v=SOD97joxFds