Getting handle on a slice created in an ended script?

[Foxley]

Is it possible to assign a variable in a script to a slice handle on a slice that was created in another script, after that script has already ended? Hopefully that makes sense. Basically, I want to be able to do things with this slice after it's stopped animating and the script that animated it has ended, but do so with a different script that will make other things happen to it.

I'm seeing the slice still attached to "map layer 2" in the Ctrl+F4 menu, so I'm wondering if I could do something like get a handle on that slice by referencing map layer 2's child slices. Or something? In any case, I'd rather not have to mess with global variables a lot just for sprite slices just so I don't lose their handle. But I guess I'll have to if there's no other way to do this.

I'm wondering if it would be possible to reference the script handle, and if so, is the script handle number fairly predictable or can it change?

Here's what I'm looking at right now:

[kylekrack]

Could you not just use lookup slice and give it a unique lookup code?

[Foxley]

You gave me the idea of doing this:

Code: Select all

container := first child(lookup slice(sl:map layer 2))

And it seems to be working, thanks!

[TMC]

Nonono, that's a bad idea: what if you parent something else to the map layer in future? What if a future version of the engine does so by itself?

Kylekrack meant assign a lookup code to the slice itself, like this:

Code: Select all

set slice lookup(sl, sli:boulder)
...
sl := lookup slice(sli:boulder)

where 'boulder' is the name of a lookup tag created in the slice collection editor.

However, this is exactly what global variables are for. The only conceivable reason to avoid them here is that after the slice is deleted, the slice handle becomes invalid and shouldn't be used in any way, not even to test whether the slice exists. It's easier to check whether lookupslice returned 0 when the slice doesn't exist.

[Foxley]

Okay, I'll go back to using globals for slices. Does every global in the entire game need to be declared with a unique number? That's why I don't want to use globals that much, keeping track of potentially hundreds of them in the process of developing my game is going to be a pain.

Could I just declare about, say, 10 of them and use them throughout the game for various purposes? Like say, on one map I assign a boulder slice container to 'globalsliceA' and an elevator slice to 'globalsliceB', then in another map I could reuse 'globalsliceA' for a sailing ship slice and do script stuff specific to that map?

[Bob the Hamster]

You will only be making things worse by trying to re-use globals like that. Just have a big list of globals at the top of your script file, they aren't really hard to keep track of.

Every script I write has a big block like this at the top:

Code: Select all

global variable(0, recursion)
global variable(1, growth cycles)
global variable(3, effects)
global variable(4, hero atk frames)
global variable(5, metadata)
global variable(6, find x)
global variable(7, find y)
global variable(8, generating)
global variable(9, stairs ignore)
global variable(10, update counter)
global variable(11, spawn x)
global variable(12, spawn y)
global variable(13, meters)
global variable(14, health meter)
global variable(15, stamina meter)
global variable(16, monster meter)
global variable(17, monster meter ticks)
global variable(18, regen state)
global variable(19, select menu done)
global variable(20, current monster hp)
global variable(21, current monster max)
global variable(22, spawn cultist x)
global variable(23, spawn cultist y)
global variable(24, spawn misa x)
global variable(25, spawn misa y)
global variable(26, spawn bacontologist x)
global variable(27, spawn bacontologist y)
global variable(28, baconthulhu dead)
global variable(29, monster kills on date)
global variable(30, death count)
global variable(31, c:recursion)
global variable(32, c:not okay)
global variable(33, c:okay)
global variable(34, c:zone)
global variable(35, chalk meter)
global variable(36, chalk decay)
global variable(37, jiffy level)
global variable(38, jiffy meter)
global variable(39, cur floor variant)
global variable(40, repel level)
global variable(41, repel meter)
global variable(42, force save steps)
global variable(43, money sl)
global variable(44, passage ms)
global variable(45, baconthulhu anim)
global variable(46, step count)
global variable(47, v:hour)
global variable(48, v:min)
global variable(49, v:sec)

Don't worry about running out of globals.

If you want to keep them semi-organized, you could group them by number, like starting the globals for one purpose at 1000, and the globals for another purpose at 2000

[Foxley]

Even 50 looks scary!

I guess I'll just start a global variable stockpile in a separate . hss and include it in the main .hss, and briefly comment each one in case I can't remember what they're for.

So I take it you don't need to declare globals in order? You can declare 1-25, then 50-100, then 200-300 without it freaking out?

[Bob the Hamster]

