the last few months

 When I last updated Roodylib a few months ago, I found a bug shortly after, but I didn't think it was important enough to bother IF Archive maintainers with another upload so soon.  Anyhow, good news!  The last few months have been very successful in finding and fixing several bugs.

To avoid having to actually get back to writing games, I had decided to distract myself by getting back to the project of applying Roodylib to other people's games.  In the past, this has been a great way for finding shortcomings in functionality and ease of configuration.

Anyhow, the game I was returning to has several randomized events and a lot of character scripting and other things that just made the original task of adding Roodylib quite daunting.

It wasn't long before I ran into an instance where a character with a long character script was never reaching his destination.  At first it drove me a little crazy trying to figure out why the last few steps in the script were not happening.

Long story short (and yes, I can easily make it a long story), I found a bug in Hugo's library code.  Character scripts are supposed to have a maximum of 32 steps; instead, if there were multiple character scripts running, the second script was overwriting the first at the 17th step.

Anyhow, I fixed the bug and I was pretty excited about this.  When I first starting making Roodylib, I had never researched how versioning numbers are supposed to work so I just jacked the numbers up willy-willy whenever an update felt big to me.  Eventually, someone pointed out to me that the major, minor, and patch numbers actually stand for things.  In the years since, of course, Roodylib version numbers crawl up by much smaller increments since most updates fall under the "patch" umbrella.

So, to me, fixing a system from the original library was BIG and merited a minor number increase, and what can I say, I find that exciting.  Also, of course, I was happy to be able to have a good reason to put out a new release because of that bug I mentioned at the start of this post, too.

Luckily, the bug fixing did not end there, nor was the hunt even limited to the Hugo library/Roodylib.

While troubleshooting that game I had been adding Roodylib, too, I found a bug where, if I referred to a known object not in scope, if there was another known object not in scope that shared an adjective (despite different nouns), the first one defined would always be the one sent to ParseError;  of course, this is noticeable if the objects have different pronouns ("You don't see him here." when you are expecting "her").

After testing, it became clear that the problem was not on the library side.  I wrote one of the people behind one of the Hugo interpreters and asked him to look at the problem;  he said that he didn't have time right away but pointed out that the problem was probably in "heparse.c" (in the source).  When I read that, I thought, huh, it never even occurred to me that I might have the chops to be able to understand the engine code but, hey, it couldn't hurt to look.

I wouldn't say that it was easy, but Kent's code is commented and organized nicely and it was fairly clear where I needed to look.   Plus, I have to give props to all of the people who have contributed to making the Hugo unix port so easy to build on modern systems so I could tinker and test my solutions relatively quickly.

I found the bug and went around making pull requests at several github projects that use the Hugo source.  Gargoyle accepted it right away, and it was kind of a bucket list moment for me.  I've always wanted to contribute to an open source project but didn't think I had the programming chops for the opportunity to ever come up.  In the acceptance, it was explained to me that Gargoyle (and several of the other interpreters) inherit their code from the Hugo unix port repository, and somewhere along the way I was made a collaborator of that so I'll never technically have to do a pull request again, but it sure was satisfying to make one and have it accepted!

After that, I was digging through old joltcountry.com posts to see if there were any problems that new light could be shed on, and I found one about Hugo's inability to write (and correctly read) negative numbers when it writes to file.  Someone helped me come up with a solution.  It won't work in 16 bit interpreters (I don't even know the likelihood that anyone will ever build a 16 bit interpreter again), but that's fine; writing negative numbers would probably never be needed by a game author- it was more for interpreters that use Nikos' opcode system for special instances.

Some years ago, I noticed that if an xverb grammar definition (xverbs in Hugo are system verbs like "save" or "restore" that don't use up a turn) was more than one line long, the additional lines would be interpreted as a verb.  I decided to look into this as well.  I initially thought the problem might be in the compiler on this one, but it turned out to be another engine error.  I got that one, too.

So, three engine fixes!  Now, I imagine that we are probably years away from our next Gargoyle or Hugor or whatever release, but it's nice knowing that those fixes will be out in the public one day.

Anyhow, I've been kind of rambling on and on.  I'll just say that in these last weeks, I also fixed some problems with Hugo's plural/identical class system and I was pretty stoked about that (another good excuse for the minor increase in the upcoming version).  The rest, I'll just save for the new release's changelog.

Thousands of Golf Balls

In my game, there's a part where you are in a room (street) where newspapers are being delivered. It occurred to me that if I used one object for both singular ("GET PAPER") and plural ("GET PAPERS") cases, there was a possibility of incorrect responses. Instead of checking this assumption or deciding to bulk up my newspaper object with parsing code that checks how it was referred to or splitting it into two hidden objects, I thought, hey, maybe I could actually do this with objlib.h's plural class.

Initially, this worked great, but I found that I could trick the game into showing me that there were only 4 newspaper objects with a command like >GET 5 NEWSPAPERS.

This also reminded me of an older WIP where, in a room full of golf balls, a tester tried the command >GET 1000 GOLF BALLS. Now, I'm not going to go code a thousand golf ball objects, but ever since then, I was a little disappointed that I couldn't do more to give the illusion that the game could handle such a command.

Anyhow, now that I have roodylib and a better understanding of how things work, I thought I'd take a swing at the problem. I tracked down the code in ParsePluralObjects that interprets the number in the command line. It calls WordIsNumber, which matches the word with a simple select-case that handles numbers "1"/"one" through "10"/"ten". I added code so it also calls StringToNumber, so it can now also handle 11-32767 (it can't handle the word version of these numbers but I figured that was a lost cause).

My first hurdle was that this section of code checks the word array for numbers twice, supposedly so that Hugo can understand commands like >GET TWO OUT OF THE THREE CHICKENS. My StringToNumber-enhanced routine can't be called twice like that, so I had to throw the "<blank> out of <blank>" code out.

It was easy enough to find the code in plural_class object where it prints a "There are only X objects here."-type command when you refer to too many, and it was also easy enough to change it to disregard the number of actual-objects-there.

Still, I thought there was another important number in the equation. There's the number you want the player to think is there. In the above example, I *don't* want >GET 1000 PAPERS to have the same reply as >GET 5 PAPERS. To handle this, I added a couple new properties to the plural_class object. One is called imaginary_plurals. It holds the number the plural class is supposed to have*.

* The type of plural object that uses these properties are going to be largely scenery. They aren't actually going to be picked up or interacted with to any large degree. We're only doing this to make responses sound smarter.

The other one is called over_max. It just holds the response the player will see when he refers to more objects than the imaginary plurals number.

Let's take a look at my finished newspaper object:

identical_class newspapers "newspapers"
{
    plural_of paper1, paper2, paper3, paper4
    noun "newspapers" "papers"
    single_noun "newspaper" "paper"
     imaginary_plurals 12
     over_max
        "Even with all of the apartments and homes on your street, you'd
     be lucky to find more than a dozen papers in the near vicinity."
}

 Hopefully, that'll all make sense in the end. There's a good chance I'm breaking more than I realized, as plural class stuff seems to juggle a lot. Anyhow, I think this *will* call for a new Roodylib upload. People can expect it soon enough.