Pathfinding imprecise when given object as target

Problem Description

If you add the pathfinding to an object (let's say O1) and give O1 a target as another object to reach as a destination. O1 will give uponce it reaches the general borders of the object and considers O1 as "arrived".

Here are some screenshots:

Changing the cell size by increasing and decreasing doesn't affect the path finding drastically (the first image is with Cell Size as the default and if changed to 0 as for the second image is for when you change the cell size to match the object's size -- note object is a square).

Attach a Capx

https://dl.dropboxusercontent.com/u/682 ... 20Bug.capx

Description of Capx

The CAPX has the same exact setup I was using and will replicate the problem above.

Steps to Reproduce Bug

• Create an object with the size of 15x15 pixels
• Add the object to a family.
• Add to the object (and not the family) the pathfinding behavior
• Don't change anything on the pathfinding settings.
• Use the "Find Path" and give it another object as the target.
• Use the "Move Along Path" and you'll find the same exact problem.

Observed Result

The moving object will not stop moving and mark itself as arrived at the dead center of the target object. The object will be marked as arrived and will stop once it "collides" with the target object.

Expected Result

The moving object should only be considered and mark itself as arrived when it reaches the dead center of the target object. If the above is desired then changing the settings would be needed to give a VERY large cell size.

Affected Browsers

• Chrome: Yes
• FireFox: Yes, but the moving object gets much closer to the intended behavior than Chrome
• Internet Explorer:NA

Operating System and Service Pack

Windows 8.1 with latest updates_

Construct 2 Version ID

r229 Beta

We don't normally investigate bugs that are not minimal projects. The attached .capx has 53 events, it probably only needs 2-3 to demonstrate the problem. There are also 3 layouts, non-trivial controls that I can't figure out within a minute or two, and no description on what to actually do in your .capx - this is why we ask for minimal projects.

Anyway, "dead center" of the target object is such an infinitesimally small target area that in practice it will never hit "dead center". This is made worse by the fact fast-moving objects can step large distances every tick (e.g. at 600px/sec, it's stepping 10px per tick, so it may not even stop on top of a 5px object). To solve this there is a radius tolerance where it can be near to but not exactly on the destination and count as arrived. Therefore this is by design.

We don't normally investigate bugs that are not minimal projects. The attached .capx has 53 events, it probably only needs 2-3 to demonstrate the problem. There are also 3 layouts, non-trivial controls that I can't figure out within a minute or two, and no description on what to actually do in your .capx - this is why we ask for minimal projects.

Anyway, "dead center" of the target object is such an infinitesimally small target area that in practice it will never hit "dead center". This is made worse by the fact fast-moving objects can step large distances every tick (e.g. at 600px/sec, it's stepping 10px per tick, so it may not even stop on top of a 5px object). To solve this there is a radius tolerance where it can be near to but not exactly on the destination and count as arrived. Therefore this is by design.

Sorry for the bad .capx. It is the first time I submit a bug and I didn't know that you only needed such a small CAPX. I am going to be more careful in the future and thanks for the explanation!