Pathfinding Broken?

Discussion and feedback on Construct 2

Post » Sat Apr 15, 2017 12:07 pm

Am I doing something wrong here? I thought the cells counted as obstacles were set entirely as non-passable.

https://drive.google.com/file/d/0Bz86oQ8I9hPOeTNoWm02UlJiNkE/view?usp=sharing
B
45
S
13
G
1
Posts: 236
Reputation: 4,010

Post » Sat Apr 15, 2017 2:05 pm

I think the Origin of your objects plays a role here.
And of course the cell size.

Although something looks really wrong in your example... Maybe @Ashley should take a look at it.

I've adjusted some things and it seems to work now.
Although it still feels as if the pathfinding system is extremly slow.

http://92.51.171.10/construct/pathfinding.capx
B
40
S
8
G
3
Posts: 159
Reputation: 3,019

Post » Sat Apr 15, 2017 3:38 pm

That's looking better, but it still acts wonky when I put the pathfinding object directly next to obstacles and then set the cell padding to -1, because otherwise the pathfinding object can't move at all. The default settings for the pathfinding even have the padding set to -1 because I remember Ashley said collisions polygons right next to each other, but not overlapping, also count as colliding because of some bug with the platform movement behavior when he didn't do that. I made the origins at 0, 0 because I don't know how else to make them properly snap to the grid, since it doesn't have an offset option where I can put in something like 8px.
B
45
S
13
G
1
Posts: 236
Reputation: 4,010

Post » Sat Apr 15, 2017 5:44 pm

I have a few things to say. If that is ok, without been called a pain.

https://www.dropbox.com/s/3rkurb2i4y2u3 ... .capx?dl=0

1/ The property 'rotation speed' in the pathfinding behavior is rather slow. Since it has to rotate 180 degrees before it is able to move at all, it has a very slow start. The property 'Rotation object' is set to 'no', so, it seems like nothing is happening. In reality, the behavior is lining up with 180 degrees at the given 'rotation speed'.

I rotated that object 180 degrees in the layout, so you can see the difference. Now it dont have to rotate before moving.

2/ That generated obstacle map is ready the next tick. Not in the same tick as you use that regenerate action. So, you have to wait till the next tick before initiating that 'find path' action.

To do this, one possibility is (since one expects the events to run top-down) to use a boolean and place a pathfinding action in an event that checks that boolean above the event that contains the regeneration action.

Now you would think ...

This tick ....
Boolean is true ? ... find path (gets skipped, because boolean is not yet true)
On enter pressed ... regenerate and set boolean
Next tick
Boolean is true ? ... find path (it runs now because the boolean is now true) And it will find a path that accounts for the obstacles -, because the obstacle map is build in the previous tick.


But that is not what going to happen at all. The 'on keys pressed' is a trigger. And keyboard triggers happen (once) at the start of a tick. So, the 'On enter pressed' will happen before the 'Boolean is true ?', yet the ''On enter pressed' event is in the event list placed after the 'Boolean is true ?'

Lesson: Be very careful with triggers when the logic depends on the order of the events.

That is why i changed the trigger to a non-trigger in my example.
B
33
S
18
G
28
Posts: 2,493
Reputation: 20,950


Return to Construct 2 General

Who is online

Users browsing this forum: Yahoo [Bot] and 8 guests