You know when you use the “Go to ___” block to make games, the sprite that goes to the other sprite seems to not go PERFECTLY. Like it works right for sprites moving at a slow speed. But for those at high ones, don't mach the positions. We'll I need to make it somehow allowing the sprite go EXACTLY at the other sprite's position no matter if it's moving fast or not.

It would be really helpful if you help me!

the problem is that the sprite that's following the other one is on the front layer. you need it to be behind the other sprite for it to work properly.

if you want a more detailed explanation:
let's say we have 2 sprites: sprite1 and sprite2. sprite1 is on the front layer, and sprite2 is on the back layer.
scratch always runs the code for the sprites on top first, and then the ones on the bottom.
sprite1, being on the front layer, first goes to sprite2. sprite2 then changes its position. this causes their position to not be the same.
if sprite2 were on the front layer instead, it would change its position, and then sprite1 would go to its new position.

ametrine_ wrote:

the problem is that the sprite that's following the other one is on the front layer. you need it to be behind the other sprite for it to work properly.

if you want a more detailed explanation:
let's say we have 2 sprites: sprite1 and sprite2. sprite1 is on the front layer, and sprite2 is on the back layer.
scratch always runs the code for the sprites on top first, and then the ones on the bottom.
sprite1, being on the front layer, first goes to sprite2. sprite2 then changes its position. this causes their position to not be the same.
if sprite2 were on the front layer instead, it would change its position, and then sprite1 would go to its new position.

You can also manually implement a tick system so everything stays on time, I put my tick scripts in the backdrop.

From a quick test I'm not convinced the layering is what decides the order in which scripts run. I've never seen anyone else suggest that either.

deck26 wrote:

From a quick test I'm not convinced the layering is what decides the order in which scripts run. I've never seen anyone else suggest that either.

try making 2 sprites on top of each other (but slightly offset in position) and put this code in them

when green flag clicked
go to [front v] layer

and then spam the green flag. can you explain why that happens?

deck26 wrote:

From a quick test I'm not convinced the layering is what decides the order in which scripts run. I've never seen anyone else suggest that either.

It seems to be the order in which the sprites are executed, I made a test project for script orders it initially displayed sprites sorted from smallest in background and biggest in front using clones, later I was correcter about the execution order and tested it for different sprites, but thier order reversed every time the green flag scripts were executed. Now that makes perfect sense.

ametrine_ wrote:

the problem is that the sprite that's following the other one is on the front layer. you need it to be behind the other sprite for it to work properly.

if you want a more detailed explanation:
let's say we have 2 sprites: sprite1 and sprite2. sprite1 is on the front layer, and sprite2 is on the back layer.
scratch always runs the code for the sprites on top first, and then the ones on the bottom.
sprite1, being on the front layer, first goes to sprite2. sprite2 then changes its position. this causes their position to not be the same.
if sprite2 were on the front layer instead, it would change its position, and then sprite1 would go to its new position.

You can just do it like this.

when green flag clicked
broadcast [go to sticman v]

when I receive [go to stickman v]
forever
go to [stickman v]
end

You can control the order that scripts run using broadcasts. For example, suppose you have a Player sprite and a Hat sprite. Your code could look like this:

when green flag clicked
forever
broadcast [move player v]
broadcast [move hat v]
end

when I receive [move player v] // In player sprite
player logic goes here ::grey

when I receive [move hat v] // In hat sprite
go to [Player v]

Regardless of which layer the sprites are on, sending two consecutive broadcasts should make the player move before the hat. In addition, because the broadcasts are both sent in the same tick (don't use broadcast and wait!), both scripts run in the same screen refresh.

imfh wrote:

You can control the order that scripts run using broadcasts. For example, suppose you have a Player sprite and a Hat sprite. Your code could look like this:

when green flag clicked
forever
broadcast [move player v]
broadcast [move hat v]
end

when I receive [move player v] // In player sprite
player logic goes here ::grey

when I receive [move hat v] // In hat sprite
go to [Player v]

Regardless of which layer the sprites are on, sending two consecutive broadcasts should make the player move before the hat. In addition, because the broadcasts are both sent in the same tick (don't use broadcast and wait!), both scripts run in the same screen refresh.

Good job, you're the first here to have accurate scripts.