Rocks'n'Diamonds

BryanFRitt wrote: ↑Thu Nov 17, 2022 10:49 pm EDIT3: There also seems to be an off by fraction of (a) move(s) at times during the ( []STOP, |>PLAY ) and/or quick restore, ?related to previous playbacks?
Start a level, quick save it right away. Try either a quick restore, and/or playback restore, will result in the player going to, or being at another square besides the starting square.

This is pretty much the simplest save / playback possible.
Start a level, don't do anything with the character, do a quick save, ...
Restore via quick restore --> player is moving to the right, paused, instead of stationary at the beginning of level
Restore via []|> play back restore --> player goes to the square to the right. (Basically same as above but not paused, so goes to next square.)

... this sounds like potentially a description of the problem I just mentioned, which leads to incorrect playback of tapes made with use of 'quick save'.

If you describe in excruciating detail how to reproduce it, maybe it will get fixed and maybe that'll fix the entire quick save system!

filbo wrote: ↑Wed Nov 30, 2022 9:23 am If you describe in excruciating detail how to reproduce it, maybe it will get fixed and maybe that'll fix the entire quick save system!

QUICK SAVED at starting position here. QUICK LOAD then restores here instead of starting position.
Game is paused. []|>Playback restore will end up here, movement from above isn't paused, so character goes to next square.
Tape timer isn't counting up. Game timer is still going. Game is not paused.

Is anybody able to reproduce this? I just tried, using the same level set and level:

- starting the game by pressing "start game"
- pressing "F1" to quick-save the game
- pressing "F2" to quick-load the game just saved
- this results in the same state as when quick-saving; that is, no move to the right at all, never

Did you do something different that the above to get that strange result? Or did you even do exactly the same, and get that strange result (which would be even more strange)?

Holger wrote: ↑Mon Dec 05, 2022 12:38 pm Did you do something different that the above to get that strange result?

It was doing this all the time, even after R'n'D restarts. now...?
I just tried setting 'START GAME IN PAUSE MODE' to 'OFF', and the problem went away. Set this back to 'ON', and the problem reappeared after restarting R'n'D, except character is going down. Tried messing with this again, and problem seems to be gone for a while even after R'n'D restart. Tried again... character is back to going to right.

The problem doesn't seem occur if QUICK SAVED when 'START GAME IN PAUSE MODE' is 'OFF'.

When 'START GAME IN PAUSE MODE' is 'ON', once the bug occurs*, it'll keep occurring, even after restarting R'n'D, until 'START GAME IN PAUSE MODE' gets turned 'OFF'. (Just turning this back to 'ON' doesn't cause the problem to start again.)

*Pressing a direction key against a wall while doing a QUICK SAVE(even though not using this QUICK SAVE) can cause the bug to start occurring. This at least affects the direction of travel when restoring new QUICK SAVEs done at start of level, when it shouldn't.

MAIN MENU > SETUP > GAME AND MENU > START GAME IN PAUSE MODE > OFF/ON

It maybe hard to spot the difference, but the character is moving down.

Thanks for the detailed description -- mentioning the setting "start game in pause mode" was the key factor that was missing!

I am able to reliably reproduce this bug now! It works as follows:

- set "start game in pause mode" to "on in the setup menu
- start a new game (which then starts in "pause" mode)
- move the player to the right (using the above example level)
- stop the game by pressing "Escape", going back to main menu
- start a new game (which then starts in "pause" mode)
- press "F1" to save the game state
- press "F2" to load the game state
- this results in the player starting to move right, which is wrong

To make things worse:

- this wrong initial player action indeed survives a restart of R'n'D (pressing "F2" then brings back the error)
- so this wrong action was not only part of the snapshot, but also part of the tape that was saved (as snapshots do not survive restarts of R'n'D, but are loaded from the saved tape then)

The bug (indirectly) seems to be caused by the third step of the steps listed above (the player moving right, adding these actions to the tape buffer). This action "player starts moving right" apparently gets saved to the game state (snapshot and tape), which should have no player action at all!

This bug might be a strong hint to the cause of the notorious "snapshot bug", as there is obviously something wrong with what was saved to the tape and snapshot!

