[Path finding] No slow down?

Anyone using the path finding behaviour know if its possible to make it work without stopping the objects as it changes path?

Normally when you tell something to go a certain path and its moving and then changes to a new path the object stops, rotate and then moves again.

What im looking for is to make an object take a smooth path to the new location, so it takes the speed and direction of the object into account as its generating the new path.

Know its a long shot but maybe someone found a solution or workaround.

Cheers

I never tried this but just an idea/theory you could try, make an invisible object that is finding a path and the object will spawn "checkpoint" which the actual character will move to the min(iid). If the invisible object stop,rotate,return same path, make it destroy the checkpoint on collision. I think this will work if the invisible object move fast enough. Probably works in confined path only, not sure if it is good for open space.

Try it, see what happen and let me know

Unfortunately such solution for my game wouldn't work, as it would increase the number of objects to something that would hurt performance quite a bit i think. Or it just wouldn't be able to calculate it fast enough to avoid stopping the ships anyway i think.

Also it is ofc difficult to know as i haven't explained what and how im gonna use it But when the player switches back the path finding takes over again. But as it need to recalculate the path the ship, they some times stops for a short while before moving, and it just seems weird.

But if i could make it so the ships continued moving as the new path was found the problem would be solved. I do however get some better results by disable and enable the path finding, but its a bit buggy at the moment.

But you suggestion gave me another idea that i might try to solve it

The problem is pathfinding can take a moment to complete, in which time the object could move to a new cell, requiring a new path to be found from a new starting location... during which time the object could move to a new cell again, and so on.

If it's noticable, you probably need a larger cell size so paths are quicker to calculate.

Thanks for the reply.

The problem is/was that as i increased the cell size the precision went with it as well, so units would not go to the correct coordinate but just somewhere near it, and that looked weird as the scale of objects are not that big, it needs to be somewhat precise.

The idea or hope was that somehow it was possible to make the path finding calculate based on the speed and direction of the object, where the actually path finding would start. So even if it changed cell it wouldn't have reached the point from where the changes would take place. But as it did the new path found from that location would take over. But as i said i knew it was a long shot, and not even sure that A* is capable or used for such type of prediction movement.

But anyway i remade how it works so it doesn't rely on path finding in those cases anymore and it works as it should now.

However it uses a every tick movement system now, and since there might be a lot of units presents on the map at the same time, i was wondering if there are any performance hit from doing it that way compared to for instant using one of the other movement behaviours or will it be the same in the end?

The movement is pretty simple a unit have a direction and move "unit_speed * dt" in that direction, so its not more complicated than that. But read somewhere in another post that someone said to stay away from every ticks. Which i agree with in most cases as its not needed, but in this case i need that or one of the behaviours, but would prefer not to discover later on that doing it with every tick will serious limit the amount of units (Im not talking 1000s, but around 30-50 max) which ofc is not a lot, but as the rest of the units are calculated offscreen there might be 1000-1500 in total, so no need to make it worse than it need to be