This only happens to me with the “ falling out of choice” error, rarely.
Without slopping down my code at the start and going down a rabbit hole. Are there instances where the two tests disagree? I even pluck out the mini scene and test just the problem area, so i know the random test is covering the same code over and over. It is true that these are always *if couched areas so i am putting in the *elseif command also and there is always a *goto, as far as i can see, to close out the sequence. I play the scene and it works perfectly each time. My thought is that my code may be inelegant but functional. Is this a possibility? I clean up the *if cascade but the Quicktest is unsatisfied, but Random test is satisfied. I assumed the Random test is more robust so I move on. I can offer the code too,but, was mostly asking the group if this has happened to them and was it really a problem or just triggered the test error for “bumbliness.” to me if it works, I’m good. Doesn’t need to be the most elegant solution. But I’m newish to coding so maybe I am not understanding a true error. If the scene plays correctly, what could I be missing?
You’d need to post the complete “problem” code to see what’s going on.
Random and quick test work in different ways so often pick up different problems. You need to run both to make sure the game is relatively bug free. I’ve had stuff pass one and not the other and there has been a game breaking code present. I’m not quite sure what problem you’ve got here, but is it a too many recursions error? That usually means you have an infinite loop that needs fixing somewhere and it’ll set random test off from memory.
I tend to prefer relying on randomtest, as it actually emulates “playing” your game. Quicktest is great for catching some simple gotchas, but it can also throw a bunch of false positives because of how it evaluates code (i.e. logs issues that a player would never encounter).
Exactly this. It is by design, they serve different purposes.
In code monkey terms, QT works like compilation, in that it immediately recognizes flagrant syntax errors like mismatched variable names or typos in commands. Meanwhile, RT works more like automated testing or quality control. It simulates playing the game, so the conditions are closer to ecological ones. A common example is, QT will tell you whether you used a variable that hasn’t been declared at all, and RT will tell you whether you put your *temp variable declaration in unreachable code.
…I use this example because this exact thing happened to me last week.
Oh gosh thanks for responding; I’m now having a gosub return issue; before i go posting I’m reading through all the threads. I just use random test now and i just have to understand that i need to run it a lot because I might just random around a problem or get fixated on a problem. I see that coders are putting all their go subs in a file, seems smart wish I started that way. I’m sort of breaking the KISS method I can’t help myself so their are multiple go subs programs; i traced and traced it looks good and plays fine. The big issue is i have random encounters so the encounter is a sub routine so you end back where you encountered it. It works and is really cool but i am 100 percent positive that is causing the problem. Just can’t actually find a problem. I’ve already taken out a few things. No dice. I’m starting to think there isn’t a problem at all.
And to respond to the original problem as it turned out it was a mathmatical variable check problem. Oh god how long to find it. I had my carrot </> facing the wrong way. I could of cried
Ugh, yeah, now I’ve played the actual game and it’s sending me to the right locations. I have half a mind to take out the gosub and use variables to get the player back to where they were. Its just such a god awful tedious thing
And I gave in for the sake of coding and robustness: set variables to mark location then unset them after. Test running…………fingers crossed………….good, and now i have 1003 variables instead of 1000 ha ha just kidding. I have a dark cavern where i needed to keep track of where things were. The player can put down things to keep track of where they go. I just tapped into that tediousness
