Need Advice

Post a reply


This question is a means of preventing automated form submissions by spambots.
Smilies
:smile: :sad: :eek: :shock: :cool: :-x :razz: :oops: :evil: :twisted: :wink: :idea: :arrow: :neutral: :mrgreen:

BBCode is ON
[img] is ON
[url] is ON
Smilies are ON

Topic review
   

Expand view Topic review: Need Advice

by j/s/toker » Mon Feb 03, 2003 7:57 pm

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

Re: More stack

by Forum Soccer Hooligan » Mon Feb 03, 2003 7:31 pm

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!!!


_____________________________________

Re: More stack

by bruce » Mon Feb 03, 2003 7:20 pm

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

More stack

by Kent » Mon Feb 03, 2003 6:21 pm

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.

Stack this

by Kent » Mon Feb 03, 2003 5:50 pm

Them's fighting words.

by bruce » Mon Feb 03, 2003 11:43 am

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

by Ice Cream Jonsey » Mon Feb 03, 2003 6:46 am

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.

by Ice Cream Jonsey » Mon Feb 03, 2003 6:42 am

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.

by Guest » Tue Jan 07, 2003 6:53 pm

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.

by Debaser » Sun Jan 05, 2003 9:28 pm

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.

by Ice Cream Jonsey » Sun Jan 05, 2003 9:22 pm

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.

by Corky the Kickboxer » Sun Jan 05, 2003 8:17 pm

*raises hand*

by Debaser » Sun Jan 05, 2003 8:04 pm

Oh, hey not to distract from all the utterly random banter, but I do have another question:

Is there an upper limit for how high the arrays can go? I ask because I noticed I've been using very short conversational snippets for each choice (basically the PC doesn't say anything unless it's chosen from the menu), and consequently I'm getting nearly 20 "Quips" each for the initial conversations with the first two characters. If I keep up this pace, I could see the more signifigant characters going upwards of 100 by the end of the game, and 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.

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.

by Ice Cream Jonsey » Sun Jan 05, 2003 2:37 am

"Corky" was the name of the family dog. Who died last year.

Christ, is there anything on the planet named Corky that is still kicking?

by Ben » Sun Jan 05, 2003 2:21 am

Debaser wrote:I felt like Corky
"Corky" was my family's nickname for my father, so if you could just rein in the whole "Corky reference" thing, gee, that'd be real swell! THANKS!!! HEARTLESS PIG!!!

by Wild, Roving Bobcats » Sat Jan 04, 2003 6:51 pm

=(

by Debaser » Sat Jan 04, 2003 3:47 pm

Anonymous wrote:Hahaha. Got it. Zounds, I am an imbecile. Code works great, Jonsey, happily ignore this thread.
This wasn't a sarcastic mewl for attention. I actually had, simply by staring intently at the code for several hours, finally figured out how these mysterious "arrays" were arranged. It was a much more triumphant accomplishment to figure this out on my own, anyway. I felt like Corky in that episode of Life Goes On where he finally learns to tie his shoes.

But I appreciate the thought. And Peter Jackson should hire you to rewrite all the dialogue before the release of the final LotR movie.

by Ice Cream Jonsey » Fri Jan 03, 2003 3:28 pm

Debaser wrote:Okay, I was taking a look at my old code and notes for <i>the Magistrate</i> and I had a bunch of ideas for a wholly seperate game just kind of occur to me while at work today. Then I pulled up your phototalk file and, where I'm lost is in the (x, y, z) quip array. I know the first number indicates the character in question, and the last number seems to always be set at 0, so I suppose it wouldn't be too large a leap to assume this is only altered during the actual procession of the PTalk code.
Yeah, if you see something like this:

SetQuip(1,10,1)

That means that for the character with a charnumber of 1, set quip 10 to "on." The last number is just a toggle and will only either be 1 or 0 (on or off).

So I'm guessing it's the middle number that's the important variable on what choices are given. But how does it relate to the case structure in question?

I mean, how do you tell the system to display cases 3 and 4 only after case 2 has been selected, to eliminate case 3 as an option if case 4 is selected and, on top of that make it start with case 1 and 2 in one scene and case 5 and 6 in another with only a single variable?
OK, to display case 3 and 4 after 2 has been selected, you just need to put

SetQuip(1,3,1)
SetQuip(1,4,1)
SetQuip(1,2,0)

For the response that is generated when the player goes into what you wrote for quip #2. Does that make sense? I don't know if I am explaining it right.
I'm sure this is all terribly simple once it's explained to me, but right now it's fucking prestidigitation as far as I can discern.
It sort of goes like this:

Code: Select all

Quip #1&#58; "Hey, what's going on?"
Quip #2&#58; "That's great, I love pies."
Quip #3&#58; "Hmm! I love cows."

Response #1&#58; 
 SetQuip&#40;1,1,0&#41;
 SetQuip&#40;1,2,1&#41;
 SetQuip&#40;1,3,1&#41;
 "Not much. Just thinking about pies and cows," says Gimli."

Response #2&#58;
 SetQuip&#40;1,2,0&#41;
 SetQuip&#40;1,3,0&#41;
 "Yeah, pies are great. I eat them with meat from the bone."

Response #3&#58; 
 SetQuip&#40;1,3,0&#41;
 SetQuip&#40;1,2,0&#41;
 "I like cows because they are short like me. Toss me! Haw, haw."
In the above example, we're allowing the player to discuss *either* cow or pies. We kill off the response that the player did not choose.

by Ice Cream Jonsey » Thu Jan 02, 2003 10:57 am

Whoops -- I totally didn't see that this thread got bumped until right now. I think it was because I had been logged in as a guest all over the weekend and wasn't getting the different colored Mr Bandwidths doing the sleuth work for me. Odd. I just woke up for work and I will revisit this once I have had some stimulants.

by Guest » Wed Jan 01, 2003 6:08 pm

Hahaha. Got it. Zounds, I am an imbecile. Code works great, Jonsey, happily ignore this thread.

Top