Hello.
Can someone build a workaround for this block?

point towards x: () y: ()

Someone said that this workaround is well known, but I am idiot enough to don't know that, so if you know how to workaround this, please tell me how.
Also: don't use invisible sprites - I would need like +20 sprites to build a single path.
Thanks.

Why exactly do you need a workaround? Are you trying to move the sprite somewhere without changing the direction that it's pointing in?

bcstahlman13 wrote:

Why exactly do you need a workaround? Are you trying to move the sprite somewhere without changing the direction that it's pointing in?

I want to move a sprite through a path using the Move—Steps block, because the Glide block don't have always the same speed with different distances.

Put a ghosted sprite at the location, point towards that sprite and then start your move in a loop.

But you don't want to use the point towards block? Nice project, btw. I'm not exactly sure where this logic would come into play in your program, though. There's an easy way to solve this problem if all you need to do is get your sprite to be touching a certain point, but if you actually need to get the sprites x and y position exactly on that point, the problem could be a little bit more difficult.

deck26 wrote:

Put a ghosted sprite at the location, point towards that sprite and then start your move in a loop.

That's sort of what I was thinking, except that it would only be helpful if he just need the sprite to be touching the zero-width (or ghosted) sprite; not if he actually needed their x and y coordinates to be exactly the same.

deck26 wrote:

Put a ghosted sprite at the location, point towards that sprite and then start your move in a loop.

bcstahlman13 wrote:

But you don't want to use the point towards block? Nice project, btw. I'm not exactly sure where this logic would come into play in your program, though. There's an easy way to solve this problem if all you need to do is get your sprite to be touching a certain point, but if you actually need to get the sprites x and y position exactly on that point, the problem could be a little bit more difficult.

I just want a sprite pointing to some coordinates instead of a sprite, because I would need lots of sprites to do a path (know what is a Tower Defense game? It's like the enemys go through a path and your towers need to hit them, but that would be really hard using 20 sprites to do a path, where I would need to use +20 if I want to make more different paths).
UPDATE:
Want to see what I'm doing? https://scratch.mit.edu/projects/115539905/ I did a block with More Blocks to move a sprite from x1 and y1 coordinates to x2 and y2 coordinates using the Move—Steps block, but it still need to point to x2 and y2 in order to go the correct direction and reach it.

Well, deck26 meant just one ghosted or zero-width sprite at the location, not 20. If you mean 20 total (20 towers), then it's still not really that hard, because you can clone the sprite 20 times. You definitely don't need to create 20 sprites.

bcstahlman13 wrote:

Well, deck26 meant just one ghosted or zero-width sprite at the location, not 20. If you mean 20 total (20 towers), then it's still not really that hard, because you can clone the sprite 20 times. You definitely don't need to create 20 sprites.

How do you point towards a clone?

bcstahlman13 wrote:

deck26 wrote:

Put a ghosted sprite at the location, point towards that sprite and then start your move in a loop.

That's sort of what I was thinking, except that it would only be helpful if he just need the sprite to be touching the zero-width (or ghosted) sprite; not if he actually needed their x and y coordinates to be exactly the same.

Not a problem if you make sure the move is to the sprite if the distance to it is less than the normal move.

Benur21 wrote:

bcstahlman13 wrote:

Well, deck26 meant just one ghosted or zero-width sprite at the location, not 20. If you mean 20 total (20 towers), then it's still not really that hard, because you can clone the sprite 20 times. You definitely don't need to create 20 sprites.

How do you point towards a clone?

It might be better to have a list of positions that the ghosted sprite goes to in turn and for each position you point towards it.

The size of the ghosted sprite doesn't matter if alll you're doing is pointing towards it or checking the distance to it - it's only the position of the sprite that matters in either case, not the size.

Isn't here someone that can workaround this +++++ block?

point towards x: () y: ()

maybe using the more blocks

So my question is how do you decide what the target coordinates are? I'm not sure I understand what you're trying to do and how the multiple towers change that.

If you want each tower to fire at the nearest enemy each enemy should record its x/y position in two lists using a cloneID as an item number. Then a tower can go through that list and work out which is nearest (Pythagoras) to itself. You could then use trig to work out the angle rather than the ghosted sprite method and the tower can create a missile which is a clone of itself with a different costume so it starts in the right place and goes in the right direction.

My demo might help https://scratch.mit.edu/projects/111228685/

Benur21 wrote:

Isn't here someone that can workaround this +++++ block?

point towards x: () y: ()

maybe using the more blocks

As I say it can be done using trigonometry. If you know two x,y positions you can use trig to work out the angle between them.

deck26 wrote:

So my question is how do you decide what the target coordinates are? I'm not sure I understand what you're trying to do and how the multiple towers change that.

To know what are the x2 and y2 I just put the mouse where I want and see the coordinates below the background.

I also tried to do that with trigonometry, but it is only working if want to point to the center (0,0) and if the Sprite y < 0
https://scratch.mit.edu/projects/115558033/

deck26 wrote:

https://scratch.mit.edu/projects/115617899/

Cool, and thanks!!! That's what I wanted!
Workaround:

define Point towards x: (X) y: (Y)
point in direction (([atan v] of (((X) - (x position)) / ((Y) - (y position)))) + ((180) * <(Y) < (y position)>))

CLOSED