I was going to suggest
glide 0.001 secs to x: x position y: y position
but there does not seem to be any way to stop a glide other than stop-all.
You may have to replace your glide with a repeat-until loop, including a test for stopping on each pass through the loop.
Offline
I'm not sure DrJim's suggestion is robust. What happens is you have two glides running at once, and I don't think there is any guarantee that the later one wins---there may be flicker between the two. The exact definition of glide is not available, so I don't know whether this will always work, sometimes work, or rarely work. It also means that you can't move again until the longer glide finishes.
Still, it seems like it might be a good trick.
Offline
kevin_karplus wrote:
I'm not sure DrJim's suggestion is robust .... The exact definition of glide is not available, so I don't know whether this will always work, sometimes work, or rarely work ...
Like I said - it "seems" to work.
Is there a technical description of the Scratch commands anywhere that has the level of specification detail needed to figure out under exactly what conditions something like this will work?
My guess is that any command "runs" until it times out and that the last command "started" controls motion. When it times out, the next most recent command still "active" takes over, etc., etc. You could thus have many actions pending and/or interrupted.
Two problems:
1. This is just a "guess"
2. This particular description is horribly imprecise, not to mention poorly written. Hopefully someone who really understands the commands can do a better job.
Offline
I suspect that the behavior is *actually* as well as *formally* undefined. That is, I think it depends on details of the scheduling mechanism for the threads, and that the behavior may be different for the same same script depending what else is being scheduled.
Offline