F1/F2 "quick save"/"quick load" often adds phantom tape data

Found a bug in R'n'D? Report it here!

Moderators: Zomis, Flumminator

Post Reply
Posts: 31
Joined: Thu Mar 27, 2008 4:45 am

F1/F2 "quick save"/"quick load" often adds phantom tape data

Post by Anonycat » Tue Oct 15, 2013 3:11 pm

Loading tapes with F2 has always been a problem for me to the point where I never actually use it, preferring instead to fast-forward through several minutes of tape at each retry, since that actually works consistently. Allowing partial tapes to play through to completion and recording from where they left off is excessively prone to desyncs. Attached is an example you can test with, taken from one of the more notable chokepoints I ran into while optimizing BD2K3 level 39. Rockford has just moved 64 frames right, and the route I eventually settled on was to move an additional 61 frames right, 8 up, 8 right, stand still for 1 frame, and 61 down before passing into the next room. Adding on that sequence after playing the tape to 1:41.36 will work and save without a hitch, but if I load that tape with F2, input the sequence, and save the tape again, it ends up inserting a 04 0C (12 frames up) in between the two chunks of rightward movement in the tape file, for no good reason. Adding to the mystery is that
some sequences (even a few that start with Right) do save properly after a load, but with no way to tell if it's going to work beforehand, I'm just staying away from the feature until I know it's no longer adding bogus input to the tape.

Unlike some other bugs that I've been able to patch away on my local installation, I haven't been able to track down what's causing this, and since a suitable workaround exists (using the normal tape control buttons instead of F1/F2) I'm probably less inclined to look.
(452 Bytes) Downloaded 338 times

User avatar
Site Admin
Posts: 2866
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany

Re: F1/F2 "quick save"/"quick load" often adds phantom tape

Post by Holger » Wed Nov 26, 2014 8:29 pm

First of all, sorry for the late reply to this topic. I have tried very hard to reproduce this problem and to track down this well-known bug, but I had no success so far. Regarding this post, I have also done numerous tests using the supplied test tape file, but unfortunately wasn't successful in my attempts to reproduce the problem either. (The only way to "reproduce" this bug (to confirm that there really is something going wrong with F1/F2) was to repeatedly record tapes using a lot of F1/F2 saving/loading and then replay the resulting tapes -- this showed that some of the tapes were broken when replaying. Unfortunately, this did not help me to debug the cause of this bug.)

In the past, I had the suspicion that I simply forgot to save or restore some bits of the game engine state, but repeated checks did not reveal such a problem so far, so it must be some more complex that that. The only fact seems to be that at some point when using F1/F2 the random number generator gets mixed up somehow, resulting in different random numbers when recording and when playing, resulting in broken tape replay.

If anybody has any idea what might be going on here, or has an idea how to debug this, or how to reproduce this bug, I would be more than thankful. :-/

Posts: 274
Joined: Fri Jun 20, 2014 10:06 am

Re: F1/F2 "quick save"/"quick load" often adds phantom tape

Post by filbo » Thu Nov 27, 2014 8:32 am

When I've had these problems it has often felt as if there was an off-by-one error somewhere in the time state accounting. I haven't studied how it works in the code, but in play it feels as if there are 6 (I think? haven't counted recently) "ticks" of the game clock per move. When doing a lot of F1/F2 it felt like sometimes the saved state would reflect a moment in game time, while the saved clock reflected 1 tick, 1/6 of a player move, earlier or later.

That was just an impression and it has been 5+ years since I tried to play an F1/F2 style. Since then I always restart a death from the beginning of time and fast forward to where I screwed up. A full replay from time zero always works (modulo other bugs...)

Post Reply