Roodylib 3.8

So, this release feels like it adds a lot more than it probably will feel to the end user, but here is the changelog:

* Added an "elevated" attribute for enterable platforms (such as ladders) where "down" is an accepted exit direction
* Changed the vehicle class again (check out roodylibdocs.odt)
* Added USE_SMART_PARENTS flag so if the player tries going into an invalid direction while in an enterable object, they get "You can't go that way." instead of "You'll have to get up/out."
* In doing so, updated DoGo, and the vehicle and door classes to support it
* Added SKIP_DOORS flag so player can breeze through unlocked doors without opening them like NPCs
* Added a HugoFix settings object so debug monitor settings are kept after a restart
* If daemon/fuse monitoring is on (in HugoFix), a prompt asks whether to run the relevant daemon/fuse (to make it easy to skip during testing, if wanted)
* Got rid of an unnecessary AUX_MATH routine call in printstatuslib
* Made sure Roodylib is more NO_OBJLIB, NO_VERBS, and NO_XVERBS compatible
* Added USE_DARK_ROOM flag so dark rooms appear like an actual room when you enter them (check out roodylibdocs.odt)
* Updated flags.h to include new flags
* Update "go" grammar
* Added the coverart extension to Roodylib because of its configlib compatibility
* Updated old files to have UNIX line feeds and fixed indenting on older code

I also touched up some of the documentation files to mention a couple more things.  Still, there is probably lots of stuff that I could describe more.  If there are Roodylib functions that you'd like to see be better described, shoot me an e-mail!

You can download the latest version here: http://roody.gerynarsabode.org/notdead/roodylib_suite.zip

Roodylib 3.2 has been released

Just since practically everyone who uses Roodylib follows this blog, yes, I uploaded the latest version of Roodylib and it is available at the usual spot:
http://hugo.gerynarsabode.org/index.php?title=Roodylib

always more to do

I have to admit that recently, I've been yet again not working on my own games but have found a distraction. I've been applying Roodylib and my extensions to somebody else's already-released game-with-available-source-code. Mainly, I've been curious how well my code can integrate with other games and whether it helps the overall playing experience. So far, I'd say the results have been fairly promising, although the experience has brought some more issues to my attention

Objects Can Be Grabbed From the Possession of Friendly Characters Without Comment

I was kind of surprised to find out that a character has to be unfriendly to refuse you from taking its possessions, and when you do take possessions from a friendly character, you just get the default "Taken." message.

Now, without modifying Roodylib, there is this solution:

replace character
{
   type character
   pronouns "he", "him", "his", "himself"
   capacity 50
   holding 0
   is living, transparent, static
   exclude_from_all true
   before
   {
      parent(object) DoGet
      {
         local l
         l = string(_temp_string, self.name)
         l--
         print "Nah, that is "; The(self);
         if _temp_string[l] = 's'
         {
            "'."
         }
         else
            "'s."
      }
   }
}

The above disallows taking things from friendly characters. To allow it, you'd have to replace the before routine with something that calls Acquire and prints its own "so-and-so lets you have the <blank>" message.

Just in thinking about the issue while I write this post, I think I will update Roodylib so that DoGet calls a character's after property to allow for different messages when you take objects from friendly characters.

EDIT: Actually, looking at DoGet closer, it already has a parent(object).after check, so I think I'll just give a default after routine to the character class.

Platforms Get No DescribePlace Love

While testing my code, I also noticed that contents of scenery platforms were not being listed by DescribePlace. The game (and others) have gotten around this by having code like this in a room's long_desc:

if child(self)

Perform(&DoLookIn, self)

else

"There's nothing on it."

Really, though, I can't think of a reason why you wouldn't want DescribePlace to handle platforms automatically. You can always deny content listing for &DoLookAround in list_contents, if you want.

