Thanks I thought I had watched them all I guess not. Could I call the add viewport terrain to arrays function manually when I add something. What I am doing right now is I am building the function of the D&D board games with the tile system that as you explore the edge of the map you get a new random tile. Once I get that function working I have some other stuff I will add to it. The point is you do not know what the next area will be until you reach the edge. This is important because there will be an array of preset rooms that as you add new rooms you take them from the array and add them. This means even if the array was exactly the same if the player goes left instead of right the map will be different. I am actually thinking of storing the state of the actor being on the edge and then calling a function when the turn is over to check if they are still on the edge.
You could call it after you add a romm, but it would be overkill, as it looks at every single tile and tile location in the game, which is likely to cause a noticable drop in framerate if itās done at runtime. I would instead suggest one of two methods. The first is to procedurally generate your entire dungeon at event begin play, but to make most rooms invisible. Then you would make them visible instead of spawning them at runtime. The other possibility is to add the new tiles added directly to the Edge Array when they are spawned. See my sixth tutorial video for an example of how to do this, where I do something similar when I change the edge array to reflect difficult terrain caused by exploding trees: UE4 - ATBTT - Tutorial - Adding New Features - YouTube
That is an interesting thought. I also considered just making each room a blank base tile make it invisible and then make it visible as needed and just spawn the walls. Rather then the whole room. Though would that not go back to my other problem with the empty floor being walkable? I guess if I set the collision to false when I hide it. Not sure. I will have to play a bit more. I will make sure to watch the two videos you linked to see if maybe there is something else I can take advantage of.
Hello again.
I must say that Iām really impressed with your video tutorials about the toolkit. Really good and informative.
If you do not show the default tile and set collision plane walkable to false, only the tiles you designate (or with through heightmap tracing) will be walkable. Iām partial to creating the entire dungeon at begin play if there is no specific reason that you need it to be determined at a later point, but either way should be fine. Good luck with finding solutions, and donāt hesitate to ask if youāre completely stuck on a problem.
Thanks! I spent a lot of time on them, so it means a lot to hear that. Let me know if you have any requests for further tutorials (that goes for anyone who reads this thread)
A tutorial on having multiple different grid managers in one scene would be useful if itās possible. As would having a tutorial for multistory buildings (but i think thats later in the pipeline)
Thanks for the suggestion, but these are changes that will require a pretty major reworking of some of the fundamental subsystems in the toolkit. Thus this is something that is a better fit for an update than a tutorial, which is what I have planned. I am planning on adding multi-level grids in the not too distant future, but multiple different grid managers are a lower priority at the moment.
Iām interested in knowing what People would use multiple grid managers for, as most cases I can think of are pretty niche. For dungeons one can simply use a single grid that is large enough to encompass all the rooms in the dungeon. The toolkit is efficient enough that there isnāt that much to gain in terms of optimization for dungeons this way.
Another use I can think of is if you want multiple board games within a single room, if perhaps you want to make some sort of digital arcade with multiple turn based games. You could also make something like this using the same Method as for the Dungeons mentioned above, but I can see that it would be a bit awkward. What would you be using multiple grid managers for, tamaster92?
Personally it would be to have different shaped boards without having to block off access to some of it. A T shape for example would be easily achieved with two rectangle boards connected instead of one big square with some blocked out.
I can understand it being a low priority though, not exactly super important 
Ok, thatās a bit of a corner case, but I can see how it would be useful in such cases. However, having multiple grids that you are able to move between would require changes to both Pathfinding and Find Tiles in Range, which would for every tile checked also make sure there might be any tiles that can be moved to/seen outside the bounds of the current grid. This would in the very least require some new branches.
This might not seem like that big of a deal, but every new addition to those very heavy function means a measurable slowing in the calculations. Even though this would probably not be noticeable to the user I would personally prefer map building to be a bit more awkward compared to making pathfinding less efficient if I was to make a T-map.
Iād prefer that too tbh. I just wondered what was possible
Keep up the amazing work!
I know that in XCOM, on some landed/crashed UFOs, the tiles on the UFO itself is rotated 45 degrees compared to the rest of the map. But in that case I think that it would be easier to let a single grid manager handle rotated tiles as well somehow. But you know it better than me.
Ok, didnāt know that! I couldnāt find any screenshot that showed this off well, but itās kind of hard to tell when they donāt really show the grid. Could they have faked it doing something similar to this?
I know that at least one of the medium ship maps does this. There may be more maps that does it, but Iām absolutely sure there are at least one map that does it.
However, they might have faked it the way you show in the screenshot.
Ok i have just recently baught this toolkit and it is amazing!!! i realy like how everything has been designed so user friendly just some stuff that confused me and i would like to know more about!
in the tutorial where you add destructable terrain you use a function that sets a variable named pawn array or something like that and then you access it this is really wierd because wouldnāt it have been easier just for that function to have a result we can access?!?! and then set any variable we desire? beacuase right now it seems i would have to run that and then get the variable and set my own variable every time a procedure that i find no sense in?!?!
for mobile development since we canāt use decals as i recall! what would you advise on using to show tiles on terrains with height?
the second is to do with multi level grid your system uses indexes to identify every tile you could use a 2d array and that would solve identifiers as for detecting you could use a multi line trace and have the results get compared to determine if it is two levels or not! as for path finding it wouldnāt be that hard because the same edge system would work in a 2d array system only considering the first element! since you use cost to determine access this system should work realy well. and your visiblilty trace already works in hight and at least right now i canāt think of anything tha would need to be considered! your continuing support of this product is epic and i hope i can help the toolkit get even better!!
Hey , one last quick question, and then Iāll get out of your hair. 
Where in the Blueprints does the cost of moving to specific tiles in the arrays get determined and calculated when determining whatās in range of the pawn that they can move to?
Rather, more specifically, where does the height cost get added into the tileās cost?
Iād like to set pawns to be able to optionally ignore the height costs if they can āflyā(Possibly ignore ādifficult terrainā as well), which Iām assuming can be done pretty easily with a branch node or two, Iām just iffy on where.
I tried fiddling with the Search and add Tile function thinking I might be able to override the costs from there, but that gave me rather odd results (Character had a movement of 10, but could only move 2-3 spaces per movement phase)ā¦
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:
Mutlitier support in the update after next?
This toolkit gets better and better
Thatās the plan You can see the list in the first post for most of the major planned features. After the next update, which is mainly focused on mobile and 2D, the next will be for XCOM-style tactical squad based games, with multi-level grids, cover systems, advanced combat abilities (such as overwatch), fog-of-war etc.
Thanks for the detailed explanation!
very smart on using an example! so iām going to do the same to explain!
332 is a small enough example and good
i am actualy saying change the index to a 2d element instead of 4 use (4,0) and 13 would be (4,1)
now the tricky part might seem that path finding would have to change dramaticly but no! because in the same way 4 shares an edge with 1,3,5,7 it shares and edge with 10,12,14,16! or in the 2d way (4,0) and (4,1) both share an edge with {(1,n),(3,n),(5,n),(7,n)} n being the floor number in this case 0 and 1.
but obviously two tiles on top of each other share any edge but you would simply always consider it null or zero (none passable)! now for the search load in identifying all of the edge costs!
ok i am horrible at explaining so iām going to upload a photo of a test map the same size you said 332 and this explanation is for that!
(i am not going to consider how your system acts with tiles out of the maps borders as i donāt have it in mind and i am not going to consider diagnal movement either it is a complication but i donāt think it could break any thing)
for the sake of this example i am going to consider that edges have the same cost of passage between two tiles example : going from tile a to tile b has the same cost of going from tile b to tile a (two tiles share an edge)
so a default tile will share an edge with every tile around it on the same floor with the cost of one (if they are default tile) and share an edge with every tile around it on its top and bottom floor with the cost of ( none passable) considering they are default tiles. As a default grid map would act in this example a 33 grid floating on top of another 33 grid
in this example I have made 5 of the second floor tile into nothing tiles which share an edge cost of 0 with every thing and I have added two walls making the cost between two tiles on the floor it is on into 0 and between the same tiles and the tiles in front of them but in the upper level also zero in other words:
(0,4)<->(0,5) cost = 0 / (0,4)<-> (1,5) cost = 0
(0,7)<->(0,8) cost = 0 / (0,7)<->(1,8) cost = 0
and one wall ladder that makes the cost between the two tiles on the same floor equal to zero but for one of the possible routes in between levels it makes the cost 1 or any number meaning passable!
In other words:
(0,0)<->(0,3) cost = 0 / (0,0)<->(1,3) cost = 1
So later when path finding check costs and it reaches (0,0) and it sees the cost of one it will add (1,3) as a possible destination and reachable tile
Now I now there is a lot to talk about doing to do with optimization for example right now in a 4 square grid not considering diagonal movement for a two floor map the checks will get twice the size for each tile!!! For a 3 floor map saying we might want something like a ladder connecting the first and the third it woulf be three times the checks and so on and so forth so I think it woul be much better to have an outer level reach check of some sort but in the end we are talking about a three floor level the summed checks would already be a lot if the three floors where put next to each other.
If I was still not able to give a good explanation please pm me and we can talk over it on skype
Iāll be interested to see how you do cover systems - iāve started slowly adding one into the toolkit for my game but itās very basic atm - just volumes attached to certain tile types which tells the pawn he is in cover