>I'm changing the subject header because I think this one's another good area
>for sharing experiences.
>
>First, soul-baring time: I have, I _think_ found out what's causing my bad
>compiles (thanks to Staz for offering me a checklist instead of just saying
>BECAUSE YOU'RE AN IDIOT which is what I'd be doing in his position by now). In
>the fine print under SEGMENT in the reference manual, we are warned not to
>have more than 127 intersegment jumps... and a quick check tells me I've got
>_way_ more than that throughout most of my .MAIN file, since adventure games
>boil down to: interpret input, show text, show pictures, play sounds... in
>other words, call the same functions over & over again at a rate of about one
>every other line. But here's the catch: the compiler doesn't count up the
>jumps and beep at you on the spot; it just quietly goes berserk in a
>picturesque variety of ways. (This may well be why some people report trouble
>when their segments get close to the 32K limit: it wasn't the segment itself
>but the leaving of it...)
>

What fine print?

I'm afraid you missed the boat again, Lucy.  The manual says that you can
have 127 jumps _out_ of a segment. This means 127 different target
locations. We looked at this several years ago and decided to err on the
side of safety. FBII was updated to handle 200 jumps out of a segment and
will show an error when this limit is reached.

When you sent me your last list of complaints, I quoted the "127" figure
from memory (in error). Still, I have never seen a program reach the 127
limit and I doubt that your program is anywhere in that range.  But we're
back to the same thing. You want to complain, but you refuse to send any
code so that I might help you find _your_ bugs.

I ended our last correspondence with this:

	If there is a bug, I need to fix it. If not,
	I'll never find your problem without sufficient
	information. It's like you're saying, "There
	was an auto accident at Fifth and Main."
	Then you ask, "What was in the trunk of the blue car?"

So send the code.

>Hence the question of invisible errors. In FB some mistakes are punished
>swiftly and immediately: bug-alert box, randomly generated beep, and the
>compiler digs in its heels and refuses to proceed until the mistake has been
>fixed. Things like undefined constants, segment too long, improperly defined
>functions, passing functions the wrong parameters or none at all...
>
>Other mistakes--notably mathematical atrocities like dividing by zero--are
>quietly converted into their non-error-generating counterparts:
>SQR(-4), well, of _course_ you meant to say SQR(4), didn't you?
>

BASIC is supposed to help you get thru _your_ mistakes. Here, you are
saying that you don't want help. In this same email, you complain that
there isn't more help. So which do you really want? More help or less?

>But then, finally, there are the deadly mistakes that we _don't_ find out
>about until it's too late. (Ever seen a purged menu? Not a pretty sight...) If
>anyone out there is prepared to admit to mistakes that I haven't yet made (and
>posted about), I'd like to hear about them. And so, I'll bet, would everyone
>else on this list except the three people who really, thoroughly, understand
>FB programming down to the minutest detail.

Purged menus are terminal. Always have been. But FB never HPURGEs a menu
handle. PG and Resourcerer both notify you if _you_ have made such an
error. There is only so much we can do to protect you from yourself.

This is supposed to be a forum where we gather to help each other figure
things out. I don't think your list of imagined complaints is productive.
In fact, it is misleading and I often handle tech calls where I have to
tell folks to ignore your posts because you did not understand what you had
written.




- STAZ  ~)~

staz@...
228-255-7085