Hi there! I’m testing out using multireplace, but I get this error in quicktest:
Error: arcy line 301: invalid @{} at letter 106; 'method' is equal to 0 which is not a positive number
from this code:
@{method option 1|option 2|option 3}
There’s no way for method to equal 0. Quicktest, of course, tries every option even if there’s no way to reach that option in the game.
But doesn’t that mean that every time you use multireplace for options that start with 1 and not 0, you’ll get this error? And if that’s the case, why is it the default for multireplace?
Right now my solution is adding +1 to it so it starts at 0 and then adding a blank option at the beginning.
@{method+1 |option 1|option 2|option 3}
This seems like it should be the default, rather than automatically triggering a quicktest error.
Oh, my solution works fine. The code that returns the error is:
@{method option 1|option 2|option 3}
It seems weird that the standard way of doing it without adding any other symbols or bits of code to it returns an error, whereas making a few modifications i.e. @{method+1 |option 1|option 2|option 3} seems to be the simplest way to get it to work properly.
This is indeed the correct syntax if method will never be equal to zero.
QT’s purpose being to ensure your code will never cause an actual error in-game, it can be a little… overly zealous in its methods. This situation is similar to how it handles length(word) stuff:
*if length(word) = 1
*set var (word#1)
*else
*set var (word#1)&(word#2)
QT will return a false error on the second*set in the event that length(word) = 1 even though that error could never actually occur in-game due to the *if line itself…
Rather than try to understand why it produces a false error in situations like this, I tend to just go with the notion that it does what it does, and how it does it, for a very good reason – and then try and figure out a different way to achieve the same result without prompting a QT error!
That’s a pretty ridiculous example you gave, ha ha. You have to give Quicktest credit for its dogged no-nonsense interpretation of the law. Like a dog that barks at the doorbell no matter who it is.
At least randomtest won’t return the same error given that it actually has to go through the game choice-by-choice.
I use quicktest pretty exclusively for this particular project because I have a lot of loops (a “hub” system) so randomtest takes literally over an hour to get anywhere (or about 10 minutes if I set it to 1000 instead of 10000 seeds). I think I’m gonna start using that thing where you can set randomtest to auto-pick options instead of pick randomly.
To be frank, I never use quicktest since my few first error reports.
As for the “hubs” and other looping codes, I usually go
*if choice_randomtest
*goto blabla
to make the tester skip over it.
Because in my experience, looping-program bugs usually happen on its loop process (wrong variable setups, invalid *label), not on the checks (*if this *else that).
And for things like this, human-tester is the best IMO.
On the other hand, it can be very useful in catching inadvertent errors to (e.g.) reduce “wasted time” having to re-run a playtest due to running into something like a simple variable name or slight indentation error.
Besides, a game has to pass both QT and RT to be eligible for publication, so it makes sense to be assured of that along the way, rather than leave it all to the end and potentially run into a host of problems (even if just of the fake bug type!).
