another DoLook update

So, while testing the new Roodylib code on old released code such as Kent Tessman's Spur, I came across things like Spur's "Little Jimmy" character where the object's/character's inventory is listed in the long_desc.  The problem with that is that verblib.h (and my update to DoLook) still print a new line after the long_desc even if everything has already been listed and no object-content text is going to be printed.

Originally, I was going to make a post here about how the best solve for that is to make a before routine for the object for DoLook, have it run the long_desc and return true so the rest of DoLook is never called.  Just as I was going to write the post here, though, I thought, eh, I'll take another look and see if I can fix DoLook since the before routine method sort of seems like weaseling out.

The good news is, I think I found a solution I'm generally happy with.



You may notice that the call to WhatsIn has an extra argument.  Normally, WhatsIn goes through every child of the object and clears its already_listed attribute before going on to list things.  I updated it so it does not do that step if the second routine argument is true (which is why DoLook has to clear already_listed before the object's long_desc property is even run).

This is how Little Jimmy's long_desc would look with the new code:


(Basically, the only change is that it marks the taffy as already_listed- of course, I probably should have moved it so it's only marked if Jimmy is holding the taffy, but in this case, it shouldn't affect anything.)

Container Theory Part II

Ok, so not long after writing that last post, I remembered one of the main reasons I have long associated "transparent" with "container".

In the example of a snowglobe, if we define it as a non-container, transparent object, it'll work fine with DoPutIn. A container, transparent object would need additional before routines to disallow it. This is part of the reason why yesterday's view of containers sounded appealing to me.

Still, that doesn't change the fact that DoLookIn demands that objects be containers. What's the point of a snowglobe that you can't look into? Anyhow, instead of trying to fix what is and isn't a container, I think I'm just going to fix DoLookIn's grammar.

I could try to do it on the grammar level, using Roodylib's "grammar helper" stuff to only allow containers and transparent items to work on the grammar pass, but I don't like forcing Roodylib users to use extensions like that so I'm probably just going to change DoLookIn's container check to an object token and add all necessary additional code to DoLookIn itself.

On the plus side, this should make coding windows (the glass kind) more intuitive to future authors. On the down side, maybe this change will have some ramifications down the road.

I mean, I could go back to my old container assumptions, but since I've already learned that others find other definitions more intuitive, I don't think that's the right path. I mean, the holy grail of an IF language is to make everything as intuitive as possible.

Container Theory -or- How Do You Code a Bucket?

So recently, I've been helping with a contents-listing problem during the >INVENTORY command involving coat pockets. Fixing that involved a change to WhatsIn and SpecialDesc- which I had intended to write up here, if it weren't for the issue that I want to talk about today (in fact, after WhatsIn and SpecialDesc, I have another thing I want to write about, so hey, the next entry will be a nice, multi-part post).

It turns out that my updated code still isn't working for that other person, and my hunch is that it has to do with the fact that my code has been slowly changing how containers are dealt with. Today, I figured I should finally run my designs past Kent. Eventually, we unearthed the point of contention where we disagreed on default behavior.

In Kent's view, a bucket coded in Hugo should have the following attribute definition:

    is container

While in my mind, it should be defined as such:

    is container, open

I think this might also be the difference in the coat objects as defined by me and the fellow I'm trying to help (since my new SpecialDesc code relies on the open attribute being used). To those who prefer the first definition, adding "open" must seem like overkill. As far as whether-contents-can-be-seen, I agree, as far as unopenable containers are concerned, it can be assumed that they are either open or transparent (otherwise, it's useless for them to be a container).

I was going to say that as far as other container behaviors go, I was worried about things like not-open, unopenable, transparent objects, but I had a Hugo-understanding breakthrough just now as I write this. I glanced over at the character class definition and was reminded that characters are transparent without being containers. I think part of my container-understanding problem is that I have so strictly associated "open" and "transparent" with containers (since thinking of transparent examples often make you think of something like a glass jar), when it's better to pretend that "transparent" has nothing to do with containers and remember that "open" only exists to work with "openable".

Anyhow, I feel pretty dumb that I have been so unclear on the concept for this long, but I'll try to update HbE so future coders don't fall into the same traps I did. Also, I still think that some of the hugolib contents-checking conditionals could be more concise, so I'm going to try to do something about that.

While I'll quickly admit being wrong on this issue, it's interesting that something as simple as containers can so easily catch people (maybe most people won't make the same assumptions I did, but I'm sure some do). I imagine the container code I wrote in ZIL recently is just as flawed. Ah, well.