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 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).
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!
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
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.
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.
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 ??
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.
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.
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…
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.
