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.

4.2.1

So, I was testing the latest Roodylib with Juhana Leinonen's HugoJS interpreter, and it turned out that I had forgotten to incorporate some code from last fall which prevented Roodylib from causing games to hang.  Anyhow, it's in there now.

I also added an "opcode alternative" folder to the extensions so people can use Nikos Chantziaras' opcode-calling routine if they find Roodylib's less-direct method too confusing.

Yes, I skipped from 4.1.9 to 4.2.1 because even though I thought an April 4.2.0 release would be funny, I forgot about that whole Hitler thing and thought best to avoid it altogether, ha.

Roodylib 4.2.1 is here.  I've also updated the Hugo Notepad++ bundle and the Hugo Notepad++ add-on (for preexisting Notepad++ installations).

Back From the Dead

So, first off, my apologies to anyone who was looking forward to more posts here during the last several years.  I was overwhelmed with some of the big changes I wanted to make to Roodylib to begin with, and then first my grandmother and then my father had health issues that took up all of my attention.  Sadly, they both passed away last year, but I'm thankful for all of the time I was able to spend with them.

I've had more time to get back to Roodylib in recent months, and I'm happy to be able to share the results.  I've uploaded a new version of Roodylib here.  I've also updated the Hugo Notepad++ bundle and the Hugo Notepad++ add-on (for preexisting Notepad++ installations).

As issue-tracking and version-numbering aren't really my forte, I have bumped this new release up to Roodylib 4.1.9, as it's basically an alpha I'd like to get out into the open (and my juvenile sense of humor thought it would be stupidly funny to put out a final 4.2.0 release later this month).  I've run it through a bunch of games with pretty much no issues except for changing how files are included, but one never can tell with these things.

Changes in this new release:

• Right after the last official release, I noticed that Roodylib didn't handle multiple AGAIN/Gs in multi-command input.  Originally, I thought it was something I broke, but it seems that Hugo's library never handled it quite like I would want.  Anyhow, that's working now.
• I moved whatever I could back to extensions for overall better code-readability for both Roodylib and the extensions themselves.  As much as I have loved the simplicity of just adding a flag to include functionality in my games, I decided that I have to keep future authors in mind so it's easier for them to see how each system works.  One side effect of this is that certain routines had to be broken up even further, so this new version of Roodylib grows in routine declaration despite being pared down in size.
• Similarly, I redesigned some of the Hugofix stuff so extensions can easily add more debugging options without having to replace the entirety of some Hugofix routines.
• I added some pronoun-choosing helper routines so games seem smarter.
• Opcode functionality should be up to date and working on all existing opcode interpreters.
• Improved some attachables stuff.

I didn't go all-out crazy making the documentation as perfect as possible, but a lot of this is covered in more detail in the Roodylib documentation.

There has been some other exciting Hugo news in recent months:

• Juhana Leinonen released Borogove, which allows people to write Hugo games online (among several other types of game)!
• Tristano Ajmone put The Hugo Book online.  With Kent's permission, updates and fixes have been made, making it the most accurate version of the book available.
• Steps have been made to centralize the Hugo code base, and discussion of Hugo's future is underway.

So yes, exciting times.

Anyhow, to warn you, I don't really see myself updating Roodylib or this blog in the future with the same frequency as I did in years past.  While nothing is ever perfect, this version is basically the culmination of years-spanning intentions, and now that I've reached this point, it's likely that I'll move on to something else- whether that is back to game-writing or something else entirely, we shall see.

progress report

In recent months, I've seen Hugo mentioned in some unexpected places, and Dannii Willis is working on a glk interface Hugo web interpreter (to which I say, the more the merrier!).  The downside of this is that it has made me more frustrated with the ways Roodylib might be unaccommodating to beginners.  I've decided against my previous "throw it all in" philosophy for Roodylib and have been moving whatever code I can to extensions, and taking out code I'm not 100% satisfied with altogether.  I just want the heart of Roodylib as simple and readable as possible.

Unfortunately, this calls for even more updating to the documentation, so that'll be yet another process.  As much as I'd like to get a new Roodylib out the door, the interpreter opcode side of things isn't as hammered out as I'd like it to be, either, so it'll probably be some time yet.

Just to make this post fun, I thought I'd share some Hugo games hard-compiled with the HugoJS behavior that should work by default once the opcode stuff is all working right.

The first game is "The Hugo Clock" by Jason McWright.  Written for a Hugo minicomp we held a handful of years ago, it's a good example of a game that, despite lacking deep narrative machinations, hits that sweet spot of just being fun to poke and prod around with: The Hugo Clock

The second game, "ScepterQuest", was originally written with Hugo 1.2, back in Hugo's DOS-only days.  I ported it myself as a coding exercise some years ago (and because I find the game very silly and funny), but I intentionally never uploaded it to the IF Archive.  Still, check it out, and if you like it, go ahead and break out DOSbox and try out the original: SceptreQuest

In other IF news:

• Bob Bates' Thaumistry: In Charm's Way hit its kickstarter goal.  People can still donate through PayPal to hit the stretch goals.
• Jesse McGrew released version 0.8 of his ZILF compiler.  I'm well overdue to post to my other blog, ZIL Crazy After All These Years, but I'm really happy with how ZILF is coming along.
• Andrew Plotkin and Chris Spiegel have been looking for official platform builders for the Gargoyle interpreter, and any steps toward more timely updates of one of the most popular offline IF interpreters are greatly appreciated!
• The 2017 Spring Thing competition is just about to start.  I'm so glad that Aaron Reed has kept it running all these years.
• One of my favorite videogame publishers, Devolver Digital, released a compilation of text adventures from a game company called No Code.  It's called Stories Untold.  Unfortunately, even with my settings set way low, it runs too slowly on my computer (I'm not so nostalgic for early 80s text adventures that I want to bring back waiting minutes between commands) but I look forward to trying it again if I ever get a nicer computer.

Apologies to all of the cool IF news things I am missing!

roody labs

My latest bit of Hugo coding has been comprised of distracted yet productive meandering.

*  * *

