Basically, I have noticed that a platform-enabled object will 'stick' to walls of an incredibly steep slope (anything short of vertical). This is a big problem as most people don't want their players being able to make their way up cliffs.

Here's an example. Totally default behaviors in a new project.

It gets even more insane!

Is there any way to fix this manually? Or could Scirra implement a solution? Because I am sure this is not what 99% of platform games need!sqiddster2012-02-05 12:57:02

something like: Player.IsNearWall(Left)Wall.Angle >= 70 // Or what ever is your max angle etc. -> Player.applyVectorX(-2) // this is out of my head, so im not sure if this is the exact action but its something to do with vector x. And you might have to change it to a possible value.

That would work, however the problem lies in finding the angle of the wall relative to the player, since my game is gravity-shifting and rotating.And still, this doesn't seem to be the best way to solve the problem, I am sure there would be issues...

This sample file may can help you doing what you want. I think if you make a mask around the player, aligned by his middle/bottom point, and overlapping the walls, you will can detect the walls and use this system to make him drop away.

The mask need to be bigger than the player, and you set what walls can ignore this system by using a collision check on another object (the wall, for example)

This could be a very complicated feature to add to the platform behavior itself - it's already one of the most complex behaviors, and it currently does not care what it is standing on. For example, you could also stand on a single pixel, so by the same rule you can land on a very steep slope. I'll see if it's straightforward to fix the Platform behavior to drop down in this case, but it might not be, so it would be best to work around this with events or careful level design for the time being.Ashley2012-02-05 20:53:00

[QUOTE=Ashley] This could be a very complicated feature to add to the platform behavior itself - it's already one of the most complex behaviors, and it currently does not care what it is standing on. For example, you could also stand on a single pixel, so by the same rule you can land on a very steep slope. I'll see if it's straightforward to fix the Platform behavior to drop down in this case, but it might not be, so it would be best to work around this with events or careful level design for the time being.[/QUOTE]

I'm trying to learn fast to use C2 to develop a nice platform tutorial.

So, my workaround for this issue will be something like this:

I'll setup three slave detectors for my player gadget, as I did in the SandBOX (to detect edges and climb them, try it and look how awesome ^^ ).

If the bottom detector is overlapping the ground families, and the top isn't, and the middle detector is overlapping too, so, the player is on a climb, if the bottom is overlapping the ground and every other aren't, so, the player is on ground, if the top detector, the middle, and the bottom are detecting, he is on a wall.

But, this will bug the climbing logic, so, I'll make conditionals using "UP" and "RIGHT/LEFT" to keep him climbing, if not, he will be pushed out the wall or slip down.

So, Ashley, I don't know how you're doing the logic for behaviors, but if you're checking the collision box to make the "triggers" for example, you may can try check how much % of the sprite area is overlapping the wall instead of checking if the collision box is touching a bottom pixel.