*if statements within *choices causing failures in random test sometimes? - Solved

This has been happening a lot in the game I’m currently working on. Can anyone see if I’m doing something wrong? Or is it a bug with the random tester. It seems to get upset if I’m using *if statements with choices within choices and makes me double up on the *goto at the end in order to pass. (Example below.)

This is the error:

This is an example sequence (It passes now because of the extra goto):

1 Like

Have you tried changing the second if to else? Does it work then?

2 Likes

Hey that does work. Weird since I’ve basically said the same thing with the if statements, but it does pass without the second goto with an *else. Thanks.

image

1 Like

Definitely change that to an else. When you include an else clause, the compiler knows for sure that every possible scenario is accounted for.

Edit: ha! Ninja’d.

2 Likes

*else should work fine, but also check the values you’re testing.

Right now, in your first example, your two possibilities are *if (voice > 29) and *if (voice < 30), but that doesn’t cover cases where voice = 29 or voice = 30.

Using:

*if (voice > 29)

*if (voice <= 29)

should work.

1 Like

Yeah it does :slight_smile:
voice>29 is the same as 30 or more
voice< 30 is the same as 29 or less.

(Isn’t it? Now you’ve got me worried.)

1 Like

Fractions, Jacic. That’s why using elseif and else is best practice.

1 Like

In practice, it probably works out that way? But on the most technical level, no. Not at all. It’s more like “29.00000001 or more”.

As above, it probably should be, at least in practice? But technically this would be more like “29.99999999 or less”.

Written like this, there’s some overlap. 29.5, while it may not actually occur during gameplay, would trigger both if it could occur. Maybe randomtest is somehow picking up on that?

Err, quicktest, not randomtest. Sorry.

2 Likes

Sorry, you’re right that your original code will handle cases where voice = 29 or 30. Not enough coffee here. But I do think the overlap in hypothetical values between 29 and 30 may be what’s triggering the randomtest error.

Yeah you’re probably right. I’m not using fairmath, so that shouldn’t happen but random/quicktest doesn’t know that!

@Amtelope haha that’s fine. It’s 2.30am in the morning here and I suddenly had this horrible feeling I’d mis-coded and entire chapter through lack of sleep :sleeping:

2 Likes

This should work just fine if not accounting for floats.

Still not touching on the core of the problem, which is quicktest doesn’t care. It cheats and assumes both sides of all *ifs are possible to both pass and fail to check every line.

Quicktest will come to this line:
*if false
   and yes, will even test assume this line is possible to reach and test it.
It will continue to this line:
*if true
   and while every real playthrough will stop here…
   *finish
…quicktest will still test this line because it runs both sides of every *if.

Quicktest often times produces fall positive bugs. It’s meant to, to prevent other, harder to detect, bugs getting through.

4 Likes