While I'm happy that the 'push out at angle' bug was fixed, there is a few Custom Movement things that are bugging me that aren't really bugs, so I decided to talk about it here instead. It's more of a comparison of how the behavior works in Construct Classic, where it works better for a few reasons, IMO.
Construct Classic Example (coded by Davo)
Construct 2 Example (recreating the above)
With the 'settings' more or less exactly the same in both caps (where possible), I'll outline the main differences the C2 version of the behavior has:
1) Acceleration doesn't adhere to angle of motion (very much). A main example being that you can go up a slope, but once you hit a flat part of the wall, you can't go down (or even slow down, for that matter). Trying to results in the PlayerSprite eventually launching itself off the wall. In Construct Classic, "horizontal acceleration" was kinda loose in that way. And yes, I have tried accelerating "forward" and via angle - doesn't work either.
2) The RotSensors are hilariously oversensitive to a fault, despite having the same 'settings' as the Construct Classic example. They'll go around right angles when they shouldn't, for starters, preventing the PlayerSprite from falling off a ledge, or not allowing the PlayerSprite to launch into the air going up a ramp.
3) The PlayerSprite can't handle bumping into walls. Just try to touch the wall on the right in the capx, and watch crazy stuff happen. It's probably because of 2), methinks.
4) Inability to decelerate. Construct Classic's version of the behavior has a 'decelerate' action, while C2's doesn't. A few people have said I'm supposed to be using positive acceleration for accelerating and negative for deceleration, but I'm convinced that's not the case, especially since all my attempts at 'custom' deceleration don't work, period.
Some other gripes that are a bit more minor:
* No 'bounce' action'. You'd think this would've been an obvious inclusion! <img src="smileys/smiley36.gif" border="0" align="middle">
* Inability to pick by 'solid'. The "is overlapping <object>" condition only includes objects, not solids, meaning I have to work around that by using a LOT of "is overlapping <object>" events to include every since Solid object. Kinda one of the downsides of merging attributes to behaviors, really. Sure, it'll become moot with the implementation of families, but still.