Global or local namespace for *temp with *gosub_scene?

Asking preemptorially:

Is namespace local or global within a game script?

Eg:

A *temp variable declared in a scene (not startup.txt)…

---scene Fuz---
*temp foo ""
*set foo "bar"
*gosub_scene Baz

Then another variable with the same name declared in the gosub_scene target…

---scene Baz---
*temp foo ""
*set foo "Boz"

Now what, is the value of foo?

And after returning,

*return

Now what is the value of foo?

Are they the same foo? Is namespace global or local?

Cheers.

3 Likes

*create is global across scenes, *temp persists within the scene in which it was defined. So when you return to a scene (via a gosub), your original copy of temp will be available (the scene you gosubbed to will have a different copy). If you *finish or *goto_scene any *temp vars are lost.

2 Likes

I believe that both of your foos won’t overlap each other, despite being the same name in a same scene.

IIRC, *temp command default-ly has a scope of the whole scene. But if you put it on a subroutine, the scope will be on that subroutine, and will be deleted when the code reaches *return… something like that ¯\_(ツ)_/¯

I’ll try to put the link about that when I found the thread.

Do you think this applies to subroutine scenes?

All *temp variables are scoped to the scene. Also, you have to *temp them all before use. That is to say, they will be dropped every time you leave the scene, either laterally by moving to a scene with *finish or *goto_scene, or by *returning from a subroutine. Subroutine *temps (both normal *temps and subroutine parameters) function in the same way (i.e. they are scoped to the scene).

(As an FYI for any coders, Dan decided to scope parameters to the scene rather than the subroutine, because he figured that would be easier for non-coders to understand.)

Indeed, subroutine scenes have their own scope. I’ve written up an example of using *gosub_scene to simulate scope, a naive recursive Fibonacci generator.

2 Likes