Problem with "move toward" in conjunction with "distance to"

In attempting to do all of the problems I'm assigning to students this summer, I encountered the following problem.

1. Add a dragon and a blimp to the world.
2. Turn the dragon to face the blimp.
3. Move the dragon toward the blimp, the distance between the dragon and blimp.

The problem occurs in step 3. If the amount to move is blimp->distance to dragon, the results are as expected. However, if the amount to move is dragon->distance to blimp, the dragon moves through and past the blimp, such that he ends up about as far away as he started (just on the opposite side of the blimp). It seems that the order in which the objects are presented to the "distance to" function affects the result.

Have I misinterpreted how "move toward" or "distance to" is supposed to work? It would be nice to be able to explain to students why this discrepancy occurs or to confirm this is a bug.

I've attached the problematic code, which includes comments about the starting and ending coordinates of the blimp and the dragon for both cases. I have not yet tested to see whether all objects behave this way, or if it is just the dragon and the blimp.

Originally Posted by Tasha

In attempting to do all of the problems I'm assigning to students this summer, I encountered the following problem.

1. Add a dragon and a blimp to the world.
2. Turn the dragon to face the blimp.
3. Move the dragon toward the blimp, the distance between the dragon and blimp.

The problem occurs in step 3. If the amount to move is blimp->distance to dragon, the results are as expected. However, if the amount to move is dragon->distance to blimp, the dragon moves through and past the blimp, such that he ends up about as far away as he started (just on the opposite side of the blimp). It seems that the order in which the objects are presented to the "distance to" function affects the result.

Have I misinterpreted how "move toward" or "distance to" is supposed to work? It would be nice to be able to explain to students why this discrepancy occurs or to confirm this is a bug.

I've attached the problematic code, which includes comments about the starting and ending coordinates of the blimp and the dragon for both cases. I have not yet tested to see whether all objects behave this way, or if it is just the dragon and the blimp.

Try it with another object in place of the blimp. I did a quick test with the cow in place of the blimp and the problem seemed to go away.

Dick Baldwin
Free Alice tutorials: http://www.dickbaldwin.com/tocalice.htm
Free Scratch tutorials: http://www.dickbaldwin.com/tocHomeSchool.htm
Free Java/C#, etc. tutorials: http://www.dickbaldwin.com/toc.htm

Originally Posted by DickBaldwin

Try it with another object in place of the blimp. I did a quick test with the cow in place of the blimp and the problem seemed to go away.

I tried this again with the dragon and the biplane; everything worked as expected. Then I tried it with the blimp and the biplane and encountered the same error described before. I guess there's a bug while using the blimp. At least now I know one problem students might encounter!

The problem may be connected with the initial positioning of the blimp out of the gallery.

When I align the blimp first with ground (or world) and then move it to its desired position , I get consistent results for <otherobject>.distanceTo(blimp) and blimp.distanceTo(<otherobject>) afterwards. Possibly, the alignment step corrects an error introduced by the automatic positioning of the blimp out of the gallery.

It might thus be a good idea to always start with new objects by aligning them to ground, either manually or in a "setTheStage" method as advocated by Dick in his tutorials.

Presumably a simple solution would be to use a quick formula like

Distance to X ( minus ( 1/2 X's width + 1/2 object that's moving's width ))

~Merg~