Moving in a grid, better method?

xRegnarokx You're overcomplicating this on several levels.
First, if your movement is grid based, then you need a custom data structure that holds the grid data, including occupancy info. I think I already suggested that. Doing shapecasts (i.e. physical collisions) is antithetic to grid organization. The whole purpose of having a grid system is to not need to do map collisions. A grid cell can either be occupied or not. It's a logical state, not a matter of colliders it the scene. Once you establish such structure, it'll be much easier to handle movement. Some impassable areas may not even be detected by collisions (e.g. bodies of water). So implement a logical cell occupancy data structure first.

Next, implement "instant" movement from cell to cell, that checks for occupancy in the occupancy map and handles the positioning onto cell coordinates properly.

Next, interpolate that instant movement using tweens or manual lerping in _process().

When you have this in place, we can talk about how to handle unit overlaps. It can be done with the above system without any complicated additions.

xRegnarokx I don't think I recommended A* in your latest batch of questions. A* has nothing to do with movement per se. It's a path finding algorithm. For simple cell to cell movement you don't need any such fancy stuff. You just need a 2D array the size of your gird, populated with boolean values that signify if a cell is occupied or not. That's all there is to a basic occupancy structure. Later you can upgrade it so that each cell holds a terrain type or whatever other cell info. But for basic occupancy, you just need to store one bit of information per cell.

xRegnarokx Your barrier is that you've set up your system too complicated and painted yourself in the corner with it. I'm telling you to re-do your system so that doesn't happen.

You also ask specific questions without describing your setup precisely. How do you get Vector3 for moving to a cell from where? Is the map flat? Is it a heightfield? Are you using GridMap? Etc.

In general you need to implement a function that calculates a world position from a grid position and vice versa. Similar to tilemap's map_to_local() and local_to_map(). For that you need to know your grid unit size and your grid origin. Calculation then simply boils down to translating the input position so that both spaces's origns match and multiplying/dividing it with cell size. If your grid and your world origin coincide, then you only need to multiply/divide with the cell size.

xRegnarokx What is z index you're referring to? In 3d, you don't need any z index. You can simply have continuous elevations.

You should first describe your map. How is each cell defined via its logical properties (terrain, elevation etc) and then how you plan to represent that visually. Then we can discuss how to reflect that in your custom grid structure and how it can all be turned into movement in 3d space.

Or better yet, give a reference to an existing game that's similar to what you're trying to do.

xRegnarokx Oh so there's vertical movement as well? You should have mentioned that from the start. Best to post some gameplay/movement footage.

I googled Tibia gameplay videos. All movement there appears to be happening on the floor plane.

xRegnarokx You should start by modeling your map with data. Introduce a cell class that contains relevant cell data

class Cell:
	var z: int = 0 # how many stacks, your "z index"
	var walkable: bool = true
	# add more stuff later

Have a "2D" array of such cells that represents your map:

var map: Array[Cell]

The array is 1D (since there are no multidimensional arrays in GDScript) but you can implement 2d access functions so it'll work like a 2D array/map:

func get_map_cell(map_coord: Vector2i) -> Cell:
	# stuff

func set_map_cell(map_coord: Vector2i, cell: Cell) -> void:
	# stuff

That's your basic map data structure. You can do a lot with it.

xRegnarokx It can be either. Your map has certain characteristics that should be described through data structures. This is called modeling with data and is essential for developing any kind of software system. I tried to do this in a most rudimentary (and incomplete) form, following your (incomplete) description and what is shown in the video. This is the part that is separate from actual visual representation which can be either 2d or 3d. For this part of code, looks don't matter. When you model your game world with data, you need to primarily think in this semi-abstract way, which doesn't really have anything to do with 2d or 3d or Godot for that matter. It only has to do with your game world. Looks are built on top of it, or based on it.

xRegnarokx If it is 3D, I still am unsure if I understand how this would help me with finding the z index for movement purposes. How is my character if I am not using the build in physics to know where they should be on the z index.

There's literally z property in the cell data which holds the integer number of stacks. If you know the height of one stack, multiply z with that height and you've got the vertical position in the world. It's basically a simple version of heightfield.

If you compare z of the current cell and z of the cell you want to go to, you'll know if you need to climb, descend or go straight. Or if a cell is an obstacle that is not climbable etc.. All this can and should determine how you animate the traversal.

xRegnarokx Note that z is perhaps a wrong name to use here. Height would be much more appropriate as it's not linked to any coordinate system. In Godot's 3d the convention is that a ground plane is in x and z directions and up is in y direction.

Here's a more elaborate "sketch" of how the whole map class could look like. Don't just copy paste this. Might not work. It's just to show the way of thinking/organizing.

class_name Map extends RefCounted

# cell data struct
class Cell:
	var terrain: String = "grass"
	var height: int = 0
	var walkable: bool = true
	func _init(iterrain: String, iheight: int, iwalakble: bool = true): # object constructor
		terrain = iterrain
		height = iheight
		walkable = iwalakble
	
# map size (number of cells)
var _size: Vector2i

# map
var _cells: Array[Cell]

# pyisical cell size
var _cell_size_physical: float = 1.0 # xz size of a cell in world units
var _cell_height_pyhsical: float = 1.0 # height of a cell in world units

# initialize the size of array that holds cell data
func initialize(size: Vector2i):
	_size = size
	_cells.resize(_size.x * _size.y)
	
# returns 1D array index from 2D cell coords, depending on map size 
# used to access a 1D array as if it was a 2D array
func _get_array_index(pos: Vector2i) -> int:
	assert(pos.x >= 0 and pos.x < _size.x and pos.y >= 0 and pos.y < _size.y) # boundary check
	return pos.x + pos.y * _size.y
	
func get_cell(pos: Vector2i) -> Cell:
	return _cells[_get_array_index(pos)]
	
func set_cell(pos: Vector2i, data: Cell) -> void:
	var cell = get_cell(pos)
	cell.terrain = data.terrain
	cell.height = data.height
	cell.walkable = data.walkable
	
# some test utility function
func add_wall(pos: Vector2i) -> void:
	set_cell(pos, Cell.new("wall", 1, false))
	
func add_barrel(pos: Vector2i) -> void:
	set_cell(pos, Cell.new("barral", 1, true))
	
# etc...

Now you can use some generation algorithm to generate an actual maze or map layout into this structure. And when you have that, you can proceed to make a visual representation of it in either 2d using fake ortho perspective or in 3d using actual geometry.

If you prefer visual editing of the map, You can make an actual GridMap with some tiles etc... and write an utility script that interprets what's in the GridMap and populates your data structure.

Alternatively you could implement the same data structure as an extension of a GridMap node, making it more coupled with actual 3D graphics, but the way of thinking about and organizing map data would be exactly the same. You need a "logical" structure that's "underneath" the visual representation.

The movement comes after this, because the movement system needs this for proper functioning. You can't really have a grid based movement system without some data in a grid

xRegnarokx Technically you could store all cell data into metadata of the gridmap meshes. In that case you wouldn't need a custom Cell class or an array of cells, although the code that access the cell data would be a bit more verbose.