A lot has changed since I uploaded "newmenu.h" to the IF archive, and I'd like to make sure it's in a good place before I upload it again. After working on the transcript stuff, I doublechecked that it worked ok with and without roodylib.h. This brought me to the auto-generating help menu thing that I set up some months ago. I was reminded that there should be a way for game-specific menu options to take precedent over the generic ones; in fact, the author should have complete control over the order of all of the options, right?
So yeah, I made a "priority" property for menu options- the higher the number, the earlier an option is listed. Coming up with a solution was trickier than I had predicted as I originally wanted to do it with regular arrays (and even modified my SortArray routine to allow for starting at an element other than 0), but since newmenu currently keeps track of its menu choices using two arrays, it was easier to just write the choices to a property array and use SortProp to re-order them.
As far as newmenu goes, I seem to be running out of hugolib-defined properties to alias to. Not aliasing is no big deal, but I try to do it when possible. Still, you don't want to accidentally alias something with a property that might be interpreted another way or otherwise interfere. I found one such overlap today, when checking to make sure that the roodylib-enhanced version of newmenu didn't run the MenuInit routine after UNDOs and RESTOREs.
So, the main thing is, the latest versions of newmenu and roodylib can be found at http://roody.gerynarsabode.org/hbe/newmenu.zip and roody.gerynarsabode.org/notdead/roodylib_suite.zip, respectively.
I've got some things to do with newmenu before I upload it to IF archive, yet. I have to make sure that the different-color-scheme-per-menu-page code still works and that the "cheap"-mode codes still works. Plus, just now, it occurs to me that maybe I should cut it down to use one array, so yeah, maybe I'll do that.
I've been using newmenu, and I recently started using roodylib. I don't know that I'm doing anything advanced enough or understand the code well enough to report anything useful about their behavior. However, I will keep updating to the latest versions before you upload them to the Archive, and if I notice anything remarkable, I'll tell you.
ReplyDeleteThanks, that's appreciated. I can imagine roodylib is kind of intimidating. There's a lot there, as much as I try to comment it. The included .odt files (which should open in open source word processors like OpenOffice, LibreOffice, and AbiWord) try to provide overviews of the important stuff (although I haven't gotten around to writing anything about newmenu's newest features).
DeleteI imagine the hardest things to initially understand is roodylib's object-based method of adding init and main routines. Instead of adding routine calls yourself to init and main, library extensions put "setting objects" in the init_instructions and main_instructions object, and their "code execution" properties are automatically run.
Another concept I imagine is kind of obtuse to a newcomer is how often I use the word array to save state within a game. Originally, init_instructions code was only meant to be run at the beginning of a game, but I have since modified it to also run after RESTOREs and UNDOs (so you can code for all situations). The downside of this is that I have to exclude the not-applicable scenarios by hand (so you'll see a lot of "if not CheckWordSetting("undo") and not CheckWordSetting("restore")").
In any case, feel free to ask questions!