I think its really annoying when I have to create a list or variable just for the purpose of using it in one place (e.g a counter). That variable is now public and clutters up the whole project.
An example of this is this custom block:
https://dl.dropboxusercontent.com/u/17754076/Scratch/Local%20variables/pic%201.png
I am never going to use that list or counter variable again.

Therefore I propose a local variable (or a few) that can be declared at the top of a script.
Like this: https://dl.dropboxusercontent.com/u/17754076/Scratch/Local%20variables/pic%202.png
The local variables and lists will come up on the drop-down menus of all the changing variable and list blocks.
This vastly reduces clutter.
I have projects with too many variables that I would much prefer to be local to the scripts they are used in.

P.S. I know there is a simpler way to do the demo script but ah well.

I think BYOB has that feature.

However, what I do is I just have one counter that I use for all loops in that sprite, provided that they don't run at the same time.

Yeah, that's how other languages are. They have public variables, then private, then local, where they are created then deleted.

jvvg wrote:

I think BYOB has that feature.

However, what I do is I just have one counter that I use for all loops in that sprite, provided that they don't run at the same time.

I always end up having mine with the potential to run at the same time. Even if the don't always run at the same time, it is good to use different variables to make sure they don't bug.

turkey3 wrote:

Yeah, that's how other languages are. They have public variables, then private, then local, where they are created then deleted.

You didn't think this was my idea did you?

Good idea!

So you're saying have local variables for sprites, then variables local to a specific script. I don't see why not if other languages have it.

I agree that it should be possible to have custom variables for custom scripts. This would be especially helpful for making custom reporters (if they were added).

I'm going to bump this suggestion. I think that this is a pretty intuitive way of dealing with the problem. My only concern is that it might be adding too much clutter to the interface with this.

I would prefer a Snap!-style [script variables (a) (b) <>] block, but admit that the idea of upvars might be a little complicated for Scratch.

Also, i would remove the show/hide checkbox, because script variables are usually pretty temporary.

Well, you can just have a variable called “tmp” (aka temporary), and use it for all your counter needs! Only one script that needs a counter, no problem. 2 scripts need it? as long as they aren't simultaneous. need more than one counter? tmp2, or a list, in which different items are different counters.
Also, there is no clutter from ONE list/variable. There is from 5-10. So, try optimizing a bit, it really helps.

This may be a bit slow but it does allow you to use a variable in a block without worrying about it colliding with some other block using the same variable.
The basic idea is to just use a list as a stack to save and restore the values of variables used inside a block. Shades of assembly programming!

First create a local list in your sprite _Stack
Now let's say you have two variable _I and _J you want to use in your block. At the very top of your block push them onto the stack.

add _I to _Stack
add _J to _Stack

You can then use _I and _J in your block freely. At the end of the block you just pop off the original values. Be sure to do it in the reverse order of adding them!

set _J to item last of _Stack
delete item last of _Stack
set _I to item last of _Stack
delete item last of _Stack

I support the ideaof variables local to a few scripts, I have wished for this feature many times myself. My envisionment is similar to BYOB's script variables block:

using local variables (a) > :: grey cstart // the arrows expand the block, adding variables.
end
// the variables can be set, changed and manipulated from within
// this block through the use of normal variable blocks (they appear
// in all variable drop-downs within the block)
// like the parameters in custom blocks, the variables can be dragged
// from the top infinitely many times, and used within the block.