So in my game, I want the tile to go to the mouse. that is very simple right? right. But my problem is, how do you make it to where it goes to the mouse pointer, but is has certain spots it has to go in, sort of like it is only between the spaces of a grid
P.S please don't comment unless you know what I am talking about and how to help thanks!

If I'm understanding you correctly, you have a tile grid and you want a sprite to move through that grid towards your mouse pointer, while avoiding obstacles on that grid?

If that's the case then you should start reading about “Path Finding” - that's what this is all about. The most widely used path finding algorithm for tile grids is called A* (pronounced A-Star)

Read up on A* here:
http://www.policyalmanac.org/games/aStarTutorial.htm

fezzinate wrote:

If I'm understanding you correctly, you have a tile grid and you want a sprite to move through that grid towards your mouse pointer, while avoiding obstacles on that grid?

If that's the case then you should start reading about “Path Finding” - that's what this is all about. The most widely used path finding algorithm for tile grids is called A* (pronounced A-Star)

Read up on A* here:
http://www.policyalmanac.org/games/aStarTutorial.htm

That isn't quite what I mean. Here look at this game an its movement https://scratch.mit.edu/projects/37855090/ verses mine and its movement
https://scratch.mit.edu/projects/73004802/#player. I want my movement to be like Yillie

so you want your sprite to go to the mouse but ONLY in certain spots.

Zekrom01 wrote:

so you want your sprite to go to the mouse but ONLY in certain spots.

Exactly! It is very hard tho (hehe tho)

does anybody know how to do that?

Don't think you can… hopefully someone else who knows more about Scratch then me can help.
60 second rule… we meet again.

If the screen is completely covered by a grid all you're doing is working out where the nearest grid cell centre is from the current mouse position.

If the grid cells are 10 x 10 the centres are at odd multiples of 5 from -235, -175 to 235, 175.

So within the grid, we can work out the column and row from

([ceiling v] of (((mouse x) + (240)) / (10)))  // gridx = column 1 to 48
([ceiling v] of (((mouse y) + (180)) / (10)))  // gridy = row 1 to 36

We can convert back to screen coordinates

set x to (((gridx) * (10)) - (245))
set y to (((gridy) * (10)) - (185))

You can do this in a single operation to show the tile in place

set x to (((10) * ([ceiling v] of ((mouse x) / (10)))) - (5) )
set y to (((10) * ([ceiling v] of ((mouse y) / (10)))) - (5) )

I haven't checked this but it should be close enough.

deck26 wrote:

If the screen is completely covered by a grid all you're doing is working out where the nearest grid cell centre is from the current mouse position.

If the grid cells are 10 x 10 the centres are at odd multiples of 5 from -235, -175 to 235, 175.

So within the grid, we can work out the column and row from

([ceiling v] of (((mouse x) + (240)) / (10)))  // gridx = column 1 to 48
([ceiling v] of (((mouse y) + (180)) / (10)))  // gridy = row 1 to 36

We can convert back to screen coordinates

set x to (((gridx) * (10)) - (245))
set y to (((gridy) * (10)) - (185))

You can do this in a single operation to show the tile in place

set x to (((10) * ([ceiling v] of ((mouse x) / (10)))) - (5) )
set y to (((10) * ([ceiling v] of ((mouse y) / (10)))) - (5) )

I haven't checked this but it should be close enough.

I tried what you said and all it did was make it to where it stays in the middle of the screen and can only move a little bit to each side.

koda1956 wrote:

deck26 wrote:

If the screen is completely covered by a grid all you're doing is working out where the nearest grid cell centre is from the current mouse position.

If the grid cells are 10 x 10 the centres are at odd multiples of 5 from -235, -175 to 235, 175.

So within the grid, we can work out the column and row from

([ceiling v] of (((mouse x) + (240)) / (10)))  // gridx = column 1 to 48
([ceiling v] of (((mouse y) + (180)) / (10)))  // gridy = row 1 to 36

We can convert back to screen coordinates

set x to (((gridx) * (10)) - (245))
set y to (((gridy) * (10)) - (185))

You can do this in a single operation to show the tile in place

set x to (((10) * ([ceiling v] of ((mouse x) / (10)))) - (5) )
set y to (((10) * ([ceiling v] of ((mouse y) / (10)))) - (5) )

I haven't checked this but it should be close enough.

