Rocks'n'Diamonds

BryanFRitt wrote: ↑Thu Nov 17, 2022 10:49 pm EDIT5: ( []Stop, |>Play ) from an older version tape doesn't allow continuing playback from it. Happens with Emerald Mine Club > Bug Mine 2, and probably others. [is this good thing on purpose due to some other error that would occur?]

Instead of "from an older version tape doesn't allow continuing playback from it.", I probably should have said "can't get the character to move, etc...", I can still ||pause/un-pause at least.
Happens with saves from my Bug Mine 3 too.
If I go back and manually play these from a fresh start, I can restore any new saves fine, any play from there.

Not sure of the edit history here -- just looking at what is written right here, I am wondering if this is another case where you needed to explicitly 'cut the tape' by hitting Record.

(Note: I don't use the 'quick save' feature at all due to past problems where tapes created by it would play back incorrectly. Holger has tried various times to fix that, but I do not yet have confidence to use it and I'm not sure if he considers it fully fixed.)

What do you mean by "doesn't allow continuing playback" -- do the following steps work?:

- start the tape by pressing the "play" button
- press the "pause" button after some time of replaying the tape
- press the "record" button and continue recording (by moving the player)

Does this work? Or did you mean something different?

(Note: I don't use the 'quick save' feature at all due to past problems where tapes created by it would play back incorrectly. Holger has tried various times to fix that, but I do not yet have confidence to use it and I'm not sure if he considers it fully fixed.)

The bug/problem you mentioned is neither found nor fixed yet, so I still consider using "quick save" and "quick load" experimental, unfortunately. That's also why the corresponding panel buttons are disabled by default.

Weird...
Earlier I backed up some of the tapes that R'n'D wouldn't let me continue from.
Then redid them from scratch earlier.
Backed up these good tapes.
Restored the bad tapes that were giving me problems and preventing me from continuing them.
Now it's letting me continue from them like normal, and not having the problem.
Not sure what's changed. Could I have messed up in backing up the bad tapes? Permissions*? Something else? Maybe these tapes were bad in another way?

---

*Note: Don't think many people would run into permissions issue, and I doubt this was the problem. The following is mainly for curiosity.

What would happen if these were read only tapes... ?

The bad tapes restored...
~/.rocksndiamonds/tapes/emc_bug_mine_3
ls
025.tape 026.tape 027.tape 031.tape 045.tape 050.tape 052.tape 054.tape 055.tape 056.tape 057.tape 058.tape 061.tape 063.tape 066.tape 069.tape
With R'n'D closed, I marked these tapes as read only.
Restarted R'n'D.
Tried to restore one of these read only tapes.
Got "NO TAPE FOR THIS LEVEL!"
It'll let me play from start.
Tried saving.
It prompted "REPLACE OLD TAPE?"
I chose "YES".
It overwrote the read only file!
New file permissions are -rw-r--r--
ops... left the 'w' that was there. (I guess that's why it could write but couldn't read)
Tried again like before, but this time from permissions all "----------"
Got "NO TAPE FOR THIS LEVEL!
Tried saving from a new play-through of level.
It prompted "REPLACE OLD TAPE?"
Nothing in the GUI that says anything bad happened. <-- perhaps there should be some sort of GUI message here like there is in the terminal.
In terminal there's a "[WARN] cannot save level recording file"... message.
These did not show the same effect that the bug report was about.

Copying back the good tapes...

On *ix filesystems, it is typical that you can overwrite a non-writable file, but can't write changes to the existing file. That is because you own the directory in which the file appears. Fully overwriting / rewriting a file is usually done as a sequence of operations: remove the old file (which works because it's a directory operation and you own the directory); create and write the new (which works fine because it's just a new file with nothing obstructing it). The new file gets whatever permissions specified by your umask.