The obvious solution is to use some hash calculated from the game file contents instead. In fact, Spatterlight already does that when naming the individual folders for autosave files, so it is really only a matter of converting the library to the same system.
Keep in mind old zcode files sometimes contain padding, changing the hash.
Sure, but it isnāt a huge deal if the same game gets listed twice because the game files differ. More of a deal are all those 175 kilobyte Commodore disk images which are empty except for a couple of kilobytes at the very end, so unless you base the hash on the entire file, they will all get the same one.
In that case, a file hash is definitely the way to go.
Iām glad that we could hash this out.
Ohmy.
You are telling me that AA andā¦ AA (i need to get better at naming games if I want to use acronyms) share the same IFID?
It never occurred to me. And yes, what Wade implied is probably trueā¦
The greatest difficulty now would be to recompile very complex games made 13/14 years ago. But I guess itās a must.
Ohmy.
Perhaps I shouldnāt have joked about rising from oneās buttocks. I forgot that you might have to recompile the game, which could be a challenge. But I guess itās the only way?
-Wade
If no one comes up with a better solutionā¦ But Iām very afraid I would break the games if something is still compiled but wouldnāt work as intended. Itās a massive endeavor.
Is there a way to, like, break the compiled game and change it manually? Asking the communityā¦
Just grab a new IFID and a hex editor:
(Edit: Actually itās only that simple if step one below finds the UUID, otherwise the IFID is built from the release, serial, and a checksum. I imagine it is there though, because it is incredibly unlikely the two games would have the same checksum.)
From The Treaty of Babel
2.2.3.2. The IFID for a legacy Glulx story file
Inform 7-produced Glulx files will be branded with an IFID in the same manner as Z-code files.
Older Glulx files come in two flavours: those produced by the biplatform inform compiler, and those produced by other tools.
Inform-produced glulx files provide similar information to Z-code: a release number, serial number, and checksum, which can be used to identify them.
Glulx files produced by other tools have only a checksum to identify them. In this case, the IFID is supplemented by the stated size of the initial memory map (which is equal to the size of the game file if it has not been padded).
The size of the initial memory map is stored in a Glulx file as a 4-byte value beginning at byte address 12.
The checksum is stored in as a 4 byte integer at byte address 32.
An inform-produced Glulx file can be identified by the ASCII sequence āInfoā at byte address 36.
The release number is stored as a 2 byte integer at address 52.
The serial number is 6 ASCII characters beginning at address 54, traditionally the compilation date.
The algorithm for calculating the IFID of a Glulx file is as follows:
- Scan byte-accessible memory for the pattern of ASCII characters UUID://ā¦//, where āā¦ā is a sequence of letters, numbers and hyphens. If this is found, thatās the IFID. Otherwise continue.
- The IFID begins with āGLULX-ā.
- For inform-generated files, skip to step 5.
- For non-inform-generated files, add the size of the initial memory map as eight hexadecimal digits and skip to step 7.
- Add the release number, in decimal, followed by a hyphen.
- Add the serial code, converting any non-alphanumeric characters to hyphens.
- Add a hyphen, then add the checksum in hexadecimal.