Do as variable [ v] block

fredmiracle

This proposal would be terribly confusing and I would not support it.

BUT it is a shame variables can't move (or alternatively, that sprites can't contain text elements that can be easily manipulated on the fly).

I haven't seen an existing sprite “solution”–though I don't doubt they exist–but by the time you get to building up several of them and positioning them properly to reflect a multi-leter/digit display, the implementation must be pretty clunky. Unnecessary reinventing the wheel doesn't seem “scratchy” to me

monstermash3

Actually, you COULD do it without sprites by creating multiple variables, but this could be difficult…

So I still support.

Edit: Never mind, this only works with variables in the large readout (which doesn't display variable names), since two variables cannot have the same name.

Last edited by monstermash3 (Dec. 27, 2015 02:00:16)

monstermash3

Also, I would say that

do as variable [ v] block:: variables cstart
ask [] and wait
end

would make the speech bubble appear at the variable, but the textbox would still pop up at the bottom of the screen.

jerry1000

How about

move [variable 1 v] to x [0] y [0]

I would support that

monstermash3

jerry1000 wrote:
How about
move [variable 1 v] to x [0] y [0]
I would support that

Like I said before, just making

do as variable [ v] block::variables cstart
end

would open up lots of non-motion options for variables, like speech bubbles and pen.

(Although I guess maybe variable motion blocks would be easier to notice and less confusing. But I still support for the “do as variable block” because we would not need as many blocks.)

zebradash

ZozaTech wrote:
No support. A variable can't move

monstermash3

Actually, here's a reason a variable should be able to move. Here's a use of variable motion:

You made a game. It's timed. The player tries to get as high a score as possible. The score variable is in the top left corner. When the timer has gotten down to 0, the game is over and, for emphasis, the variable is moved to the center of the screen.

Again, I guess you could just create two variables, but still, it feels like you're storing more data than you need to…

zebradash

monstermash3 wrote:
Actually, here's a reason a variable should be able to move. Here's a use of variable motion:

You made a game. It's timed. The player tries to get as high a score as possible. The score variable is in the top left corner. When the timer has gotten down to 0, the game is over and, for emphasis, the variable is moved to the center of the screen.

Again, I guess you could just create two variables, but still, it feels like you're storing more data than you need to…

Well, I guess for that. Any other way i think is useless.

The_Kitty_Eevee

zebradash wrote:
monstermash3 wrote:
Actually, here's a reason a variable should be able to move. Here's a use of variable motion:

You made a game. It's timed. The player tries to get as high a score as possible. The score variable is in the top left corner. When the timer has gotten down to 0, the game is over and, for emphasis, the variable is moved to the center of the screen.

Again, I guess you could just create two variables, but still, it feels like you're storing more data than you need to…
Well, I guess for that. Any other way i think is useless.

Zro716

Looking at a project JSON and the Scratch source code, variables do not have most of the constructs that a sprite has, and therefore they cannot act like them. I was concerned that including sprite-like behavior like changing direction, cloning, etc. would violate variable constraints. The only viable commands for variables is changing position, changing watcher look, and setting slider min and max.

monstermash3

Zro716 wrote:
Looking at a project JSON and the Scratch source code, variables do not have most of the constructs that a sprite has, and therefore they cannot act like them. I was concerned that including sprite-like behavior like changing direction, cloning, etc. would violate variable constraints. The only viable commands for variables is changing position, changing watcher look, and setting slider min and max.

They probably can input the variable readout images like sprites, though, and we could support only blocks that just do stuff with the images. (Sorry if my statement is inaccurate, I don't know much about coding beyond Scratch.)

MClovers

semi-support

Scratcher1002

MClovers wrote:
semi-support

Why?

MClovers

Scratcher1002 wrote:
MClovers wrote:
semi-support
Why?

Because some of these are impossible

scratchisthebest

This works, I guess? It's a really, REALLY clunky way to implement it though, and it makes no sense.

Imagine if you weren't able to add scripts to sprites, and instead had to do this little song and dance in the Stage:

when gf clicked
forever
do as [Sprite1 v] :: variables cstart
when gf clicked :: stack
move (10) steps
wait (5) secs
broadcast [yeah v]
end
do as [Sprite2 v] :: variables cstart
when gf clicked :: stack
go to x:(100) y:(40)
::control stack
when I recieve [yeah v] ::events stack
forever
turn cw (15) degrees
end
end
end

It makes no sense whatsoever - neither does “do as variable”.

If you want to make this functionality, you can use two variables - show one and hide the other, and it will look like it “moved”.

Scratcher1002

MClovers wrote:
Scratcher1002 wrote:
MClovers wrote:
semi-support
Why?
Because some of these are impossible

Yes, so:

Sonickyle wrote:
Support. Unsupported blocks could turn red if they are dragged in.

Zro716 wrote:
Looking at a project JSON and the Scratch source code, variables do not have most of the constructs that a sprite has, and therefore they cannot act like them. I was concerned that including sprite-like behavior like changing direction, cloning, etc. would violate variable constraints. The only viable commands for variables is changing position, changing watcher look, and setting slider min and max.

That means that

move [variable v] to x: () y: () :: variables
move [list v] to x: () y: () :: list
change [variable v] to watcher [small,large,slider v] :: variables

are possible.

Last edited by Scratcher1002 (Feb. 8, 2016 17:31:59)

Elverbasse

Good idea!

theory_

After reading you post, a few things came to mind. For example, In my opinion custom blocks seem to be what you are describing. Custom blocks additionally have an advantage of speeding up your projects, and entering in values. Therefore, no support. However, that is just my opinion.

Scratcher1002

theory_ wrote:
After reading you post, a few things came to mind. For example, In my opinion custom blocks seem to be what you are describing. Custom blocks additionally have an advantage of speeding up your projects, and entering in values. Therefore, no support. However, that is just my opinion.

No… They're talking about being able to make a variable move 10 steps, or glide to x 32 y 4.

Discuss Scratch