Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Error in

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 :D (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
Het duogevecht
<<set $LatestAttack1 to 2>>
<<set $BadabraAttack to 1>>
<<endif>>
<<if $variablebada eq "1">>
You couldn't pierce the armor...
Atk 0 Def 3
Het duogevecht
<<set $LatestAttack to 0>>
<<set $BadabraAttack to 3>>
<<endif>>
<<if $VariableBada eq "1">>
/* Insert any other atk here */
Het duogevecht
Intro
<<endif>>
<<endif>>


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

Comments

  • edited June 2017
    Don't use "eq" - it's use is no longer recommended. Instead use ===" or "is":
    <<if $VariableBada === 0>>...<</if>>
    

    From what I can see you are using the <<if>> macro wrong. The structure should be:
    <<if $VariableBada === 0>>
    ...
    <<elseif $VariableBada === 1>>
    ...
    <</if>>
    

    And of course your code will print black screen, since that is what you tell it to do when you say:
    <<set $VariableBada to random(1)>>
    <<if $VariableBada eq "0">>
    ...
    <</if>>
    

    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.
  • idling wrote: »
    Don't use "eq" - it's use is no longer recommended.
    Could you supply a link to that recommendation? Because the documentation for the <<if>> macro makes no mention of that fact.

    The random(1) call returns a number (a integer to be more precise) and it will be either 0 or 1.
    <<if $VariableBada eq "0">>
    ... 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:
    <<if $VariableBada eq 0>>
    
    ... 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.
    <<set $varA to random(1)>>
    <<if $varA is 0>>
    
    
    	<<set $varB to random(1)>>
    	<<if $varB is 0>>
    
    	
    	<<else>>
    
    	
    	<</if>>
    <<else>>
    
    
    <</if>>
    
    ... I have replaced your variable names and left out your code in the above example so that you can see the structure better.
  • edited June 2017
    greyelf wrote: »
    idling wrote: »
    Don't use "eq" - it's use is no longer recommended.
    Could you supply a link to that recommendation? Because the documentation for the <<if>> macro makes no mention of that fact.

    That's mentioned on the Twine Wiki under under logical operators.


    greyelf wrote: »
    The random(1) call returns a number (a integer to be more precise) and it will be either 0 or 1.
    <<if $VariableBada eq "0">>
    ... the above condition is comparing the number in the $VariableBada variable against a String representation of the character zero which will not work.

    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
    <<if $VariableBada eq 0>>
    

    and
    <<if $VariableBada eq "0">>
    

    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.
  • edited June 2017
    Hi,

    Try that :
    <<silently>><<set $VariableBada to random(1)>><</silently>>
    <<if $VariableBada eq "0">><<set $variablebada to random(1)>><br>
    You push the creature on it's back and stab the sword in its belly
    \<<if $variablebada eq "0">><<set $LatestAttack1 to 2; $BadabraAttack to 1>><br>
    \You pierced his armor!
    Atk 2 Def 1
    [[Back to the fight!|Het duogevecht]]<br>
    \<<elseif $variablebada eq "1">><<set $LatestAttack to 0; $BadabraAttack to 3>><br>
    \You couldn't pierce the armor...
    Atk 0 Def 3
    [[Back to the fight!|Het duogevecht]]<br><</if>>
    \<<elseif $VariableBada eq "1">><br>
    New Attack
    [[Back to the fight!!|Het duogevecht]]
    [[Back to the Begin!|Intro]]<</if>>
    

    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.
  • edited June 2017
    idling wrote: »
    That's mentioned on the Twine Wiki under under logical operators.
    Two points:

    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.

    idling wrote: »
    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
    <<if $VariableBada eq 0>>
    

    and
    <<if $VariableBada eq "0">>
    

    work equally here.
    Actually they don't 'work' equally but they do both (in this case) result in the expression being true.

    The first is comparing two values of the same integer data-type, the second is comparing an integer with a String. To do the second comparison the Javascript environment has to first convert both of the values to the same datatype, it does this by guessing your intent and more than likely temporarily converting the value in the variable to a String before doing the comparison. Relying on the Javascript environment to always get that guess right is not a good idea, which is why I suggested using a numeric instead of a String literal for the zero.

    idling wrote: »
    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.
    Thus why I suggested the final if & else structure that I did.
  • greyelf wrote: »
    idling wrote: »
    That's mentioned on the Twine Wiki under under logical operators.
    Two points:

    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.

    idling wrote: »
    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
    <<if $VariableBada eq 0>>
    

    and
    <<if $VariableBada eq "0">>
    

    work equally here.
    Actually they don't 'work' equally but they do both (in this case) result in the expression being true.

    The first is comparing two values of the same integer data-type, the second is comparing an integer with a String. To do the second comparison the Javascript environment has to first convert both of the values to the same datatype, it does this by guessing your intent and more than likely temporarily converting the value in the variable to a String before doing the comparison. Relying on the Javascript environment to always get that guess right is not a good idea, which is why I suggested using a numeric instead of a String literal for the zero.

    idling wrote: »
    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.
    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).
  • idling wrote: »
    But my core point was that this has nothing to do with why Vengefull_Poseidon's code isn't working as intended.
    You are correct, it was not the main cause of their issue but it was still an error in the example code which is why I pointed it out.
Sign In or Register to comment.