I don’t understand this error, but I am afraid it is something really simple.
The error I’m getting is: Error: chapter_1b line 220: It is illegal to fall in to an *else statement; you must *goto or *finish before the end of the indented block.
My code looks like this:
*if (genderchoice)
*fake_choice
#"I'm Yves Bouchet," he introduces himself.
#"I'm Yvette Bouchet," she introduces himself.
*gosub_scene startup chef_female
#"I'm Yves Bouchet," they introduces himself.
*gosub_scene startup chef_nb
#"I'm Yvette Bouchet," they introduces himself.
*gosub_scene startup chef_nb
*set chef_fname "Yvette"
*else
"I'm ${chef_fname} ${chef_lname}," ${chef_he} introduces ${him}sel@{chefplural ves|f }.
"I'm very pleased to meet you."
Do I really have to make a goto and a label to the last sentence for all these options? Or is it better to change the *else command in a if genderchoice false?
I’d say it’d probably just be easier to create a quick *label after the next line, then after the *else text, insert *goto label. Basically, any time you use the *else statement ChoiceScript doesn’t know where to go so you have to finish it off with a *goto.
You could of course go with *if genderchoice false as long as you are sure that every player will have that option set to either true or false at this point, if that makes sense Seeing as this is a gender selection for a character, I’m assuming the player has either already set the gender earlier or chose the “select as they appear” kind of option so I think you are safe with using *if genderchoice false here!
Yes, with an *if that is followed by an *else you must exit the initial *if with a *goto.
As you mention, if you don’t use *else then you can drop out of the *if just as you have. Personally I always do that and just have the two *if statements.
Having two if statements is not always possible, because both expressions can evaluate to true, but you want to only execute the body of the first statement that evaluates to true.
If you find these kind of statements are becoming a chore, try using implicit control flow.
I see three possible problems here, including your "fall in *else" error.
*if (genderchoice)
*fake_choice
#"I'm Yves Bouchet," he introduces himself. <<< This choice has no body. Could cause error.
#"I'm Yvette Bouchet," she introduces himself.
*gosub_scene startup chef_female
#"I'm Yves Bouchet," they introduces himself.
*gosub_scene startup chef_nb
#"I'm Yvette Bouchet," they introduces himself.
*gosub_scene startup chef_nb
*set chef_fname "Yvette"
<<<As people pointed out, the *if branching here has no exit point using *goto. Put the *goto here, in this exact indentation.
*else
"I'm ${chef_fname} ${chef_lname}," ${chef_he} introduces ${him}sel@{chefplural ves|f }.
<<< Same as the above *goto issue.
"I'm very pleased to meet you
Alternatively, you can try read more about ICF on the article Cup linked.
Thanks! I had a read through the ICF topic and don’t really get whether I should use it or not. I thought that by using fake_choice I was doing the same thing and you do not need a goto, apparently not.
You’re right about the first option not having a goto, as I set all the variables already to be male so no need to change anything here.
*if (genderchoice)
*fake_choice
#"I'm Yves Bouchet," he introduces himself.
#"I'm Yvette Bouchet," she introduces himself.
*gosub_scene startup chef_female
#"I'm Yves Bouchet," they introduces himself.
*gosub_scene startup chef_nb
#"I'm Yvette Bouchet," they introduces himself.
*gosub_scene startup chef_nb
*set chef_fname "Yvette"
*if (genderchoice = "false")
"I'm ${chef_fname} ${chef_lname}," ${chef_he} introduces ${him}sel@{chefplural ves|f }.
"I'm very pleased to meet you."
Changed it to this which is working. As a beginning choicescript user, would you recommend turning ICF on or off?
I would definitely recommend turning it on. The ICF itself should be compatible to, what I would call, the legacy setup (should be no problem if you turn on ICF on your non-ICF drafts), but there’s merit on reading why ICF exists and what leads to its creation.
ICF means that the ChoiceScript interpreter will read your code top-down. This is the flow of your script.
With ICF off, when the interpreter finds any flow-control command (that is, any command which can change the flow, or “position”, inside the script, eg. *if, *choice, etc), it demands that you explicitly state where to go from there. But sometimes, a lot of times really, you want the flow to just “continue down”. With ICF off, you’ll have to add a *goto statement to a *label in the next line!
ICF takes care of that. Whenever you don’t define the flow explicitly, it implicitly decides to “run down”, in other words, *goto the next valid line. The only downside is that you might unwittingly introduce a bug, where you wanted to control the flow explicitly but forgot to add the *goto statement and the runtime won’t raise any errors because it will just keep running down. This kind of error might be hard to catch and usually comes up at beta testing.
ICF
No ICF
Pro
Greatly reduce the amount of *gotos and labels.
Ensures no unwanted path is introduced in your game.
Con
Catching unintended control flow errors is harder.
Bloats your script and makes writing simple *if blocks a chore.
Thank you so much for the elaborate summary! I have turned it on now I thought that by using fake_choice I was doing the same thing and you do not need a goto, apparently not.
You’re correct that fake_choice does ‘turn it off’ - but only for the choice itself. Thus you do not need a *goto for each of your choice options.
However, when you use *if + *else you require a *goto for those two components. So you would need a single *goto at the end of the *if block, which all four fake_choice options would utilise.
I don’t have ICF turned on. I prefer to use *goto whenever I need to move around the code because it makes then I know the code is doing what I want it to do. It also make me think explicity about what I want to happen at each stage. Having said that though, I’ve not written enough branching narrative to discover if it’s just a pain to do hundreds of times, so that view may change.
Seeing as this is a gender selection for a character, I’m assuming the player has either already set the gender earlier or chose the “select as they appear” kind of option so I think you are safe with using *if genderchoice false here!