Tdarcos wrote:I keep hearing about the problems with Hugo and it doesn't sound like a well-designed system to handle Adventure games since all I seem to hear from you guys are complaints (and suggestions) on how to 'get around' deficiencies in the underlying parser system.

Well, I don't post about the hundreds of times it does things right, over the last 5 years I have been working on this one particular project using it. :)

It's very well-designed and user friendly. That statement would be stronger if I provided examples, but maybe we can table that for another day.

Roody_Yogurt wrote:What I'm guessing you're doing is typing 'WAIT' (or Z) while testing your fuse, which under normal circumstances, passes three turns.

Yes, that's exactly what was happening. The sequence is tightly timed, and I don't want the sequenced compressed into fewer turns if the player chooses to wait (which, in my bare outline game file so far, is the only thing she can do). Maybe in my next stage of implementation, I'll only have a long timer that will end the sequence, with other code producing the messages, so a player could actually choose to just wait around to get through it faster. It seems this is one of things Hugo's wait code may have been designed for. Thanks again, Roody.

Tdarcos wrote:I keep hearing about the problems with Hugo and it doesn't sound like a well-designed system to handle Adventure games since all I seem to hear from you guys are complaints (and suggestions) on how to 'get around' deficiencies in the underlying parser system.

It may be glitchy in some ways, but Hugo is both fairly simple and fully-featured in terms of being capable of producing community-standard IF games. Most of the other "simple" systems struggle to produce text adventures with the same parser, undo, multimedia, and portability features. I've tried several different systems for making text adventures, and I am not tied to Hugo. However, Hugo suits my needs very well right now, even if I do keep forgetting that it's not Inform 6. ;-)

I'm not looking anything up so let me know if I'm wrong and I'll research this a bit better, but I have used fuses in the past and, um, I think fuses should only tick once per turn.

What I'm guessing you're doing is typing 'WAIT' (or Z) while testing your fuse, which under normal circumstances, passes three turns.

The way to get around this is to set event_flag as a non-false (non-0) value in your fuse code, like this:
EDIT: Changed event_flag to 2. I had that in the original source I was drawing from but had forgotten why it was 2 so I changed it. Anyhow, event_flag = 2 forces the WAIT to stop after one turn without one of those 'Do you want to keep waiting?' messages which is really annoying during fuse situations.

Fuses are apparently not easy. I'm not sure if there's one in Collossal Caves (or if there is, it goes off immediately and is the climax of the game). There is one in Dungeon (the predecessor to Zork) for the PDP-11. But any timed event is hard to do right unless the underlying game has support for a clock-driven or turn-driven event.

I keep hearing about the problems with Hugo and it doesn't sound like a well-designed system to handle Adventure games since all I seem to hear from you guys are complaints (and suggestions) on how to 'get around' deficiencies in the underlying parser system.

I would think the system should allow you to define the number of ticks per turn a fuse has, to allow slow-burning and fast-burning fuses. Or whatever you want to do.

I recently added a fuse to my skeleton game. At first, the results were quite mangled; it would display the whole sequence of text that I spaced out for 10 turns in just 3 turns. Using the fuse/daemon monitoring feature of the Hugofix library, I discovered that the fuse was running three times every turn. The simple solution was to triple the number of ticks that the fuse is initially activated with and to change the "case" numbers that display the text of my timed sequence accordingly. Also, I had to change the original condition that was controlling the code block that I wanted to launch when the timer runs down from "if not self.tick" (as the Hugo Book says to do) to "case 0" of my "select" statement.

I couldn't find any code related to fuses in the libraries, using my text editor's search function. It's interesting that fuses apparently run three ticks per turn. I can see a hypothetical purpose for this -- suppose a game author wanted to manipulate the vale of "fuse.tick" according to certain circumstances, so that two sequential effects of a series of reactions may or may not occur on the same turn. For instance, if the kettle begins to steam on "case 4" and begins to whistle on "case 3," both text strings will be displayed on the same turn if "fuse.tick" happens to hold the value of "5" at the beginning of the turn, but if the "fuse.tick" begins with a value of "6", then the kettle will only steam on that turn, and the whistling will have to wait until the next turn.