There should be 5 kinds of variables in scratch 2.0, each with different levels of access:
1)Cloud variables. Stored on servers and everyone playing the same project has access to the same ones.
2)Global variables. All sprites in one project have access to the same ones.
3)Sprite-local variables. Different sprites can have different local variables of the same name, but all the clones have access to the same ones. (this is how local variables work now) Also, the stage should be able to have local variables as well.
4)NEW! Clone-local variables. Every clone of a sprite gets their own copy of these variables. They start as the value of the variable in the original sprite at the time they were cloned. THERE IS NO WORKAROUND!
EDIT: This is now how local variables work anyway
5)NEW! Script variables. Temporary variables for a particular script, which are destroyed with the script ends, and different scripts can have different script variables with the same name. These would be made with a new block called "script variables" and would come with a variable in it that when you drag, the variable block does not come out of his "input", but will copy itself and the copy gets dragged instead. You could right click (or shift click) on this special "input" and rename it, and there would be + and - buttons next to it to add or remove variables. Useful if you are calculating something and you have to save parts of the calculation in order to make it work/make it fast. A script variable will cause an error if dragged into a script other than it's origin when the foreign script is run. The workaround of having lots of local variables clutters up the pallet and makes the scripts harder to read, and would fail when this sprite is cloned unless we had clone-variables.
Agree?
Last edited by joefarebrother (2012-10-15 15:48:20)
Offline
4). There is a workaround, lists, but I support.
5). When you said that the variable will be destroyed at the end of the script, what if you're using a forever block?
Offline
for the "clone local" variables, I can think of a workaround, as long as the "clone #" reporter exists, also I think cloning a sprite would clone the sprites local variables too
The workaround:
when gf clicked repeat (10) add (pick random (1) to (3)) to [list v] end repeat (10) clone end forever set [personal local v] to (item (clone#) of [list v])
Offline
zammer990 wrote:
for the "clone local" variables, I can think of a workaround, as long as the "clone #" reporter exists, also I think cloning a sprite would clone the sprites local variables too
The workaround:when gf clicked repeat (10) add (pick random (1) to (3)) to [list v] end repeat (10) clone end forever set [personal local v] to (item (clone#) of [list v])
That's what I originally thought of, but what i there wasn't a "clone number" reporter? You can't keep track of it in a variable, because when it changes you've lost the identification!
Offline
Offline
At the time of this post, there is no clone number block. We NEED either a clone number block, or clone-local variables (preferably both), or clones will be extremely limited.
Last edited by joefarebrother (2012-10-12 16:28:57)
Offline
this could be confusing to new users which would then defeat the purpose of scratch
clone-local variables would be useful although i dont fully know what happens with cloning. that may have even been implemented already
Offline
Wes64 wrote:
this could be confusing to new users which would then defeat the purpose of scratch
clone-local variables would be useful although i dont fully know what happens with cloning. that may have even been implemented already
If you're referring to 5 different variable types, agreed.
if you're talking about having a "clone #" block, I can hardly see how it would be confusing, and without it the only workaround I can think of requires very specific timing if you want clones to react the way you want them to
Offline
zammer990 wrote:
Wes64 wrote:
this could be confusing to new users which would then defeat the purpose of scratch
clone-local variables would be useful although i dont fully know what happens with cloning. that may have even been implemented alreadyIf you're referring to 5 different variable types, agreed.
thats what im talking about.
Offline
ErnieParke wrote:
5). When you said that the variable will be destroyed at the end of the script, what if you're using a forever block?
Quite simply, the variable wont get destroyed, unless the script is stopped in some other way like stop script or stop all, or the script's broadcast getting re-broadcasted.
Firedrake969 wrote:
4. Use procedures
How would you use procedures to workaround this?
Offline
joefarebrother wrote:
That's what I originally thought of, but what i there wasn't a "clone number" reporter?
You make it.
when gf clicked set (clone # v) to (0) delete (all v) of (clone vars v) repeat (10) change (clone # v) by (1) clone add (pick random (1) to (3)) to (clone vars v) end
(item (clone #) of (clone vars v)) //then, to retrieve the valuesHey, Scratch is all about making stuff simple for kids and people just getting into programming, but one big aspect of programming is coming up with practical solutions to whatever you need to do.
Last edited by technoguyx (2012-10-13 11:25:41)
Offline
The simple variable simple used today is almost the only one that will allow Scratchers to learn the concept easily. Even it needs some tutorials (see my project).
Offline
technoguyx wrote:
joefarebrother wrote:
That's what I originally thought of, but what i there wasn't a "clone number" reporter?
You make it.
when gf clicked set (clone # v) to (0) delete (all v) of (clone vars v) repeat (10) change (clone # v) by (1) clone add (pick random (1) to (3)) to (clone vars v) end(item (clone #) of (clone vars v)) //then, to retrieve the values
And how do the clones identify themselves on the list once the variable changes for the next clone?
technoguyx wrote:
I agree that Scratch needs "temporary" or "local" variables, they're useful for iterators and the such. Projects tend to get quite messy if you need lots of these.
Yeah. Either that or you try to recycle them for different scripts but then you have to end up giving them generic names like "temp" or "value" and it makes your project hard to read. Or BOTH happen.
Last edited by joefarebrother (2012-10-13 13:10:14)
Offline
i'm sure there clone-local variables, like on Panther there were.
Offline
Borrego6165 wrote:
i'm sure there clone-local variables, like on Panther there were.
At the time I made this topic, local variables worked like the sprite-local variables I described above, that all clones of one sprite use the same variable.
Offline
kayybee wrote:
Currently, if a sprite with a local variable clones, a new clone-specific variable will be created.
It'd be nice if people read what I write. Just cause I don't have a signature doesn't mean I don't write important things.
Offline
kayybee wrote:
Currently, if a sprite with a local variable clones, a new clone-specific variable will be created.
At the time of making this topic, that wasn't what happened.
Offline
joefarebrother wrote:
kayybee wrote:
Currently, if a sprite with a local variable clones, a new clone-specific variable will be created.
At the time of making this topic, that wasn't what happened.
Let me test again...
EDIT: clone-specific variables are created when a sprite is cloned with a local variable. that's how my score works (a sprite with costumes 0-9, and clones to match a digit of a variable). where are you getting you information from, that it does not do that?
Last edited by kayybee (2012-10-14 02:25:49)
Offline
kayybee wrote:
joefarebrother wrote:
kayybee wrote:
Currently, if a sprite with a local variable clones, a new clone-specific variable will be created.
At the time of making this topic, that wasn't what happened.
Let me test again...
EDIT: clone-specific variables are created when a sprite is cloned with a local variable. that's how my score works (a sprite with costumes 0-9, and clones to match a digit of a variable). where are you getting you information from, that it does not do that?
It's what happened when I tested it before making this topic.
Offline
joefarebrother wrote:
kayybee wrote:
joefarebrother wrote:
At the time of making this topic, that wasn't what happened.Let me test again...
EDIT: clone-specific variables are created when a sprite is cloned with a local variable. that's how my score works (a sprite with costumes 0-9, and clones to match a digit of a variable). where are you getting you information from, that it does not do that?It's what happened when I tested it before making this topic.
You're a tester? Oh. Never saw you on the forum.
But it's always been the way I described, so I don't know if you we're doing something differently. Look at my project the billion button. Look inside it and you'll see that each digit has its own variable. Or my particle test. The most recent one with gravity. The gravity wouldn't work if they all had the same variable...
Offline
kayybee wrote:
joefarebrother wrote:
kayybee wrote:
Let me test again...
EDIT: clone-specific variables are created when a sprite is cloned with a local variable. that's how my score works (a sprite with costumes 0-9, and clones to match a digit of a variable). where are you getting you information from, that it does not do that?It's what happened when I tested it before making this topic.
You're a tester? Oh. Never saw you on the forum.
But it's always been the way I described, so I don't know if you we're doing something differently. Look at my project the billion button. Look inside it and you'll see that each digit has its own variable. Or my particle test. The most recent one with gravity. The gravity wouldn't work if they all had the same variable...
I'm not a tester, I've just read this. At some point before I made this topic I did a test and local variables worked as sprite-specific, not clone-specific.
Offline