parser conflict checking improvement suggestions?

One of HugoFix's useful-sounding but rarely-used tools is the parser conflict checking command.  If you provide it with an object, it checks against the rest of the game and lists any other objects with shared adjectives or nouns.  If you don't provide an object, it checks every object in the game against every other object.

Anyhow, I like what it does, but here is the current format of the output:

Part of me thinks that it can be improved so it's easier to read, but I haven't yet put too much thought into it (which is why I'm throwing it out to y'all, ha).

go hug an object tree

The good news is, I've actually been writing game text lately. It's been slow going, but I basically have the opening to my new game done. It's coming together.

Now, this aforementioned game should have a couple color changes when its done, but I haven't decided on the color combinations yet. I was getting pretty sick of trying colors blindly. I thought somebody had made a utility that showed all of the available colors, but I couldn't find it so I coded my own: http://roody.gerynarsabode.org/notdead/colorthing.hex

While putting it together, for some reason, I was using HugoFix's "$ot" command to look at the object tree. All of the blank (no-named) objects due to my sample game's many windows bothered me, so I updated DoHugoFix's (and its companion routine, DrawBranch's) code so that the following usually-blank items now have a description:

1. Object 1 is now listed as the display object, which it should always be in a standard library-using game.
2. I gave the window_class object in "window.h" the type "window_class" so it can be checked for. Window objects get some special window-printing code.
3. All other unnamed objects are assumed to be replaced objects and are listed as such.

Note: Even unnamed objects are given a name by the compiler- the object's name within parentheses. Window objects are special in that they override this behavior by declaring their name as "" (window names are assumed to be window titles that need to be printed underneath the applicable window). So, other than window objects and replaced objects, it is unlikely (though not impossible, of course) that an object will be without a name.
 
So yeah, admittedly, that's not the most important roodylib addition I've ever written, but I like it enough.

Other than that, I noticed that Hugor is not handling the MATCH_FOREGROUND constant correctly, so the input color is coming out wrong on some games. I e-mailed Nikos about it, although maybe I've said something about it before as the e-mail gave me a little bit of deja vu (the only implication here is that I'm so disorganized).

Oh, well, progress is progress!

more debugging stuff

I updated the "roodylib suite" file today (roody.gerynarsabode.org/notdead/roodylib_suite.zip). First off, it fixes a couple things in the included shell file that were caught by Royce Odle (yes, the Royce Odle of Hugo by Example fame). Secondly, I threw in some more debugging commands that are available when the HUGOFIX flag is set. The first two commands are SCOPE and SCOPE ROOMS, meant to remind an author exactly what the player can "see" at any point. SCOPE just checks what is available in the current room, while SCOPE ROOMS makes a list for every room in the game. I previously had shared the code for these routines on Hugo by Example, but in priming it for roodylib, I made a couple things work nicer. The other thing I did was add a VERBTEST <object> command. This is my attempt to emulate an extension that Juhana Leinonen made for Inform 7. It automatically barrages an object with a bunch of library verbs, as a way to remind yourself of what kind of obvious commands a player might use.

So yeah, hopefully, those are somewhat useful.

Lately, I've admitted to myself that I should probably start looking into filing my extensions in some source code management system, but I haven't yet looked into my options. Hopefully some of them are pretty simple. Also, rights-wise, I probably can't choose some open source site for any extensions that use standard library code (like roodylib).