8 direction possible bug

Problem Description

The capx have 2 objects: Blue which is a sprite with 8 directions, and Solid, which is a solid tiledbackground, when it enters in motion, it should stop when he collide, or that does not happen.

Attach a Capx

attached

Description of Capx

when you push up, down, left or right, Blue has a variable change, which simulate a control constantly until he collide with something, or so we though, the on collision triggers while the collision has not occured yet (you may see it being slightly off, like there is a space between blue and solid when it stops), if you increase the max speed and acceleraton by a factor of 10, sometimes the gap is huge.

Steps to Reproduce Bug

• Open capx and run it
• push and release right, left, up or down
• See the gap between blue and solid

Observed Result

Blue stops before colliding

Expected Result

Blue to stop when he was against Solid

Affected Browsers

• Chrome: (YES)
• FireFox: (Untested)
• Opera: (YES)

Operating System and Service Pack

Windows 7 home edition

Construct 2 Version ID

r195 (current stable)

I saw it a long time before but never reported it for some reason.

Perhaps it is expected, but I think not.

I don't believe it's a bug. It seems to me the issue is that your using tiled backgrounds which don't give the ability to draw a collision polygon. I'm sure this is due to the fact that they can be resized and tile automatically. If you use sprites, you won't have the issue. Tiled backgrounds seem to create an imperfect collision polygon oversized to the actual size of the background.

I changed it on overlap added System wait 1.0 before changing the Move value to 0 worked better.

Using "on overlap" works better but, if you need to use tied backgrounds I suggest the following:

Use a larger sprite for the Blue block to 64, 64. Then draw the collision polygon undersize within the image editor for the Blue block. Then just resize the block down to 16,16 in the properties dialog box. Use "on overlap" instead of "on collision" and give it a delay before changing the value of Move to 0 as said above with the system wait.

I'm sure Ashley could elaborate better as to why the Tiled Backgrounds work differently as solids than sprites since you have no ability to draw collision polygons.

I'm using windows 8.1

TheDom as expected, a tiledbackground collision polygon is equivalent to a rectangle, and I tested it, it still happens with a sprite with solid on it.

"I'm sure Ashley could elaborate better as to why the Tiled Backgrounds work differently as solids than sprites since you have no ability to draw collision polygons. "

They work indeed differently, as tiled background can only have a rectangle collision polygon, however they still react the same as sprite with a rectangle collision polygon (in this case too).

So definitively a bug I think.

This bug is also disturbing since I saw it originally as 8 direction fast moving objects tends to stop then move again when approaching a wall. But anyway, the fact it is solid or not should not change the way "On collision triggers" this much.

It's the same thing with a tilemap, and tilemap is not a tiledbackground.

Aphrodite That is interesting. I did not try replacing the tiled backgrounds with sprites. I tried to keep it in the scope of what you made, assuming you had a reason for using tiled backgrounds instead of sprites. Perhaps it is indeed a bug. I noticed even when it stops short, you can press again and it will continue until it touches. Perhaps you should try replacing the "8 direction" behavior with another movement behavior, eliminating the "Move" variable, and see if the result is the same.

Aphrodite That is interesting. I did not try replacing the tiled backgrounds with sprites. I tried to keep it in the scope of what you made, assuming you had a reason for using tiled backgrounds instead of sprites. Perhaps it is indeed a bug. I noticed even when it stops short, you can press again and it will continue until it touches. Perhaps you should try replacing the "8 direction" behavior with another movement behavior, eliminating the "Move" variable, and see if the result is the same.

Well the only thing stopping it is the fact On collision triggers, and as we can see, it should not trigger in that case (since the bounding boxes themselves are not overllaping, so the collision is 100% impossible in that case), that is the bug, it seems that solid has to be setted on the walls, and that it happens with 8 directions behavior only (though I could be wrong).

I do not think I need to go deeper, as this is a bug in my mind and so there is no reason to take it as a "side feature" that we should explain, waiting the opinion of ashley to know if it has to be fixed or not.

I don't think it's a bug. The 8 direction behavior will prevent the object being stuck inside a solid, so when it collides, it fires 'On collision' then backs out to its last position so it's not inside the solid. This happens in jumps since the object is moving speed x dt pixels per tick, so is usually not exactly aligned with the solid edge. If you keep pressing the direction key again it will accelerate towards the wall again and get a bit closer. So maybe you want to wait a fraction of a second before stopping it.

It is a weird way to handle it I might admit, every other behavior seems to detect the collision then push back just outside of the solid, not to the previous position, also nothing in the manual seems to state that the behavior stop before reaching the solid, it just says it is blocked by them, which means that it would be expected that it just does not enter the solid itself. Not that it reacts accordingly beforehand to not go towards it before even reaching it.

it just feels wrong.

Aphrodite, your model solved my problem, thank you!