..."repeat until I receive..." You could also make it a control block. Or make the repeat a control and the until I receive a sensing. This would be helpful --> so you can make a sprite do something until you receive. Doing a forever does not work.
I also agree with the stop sprite.
Offline
by recieve i asume you mean recieve a broadcast. if so i second that because it would be very useful.
Offline
Repeat until I recieve <message>
and
wait until I recience <message>
would both be *very* useful blocks.
Offline
Would a variable switch not do the job?
Make a variable StopSprite
set StopSprite to 0
repeat until StopSprite = 1
Do some stuff
Elsewhere do some other stuff until the point when you need to StopSprite.
Offline
Using variables is not quite equivalent to messages. Plus the blocks for handling messages are better designed than the blocks for handling variables--- the pulldown lists are much handier than scrolling through the variable pane, and large numbers of variables seem to break scratch sometimes.
As an efficiency issue, if properly implemented, waiting for a message is a much more efficient daemon than waiting for an arbitrary boolean expression. The implementation should be pretty easy, since the "when I receive" blocks are just
forever
wait until I receive <msg>
body
That is, the code for doing wait until I receive must already be implemented.
Offline
Duncan: This would take awhile and be very annoying, but can be done.
kevin_karplus: I agree on both posts.
bigB: YES!!
Offline
agreed, could be very useful for eliminating bugs
Last edited by astrosapien (2007-07-12 18:39:59)
Offline
kevin_karplus wrote:
Repeat until I recieve <message>
and
wait until I recience <message>
would both be *very* useful blocks.
Agreed. These two are only one of a very small handful I can think of that are obvious gaps.
Offline
When developing PSP 1.5, I found multiple instances I could use this. Sometimes I did use the variable, though.
Offline
This will be very useful, and it was discussed before. There really should be a "when I recieve (mesage)" triangular block.
Offline
my friend and I were thinking the exact same thing!
Offline
Yeah, i´m very agree with this, i was thinking too the same thing?
But, why just for receiving broadcasted messages?
I´ve proposed messages sent to a single Sprite, like : < Send to [ Sprite ] [message] >
that would help too to make code clearly and we could 'teach' certain sprites to respond like customized functions or procedures helping another sprites like libraries.
http://scratch.mit.edu/forums/viewtopic.php?pid=164604#p164604
http://scratch.mit.edu/forums/viewtopic.php?pid=164596#p164596
Offline
kevin_karplus wrote:
Using variables is not quite equivalent to messages. Plus the blocks for handling messages are better designed than the blocks for handling variables--- the pulldown lists are much handier than scrolling through the variable pane, and large numbers of variables seem to break scratch sometimes.
As an efficiency issue, if properly implemented, waiting for a message is a much more efficient daemon than waiting for an arbitrary boolean expression. The implementation should be pretty easy, since the "when I receive" blocks are just
forever
wait until I receive <msg>
body
That is, the code for doing wait until I receive must already be implemented.
Yeah.
Also, the same is:
forever
if I receive <msg>
body
Offline
kevin_karplus wrote:
forever
wait until I receive <msg>
.
Wait until I receive monosodium glutamate?
Sorry, the nerd in me just couldn't resist.
However, these are some very good ideas.
I suppose that having these handled by squeak would be faster...
You could use jens' latest BYOB to add this using elements.
However, I will certainly try to get this into Streak soon.
Offline