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.
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.