Lately, I've been more hugolib spelunking. The most recent thing to grab my attention was the OLD_STYLE_PRONOUNS flags. There's a bunch of code for non-old-style-pronouns that can't even be called without editing hugolib.h, as hugolib.h explicitly sets the OLD_STYLE_PRONOUNS flag. It turns out that Kent was never happy with all aspects of new system so he disallowed it but kept the code there in case it could be salvaged.
There isn't a fix for the main problem he foresaw, but there's a workaround, so I've since enabled the system in Roodylib, although now it's called NEW_STYLE_PRONOUNS. Anyhow, it's very likely that there are other issues with the system yet to be found, but it'll be interesting finding it out. I copied over Roodylib's comment-documentation for the feature of to this Hugo By Example page:
http://hugo.gerynarsabode.org/index.php?title=NEW_STYLE_PRONOUNS
Since the workaround to the NEW_STYLE_PRONOUNS problem involves using routines-as-grammar-tokens, it opens the door to more routine-grammar-tokens down the road. Since a fair amount of these routines might require specific things of the objects fed to them, I thought it'd be good to make a helper routine to call. It uses global masks so you can check for several things against one object. I also transferred the comment-docs from this to a HbE page: http://hugo.gerynarsabode.org/index.php?title=ROUTINE_GRAMMAR_HELPER
Other than that, the new release of Roodylib will have a couple small improvements. Characters now default to having exclude_from_all be true, so things like >GET ALL ignore them. I also put a ClearArray call in one of the status-window-drawing routines to prevent room names from being printed twice in certain scenarios.
Lastly, I've updated the shell file included with Roodylib. I've thought the flag listing in the old shell was starting to get a bit unwieldly, so I thought it better if flag-setting was its own file (I did the same for grammar and library inclusion). Unfortunately, it might bug people to have four files where there once was one, so now Roodylib comes with a shell folder with both old and new shell versions.
Thursday, January 31, 2013
Sunday, January 27, 2013
We, the Roodylib
I made some great Roodylib progress lately. It was especially satisfying work because some of the features were requested; I definitely intend to check with everybody to see if there's anything they want to see in the next one, as Roodylib is at its best when it's a collaborative effort.
One of the suggested features was to make it easier to credit the Roodylib version in-game. For a long time, I've had a versioning system on the compiler side of things, but I admit that, in the future, I'll be curious which Roodylib version this or that game was compiled with. So, now there's a ROODYBANNER constant that says something like "RoodyLib Version 2.7" and a ROODYVERSION constant that will just say "2.7".
I also added a default "XYZZY" response to Hugo, as suggested by Rob O'Hara. He doesn't even use Hugo regularly, but he is one of the many Hugo authors caught unawares by players trying the outdated command. The new response is, "You mention an ancient reference to an archaic game. Nothing happens." This XYZZY-support can be turned off with the NO_XYZZY flag.
Along the lines of the crediting mentioned above, I added a system to Roodylib making it easier to pull up a list of included libraries for hypothetical CREDITS responses. In setting this system up, I made a ListChildren routine so object hierarchy can be used to create lists, the way that PropertyList uses property elements to do so (or PrintArrayList uses arrays).
I think it's kind of cool to set up this object-based way to do this. I haven't thought very long and hard about it, but I imagine there are cases where doing it this way might have some benefit over the other ways, just because object-hierarchy is auto-collapsing and you don't have to worry about empty elements.
At some point, I'm going to have to try my hand at writing several object-based sorting routines just to see what they look like.
Also, I added a "conjunction" argument to PropertyList, ListObjects, and PrintArrayList so you can conceivably replace the AND_WORD with something like "or", for when your listed options are choices.
Lastly, it didn't go into Roodylib, but Robb requested some weather code when I asked everybody if they had any other requests. I knew that Future Boy! had both nice weather and environment support for such things like sky, ground, and stuff, but while related, they were in different files. I spent some time yesterday combining the code (and commenting out Future Boy!-media-specific lines). The result can be found at roody.gerynarsabode.org/hbe/enviroweather.zip .
One of the suggested features was to make it easier to credit the Roodylib version in-game. For a long time, I've had a versioning system on the compiler side of things, but I admit that, in the future, I'll be curious which Roodylib version this or that game was compiled with. So, now there's a ROODYBANNER constant that says something like "RoodyLib Version 2.7" and a ROODYVERSION constant that will just say "2.7".
I also added a default "XYZZY" response to Hugo, as suggested by Rob O'Hara. He doesn't even use Hugo regularly, but he is one of the many Hugo authors caught unawares by players trying the outdated command. The new response is, "You mention an ancient reference to an archaic game. Nothing happens." This XYZZY-support can be turned off with the NO_XYZZY flag.
Along the lines of the crediting mentioned above, I added a system to Roodylib making it easier to pull up a list of included libraries for hypothetical CREDITS responses. In setting this system up, I made a ListChildren routine so object hierarchy can be used to create lists, the way that PropertyList uses property elements to do so (or PrintArrayList uses arrays).
I think it's kind of cool to set up this object-based way to do this. I haven't thought very long and hard about it, but I imagine there are cases where doing it this way might have some benefit over the other ways, just because object-hierarchy is auto-collapsing and you don't have to worry about empty elements.
At some point, I'm going to have to try my hand at writing several object-based sorting routines just to see what they look like.
Also, I added a "conjunction" argument to PropertyList, ListObjects, and PrintArrayList so you can conceivably replace the AND_WORD with something like "or", for when your listed options are choices.
Lastly, it didn't go into Roodylib, but Robb requested some weather code when I asked everybody if they had any other requests. I knew that Future Boy! had both nice weather and environment support for such things like sky, ground, and stuff, but while related, they were in different files. I spent some time yesterday combining the code (and commenting out Future Boy!-media-specific lines). The result can be found at roody.gerynarsabode.org/hbe/enviroweather.zip .
SimpleTalk
I recently took another look at simpletalk.h, my include-able version of Robb Sherwin's ptalk, which was his port of Adam Cadre's "phototalk" extension for Inform 6 (based on code he used for his game, Photopia). I took a look at simpletalk for two reasons- 1) simpletalk was one of my earliest stabs at library-extension-writing and I thought it was likely I could make it look better, and 2) there was some code in the original "phototalk" whose purpose I couldn't understand and I wanted to take another swing at it.
This time around, I decided that the confusing code was Inform 6's version of Hugo's masking function. Having figured that out, I then had to think for a long time about why masking was even useful. Eventually, I decided such an implementation would allow simpletalk to easily distinguish between unavailable-and-already-spoken and unavailable-and-not-spoken chat options, or available-and-spoken and available-and-not-spoken chat options.
I also decided that the SetUpQuips routine and the arrays were an awkward way to keep track of everything, so I switched it over to a property-element-based system and renamed the extension as "newsimpletalk".
Still, I am keeping an updated-but-using-the-old-array-system version (still called "simpletalk") that will hopefully work with all existing ptalk code out there.
Anyhow, I really need to write a HbE page about the usefulness of masking. It's only taken 15 years or so, but I finally would know how to do the duct-tape-weapons system from "Death To My Enemies" in Hugo.
This time around, I decided that the confusing code was Inform 6's version of Hugo's masking function. Having figured that out, I then had to think for a long time about why masking was even useful. Eventually, I decided such an implementation would allow simpletalk to easily distinguish between unavailable-and-already-spoken and unavailable-and-not-spoken chat options, or available-and-spoken and available-and-not-spoken chat options.
I also decided that the SetUpQuips routine and the arrays were an awkward way to keep track of everything, so I switched it over to a property-element-based system and renamed the extension as "newsimpletalk".
Still, I am keeping an updated-but-using-the-old-array-system version (still called "simpletalk") that will hopefully work with all existing ptalk code out there.
Anyhow, I really need to write a HbE page about the usefulness of masking. It's only taken 15 years or so, but I finally would know how to do the duct-tape-weapons system from "Death To My Enemies" in Hugo.
.h vs .hug
I have to admit that for a long time, I've been kind of confused about when an included Hugo file should have the extension ".h" and when it should have ".hug". I mean, the hugolib library files are obviously all *.h and a shell file is always *.hug, but why, for instance, did all of the Future Boy Selected Source files use the *.hug extension when several seem to be relatively includable (and are comprised of utility routines and object classes and such).
I've recently decided on the distinction that the *.h extension is reserved for files that have gone the extra mile and have inclusion-specific code like:
I may change "version.h" back to *.hug at some point, too, as as far as contributions go, that one is very short and likely to be modified by the author.
I've recently decided on the distinction that the *.h extension is reserved for files that have gone the extra mile and have inclusion-specific code like:
#ifclear _ROODYLIB_HWhat this means for Hugo-by-Example-hosted files is that while most of my library contributions will remain the same, some of the Future Boy! contributions like "books", "time", "context_menu", and "config" are going back to their original *.hug extension.
#set _ROODYLIB_H
I may change "version.h" back to *.hug at some point, too, as as far as contributions go, that one is very short and likely to be modified by the author.
Wednesday, January 2, 2013
announcements and enlistments
Thanks largely to the second annual "Hugo Open House" game release, I've made several improvements and discoveries in the last week or so. What announcing I've done has mainly been at the joltcountry.com forums, as I think that is the best pedestal for shouting to the Hugo world. What has been going on? I'll tell you!
I found a huge xverb grammar bug. I made some progress in refining DoGo. I found my first "checkheld" weakness.
Beyond that, I think I've uploaded new versions of Roodylib a couple times in the last few weeks. Again, this is largely because of the extra testing it got because of the recent games, so that's cool.
With some of those problems above, I've asked for help. I'm pretty confident that we, the Hugo community, will be able to hammer these things out, and Hugo's going to be all the better for it.
I found a huge xverb grammar bug. I made some progress in refining DoGo. I found my first "checkheld" weakness.
Beyond that, I think I've uploaded new versions of Roodylib a couple times in the last few weeks. Again, this is largely because of the extra testing it got because of the recent games, so that's cool.
With some of those problems above, I've asked for help. I'm pretty confident that we, the Hugo community, will be able to hammer these things out, and Hugo's going to be all the better for it.
Subscribe to:
Posts (Atom)