Initializing temp variables in a gosub

Game Development ChoiceScript Help
1

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?

1 Like
2

I don’t know how you set up the *gosub, but be noted that *temp is limited inside the scope of the subroutine.

3

I understood that differently. As far as I can tell it says *temp are scoped per scene file, so if I use two *gosub commands in the same scene file, they can override each others’ parameters.

My code basically looks like this:

*comment for debug menus
*label inittemps

*temp spyconv  0
*temp noniconv 0
*temp kidconv  0
*temp croconv  0
*temp chapconv 0

*return

And the invocation is with *gosub, not *gosub_scene, so no new scene is loaded.

4

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?

1 Like
5

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.

6

What is the exact error quickest is throwing?

1 Like
7

The code:

The code

The subroutine:

*comment for debug menus
*label inittemps

*temp kidconv  0
*temp tourpal  false

*return

The invocation:

      *if ((debug_char = 2) and (route = 3)) #Jump to DTB3 with Lux.
        *label farah_taj_dtb3
        *gosub_scene debug int_r3_dtb3
        
        *comment temp vars
        *gosub inittemps
        *set tourpal true
        *set kidconv 2
        
        *goto dtb3

The error:

2heir
executing
2heir,goto nolix_kidia_dtb3
2heir,goto farah_taj_dtb3
QUICKTEST FAILED
Error: 2heir line 190: Non-existent variable ‘tourpal’

Edit: line 190 is *set tourpal true of course.

8

I see

2heir,goto nolix_kidia_dtb3

If Nolix Kidia has similar format with Farah Taj, my educated guess would be the redeclaration of *temp, and QT hates that.

1 Like
9

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.

10

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.

2 Likes
11

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.

1 Like