editor_type() - values 2 or 4 nuke attached script?
okay, getting my head twisted on this...
does changing a sprite (which has a script attached) placed via the editor on a screen to
editor_type(sprite, 2)
or
editor_type(sprite, 4)
in that script actually nuke the script attachment?
I know the background values of 3 and 5 probably do, since making a sprite a background one in the editor means no script works... I think.
But editor_type values 6 to 8 return the sprites (usually enemies) with their respective scripts attached.
Can work around this via the editor type 0 and storing the new image values I guess, then using sp_pseq() and sp_pframe() with retrieved values, and still keep the script attached but it seems a clunky workaround...
does changing a sprite (which has a script attached) placed via the editor on a screen to
editor_type(sprite, 2)
or
editor_type(sprite, 4)
in that script actually nuke the script attachment?
I know the background values of 3 and 5 probably do, since making a sprite a background one in the editor means no script works... I think.
But editor_type values 6 to 8 return the sprites (usually enemies) with their respective scripts attached.
Can work around this via the editor type 0 and storing the new image values I guess, then using sp_pseq() and sp_pframe() with retrieved values, and still keep the script attached but it seems a clunky workaround...
If a sprites editor type is set to 2 or 4, the script will stay attached until screen exit, and the script will not load when returning to that screen. So not instant nuke as soon as it changes, but nuked on future screen loads, yes.
3 and 5 work the same way.
I tested this with a hit proc, which still worked after the change (which took place in a prior talk proc). And I used scripts_used to confirm that the script was still loaded but was not loaded when exiting and returning to the screen.
3 and 5 work the same way.
I tested this with a hit proc, which still worked after the change (which took place in a prior talk proc). And I used scripts_used to confirm that the script was still loaded but was not loaded when exiting and returning to the screen.
Nuked on future screen loads, yeah, thanks, that's what I'm seeing. So it's not just me, phew...
I finally figured out how I got around this 20 years ago, and it wasn't using variables or visions. I had a script attached to another sprite on the map screen, a screen with only 3 sprites, the snow covered tree, the rock and the snow storm. The rock script had a wait(100); and then attached the original tree script to editor sprite number 4, which I figure the game then assigns that number to the tree after it has been given a new life via the
I broke this by adding two flowers around the tree, in my attempt to provide a hint that this tree held a secret.
Now I'm using global variable and visions - yes I know visions are like your dirty cousin who bathes once a month, but I don't mind them. Then and again, I like riddles... so go figure.
Shame the engine treats editor_type() 2 and 4 this way. For me it would make more sense that the script stayed attached on a reload, otherwise these types are essentially the same as 3 and 5.
I finally figured out how I got around this 20 years ago, and it wasn't using variables or visions. I had a script attached to another sprite on the map screen, a screen with only 3 sprites, the snow covered tree, the rock and the snow storm. The rock script had a wait(100); and then attached the original tree script to editor sprite number 4, which I figure the game then assigns that number to the tree after it has been given a new life via the
editor_type(&hold, 4)command.
I broke this by adding two flowers around the tree, in my attempt to provide a hint that this tree held a secret.
Now I'm using global variable and visions - yes I know visions are like your dirty cousin who bathes once a month, but I don't mind them. Then and again, I like riddles... so go figure.
Shame the engine treats editor_type() 2 and 4 this way. For me it would make more sense that the script stayed attached on a reload, otherwise these types are essentially the same as 3 and 5.
