Quicktest acts up with arrays in unreachable code segments

Game Development ChoiceScript Help
1

In my startup file, I have the following code:

*create class 0

*create arrClass_1 "Pied Piper"
*create arrClass_2 "Instigator"
*create arrClass_3 "Inadequate Ranger"
*create arrClass_4 "Unhinged Pyrodancer"
*create arrClass_5 "Self Saboteur"
*create arrClass_6 "Exhibitionist Grappler"

Inside my choicescript_stats, I have this:

*if (class != 0)
    Class: ${arrClass[class]}

If I run the game, everything is fine and dandy, but if I run Quickest, I get the following error:

QUICKTEST FAILED
Error: choicescript_stats line 137: Non-existent variable 'arrclass_0'

This is technically true, arr_class_0 does not exist. But the game should not execute that code in the first place anyway because it’s behind the if statement.

A goofy fix would be to add this in the startup file
*create arrClass_0 "Bug fix"
But it would be kind of hackish since when I will switch to the *create_array command, it will start the array from index 1 instead of 0.

But I’m interested if there is a way to fix this behavior.

2 Likes
2

Yeah, I’ve had a problem of this sort before. If you want to fix it without creating arrclass0, then you would have to find a way not to mention or imply the variable in your code. Personally I’ll just create the variable as a sort of bug check.

PS: It seems you’ve not shown us the complete code?

3

The code shown is the only code that’s relevant to the issue. Quicktest fails as soon as the game starts, it does not get to make any other choices, it just crashes because it tries to reference arrClass_0 even though it should not because the *if(class != 0) would not pass.

This problem does not happen if I run the game. The section just does not appear in the stats screen, as intended.

4

I was thinking it has something to do with the elseif/else statements. However, if the bug only comes with quickest, you could try ignoring it. Quickest seems to think that if class can be “not zero”, arrclass can also be “not zero”. This implies that class can be zero and arrclass can also be zero (I hope that made sense).

5

I believe that’s how quicktest is, it doesn’t realize the value can’t be zero because it at the same time tests both the cases where the if clause is true, and where it is not (it doesn’t care if both options actually can happen). (Although why it expects there to be index zero, if arrays start at index one, is beyond me. Unless I misunderstood and they by default do start at zero.)

3 Likes
6

I guess that’s what happens (it goes through every line and replaces it with certain values without checking the bigger picture), but why it’s designed to work like that is beyond me.

7

Hmm. I may be wrong, but what if it is a problem with how primitive data is processed in the javascript layer that reads and interpret choicescript scripts we declare when we *create class [number_value]?

As in Javascript 0, “0” and [false] are not the same kind of data type. But in choicescript we can declare a variable as a number, test it as a boolean and even concatenate it’s value as if it was a charactere. This kind of weak language woestruck may be the cause to the losing of cohesion in the quicktest.

maybe he sees the class variable as a string during the test, but still compare it to a numeric value in the logical gate “IF”.

So, this way you get a “0” value that is a character rather than a number, hence the:

*if (class != 0)

resulting in a true statement where a:

*if (class != "0")

wouldn’t.

My two pennies.

8

I understand where you are coming from, but that does not seem to be the issue, even if I try

*if (class != "0")

the issue still persists

It still happens even if I declare an explicit boolean variable above and use it as the flag

*temp test false
*if (test)
    Class: ${arrClass[class]}

Still, this error happens only for quicktest, not for running the game. It’s almost like quick test replaces every line with every possible value while ignoring all the lines of code above it.

1 Like
9

fascinating!

So, its in the way quicktest is working the… tests?

As in:

  1. check first if a variable is declared, before

  2. run the branch where the code that manipulates it is located?

10

Honestly, I have no idea how quicktest runs under the hood. @CJW Can you help us understand why quicktest runs through logically impossible branches?

1 Like
11

As @LiliArch has implied, QuicktTest doesn’t actually “run” your game. It scans the code for inconsistencies, so will check both branches of every if. It has no way of knowing what values would be possible at runtime, so it uses your startup value iirc. So you’ll probably have to modify that, or their might be an “*if choice_quicktest”, I know there’s definitely an “*if choice_randomtest”.

12

That actually makes sense!

In other languages the code compiler always execute a semantic analysis to know if all the variables used are properly declared. So the error is that quicktest is checking up if arrClass_0 is properly declared. In this case you can fix that by literally declare a temp variable:

*temp arrclass_0 ""

lol!

edit: Hmm. can we declare temp variables in choicescript_stats.txt? I never tried that…

13

It’s good to know that quick test does not actually run the code. *if (choice_quicktest) does not fix the issue, but even if it did, it’s a less clean solution than declaring the offending variable.

Yes, you can declare temp variables in the stats file. However, I’m gonna go with my first workaround of declaring the arrclass_0 variable in the startup file to reduce code clutter in the stats file.

1 Like