Roodylib takes several important Hugo library routines and breaks them up into several routines for the sake of readability and modification (I'd rather provide authors with a method to change just the important thing instead of having to switch out the entire 126 lines of FindObject).  Of course, one side effect of this is that it greatly increases the starting number of routines in any given game.  The Hugo default max limit of routines is 320.  Now, this is a changeable, soft limit, but it worries me when a Roodylib game creeps up to that 320 limit; I don't want it to get to the point where my beginning advice to new authors includes how to raise the routine limit.  They have enough things to take in at that point.

DescribePlace, the routine responsible for room descriptions, was one that I split into several routines so authors had the ability to change the order in which things are listed.  To combat the creeping-routine problem, I redesigned the routines as objects with one routine to execute them.  It's actually been done for a while, but I didn't mention it because it's kind of a useless modification, all things considered, and the number of routines probably only bothers me.

* * *

I also modified the "shell" files included with Roodylib to automatically compile with the -s switch.  This provides compilation statistics like number of objects, routines, etc.  I always find this useful; I figure others will, too.

* * *

Sir Jiz has a lot of timers in his game- most of which he's been handling with the room each_turn property.  I usually do this by keeping the number-of-turns-spent-in-room in the misc property so the each_turn property routine can have some "select self.misc" code and go from there.  Long story short, Jiz was getting sick of reminding himself where the best place to set the misc value was.  I figured, ah, yeah, I guess Roodylib could do something about that.  So now there's a RoomTurnCount thing so nobody has to mess with misc anymore.

select RoomTurnCount

case 0

"Runs as soon as player enters room."

case 1

"Runs after first turn."

case 2

"And so on."

Although maybe I should have pushed him towards using a daemon instead.  Ah, well, always nice to have multiple ways to do things.

* * *

Some months ago, someone expressed interest in there being a Hugo Comp this year, so I tried to gauge interest from everybody at the joltcountry.com forums and throw some theme ideas around.  I had been in the middle of playthrough of "Spellcasting 201: The Sorcerer's Appliance" so I figured a magic-themed comp would be fun.  I even offered to throw together an extension for authors to use so they wouldn't have to write the magic system themselves.

I started off by looking at Cardinal Teulbachs' (yes, back in the olden days, we used to have an IF community member named "Cardinal Teulbachs") take on a spellcasting system.  His code strictly prohibited modification, though, so I was going to have to write my own thing by scratch (I don't always honor code licenses, but hey, this time I did).

I think I came up with the base design for my system, but I decided I needed to refresh my memory on how spells worked in the Enchanter trilogy (how many memory slots the player has, if all spells can be memorized multiple times- stuff like that).

The funny thing, though, is that I found myself super distracted by the fact that you could not read dropped scrolls in Teulbachs' sample game which was a departure from expected Infocom behavior.  Just the same, it made some sense, and I decided it'd be nice to write an object class system for objects that had to be held to be read (like a pamphlet) while still allowing for ones that don't (like a billboard).

More difficultly, I wanted to do this on the grammar level so all "You don't have that." messages didn't use up a turn.  Truthfully, it's not easy to have varied behavior when it comes to held/unheld verbs.  I knew that when I did get around to writing this system, I'd have to use my Roodylib "routine grammar helper" system.

I finally got around to looking at this problem yesterday.  It was one of those funny times where you return to an old problem a bit smarter and almost resent the obligation to improve your solution ("WHY CAN'T I JUST STAY STUPID FOREVER?").

