Hello,
Lately, we are fixing various bugs reported on trac and elsewhere, and one of these items is:
http://dev.laptop.org/ticket/5214
(Try the example project made by Abe-san.)
The simplest fix was to remove some logic that ignores the attempt to set a new heading value if it is "close to" the old value. The logic was from old days and we (collectively) cannot really see the reasoning behind it.
We can take the check out (and the change is pushed to the update stream already), but there is a small risk.
The risk is that some existing projects may change their behavior; if your program depends on the old behavior, where if you set a value to heading but it actually doesn't change it sometimes, it could be a problem.
Also, the calculation of heading after an object bounced at the edge is changed. This is similar but more risky because in the old behavior the heading was rounded. If your project uses equality on the heading value and bounce, this could be a problem. (Now, we have the function tile to "round" the value, so one could create a proper script with it.)
Please let us know if this change causes a trouble. Thank you!
-- Yoshiki
Yoshiki Ohshima wrote:
Hello,
Lately, we are fixing various bugs reported on trac and elsewhere, and one of these items is:
http://dev.laptop.org/ticket/5214
(Try the example project made by Abe-san.)
The simplest fix was to remove some logic that ignores the attempt to set a new heading value if it is "close to" the old value. The logic was from old days and we (collectively) cannot really see the reasoning behind it.
I think it was helpful when you rotated a morph by the handle it would 'snap' to the old angle.
Karl
We can take the check out (and the change is pushed to the update stream already), but there is a small risk.
The risk is that some existing projects may change their behavior; if your program depends on the old behavior, where if you set a value to heading but it actually doesn't change it sometimes, it could be a problem.
Also, the calculation of heading after an object bounced at the edge is changed. This is similar but more risky because in the old behavior the heading was rounded. If your project uses equality on the heading value and bounce, this could be a problem. (Now, we have the function tile to "round" the value, so one could create a proper script with it.)
Please let us know if this change causes a trouble. Thank you!
-- Yoshiki _______________________________________________ Etoys mailing list Etoys@lists.laptop.org http://lists.laptop.org/listinfo/etoys
Karl,
The simplest fix was to remove some logic that ignores the attempt to set a new heading value if it is "close to" the old value. The logic was from old days and we (collectively) cannot really see the reasoning behind it.
I think it was helpful when you rotated a morph by the handle it would 'snap' to the old angle.
Sure. It still does, right? Snapping still works.
I thought that it might have something to do with smooth rotation from the blue handle, but if you are rotating a normal sized object via the blue handle, one pixel move translates to way more than 0.01 degrees, so having closeTo: there doesn't help.
-- Yoshiki
etoys-dev@lists.squeakfoundation.org