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