Ultimate Noob Coding


#41


#42

Ah that’s helpful, thank you. Do you have *create symbol "" in startup? (Also, you probably know this, but once you correct an error you can either clear it manually in the Issues Tab, or you can clear the whole lot at once with the ‘Dismiss All’ button.)


#43

So I have to create variables in startup before I can set them in chapter 1? I did not know that. Should I create more variables just to have them for future situations?


#44

Variables either need to be created in start-up or as temporary variables prior to their use in the script.

I usually have a set of “permanent” variables that carry over from one part of the story to another and a set of temporary variables that I set at the beginning of each section (chapter) of the story.


#45

Since this text only impacts this one part of one scene, it seems like it would make the most sense to do temp variables.

Would I do that by listing *create temp var “)” and so on at the top of the scene, and then *set temp var “)” in the choice, and then use the *if command where I want the alternate text to show up? Or am I way off base?


#46

It should be *temp var ")" to create the local variable var, and *set var ")" to alter it (as with global variables).


#47

Right, and in this case, you’d want *temp symbol ")" and *set symbol "*" (or whatever) in the text.

'var' is just a placeholder when discussing variables (in case that wasn’t clear—if it was, sorry to over-explain). And you can make as many temp variables as you need, but they’ll only last for the one scene, as @Eiwynn was saying, unlike variables made by using *create in startup.


#48

There is no over-explaining, I can assure you (and no, I did not know; in the temp section of the wiki it just uses the temp var verbiage, I had not realized that was just a generic term. I thought it was the actual command). I promise to be zero percent offended no matter how much anyone talks down to me, because it is better to start super low level and work up than the inverse. Especially since Inhave proven super low is where I am currently. I already look forward to my second HG title, where I can focus more on just writing because the code will be more known.


#49

Success! It worked like a charm! Had an error for a moment but it was just text being indented that wasn’t part of a choice. With this I should have enough new stuff to justify an update to the WIP thread. Y’all rock!


#50

Hey gang! Been making some headway, but I got to my first skill check and hit an error. I think it is just an indent issue. I know it goes *if (Stat name > X) and then you put the text, then a finish or goto, then the *else for the fail and the same thing. But where do the if and else ident under? The original *choice or the #option?


#51

I’ll give you an example of our faithful and innocent MC, Bob. :child:

Bob, do you want the Coca Cola, Pepsi, or Fanta?

*choice
  #Coca-Cola
    *if thirsty
      You grab the red bottle and drink the soda directly from its bottle
    *if perfectionist
      You pick a wine-glass and pour the soda to it, twirl it around, and then drink it
    *else
      Nah, you just drink it like a normal ppl would.
  #Pepsi
    *if thirsty
      You grab the blue bottle and drink it.
    *else
      Woops, the bottle slipped from your hand and begin bursting out, flying through the whole room with that pssshhhhh sound.
  #Fanta
    You're tired of black-brown-ish liquids and grab a colorful of Fanta.
  #I don't drink. I breath  
     Yes, you're an alien.

#52

OK, so you are saying there does not need to be a goto or finish after each one? Maybe that is why I errored out. And the indent is equal to where the set and other things would be it looks like.


#53

At this moment in time, you do still need a *goto (or other redirectional command) following each *if and *else when the two are used together. This may (or may not) change in the next version of CS, but right now that’s still a requirement to avoid error.

You also have to be careful where you fail to use an *else. For instance, while this is perfectly valid—

*if thirsty
      You grab the red bottle and drink the soda directly from its bottle
*if perfectionist
      You pick a wine-glass and pour the soda to it, twirl it around, and then drink it

—in the event that the PC is both thirsty and a perfectionist, the response narrative would read—

You grab the red bottle and drink the soda directly from its bottle You pick a wine-glass and pour the soda to it, twirl it around, and then drink it

—which is probably not the intended result.

You can use an *if *else for either the #options themselves or within a particular option body, or both—and yes, their use would follow normal indentation rules of always increasing by one more level where applicable, as follows:


*choice
  *if (var1 != 0)
    #This is option 1 text
      *if (var2 = "thirsty")
        Response narrative or *sets go here.
        *finish
      *else
        Response narrative or *sets go here.
        *finish
  *else
    #This is option 2 text
      *if (var2 = "thirsty")
        Response narrative or *sets go here.
        *finish
      *else
        Response narrative or *sets go here.
        *finish
  #And this is an ordinary (non-conditional) option.
    Narrative goes here.
    *finish

#54

Thanks to both of y’all! I realized the indent thing just a moment ago; CSIDE was trying to tell me all along by auto-indenting further when I did my *if command. I had just been ‘correcting’ it to have less indentation. It looks we are still moving right along.

And good to know about the if stuff when it might potentially involve a non-binary situation where more than one of the possibilities could occur. In this case it was just whether a stat was greater than 14 or not, so no issues kicked up there. I guess doing it that way without an *else could still have been achieved, though it would have required an extra line (the success one for > 14, the fail one for <14, and the fail one copypasted for = 14). But it still would be valid, as I understand it.


#55

You can also use >= and <=, thus:


You have a number of things.
*if (things > 14)
    That number exceeds fourteen.
*if (things <= 14)
    You have, at most, fourteen of the things.

#56

If you need all three cases specified you can always *if / *elseif / *else, of course, but if both less than and equal 14 are in effect identical then <= or >=… gets ninja’d by @Fiogan. :grin:


#57

Gotcha. Wasn’t sure if there was a way to easily represent less/greater or equal to on a keyboard, since the mathematical symbol for it cannot be typed. Interesting that you do not put a space between the less/greater sign and the equal sign, despite having a space between both and the variable and number involved.


#58

I tend to think of the parsing (is that the right word?) as [variable] [operator] [number], at least with numerics. Fairmath is like that too, %+ goes together because it’s the operator.

Although, you may not even need the space between the operator and the number, I’m not sure. I always use it, but I think I’ve seen it both ways?


#59

Yep, CS generally manages fine without the extra spaces on command lines, but it’s horrible for many people to read and definitely not good for giving examples!

@hustlertwo As @Fiogan says, arithmetic operators and those used for conditions do themselves need to use the correct syntax to avoid error.


#60

Hey hustlertwo. I’m sorry to hear that you’re having some issues with CSIDE. I couldn’t help but notice this comment inparticular:

If you have any further issues, or if the above happens again, please don’t hesitate to drop some feedback (good or bad) in the CSIDE thread, so we can work on improving the experience. :slight_smile: