Jolt Country

Mainly for Kent:

Somebody posted an interesting question to the newsgroup. Basically, if the him_obj is set to an NPC and you immediately try to do something like "ask barman about himself" (where him_obj is not the barman), then the Hugo lib works unexpectedly.

As far as I can tell, it's happening in objlib.h, in the self_class. What gets returned for the xobject used by the self_class is himself.self_object or herself.self_object -- which is always "him_obj" or "her_obj".

If you were to say "x barman" and then "ask barman about himself" I think it'd work fine (I haven't tested it) -- because him_obj is going to be set correctly. But if you say something like "x other guy" and then "ask barman about himself", the barman is going to respond as if "himself" is "other guy" becase him_obj is set to the other guy.

The "xobject" checking makes sure that the object is actually living and appropriate for the pronoun (via checking self.self_resolve). So, self_class *already* knows that the self-referencing pronoun refers to the object. So, I think the bug is actually in self_class. It shouldn't be using self.self_object as the xobject in the perform() call -- it should be using object as the xobject, right?

So, where line 125 in objlib.h currently says this:
It should be changed to this:
Right? The whole purpose of self_class when the self pronoun is the xobject is to make the object refer to itself. So, self.self_object is okay when the pronoun was the object, but not when it's the xobject. Right?

Sorry: I meant to comment on this earlier. I think that looks like the right approach. I don't have time to test it extensively to see if it holds up, but I'd like to hear if people do, and any other issues that may arise. If it works in practice, I'll incorporate it into the library.

Cool. Don't forget these others, too! :)

http://www.joltcountry.com/phpBB2/viewtopic.php?t=3985

http://www.joltcountry.com/phpBB2/viewtopic.php?t=3962

http://www.joltcountry.com/phpBB2/viewtopic.php?t=3990

http://www.joltcountry.com/phpBB2/viewtopic.php?t=4039

http://www.joltcountry.com/phpBB2/viewtopic.php?t=3089

You may already have looked into (or fixed) some of these. None are particularly troublesome. Just a few quirks I've noticed over the months. :)

And here's something that's not a bug -- just a feature request. When comparing text in games written in TADS and Inform to text that's displayed in a Hugo game, I've found that I like the extra spacing between paragraphs in the former (which Hugo lacks). Room descriptions begin with an indent, but it can look a little odd when there are 3 or four paragraphs (even if short) where each one is indented, because command/replies are typically not indented (and it'd look weird if they were).

You can set the indent size to 0 by setting a define (or something -- I forget) but the whole engine is built around room descriptions with an indent and single spacing. So that looks even worse.

I did something in The Traveling Swordsman to (a) set the indent size to 0, and (b) replace the "indent" routine so that it prints an extra blank line instead of an indent. Run Distress through a few moves/rooms, and then run TTS through a few moves/rooms, and you'll see the difference. I think TTS is a lot easier to read.

This did take some extra work, though. There are places where "indent" is called when listing container contents (and maybe a couple other places). So you'd end up with *two* blank lines in some cases. I have to check something in "indent" to avoid printing an extra blank line in certain cases. It wasn't all that hard to figure out, but I mention it for completeness.

So, here's my suggestion. Add something to the library so that if indent_size is 0 (or maybe even add a new var to handle this) it does a blank line instead of an indent. It'd let games look more like Inform and TADS, and I think I prefer that style. :)

I know I'm bumping an old thread, but I thought I'd take a look at this today. I changed over to the recommended code a while ago, but today, I thought I'd try to replicate the problem and switched back to the old code. So far, it hasn't worked.

I think as long as your DoAsk select case code points to the objects themselves, it should work. Like this: Merk, I see that your games' DoAsk routines largely rely on strings. Might that be the problem?

Today, I've been updating the Hugo Bug List / Feature Request document, so I took another look at this.

Anyhow, I must have misinterpreted the problem originally since yeah, taking another look at it, I see it acting like Merk said. My mistake!