An interim solution (to find out how many tapes are affected) would be to auto-play all your tapes automatically over night, and see which tapes succeed, and which (and how many) are broken when played with the latest version. (See the "autoplay LEVELDIR [NR ...]" command line command for this.)
I started playing with this and have a bunch of observations:
- It displays the start(?) of each level as it prepares to solve it
- This display is done in the artwork set of whatever you were playing last: the "rnd_tutorial_aaron_davidson" levels look quite bizarre in the artwork of "jue_puzznic"!
- Because of the display, I assume (but did not test) that I will not be able to do "autoplay" from an ssh. I'm sitting here on "the slow computer" (1GHz Pentium III w/384MiB RAM!) while my oldest daughter hogs "the fast computer" (2.1GHz Core i3 w/8GiB RAM) playing Minecraft... (Also, of course, I cannot test any 64-bit issues on this PIII system!)
- The doc and command-line help do not appear to clarify what is meant by "LEVELDIR". I tried just "-e autoplay rnd_tutorial_aaron_davidson" and that worked; now I'm trying to distinguish, since both I and the game hierarchy have full sets of 26 tapes for this level, whether it is stepping through /usr/share/games/rocksndiamonds/levels/Tutorials/rnd_tutorial_aaron_davidson/tapes/* or /home/filbo/.rocksndiamonds/tapes/rnd_tutorial_aaron_davidson/*
- Each startup takes a fairly long time on this slow machine, with all levelsets and artworks installed
- Each exit reminds me of a bug I've been experiencing, where the process hangs stuck in what `strace` shows as:
Code: Select all
$ strace -p5501
Process 5501 attached - interrupt to quit
futex(0xb2f03bd8, FUTEX_WAIT, 5504, NULL
Mostly this dies when I kill it (-15); sometimes I have to `kill -9`; exactly twice I have seen:
Code: Select all
Assertion 'pthread_mutex_destroy(&m->mutex) == 0' failed at pulsecore/mutex-posix.c:83, function pa_mutex_free(). Aborting.
on killing it -- so it looks like some misinteraction with pulseaudio libraries.
- The output "Level 004: playing tape ... solved." looks like it's intended to be printed in two stages, but in fact the entire line appears at the moment that level 4 is solved (so for the entire time that 4 is running, the last output on the terminal is "Level 003: playing tape ... solved.\n")
- Ah, it has just started autoplaying level 7 of "rnd_krystian_abramowicz" while I only have tapes for 001..006, so that proves it's playing the :ist tapes
- I then tested with a levelset for which I have tapes, but /usr/share/games/... does not; it didn't find my tapes. So that proves that it's
only playing the :ist tapes.
- How, other than clumsy tricks with moving directories around the filesystem, can I have it play
my tapes?
- Thought towards a fix: it should be possible to implement the wrong not-64-fixed random init code as a separate step. Tape files give the version number as e.g. 03 03 01 02, but not the 32/64-bitness of the engine. So (1) add that to the save format; (2) for tapes made before the 64-bit fix, let the user somehow control whether you use the correct or broken-64-bit random seed initialization procedure. Obviously it would be nice to automatically determine this, but I don't see how. (If the time stamp is old enough, dating back to before AMD64 CPUs shipped, you could assume a 32-bit save -- I don't know if that's a big help...)
- Ah, in particular, when doing "autoplay", if a tape fails then you could try the other random initialization; if it then succeeds, you could stamp the file with the 32- or 64-bit tag. Or stamp it with what the random number seed
should have been, using the correct init algorithm. But "autoplay" should not edit files -- just have it display:
Level 004: playing tape ... solved.
Level 005: playing tape ... failed. Retrying with alternate random number seed algorithm:
Level 005: playing tape ... solved. Level 005 tape needs its random number seed corrected.
and add an "autofix" which actually applies such changes.
- Please add "rocksndiamonds --version" flag! It should print, as text, the same as you see in Info Screen -> Version Info. Please also add CPU info to that screen.
- -e "dump level foo.level" and -e "dump tape foo.tape" should print the date stamp from the file
- the tokens "tape" and "level" aren't (always) necessary since many of the formats you read have IFF chunks identifying what they are, or probably other similar things. Plus in many cases they're named "whatever.tape" or "whatever.level" (detect by extension) or "/blah/blah/levels/blah/12" (detect by last subdirectory named "levels" or "tapes" in path).
- WOULD IT HELP for me to go back and post individual bug topics for each of the above points which call out a specific bug? I am inclined to do this, but I want to do whatever is least annoying to you: (A) leave it like this, with 5-10 minor bug reports munged into a single thread reply or (B) post 5-10 separate threads about them...
002.tape
-- but the help could be better. e.g.: