Jolt Country

Debaser wrote:Is there an upper limit for how high the arrays can go?

I think so, but you can raise the memory limits that Hugo normally has in place (for ease of running on platforms with less memory) in your code. For instance, I have a line that says:

$MAXROUTINES=512

As I was nearing the point in FoD where the standard number of routines was not going to be enough.

For what it's worth, in FoD, my qflag array (which is to be the number of expected arrays times 8) is set for 2000. So I know you can go at least that high.

Less important, but I also thought it might be nice for conversation to initialize automatically on occasion and continue for several rounds without requiring the player to type "talk to" each time. Basically like in the Infinity Engine series of games where you get a response and the menu for your next reply just pops up again. Follow? Is there an easy way to do this? If not, don't wrack your brains or anything, as it's not a huge issue.

You could probably force a "talk to" command to follow the conclusion of your responses. Something like Perform(&DoTalk, Protagonist, NPC) right at the end. I've never tried it myself, but I imagine that would kick you right back into to another round of speaking.

Ice Cream Jonsey wrote: I think so, but you can raise the memory limits that Hugo normally has in place (for ease of running on platforms with less memory) in your code. For instance, I have a line that says:

$MAXROUTINES=512

As I was nearing the point in FoD where the standard number of routines was not going to be enough.

For what it's worth, in FoD, my qflag array (which is to be the number of expected arrays times 8) is set for 2000. So I know you can go at least that high.

Outstanding, though I am more worried about the number of quips per character than the number of characters.

You could probably force a "talk to" command to follow the conclusion of your responses. Something like Perform(&DoTalk, Protagonist, NPC) right at the end. I've never tried it myself, but I imagine that would kick you right back into to another round of speaking.

I tried that. It gave me truly bizarre results. Any given time the routine was called it would randomly:

A. Work as expected.
B. Say "You can't talk to that!"
C. Crash to desktop.

Debaser wrote:Is there an upper limit for how high the arrays can go?

What Jonesy said about increasing the number of named arrays will work--but (although I haven't looked in that much detail at the quip code) you almost certainly won't have to worry about it. You also shouldn't have to worry about any static array space limits (unless you're storing huge amounts of text purely as string arrays or something).

Debaser wrote:Less important, but I also thought it might be nice for conversation to initialize automatically on occasion and continue for several rounds without requiring the player to type "talk to" each time.

This is possible, too--in fact, my current (in-the-works) conversation system works exactly like that. Just put your display-->input-->dispatch code in a loop--there's no need to return to the regular player input line until you're done.

Debaser wrote:I want to know now rather than then if this is going to cause the compiler to explode in a hail of delicious monterey jack cheese or some such.

Jonesy requested the jack cheese option, too--I'm still working on it.

Debaser wrote:

Ice Cream Jonsey wrote: You could probably force a "talk to" command to follow the conclusion of your responses. Something like Perform(&DoTalk, Protagonist, NPC) right at the end. I've never tried it myself, but I imagine that would kick you right back into to another round of speaking.

I tried that. It gave me truly bizarre results. Any given time the routine was called it would randomly:

A. Work as expected.
B. Say "You can't talk to that!"
C. Crash to desktop.

Hmm. I just implemented this, finally. What I see is that, say I got three "levels" in -- my routine would, at the last one, print the final response three times.

So, I'm currently debugging this.

Ok, I debugged it. It had nothing to do with the routine. I had a loose "SetQuip(11,4,0)" line of text hanging about.

Hmm.

The thing is, though: normally the DoTalk routine allows you to hit "0" if you don't want to say anything. I am calling the exact same routine, so at best I, as the author, am just suggesting that the player continue the conversation. They still have a chance to get out of it.

That's not the intended behavior, but I may end up going with that. That way if someone really wants to bail, they can.

Ice Cream Jonsey wrote:

Debaser wrote:

Ice Cream Jonsey wrote: You could probably force a "talk to" command to follow the conclusion of your responses. Something like Perform(&DoTalk, Protagonist, NPC) right at the end. I've never tried it myself, but I imagine that would kick you right back into to another round of speaking.

I tried that. It gave me truly bizarre results. Any given time the routine was called it would randomly:

A. Work as expected.
B. Say "You can't talk to that!"
C. Crash to desktop.

Hmm. I just implemented this, finally. What I see is that, say I got three "levels" in -- my routine would, at the last one, print the final response three times.

So, I'm currently debugging this.

Y'all are using Hugo, right?

Because when I did something like this in Glulx Inform, for SMTUC, I'd crash pretty fast as I ran out of stack space; the routines consume stack like popcorn, and even Glulx Inform doesn't have a very large stack. Maybe this is what's happening in Hugo, except that instead of hitting the limits of the stack and getting a runtime error, the stack is quietly overflowing into somewhere else in the memory map and corrupting it? I don't know whether Hugo tries to enforce any bounds separation between the different parts of its memory map, but this seems likely.

Bruce

Them's fighting words.

It's been suggested that I clarify my response somewhat. Basically, there's next to no chance of that (i.e., stack overrun corrupting other memory/code) since the game's runtime stack doesn't live in the same sort of memory as code and dynamic data. (That is, it's handled by the underlying machinery--the native machine core handles the Hugo stack.)

It is possible to crash the stack, in which case the engine itself will complain and crash (in whatever manner stack-toppled programs compiled with the compiler/library used to compile that port of the engine are wont to crash). But since rewriting stack management in the engine core some years ago I've yet to see a recursion problem like that (other than something that unintentionally and unendingly recurses until it crashes).

Sounds like the bug got caught, anyway. If not, let me know, and we'll give that little sucker what for.

Kent wrote:It's been suggested that I clarify my response somewhat.

Well, see, that's cool. The next time some <s><b>slackjawed fucknut</b></s>well-intentioned newbie asks "which IF system is better?" I can say, "Well, turns out that Hugo is much easier to do deeply-nested conversation trees in because the stack is much less stingy than in Inform or Glulx Inform."

Bruce

Kent wrote:It's been suggested that I clarify my response somewhat. Basically, there's next to no chance of that (i.e., stack overrun corrupting other memory/code) since the game's runtime stack doesn't live in the same sort of memory as code and dynamic data. (That is, it's handled by the underlying machinery--the native machine core handles the Hugo stack.)

EAT IT, STIFFY!!! HAHAHAHAH

GO, UNITED!!!


_____________________________________

Ugh. Blue text. I thought soccer hooligans induced vomiting in themselves.