What do the letters mean at the end of the PunyInform library version?

When I built my code for debugging it said in the header

Inform v6.45 PunyInform v6.0.2 SDR

and now when I build it for release it says just

Inform v6.45 PunyInform v6.0.2 S

This surprises me because I thought R would stand for release. What do the letters signify?

1 Like

D means it’s a build with debugging enabled, e.g. through the compiler flag -D or Constant DEBUG; in the code. This is good for development and testing, especially combined with the extended set of metaverbs, but for release you do not want to see a D at the end of the version number.

S means it’s compiled to have strict error-checking at runtime, which is on by default. This is good for development and testing, but not recommended for a release because it makes the game bigger and slower. To turn it off, pass the compiler flag -~S, either on the command line or as a compiler directive with !% in the source file. (Thanks Fredrik!)

R means the RUNTIME_ERRORS constant is set greater than 0. This is also good for development and testing. The author’s guide suggests setting it to 0 for a release build to avoid bugging the player about non-critical errors.

Thus, development and testing builds are likely to have the letters “SDR”, but release builds are probably going to not have any letters at all at the end.

(Yes, I figured it out on my own but there was no clear web search hit for this so I thought I might make one.)

2 Likes

If you start building a game using the code skeleton minimal.inf, you get a good start, including a few lines at the top to set compiler options to make the game smaller and faster. This includes -~S, to turn off strict error-checking, as strict error-checking has a severe impact on both file size and speed. At least for a release build, meant to be playable on 8-bit machines, strict error checking should always be disabled.

2 Likes

What about R for RUNTIME_ERRORS?

I don’t have it set, so mine’s default. Should I go back and rebuild game? I’m targeting 8-bit and 16-bit, plus making a .z5 for a web browser.

The Author’s Guide says

Additionally, it’s generally advicable to set RUNTIME_ERRORS to 0 when making a proper release. This means the library will keep quiet about problems it spots which don’t make the game crash. This makes the game file smaller and stops the library from breaking player immersion with complaints about programming errors.

And now that I read it more closely again, I realise it also says about strict checking that

it makes Inform code both bigger and slower, we usually recommend game authors to disable it, and this is done on the first line of the game template minimal.inf (“!% -~S”)

although this wasn’t in the “Before release” section so I missed it at first. This confirms what Fredrik said in this thread.

The documentation for PunyInform really is very good. Rare these days.

2 Likes

I guess I have to rebuild anyways. I forgot to put an IFID in there.

And it looks like IFIDs changed with Inform 7. The number is pretty long, and it doesn’t have a lot of meaning.

UUID://1974A053-7DB0-4103-93A1-767C1382C0B7// vs UUID://ZCODE-1-220928-2582//

The first form of IFID is the correct form for both Inform 6 and 7.

The second form is a fallback that is used for games where the author hasnt put an IFID in them, possibly because they came out before the IFID standard emerged.

4 Likes

The IFID will (if randomly generated, almost certainly) be unique. That’s what makes them meaningful.

1 Like

Yeah, the drawback of the old-style (automatically assigned) IFIDs is that they change with every new build. New-style (randomly generated) IFIDs are consistent across builds, which is better for identifying particular works of IF.

This site is handy for generating a new IFID:

one here too. scroll down a bit.

i’ve always wondered what the odds are of getting the same IFID from each site. something like the number of atoms in the universe?

i usually forget to add an IFID when using inform. dialog, however, will pester you about it until you’ve added one.

2 Likes

Somewhat better odds than that; it’s closer to the number of grams of matter in the Milky Way (1041).

Which is to say, still effectively impossible by all human standards.

2 Likes

3 Likes