Multireplace Quicktest error after *if

I’m getting the following quicktest error in scenarios where multireplace is used after an *if statement that limits the possibilities of the variable being called in multireplace:

Error: test line 7: invalid @{} at letter 2; ‘hacked’ is equal to 11 but there are only 10 options

The issue is that the *if statement already limits “hacked” to 1 through 10, but quicktest appears to be testing all possibilities instead. Here’s the code I used to test the issue outside the full game:

*temp hacked 0
*rand hacked 0 11

Hacked is ${hacked}

*if (hacked>0) and (hacked<10)
	@{hacked ||You'll have to be careful not to get noticed.|If you keep winning, it will get suspicious, but winning is addictive!|You know you can only do this a few more times before security gets involved, but winning sure is fun.|You're getting the hang of this hacking device.|You are definitely being noticed.|The croupier is giving you the side-eye.|People are starting to whisper all around you.|}


The above code plays though correctly with no issue.

I’ve encountered this issue in two separate places where the multireplace variable is limited by an *if statement so it seems to be a limitation in quicktest. Is there a workaround that doesn’t involved a huge list of *if statements?

Mnnn… easiest work-around i can think of would be

*if (hacked <11)
  *goto 1
   *goto 2
*label 1
@{hacked 1to10 and identical to 11}
*goto 3
*label 2
*goto 3

Adjust to your needs

The *if doesn’t limit the “possibilities” for the multireplace.

If I have

*if yay < 3
   @{yay hah|yes|omg|whee|lul}

the multireplace will still check [yay] for all possible result, regardless of *if yay < 3

Thanks, Szaal. I guessed that was what was going on, and I’m glad to have it confirmed.

I’m pretty sure I can work around this for my needs, since I’ve only got this issue in a couple places with temp stats and I can fudge them to start at 1 rather than 0 and add empty options past the actual end point.

1 Like

Thanks! I just tested that and it still throws the error. I’m guessing it’s because of the functionality that Szaal describes.

Also, bear in mind that multireplace doesn’t allow zero so that’s going to cause issues as well since you’re allowing ‘hacked’ to be set to zero.

What I would do is:

  • Get rid of the if statement
  • Add 1 to the value of hacked in the multireplace statement @{(hacked +1)
  • Use vertical bars at the start and end to indicate that the first and last entries are blank.

So it’d look like:
@{(hacked +1) | first bit of text | … | last bit of text |}

Notice the vertical bars at the beginning and end. You can have as many ‘empty’ slots delineated by vertical bars as you need, anywhere in the construct. So you don’t need an if statement at all if you’re using the multireplace.


I modified your code for testing purposes:

*temp hacked 0
*rand hacked 1 11

Hacked is ${hacked}

@{hacked 1|2|3|4|5|6|7|8|9|10|11}


Thanks for the help, all.

The testing code I posted is just an example to show what was happening. In the actual game the variable is adjusted in other ways and will always end up outside the parameters of the if statement (which is why the if statement is there in the first place).

I’ve got a workaround for 2/3 of my problem areas. I may end up having to take multireplace out of the final one, since there’s no way to avoid the variable in question being under 1.

You can use @{(variable + 1) text1 | text2 | text3 … } to get around the problem of the variable being set to zero. If it goes below zero by varying amounts there’s not much you can do. The IF statement would prevent the game reaching the multireplace when it runs but Quicktest will still find it and complain. That ‘thoroughness’ can be a godsend or a curse!