[Playback] Fixes timing between recording and playback#291
Merged
ScribbleTAS merged 4 commits intoMinecraftTAS:develop-beta3from Apr 16, 2026
Merged
[Playback] Fixes timing between recording and playback#291ScribbleTAS merged 4 commits intoMinecraftTAS:develop-beta3from
ScribbleTAS merged 4 commits intoMinecraftTAS:develop-beta3from
Conversation
The 0th tick in the input list will now contain the state the keyboard was in when the recording was started - Fix issues when the VirtualPeripherals tried to copy from itself - Fix mixin.json being invalid - Add "tasmod.playback.trace" vm variable - Fix DesyncMonitor being 0 in the first tick
This commit makes it so the recording and playback will line up properly. Before this, the playback was delayed by one tick. To achieve this, the playbackNextTick and recordNextTick functions were split into different tick functions. Before, both methods were called in onClientTickPost, which is fired when the tick ends. This is correct for recordNextTick, however the playbackNextTick needs to be in a onClientTickPre method. - Added UnitTests for the PlaybackControllerClient - Fixed mistake where nextPlaybackKeyboard were used instead of currentPlaybackKeyboard - Replaced static TASmod Logger with local logger - Added onClientTickPre Event
Member
Author
|
Nvm need to fix something... The camera is also one tick delayed... |
Member
Author
|
Fixed now! |
PancakeTAS
approved these changes
Apr 16, 2026
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Up to now, playback was always delayed by one tick compared to the recording,
meaning if you recorded an input on tick 10 it would be pressed on tick 11.
By itself this was not really an issue, however it had a knock on affect when creating savestates, the desync-monitor or RNG,
where the playback had to be artificially delayed to sync everything up...
tasmod.playback.traceVM option for outputting a file with the current playback container every tick