The original scenery-contents check looks like this:

         if obj.type = scenery
         {
            obj is known
            if player not in obj and
               (obj is open or obj is not openable)

My check now looks like:

if obj.type = scenery

{

if player not in obj and

! (obj is open or obj is not openable)

((obj is container and (obj is open or obj is transparent))  or

obj is platform) and obj is not quiet

There's probably some overkill in there, and hopefully I didn't introduce new problems.

Platform Problems Part 2

Another problem cropped up, where even looking at scenery platforms or containers like above didn't prompt a listing of their contents. Since I've run into a problem like this before, I quickly guessed that my DescribePlace had left those items with the already_listed attribute, which DoLook looks for before listing contents. At first, I tried updating DescribePlace to always remove that attribute from them, but the thing is, in my modular version of DescribePlace, I really want the author to be able to list objects in any order they want, and I didn't want to restrict them to always having to list scenery contents last.

In the end, I thought, huh, why does DoLook even care about already_listed, anyway? Those attributes will just be reset the next time DescribePlace is run. The only thing instance where I think the already_listed-check might be important is in the case of identical plurals, but in my cursory testing, removing the check has had no effect on identical-plural behavior. Guess I'll just keep the check off the next version of Roodylib and see what problems pop up.

Speaking of Roodylib, I should probably upload a new official release soon. I guess I've been putting it off. I think I'll probably do something about that DoGet issue mentioned above, and here is some other stuff that'll show up in the new version:

 * added a missing printed bracket in parser monitoring code

* added NEW_EMPTY system for more container/platform-emptying options

* added AMERICAN_ENGLISH flag to switch between quotation punctuation styles

* added NEW_DESCRIBEPLACE to give more DescribePlace options

* added WhatsIn replacement and ListObjects RLibMessage-call for more printing options

* updated CenterTitle to not draw extra window in simple, non-Glk terps

* Fixed some places in the supercontainer class that didn't work right with transparent supercontainers.

* Fixed a problem where non-door items with door_to properties weren't being accepted by DoGo. Probably still some perfecting to do on this one.

* Attachables DescribePlace code was missing some parentheses.

more roodylib updates

I added a lot to Roodylib today. The biggest chunk of code was probably my new (optional)  DescribePlace system. All in all, Roodylib went from 160 KB to 181 KB.

I also "released" my port of Cardinal Teulbach's SceptreQuest, which I uploaded to http://roody.gerynarsabode.org/games/squest.hex (I use quotes because I don't intend to announce the game any where besides here and my twitter account, as the copyright on the game doesn't technically allow re-release like this). Writing that inspired several Roodylib updates today. We'll get to that in a bit.

First off, I added an AMERICAN_ENGLISH flag to Roodylib. It really doesn't change as much as you'd think. All it really does is move quotation mark placement for statements such as "I don't understand the word 'blah.'"

As mentioned I also added that DescribePlace stuff. When I ported SceptreQuest, I also coded its odd color handling. I found that this involved changing color at places that forced me to replace whole hugolib routines, so among other things, I added calls to RLibMessages to handle different printed tasks for DescribePlace (such as the printing of the room name), WhatsIn, and ListObjects. As far as ListObjects goes, there are probably more bits of text that I could sent to a message routine, but I'll add those as needed.

 I also finally added that DESCFORM_I constant to act as a FORMAT mask. When enabled, DescribePlace does not print the blank line before printing the room name. It now does this check (in RLibMessage):

                    if not (FORMAT & DESCFORM_I) or (verbroutine ~= &MovePlayer and
                    verbroutine ~= &DoLookAround and a = location)
                        print "\n";

The location check allows one to use DescribePlace to fake movement to rooms (where it should not print a new line) but still prints a new line for when things like newmenu.h call DescribePlace after having printed "returning to the story...".

The next thing I'm considering working on is a combination of Future Boy's time object class and improved resource.h  routines where things like audio.current_music is automatically cleared after the song is over. Going over it in my head, though, has me thinking it might be too bulky for Roodylib-inclusion so I may just improve my already-existing-but-separate jukebox system to do that. We shall see!

3.1

Just letting you all know that Roodylib v3.1 is now up on Hugo by Example and the bitbucket repository. I also uploaded it to the IF Archive, but it'll probably be some days before that one is accepted.

shell shock

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.

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 .

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.

The fruits of my labor

I think the latest versions of the library contributions discussed in the last couple posts are ready for the public:

NewConverse 2.0
Opportune 1.3
MultiOpportune 1.3
PastTense 1.2
Roodylib 2.0

The new UNDOlib extension is part of the roodylib suite (among several other added features). Opportune.h actually has decreased functionality compared to the earlier version; MultiOpportune.h is the version which does multiple opportunities, but like I said, fuses are probably better in that case. PastTense.h just has some bug fixes, but I've tested that one so little that I'm sure there are several more out there.

updates

Today, I wrote that color-support extension I mentioned the other day. I don't remember if I mentioned it already, but I also threw together the optional "cheap mode" extension on Friday. Unfortunately, I was too lazy to write code in these libraries to support non-"roodylib" usage. I tried to keep non-roodylib support in my updates to the various libraries, but now it's all kind of a jumbled mess so I'm not even sure. I figure I'll give roodylib and the updated libraries their own page on HbE to quarantine them for a while.

Anyhow, after a day away this weekend, coming back to work on these things wasn't the rewarding challenge I was hoping it'd be, so I think I'm starting to get a little burnt out. I'll try to use my waning attention in the next couple days to organize and document what I've got so people can take a better look at it.

Next on the agenda (when I feel like working on the agenda) is:

1. NewMenu, like the Menu routines it borrows from, looks for a default menu if not given a particular one. It doesn't come with an example menu, so in a way, the extension feels kind of like it's "shipping" a defective product. I was thinking it should come with a default menu that comes with three options. The first option would be general information about Hugo itself. The second one would a thing on general IF commands. The third one, though, would be the interesting page, as it'd write itself based on what libraries have been included. For instance, if my new cheaplib or colorlib libraries are included, it'd automatically inform players of the "COLORS ON" and "CHEAPMODE OFF" commands. Authors would be free to alter or replace the default menu completely, but there'd be a functional menu there without any effort.
2. Another thing to consider is a better way to automate file inclusion.
3. See if I can update my "newconverse" update to play nice with "roodylib" 

An issue to ponder-
One of the things that "roodylib" does that I am overly fond of involves the status bar. In glk, once the status window has been drawn, it is not possible to make it disappear with a "window 0". Often, when you restart a game, the status bar will show the last session's information until the first time PrintStatusLine is called (which may be a keypress or two away, depending on the length of the introductory text). Instead of trying to fix that by clearing the status bar at the beginning of the game- showing a blank bar- I thought it'd be cooler to write something up there. I wrote some code where if the constant GAME_TITLE is defined, it prints that. Otherwise it just prints "HUGO INTERACTIVE FICTION". The end result looks pretty sharp. In fact, if someone turns cheap mode on in a cheaplib-enabled game it just shows that all of the time.

So, that's all fine and dandy, but in a regular, non-cheap-mode session, "window 0" does work, and it looks kind of cool to have no status bar up until the first PrintStatusLine of the game hits you. Unfortunately, though, this can cause some problems if there is a long opening, as the start of the intro text gets all of the way to the top of the screen, and when we get to PrintStatusLine, the new status window can cause text corruption or cover the top of our intro text completely.

So, the question is, should even regular interpreters get the "HUGO INTERACTIVE FICTION"/GAME_TITLE window treatment just to avoid buffer/screen issues? I have not yet committed myself to an answer yet.