xyz I guess the "a bit too complicated for a mere grid movement" haha. Once I have multiple entities moving around I am worried it will create larger problems with how complicated it is, also shapecasting for moving to a location is unreliable if two objects want to move into the same area at the same time they won't detect collisions until they do, that will force them to either overlap, or stop not in a grid_position. So, if I make the raycasts longer to detect the "next" move increment, that doesn't account for coming from another angle into the same space...
I am just running into a bottleneck on how to implement a movement that locks everything to a x,y of 1 meter, while allowing for the z index to be handled by physics, rather than manually changing it as well (though that may be what I have to do). If I don't use move_and_slide is there a reliable way that I can get the z index of the terrain, so that I can maybe interpolate the position, ignoring physics interactions and setting up an occupied tile array for positions? I guess the moment the z index comes into the picture in a game that I am trying to emulate psuedo 2D it makes it complicated for me to navigate movement.
I considered setting up like an Astar movement alongside a gridmap and using that as a base, with the array that stores occupied tiles, however, I am running into how to implement an Astar in 3D, I've implemented it in 2D several times, along with my own very basic custom movement algorithms. I am struggling how to get the Vector3, and if I get them is it the top of the object or the middle, or bottom...