Better to 1 or to 0 with numeral variables

Game Development ChoiceScript Help
1

I’ve been running into this a few times: When I use a numeral variable to keep track of continuity quick- and random test do well when it is a
*create var 0
until i get into a subscene
Then QT stumbles over executing things. Only in subscenes, never in chapters.

So, should numeral vars be created with a starting value of 1 or should I just change the guilty party to one for testing?

2

I’ve had a lot of trouble with numerical values and multireplace.

*create var 0
*set var 1
@{var one|two|three}

That creates an error. It starts at 0, but there’s no 0 option in the multireplace.

You could go *create var 1 but I don’t trust it, and sometimes I want the variable to be 0 as in “not set yet”.

So, here’s how I format the multireplace:

@{var+1 |one|two|three}

It’s ugly but there are never any errors. Unless I go @{var+1 one|two|three} but I know to do a CTRL+F for that one.

2 Likes
3

multireplace, funnily enough never gives me an error here. but anything that requires a positive number in a subscene does.
it’s weird

4

Can you provide the error and an excerpt of your code?

5

I’ve generally found this is because Quicktest is overzealous.

If you have code like

*temp faction_selected 0

Choose the faction you want to join:

*fake_choice
   #The Great Serpent
      *set faction_selected 1
   #Machinists
      *set faction_selected 2
   #Laser Mice
      *set faction_selected 3
   #Nobody

*if faction_selected != 0
   Your fellow @{faction_selected snake scales|engineers|rodentia} welcome you @{faction_selected coldly|with a disinterested shrug|warmly}.

QT is going to complain that faction_selected is 0 in that multireplace, even though the code can never reach that line in actual play if that is the case. So I end up having to throw lines like

*if choice_quicktest
   *set faction_selected 1

at the top of every optional block like this, even though logically it shouldn’t be necessary.

6

It’s that kinda stuff.

In my case it’s errors like this:

Error: 4_scpreacher line 1720: invalid @{} at letter 70; 'mcsize' is equal to 0 which is not a positive number

referring to this line:

@{mcsize bit taller than I| around me height| 'bout this smaller than I}?"

(yeah, QT decided multireplace should give me trouble now too >_> )
and this bit in a sub_scene:

Error: sub_dreams line 10: invalid @{} at letter 223; 'dream1' is equal to 0 which is not a positive number

referring to this line:

*if (dream1 =1)
   It... was one of'em fancier hotels. All complicated twisty, err... filigree?"

So far none of these variables is altered with a *set +1, but with a direct *set 1 (etc)

Curiously multireplace and *if trees where the variables are altered with +1 go through smoothly

1 Like
7

My @{var+1 |1|2} solution fixes that too! :slight_smile:

1 Like
8

I think with that way you’ll have add an additional bit once you set the variable, if I understand this correctly.

2 Likes
9

Yeah, you won’t be able to catch actual coding errors with an improperly unset variable in that case, it will just silently display nothing.

You’ll need to say @{(var + 1) ERROR|1|2} and search through Randomtest’s output for the word “ERROR” to check for that, then.

10

What worries me is that the qt and rt upon submission won’t pan out, about the same as I’m worried to miss a choice where I do set something +1 and end up with a wrong result

I know what is meant here, but … the game itself is working fine, it’s just really the submission QT that worries me.

e.g. the ‘mcsize’ variable gets set even before the game starts, so by the time of ch4 it’s definitely having a positive value.
will the submissions stuff work without having to set these to 1 in the startup?

edit:
cause right now it’s like this:
There’s a couple of variables that are steadily increased to keep track of the MCs progress with things (romances, sidequests etc) and i’m very worried something will get messed up along the line if I have those variables start out as 1.

Curiously QT has no problem with variables being increased with *set var +1
so… it’s all very confusing

11

If Quicktest passes when you run it on your code, it will pass when the team runs it. (Assuming you aren’t running some old version from years ago or something.)

1 Like
12

This is what i worried.
Well, so far the error at least only occured at steady variables, so i can probably create them as 1 in the startup.
Still eehh

13

Mmm, that might be a bad idea. I believe the best solution is to just put this right before any line that gives you an error about mcsize, for instance:

*if choice_quicktest
   *set mcsize 1
14

Thanks.
Though I think with variables like mcsize I’ll be fine, as they are set like this:

*fake_choice
   #I'm definitely smaller than that.
      *set mcsize 1
   #I'm around that size.
      *set mcsize 2
   #I'm definitely taller than that.
      *set mcsize 3

so picking the first option won’t actually change anything (it’s even not necessary to have it there, i think, but I’ll keep it, just in case)

15

True. As long as you can ensure the player will always reach that *fake_choice, starting that variable at 1 won’t make a difference.

16

So far ALL these variables are guaranteed to be reached… just QT is being a brat