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.

using what I've learned

First off, hey, this is the 70th post of this blog. Not bad for something less than a year old, I think. Just goes to show how geeky I can be about taking apart an IF language!

Anyhow, I had been thinking that of all of my extensions, my NPC  pathfinding extension "findpath.h" probably had the most bad code, memory-wise, as it assigns every room two additional properties, which it clears between uses. That is not unlike my array-clearing code that caused that huge headache in Roodylib.

It's always interesting to look at code you wrote a year ago, as I found several parts of "findpath.h" useless. Among the changes:

• Previously, before writing the directions to be taken to the applicable character's script, I stored it in a property for that character (something that I was replacing the whole character class to give each character enough open slots). Since the code only sets up one path at a time, I figured I could just store the steps in a regular array that all characters would use. I think I wrote the original code at a time that I was especially fond of property arrays.
• The code used an included routine called PropertyCount that went through the given property array and counted how many elements had values. Now, this might still be useful somewhere, but the way my code used it, I found I could easily replace it with better usage of local variables. I also clipped some of my determining-which-exit-is-best code by using local variables better.
• Instead of clearing the room properties, I now determine whether or not a room has been counted yet by using the already_listed attribute. I can't say for certain, but I thought there was a chance that using an attribute might leave a smaller memory footprint.
• I replaced this finding-the-other-side-of-this-door-object code:
  

          if InList(a.d, between, a ) = 1
              a = (a.d).between #2
          else
              a = (a.d).between

  With this code:
  

          a = ((a.d).between #((a = a.d.between # 1) + 1))  

   Anyhow, that second thing, which I got off of CharMove or somewhere, might take a bit longer to read, but it does the same thing without having to call InList. Now, I don't know if calling InList really uses that much more processing power or memory or anything, but at least, when you are using the debugger, you won't have to step through those extra lines.
  
  So, all in all, findpath.h is a leaner, meaner machine now. It still has some of the same hang-ups. Like, it doesn't have awesome code for dealing with locked doors or anything, but even with that, I think I put it in a much more stable place (now, if there is no available path to the "prize", the code should shut down without printing anything embarrassing).
  
  So yeah, there's that. If you are curious about the two versions, the old version is http://roody.gerynarsabode.org/hbe/findpathold.h and the new version is http://roody.gerynarsabode.org/hbe/findpath.zip.
  
  Happy pathfinding!