Choicescipt keeps telling me that it’s illegal to fall out of a choice statement, and that *goto or *finish must be used. Problem is that I can’t find the instance where I don’t use it. I checked the indent as well, but can’t spot anything. The error message marks line 384, which is the fourth choice option, but I literary can’t see anything wrong with it.
Here’s the code:
You respond by...
*Choice
#Asking who this lady Eir is. It's a friendly enough approach.
Choice dependent text.
*goto communication_crisis
#Apologising, to keep from getting on their bad side.
Choice dependent text.
*goto communication_crisis
#Making a run for it.
Choice dependent text
*if fraught > 50
Some text.
*goto runaway
*if coordination >= 20
Some text.
*goto runaway
*if ((fraught > 50) and (coordination >= 20))
*achieve grun
Some text.
*goto runaway
#Threatening them.
Choice depentent text.
*if lure >= 10
Text.
*goto escape_crisis
*if fraught >= 50
Text
*goto escape_crisis
*if (lure >= 10) and (physicality >= 20)
Text.
*goto escape_crisis
*else
Text.
*goto escape_crisis
*label communication_crisis
*line_break
*line_break
Wall of text.
*goto escape_crisis
*label escape_crisis
Some text.
*goto runaway
*label runaway
*page_break
Wall of text.
*line_break
*line_break
*if (persistance >= 5)
Some text.
*goto Go_To_Sleep
*else
Some text.
*goto Go_To_Sleep
*label Go_To_Sleep
Text.
*page_break
*goto memory
Try popping an *else under Making a run for it (or replacing the *if ((fraught > 50) and (coordination >= 20)) with an else, if that’s what it’s meant to do).
Yeah, I ran just that code snippet in CSIDE and it worked fine, so we’d need to see the entire code to determine the issue. For the time being, so you can keep testing other things, try adding:
*create implicit_control_flow true
at the beginning of your startup.txt file. It usually helps prevent these issues because it allows you to fall out of *choice statements.
Unless you meant to use the opposite comparators on that third if clause, in the case where “fraught” and “coordination” variables both fail to meet your requirements, you would indeed fall out of the choice.
As coded, the last *if statement isn’t going to work. At all.
Right now, it’s saying “if both A and B are true, do this”. The problem is that no player who meets that requirement will ever reach the *if. Any player who has both (fraught > 50) and (coordination >= 20) is going to succeed at the earlier fraught check. And that earlier fraught check? It’s using a *goto command to send the game to a completely different section of code.
The easiest way around that will be to bump the combined check to the top of the stack, and put the single checks underneath it. That way, players who meet both requirements will get the special combo bonus, while only players who fail one or both checks will proceed on to the singles.
The problem is here (as other people have said); even though the code can’t reach the end without seeing a *goto, the tests don’t know that. Since they’re all going to the same place, you might as well just have a single *goto at the end:
#Making a run for it.
Choice dependent text
*if fraught > 50
Some text.
*if coordination >= 20
Some text.
*if ((fraught > 50) and (coordination >= 20))
*achieve grun
Some text.
*goto runaway
EDIT: on second thought, I notice that all of these are >; should some of them be < instead?
if you use if and else, if (hah) there are ifs between they should be elseifs.
in the threatend and make a run choices, it should look more like this:
*if ((fraught > 50) and (coordination <=19))
text
*if ((coordination >=20) and (fraught <=49))
text
*if ((fraught >50) and (coordination >=20))
achievement
stuff
FWIW, I think the snippet posted by OP is structurally fine.
The only possible mistake AFAI-see is mentioned by @Havenstone: there’s a possibility where all the conditions inside the 3rd option can’t be met.
I got this issue too. Quicktest checks what happens if none of the *if statements are met (even if that’s not possible). Use *else to get the little bastard to calm down.
Or like Parrotwatcher suggested, put the *goto outside of the *if statements. Saves you two lines of code to do that, so you should’ve been doing that already.
Thank you !!
The issue was that I didn’t include a *elseif command, which I didn’t even think of because so far I’ve only ever had to use one *if command and one *else so far.
No, I don’t think so? > is used when the variable have to be above the given number, right? But you may be right, since I do confuse them sometimes. But I’ll look into it.
Yeah; as it is, though, if your fraught and coordination are both above the required limits, then the game will always only give you the high-fraught text, and always miss the achievement. If you want to check for high fraughtandcoordination, you’ll need to do it first:
#Making a run for it.
Choice dependent text
*if ((fraught > 50) and (coordination >= 20))
*achieve grun
Some text.
*goto runaway
*if fraught > 50
Some text.
*goto runaway
*if coordination >= 20
Some text.
*goto runaway
(And you'll need some text or an elseif down here to fix the testing errors, too.
And you'll need to give it its own *goto, too.)
#Making a run for it.
Choice dependent text
*if ((fraught > 50) and (coordination >= 20))
*achieve grun
Some text.
*goto runaway
*elseif ((fraught > 50) and (coordination < 20))
Some text.
*goto runaway
*elseif ((coordination >= 20) and (fraught <= 50))
Some text.
*goto runaway
*else
Some text.
*goto runaway
This code runs through every possibility (high fraught and coordination, high fraught and low coordination, low fraught and high coordination, low fraught and coordination).