I will further investigate this. Thanks a lot for your patience explaining to me how to reproduce this bug!

Just tried out rocksndiamonds-4.3.3.0.
This bug seems to be fixed now ! (well, at least in my brief testing around with this particular tape issue so far)

Note: There isn't this easy way to test out this bug right at level start any more on this version. It's blocked by inability to save at that point. "NO TAPE THAT COULD BE SAVED!". Which makes since to me as to why blocked, as the chance/cost of accidental tape override is greater than wanting to save that which is basically a blank tape.

If one wants to save a nearly blank tape, ||unpause the tape for at least a bit(at least one game frame?)then try to save. One can also delete the current tape file, if that's what they want.
Idea: Trying to a quick save a spot in the middle of a []|>playback gives "NO RECORDING THAT COULD BE SAVED!". Instead of this message, doing this could have the same effect as if one pressed ()record at this tape []|>playback spot then tried to do a quick save, or there could be some instructions that ()record has to be pressed to continue game playing from middle of a tape []|>playback.

If you find a tape that has this problem, a potential workaround seems to be when stationary making sure the tape full []|>playback and quick save/restore go to the same stationary point.

Do something like a []|> playback restore to point that you want to go to, if not stationary get that way, quick save it, then []|>playback restore to the end again. Is character stationary at the same point? If not, move a bit and get stationary again, then try quick save, then []|>playback restore to end again. Repeat again as needed.

If things have gone bad, you may need to do this at an earlier point in the []|>playback by pressing ()record during []|>playback at the point you want to try to go from before things went bad.

Seems to work in some cases with some bad tapes.

"NO TAPE THAT COULD BE SAVED!".

This message during tape playback quick saves, messes up save habits. I'm used to doing a quick save keyboard shortcut, then a 'Enter' dismissing message(without reading it) to do a save. Instead of 'Enter' dismissing that does a quick save, this 'Enter' dismissing doesn't save.

This message during tape playback quick saves, messes up save habits.

Not sure what to do about this -- "No tape that could be saved!" means that you cannot save the tape, because it is empty (which should only ever happen if you start the game in pause mode and press the "quick save" key).

How could the game save a tape if it is not there? (Before, saving an empty tape was indeed possible, but the saved tape was broken, as tape files with "empty tapes" are undefined and resulted in the buggy behaviour your have described earlier.)

Holger wrote: ↑Wed Dec 21, 2022 12:07 am

This message during tape playback quick saves, messes up save habits.

Not sure what to do about this -- "No tape that could be saved!" means that you cannot save the tape, because it is empty (which should only ever happen if you start the game in pause mode and press the "quick save" key).

How could the game save a tape if it is not there? (Before, saving an empty tape was indeed possible, but the saved tape was broken, as tape files with "empty tapes" are undefined and resulted in the buggy behaviour your have described earlier.)

Ops... I copied the wrong phrase. Should have copied "NO RECORDING THAT COULD BE SAVED!" message instead. This is the message that occurs if a quick save is attempted in the middle of a []|>playback without pressing ()record.
NOTE: One says 'TAPE'(The one at initial starting point) the other says 'RECORDING'(the one during []|>playback). Is there a technical difference what is meant between these two words, or is it just different to be different?

If I'm doing a []|>playback and want to set up a new go to point within that and press the quick save shortcut key without having pressed ()record 1st, that message(without an update in saves) will show up, instead of the usual confirmation of save overwrite message, "REPLACE OLD TAPE?". The two different message box save responses mess with the habit of not reading the message with the assumption that it's a confirmation of desire to "REPLACE OLD TAPE".

During []|>playback, the quick save shortcut could instead also prompt with the "REPLACE OLD TAPE?" message; If "YES" is chosen behave the same as it does when the ()record button had been pressed beforehand and do a quick save, If "NO" is chosen, continue with the []|>playback as if the dialog was never shown.

A lot of the time there's a tape mess up it seems that that tape []|>playback adds something that quick restore doesn't; tape []|>playback often results in a longer tape time than quick save/restore does. [at least old tapes still have this bug.]