Manually setting the IFID

There is an annoying bug with Inform 7 (9.3, MacOS): I have a new cover image, but the IDE refuses to include this in the gblorb file when I publish. The old cover remains there.

Now I have created a new project and copied everything (source code, images, etc.) into it, but then of course I get a new IFID.

  • Can I set the IFID manually? (So that I can keep the old IFID.)
  • Or should I just continue with the new IFID?

In this context: Should a new release always have a new IFID? Or better not?

The IFID is stored in a file uuid.txt in the Project.inform folder. Copy that from the old project to the new one and you’ll have the same IFID as before.

2 Likes

The intended semantics of the IFID are clear that new releases (that are for the same system) ought to keep the same IFID. Quoting the Treaty of Babel (my emphasis):

As with published books, where an ISBN remains the same even if the book is reprinted with corrections, the IFID should be associated with a project, not a specific story file compiled from it. A re-release with bug fixes should have the same IFID.

3 Likes

Note that the uuid.txt must not end with a newline. It’s easy for one to sneak in if you’re copying a value over by hand in a text editor. But then you wind up with a bad UUID in the compiled game file. (Type VERSION, you’ll see there’s a newline before the last //. This messes up IFID tools.)

I oughta file a bug about that.

(If you copy the entire uuid.txt file, this isn’t a problem.)

5 Likes

Which I think means it’s technically not a valid text file according to POSIX—the sort of pedantry that usually doesn’t matter but helps when you’re arguing that something is a bug!

Thanks for the clarification!

(I mean, I can see one might be nervous about manually fiddling with this under-the-bonnet looking thing; I can imagine other, non-IF contexts where changing/duplicating this sort of ID would be a bad idea, confusing tools or leaving your project in an inconsistent state. I am assuming that, given the original purpose of the IFID, any IF authoring tooling like Inform 7 or Twine isn’t going to have a problem with it.)

1 Like

I just changed the IFID in the uuid.txt and now the old cover is again shown as icon for the gblorb file. I have no idea where this is coming from. Is the Inform IDE getting the image from a database on the internet?

The IDE can’t do anything as radical as that.

So, you’ve put everything in a new project, including the new UUID, and you say you’re getting the old cover image in the build? It must either be in a cache that’s not being flushed, or there are problems with the image names or image file types, or a mixture of both. The file names/types has been an ongoing source of annoyances for people with the way Inform handles cover images.

Maybe you have a copy of the old image hanging around sneakily, or the new image is somehow being judged to be incompatible (by file/image type, or by name) and so the IDE refers back to the cached version, or grabs onto the old image which is named correctly, or just the file it used before – something along these lines.

My advice would be to rename both files themselves. Then point your internal source reference to the newly renamed cover image file. Give your current image a new file name you’ve not yet used in this process. Do the same for the old cover image – give it a name never used before.

Next step is probably unnecessary but let’s cross our T’s: type a few words in your source file then delete them. This makes sure Inform is going to compile everything from scratch. (This would probably happen anyway for a Build, but as I say, crossing our T’s).

EDIT - If this still doesn’t work, I would take all cover images out of the figures folder, duplicate them, throw away the original copies, give the duplicates names never used before, put the wanted duplicate back in the figures folder, THEN build. At this point, macos cannot grab the old files; they no longer exist.

-Wade

1 Like

Hard to prove from all the way over here, but it’s possible that the blorb is fine and some other program is caching the art. If you double-click on the blorb, what software does it open in?

1 Like

Spatterlight

After an extremely cursory investigation, I think this is pretty likely to be caused by Spatterlight caching the image for a particular story, which would mean Inform is not to blame.

You could use a tool like blorbtool.py to check the contents of the blorb and see whether the cover image appears to be the right one, or send it to another Spatterlight user to check.

If my suspicion is right – might be a good bug report for the Spatterlight author. Not sure if they hang out here, though.

1 Like

Although the author of Spatterlight (only the one “l”) is Tor Andersson, its current maintainer, Petter Sjölund aka @Angstsmurf does hang out here.

2 Likes

Yes, this is caused by the Spatterlight “thumbnailer” system extension, which gives supported files a system icon based on their cover image. The problem is that cover images in Spatterlight’s internal database take precedence over the cover image in the blorb file.

I fixed a similar problem in the Quicklook preview system extension a couple of years ago, but I apparently missed that the same problem exists in the thumbnailer extension.

You can turn off the Spatterlight system extensions in System Preferences > Privacy and Security > Extensions. You may still have to replace the icon manually, but at least it won’t change again. Or you can replace the cover image in Spatterlight, which will eventually update the Finder icon to the new image.

3 Likes

This worked, but unfortunately left me without the beautiful icons. So I checked which Spatterlight version I have (it was 0.9.0) and then updated to the latest version. Now everything works wonderfully!

Sorry for all the confusion, I never thought this could be the cause.

1 Like