New Menus and new Basic Help Menu extensions

This is a general reminder that if you want to use some shiny new menu extensions in your z-code or glulx game (maybe to sexen up your IFComp effort…?) that I released two semi-recently.

(EDIT: Mark Musante saw this post, and the extensions are now up on the extensions site, here: )

Here’s the blurb for Menus:

“Lets you include a menu system of help, hints and/or other information in your Glulx or Z-Code project. This is an upgrade of Emily Short’s Menus extension featuring user friendly single keypress controls and a more sophisticated UI. It also has configurable options, a book mode with automatic pagination and isolated message content to make translation to other languages easy. Old Menus format tables can be upgraded for use with this extension with a little work.”

Here’s the blurb for Basic Help Menu:

“Provides a HELP command in your Glulx or Z-Code project which brings up a menu giving standard instructions about IF. This is an update of Emily Short’s Basic Help Menu extension to make it compatible with Wade Clarke’s Menus. Requires Menus by Wade Clarke to run.”

These extensions have the same name as the famous Emily Short extensions, as they are intended as upgrades/updates on those. I ran this past a good number of knowledgable people and they basically agreed I should stick with these names. Emily Short also okayed the project. All 4 extensions can co-exist in your Inform installation for the time being, since they are filed separately under their respective authors.

While these new extensions have a good number of features, the biggest helps are the single keypress selections (the old extensions required navigating in and out of menus with arrow keys, and also couldn’t keep your place in a menu) and that the newies produce really clean transcripts when players use the menu system. The old extensions produced pages of filler. All the info in the new Basic Help Menus is up to date, too.

The extensions have undergone all the tests required by the extensions website, as well as tons of testing by me and some by third parties. The docs are super comprehensive, and Menus has an example built in so you can see what it’s like.

(If you want, you can read the two old development topics about the extensions here:

The first one:
The second one: )

  • Wade

Wade, this looks cool. I’m in the middle of some other areas of my game, so I won’t do the upgrade until I get to a more stable point. Thank you also for providing documentation on upgrading.

Thanks Zack. Let me know if you find you have any troubles when you get to that point.

  • Wade

The order of columns in a table doesn’t matter. If you recommend that the first three number columns are place last then authors won’t need to fill in 0’s for all the rows. The subtable/description/toggle columns can also be left out if none of the rows use them.

There’s already a comment in the extension docs that the column order doesn’t matter. But I don’t feel safe agreeing with the other statements because I remember spending time error/troubleshooting such issues at the time I was writing the extension. That’s now months ago, and without going back to doublecheck right now to verify (especially the one about the zeroes), I can’t endorse Dannii’s other statements. Sorry Dannii :wink:

  • Wade

Well you may need to change the code to more carefully check if the data is present, but it is possible. Something to consider when you inevitably update it!

(3 months later)

Ok Dannii, you were right about the zeroes. I experience your constant rightness in these things as a kind of mild but incessant punching in the face. So lemme see if you know something I don’t know about the other columns.

You’ve suggested ‘the subtable/description/toggle columns can also be left out if none of the rows use them’. Now the way I see it, that would be true if I didn’t go around checking for their existence. This extension must scan every row of every table when it starts up to analyse the table contents and structure. And at such times, the only way it can check a row for a toggle entry, for instance, is to ask ‘if there is a toggle entry’. And if there isn’t a toggle column at all in that table, one of two things will happen

(a) if there’s no toggle column in any other table in the program, the compile will fail, and say ‘what’s a toggle?’
(b) if there’s a toggle column in some other table, the test will work (IE it will return the fact that there is no toggle entry in this particular row)… though did it work ‘right’, or is this a dodgy mechanism?

If (b) is not a dodgy mechanism, I could let authors leave out completely unused columns in tables so long as I put a dummy table in the extension with one of each kind of column.

If (b) is a dodgy mechanism, I don’t see any way I can let authors leave out any of the columns, because I’m going to explicitly ask if that data is there, and if isn’t, the compile fails.

Have I got all this right?


Haha, no worries! You should definitely include a table of column definitions to ensure the columns all have the right kinds. Then you can do method B. That’s exactly how my Menus extension works.

Cool, thanks for verifying that.