Just curious. Is there any real difference between putting " *choice " as opposed to " *fake_choice " ? Does one change the page in a different way or show up differently than the other? For me it appears as though they are virtually the same.
Any help would be appreciated. Thank you.
a *choice requires directions for each choice (e.g - *goto) whereas a *fake_choice doesn’t. In a *fake_choice, it will just continue to the next thing outside of the paragraph of that *fake_choice. Not really a lot of difference.
Ah ok. That makes sense. Thank you for that!
Also beware of nesting *fake_choices, I heard it causes buggy behavior. So if you have a long nest of many choices inside one another, it’s best to use *choice.
What @ElvesForTheWin said about the *goto is true. However, it is possible to remove the requirement of *gotos on *choices, *elseifs and *elses by using implicit control flow.
Basically, *choice is used for branching and *fake_choice is used for linear decisions.
Uh…what? lol what is that?
In CS each option of a *choice must end with a *goto otherwise it will throw an error. This also happens when *elseif or *else is used. You will get this error if you do not use the *goto:
It is illegal to fall out of a *choice statement; you must *goto or *finish before the end of the indented block.
It is illegal to fall in to an *else statement; you must *goto or *finish before the end of the indented block.
Implicit control flow is an optional setting you can use to disable this error message, allowing you the option to use *goto at their ends or not. I like it because it removes the need for redundant *gotos and *labels after the *elseif and *else.
So imagine you want to do something like this:
*if (money >= 20)
You pay 20 bucks and buy the tanktop.
*else
You don't have enough money to buy it.
On CS it wouldn’t work because of the requirement of having a *goto at the end. You would need to do this:
*if (money >= 20)
You pay 20 bucks and buy the tanktop.
*goto afterTanktop
*else
You don't have enough money to buy it.
*goto afterTanktop
*label afterTanktop
As you can see, that’s redundant since the code could just continue down. By using implicit control flow, you don’t need to add this *goto and *label, the first example would work.
More info here:
“…Is it possible to learn this power?”
Uh…like it was said on the thread I linked, just add this at your game startup:
*create implicit_control_flow true
Enjoy no more redundant *goto/*label pairs, but be mindful that this also removes the requirement on *choices too, so if you wanted to actually include a *goto in one of the *choice options and you forget, there won’t be an error message to remind you any longer. But thats the only con really.
Sorry. It was a sad attempt at a joke 
Thank you kindly good sir. You’ve done a great service and cut down a lot of time for me. 
Don’t worry my guy I got it 
AG, stop trying to make implicit happen. It’s okay to use for testing, but in a published thing it only causes trouble. D<
Doing anything implicitly makes it easier to do it by accident and end up with something that’s wrong but doesn’t crash.
@rinari ^this
implicit skips odds and ends that randomtest etc might stumble over and the like. having it activated upon publishing can easily cause chaos due to a variable that should not be empty suddenly being empty and the game skipping straight to the end (who was it again who had that happen?)
I think you missed the part where I said it was optional and mentioned the “con”.
The only problem caused here is if the author makes the skeleton of the choice and then later forgets to put whatever he meant in there. And then the code simply follows down. You’re blowing this way out of proportion, it simply behaves as a *fake_choice, it won’t cause the universe to go boom.
This isn’t about “trying to make implicit happen”, the meme image was just a joke. I’m just telling them about it in case they prefer it that way; when I programmed in Java there was no sort of thing like this *goto requirement on *elseifs/*elses, and now it’s a lot better for me when I found out I could get rid of it. If you don’t want to use it that’s fine, but there’s no need to come saying it’s wrong to tell people about it so they can make up their minds if they want to use it or not.
And I don’t even mind about the need for *goto after the *choice. Just the one after *elseif and *else that bogs down the code. Many programming languages don’t use this sort of thing.
Also, there are CoG games published that do use implicit control flow; just check Choice of Magics code and you will see it turned on there.