Is THIS the first tutorial off Google or something? If I'm confused by this block, no wonder there's so many new scratchers stuck on the tutorial. Can't you just do collision detection the normal way? What about just moving 1 pixel the whole way or optimizing it a little too. I am so confused by this block and so many other people are too. Please help me fix my brain it blew up a long time ago from this

Can you xlarify your question?
If you mean the move steps block, it’s of the most simple ways to properly move a sprite without needing to use the workaround, which has trig involved.

No I mean this custom block called move with steps. It's in like nearly all the platformers on HwS and very confusing

It's to simplify the movements of the player by using the change x and y blocks.

Well, theres that, which removes the need for 3 blocks when you use it each time, so 12 blocks, or rewrite the exact same Cade, adding 12 blocks. Besides, it helps debug.

Oh. Maybe it does simplify. I honestly just this blocks collision confusing

People use it because, when a sprite is facing any direction, it will move x amount of pixels and be going in the direction it's facing, unlike change x position by () blocks, for example, as you cannot (or it is very difficult to) move them in the direction a sprite is facing.
I do not find this block annoying, it is quite helpful. Although it may be worded simply, this is a beginners programming platform after all.
Very professional!

usyfben8o34 wrote:

People use it because, when a sprite is facing any direction, it will move x amount of pixels and be going in the direction it's facing, unlike change x position by () blocks, for example, as you cannot (or it is very difficult to) move them in the direction a sprite is facing.
I do not find this block annoying, it is quite helpful. Although it may be worded simply, this is a beginners programming platform after all.
Very professional!

I mean the custom block..

supernavo wrote:

(#3)
No I mean this custom block called move with steps. It's in like nearly all the platformers on HwS and very confusing

Does the block look something like this?

If so, then they're probably following griffpatch's platformer tutorial (especially if the project doesn't have scrolling and uses a custom Scratch Cat as the player), and I'll quote him about it:

Code a Platformer Game | 1. The Basics wrote:

The next step, no pun intended, would obviously be to stop us colliding with this right hand step (or wall) by detecting the collision and backing our player sideways carefully out of it, just like we did for gravity…
however… I’m going to stop us right there, and take a short breather! Why? Because I want to try something a bit different. What I love about coding is that there’s always space to innovate – To try doing things a little differently to see if you can improve things!
We yet have many problems ahead of us that we will need to address, some easy to work around, others more problematic, for example, like the player getting caught on the irregular pixels of steep inclines, the very pixels that make up our bitmap level – man that’s a real doozey.

What I am going to propose is that, rather than moving the player in large steps until they collide, and then using small steps to get out of the collision. We instead use small steps at all times while moving the player. This allows us to detect collisions as soon as they occur, and also allows us to handle the movement and collisions in far more detail going forward.

CST1229 wrote:

supernavo wrote:

(#3)
No I mean this custom block called move with steps. It's in like nearly all the platformers on HwS and very confusing

Does the block look something like this?

If so, then they're probably following griffpatch's platformer tutorial (especially if the project doesn't have scrolling and uses a custom Scratch Cat as the player), and I'll quote him about it:

Code a Platformer Game | 1. The Basics wrote:

The next step, no pun intended, would obviously be to stop us colliding with this right hand step (or wall) by detecting the collision and backing our player sideways carefully out of it, just like we did for gravity…
however… I’m going to stop us right there, and take a short breather! Why? Because I want to try something a bit different. What I love about coding is that there’s always space to innovate – To try doing things a little differently to see if you can improve things!
We yet have many problems ahead of us that we will need to address, some easy to work around, others more problematic, for example, like the player getting caught on the irregular pixels of steep inclines, the very pixels that make up our bitmap level – man that’s a real doozey.

What I am going to propose is that, rather than moving the player in large steps until they collide, and then using small steps to get out of the collision. We instead use small steps at all times while moving the player. This allows us to detect collisions as soon as they occur, and also allows us to handle the movement and collisions in far more detail going forward.

Oh ok, that answers my question. I don't recognize that code (even tho I seen the tutorials) but it was the same length as others I've seen so it's probably the same