Scratch

redware · 2007-06-03 22:31:29

A sensing block for DIRECTION OF <sprite> would be useful. There is already a DISTANCE TO <sprite> so the concept fits with what is already there and allows more flexibility than the POINT TOWARDS <sprite> motion block. In fact, it would make it redundant.

Imagine a <prey> sprite that wants to run away from a <predator> sprite. You could make the <prey> sprite point towards the direction of the predator multiplied by -1 to move in the opposite direction. Currently I have to do it by pointing towards the <predator> and turning 180 which is a little messy.

Whilst you are at it - a DIRECTION OF <colour> and DISTANCE TO <colour> also fit in with what you have there already.

kevin_karplus · 2007-06-04 00:41:08

"Direction to <sprite>" would be much nicer than "Point towards <sprite>"

but direction to <color> and distance to <color> are not well defined, as the color may be in several places (while a sprite has a unique location).

rivendell · 2007-06-04 01:15:30

That's a good idea, one that I could have used in my Bumper Golf game. I swiped a game-play interface (from Mini Putt 2) that has the ball going the direction opposite from the mouse pointer. I then needed the direction so I could modify it if I needed to bank off a horizontal or vertical wall. What I did was "point at mouse pointer"/"turn 180" and then set my own variable "direction" to the sprite direction. After that I could manipulate the direction however I wanted without having to point.

That doesn't work so well for a dynamic motion, though, where the predator sprite is moving. You can't flip the sprite every step, or hide/unhide, without getting awful flickering.

Hmm... you could put an invisible sprite underneath your prey sprite, and flip the invisible one around and then read the direction to use for setting the prey sprite's direction. Kludgy, but it would eliminate the flickering problem.

kevin_karplus · 2007-06-04 10:03:56

Having one sprite shadow another can be done, but they get out of sync a lot, particularly in the java implementation, which does not seem to have as "fair" a thread scheduler.

Mayhem · 2007-06-04 12:16:49

redware wrote:
Imagine a <prey> sprite that wants to run away from a <predator> sprite. You could make the <prey> sprite point towards the direction of the predator multiplied by -1 to move in the opposite direction. Currently I have to do it by pointing towards the <predator> and turning 180 which is a little messy.

Might I suggest a neater solution?

Flip the sprites costume in the costume editor, so its "forward" direction points towards what looks like its rear.

Then when you use "point towards", the sprite appears to be facing *away* from the other sprite.

Then for movement, just use "move -10" instead of move 10.

heybrian1 · 2008-03-02 15:34:51

kevin_karplus wrote:
"Direction to <sprite>" would be much nicer than "Point towards <sprite>"

but direction to <color> and distance to <color> are not well defined, as the color may be in several places (while a sprite has a unique location).

how is derection difrrent then pinting?

kevin_karplus · 2008-03-03 13:59:57

"Point towards ..." changes your direction. It is equivalent to
"Point in direction <direction of ...>"

EdnaC · 2008-03-05 12:19:04

A Block that would return the (smallest) angle to turn thru to point at another sprite would be very useful.

It would accept the name of the sprite you are interested in and compare the "angle to" that sprite to the "direction of" the sprite using the block, and would return either a positive (right turn) or negative (left turn) angle. This would avoid doing some messy comparisons to find the smallest angle, or more importantly, the direction, to turn toward for an "intercept".

I'm not sure what you could call the block to make its function clear. Perhaps:

"TurnAngle to (TargetSprite)"

-MrEd

kevin_karplus · 2008-03-09 09:04:58

It isn't that messy if you have "direction to sprite":
((direction to sprite - current direction + 180) mod 360 ) -180

pat12 · 2008-10-21 08:17:48

Yeah this would really be helpful. I am trying to make a genetic algorithim and I need a:
if direction to sprite - 5 < direction < direction to sprite + 5
then do something

Basically the sensing is fixed but the responces to the sensing evolve.
This cannot be accomplished without a direction to sprite sensing block.

deerel · 2008-10-21 09:47:52

kevin_karplus wrote:
It isn't that messy if you have "direction to sprite":
((direction to sprite - current direction + 180) mod 360 ) -180

Why to complicate it so much? Unless you need it for comparision, you may freely omit +180 and -180, as well as mod 360, for turning in direction, -450 is same as -90 is same as 270 is same as ... you get it.
Even if you want to compare angles, simple mod 360 would do it, why trying so hard to stick into Scratch's -180..+180 model?

bhz · 2008-10-31 21:44:58

<point towards( sprite )
<set{ direction to sprite }to( <direction> )

DarthPickley · 2008-11-03 03:37:22

I've already tried to make a thing that can point towards a point and find a direction for a point using trig, and it was really hard and glitchy. I support this idea.

Scratch

archived forums

#1 2007-06-03 22:31:29

Direction To <sprite> sensing block requested..

#2 2007-06-04 00:41:08

Re: Direction To <sprite> sensing block requested..

#3 2007-06-04 01:15:30

Re: Direction To <sprite> sensing block requested..

#4 2007-06-04 10:03:56

Re: Direction To <sprite> sensing block requested..

#5 2007-06-04 12:16:49

Re: Direction To <sprite> sensing block requested..

redware wrote:

#6 2008-03-02 15:34:51

Re: Direction To <sprite> sensing block requested..

kevin_karplus wrote:

#7 2008-03-03 13:59:57

Re: Direction To <sprite> sensing block requested..

#8 2008-03-05 12:19:04

Re: Direction To <sprite> sensing block requested..

#9 2008-03-09 09:04:58

Re: Direction To <sprite> sensing block requested..

#10 2008-10-21 08:17:48

Re: Direction To <sprite> sensing block requested..

#11 2008-10-21 09:47:52

Re: Direction To <sprite> sensing block requested..

kevin_karplus wrote:

#12 2008-10-31 21:44:58

Re: Direction To <sprite> sensing block requested..

#13 2008-11-03 03:37:22

Re: Direction To <sprite> sensing block requested..

Board footer