PunyInform v4.7 released

It may happen. Then again it may not. PunyInform wasn’t meant to replace the full library, and I’m sure it never will.

Well no, the standard library doesn’t have a workaround to support identical objects. It’s built into the core of the library. It affects the printing of objects and the parser. While it’s now pretty easy to support the printing of identical objects in PunyInforn, the changes required for the parser are quite extensive.

I have an idea for a workaround for PunyInform, but it turns out to be quite hard (no surprise really). If I manage to put something useful together, I’ll make it part of the howto folder in PunyInform and/or post it in this forum. I won’t post it in this thread though, as this is the release thread for PunyInform, and it has nothing to do with PunyInform releases.


PunyInform v4.2 is out!

PunyInform v4.2 has a new entry point routine called ChooseObjectsFinal, which lets the game intervene just before the parser has to ask the player which object they mean.

Incidentially (not really!), this makes it possible, in a slightly hacky way, to handle indistinguishable objects in a game. We hope this will prove useful for some games, and we created a demo called howto/indistinguishable.inf. There are limitations though:

  • Expect it to make parsing a bit slower whenever player input matches several different objects, and more so if you have a lot of indistinguishable objects in scope.
  • You can’t specify a number of objects in input, e.g. “get 5 coins”, but you can say “get a coin” or “get the coins”
  • When you take or drop several indistinguishable objects, they are treated one by one, i.e. you get “Coin: Taken, Coin: Taken, Coin: Taken”

PunyInform v4.2 also includes important bug fixes, better parsing, and corrected weight of ChooseObjects score (it now always trumps the parser’s own score for the objects when picking the best object).


PunyInform v4.3 has been released.

  • Several library messages now adapt to plural names (see screenshot)
  • There’s a new runtime error message, if you enter a door which lacks a necessary property for a door
  • The runtime error message which points out that a timer/daemon object lacks the necessary time_out property now prints the offending object
  • The routine RunTimeError was renamed _RunTimeError, to reflect that we don’t expect it to be of any use to game authors
  • We read through the entire manual and fixed several errors and omissions, and added some clarifications
  • Bugfixes

See link to Releases page in previous posts.


Just in time for PunyJam #3.


I have updated the Inform6 for Unix package to update PunyInform to version 4.3. This time, there are no warnings when building the PunyInform demos. There was one warning when building the Standard Library demos. It all builds and runs fine. Have fun all!


PunyInform v4.4 is out!

Some news:

  • The flags extension just got more powerful - you can set, clear or check up to three flags at a time, e.g SetFlag(FLAG1, FLAG2, FLAG3); .
  • Using flag 0 is deprecated.
  • New optional feature: Manual Scope Boost - speeds up games which use manual scope, where the player will often see many objects but react_before, react_after and each_turn are often not used. See manual for better explanation.
  • Default value for MAX_SCOPE is increased from 32 to 50, to increase the chances of PunyInform games running fine without adjusting the limits
  • Rearranged Game Author’s Guide to put the most important parts first, and pointed out in manual and on project page that the all but the optimization part is required reading
  • Optimizations
  • Bugfixes

I’ve just updated the Inform6 for Unix package to update PunyInform to version 4.4. No warnings at all this time. It’s at 661.org now and at the IF Archive when the curators there update stuff.

Happy Implementing!


PunyInform v4.5 is out.

  • Important bug fixes in the core library and the talk_menu extension.
  • cheap_scenery has new features, centered around the new option to have multiple nouns and adjectives for a cheap scenery object
  • talk_menu has new features, adding power and flexibility. It’s mainly about adding non-verbal communication, and allowing multiple IDs per topic and multiple topics per ID.

The quickref document hasn’t changed, apart from the version#, since it doesn’t cover the extensions.

Note that the cheap_scenery extension can be used in Inform 6 games using the standard library as well, and the talk_menu extension can be used in Inform 6 games targeting Z-code.

As always, please read the “Important to note when upgrading” section of the release notes before upgrading.


Is there a Spanish library available for PunyInform?


Nope, but there are two different translations to French.


Ce n’est pas la même chose, monsieur.



1 Like

I’ve updated the Inform6 for Unix package. All looks good.


Vraiment? :slight_smile:

The french translations serve as evidence that a translation is quite doable. Also, they offer two different ways of approaching the problem, which may be helpful for anyone wanting to create a translation to a language which has some similatities with French.

But yeah, the simple, binary answer is “No”, which I think was clear from my first reply.


Compiled, installed and successfully tested the new punyinform… a question:
what is, and what means, that R in the banner and VERSION, just after “v4.5”, in the spot where usually S D, and SD are printed ??

Best regards from Italy,
dott. Piergiorgio.


It means RUNTIME_ERRORS > 0. It’s to let the user know that they might see PunyInform runtime errors. I guess it serves to remind the developer that this setting has been left on.


Correct. (This is also in the release notes.)

A production build typically shouldn’t have runtime errors enabled, so it’s a reminder to the developer that the game you’re looking at is not a release version. Also, it may be useful during testing, as you then know if you can expect the library to try to highlight problems or conceal them.


I’m unsure about this reminding; post-release bug reporting will always happens, notwhistanding the best efforts of the author(s) and his/her ßtesters, so I guess that a runtime error cited in a bug report from a player with with little or no knowledge of programming is a sound telemetering (artillery sense, of course) in aiming against bug.

Best regards from Italy,
dott. Piergiorgio.

1 Like

Yes, but it will also be ugly and make the player enjoy the game less, when possibly they could have completed the game and enjoyed it without ever noticing a problem.

E.g. one of the PunyJam #3 games didn’t have the scope limit set correctly, and had runtime errors enabled. A player got error messages, and this was a big enough turnoff to make it into his/her review of the game, making it look like a pretty broken game. It seems the reviewer never had any problems because of the bug, but the error messages became a problem, and now they’re stuck in the review for ever. As an author, you don’t want that. You can fix the game, but not the review.


Agree that runtime errors can became an ugly issue for players, but here we’re dangerously nearing the border of Mimesis, and beyond it, the runtime error message became sins and crimes against it…

Best regards from Italy,
dott. Piergiorgiorgio

1 Like

This tilts the other way if the bug makes the game silently unwinnable. (Which is common, for runtime errors. The usual outcome is that the action fails but the game loop keeps running, so there’s no indication that you’ve tripped over a bug.)

Better if the player knows something is wrong and can wait for an updated version.