Pages: 1
If I want to use a direction value -5 or +5 (or whatever number) you get very wierd results when you get closer than your direction +/- value to the line where 180 goes back to -180.
You should probably fix it so that you can make code like this:
[blocks]
<when[ QWERTY ]key pressed>
<point in direction( (( <direction> <-> 5 )) )>
[/blocks]
Without getting strange results.
Offline
Just curious - why where you not using
[blocks]
<turn cw( )degrees>[/blocks]?
Last edited by Mayhem (2007-08-18 09:22:48)
Offline
Is this maybe happening because you are using radians instead of degrees?
Offline
I don't see any strange results---the angle 181 degrees is the same as angle -179 degrees, and scratch merely reports the angle in the range -180<direction<=180
What is the strange behavior you are seeing?
Offline
No, it's because I tried to make a ship that would turn towards my mousepointer. But do so slowly.
See here: http://scratch.mit.edu/projects/AlveKatt/30104
Move the mouse past 180 degrees of the ship a couple of times and see what happens.
Last edited by AlveKatt (2007-08-18 11:44:08)
Offline
The problem is not with the meaning of direction, but with your simple test:
direction < mouse-direction
Angles are not easily compared that way, because of the 360 degree jump somewhere in the circle (at 180 degrees in the scratch implementation).
Try (direction -mouse_direction) mod 360 >180 for your test instead.
Of course, there is no guarantee that you will *ever* get equality, so your repeat-until test should probably allow some round off error:
abs( (direction-mouse_direction + 100) mod 360 -100 ) < 1
(the "100" can be any number larger than your tolerance "1").
Offline
Thanks!
But I don't really understand the math, so I am not sure where I should put it.
But the thing for the round off error means I could make it spin more than one degree at the time, right? (Before when I tried to make it spin faster it it spun round many times before it actually hit the degree that was toward the mouse pointer... I do understand why, at least.)
Edit: I would still like to suggest an option for having the direction of a sprite as starting point for direction. And a sensing block like < angle to[ ] >. Also a movement block, like < move( )steps in( )angle > It would make many things so much easier.
I actually managed to make my spaceship do lateral movement with the help of a hidden second sprite. It worked better than I imagined, but it would be more elegant if you could do it with one sprite and the code. I made the spaceship sprite start in direction 0 and the lateral motion sprite start in direction 90, then I tied them together with a < go to[ sprite ] > block in each and made sure they both made the same < turn cw( )degrees > when < key[ ]pressed? >.
Last edited by AlveKatt (2007-08-18 13:52:31)
Offline
A sensing block for "angle to [SpriteName]" isn't a bad idea. However, as Kevin pointed out, you are still faced with the "jump" of 360 degrees, where angles that were counting up 178, 179, 179.99999 suddenly jump to -179.99999, -179, -178. The code in your sample is actually working OK, it just isn't figuring out the "closest" solution as you would like it to.
To make sense of this, you almost have to draw a diagram of a circle, labeled with angles. Then draw the direction you are pointing in, and the direction to your target. If your direction and the direction "angle to [Target]" stay away from the "jump", everything is fine, just as you noticed.
Angle to Target - My Direction = Angle to Turn (Negative is Left, Positive is Right)
so: If the Angle to the Target is 30, and My Direction is 60, the "CourseCorrection" is 30 - 60 = -30, and I need to be turning left. Of course, turning 30 degrees left would do the same thing as "point towards", but to slowly turn, you could choose any step, the important thing is the direction.
The Problem: If the Angle to the Target is -170 (just left of straight down) and My Direction is 170 (just to the right of straight down), then the math goes funky:
(-170) - (170) = -340 , which means turning 340 degrees left, when the target is only 20 degrees to the right. You will eventually get there, just not the way you want to. To fix this, you have to look for values greater than 180 degrees. If the difference is less than -180 (more negative than -180), add 360 degrees, if it is greater than 180, subtract 360 degrees and everything works out.
So, when the answer to Angle to Target - My Direction comes back as -340, you add 360 and get 20 degrees, which tells you the "short way" to alter your course.
Does that make sense? (If not, the diagram will help.)
If you look at the scripts for "PlaneTwo" in StealthFighter, you'll see one that of them sets "Plane2CourseCorrection" in this manner. It's also a pretty fun game for one or two players, it got my son away from Runescape for almost an hour today...
http://scratch.mit.edu/projects/EdnaC/33613
-Mr Ed
Last edited by EdnaC (2007-10-23 17:55:34)
Offline
Ahh, I see what you need to do, the code should be like this
<when green flag clicked>
<forever>
<set{ Slow Direction }to( direction/2
<when[ right arrow ]clicked>
<turn cw( Direction-Slow Direction )degrees>
Offline
Pages: 1