Even 50 looks scary!

I guess I'll just start a global variable stockpile in a separate . hss and include it in the main .hss, and briefly comment each one in case I can't remember what they're for.

So I take it you don't need to declare globals in order? You can declare 1-25, then 50-100, then 200-300 without it freaking out?

Putting them in a separate file and including it is a great idea.

Yes, you can declare them willy-nilly in whatever order you wish. You can skip numbers, number them backwards, whatever, just as long as the numbers are unique (and even if you accidentally duplicated a number, you should get a clear compiler error message about it)

[kylekrack]

Wow, that huge list of globals makes me feel a lot better about my own scripts.

[Pepsi Ranger]

Even 50 looks scary!

Wanna see something really scary? Here's what Entrepreneur: The Beginning is currently packing:

Code: Select all

global variable (1,money)
global variable (2,persuasion)
global variable (3,access)
global variable (4,popularity)
global variable (5,reputation)
global variable (6,usedfilter)
global variable (7,newfilter)
global variable (8,coffeepot)
global variable (9,coffeebrewer)
global variable (10,coffeesock)
global variable (11,sugar)
global variable (12,cream)
global variable (13,milk)
global variable (14,vanillacream)
global variable (15,espresso)
global variable (16,vanillaicecream)
global variable (17,crushedice)
global variable (18,sandwich)
global variable (19,soda)
global variable (20,cappuccino)
global variable (21,storepowder)
global variable (22,beangrinder)
global variable (23,hawaiian)
global variable (24,costarican)
global variable (25,italian)
...
...
...
global variable (7700,whippedvanillacream)
global variable (7701,whippedhazelnutcream)
global variable (7702,steamedunpasteurizedmilk)
global variable (7703,steamedsoymilk)
global variable (7704,whippedvanillacapp)
global variable (7705,whippedhazelnutcapp)
global variable (7706,steamedskimcapp)
global variable (7707,steamedunpasteurizedcapp)
global variable (7708,steamedsoycapp)
global variable (7709,whippedvanilla)
global variable (7710,whippedhazelnut)
global variable (7711,steamedskim)
global variable (7712,steamedunpasteurized)
global variable (7713,steamedsoy)
global variable (7714,freshsalt)
global variable (7715,servfreshsalt)
global variable (7716,freshsalttrend)
global variable (7717,difficultytext)
global variable (7718,tutorialtext)
global variable (7719,intromenu)
global variable (7720,difficultymenu)
global variable (7721,easyselect)
global variable (7722,normalselect)
global variable (7723,hardselect)
global variable (7724,customselect)
global variable (7725,randomselect)
global variable (7726,tutorialselect)

And I'm nowhere near finished.

So, never be afraid of global variables, especially not 50 global variables.

Do be afraid of a future where arrays do not exist.

[kylekrack]

My heart, it aches.

[TMC]

That's genuinely scary. I'm surprised you aren't worried about running out of globals; there are only 16384!

[Pepsi Ranger]

That's genuinely scary. I'm surprised you aren't worried about running out of globals; there are only 16384!

Trust me, I am. Especially when you consider the fact that I've been thinking for quite some time about making this into a single-file trilogy.

But then I remember two things:

1. Once upon a time, we had only 4096 global variables available. Now we have quadruple. Maybe we can double it again if needed.
2. You'll likely include arrays before I run out, which means I won't need to run out, since large chunks of my variable list are "stored branches" of a singular use.

So, I'm not that worried.

[Mogri]

Code: Select all

global variable (7720,difficultymenu)
global variable (7721,easyselect)
global variable (7722,normalselect)
global variable (7723,hardselect)
global variable (7724,customselect)
global variable (7725,randomselect)
global variable (7726,tutorialselect)

Something tells me you'd have a lot more free global space if you used local variables for items that don't need to find their way into the save file.

[Pepsi Ranger]

Something tells me you'd have a lot more free global space if you used local variables for items that don't need to find their way into the save file.

Very true. But those variables are used to store slices that I have to close in separate scripts, so locals won't work. I don't think. Not unless open slices can be reassigned to new variables after one script ends and another begins. Then I could make them local. But I've never had success with that.

EDIT: Which, now that I look at the top of this thread again, is the whole point behind the thread. So...maybe I CAN (and screw things up while I'm at it).

The majority of my variables are used across multiple scripts. The ones that are truly local are written locally. I just have a LOT of stored information in this game that persists across saves.