Hello! I'm monkboyeli, and I'm currently developing a game! (Check my profile for the very bad trailer). I need help with slope detection. See, the scripts I'm using is just fine…when going up. When going back down, it gets stuck in midair. Could somebody please help?

I think you need to share something that shows what you're trying to do. There is nothing in your profile that shows any sign of slope detection.

https://scratch.mit.edu/projects/51219296/

Here you go. Grab a remix so I can unshare it.

The instructions imply you've solved the problem though? I have a copy but is there any need?

deck26 wrote:

The instructions imply you've solved the problem though? I have a copy but is there any need?

No, I haven't solved it. I was restraining myself from posting but I did every script that made sence to me. Test it out on the second room and you'll see.

The only script that sends you down is only run if it has first moved you up by the same amount. Your “gravity” function needs to be outside of that or even as an else (if you're not going up then you at least need to test if you should be going down).

You also have move x steps as well as x and y velocity - most projects will use one or the other but not both.

deck26 wrote:

You also have move x steps as well as x and y velocity - most projects will use one or the other but not both.

I think it's quite necessary to use both.

I'm also unclear why you would ever change y by the (abs) value of x velocity.

It's a very smooth way for him to go up.

monkboyeli wrote:

It's a very smooth way for him to go up.

But probably then gets in the way when he's trying to come down! Much better to just let the x and y sort themselves out properly rather than introduce such an artificial fix.

Do you have a suggestion on what I can use?

Others may be better placed to advise but I am looking at your project.

It's far from perfect but here's a remix https://scratch.mit.edu/projects/54466378/ . I've tidied up your code a bit, especially combining green flag scripts to make it clearer what's happening in what order.

The main problem at the moment is that the character will go up whenever he touches brown, even if the top of his head or his arms touches brown. there are various ways of trying to fix that depending on what you're aiming to do next.

Note that the custom block has to run without screen refresh to give smooth movement.

deck26 wrote:

It's far from perfect but here's a remix https://scratch.mit.edu/projects/54466378/ . I've tidied up your code a bit, especially combining green flag scripts to make it clearer what's happening in what order.

The main problem at the moment is that the character will go up whenever he touches brown, even if the top of his head or his arms touches brown. there are various ways of trying to fix that depending on what you're aiming to do next.

Note that the custom block has to run without screen refresh to give smooth movement.

This is where your logic is flawed, changing the main characters y by 1 when he touches brown may seem like a good idea, but of course, even when crouching he clips through the little thing above him. I am trying to do everything in my power to stop this from happening.

monkboyeli wrote:

deck26 wrote:

This is where your logic is flawed, changing the main characters y by 1 when he touches brown may seem like a good idea, but of course, even when crouching he clips through the little thing above him. I am trying to do everything in my power to stop this from happening.

Wouldn't it be better to design the level so he can't clip things. You can't really use brown as a boundary colour if he has to go through it in some instances.

I said it wasn't perfect and pointed out that particular flaw. I also pointed out that there are solutions depending on what else you're planning on doing.

For example, you could use a different colour for obstacles which are overhead. You could use colour touching colour and only react to the feet touching brown. Or you could use a separate (ghost?) sprite to detect the touching. There are other solutions but which is most relevant will depend on what else you intend doing in your project.

How is he meant to get through that gap if by crouching he still touches it? Your version also reacted to touching brown so it wasn't going to get through the gap either.

Psiborg wrote:

monkboyeli wrote:

deck26 wrote:

This is where your logic is flawed, changing the main characters y by 1 when he touches brown may seem like a good idea, but of course, even when crouching he clips through the little thing above him. I am trying to do everything in my power to stop this from happening.

Wouldn't it be better to design the level so he can't clip things. You can't really use brown as a boundary colour if he has to go through it in some instances.

I have been clipping the level, but it makes it look choppy. I know, gameplay over graphics, but I mean, come on, if a game looks that bad, you gotta step it up.

deck26 wrote:

I said it wasn't perfect and pointed out that particular flaw. I also pointed out that there are solutions depending on what else you're planning on doing.

For example, you could use a different colour for obstacles which are overhead. You could use colour touching colour and only react to the feet touching brown. Or you could use a separate (ghost?) sprite to detect the touching. There are other solutions but which is most relevant will depend on what else you intend doing in your project.

How is he meant to get through that gap if by crouching he still touches it? Your version also reacted to touching brown so it wasn't going to get through the gap either.

I'm aware as well, and I know my version wasn't as good. But the problem had nothing to do with him going up on top of it. Instead, he was clipping through it.