This is generating an error saying that “it is illegal to fall out of a choice statement, you must goto or finish before the end of the indented block”
My understanding was that the use of the else, and a goto line in each option would resolve this. I also tried it using a single “*goto shot” phrase at the end, at the indent level of the “if” statements, but this resulted in it saying there was the same error, merely in the first of the “elseif” statements, rather than in the choice line.
Thank you all for the help
John
#Look for some way to get everyone's attention. There are safety whistles and flares nearby...
*set perception %+1
*if perception > 30
You glance desperately around... There! Safety flares are laid out every ten feet on the ground. You snatch one up, activate it, and toss it onto the fire zone. Moments later, it explodes in a plume of smoke and light, obscuring the running figure and instantly halting the gunfire.
*set yell "partial"
*goto shot
*elseif perception > 40
You glance desperately around... There! A whistle hanging on a posts near the firing line! You grab it and start blowing as hard as you can, loosing a piercing shrill that cuts through the gunfire. And safety flares are laid out every ten feet on the ground. You snatch one up, activate it, and toss it onto the fire zone. Moments later, it explodes in a plume of smoke and light, obscuring the running figure and instantly halting the gunfire.
*set yell "yes"
*goto shot
*else
...Somewhere ... Where the ...There! Agonizing seconds later, you spot the safety flares that are laid out every ten feet on the ground. You snatch one up, activate it, and toss it onto the fire zone. Moments later, it explodes in a plume of smoke and light, obscuring the running figure and instantly halting the gunfire.
*goto shot
etc
Also IIRC you have to use the higher number first for things to work correctly. As in the >40 should be at the first if
(someone correct me on this one, though)
Alternatively you could write:
*if ((perception >30) and (perception <40))
text
*elseif (perception >=40)
text
*else
text
Second is if you want this to happen for the stats being either 40 or above.
If you want the first one to be 30 and above, it needs a >= as well
No – not for a single expression like that. CS can handle that just fine (it’s only “two things”).
John: What’s the whole choice block look like, not just that option? What you’ve shared with us looks to me like it should work.
Nope, you’re totally right. All numbers greater than 40 are also greater than 30; no reader would ever see that elseif line, because they would already be at *label shot.
The best way to fix that would be to put the >40 check first, and have >30 be the elseif condition (catching everyone with a stat between 31 and 40).
But if the author was set on keeping the current order of texts for some reason, they could do it with one fewer set of parentheses in each condition than you’ve got in your example.
*if (perception >30) and (perception <40)
text
*elseif perception >=40
text
*else
text
Nothing wrong with slapping everything inside extra parens if that works best for you. Gower does too. It’s just not strictly necessary.
Regardless, that error wouldn’t trigger just because of an unreachable elseif. I think we need to see the rest of the choice and its indents.
I don’t understand your issue, I copied your code exactly like you shared it and it works.
The thing is, since choicescript is made with non-programmers in mind, it has a couple guardrails and hand-holding that can be frustrating. You can’t leave a block in an if-ladder without a goto. You can disable it by creating a variable called implicit_control_flow and setting it to true. This will make choicescript behave like most other programming languages.
If you don’t want to set it for the whole project, you can initiate the variable with value false and temporarily set it to true when needed.
*set implicit_control_flow true
*choice
#Look for some way to get everyone's attention. There are safety whistles and flares nearby...
*set perception %+1
*if perception > 40
You glance desperately around... There! A whistle hanging on a posts near the firing line! You grab it and start blowing as hard as you can, loosing a piercing shrill that cuts through the gunfire. And safety flares are laid out every ten feet on the ground. You snatch one up, activate it, and toss it onto the fire zone. Moments later, it explodes in a plume of smoke and light, obscuring the running figure and instantly halting the gunfire.
*set yell "yes"
*elseif perception > 30
You glance desperately around... There! Safety flares are laid out every ten feet on the ground. You snatch one up, activate it, and toss it onto the fire zone. Moments later, it explodes in a plume of smoke and light, obscuring the running figure and instantly halting the gunfire.
*set yell "partial"
*else
...Somewhere ... Where the ...There! Agonizing seconds later, you spot the safety flares that are laid out every ten feet on the ground. You snatch one up, activate it, and toss it onto the fire zone. Moments later, it explodes in a plume of smoke and light, obscuring the running figure and instantly halting the gunfire.
*set implicit_control_flow false
*goto shot
Yes, but if you’re not practiced/confident enough with the code you’d not know how to structure things to not have things fall through. And it’s a hassle to fix.
Nobody is born knowing how to program in any language. If you prevent people from making mistakes they’ll never learn, that’s the only truth. They are already finding it a hassle to deal with choicescript stiff control flow, otherwise they wouldn’t have made this post. I don’t believe in hiding tools from people, let them know it’s an option and let them decide if they want to use it or not.
Without icf the engine will tell you when it can’t reach a thing.
So that builds up the understanding of how to structure code so that it can reach a thing and then use icf
I reckon it’s pretty safe to say that OP is (like me) a non-programmer, or at least not super experienced. Great for them to know that ICF is an option, and that people with more programming experience often find CS’s guardrails irritating.
But advice-wise, I’m with Meeps. @wurziii – all good if you want to go with cup’s advice and turn off the ChoiceScript guardrails (by turning on ICF), but I’d personally recommend against it. Maybe if you expect this to be your entrypoint to a broader software career, it’s worth getting an early start on coding without the safety net of explicit *gotos all over the place.
But for someone still struggling to find basic bugs, QT and RT are terrific tools, and reducing their ability to help you zero in on the bugs is questionable. At the start, while you’re learning to code within the CS guardrails, you will get some error messages that are just about breaking the guardrails, not about actual bugs in your playable game. That’s annoying, and outright infuriating for people like cup with wider coding experience.
I don’t think that’s the error we’re talking about, though. Nothing in what wurziii has shown us so far should be giving that particular message. I wouldn’t jump straight to recommending ICF until we’ve figured out what the actual bug is.
Wow, I definitely didn’t expect to generate this much thought.
I really appreciate everyone’s input on this. I’m actually a doctor and in all my overeducated years, this is the first time I’ve even thought about writing code so… definitely not a coder at all, and I don’t think taking off guard rails would work out well for me in the slightest . I just decided to write a book in the least efficient and most confusing possible way.
I haven’t the faintest idea how this all works, so I’m super appreciative of the help.
As for the issue, it seems to have resolved. I was just tinkering and then it stopped being an issue. Although the code is still exactly what I posted, maybe something I did elsewhere helped. Like I said, clearly I’m not a coder.
Thanks again all! I’m trying not to post too much, and to figure this stuff out on my own, but the help is very much appreciated!
Woohoo and welcome to the club! Glad the issue resolved itself.
One piece of unsolicited advice about fairmath: %+1 or %-1 will do nothing, because fairmath rounds all fractions down to zero.
Fairmath stats tend toward 50, and can never reach 0 or 100 – but you would have to e.g. have a stat of 0 before %+1 would move you up by a non-fractional amount. I just tried raising a stat of 50 by %+1 a hundred-odd times, to confirm that this hasn’t changed; the stat was still 50 at the end.
Here’s some advice I gave a few years back in how to think about fairmath:
Worth noting that %+5 will stop having any impact once a score reaches 80, and %+10 once it reaches 90. But a fairmath stat that gets to 80 is really high. If you get to 90, it’s probably because you’ve been working with regular %+20 and %+30 bumps in your game.
Haha, “least efficient and most confusing possible way”—I think we’ve all been there! Glad you got the else/elseif sorted out.
That’s some crucial advice about Fairmath, though! For anyone reading this, the single most important thing to remember is that %+/-1 does absolutely nothing since Fairmath rounds all fractions down to zero.
Stick to %+/-10 for a decent stat bump, and know that once you hit ~80, even %+/-5 won’t move the needle anymore!
. I just decided to write a book in the least efficient and most confusing possible way.