Platform behaviour - change animation

Link to .capx file (required!):

dl.dropboxusercontent.com/u/14522925/C2%20examples/PlatformerAnimationChange.capx

Steps to reproduce:

1. Use arrow keys to walk to the right of the platform (against the wall).

2. Press C to change animation states.

3. Now walk all the way over to the wall on the left. Press C.

Observed result:

In step 2, observe how the sideways block is simply pushed away from the wall and remains on the floor.

In step 3, observe how the block is pushed away from the wall and a bit up. It then falls to the ground.

Expected result:

The change in animation should be identical whether there is a wall to the right or the left - i.e.: the block should not "float" when there's a wall to its left.

Browsers affected:

Chrome: yes

Firefox: n/a

Internet Explorer: yes

Operating system & service pack:

Windows 8 64-bit

Construct 2 version:

r134

The Platform behavior is not designed to be used with animated sprites (as described in how to make a platform game). If you swap animation frame to one with a wider collision mask by a wall, you've effectively teleported the object inside a solid. This should never happen, and it activates "get me out of here" mode in the Platform behavior, which basically teleports you to the nearest free space. Workaround: don't animate the platform object, and pin an animated object on top. Closing as won't fix.

Ashley I expected you to say that, and to be honest I was reluctant to report this as a bug since you're obviously aware of this issue.

But I have to reaffirm that this is an issue, because it's inconsistent. That "get me out of here" mode could actually be useful if it were reliable, but as it stands now it just doesn't make sense. It works perfectly well on one wall but not the other.

If you could make it work in a predictable manner, that'd take care of the issue (and possibly solve that other anchoring issue that keeps popping up) and make the behaviour that much more powerful - it's half solved already.

Ashley I agree with GeometriX

If you have played any game such as Street Fighter, if you face a wall and crouch, the sprite doesn't move, or, if he collides, the sprite is moved to a position that is consistent with his current position. In GeometriX case, the origin point is set to the bottom, and the consistent thing to do when crouching is to crouch at the origin point position.

The inconsistent behavior is what's happening right now, that the sprite is teleported in the air.

As I already mentioned in another thread, there needs to be consistency in origin points having a higher priority over other actions.

check this little fella:

https://dl.dropboxusercontent.com/u/23009908/construct_bugs/originnnnn.gif

<img src="https://dl.dropboxusercontent.com/u/23009908/construct_bugs/originnnnn.gif" border="0">

When he crouches, notice the gun is a pixel to the right.

And of course he doesn't teleport to mid air.

California, I appreciate the vote of confidence, but I'm literally just referring to the floating issue here. I don't want to dilute my bug report with a broad approach, I'm just after a tightening up of an existing feature.

The problem is that the platform behavior is not designed to be teleported in to solids. I think this is a pretty reasonable limitation. I could change the details of how the platform behavior teleports itself to a free space when it's teleported inside a solid, but I don't believe this would fix it - it would just change the circumstances of when it teleports badly, especially when dealing with slopes, moving platforms, etc. So then it's still a bad idea to rely on it, except it's even more insidious, because at first it will look like it works but actually it will just bite you further down the line when you're even more invested in your game and it's even harder to change.

Basically if the platform behavior suddenly finds itself wedged inside a solid, it has to guess where to move itself out to. It could guess smarter, but it will never get it right every time. So I think it's better to leave it obviously guessing wrong, so people never rely on it guessing correctly.

I don't see any reason you can't just use a fixed collision object and change the animation on top of that. That looks exactly like what California's example is doing. And it will always work.

Ashley I've followed the best practice and I am using a collision object. This particular situation came about when I was trying to implement a sliding animation in a game, which needs more width than the standing animation to keep the sprite from overlapping the wall during the animation.

I already have a workaround in which I check which side the wall is on and move the collision object out by x pixels. It's not really a matter of finding something that works; I posted a thread about this in General and the consensus was that I should report it as a bug because it's so consistently... inconsistent - it's spot on every time there's a wall to its right. California thought it might be linked to some greater issue.

I do get your point though - it's simply not designed this way, and if it's not a straight-forward fix then I'm totally okay with that and I'm prepared to work around it. I think the concern (California's, at least) is that whatever its design is, is affecting other parts of the engine.