At the moment, I am creating a game in which one sprite, being the player's character, must be followed(same x and y) by a seperate sprite, being the character's tool. The problem is, there is a slight delay in the tool sprite that causes it to glide away about a pixel or two from the character sprite when the character sprite moves. Once the character sprite stops moving, the tool sprite then catches up with the character. This is very irritating and degrades the game's look and quality. Currently, I am using a simple forever script that loops a script saying “go to player.” How do I remove this delay?

Try making a pair of variables called something along the lines of characterx and charactery
put this on the character

when green flag clicked
forever  
set [characterx] to [(x position) 
set [charactery] to (y position) 
end

and this on the object that is supposed to follow or go to the character

forever
go to x: (characterx) y: (charactery)
end

Let me know how that works for you.

Thevforever loop should do it - I've used that on a lot of my own projects with no delay. Could you share your project so we can see your code?

@Allycorn this unfortunately does not work. @wkelly42 I'm not going to share this project at the moment, sorry. What more do you need to know about my scripts to be able to help me?

Can't you just tell the second sprite to go to the first one in a forever or repeat loop?

deck26 wrote:

Can't you just tell the second sprite to go to the first one in a forever or repeat loop?

That is what I'm doing. It has a delay for some reason.

GhastlyConjurer wrote:

deck26 wrote:

Can't you just tell the second sprite to go to the first one in a forever or repeat loop?

That is what I'm doing. It has a delay for some reason.

Impossible to advise further without seeing the project. Can you produce a stripped down copy which you can share if not willing to share the main thing?

GhastlyConjurer wrote:

deck26 wrote:

Can't you just tell the second sprite to go to the first one in a forever or repeat loop?

That is what I'm doing. It has a delay for some reason.

That's all depending on the order of the sprites, how it runs the script. It may be delayed for one game tick if it runs the scripts in the wrong order, try to switch the sprites.

The reason why that comes up is, that the computer doesn't actually run all scripts at once, rather one after each other, just really fast. I'm not very sure, but I think it starts with the last sprite, runs the script once, continue with the next one and so goes through all sprites until done. When it's done, it updates and displays all the sprite's new positions and other transformations on the screen, what you can see in the game.

For example, you have two Sprites: Sprite 1 and Sprite 2, in which Sprite 1 is the first one. You want Sprite 2 to follow Sprite 1, so add following script:

forever
set x to (([x position v] of [Sprite 1 v]) + [x offset])
set y to (([y position v] of [Sprite 1 v]) + [y offset])
end

Now, when you run the scripts, the order is
Sprite 2 script → Sprite 1 script → Update
So, Sprite 2 follows Sprite 1, but when you move Sprite 1 it never has the same position, because Sprite 2 comes first before updating the screen. Switching the Sprites would invert the running progress like
Sprite 1 script → Sprite 2 script → Update
and the whole thing should work without any delay.

Hope that was the reason and I could help

-Scratcher- wrote:

GhastlyConjurer wrote:

deck26 wrote:

Can't you just tell the second sprite to go to the first one in a forever or repeat loop?

That is what I'm doing. It has a delay for some reason.

That's all depending on the order of the sprites, how it runs the script. It may be delayed for one game tick if it runs the scripts in the wrong order, try to switch the sprites.

The reason why that comes up is, that the computer doesn't actually run all scripts at once, rather one after each other, just really fast. I'm not very sure, but I think it starts with the last sprite, runs the script once, continue with the next one and so goes through all sprites until done. When it's done, it updates and displays all the sprite's new positions and other transformations on the screen, what you can see in the game.

For example, you have two Sprites: Sprite 1 and Sprite 2, in which Sprite 1 is the first one. You want Sprite 2 to follow Sprite 1, so add following script:

forever
set x to (([x position v] of [Sprite 1 v]) + [x offset])
set y to (([y position v] of [Sprite 1 v]) + [y offset])
end

Now, when you run the scripts, the order is
Sprite 2 script → Sprite 1 script → Update
So, Sprite 2 follows Sprite 1, but when you move Sprite 1 it never has the same position, because Sprite 2 comes first before updating the screen. Switching the Sprites would invert the running progress like
Sprite 1 script → Sprite 2 script → Update
and the whole thing should work without any delay.

Hope that was the reason and I could help

Thank you for the help, but unfortunately that is not working. Do you have any other suggestions?

GhastlyConjurer wrote:

@wkelly42 I'm not going to share this project at the moment, sorry. What more do you need to know about my scripts to be able to help me?

Sounds to me like something is interfering with the movement on the tool sprite, making it slow down. Without seeing the project I can't tell you what that something is. All any of us can do is speculate.

You need to get the scripts for the two sprites to execute in the same frame - i.e. to synchronise them. (That's basically what -Scratcher- was saying above.)

There are ways to ensure this happens with forever loops in the separate sprites - but people who do that and have it working are more often just lucky in the way they happen to have ordered the sprites on the stage and the scripts within the sprites, rather than actually understanding why it works.

But the best way to do it for sure is to use a broadcast-and-wait from the first sprite right after it has moved. The follower sprite responds to the broadcast by moving to where that first sprite has gone.

So something like this:

forever // first sprite
do stuff, and move to wherever...
broadcast [follow me v] and wait
end
when I receive [follow me v] // following sprite
go to [first sprite v]

Hope that helps!

GhastlyConjurer wrote:

-Scratcher- wrote:

GhastlyConjurer wrote:

deck26 wrote:

Can't you just tell the second sprite to go to the first one in a forever or repeat loop?

That is what I'm doing. It has a delay for some reason.

That's all depending on the order of the sprites, how it runs the script. It may be delayed for one game tick if it runs the scripts in the wrong order, try to switch the sprites.
(…)

Thank you for the help, but unfortunately that is not working. Do you have any other suggestions?

You're welcome! I'm sorry, I need to see the project or an example project to know what is going on, so I can't help more before knowing the reason.
Another suggestion to get rid of the delay, is to control the main character with another sprite, using variables.
For example, add a third sprite as the controlling system and do

forever
if <key [Up v] pressed?> then //just some example motion scripts
change [y v] by [1]
end
if <key [Down v] pressed?> then
change [y v] by [-1]
end
if <key [Left v] pressed?> then
change [x v] by [-1]
end
if <key [Right v] pressed?> then
change [x v] by [1]
end
end

and then, for the Sprite 1 (player's character) and Sprite 2 (character tool)

forever
go to x: (x) y: (y)
end

That could do it, too.

TheLogFather wrote:

You need to get the scripts for the two sprites to execute in the same frame - i.e. to synchronise them. (That's basically what -Scratcher- was saying above.)

There are ways to ensure this happens with forever loops in the separate sprites - but people who do that and have it working are more often just lucky in the way they happen to have ordered the sprites on the stage and the scripts within the sprites, rather than actually understanding why it works.

But the best way to do it for sure is to use a broadcast-and-wait from the first sprite right after it has moved. The follower sprite responds to the broadcast by moving to where that first sprite has gone.

So something like this:

forever // first sprite
do stuff, and move to wherever...
broadcast [follow me v] and wait
end
when I receive [follow me v] // following sprite
go to [first sprite v]

Hope that helps!

Thank you, this does work and get rid of the following delay. However, now the entire character moves with a delay.

GhastlyConjurer wrote:

TheLogFather wrote:

You need to get the scripts for the two sprites to execute in the same frame - i.e. to synchronise them. (That's basically what -Scratcher- was saying above.)

There are ways to ensure this happens with forever loops in the separate sprites - but people who do that and have it working are more often just lucky in the way they happen to have ordered the sprites on the stage and the scripts within the sprites, rather than actually understanding why it works.

But the best way to do it for sure is to use a broadcast-and-wait from the first sprite right after it has moved. The follower sprite responds to the broadcast by moving to where that first sprite has gone.

So something like this:

forever // first sprite
do stuff, and move to wherever...
broadcast [follow me v] and wait
end
when I receive [follow me v] // following sprite
go to [first sprite v]

Hope that helps! bla bla bla

Thank you, this does work and get rid of the following delay. However, now the entire character moves with a delay.

Try without the “wait” p4rt.

GhastlyConjurer wrote:

Thank you, this does work and get rid of the following delay. However, now the entire character moves with a delay.

Moves with a delay compared to what…?


In general, I'd recommend that you control *everything* from a single loop in one sprite, rather than having multiple loops.

In order to keep everything else synchronised, you can have the main loop in the sprite doing the following:

forever // in the sprite doing the following
broadcast [do frame v] and wait
go to [sprite to follow v]
end
when I receive [do frame v] // all other sprites
do stuff for this frame...

That will ensure that all other sprites are synchronised in what they are doing, and *then*, afterwards, but in the same frame, the following sprite will move to where you want it (before the end of that frame, which comes at the end of the forever loop).


However, your reference to another ‘delay’ suggests you may have more sprites following other sprites? If so, then it can get more complicated (because you need to ensure the execution order is correct - the sprites-to-be-followed must move first, then, within the same frame, you want the sprites-doing-the-following to make their move - but if you've got a chain of following then you have to have a chain of broadcast-and-waits.)

Note that you *should* use broadcast-and-wait (not just broadcast as suggested above, since that will not guarantee the correct execution order…)

Hope that kinda makes some sense!

There is an extremely easy fix for this.

Say you have a sprite with an arm that is separate. There is indeed a delay for most ways of tracking in scratch but I will show you an example of how to remove the delay without an hassle or LAG!

when green flag clicked 
forever
(Follow)
end

define follow
broadcast [ follow me v]

So you have your forever define function. The define function MUST BE RUNNING “WITHOUT SCREEN REFRESH”
The define function should be broadcasting a message eg. “FOLLOW ME”

Now in the arm/extra sprite:

when I receive [ follow mev]
go to [ charactor v]

i have been having trouble on making karlson 2d and the arm isnt moving at the past of the body and it has a delay can someone help

Professor-Scratch wrote:

There is an extremely easy fix for this.

Say you have a sprite with an arm that is separate. There is indeed a delay for most ways of tracking in scratch but I will show you an example of how to remove the delay without an hassle or LAG!

when green flag clicked 
forever
(Follow)
end

define follow
broadcast [ follow me v]

So you have your forever define function. The define function MUST BE RUNNING “WITHOUT SCREEN REFRESH”
The define function should be broadcasting a message eg. “FOLLOW ME”

Now in the arm/extra sprite:

when I receive [ follow mev]
go to [ charactor v]

That just made it worse lol

Devobio wrote:

Professor-Scratch wrote:

There is an extremely easy fix for this.

Say you have a sprite with an arm that is separate. There is indeed a delay for most ways of tracking in scratch but I will show you an example of how to remove the delay without an hassle or LAG!

when green flag clicked 
forever
(Follow)
end

define follow
broadcast [ follow me v]

So you have your forever define function. The define function MUST BE RUNNING “WITHOUT SCREEN REFRESH”
The define function should be broadcasting a message eg. “FOLLOW ME”

Now in the arm/extra sprite:

when I receive [ follow mev]
go to [ charactor v]

That just made it worse lol

Please don't necropost. Create a new topic if you need help.