Sprite-local variable crashes imported project

[BryceLTaylor]

Expected Behavior

Launching project 223217573 in Scratch 3 should behave just as it does in Scratch 2.

Actual Behavior

On launch, errors appear in the console.

Then if you click on different sprites in the sprite menu, eventually their blocks will stop appearing in the workspace and more errors will appear in the console:

Uncaught Error: Variable "Light" is already in use and its id is "X!74*sFc|x7vP3Bl3q@,-Light" which conflicts with the passed in id, "{jo-mL!R)yYANgt0I~]?-Light".

I can get this to happen every time, though not consistently with the same sprites that I click on.

After getting that error and the blocks disappear if you click the costumes tab and then back to the code tab the whole blocks area becomes blue with the "Oops! Something went wrong" error message. Even more errors appear in the console:

Steps to Reproduce

Launch project 223217573 in the 3.0 editor.
Open the console
Note: There are errors
Select different sprites in the Sprite Editor
Note: Eventually a sprite will not show any code in the workspace (all sprites have code in this project). Also, there are more errors in the console
Select other sprites
Note: no sprites show code now, even ones you had seen code in before
Select the Costume Tab
Select the code tab
Note that the workspace, blocks pallet, and the category menu are gone and the "Oops" error message appears there instead. More errors appear in the console

I tried reproducing in another 2.0 project that uses the same name for local variables, but I couldn't get the same outcomes.

Operating System and Browser

Chrome and Safari on Mac

[paulkaplan]

I updated the title to reflect what I think is the cause of this, that there is a sprite-local variable named "Light" in multiple sprites, but scratch-blocks does not like that.

@kchadha I had thought we made scratch-blocks ok with have variables that have the same name, but it looks like that is still not kosher. See core/variable_map.js, line 184. Fixing this will be part of implementing sprite-local variables.

[TheLogFather]

My guess would be that it's because "Light" doesn't exist as a local variable in all sprites where it is used, e.g. the "Background" sprite, but it does exist sprite-local in others.

(Looking at the scripts, I'd expect the creator intended for "Light" to be global.)

When the variable doesn't exist in a sprite, but does get used, this project only uses it on clones created by that sprite. Under those conditions, Scratch 2.0 doesn't create the variable until it actually reaches it during execution – meaning it only gets created sprite-local for the clone(s) that use it, and the original sprite still doesn't have it.

Guessing further, it seems like Scratch 3.0 creates the variable when loading the blocks for the project – but it creates it global rather than local (you can see it exists in Stage once the project has loaded). That then clashes with the existing "Light" variables that are local to some of the sprites.

The essential problem, then, could be simply that Scratch 3.0 creates variables that are referenced within a sprite's scripts, but which are not 'declared' anywhere for that sprite (or Stage), as global rather than local.

[TheLogFather]

After trying a couple of quick tests, it appears the non-existent variable doesn't get created on load, but only when viewing the script area for the sprite that references it. (In the offending project referenced above, that's the "Background" sprite, which is the sprite that has its scripts appear after loading.)

However, if you don't actually view the sprite's scripts (so the var still doesn't exist), but run the project so that it reaches a reference to that non-existent variable during execution, then the var gets correctly created sprite-local.

The problem, then, is that when Scratch 3.0 finds a non-existent variable referenced in a script for the sprite that has its scripts being shown in the scripting area (even if not actually visible within it at the time), it creates it there and then as a global var (rather than local to that sprite).

[BryceLTaylor]

I can import projects that use the same variable name on multiple sprites, all "for this sprite only," without getting any errors. This project (226235128) for example. The ducks and the cat all have a variable for this sprite only called Thing. The project loads and runs fine in Scratch 3.0.

[TheLogFather]

Yes, there's nothing wrong with the way Scratch 3 handles sprite-local vars that have the same name across multiple sprites – that all appears to be working fine. (NOTE: except for show/hide a watcher – it gets confused about which stage/sprite's var it should reference...)

There's also no problem when it comes across a non-existent var in a sprite during execution – it creates the var as local to that sprite/clone just as Scratch 2 does, and continues without issue.

---

The potential problem comes when it creates a var that does not already exist due to it being referred to in a script that's 'showing' in the 'current' sprite (i.e. the sprite that's having its scripts shown in the scripting area). –It then creates it as a global var (without any scripts being executed).

At that point I reckon there's still not necessarily going to be a problem – it may be fine that such a global var exists. However, it causes trouble if it tries to reference that new global var from a sprite that already has a local var with the same name, because that sprite sees two possible references to a var with that name.

---

I'd imagine the same problem would happen at runtime in Scratch 3 for a project that simply references a non-existent var in the stage.

Under such a scenario, Scratch 2 also creates the var as global (since it's on the stage), and that can cause some trouble in Scratch 2 if a sprite already has a var itself by that name. (Scratch 2 tends to be OK during execution with such things, since it checks for local var references first, so that's the one it'll use when it comes across that var name in a script in that sprite. –But there are issues with the UI for watchers in Scratch 2 for such multiply-defined vars.)

What I reckon will happen with Scratch 3 is that it would create the global var (just as Scratch 2), but then give the same kind of errors on the console (as you saw above) when it executes script in a sprite that has the same name var locally. –The problem is simply that the sprite can see two references to a var with that name (one local, one global).

At least, those are my immediate thoughts as to what's likely going on here...

[TheLogFather]

Here's a simple project to play around with this...

https://scratch.mit.edu/projects/226703491/

It has a sprite with a single local var named "test", and no global vars.

However, there's a script on the stage that references var "test", so causing it to be created as a global var when executed (which is done by hitting space at some point after launching the project).

If you switch to the stage in Scratch 2 then you will not see any var there until that stage script is executed, at which point Scratch 2 creates it as a global (and the script also shows that var underneath the existing local "test" watcher for Sprite1).

However, if you go to stage in Scratch 3 (before running anything), then the "test" var gets created, as a global, straight away (due to the reference in the script).

OTOH, if you don't switch to stage in Scratch 3, but just launch the project first thing, then the var only gets created once the stage script executes after you hit space. (Note that its watcher never shows up, because show/hide isn't quite working correctly in Scratch 3 for local vars.)