Ok, thanks. I’m sure you’re right. I’ll keep collecting corner cases and if I find enough I’ll move it up on my priority list, but needless to say the list is pretty long 
Thanks! I’ll try to help as best I can.
You’re thinking that it could have an integer array as input/output, so you could specify what array you want to fill yourself? I agree that that makes sense as people start experimenting with the functions some more. The main reason it is not like this at the moment is that Find Tiles In Range initially had a very specific use, and was only used for pawn visibility. As only one of this would ever be called at once, there was little reason to make the function messier to accommodate for different arrays. I will change the function to have an input/output array in the next update, and do the same witht a few other functions (such as pathfinding). Thanks for the suggestion 
You can still use instanced static meshes with heightmaps, as long as the terrain is composed of flat/slanted tiles, as the ISMs will rotate to fit the underlying tile. For stuff like moulded landscapes this looks really bad, though. I guess one could use a spline that connected all the outer tiles of the tiles in the CanMoveTo array which hovers a bit above the ground. You could also use floating orbs or similar on the edges, though this might not look that good. There might also be other possibilites than decals for projecting onto terrain, such as ligting/shadow that could acheieve similar effects to decals, but I haven’t tested that out yet.
Ok, thanks for the input, but I’m having a somewhat hard time following what you’re saying. Are you suggesting that I simply make my 2D arrays into 3D arrays by doing the same thing as when I converted my 1D arrays into 2D arrays? What I mean is that if I have a 332 array, index 4 would be in the center on the bottom level, while index 13 would be on the top level etc.? That’s the way I have considered doing it myself. It requires larger arrays than if I use smaller sub-grids to represent higher levels, but arrays can be extremely big without any issues, and it will be a lot simpler to work with for users.
Pathfinding would be easy in this case as I could do what I’m doing now, but also check up and down. If I check every up and down direction, though (upNW, upNE etc.), this would more than triple the amount of tiles search, slowing down pathfinding significantly. Therefore I would probably only want to check directly up/down and then check the surrounding tiles if the one directly above/below is marked as walkable.
My visibility system does not work in height at the moment, but it would similarly be pretty easy to expand to a 3D array. I’d still need to check how seriously it will affect performance, though.
So to sum it up, 3D arrays are easy, but might not be the best performance wise. I’ll test multiple solutions as I start working on multi-level grids for the next update after the coming one.
Don’t worry about it. I honestly enjoy answering questions about the toolkit
Various aspects of height/movement cost are set a few different places. Firstly, all actors of the Tile_Parent class have a public variable called EdgeCosts that determines the cost of entering that tile from a certain direction. These costs are added to the EdgeArray in the Add Viewport Terrain To Arrays function in BP_GridManager (inside the second comment box). If the toolkit is set to automatically change edge costs depending on height differences this is done in the third (hexagonal) or fourth (rectangular) comment boxes in the same function.
If you want units to ignore terrain costs you could indeed change this in the Search And Tile function. Here’s one way to do this which will only have a very slight impact on pathfinding efficiency:
