Please help:
I have created a sort of jigsaw-puzzle (a 'toy scratch' actually) with several sprites that each can be dragged around while the mouse is down on any of them (they just follow the mouse pointer). Once the sprite being dragged touches another sprite I want that other sprite to become highlighted (change costume) by broadcasting and receiving an event.
Now, here's the problem: Everything works just fine, but ONLY in the offline-FULLSCREEN mode. in the 'normal' Windows version the broadcast just doesn't seem to get fired off (or received for that matter). Same problem with the online version. The broadcast just doesn't get through.
Is this a bug, or did I misunderstand something?
BTW here's the project: http://scratch.mit.edu/projects/Jens/10220
Thx
-Jens
Offline
Dragging a sprite doesn't work in presentation mode (which is ideal for some projects but not for others).
There are work-around solutions. For example, see the Gravity Blocks example that's posted here:
http://scratch.mit.edu/projects/jay/132
In addition, currently there's a bug in the Java player where in a "forever" loop "broadcast" doesn't work unless you add a wait after the broadcast. You can add a tiny wait .0001 seconds.
Natalie
Offline
All forever loops need a wait in them---even without broadcasts there are lots of scheduling problems with forever loops in the java implementation.
Offline
Thanks natalie and kevin. But now I suspect that the problem I stumbled upon really seems to be a different one:
I don't really want to "drag" a sprite, but to "emulate" dragging a sprite in Scratch, i.e. make the sprite follow the mouse while the mouse is down on it. That somehow seems to conflict with actually "dragging" a sprite in the 'construction' mode of Scratch, and seems to disable most scripts, at least as far as broadcasts are concerned.
Does anybody know any workaround for that?
Offline
If you want to emulate dragging, you need to go into "presentation mode" by clicking on the easel underneath the little window. In construction mode, holding down the mouse will give the scratch editor control of the sprite rather than your program.
I ran into the same problem in the architecture stamp tools I just put up:
http://scratch.mit.edu/projects/kevin_karplus/11530
Presentation mode is the only workaround I know of.
Offline
thanks, Kevin. that's what I meant with 'offline-FULLSCREEN mode', the 'presentation mode' that is. What I don't really understand, why the same happens with the java renderer, since there's no editing mode there. Also, I believe highly interactive projects (like your architecture stamp example) should allow users to drag around sprites and still perform scripts... but hey, Scratch is wonderful anyway!
Offline
Presentation mode and the java applet do not allow editing the scripts.
They also don't take control of the sprites away from the program. This is a feature, not a bug---if you can drag sprites manually, all sorts of "cheating" in games could be done.
It is easy enough to add a loop to "go to mouse pointer", so if you need to have sprites follow the mouse, put it in your programs.
Offline
Actually, what I was originally asking was: Why does my 'sprite-dragging-emulating' project behave *differently* in the presentation mode and in the java runtimer. I would expect it to behave just the same in both modes, since all i did was tell the sprite to follow the mouse pointer if is down on it.
Offline
Ah, that's a different question. Most likely, you have a forever loop without a wait in it.
These cause more problems for the java implementation than for the squeak implementation.
Make sure that all paths through a forever loop include at least one wait that will really wait (either for a time or for a condition that is not true when you get to it in the loop).
Offline
Ok, so *that's* the problem - a bug after all!
I checked my code, and - yes - there's a forever loop without a wait in it, because I don't need any.
Actually, I think I'm just going to leave my project the way it is, and wait for the java-bug to be fixed in a later version....
Offline
Forever loops without waits are an invitation to scheduling problems.
I suspect that they will "fix" the problem by putting an artificial wait (and reschedule scripts) at the end of every forever loop.
Offline