Scratch

It should work if you have no repeat blocks in your script...

If you put a counter variable at the beginning of your code, and reset it to zero at the end, then you will know that multiple messages have been recieved.

[scratcblocks]
When message recieved clicked
change [counter v] by (1)
say [Do Code] for (2) secs
set [counter v] to (0)
[/scratchblocks]

EDIT: I tried, I failed. I hope the point gets accross though.

Last edited by tcb (2013-01-06 17:13:45)

Thanks to everyone. Using variables and lists is exactly what I was proposing in my "tutorial" projects http://scratch.mit.edu/projects/s_federici/1383298 and http://scratch.mit.edu/projects/s_federici/1383090. But I was wandering if there was also a non-variable-based solution.

As for what mathwizz says, my script has no repeat blocks. But it gets immediately interrupted, without any block being run in the receiving script. As I knew that IF blocks are not interrupted, I also tried to use a dummy IF as the very first block and I put the whole receiving script inside it. But this too didn't work.

Any further suggestion is welcome 

blob8108 wrote:

Can we see the offending script?

Sure. You can have a look at http://scratch.mit.edu/projects/s_federici/3024202. If you click on two or more cows that are very close to each other, often you don't get all the points you should (1 point per cow). The "offending" script is the one starting with <when I receive "guadagni un punto"> in the n1 sprite.

The "guadagni un punto" message is sent by the cows sprites called "mucca".

Last edited by s_federici (2013-01-07 11:20:44)

blob8108 wrote:

s_federici wrote:

blob8108 wrote:

Can we see the offending script?

Sure. You can have a look at http://scratch.mit.edu/projects/s_federici/3024202

That's... very interesting. I cannot see why that is. 

Really? No clue? Someone is willing to... try harder? 

LS97 wrote:

It's somewhere in some documentation

Yes, Scratch is a "reentrant" programming language (scripts can be restarted even before they are completed). I would have just preferred that script invocation could be traced without having to use variables. Maybe just allowing the very first block of the script to be always run (otherwise, the script is not interrupted, it is never started...).

blob8108 wrote:

As I understood it, though, Scratch should finish the script topped with the broadcast before switching back to another script that might call the broadcast again. 

No. As I said, Scratch is a reentrant programming language, so it starts again all scripts that have a hat as their very first block, as soon as the hat condition is true again.

Indeed, in my tutorial projects linked above, the problem is really how to make a script run until it is finished before starting it again (by "stacking" events that are intercepted by the hat). But in order to do it, I had to use blocks from the Variable category. I was wandering now if this can be done even without Variables.

blob8108 wrote:

doesn't Scratch only execute one script at a time

Again, no. Scratch is a parallel (or "concurrent") programming language. Indeed scripts from different sprites (but even from the same sprite) are run at the same time (almost). This is done by running a block at a time from each active script. Even this is not really exact: long running blocks (e.g. "glide" or "wait") are often interrupted by running other blocks from other scripts.

Anyway, there are some non interruptable sequences. For example, as far as I know, the blocks contained inside an "IF" block are run without interruption, so to avoid that other scripts will change the truth of the condition (that could make inconsistent the sequence contained inside the "IF" block).

s_federici wrote:

blob8108 wrote:

doesn't Scratch only execute one script at a time

Again, no. Scratch is a parallel (or "concurrent") programming language. Indeed scripts from different sprites (but even from the same sprite) are run at the same time (almost). This is done by running a block at a time from each active script. Even this is not really exact: long running blocks (e.g. "glide" or "wait") are often interrupted by running other blocks from other scripts.

Anyway, there are some non interruptable sequences. For example, as far as I know, the blocks contained inside an "IF" block are run without interruption, so to avoid that other scripts will change the truth of the condition (that could make inconsistent the sequence contained inside the "IF" block).

Aha! How interesting, thanks    I hadn't realised this...

So after half an hour of editing your script down, I appreciate the problem now!

This seems to be enough to replicate it:

set [score v] to [0]
show

when green flag clicked
broadcast [guadagni un punto v]

when green flag clicked
broadcast [guadagni un punto v]

when I receive [guadagni un punto v]
change [score v] by (1)

(I've also swapped "next costume" for "change score by 1"; you get the idea.)

If you run this with single-stepping set to "Flash blocks (slow)", you can see how the first two scripts broadcast the message, but the receiving script only actually runs once the first two have both finished. (Put all these scripts on one sprite, so you can see the blocks flashing!)

Honestly, I think the only way you can fix this is to replace the broadcasts with "change score by 1", etc. 

nXIII wrote:

s_federici wrote:

blob8108 wrote:

doesn't Scratch only execute one script at a time

Again, no. Scratch is a parallel (or "concurrent") programming language. Indeed scripts from different sprites (but even from the same sprite) are run at the same time (almost). This is done by running a block at a time from each active script. Even this is not really exact: long running blocks (e.g. "glide" or "wait") are often interrupted by running other blocks from other scripts.

Anyway, there are some non interruptable sequences. For example, as far as I know, the blocks contained inside an "IF" block are run without interruption, so to avoid that other scripts will change the truth of the condition (that could make inconsistent the sequence contained inside the "IF" block).

No, that's not correct either. Scratch runs each script in serial until it yields, which happens, e.g., when the script ends or when a loop finishes one iteration. After each process (script) has been run until it yields once, the evaluator goes back and does the next set in serial, and repeats this until there are no more running processes.

So the issue is that the broadcast is being pushed into the "queue" after the currently running scripts? It seems to be executed in the "next set", as you described it.

blob8108 wrote:

So the issue is that the broadcast is being pushed into the "queue" after the currently running scripts? It seems to be executed in the "next set", as you described it.

The issue is that two broadcasts are being sent in one execution frame. When a broadcast is sent, the implementation simply starts new processes for each hat responding to that event. When a hat already has a process attached, it is replaced by the new process (at the beginning of the script, regardless of the previous process's position). This leads to the behavior you see: the hat is only evaluated once.

Digimath wrote:

So, then, the trick is to have each cow release control a different number of times before calling the score routine

Wow!!!!!!!!!!!! This is really cool! And, I shouldn't say this but I will say it: I knew there was a non-variable-based way of getting this result! It works incredibly well. I says incredibly as it is not really clear to me why it does work    Any further detail/example?