Vraiment? 
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.
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
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.
Fully concur and agree with Uncle Zarf: this indeed is the rationale of why I’m perplexed about this R reminding…
I think there’s a possibility that one of us knows more about exactly which runtime error checks are skipped in PunyInform if you set RUNTIME_ERRORS to 0, thus losing the R in the banner.
Also, keeping full runtime error checks is the default behaviour, and it isn’t wrong to do so. It’s still good to know that the build you’re playing has these extra checks and messages enabled.
Independent of any discussion about right or wrong, if you prefer the v4.4 user experience in your game(s) there’s nothing to stop you just commenting out this feature in lib/grammar.h (lines 1245-1248).
Actually this discussion serves as a good reminder that we should document exactly which runtime checks the RUNTIME_ERRORS setting controls. I realize it may sound like it lets you enable or disable all runtime checks, and this is not the case. I consider it quite similar to Strict Mode - a bunch of checks which are useful, but they also make the game larger and slower, so you may want to consider disabling them in a production release, especially for 8-bit targets.
PunyInform v4.6 has been released.
“That is not a verb I recognize.” in the screenshot is due to a bug. Fixed in v4.6.1.
Inform6 for Unix package is now updated with PunyInform 4.6.1.
the md5sum posted on your website doesn’t match.
I’ll fix that later today.
It’s now fixed. The problem came from a flaw in the git-archive-all script. The gzip program saves the timestamp of the compressed file unless this behavior is specifically suppressed. I use this add-on because simply using git-archive won’t work if a repository includes other repositories – here it’s the Inform6 compiler source code, PunyInform, and the Inform6 Standard Library.
Thank you for your continuing support & development for retro-adventuring
PunyInform isn’t only for retro adventuring. Although the aim is to allow the creation of games that are really compact and can run on old 8-bit and 16-bit platforms, you can still write super sophisticated games that are every bit as feature rich as all the other modern authoring systems.
