Rocks'n'Diamonds

The levelsets:

(A) emc_freak_mine_super_pro
(B) emc_super_freak_mine_prof

are identical. Well, in fact, not precisely identical. Levels 1 22 25 26 32 49 52 69 74 76 79 all have slight edits. Two of those (32 & 52) are documented in an updated titlemessage_1.txt; I feel safe in assuming the others are similar small tweaks to fix broken levels.

Also, B's levelset name is the same as it describes itself ('SUPERFREAKMINE PROF' in the title msg), while A's is not.

So B is a fixed edition of A. Further, mildly supporting this interpretation, the changed levels' files in A are dated 1990-12-23 or 1991-10-03, while in B they are 1995-05-03 through 1996-06-22 (except level 79 is 1980-01-02, probably modified while a PC was booted into MS-DOS with dead CMOS battery...)

So I think A should be removed from the collection.

=====

While examining this I noted that the graphics/*.png in 3.1.0 have different date stamps than *.pcx in 2.1.1. I curate date stamps and in a case like this (translating file to more modern format, intending to exactly preserve original intent) -- I would stamp the new file with the original timestamp. I also noted that the *.png in 3.0.0 had identical contents to 3.1.0, but earlier timestamps, showing that you either ran the conversion twice, or automatically run it for each build of the collection. Seeding extra timestamps for identical files is not good :)

The timestamps for *.conf also differ, but in this case there are actual material changes. I would probably stamp comments into the modified versions, stating the prior timestamp & purpose of changes, but that's just me being overly fussy :)

So I think A should be removed from the collection.

I totally agree -- thank you for the detailed analysis of the differences of the two disks. (BTW, www.emeraldmines.net only knows the first one, but the second one should indeed be used!)

Just removed "emc_freak_mine_super_pro" for the next update of the EMC collection!

While examining this I noted that the graphics/*.png in 3.1.0 have different date stamps than *.pcx in 2.1.1.

Yes, that's right, because I converted them from PCX to PNG for the 3.x.x release. And I really think that it should be that way. Especially for such retro stuff made usable for current systems -- what exactly is the "original timestamp"? I would find it strange to have the original Amiga ILBM files from the late 80's converted to a modern file format like PNG, but then force an ancient time stamp upon to these files (as there was no PNG file format in that time). When seen that way, also the PCX format was just an intermediate file format, so from your point of view, that file date was already wrong, too. And there might be some more conversion done to these files, like changed image resolution, or images being extracted from the game binaries (like it is the case with many EMC disks), so I would say a recent file time stamp just reflects this.

And don't get me wrong: I also do massively dislike timestamps forcefully set to an arbitrary recent date without any purpose -- something I really, really hate about Git, btw., as it makes it practically useless for me to store anything other than source code files (but text documents, for example, for which I definitely want to know if I last changed it yesterday or 30 years ago).

But if you look closer to the PNG files of 3.0.0 and 3.1.0, those files with a different timestamp indeed have different content! But it is not too obvious in some cases, like the changed tape recorder font color and some other minor changes.

I also noted that the *.png in 3.0.0 had identical contents to 3.1.0, but earlier timestamps, showing that you either ran the conversion twice, or automatically run it for each build of the collection.

The whole collection is completely created automatically from scratch every time, but the timestamps of unchanged files should always be the same (except for those files that are automatically created each time, like title screen images and title messages, game content converted from game binaries or ILBM files and some config files created from template files, but not the additional "Rocks*.png" images, for example, unless they were manually changed between versions).

The timestamps for *.conf also differ, but in this case there are actual material changes.

Not always; sometimes this is caused by config files being created from template files, which did not change, but the package only contains the target files.

I would probably stamp comments into the modified versions, stating the prior timestamp & purpose of changes, but that's just me being overly fussy

No, you are right here; what I really should do is putting all that change history into a versioning system like Git, as I sometimes wonder by myself what the heck I changed some years ago, and then have to manually find out using "diff" and so on. The problem here is just that the amount of data is just too much to just stuff it all into one Git repo, so I would have to check what to include and what to exclude. The automated process really works very nice, but the data from different sources for different purposes is a bit unsorted to put it into a repo without a little cleanup first...

> something I really, really hate about Git, btw., as it makes it practically useless for me to store anything other than source code files

Hmmm, well, I think its idea is that all changes you ever do (or ever have done) were done / will be done via `git`. So `git log whatever.txt` should tell you all about what and when.

This doesn't seem entirely wrong to me. If you're committing an old file with nothing but remembered history, well, in that first commit msg you could enter what you remember, as well as documenting the last pre-git file timestamp.

Not fussed about whatever happens with the EMC file dates; I just wanted to make sure you were aware & handling with intentionality.

BTW, it occurs to me that people's existing tapes for one name will become disassociated, since there's no way for them (or the game) to know that that levelset internal name has been migrated to a different one. Plus, I didn't look into the details of those dozen or so changed levels. Don't know if all were fixes to unplayable levels (who ships a dozen unsolvable levels?). If they were previously playable, the changes might make the old tapes fail. So now I am having second thoughts about the change that I caused to happen! :) ;}

Hmmm, well, I think its idea is that all changes you ever do (or ever have done) were done / will be done via `git`. So `git log whatever.txt` should tell you all about what and when.

This doesn't seem entirely wrong to me.

No, it's great, and I really love to use Git for R'n'D now (after many years of fumbling around with tar files ), and it's perfect to track down the history of files (which timestamps cannot do, of course).

I just wish there would be a command line option for Git to optionally also commit/checkout a file's timestamp.

Nearly every day I do a "ls -rtl" in some directory to quickly see the last few modified files of a bunch of files. I have no idea how to do this quickly and easily with Git (probably there is a way, with some pipes involved).

If you're committing an old file with nothing but remembered history, well, in that first commit msg you could enter what you remember, as well as documenting the last pre-git file timestamp.

Yes, this is probably a workaround that works in some cases...

Not fussed about whatever happens with the EMC file dates; I just wanted to make sure you were aware & handling with intentionality.

At least I try to.

BTW, it occurs to me that people's existing tapes for one name will become disassociated, since there's no way for them (or the game) to know that that levelset internal name has been migrated to a different one. Plus, I didn't look into the details of those dozen or so changed levels. Don't know if all were fixes to unplayable levels (who ships a dozen unsolvable levels?). If they were previously playable, the changes might make the old tapes fail. So now I am having second thoughts about the change that I caused to happen! ;}

Not entirely sure that I understood what you mean here... Do you mean such changes of level files like in the case mentioned above (two old EMC disks where the one is a fixed version of the other)? As far as I can see, there should be no tapes affected ever in such cases, as the affected levels would be unsolvable in the first place...

For simplicity, imagine for a moment that the two levelsets were entirely identical other than name / location in levelset hierarchy.

So maybe I've played and recorded tapes of all levels under name 'A'. Then one day you notice the duplication and delete 'A', leaving only 'B'.

So now my tapes under 'A' are orphaned. I don't know, and I presume there's no way the game is going to know, that those tapes are also solutions to levelset 'B' and should be mapped in.

Or suppose I had complete sets of solutions to both levelsets (maybe I didn't notice, or thought 'what the heck, I'll play those again', or whatever). Even if the game were aware of the mapping, how could it curate which of two tapes to show?

Now, in reality there are some ~dozen levels with changes. The provided doc mentions why 2 of them were changed. We only speculate that the other ~10 were changed because they weren't solvable. Maybe the person doing the 'fixing' just didn't like their aesthetics, or thought they were too hard, or too easy for that matter. Or maybe they thought the original level was unsolvable, but actually they just weren't tricky enough. Or even -- they might have been unsolvable due to then-existing engine bugs (or not-quite-bug differences), but were solvable on some then-future release of RnD, and have been so solved by me.

In any of those cases, I might have tapes which solve the original levelset 'A' versions of those levels; and which no longer work on the modified 'B' versions. Which is sort of uncool.

====

On git and old file history: there are tools to import into git from various others like bz, hg, cvs, p4, etc. (probably 20 different scm systems if you look hard enough...) Any of those would preserve file modification history including time stamps; but of course you are not trying to import from a different scm. But the general concept of 'yo, I have a tree full of files here and I'd like to record them as having been individually committed, once, with their current contents, at precisely the time seen in their current filesystem timestamps' should be easy enough. If you had old backups, tarballs, whatever, containing snapshots of history, you could run multiple such commit storms, building up a history-ish of the files.

Without looking, I don't know of any project to do that, but I bet there are a couple dozen of them on github today...

Some quick googling leads to ... there are 14 zillion pages about 'import from blahblah scm to git', but 'import from a bunch of old files or tarballs or whatever' is kind of thin on the ground. Perhaps because it is thought to be trivial.

BUT, one good hit was: https://stackoverflow.com/questions/2759858 -- which points to a couple of examples provided in or near git itself, for importing from a series of tarballs or .zips. I didn't check whether the referenced examples still exist 10y later, but surely for something whose whole purpose is Preserving The History Of Things, they should exist somewhere :)