-
Notifications
You must be signed in to change notification settings - Fork 0
IFID vs UUID
Explanation of the difference between an Alan 3 storyfile IFID and its UUID.
Table of Contents
The Alan compiler automically generates two distinct UUIDs (Universally Unique Identifiers) for the compiled adventure:
- An IFID string, stored in the associated "
.ifid" file. - An internal UUID hidden inside the "
.a3c" storyfile.
These two UUIDs serve two different purposes: the former is for cataloging the adventure, the latter is used by the Alan interpreter when restoring a saved game, to check that it was created from the eaxct same storyfile.
The IFID is associated with the IF work as a publication, and it's meant to remain the same in the course of time, regardless of any updates to the original adventure.
The internal UUID, on the other hand, is for internal safety checks, and must change at every compilation of the game.
As an author or player, you're only interestered in the IFID, and you're not even going to see the internal UUID unless you examine the storyfile headers with an hex editor.
An ".ifid" file is generated when you compile an Alan adventure for the first time. For example, let's say you have the "DarkCastle.alan" adventure, when you compile it you'll get the following files:
- "
DarkCastle.a3c" — the binary storyfile. - "
DarkCastle.ifid" — the adventure IFID.
The ".ifid" text file will contain a single line with a string that looks like this:
UUID://27f3b919-5345-7cdf-1215-28c8d2a64351//
This is the Universally Unique Identifier (UUID) associated to this adventure — also known as IFID (Interactive-Fiction Identifier) — which serves for cataloging purposes, e.g. on the IFDB portal. It's a bit like the ISBN numbering system used for books, but in this case it's used to identify works of Interactive Fiction.
The Alan compiler will not generate a new IFID if there's already an ".ifid" file for that adventure — i.e. if in the folder of the source adventure there's already a same-named ".ifid" file from previous compilations, the Alan compiler will reuse it. This is because you don't want the unique IFID to change in the course of time, even if you update the code of the original adventure, for it's still the same adventure and should be catalogued only once.
For these reasons, you should always keep the original ".ifid" file generated by the compiler, for that unique ID is not stored elsewhere (it's not inside the ".a3c" storyfile).
NOTE — After examining "
.a3c" storyfiles with an hex-editor, it looks like Alan actually stores the IFID string in the storyfile as well. I'm not sure wether this prevents generating a new IFID if the ".ifid" file is lost/deleted or not. Also, this feature might have been introduced at some point, with earlier versions of Alan 3 not including the IFID in the storyfile. I need to check better this point.
This can also be referred to as the "external IFID/UUID" for it's stored externally from the storyfile, in the ".ifid" text file associated with each adventure.
Every ".a3c" storyfile contains an internal UUID which is generated afresh with each compilation. Unlike the IFID, this internal UUID needs to be different for each compiled adventure, for the Alan interpreter uses this UUID to associate each saved-game file to a specific storyfile. Even the slightest change to the adventure code would make a saved game unusable — e.g. if you've saved your game session with "DarkCastle.a3c" v1.0, then you can't load the saved game with v1.1 of the same adventure.
This UUID is stored internally in a storyfile and all the game-saves created for that storyfile. It's not intended for cataloging nor to be acknowleged by end-users in any way, it's only used by the Alan interpreter for interal checks.
Alan IF official links: Alan Website | Alan Wiki | Source code on GitHub