Well, i'm working on this code for about 3 hours now, and i can't get it fixed. It is made for an combat system, choosing random atks, but it doesn't really work. it sometimes shows just blanc space. i checked the code trice and can't find any blanc <<If>>'s If anyone could help me, that'd be great!
Here's the code i used
(if only anyone knew how to make these yellow cubes...)
<<set $VariableBada to random(1)>>
<<if $VariableBada eq "0">>
You push the creature on it's back and stab the sword in its belly
<<set $variablebada to random(1)>>
<<if $variablebada eq "0">>
You pierced his armor!
Atk 2 Def 1
<<set $LatestAttack1 to 2>>
<<set $BadabraAttack to 1>>
<<if $variablebada eq "1">>
You couldn't pierce the armor...
Atk 0 Def 3
<<set $LatestAttack to 0>>
<<set $BadabraAttack to 3>>
<<if $VariableBada eq "1">>
/* Insert any other atk here */
If you need the 'decoder' please ask me, but i think it's in this piece of code
PS I used SugarCube 2.18.0 in Twine 2.x
From what I can see you are using the <<if>> macro wrong. The structure should be:
And of course your code will print black screen, since that is what you tell it to do when you say:
You set your variable to be randomly 0 or 1 and the <<if>> macro will then execute your code only if the variable ends up being 0. If it is 1 instead, all you get is empty black space. I'm not even sure why that <<if >> is there in the first place. It doesn't seem to serve any purpose whatsoever. Maybe you should tell us what you want your code to do.
Edit: It might also be a good idea not to name your two variables this similar. Naming them $VariableBada and $variablebada respectively just makes it more likely for you to make a hard-to-spot mistake later on.
The random(1) call returns a number (a integer to be more precise) and it will be either 0 or 1. ... the above condition is comparing the number in the $VariableBada variable against a String representation of the character zero which will not work. So the code should look like the following: ... note that there are no quotes around the number zero. The same change needs to be done with the other <<if>> macros.
Based on your example I believe the structure of your <<if>> macros should be something like the following.
note: Because the variable values can only be 0 or 1, you can use an IF combined with an ELSE to check for both values. ... I have replaced your variable names and left out your code in the above example so that you can see the structure better.
That's mentioned on the Twine Wiki under under logical operators.
I had tried out whether that was the problem and it turned out that the eq operator does work like == and not like ===, so both
work equally here.
The reason the initial code will display a blank screen 50% of the time is because the outer-most <<if>> is lacking an <<else>> with content.
Try that :
I don't have any blank page.
P.S. : "<</if>>" and "<<endif>>" are the same. I just prefer the first one.
And for the coding window, use the "C" in the bar on top of the writting box.
1. That documentation was written for the (vanilla) Story Formats that came with Twine 1. (Sugarcane, Jonah, and Responsive) and not for SugarCube, which is why it has its own documentation about the operators it supports.
In the vanilla story formats is & eq were both aliases for the same mathematical comparison operator (==), where as in SugarCube they are alias for two different mathematical comparison operators (== & ===) which is one reason why Vengefull_Poseidon's code was not working as they wanted because they were also comparing the data types of the two values.
2. The purpose of the recommendation to use the keyword based operators (is & eq) instead of the mathematical operators is to stop people accidentally using = for comparison and == & === for assignment.
Actually they don't 'work' equally but they do both (in this case) result in the expression being true.
Thus why I suggested the final if & else structure that I did.
Yeah sorry - I meant to say both eq "0" and eq 0 equally work , not work equally as I actually ended up typing.
But my core point was that this has nothing to do with why Vengefull_Poseidon's code isn't working as intended. As soon as one either deletes the unnescessary outer <<if>> or puts something into an <<else>>, the code perfectly works every time (although yes - it would be better to it the way you describe).