First, to help me design the readable object classes, I looked over some grammar classes I had made previously for containers that are emptied in different ways (those that had to be held vs those that don't and so forth).  In my testing, though, the "empty" code wasn't working, and for a while there, I thought maybe I had broken FindObject somewhere along the way (and getting FindObject to do the things I already have it do was a scary, confusing journey so I wasn't looking forward to working on it again).

It turned out that a call to FindObject from AnythingTokenCheck (which itself is called from within FindObject) should have used the "recurse" argument.  Whew!

I also decided that half of my original "routine grammar helper" code was unnecessary.

But anyway, that's all working better now, although I might redesign the routine grammar helper again, possibly to use attributes instead of variable masking.

And, oh yeah, if you were curious, no, I don't think the Hugo Comp is happening.  That discussion fizzled out pretty quickly.

* * *

STATUSTYPE is a global variable that determines what kind of information is displayed in the upper right corner of the status window.  One of the several options displays a game clock like in the game Deadline.  Since the HoursMinutes routine used to print the time could also do military time, a while back, I added a STATUSTYPE value that provides a military time clock (like in Border Zone).   It kind of bugged me that the code didn't have an easy way to switch between the military time with colon and without.  While easy enough to provide a choice for the author, I really wanted it to be as unobtrusive as possible because, really, there's like no chance anyone is going to write a military time game again, and it'd just be embarrassing to show that I spent much time doing some sort of time-configuration system for a feature no one would ever use.  I ended up with just going with a #set NO_MILITARY_COLON flag.

* * *

There are a couple other things, but I'm getting tired of writing.  Anyway, probably will try to put out a Roodylib update within the next couple weeks and then maybe do a round of uploading-stuff-to-the-IF-archive.  Then, maybe, write some IF?  (gasp)

Summertime Frolicking

One of my favorite things about frolicking is how quickly I get sick of it and want to return to my projects.  That said, August is lousy with birthdays among my friends and family (of course, I mean that in the quantitative, Catcher in the Rye sense and not the qualitative one), and I've still got some pool parties, a "pedal tavern," and possibly a trip to the Renaissance Faire in my future.

Still, I can't wait to submerge myself in something Hugo again.  Earlier this week, I made some progress in my most recent problem; I had noticed how horribly broken the baby-naming code was in my silly, nonsensical game, "Baby Uncle New Year," and I wanted to fix it up.

I was hoping my new code would be general enough that I could easily throw it into Roodylib for everybody to use, but it ended up being too specifically purposed.  When I get back to coding, writing that general purpose system will probably be my next task.

Ideally, I'd like it to do these things:

1.  If the game is being played on an interpreter that supports Hugo's timing system (and accessibility mode is not turned on), it would throw up a floating window like in my game "The Halloween Horror" and use my "fake prompt" code to capture the input and writing it straight to an array.
2. If the game is being played on a glk interpreter or has accessibility mode turned on, it has a prompt in the main window.  Actual Hugo prompts are tricky because unless the text is within quotation marks, Hugo can only keep track of one unrecognized word.  I'll have to find a tactful way to instruct the player accordingly.
3. Both of these will result in a, "'<blah>'? Is that correct?" response so the player can double-check how it was received.  Even with whatever nudging I give, the main window Hugo prompts have a fair possibility of being wrong, like if the player used any of the "removal" words ("a", "an", "the", "some", "of") that Hugo automatically drops from input lines.
4. Include an option to write all unrecognized words to the game dictionary and apply them to an object.

At least one game in progress by another person uses my "fake prompt" code so I figure this system could be useful to others as well.  Besides this, I need to reacquaint myself with my Hugo "to do" list and see if there's anything else I'd like to add before the next Roodylib release.  I also have some real world research I want to do on one of my game ideas.

Here's to ending 2016 with a little more Hugo in the world!

Roodylib 4.1.2

I'm several months late in helping someone code a scene in their game, so me being me, that means I went and got Roodylib ready for a new release!  SORRY, JIZ!

The three main elements of this new update are:

• Incorporated the accessibility code mentioned one or two posts back into Roodylib and made them available by default.  I may add another accessibility feature at some point- some kind of spelling system for uncommon words (as discussed on the intfiction.org forums)
• Code supporting Nikos Chantziaras' Hugor opcodes system
• Incorporated "newmenu.h" into Roodylib so one doesn't have to include the extra file.  I added mouseclick support to menus sometime within the last handful of months, too.

Roodylib 4.1.2

Latest Hugo Notepad++ Bundle

Hugo Notepad++ Add-on

Updates in Accessibility

I spoke about accessibility in the last post.  It was brought to my attention that NVDA, another screen reader, does in fact work with some Hugo interpreters.  This was exciting news as I could finally test my new accessibility code.

For one thing, I was pleased to discover that my option to disallow screen-clearing was in fact justified; in-game screen clearing occasionally causes NVDA to lose track of the text.  For the meantime, I'm taking the "clear every turn" option out until I learn of screen reader software that might work with.  I'm also pretty pleased with the switching-the-prompt command; "Your command..." sounds a lot better than "greater than."

If anyone wants to try NVDA out themselves, you can download it at http://www.nvaccess.org/download/

You can get the add-on someone wrote for several IF interpreters at http://jeff.tdrealms.com/Add-Ons/IfInterpreters-1.1.nvda-addon

I found finding the place to install the add-on in NVDA was a bit of a search, but dig enough, and you'll find it.

The add-on specifically targets the winglk Hugo interpreter which can be downloaded at http://ifarchive.org/if-archive/programming/hugo/executables/hugov31_winglk.zip

Lastly, download any of the following games, compiled with Roodylib's new accessibility code.  Now, they're not my games (I'd much rather have people play something good) so please don't redistribute; these are just for personal use.

Spur: https://drive.google.com/file/d/0B_4ZXs4Z_yoWOFg2b2FUZVBXeTQ/view?usp=sharing
Guilty Bastards: https://drive.google.com/file/d/0B_4ZXs4Z_yoWNG5TX1BMem9TWmc/view?usp=sharing
Down: https://drive.google.com/file/d/0B_4ZXs4Z_yoWZkVtUndXQ0VUcGs/view?usp=sharing

Accessibility commands are listed if someone types the suggested "INFO" command.

Moving your mouse reverts NVDA to "hover over words" mode, so for best uninterrupted behavior, leave your mouse alone.

These accessibility commands will be on by default in future releases of Roodylib.

Roodylib non-progress and a ZIL update (gasp!)

Since the last Roodylib update, I've been working on a couple things.  Unfortunately, none of them have been very successful which is especially unfortunate because I noticed a capitalization bug I introduced into the last Roodylib release (only seen when someone UNDOs after taking their inventory) and it'd be nice to put out an official release as soon as possible.

Plural Class Stuff

I have a folder of little bits of Hugo code to specifically test this or that functionality.  For example, since I haven't really used Hugo's plural class support much in my own games and WIPs (I have used it a couple times but nothing that'll give the code a good workout), I made a dishwashing simulation where the game begins with 3 dirty dishes and as you wash them, they turn into clean dishes.  Already this little bit of code has been useful to me since it helped me catch a typo in the original plural class code, but it never has been working perfectly so I put it aside to look at again one day.

I took that closer look a few weeks ago; actually, before I started looking at the code again, I thought there might even be a chance that my tweaks to the plural class code since then might have resolved the original issue.  Sadly, no, this was not the case, ha.

The issue was that the game wasn't recognizing the references to the clean dishes once there were 2 or more of them.  It turned out that, just how the attachables system makes the assumption that there is only one attachable in scope, the plural class system makes the assumption that there is only one item in scope with the same noun property.

Hugo's plural class system is a complicated bit of pre and post engine-parsing parsing.  Trying to fix the problem through little code tweaks was unsuccessful in the end, so I think I'll need to re-design the whole thing if I really want it to work.  Like the only-one-attachable-in-scope thing, I don't think I'll revisit this problem until someone's game in progress requires me to do so (or I get really really bored).

Accessibility

Last month, there were a couple posts to the intfiction.org forum by people who use screenreaders to play IF.  I had actually been wanting to get in touch with someone about that for months; at one point, I tried to write to the Audyssey mailing list but I think I used the wrong link and felt too self-conscious to keep trying, haha, so I was excited to finally have some people to talk to.

One got back to me right away, and I began working on extra Hugo commands to present the screen as nicely as possible to screenreaders.  Eventually, I decided the wisest thing was to test it myself, so I installed JAWS for the first time in 10+ years and was painfully reminded that no Hugo interpreters- not even the glk one- work with it.

Still, some interesting threads came up in my research:

http://www.inthecompanyofgrues.com/?p=220 (and the thread discussing it) - Makes several interesting points about accessibility and was very useful in reassuring me about the usefulness of some of my ideas.

http://www.intfiction.org/forum/viewtopic.php?f=6&t=8690&start=0 - Lists interpreters that already work well with screenreaders.  Seems like the main deciding factor is whether text is selectable in the main window (without going to scrollback).

So yeah, my Hugo code is pretty useless until there's a Hugo interpreter that works with screenreaders (technically, there's a 16-bit simple DOS interpreter that should work but I've found that it crashes for larger games), so that project, too, goes on the backburner for a while.   Possibly I'll implement it in ZIL in the meantime.

ZIL!

Speaking of ZIL, I wanted to end this post with at least one tale of success.  I was quite excited to see Jesse McGrew's ZILF 0.7 release.  It comes with his complete re-implementation of Adventure and has examples of the kind of character command code I need for my ZIL project ideas.

As I did for Hugo, I made a notepad++ ZIL distribution with some syntax highlighting and buttons for project creation, compiling, and running games.  To be totally honest, I don't always keep the same kind of functions the same color, changing it up a bit for readability, but if people find that confusing, of course, feel free to edit it to your heart's desire (and I'd be interested to see what you do with it).

ZIL notepad++ screenshot

 Unfortunately, these standalone versions of notepad++ don't seem to work for people who have notepad++ already installed (and are storing settings in user settings).  At some point, I may write instructions on how to integrate these things into your own notepad++ installation, but it's complicated as the Customize Toolbar plugin I use to provide buttons doesn't currently allow for different-buttons-based-on-the-currently-open-file.

Anyhow, if you'd like to play around with it, you can get it here.

Announcing Roodylib 4.1.1 - the "Information" release!

So, a couple months ago, I had recently added a donation button to this blog.  A generous soul jumped on that right away.  I decided the best way I could pay him back was to improve the Roodylib documentation so people wouldn't have to dig through "roodylib.h" for all of the hidden features.

It took much longer than I had predicted, but I like to think that the final product is nicer than I originally foresaw, too.  Plus, writing the documentation led to a couple updates in Roodylib itself, so all in all, I'd say this was a good deal!

Download Roodylib 4.1.1 here

or...

Download the latest Hugo Notepad++ bundle

Changelog stuff

        * updated - BeforeRoutines, AfterRoutines, RepaintScreen, DoInventory

* some additional HugoFix object tree organization, a HugoFix recording playback helper, $mp tweak

* made automatic-door-opening look nicer

* if a key_object is set quiet, it won't automatically open a door until after it has been explicitly used

* USE_SCOPE_REACT for checking react_before/after of scope objects

* changed PreParseError to BeforeParseError

* changed USE_SMART_PARENTS to SMART_PARENT_DIRECTIONS

* attachable behavior improved, especially with regards to pushable things

* USE_JUKEBOX, USE_CONFIG_SYSTEM added

* better DescribePlace configuration support

* cleaned up some rollable-objects code

* reworked how some FORMAT & LIST_F and indentation stuff works

* updated documentation

documentation update

So, work started off slower on the documentation than I predicted, but I'm pretty happy with the styling and approach I've come up with (lots of picture examples to show options in action with a little bit of IF theory thrown in here and there, too).  It'll probably be weeks before I'm finished, I think- and I'll probably tweak fonts and stuff to make it look as nice as possible- but I figured I'd share what I've done so far.

Check out the start of the new Roodylib documentation!

Suggestions are welcome.

Configuration Files

I don't remember what prompted it, but something got me thinking about configuration files in Hugo and how I never perfectly designed a way to detect if an interpreter fully supports them.

See, the FILE_CHECK constant-checking method described in the Hugo manual doesn't work with Gargoyle.  Not only that, but Gargoyle can read configuration files- just not write to them- so if a configuration file has been created by another interpreter, previously, the game could easily be tricked into thinking everything is working fine.  Adding even more complication is that configuration-file-writing does work in the glk Hugo interpreter (even though no one ever uses that one) so I couldn't just do a simple "minimal port"check.

So I brought my attention to this the other day.  Eventually, my fix for the problem involved using Hugo's system-time-catching functionality (along with Future Boy!'s time-handling routines) to take the current time, save it to the configuration file along with everything else, then read the time back from the configuration file.  Then it calculates the difference between the two times, and if it's longer than 5 seconds (I'm trying to account for really slow computers here even if a 2 second timer would probably still be playing it safe), it calls the configuration error routine (so a game like "the Halloween Horror" can quit out, as it relies on configuration files).

In other news

Herr Jizaboz finished his demo game about a tourist in North Korea.  I've helped him with it here and there.  I hope people get a big kick out of it!

A Day in DPRK

Also....

Looks like there was a Notepad++  update so I also updated the Hugo Notepad++ distribution.  You can get it here.

Formatting

In that last bout of Roodylib attachables improvement, playing around with the "Vault of Hugo" sample game made me check out some other things, too.  Specifically, I was reminded that Roodylib's doublespace formatting option worked imperfectly.  This is how it looked when it attempted the Vault of Hugo's "Object Room."

(there are no commands listed since it is the result of a recording playback)

As you can see, spacing is inconsistent, with no extra lines between the two items with short_desc's (and all of the non-short_desc-related objects are clumped together, too).

I set out to fix this- and not only that, as I also decided I wanted Roodylib to have an option for smart room descriptions if the player is in an object (I had gotten a test case of this working months ago but it still required some code clean-up and adapting to put it into Roodylib).

Not only this, but I also wanted to make sure that rooms printed properly with the LIST_F format option on.  This is the setting that does "tall" listings like those in Zork:

>look

West of House

You are standing in an open field west of a white house, with a boarded front door.

There is a small mailbox here.

The small mailbox contains:

  A leaflet

>

I can't remember how broke the alignment was before I started this latest wave of improvement.  Might have not been that broke, but with Hugo, "The small mailbox contains:" was indented once and the next line twice.  This was probably intentional, but to be honest, I prefer the Zork version.  Hugo also didn't capitalize the article for children like "A leaflet".  I've changed that, too, since again, I liked the Zork way.  If I had my druthers, I'd make both of these things optional but as it is, configuring DescribePlace to your needs is already going to be a bunch of global variable tinkering and flag setting.  Still, one day I might re-design the WhatsIn and ListObjects routines so they're much more configurable.

While I was at it, I also added my system for smarter listing when the player in a container in the room (it's possible to configure it to also do platforms, but it was hard to come up with a wording that'd work for all cases- if you're on a chair, do you really want to describe all other objects in the room as "off the chair"?).

FORMAT global set to DESCFORM_F and COOL_PARENTS flag set

FORMAT with LIST_F (you'll notice that I changed how Indent works with LIST_F just so the two systems use the same logic)

The cauldron and the grandstand listed are not in the original game.  I added them just to test the part of DescribePlace's code that lists the children of scenery items.

Now let's take a look at some of the behavior if the NEW_DESCRIBEPLACE flag is set.

NEW_DESCRIBEPLACE with doubles-pacing on

The new DescribePlace defaults to having children of scenery listed right away, right after children of parent-of-player.  I figured it's better for them to be closer to wherever they were mentioned in the room text.  Ideally, I'd have an extra check in there to list attachables-connected-to-scenery objects right up there, but I don't think that comes up enough to justify the extra work for now.

With double-spacing on, it only prints newlines (and the extra space) when it needs to.  All those extra spaces might look kind of ugly in that example right there (since that room has so many objects), but I'm fairly certain that it'll look quite nice in the average IF game.

I'm pretty happy with the different options I've given the DescribePlace system although the extra settings I've created could probably use some finessing.

Right now, there are the following additional Roodylib options:

• Set the "COOL_PARENTS" flag (this gives the room better relative text when the player is in a container in the room)...  My gripe about this name is that it's close to my SMART_PARENTS flag (which gives better responses when a player tries to go in an unavailable direction while, like, sitting in a chair or something).
• Give FORMAT the DESCFORM_I mask. DESCFORM_I gets rid of the extra new line before a room title is printed, based on Infocom layout (hence the I).  Just the same, the F in DESCFORM_F probably stands for "flag" so changing it to I is probably just confusing.
• Set the "NEW_DESCRIBEPLACE" flag.  This gives the extra functionality of the new DescribePlace code.  I'm pretty fine with this one.
• Give FORMAT the DESCFORM_D mask.  If the new DescribePlace system is on, this turns on double-spacing.

Beyond the probably-confusing names of my new masks and flags, I'm not sure I even want to expect new authors to know how to change this stuff- if I recall correctly, FORMAT masks are covered very briefly in the manual; pretty sure I learned most of what I know just by looking at hugolib.h.

I'd like to make it easier for authors by creating some routines that will set the game to the formatting they prefer, but even that is kind of a headache. *

* I was going to continue with the annoying aspects of trying to design and name helper routines, but I think I might have an idea I'd like to play with.  Stay tuned!

automatic door unlocking/opening

So, in posting that "Vault of Hugo" transcript the other day, I was reminded my dissatisfaction over the messaging in my first attempt at automatic door unlocking.  Here's the applicable part again:

>dig ground
You find a rusty iron key!
(Taken.)

>e
(unlocking the vault door first)
(with the rusty iron key)
Unlocked.
(opening the vault door first)
Opened.
It's pitch black in here. Stumbling around in the dark isn't such a hot idea: you're liable to be eaten by a grue.

>

Now, the automatic-door-unlocking was one of the first things ever added to Roodylib so, of course, I've learned a lot since then and I thought it was worth taking another swing at it.  Here is a transcript of what would happen now:

>dig ground
You find a rusty iron key!
(Taken.)

>e
(unlocking the vault door with the rusty iron key first)
Unlocked.

(and then opening it)
Opened.

It's pitch black in here. Stumbling around in the dark isn't such a hot idea: you're liable to be eaten by a grue.

>

As you can see, it now combines information where it can, and I added some spacing to make it prettier.  The "(and then opening it)" message was especially tricky to do, but I think the code I threw together should work well enough (it relies on checking the parser_data[PARSER_STATUS] value, and I don't see that changing anytime soon).

I also threw in an option where, if the key object is set quiet, a regular >UNLOCK DOOR asks the player to be more specific or in something like the instance above, does:

>dig ground
You find a rusty iron key!
(Taken.)

>e
The vault door is locked.

>unlock door with key
Unlocked.

>lock door
(with the rusty iron key)
Locked.

>e
(unlocking the vault door with the rusty iron key first)
Unlocked.

(and then opening it)
Opened.

It's pitch black in here. Stumbling around in the dark isn't such a hot idea: you're liable to be eaten by a grue.

>

 I figure there might be instances where you want the player to figure out which key is correct.  After being used correctly once, it'll do automatic unlocking/locking no problem from then on.

Anyhow, I wanted to put the feature there, but I doubt many people will use it so I won't even go to the trouble of aliasing quiet to another more-apt attribute name to be used in these instances.

Attachables

In preparation of the next official release of Nikos Chantziaras' Hugor, I've been playing through Kent Tessman's Future Boy! again as it is basically the only Hugo game in existence that uses Hugo's movie feature.

In one late scene, there is a rope and a wheelbarrow (the wheelbarrow isn't especially important- I get the feeling it mostly exists just to show off Hugo's capabilities) and I found some inconsistent behavior.  This got me looking at Hugo's attachables code, in particular how it works with pushable items (like Roodylib's USE_ROLLABLES switch).

It took a couple attempts, but I eventually got Roodylib working as I would like it.  To test it out, I made the mine car in "Vault of Hugo" a pushable object.  Here is a transcript with the new code in place:

You brace yourself, check your flashlight, and, with source code in hand, prepare to enter...

THE VAULT OF HUGO
An Interactive Example
Hugo v3.1 / Library 31031

Outside a vault
Kind of that 1930s, Bela Lugosi, graveyardy motif at work here. It's a pretty creepy place. Directly in front of you is the giant door to an even more giant vault. Above the door hangs a rusty sign.

>dig ground
You find a rusty iron key!
(Taken.)

>e
(unlocking the vault door first)
(with the rusty iron key)
Unlocked.
(opening the vault door first)
Opened.
It's pitch black in here. Stumbling around in the dark isn't such a hot idea: you're liable to be eaten by a grue.

>turn on light
A beam of serviceable light appears from your flashlight.

Inside the vault
Standing in the middle of this dimly lit chamber, you realize that just maybe you should've splurged on a more expensive flashlight. You also realize that there are four ways you can go: a marble archway to the north, a muddy cave opening to the east, an oak door set in a brick frame to the southeast, and west back outside where you came from.
An old mine car sits abandoned to one side.

>push car n
Something seems to be stopping the mine car from rolling.

>look under car
You find a big rock lodged between the wheels, which you manage to wrestle out of the way.

>push car n
You push the mine car over to the...

Object Room
This room contains a collection of objects with different properties, attributes, and associated routines in order to give some idea of basic object design. In addition to the various furnishings, you notice a dartboard hanging on one wall.
A large drum--not the musical kind--is here. Attached to it is a warning note.
Lying in the corner of the room is a non-descript, unnamed object.
An old mine car sits abandoned to one side.
A wooden chair, a card table, a transparent box, and an opaque box are here.
A deck of playing cards has been placed appropriately on the table.
Also sitting on the card table are three shiny gold coins and a pad of paper.
A green dart is sticking out of the old dartboard.
A heavy rope is tied to the wooden chair.

The mine car slows to a stop.

>tie rope to car
You tie the heavy rope to the mine car.

>push car s
You can't move the mine car while the heavy rope is still tied to to the wooden chair.

>enter car
You get in the mine car.

Object Room, in a mine car
This room contains a collection of objects with different properties, attributes, and associated routines in order to give some idea of basic object design. In addition to the various furnishings, you notice a dartboard hanging on one wall.
The old mine car is loaded with a pencil.
A large drum--not the musical kind--is here. Attached to it is a warning note.
Lying in the corner of the room is a non-descript, unnamed object.
A wooden chair, a card table, a transparent box, and an opaque box are here.
A deck of playing cards has been placed appropriately on the table.
Also sitting on the card table are three shiny gold coins and a pad of paper.
A green dart is sticking out of the old dartboard.
A heavy rope is tied to the wooden chair and the mine car.

>drive s
You can't go anywhere while the heavy rope is still tied to the wooden chair and the mine car.

>out
You get out of the mine car.

>untie rope from chair
You untie the heavy rope from the wooden chair.

>push car s
(with the heavy rope tied to the mine car)
You push the mine car over to the...

Inside the vault
Standing in the middle of this dimly lit chamber, you realize that just maybe you should've splurged on a more expensive flashlight. You also realize that there are four ways you can go: a marble archway to the north, a muddy cave opening to the east, an oak door set in a brick frame to the southeast, and west back outside where you came from.
A big rock and a mine car are here. The old mine car is loaded with a pencil.
A heavy rope is tied to the mine car.

The mine car slows to a stop.

>enter car
You get in the mine car.

Inside the vault, in a mine car
Standing in the middle of this dimly lit chamber, you realize that just maybe you should've splurged on a more expensive flashlight. You also realize that there are four ways you can go: a marble archway to the north, a muddy cave opening to the east, an oak door set in a brick frame to the southeast, and west back outside where you came from.
The old mine car is loaded with a pencil.
A big rock is here.
A heavy rope is tied to the mine car.

>drive n
(with the heavy rope tied to the mine car)

Object Room, in a mine car
This room contains a collection of objects with different properties, attributes, and associated routines in order to give some idea of basic object design. In addition to the various furnishings, you notice a dartboard hanging on one wall.
The old mine car is loaded with a pencil.
A large drum--not the musical kind--is here. Attached to it is a warning note.
Lying in the corner of the room is a non-descript, unnamed object.
A wooden chair, a card table, a transparent box, and an opaque box are here.
A deck of playing cards has been placed appropriately on the table.
Also sitting on the card table are three shiny gold coins and a pad of paper.
A green dart is sticking out of the old dartboard.
A heavy rope is tied to the mine car.

>get rope
Taken.

>push car s
To walk, you will have to get out of the mine car. Otherwise, try "roll" or "drive" and a direction.

>drive s

Inside the vault, in a mine car
Standing in the middle of this dimly lit chamber, you realize that just maybe you should've splurged on a more expensive flashlight. You also realize that there are four ways you can go: a marble archway to the north, a muddy cave opening to the east, an oak door set in a brick frame to the southeast, and west back outside where you came from.
The old mine car is loaded with a pencil.
A big rock is here.
The heavy rope that you're holding is tied to the mine car.

>out
You get out of the mine car.

>push car n
You push the mine car over to the...

Object Room
This room contains a collection of objects with different properties, attributes, and associated routines in order to give some idea of basic object design. In addition to the various furnishings, you notice a dartboard hanging on one wall.
A large drum--not the musical kind--is here. Attached to it is a warning note.
Lying in the corner of the room is a non-descript, unnamed object.
A wooden chair, a card table, a transparent box, an opaque box, and a mine car are here.
A deck of playing cards has been placed appropriately on the table.
Also sitting on the card table are three shiny gold coins and a pad of paper. The old mine car is loaded with a pencil.
A green dart is sticking out of the old dartboard.
The heavy rope that you're holding is tied to the mine car.

The mine car slows to a stop.

>enter car
You get in the mine car.

Object Room, in a mine car
This room contains a collection of objects with different properties, attributes, and associated routines in order to give some idea of basic object design. In addition to the various furnishings, you notice a dartboard hanging on one wall.
The old mine car is loaded with a pencil.
A large drum--not the musical kind--is here. Attached to it is a warning note.
Lying in the corner of the room is a non-descript, unnamed object.
A wooden chair, a card table, a transparent box, and an opaque box are here.
A deck of playing cards has been placed appropriately on the table.
Also sitting on the card table are three shiny gold coins and a pad of paper.
A green dart is sticking out of the old dartboard.
The heavy rope that you're holding is tied to the mine car.

>drive e
You can't roll that way.

>drive s

Inside the vault, in a mine car
Standing in the middle of this dimly lit chamber, you realize that just maybe you should've splurged on a more expensive flashlight. You also realize that there are four ways you can go: a marble archway to the north, a muddy cave opening to the east, an oak door set in a brick frame to the southeast, and west back outside where you came from.
The old mine car is loaded with a pencil.
A big rock is here.
The heavy rope that you're holding is tied to the mine car.

>drive e

Character Room, in a mine car
The Character Room provides a couple of good examples of character scripts and events. Exits are north and west.
The old mine car is loaded with a pencil.
A burly guard is here.
The heavy rope that you're holding is tied to the mine car.

The guard lifts his big boot up to the mine car and gives you a firm shove back out the door. "Not in that thing, you don't, pal!"

Inside the vault, in a mine car
Standing in the middle of this dimly lit chamber, you realize that just maybe you should've splurged on a more expensive flashlight. You also realize that there are four ways you can go: a marble archway to the north, a muddy cave opening to the east, an oak door set in a brick frame to the southeast, and west back outside where you came from.
The old mine car is loaded with a pencil.
A big rock is here.
The heavy rope that you're holding is tied to the mine car.

>drop rope outside car
Dropped.

>drive e
(with the heavy rope tied to the mine car)

Character Room, in a mine car
The Character Room provides a couple of good examples of character scripts and events. Exits are north and west.
The old mine car is loaded with a pencil.
A burly guard is here.
A heavy rope is tied to the mine car.

The guard lifts his big boot up to the mine car and gives you a firm shove back out the door. "Not in that thing, you don't, pal!"

Inside the vault, in a mine car
Standing in the middle of this dimly lit chamber, you realize that just maybe you should've splurged on a more expensive flashlight. You also realize that there are four ways you can go: a marble archway to the north, a muddy cave opening to the east, an oak door set in a brick frame to the southeast, and west back outside where you came from.
The old mine car is loaded with a pencil.
A big rock is here.
A heavy rope is tied to the mine car.

>out
You get out of the mine car.

>push car e
(with the heavy rope tied to the mine car)
You push the mine car over to the...

Character Room
The Character Room provides a couple of good examples of character scripts and events. Exits are north and west.
A burly guard is here.
A mine car is here. The old mine car is loaded with a pencil.
A heavy rope is tied to the mine car.

The mine car slows to a stop.

The guard lifts his big boot up to the mine car and gives you a firm shove back out the door. "Not with that thing, you don't, pal!"

Inside the vault
Standing in the middle of this dimly lit chamber, you realize that just maybe you should've splurged on a more expensive flashlight. You also realize that there are four ways you can go: a marble archway to the north, a muddy cave opening to the east, an oak door set in a brick frame to the southeast, and west back outside where you came from.
A big rock and a mine car are here. The old mine car is loaded with a pencil.
A heavy rope is tied to the mine car.

>get rope
Taken.

>e
(with the heavy rope tied to the mine car)

Character Room
The Character Room provides a couple of good examples of character scripts and events. Exits are north and west.
A burly guard is here.
A mine car is here. The old mine car is loaded with a pencil.
The heavy rope that you're holding is tied to the mine car.

The guard lifts his big boot up to the mine car and gives you a firm shove back out the door. "Not with that thing, you don't, pal!"

Inside the vault
Standing in the middle of this dimly lit chamber, you realize that just maybe you should've splurged on a more expensive flashlight. You also realize that there are four ways you can go: a marble archway to the north, a muddy cave opening to the east, an oak door set in a brick frame to the southeast, and west back outside where you came from.
A big rock and a mine car are here. The old mine car is loaded with a pencil.
The heavy rope that you're holding is tied to the mine car.

>n
(with the heavy rope tied to the mine car)

Object Room
This room contains a collection of objects with different properties, attributes, and associated routines in order to give some idea of basic object design. In addition to the various furnishings, you notice a dartboard hanging on one wall.
A large drum--not the musical kind--is here. Attached to it is a warning note.
Lying in the corner of the room is a non-descript, unnamed object.
A wooden chair, a card table, a transparent box, an opaque box, and a mine car are here.
A deck of playing cards has been placed appropriately on the table.
Also sitting on the card table are three shiny gold coins and a pad of paper. The old mine car is loaded with a pencil.
A green dart is sticking out of the old dartboard.
The heavy rope that you're holding is tied to the mine car.

>

So, if you read carefully, you may have noticed that it mentions the attachables if the rope is being dragged or pulling something, but it doesn't if the player is just holding it (I also added some code so held attachables tied to something in the room are mentioned in the room's description).

My new code might not work in every situation (in fact, I can think of at least one instance in which it won't), but attachables are so rarely used in any case; if the day comes that an author codes something that doesn't work with the new code (specifically, the attachable would have to be tied to something in a container and the player would have to GO in a direction that leads to a locked door or something), I'll be happy to help them tweak their code so that it works.

Interestingly, playing around with "Vault of Hugo" inspired me for what I'd like to work on next, too, which is smarter room descriptions when the player is in a container or on a platform.  I've successfully coded that in the past so it's mainly a case of integrating it into Roodylib as cleanly as possible.

Roodylib 4.0 and Hugo Notepad++

So, official Roodylib 4.0 is out!  Here is my announcement from the couple places I posted about it:

"Roodylib," my collection of updates to the Hugo library files, just had its 4.0 update. I feel that it's come a long way and has plenty of nice bug fixes and added functionality. I'd hope that any Hugo author checks it out. I've uploaded it to the IF Archive (should be in "unprocessed" right now), but you can always download the latest official version here, too: https://goo.gl/0s67c4

Windows Hugo users new and old may also be interested in a Notepad++ package I've put together for Hugo (this seems allowable by its licensing as it only insists that info remains intact for finding the official Notepad++ site and I did not delete any of the included readme's). It adds several toolbar buttons for easy compilation and running games, and it handles directory management (one of the trickier things, IMO, for the budding Hugo author). Best of all, it's a standalone program so it can be put on a USB stick and carried from computer to computer. Download Hugo Notepad++

As you can see, I didn't really go into new features and fixes.  For that, you'll want to take a look at the changelog text file in roodylib_suite.zip or even look at all of the new comments in roodylib.h.

I already have plenty of ideas for the next Roodylib release.  Some are:

• Overhaul the entire pronoun system. I was going to do this for 4.0, but when I polled the public, I found there were too many competing theories on how pronouns should work. Instead of trying to sort it out all now, this task has been moved to "someday."
• Add some commands with accessibility in mind (specifically, for the visually impaired).  One thought is a "STATUS" command that reiterates the information that is displayed in the status bar.  Another idea is a "PROMPT" command to change the prompt for people with text-to-speech software (something like >PROMPT "What now?"  so the prompt is "What now?" instead of ">").
  
  This idea has actually been on my mind for months, and I've tried to get in touch with the visually-impaired gaming community for their suggestions but my attempts did not work.  Luckily, a thread about this showed up on the intfiction forums, and one fellow in particular is going to research the issue to find out what more can be done.  I'll re-visit this idea then.
•  I'd like to add FakePrompt to Roodylib, with some extra routines to automatically draw windows for whatever question is being asked (FakePrompt is a cool way to get the exact thing a player types without having to try to train them to put it in quotation marks).
• I'd like to also just incorporate a handful of other extensions into Roodylib, just so authors don't have to go searching around for too many things every time they start a new project.  Much easier to just add a flag to their code, I would think.
• It's not Roodylib, but I also need to re-visit Hugo By Example and update a ton of its pages.  The whole "replacement routines" category is pretty much what turned into Roodylib, and it'd probably be better to just have a nice Roodylib section where I explain how things work better.  That and just general updating all around.

So, I have all of those ideas, but I'm hoping to ignore them all for a while and spend some time on my own games.  I really neglect them when I have Roodylib things to work on, and it'd be good if I made some progress.  We'll see how it goes!

Roodylib developments

So, since the last official release of Roodylib, I've somehow managed to get sucked into a ton of tweaking-the-parser type stuff, things that I didn't really even see myself taking a look at just a couple months ago.  Most audaciously, I have moved some of the parsing gruntwork out of the Parse routine and into routines like FindObject and Perform (routines called after the parsing cycle is done).  There has been a lot of attention to the parsing of orders to NPCs.  I've also taken a stab at changing how the pronoun system works.  No longer will authors have to set the object global to "-1" just to make sure AssignPronoun (*) actually works like we want.

some parser responses under the new code

Now, for much of that, the responses are just what you'd expect out of a game, but, of course, that's mainly the point.

Overall, I like where this all is heading, but really, I've tweaked so many things that I could have introduced a ton of small bugs so I've been trying to get more testing of this new code than I usually ask for before an official release.  To do so, I have compiled several games with code available with the latest Roodylib code.  If interested, you can play them here (last updated November 14th with the new pronoun code):
https://drive.google.com/file/d/0B_4ZXs4Z_yoWalJZRGJIVElBbmc/view?usp=sharing

And feel free to take a peek if you are curious about new code.  Like I said earlier, most of the important stuff is in Parse, FindObject, ParseError, or Perform (and SpeakTo).

* My updated AssignPronoun uses a second argument in cases where the author wants to force the pronoun setting.

AnythingTokenCheck (new to Roodylib 3.9)

One of the things I was most excited to take a swing at in Robb Sherwin's CZK was a certain gun.  I had noticed when betatesting the game that >UNLOAD GUN dropped the ammo to the location.  This was the impetus for me to code my "new empty" system for Roodylib, which uses grammar sorcery and object classes to support objects with different emptying behavior- held items that empty to the ground, held items that empty to the player, unheld items that empty to the ground, etc.

So I was really happy to apply this code to CZK and see how it worked.  Unfortunately, it didn't work great!  See, my "grammar helper" stuff uses the "anything" grammar token, so any object is fair game.  Since CZK has several guns, >EMPTY GUN got a "Which gun do you mean, this gun or that gun or... ?"

Nothing else could be done about this at the grammar level so I had to look other places.  Luckily, FindObject determines what objects are available at any point, so it just took some digging and examination to find a good place to test against an AnythingTokenCheck routine.

            if not AnythingTokenCheck(obj)
            {
#ifset DEBUG
                if debug_flags & D_FINDOBJECT
                {
                    print "[FindObject("; obj.name; " ["; number obj; "], "; \
                    objloc.name; " ["; number objloc; "]):  "; \
                    "false (AnythingTokenCheck returned false)]"
                }
#endif
                return false
            }

Now let's look at the AnythingTokenCheck routine:

I check for a parent of obj just so we can dismiss any objects not currently in any room or container straight away, and then it can check against the location.  This way, >EMPTY will only be used against objects within scope.

Now, it doesn't seem like people generally use the anything grammar token for much other than ASK/TELL, but I still think AnythingTokenCheck will be useful whenever people do use them for other means, and now it's there to be replaced when people need it.

More Roodylib updates

First off, you may have noticed that I've been using pastebin lately for larger pieces of code.  I'm in the process of looking at gist (github's source code sharing thingy) and may switch over to that soon (it seems it does a better job of preserving tabs, although you can still keep pastebin's tabs if you click through to the raw format).  Ideally, eventually I'll have some kind of syntax highlighting on here, too.

Anyhow, let's talk about the things I've added to Roodylib!

New DoOpen Behavior

While taking a look at another look at Cryptozookeeper, that mailbox in the first room reminded me how much I don't like Hugo's default opening behavior.  Funny how my perfect example goes so far back, but I've always liked Zork's "Opening the <blank> reveals a..." text.

So I added this code to do it:

See, it even properly sets the pronoun now

Initially, I wanted the contents to be listed even if there was an object.after, so you could have something like:

"The mailbox squeaks open.

Inside the mailbox is..."

But since the original Hugo library didn't do that, I don't want to break all of the existing games out there more than I have to (of course, you can put the content-listing code in your object.after property routine, which is what those old games already do... it's just uglier).

As of right now, I'm thinking this will be a default behavior, but if people hate it, I'll put in some way to turn it off.

Anchorhead-style Auto-Examination of Picked Up Items

The other day, I was looking at the tips section of Hugo By Example, and I was reminded of this neat little thing that Anchorhead does that I wouldn't mind seeing in more games.  In the game, for certain items, if you hadn't examined them before picking them up, picking them up automatically examines them.  I think it's a cute time-saving device, and I figured there's no reason it can't be thrown into Roodylib for convenience.  To use it, all you have to do is set the AUTOMATIC_EXAMINE flag.

Here is the code that makes it work:

Actually, more Zork-style stuff

I also haven't liked how it's always on the author's shoulders to specify whether a container is open. Even though, in this day and age, all objects should have a long_desc anyway, I've updated DoLook so that if an object doesn't have one, openable containers automatically tell you if they are open or closed.

mailbox with object.after property routine and the above DoLook code

Pretty sure that's all I wanted to talk about for now! New Roodylib update coming soon!

Clothing Update Part II

So, all of this work with clothing made me go, huh, wonder if my old "AIF" code still works. That's the flag that allows you to take off all of your clothes easily.  I mean, I have no intention of writing any clothes-heavy (or clothes-light har har) games anytime soon, AIF or not, but the world model fetishist in me likes to know these things work.  Anyhow, I found that, no, my old code did not work (I don't think it ever worked perfectly; I just hadn't completely tested it correctly).

See, the big problem is that >REMOVE ALL should default to held items, but you can't give it a multiheld token because you still want REMOVE to work with things like platforms or containers, and if you give it just the multi token, it ignores held items completely (only working for held items when they are used specifically).

Initially, the only way I could get it to work was to use the USE_CHECKHELD flag.  The checkheld system moves everything the player is holding to a hidden container in the room, so everything is considered not held (but it marks them with the checkheld workflag so the library knows it WAS held), allowing all verbs to work as you'd like.

Still, I put in all of this work so that in the instances where REMOVE failed, I made WEAR and TAKE OFF also fail in the same way just so there'd be consistency. I also made some instances of DoGet get directed to DoTakeOff.  Anyhow, I'm sort of embarrassed by how much work went into it, but if you want to check it out for yourself, check out the routines ExcludeFromAll, ParseError (cases 3 and 9), and VerbHeldMode in the next official release of Roodylib (version 3.9).  It is really ugly code; I should probably clean it up, but I just don't want to even look at it for a while.

As it often goes, I figured out a nice, non-checkheld-system workaround the next day. It occurred to me that the following PreParse code would do the trick:

        if word[1] = "remove" and word[2] = "~all"
        {
            word[1] = "take"
            InsertWord(2,1)
            word[2] = "off"
            return true
        }
        return false

So, basically, >REMOVE ALL gets turned into >TAKE OFF ALL (since >TAKE OFF doesn't have the same grammar issues).  Of course, ParseError messages will say TAKE OFF instead of REMOVE, but I don't think most players would even notice it isn't intentional.

Right now, if the AIF flag is not set, all variations of TAKE OFF, REMOVE, or WEAR ALL get a "Please specify which item to <blank>."-type message.  If it's set, those commands work, although they work in slightly different ways, depending on whether USE_CHECKHELD is set.

(Of course, I jokingly call it the "AIF" flag, but an author could easily want such a flag in a roleplaying-flavored game where the PC changes his or her armor a lot.)