What is exactly 1 second in scratch? Because I put “Wait 1 second, next costume” for a 1's and “Wait 10 seconds, next costume” for 10's and when the 1's is at nine, the 10's starts to go before the nine goes to zero.

Um… Well, 1 second is 1 second. There's really nothing else to say. The timer is correct. Unless you have solid proof that something like this happened, I would say that you maybe (as a human) couldn't see the instant the timer turned to 10 when the script started.

That_Annoying_Guy wrote:

What is exactly 1 second in scratch? Because I put “Wait 1 second, next costume” for a 1's and “Wait 10 seconds, next costume” for 10's and when the 1's is at nine, the 10's starts to go before the nine goes to zero.

The “wait” block is only accurate to .03 sec and maybe not even that if you have any lag.

If you have 10 “wait 1sec/next costumes” against 1 “wait 10sec/next costume”, then the computer has to do 10 times as much for the first case and that adds time to the process.

For accurate timing, do it the way this project does it >>> https://scratch.mit.edu/projects/95606405/

Nevermind. The 10's was just out of time. IT SUCKS

As footsocktoe implies above, when you have a “wait N secs”, you should not expect that Scratch will wait exactly N seconds. It should, however, wait *at least* N seconds.

Whenever you use the “wait N secs” block, Scratch will tell Flash to allow a screen refresh before continuing. Since Flash's screen refresh rate is 30 times per second in the Scratch player, that means even “wait 0 secs” will cause it to wait for 1/30th second.

If you really want to create a script which tries its best to ‘fire’ at a set interval, then you should use the timer something like this:

when GF clicked
set [interval v] to [0.2] // time between increasing the counter variable below
set [counter v] to [0] // this is just used to count how often it 'fires' 
set [nextTime v] to ( (timer) + (interval) ) // first 'firing' will be after 'interval'; set to just 'timer' to fire straight away
forever
wait until < (timer) > (nextTime) > // only 'fire' once timer passes required time
change [nextTime v] by (interval) // this ensures next firing time increases by correct amount
change [counter v] by (1) // can do something else here, e.g. "next costume", or maybe a broadcast, etc.
end

Note that if the ‘job’ you do at the firing point (i.e. whatever you want to actually do instead of increasing the counter) takes longer than the time interval, then it will not be able to fire at the correct next time, since it will not be able to carry on with the loop in time. However, the above script will try to ‘catch up’ on the missing firings if it gets chance later on. That may be what you want, or it may not. If not, you'll need to add some logic to prevent it changing nextTime to a value that is already less than the current timer (perhaps plus some minimum time difference).

———

Having said all of that, the best way to synchronise when things happen in two different sprites is to use broadcasts. For your case, you want a sprite to change its costume ten times and have another sprite change its costume on that tenth time (and presumably on every tenth change?)

That would go something like this:

when GF clicked
switch costume to [first costume to use v]
forever
wait (0.1) secs // will wait approx. 0.1s
next costume
if < ((costume #) mod (10)) = [0] > then
broadcast [next costume for other sprite v] // other sprite responds by doing "next costume"
end
end

Note that above assumes the first costume is costume number 1 (or at least a multiple of ten, plus one), and that you want to synchronise the same costume switches each time.

You will have to tweak above to your specific case (e.g. perhaps create a counter variable to use instead of the costume# in the mod operator).

Of course, if you want the first sprite (the one changing quickly) to change at exactly the right rate (rather than not minding exactly when as long as the two sprites stay synchronised) then you should combine both methods – use the first script above to tell the first sprite when to change, and also tell the other sprite to change every tenth costume change (or every tenth time through the timer loop).

Whew! –that ended up a lot longer than I expected… But I hope it helps in some way!