Limit to if/otherwise?

Is there a limit to the number of “otherwise’s” you can have for an “if” statement? Pretty sure that’s what has happened with the error below. I have a very long chain of “otherwise if” and adding one more causes the error. I’ve since redone my code, but I figured I’d ask anyway.

Problem. An internal error has occurred: block stack overflow. The current sentence is 'say "[one of]'Ah, sorry, professor, I d [...] ,' Ulwazi replies.[then at random]"'  ; the error was detected at line 135 of "inform7/Chapter 30/Phrase Blocks.w". This should never happen, and I am now halting in abject failure.

What has happened here is that one of the checks Inform carries out internally, to see if it is working properly, has failed. There must be a bug in this copy of Inform. It may be worth checking whether you have the current, up-to-date version. If so, please report this problem via www.inform7.com/bugs. 

 As for fixing your source text to avoid this bug, the last thing you changed is probably the cause, if there is a simple cause. Your source text might in fact be wrong, and the problem might be occurring because Inform has failed to find a good way to say so. But even if your source text looks correct, there are probably rephrasings which would achieve the same effect.

It’s my section of code that guides which NPC dialogue table should be used. All the “otherwises” essentially are blanket responses when a table isn’t to be used:

Instead of asking a person (called the interlocutor) about a topic:
	let the conversation table be the table name produced by the conversation selecting rules for the interlocutor;
	if the topic understood is a topic listed in the conversation table:
		say the response entry;
		say "[line break]";
	otherwise if the interlocutor is Kevin and the player is Susie and Kevin is in the Mansion and Kevin is KevinTraveling:
		say "'Can't talk right now, Susie, I'm on my way to a meeting,' Kevin says hurriedly while walking through the room.";

[many more otherwises follow]

Below is the second part of the routing. I’ve moved all those “otherwise if” to this part instead. I’m not sure why I didn’t do it that way in the first place-- I swear it didn’t work when I tried that the first time around, but clearly I was doing something wrong back then because it works now.

A conversation selecting rule for Kevin:
	if the player is Susie and Kevin is in the Car:
		rule succeeds with result Table of KevinNPC_Susie_Car;
	otherwise if the player is Susie and Kevin is in the Mansion and Kevin is KevinInvestigating:
		rule succeeds with result Table of KevinNPC_Susie_Mansion;
	otherwise:
		rule succeeds with result Table of Kevin's Standard Responses.

Stupid question: Do you need the “otherwise”? Wouldn’t a simple “list” of "IF-THEN"s do the same? If one “IF-THEN” is successful, the following statements would not be reached, right?

I don’t remember hearing about that error (and I don’t have the I7 tracker to refresh my memory).

“Abject failures” are not documented limits; you can always consider them to be compiler bugs. In practice, you still have to rearrange your code, of course.

It looks like you could break that rule up into three atomic ones if you wanted. That’s a matter of style.

1 Like

Another possibility is to write multiple rules (A conversation selecting rule for Kevin when ...).

The downside of this is that you have less control over the priority order; by default Inno will select an ordering based on its own complexity metrics (which will likely be different from the order in the source), although you can influence this via first and giving the rules names and explicitly ordering them relative to each other. If all of your conditions are mutually exclusive then you don’t need to worry about this, though.

The Index should show you the order that Inform chose, though.

1 Like

It’s not necessary to explicitly name a rule and write a separate phrase to order it using First. If you’re never going to need to refer to the rule elsewhere, just using First rule for … in the rule definition phrase is sufficient. Even the Standard Rules sneak in a few ordered but unnamed rules (e.g. the scene-handling rules in the turn sequence rules).

Those were two alternatives, not a suggestion to use them together.

Having said that, it is useful to name all your rules as this produces a better output in the Index, which in turn makes things easier to keep track of.

Can’t argue with that, it’s certainly good writing style. It bugged me that I had to search through the text of the Standard rules to find out what those ‘blank’ rules in the turn sequence rules were. I’m assuming this was an oversight on the part of Mr Nelson, who appears to be after all human :grinning:

I know that feel.

I’ve done this again, this time with a big 'ole “instead” with a bunch of “otherwise if”. Everything works fine when I chop off the final offending “otherwise if”, and that statement itself works fine if I shuffle the order of my “otherwise if” list; it’s really just a limit thing.

Problem. An internal error has occurred: block stack overflow. The current sentence is 'move the player to the Laundry Room'  ; the error was detected at line 135 of "inform7/Chapter 30/Phrase Blocks.w". This should never happen, and I am now halting in abject failure.

What has happened here is that one of the checks Inform carries out internally, to see if it is working properly, has failed. There must be a bug in this copy of Inform. It may be worth checking whether you have the current, up-to-date version. If so, please report this problem via www.inform7.com/bugs. 

 As for fixing your source text to avoid this bug, the last thing you changed is probably the cause, if there is a simple cause. Your source text might in fact be wrong, and the problem might be occurring because Inform has failed to find a good way to say so. But even if your source text looks correct, there are probably rephrasings which would achieve the same effect.

That Inform 7 bug URL no longer exists.

In any case, I’d guess the way to deal with this is to just have a bunch of “if’s” instead of nested “otherwise”? I just don’t know the syntax for how to do that.

The context is that I have a spell system of sorts which can be used on many things around the game, and affected by differing values. An abbreviated version of that code:

A WeatherEffect is a kind of thing. Lightning is a WeatherEffect. Wind is a WeatherEffect. Rain is a WeatherEffect. A WeatherEffect is always proper-named. 

Summoning it on is an action applying to two visible things.

Understand "summon [any WeatherEffect] on/at [something]" as summoning it on.
Understand "[any WeatherEffect] [something]" as summoning it on.

OkWeather is a kind of thing. Office_PowerLines is OkWeather.

Instead of summoning:
     if the player is Kevin and the noun is Lightning and the second noun is Office_PowerLines and StormPCOffice is 4:
          say "lightning crashes";
     otherwise if the player is Kevin and the noun is Wind and the second noun is Office_PowerLines and StormPCOffice is 4: 
          say "wind blows".

How do I create a single “entry” for “instead of summoning” and each of those “if” statements?

1 Like

Nevermind on the syntax help “Instead of summoning when…variable variable” was the way.

Now to chop up all those otherwises…

1 Like

How about using a combination of ifs and cases (if X is … — case 1; — case 2;), see page 19 of the programming guide:
http://www.plover.net/~pscion/Inform%207%20for%20Programmers.pdf

Maybe that way you can order the different cases better and shorten the if then otherwise cascades. That could help to structure the different cases better, but I don’t know if this solves the runtime error (depends on if cases are treated differently from if otherwise cascades). Next thing I would try is to find similarities in the different cases to delegate conditions to functions, see as of page 25 of the same guide. I am still experimenting with that kind of stuff myself, though.