When I make a code block for movement like this

when [right arrow] key pressed
change x by (10)

There is much delay in movement when you hold the button down…

However, when you make a more complicated setup like this.

when green flag clicked
forever
if <key [right arrow] pressed?> then
change x by (10)

There is NO delay in input movement.

Does this have something to do with the way keyboard inputs work? Specifically, if I do the first method, the,movement acts as if I am typing something in notepad. But the second method keeps moving anyway until you let go.

Is that intended, or a bug? I feel like you could get away with first method, but second one has more control? Kind of stumped as why more code blocks matter just for the same effect..

Honestly I don't know why the when () key pressed block is coded that way. If you hold down that key, scratch will wait around half a second and then start executing the script every frame. The forever if one doesn't do that because it checks every and does stuff under it every frame.

is the same as

Yea like… I was exploring some of the basic tutorials Scratch gives included, and for the flying cat example (“Make it Fly”), it says to use the first method for arrow key inputs (not the forever method). But that seems to be the bad setup? Odd.

Maybe it's to make it simpler, and to prevent events from repeating quickly if you just tap button.

It runs the same way it would on a text document. Open wordpad or something, hold d, you'll notice the first keypress happens instantly then there is a delay in each successive d that appears as you continue to hold. That hat block behaves the same way.