Isn't that wierd...
In this case of a suggestion, I support to having it made available!
Offline
If you mean dragging variables into the "When I receive" block just like you can drag them into the "broadcast" block, I support. And I'd also like to be able to drag variables into any drop-down box, as I suggested here 2 months ago
Last edited by technoguyx (2010-01-29 12:40:44)
Offline
Let's say you want to make a sprite with broadcasts independent from the project itself (eg. internals). To encapsulate it better, you may find it helpful to generate a random identifier each time project is run. The variable will be stored somewhere, and then, to send a message to a specific sprite, you will use this:
broadcast(join((sprite id) [.turn90cw]))
...and a receive event hook (the hat block), when I receive join((sprite id) [.turn90cw]).
Edit: Bleeding heck, why does the forum blocks function get in the way?!?!?!
Last edited by filo5 (2010-01-29 18:26:47)
Offline
I like this suggestion. And it makes sense!
Offline
The problem with this idea is that you'll never really need to use it in practice. Say you had a script that broadcasted "start":
When flag clicked{ set variable_to_broadcast to "start" broadcast(variable_to_broadcast) } When I receive(variable_to_broadcast){ //do something }
In this situation, it would be much easier just to not use variables in broadcasts entirely. And in a situation where you did need to use broadcast the value of a variable:
//Here we want to broadcast "1","2","3", or "4" depending on the value of variable (random) When flag clicked{ set random to (pick random between 1 and 4) broadcast(random) } When I receive ("1"){ //This happens when "1" is chosen randomly } When I receive ("2"){ //This happens when "2" is chosen randomly } When I receive ("3"){ //This happens when "3" is chosen randomly } When I receive ("4"){ //This happens when "4" is chosen randomly } When I receive(random){ //This will always happen! What's the point? }
Anything that this would accomplish can be done by broadcasting variables. There is a reason the Scratch team omitted it.
Offline
I think what folks want--at least what I would want--is the ability to include some data with an event. Useful things might be an x,y location related to the event, or the identity of the broadcasting sprite.
You can, of course, stuff such data into one or more variables on Broadcast and pick it up on Receive. One might worry about contention in the case of multiple Broadcasts, however the current implementation of Scratch interrupts a Receive in progress if another Broadcast occurs, so if it happens you're screwed anyway, and there's no point in me writing down the fancy method I had all worked out for passing multiple values using Lists as LIFO buffers and all that. *grins*
regards, Fyxen
Last edited by Fyxen (2010-01-31 15:03:13)
Offline
No. When you broadcast a variable, it's like this:
<set var to [1]>
<broadcast [var]>
<When I receive [1]>
<move [10] steps>
Offline
fullmoon wrote:
filo5 wrote:
...and I'm talking about
set var to 1
broadcast var
when i receive var
move 10 stepsBut what's the point? Why broadcast a variable?
Yeah. The method that I have makes sense.
But your way is silly. The variable doesn't do anything.
Offline
gershmer wrote:
fullmoon wrote:
filo5 wrote:
...and I'm talking about
set var to 1
broadcast var
when i receive var
move 10 stepsBut what's the point? Why broadcast a variable?
Yeah. The method that I have makes sense.
But your way is silly. The variable doesn't do anything.
Whoops, I meant "why receive the variable". My bad.
Last edited by fullmoon (2010-02-03 23:05:14)
Offline