You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Commit c769194 separated the monotonic and realtime clocks and made it so that the realtime clock can be set independently of the monotonic clock by editing the "System time" fields. This commit also made the monotonic clock always start at 0.
However, this lead to a regression in that the ability to change the start time of the monotonic clock was removed. This is relied on heavily in Gamemaker games such as Undertale, where the function randomize() generates an RNG state based on the current value of the monotonic clock. This causes desyncs, as the RNG state doesn't match the previously chosen state that was based on the system time. This will also cause time loss in future TASes of these games, as the ability to manipulate RNG without losing time by changing the monotonic clock start time is removed. Thus, RNG manipulation would need to be done in-game, often in ways that lose time.
My suggested solution would be to have an additional field for designating the start time of the monotonic clock. This would allow manipulating RNG by changing the monotonic clock while also not affecting the ability to change the system time in the middle of the TAS, as requested in #474.
The text was updated successfully, but these errors were encountered:
Commit 6a0621a solved this issue. I was able to change the starting value of the monotonic clock to match the starting time from an Undertale TAS and it all synced up.
Commit c769194 separated the monotonic and realtime clocks and made it so that the realtime clock can be set independently of the monotonic clock by editing the "System time" fields. This commit also made the monotonic clock always start at 0.
However, this lead to a regression in that the ability to change the start time of the monotonic clock was removed. This is relied on heavily in Gamemaker games such as Undertale, where the function
randomize()
generates an RNG state based on the current value of the monotonic clock. This causes desyncs, as the RNG state doesn't match the previously chosen state that was based on the system time. This will also cause time loss in future TASes of these games, as the ability to manipulate RNG without losing time by changing the monotonic clock start time is removed. Thus, RNG manipulation would need to be done in-game, often in ways that lose time.My suggested solution would be to have an additional field for designating the start time of the monotonic clock. This would allow manipulating RNG by changing the monotonic clock while also not affecting the ability to change the system time in the middle of the TAS, as requested in #474.
The text was updated successfully, but these errors were encountered: