Multireplace Error

I went ahead and changed all my multi-replace variables to be created with a value of 10 in startup.

Now – time for me to rest :slight_smile:

4 Likes

I noticed this happening to me too! I started using @{test+1 |example1|example2|example3} and that always seems to work.

1 Like

I know the problem has been identified and there’s nothing incorrect in your code. But I did say I’d write something about manual testing and you might find it useful in any case. As per CJWs post below, the issue described in this post is attributed to a bug with quick test, I posted this as I was discussing manual testing with Eiwynn and it wouldn’t help in this specific circumstance.

There’s a million things to discuss about testing strategies and methods, but the pertinent bit to your situauton is this:

You had a piece of code that on the face of it should work, but isn’t.
The error (variable = 0) suggests strongly that the variable is set incorrectly (as 0)
But the auto test process is mostly just returning success or failure (under different conditions) and not really telling you what is wrong.

The advantage that manual testing has is a) You can control what is happening and b) You can see what is happening

The crucial thing to know first is what is the value of the variable at the point when the multi replace runs, because if it is 0, then it is set incorrectly. If it is 1/2/3 then your multi replace code has an error.
One of the most useful things you can do is print variables you are interested in ( ${chutemr} ) - simply putting that in your code at a point where you want to see the value immediately tells you whether it is set correctly (in your case, remove the multi replace temporarily and insert the print statement - this allows the code to run without error and you can view the value at the point when the multi replace would run).

By running the game manually you are playing it in the manner intended (i.e. sequentially, from scene to scene - removing any weird nuances from quick test). You then get to the printed variable in the correct manner and can therefore see if, under normal conditions, the variable is correctly set (and test it out for all the different ways of setting that variable (namely: the three chute options, but also saying ‘no’ in the ‘are you sure’ choice and then changing your mind AND selecting the same option again) - you then confirm that normal play yields the correct value for the variable. You then also confirm that the multi replace works correctly too (at least in this case)).

You can then more easily see at which point the game errors out, or which variable is incorrect and which pathways causes the errors - it massively helps reduce the search space for where the bug might be.

For shortcuts when manual testing.
The first thing to remember is that your error is localised and (likely) independent - therefore you don’t need the entire game running in order to replicate it. In this case, you are literally interested in one variable (chutemr). So you can bypass all the preceeding scenes as they don’t affect chutemr.

To do the manual test, you need to set chutemr, then run the multi replace. If the setting occurs in scene ‘Scene_12’ then in your startup you just put a *goto_scene Scene_12 and skip everything in the game, set the variable and then move on to the multi replace. You can then restart the game over and over to test the different conditions very quickly.

The one thing to consider is if Scene_12 does rely on other variables, you might need them to be set for it to work correctly (but I don’t think so in your case).

Well, that ended up longer than I expected… Good procrastination from my own writing.

5 Likes

Not to undermine your post (really, thank you for sharing it!), but I do want to say (for future readers) that in this circumstance, I really don’t think manual testing would have helped. I’d honestly go as far as to describe it as quicktest being buggy: it shouldn’t be complaining about things that can’t actually happen for a player.

Printing the value wouldn’t work because the path in which the value is 0 can’t actually happen in a manual playthrough, and quicktest doesn’t output text.

Again, not to undermine a very informative post, just a heads up for those facing issues similar to Eiwynn’s.

6 Likes

Thank you @Sinnie for your rundown on manual testing. I shall now be able to use that method.

I did not realize you can tell the game to go to any scene by putting such a command in start-up.

That seems like a command that Dan would not allow to function, due to the ability to screw things up if used wrongly by a beginner, or someone, like myself, who is not a good scripter/coder.

I’m going to take some time to digest everything and then get back into advancing the development of the project in question

Thanks to everyone that helped me understand the issue.

:two_hearts:

7 Likes