My largest chapter in my WIP relies on an ill-advised number of *temp variables. In my pursuit of quick debug code that will allow me to jump directly to the part of the game I’m currently testing, I tried moving the initialization of these temp variables from the beginning of the scene file, into a *label that can be invoked by *gosub.
When I playtest this, it works well and serves the exact purpose I had hoped for – two clicks, and I’m at the part I need to test.
However, it fails quicktest.
I can’t reasonably continue developing without quicktest, of course, so if I can’t make it work I’ll revert to a simpler version of the testing code… but I’d rather not. I haven’t dug into how the variable initialization works behind the scenes, so I don’t know if this is a limitation of the scripting abilities, or a feature that was added to CS by design. I could conceivably convert the variables in question into regular old *create statements… but that’s a lot of work.
Has anyone ever tried initializing *temp variables in a gosub?
I would imagine that declaring a temp variable a second time would simply overwrite its value with the new one but it’s something I’ve always tried to avoid doing - probably out of habit since doing such things in other languages generally raises compiler errors. What error was quicktest throwing up?
But if you’re initialising them to all to zero and, presumably setting the values elsewhere, why would you need to call that subroutine more than once anyway?
Not more than once sequentially, more than once in the file. The goal was to be able to jump into some code in the middle of the scene. The temp inits were at the beginning of the file before I moved them.
Hmm. That seems like a plausible explanation, except that those two bits of code are competing options for the same *choice block. They should never be invoked in the same playthrough. However, it’s still bad form to declare variables more than once, and I guess I need to consider serious restructuring.
QuickTest infamously likes to “cheat” and this can often cause it to throw false positive errors. As you mentioned, when you play the game (and probably also when you run randomtest), everything will work fine.
I’m not sure what COG’s stance on this is. Most likely, yes, as much of a pain as it is, you’ll need to restructure your code to play nice with QT.
I know from my own experience that normal temps created using the *temp command remain available for the duration of the scene, and that if redeclared, it simply overwrites the variable with the new value. This doesn’t apply for the special temps created by things like achievement checks or params however.