Rocks'n'Diamonds

I am just about to debug this issue (that is, broken tapes resulting from using quick save and load while playing a level) again (after having tried again and again and again during the last about 10 or 20 years).

The problem is, providing me with such broken tapes is not likely to help, as they only contain the "wrong moves" (stored in the tape), but not the "right moves" used while solving the level.

What might help could be the following: I am currently looking for scenarios that can be used to more or less reliably reproduce this problem. That is: How could an easy test level look like, and how could a simple way of solving it look like that likely result in a broken tape?

If a problem can be reproduced, it can be solved in most cases. Unfortunately, this problem seems to be hard to be reproduced in a repeatable way.

If any such (hopefully short and simple) "strategy", used on a (hopefully small and simple) test level would be known, I could add lots of debugging output to R'n'D to see what happens when playing (including quick loading and quick saving) and when re-playing the resulting (broken) tape.

If anybody should have any clue here, that would be more than helpful!

Until then, I am trying again to find a simple level and a way to play it, which might result in broken tapes as often as possible...

The attachment at the 1st post of this thread hints that there's bug situation at a specific point during playback which screws up the rest of playback, and not all the rest of the playback being messed up.

BryanFRitt wrote: ↑Thu Sep 12, 2024 8:35 pm 100-sp_level_collection_95-MessedUp-ButMakesItToEndExceptForEmeralds.tape (5.96 KiB)
download/file.php?id=1519

The specific points of mess up seem to be (usually?) around points of quick loading tapes, or continuing a tape from the middle of a tape playback. With the tape playback []|> ending later than it should.

I'm also curious if this(these) bug(s) could this being caused by doing things too fast. Something like trying to reload quick tape, before a previous reload quick tape gets finished reloading.

Thanks for mentioning this again -- I will have another look at this specific level and tape again!

The problem should really only occur when "quick load" or "quick save" (that is, engine snapshots) are involved. Continuing a tape from the middle of an existing tape (using only the tape buttons) should in fact never result in broken tapes (at least I did not encounter such a case by myself so far).

This bug should also not be caused by doing things too fast, as "quick load" or "quick save" (like any other functions that can be triggered by pressing a button or key) are always finished before a potential next action (that might already be in the event queue) gets executed.

Thanks again for your feedback!

Holger wrote: ↑Thu Jul 03, 2025 2:33 pm I will have another look at this specific level and tape again!

That one's a rarity. It clearly messes up(around 5:01 mark), but then goes back to playing normal (around 5:51 mark).

Most of the time when it messes up, once it messes up, it's messed up from that point on. Might be like trying to follow a map at getting to a point where you mess up by not noticing that you moved differently than intended or slipped, and therefore think you're at one spot/time that your not really at. Once that messed up, all future moves are likely off, even if they would have been right if you had you actually been at the point you thought you were at at that time.

Graphing analogy: graphing left to right y = x^2-3, slip at x=0 from (0,-3) to (0,0) and still think your at (0,-3) then continuing. Instead of ending up with y = x^2-3 throughout the whole graph y = x^2-3 goes part only goes from -∞ to <= 0 and the rest from > 0 to +∞ is y = x^2 instead. Without the slip it would have been y = x^2-3 throughout the whole graph.
Purple curve after 0 represents the data after slip. It's 3 above the line below it.

Yes, this is a rare case. According to your navigation example, if you -- just by chance -- reached a point after getting lost where your remaining navigation steps are right again, you will reach the destination despite getting lost in between. But this will only happen in very rare cases.

So far, even when testing with this specific level, I wasn't able even a single time to produce a broken tape.

So, any hints on specific steps on a specific level (probably with specific points during playing where to save or load snapshots) that have a high probability to produce a broken tape situation (therefore being able to reproduce this bug with a relatively high probability) would be highly appreciated!

Until then, I will continue testing with different levels if I will ever be able to produce a broken tape under "laboratory conditions" again... :-/

Holger wrote: ↑Sat Jul 05, 2025 9:54 am So, any hints on specific steps on a specific level (probably with specific points during playing where to save or load snapshots) that have a high probability to produce a broken tape situation (therefore being able to reproduce this bug with a relatively high probability) would be highly appreciated!

It seems like it more likely happen on spots where I'm doing a bunch of quick-save quick-restore in a row, maybe involving dying. I might be accidentally pressing some other key(s) while doing this? At one point I wondering it had something to do with pushing attempts. (didn't figure out if true or not) Seemed to happen more often with the gdash levels, and less with levels that seemed newer?*
The 1st one of these feels most true of these: "It seems like it more likely happen on spots where I'm doing a bunch of quick-save quick-restore". None of these seem to guarantee to recreate bug(s) easily, or 100%.

* Could you use statistics on submitted level play throughs that failed vs total submitted level play throughs? Like levels that have the highest fraction of submitted levels level play throughs that failed to total submitted level play throughs are the levels where some tape bug(s) is(are) most likely happen with standard game play.

BryanFRitt wrote: ↑Sat Jul 05, 2025 11:22 am

Holger wrote: ↑Sat Jul 05, 2025 9:54 am So, any hints on specific steps on a specific level (probably with specific points during playing where to save or load snapshots) that have a high probability to produce a broken tape situation (therefore being able to reproduce this bug with a relatively high probability) would be highly appreciated!

It seems like it more likely happen on spots where I'm doing a bunch of quick-save quick-restore in a row, maybe involving dying. I might be accidentally pressing some other key(s) while doing this?

I often pause a game before doing a quick-save, and at other times for time to think. [pause is currently set to space bar]

BryanFRitt wrote: ↑Sun Jul 13, 2025 6:45 am Looking at the 'HELP' for the one in the subfolder I see "ESE VERSION 1.2 UPDATED AUGUST 2006." and "FOR ROCKS & DIAMONDS VERSION 3.2.0", for the one outside I see "ESE VERSION 1.1" and "FOR ROCKS & DIAMONDS VERSION 3.0.8". I'll call these 1.2 version and 1.1 version for now.

I noticed that for Earth Shaker Explosions "022: SALTWATER DESALINATION" in playing back the tape on the server with score of 0398 and time of 02:12, it's a victory on the old 1.1 version, but on the 1.2 version it's not a victory, and it looks like one of these tape issues may be happening around the 01:52 mark. (can't tell for sure)

Don't know if it'll help find the tape issue problem, but here's a tape in team mode that's messed up.
Seems to mess up around 1:24

Save this as something like (adjust for your setup)
~/.rocksndiamonds/tapes/emc_per_one_mine_1/038.tape
Play with
EMERALD MINE CLUB > PER ONE MINE 1 > 038