Jolt Country

Kent, you might think I'm crazy, but this was really happening.

I'm using an "undo" counter. In order to make sure it's correct, I have to use a "local" in routine DoUndo (which I replace, based on the library default) to remember the original counter, and after the undo, set it back to the original value and increment it for next time (otherwise undo would lower and lower that global... this way I can remember it and raise it each undo instead).

Here's the odd thing.

It worked okay, unless the last command was a "wait". Basically, at the top of DoUndo:

local und : und = undo_counter
print "It started at: "; number(und)

(then the "undo" is performed, and if successful...)

print "But now it's: "; number(und)

Basically, the local would get changed to "3" if I did a "wait" followed by an "undo". I thought it would have something to do with MAIN() running 3 times, but I'm not incrementing undo_counter then. I even try changing my variable names -- no luck.

Here's the strange part. After an hour of pulling out my hair, I started thinking that the hugo engine must be somehow messing up that local variable, even though it's not supposed to. So I add temp1 as a local in DoUndo *before* local und. Now temp1 (initialized to 0) becomes 3, and my second local (the real one) is left alone.

If I 'wait 5' or 'wait 35' or whatever, then the first local gets changed to that value when I "undo". Maybe that's intentional? I don't know how, though. It's just really weird.

That is really weird. I'll look into it.

There's usually a perfectly logical explanation for something like this. Usually a crooked real estate developer in a ghost outfit.

Heh -- well, I hope when you try, it actually reproduces for you. Otherwise, maybe I really am going crazy!

I think this is fixed now. I had the chance to look into a couple of minor issues that have been bugging me for a while, including this one.

New versions for Windows and Pocket PC/WinCE for the time being are at:

http://www.generalcoffee.com/hugo/beta/

I should point out that if you're currently using that temp local variable workaround, you should probably keep it in place for the time being until this fix is rolled out for all platforms the next time a full Hugo update is done.

Hey, cool!

Any thoughts on adding a way to disable the "wait" pausing, or at least reset the line counter? It's not a biggie, but it would sure help my custom menu thingie. :)

Also, I was talking to the author of Cugel and Gargoyle (at least, I think he did both) right before the comp started, to work out some weird crashing. He said your recommendation for checking a GLK port was to try a system pause of less than one second. This seemed to work okay, but now's a good time to ask if there is any totally reliable way other than that? I noticed that display.hasgraphics can be 2 -- not just 1 or 0 -- indicating redirected output. Does that imply GLK?

What are the circumstances, again, under which you'd need to disable pausing. You're talking about the [MORE] prompt?

I don't remember exactly what the issues are with Glk, but that sounds familiar. Part of the problem is that there isn't a 1:1 relationship between concepts, display-related and otherwise, in Glk and Hugo. A native port is always preferable for playing. I'll have to look back over my correspondance to see exactly what we were talking about and what I said.

As for display.hasgraphics, yeah, the 2 return value exists to indicate "Yes this client can display graphics, but they come up in a separate window or windows." This was initially intended for Glk or other systems where normal windowing would be impossible, but has yet to be implemented in any. The current attempts at implementing graphics in Glk do them in the client window, attempting to approximate normal Hugo behavior.

Ah, that makes sense.

Yes, the "[More]" prompt. Well, what happens is, I have written a menu that (a) uses a proportional font and (b) clears itself when done, then prints just the option selected. I guess the easy way to see it would be to playback one of the Distress scripts (see the walkthrough) up to the point where the first "touch" is shown. At that point, it's using my menu. You can actually see where the "[More]" prompt appears, if the printed text is too long.

The reason is, I have to know what line I'm on, so I can back up, print blank lines, and then print the selected option. Because the screen may already be full, basically every line printed is going to scroll up one (when the options are shown). To make it work, I print a number of blank lines first. I can't reliably "locate" in a proportional font, so I location 1,1 and then print nothing until I reach the right point. Hmmm... actually, a demo program and the source might be easier. I'll try to email you a demo that might make it make more sense.

In a nutshell, printing blank lines and then backing up works fine. I can clear the menu and then print more text, as long as what I print doesn't also reach the bottom of the screen. It's because a >prompt isn't shown, so Hugo doesn't reset the line counter. It's not a bug in Hugo -- I spent some time looking at the C source to figure out why this was happening -- it's doing exactly what it's supposed to, but for my purposes, I'd like to reset the line counter at the same time I clear the menu and start printing more text.

To clarify, what I'm after is a way to reset the printed line counter. I don't really want to disable the "[more]" prompt, because if it's a small display or a print a lot of text after the menu option is selected, "[more]" would still make sense. I'd just like to be able to reset the line counter, before I start printing the results of the option.

It wouldn't be a problem normally, because key pausing resets the line counter already. But I'm locating to the top of the screen and then moving downward to find the right position (since I can't rely on proportional Locate x,y). It's because I do this *after* the keypress, I end up letting Hugo increment the line counter all over again, so by the time I print text that hits the bottom of the screen, "[More]" comes up.

The easy thing for me is to just turn off a couple features in my menu. If I don't allow arrow up/down highlighting, and if I don't try to clear the menu off the screen afterwards, it's a non-issue. In fact, that's what I do when it detects GLK mode (because the whole thing breaks in GLK, where the screen width and height seems huge). I was just going for an effect where a menu can appear in-line in the same game font (not fixed-width), and then go away when finished. It works fine already, except for the "[More]" prompt if I print too much text after the menu. :)