Frame delay for immediate blocks in containers, when they are first

This is great

This is inconsistent

(Result of 1 would be expected above)

So when the Set block(s) are the 1st (same result with multiple sequential Sets) blocks, the code execution doesn’t continue to the next non-Set block as expected within the same frame

Additional steps to reproduce:
[Edited in by moderator]


I think only the delay between a set/change variable and a container was fixed, although, yeah, it is very inconsistent.


Correction. When a Set/Increase block is first within a parametric Ability, there’s a frame delay before the Set/Increase executes…

(Verified by using a global variable within the Ability and reading that to a text during the 1st and 2nd frames)


That’s interesting, I’ll try and do some testing around that too.

I did find that both Set Var and Increase Variable blocks are taking 1 frame each to execute in webplayer 2.0, whereas in 1.5, they took 0 frames.

I’ll make a separate bug report for this later, but here is the same code in different webplayer versions:

If you take the Increase variable block out in both cases, the loop takes 90 frames to execute.

(You can replace the Increase var block with Set var too)


So there was an extra frame if the set var block is the first in the repeat container (it doesn’t happen if it’s second) and that will be fixed.

I’ll look at the case for abilities too.


I’ve just moved this to a separate topic, to make it easier for me to keep track of.

I think at least one of the frame delay issues, for when the Increase/Set block is the first in the ability or repeat container, will be fixed.

This code results in 181 being displayed on the live app, and 92 in the staging/development app:

(but there is another bug currently appearing in the staging app after the fix, which I’m looking into)


Adding to this, it seems like there is a frame added when instant blocks are at the beginning. Same thing happens in this project – wait after set variable causes delay, but no wait or wait before runs all 60 frames.

^ This is broken. Moving the wait to before set variable or removing the wait block makes it run at full speed, so this is somehow adding a frame when it shouldn’t.


it’s extremely useful tho

I reproduced this (AE’s post above) in the new player, but the results seems backwards to me. Agreed that the Increase followed by Wait should run at 60fps, but

That should run at 30fps… 1 frame for the wait block & a 2nd frame for the subsequent Increase block. (When the Set/Increase is the last or only block it takes, or at least previously took, a frame)


Yeah the intended behaviour is that if the Set/Increase/immediate block is last in the Repeat container, it should take a frame. (Paraphrasing from AwesomeOnion — you can think of an immediate block as a block in which after it executes, we continue onto the next frame immediately after. Since it is the last block in the container in this case, there is no next frame. So we end the frame and wait until the next tick.)

If the immediate block is first in the Repeat container, it should not take a frame before.

We are planning to fix this. (There was a fix, but another bug resulted with how trails were being drawn & the set speed block, so that was why I just removed the #in-development tag for now.)


No it’s not. If I wanted to make it wait, I’d add a wait zero after the wait zero.

1 Like

wait what
the fps will drop to 15

Use this template to make awesome bug reports:

Username: Spy guy 96

What kind of device are you using?: iPad 9th gen, latest app and latest iOS version.

1 sentence description of the problem (I was doing _________, and then __________ happened): I was trying to help @Crosbyman64 with a problem when I came across this bug.

Steps that the Hopscotch team can take to reproduce my problem every time:
This project explains it all

I expected this to happen:
The 2 numbers to be equal

But instead this happened:
They were not

Here’s a sweet screenshot:
Look at the project


I should probably tag @Yuanyuan and @t1_hopscotch


I just set the subcategory to Player Bugs, as this occurs in the player.


@Dragongirl1264 this is the bug (read OP)


I just did some testing. I found out this bug is much worse that I thought.

Not only does this happen in Check Once If containers, it also happens in all other containers, excluding Rules and Repeat Forever.

Unexpected extra delay happens in the following containers:

  • Check Once If (known)
  • Check If Else (known)
  • Repeat
  • Draw a Trail
  • Custom Abilities (the new ones)

(@t1_hopscotch, @/Spy_Guy_96)


@Mathematics2 here’s the bug (read OP)


Ok I don’t know who’s a hopscotch dev on this form but I’m guessing there all leaders so @Leaders have you seen this bug report yet?
It’s stoping people from joining my platformer contest.


Yuanyuan and t1_hopscotch were already tagged, and they have seen the bug report.

Also, not all leaders are HS developers.