I tried what you said and all it did was make it to where it stays in the middle of the screen and can only move a little bit to each side.

If you can share the project where you've done that I'm happy to have a look.

deck26 wrote:

koda1956 wrote:

deck26 wrote:

If the screen is completely covered by a grid all you're doing is working out where the nearest grid cell centre is from the current mouse position.

If the grid cells are 10 x 10 the centres are at odd multiples of 5 from -235, -175 to 235, 175.

So within the grid, we can work out the column and row from

([ceiling v] of (((mouse x) + (240)) / (10)))  // gridx = column 1 to 48
([ceiling v] of (((mouse y) + (180)) / (10)))  // gridy = row 1 to 36

We can convert back to screen coordinates

set x to (((gridx) * (10)) - (245))
set y to (((gridy) * (10)) - (185))

You can do this in a single operation to show the tile in place

set x to (((10) * ([ceiling v] of ((mouse x) / (10)))) - (5) )
set y to (((10) * ([ceiling v] of ((mouse y) / (10)))) - (5) )

I haven't checked this but it should be close enough.

I tried what you said and all it did was make it to where it stays in the middle of the screen and can only move a little bit to each side.

If you can share the project where you've done that I'm happy to have a look.

It is shared. on my profile it is the featured project. here https://scratch.mit.edu/projects/73004802/#player

You haven't copied it correctly - you've missed the multiply by 10 and the combined version doesn't mention 240 or 180 but you've included these.

Your sprite size better suits a grid cell size of 30 x 30 so try this

set x to (((30) * ([ceiling v] of ((mouse x) / (30)))) - (15) )
set y to (((30) * ([ceiling v] of ((mouse y) / (30)))) - (15) )

you can fine tune by changing the 15 to something else.

deck26 wrote:

You haven't copied it correctly - you've missed the multiply by 10 and the combined version doesn't mention 240 or 180 but you've included these.

Your sprite size better suits a grid cell size of 30 x 30 so try this

set x to (((30) * ([ceiling v] of ((mouse x) / (30)))) - (15) )
set y to (((30) * ([ceiling v] of ((mouse y) / (30)))) - (15) )

you can fine tune by changing the 15 to something else.

I did it, and it works but the blocks are a bit spaced. I don't know if I did it right… but it is way better than what I had before!

You're not quite getting it, I think.

You don't necessarily need gridx and gridy unless you want them for other purposes. You're still multiplying by 10 but dividing by 30 - the multiplication is to cancel the division with the ‘ceiling’ operation taking place in between. So, for example, for mousex = 160 ceiling of 160/30 = 6, multiply by 30 to get 180 which is the next multiple of 30 above 160.

You potentially ONLY need the two blocks from my last post so get rid of the blocks that set x and y according to the values of gridx and gridy. You also still have the value 180 being added to mousex and mousey but you don't need that!

https://scratch.mit.edu/projects/51479882/ is a remix with the code corrected. Your building blocks have different sizes but if you try it with the lava block you'll see it works reasonably well.

If you want to get them closer together you need to change each of the instances of 30 to a smaller number - the lava block is around 27 x 27 so substituting 27 should get them touching each other.

deck26 wrote:

https://scratch.mit.edu/projects/51479882/ is a remix with the code corrected. Your building blocks have different sizes but if you try it with the lava block you'll see it works reasonably well.

If you want to get them closer together you need to change each of the instances of 30 to a smaller number - the lava block is around 27 x 27 so substituting 27 should get them touching each other.

Thank you so much. wow. I kind of feel dumb because I just seemed to refuse to understand XD wow. It works now.

Perhaps I should have given you and example earlier so you could see how it worked.

Anyway, glad it's working. I'll unshare my version in a little while.

I'm a big fan of grid systems when you can use them - they make the placement of objects fairly simple (once you get the idea!) and work well for things like the classic snake game which is much easier to code when you realise for each move you actually only need to move the head and the tail.

deck26 wrote:

Perhaps I should have given you and example earlier so you could see how it worked.

Anyway, glad it's working. I'll unshare my version in a little while.

I'm a big fan of grid systems when you can use them - they make the placement of objects fairly simple (once you get the idea!) and work well for things like the classic snake game which is much easier to code when you realise for each move you actually only need to move the head and the tail.

This could end up helping me with more games too! I will give credit. thank you!