I try my best 
Let me know if you have any questions.
Hello,
I tried this tip for increasing the cost of diagonal movement by 50% and it work perfectly but only on the first level of the grid. The units move now twice further on the higher levels. How can I adapt this for a multi-level grid ?
Thanks in advance 
Totally forgot about how edge costs are set separately for higher levels. These costs are set in the Add Viewport Terrain To Arrays function in BP_GridManager. Generally what you need to do is to double the cost each time a cost is set within that function. I will not be home until tomorrow so I cannot show you exactly what you need to change at the moment. If you do not manage to achieve the desired result by doubling all cost variables in Add Viewport Terrain To Arrays by tomorrow I will show you using screenshots.
Yes I figured it should be on the āadd viewport terrain to arraysā but didnāt saw a reference to the cost (I checked your blueprint video on youtube but there is a lot of changes since this vid). Iāll have a second look, Iām new in UE4 and sometime, BP can be a little bit mazy.
Thanks for the help
I tried yesterday to find were to set the costs in the function but was not able to achieve it. Your screenshots could be a big help for me
Hi again, I have access to my computer now. Little wonder you had trouble figuring this out yourself, as it was quite a bit more complicated than anticipated. In the Gameplay Grids function it is very straightforward to identify which edges are diagonal and which are straight, but at a later point this is more tricky, as the Edge Array does not distinguish between various forms of edges. There are many ways to determine this, however, so it is definately doable, but takes a bit more work than just doubling the edge costs set in the graphs. You just need to alter one macro, though, which is the Get Edge Cost from Z difference macro. Here is how to alter it so that it sets the edge costs of all straight edges to 2 and all diagonal edges to 3:
Here is the original for comparison:
Since this modification alters the inputs of the macro you will also need to connect the index of the parent tile instead of the Z height of the parent tile every place the macro is used. It is used three times in Add Viewport Terrain To Arrays. You can easily find all three by right clicking the macro in the MyBlueprint tile and selecting Find References.
This seems to do the trick. Hope that helps!
Thank a lot ! Iāll try this as soon as I can 
It work perfecly, thanks a lot man, youāre da man
One last thing : Do I need to also change something in the ātile parentā BP (in the āmake edge cost int arrayā function?) ? I double the edge costs of the ātile_cost 2ā (from 2 to 4) but it doesnāt seems to do the trick anymore.
In any case, thanks a lot for your quick answers
You should not have to change something in the functions. Doubling the edge costs does seem to do the trick on my end (though you should multiply diagonal edge costs by 3). Like this:
For this result:
Thatās really strange, on my hand tiles with cost doesnāt work anymore.
And it also seems to have an impact on the multilevel : If I donāt have a Tile with cost on the edge of my higher level, pawns can just ignore hight and walk from a level to an other.
That is very strange. It works fine on my end. Can you post screenshots of all three locations of Get Edge Cost from Z difference in Add Viewport Terrain To Arrays so I can see if everything is hooked up correctly?
is there a tutorial on the 2d hydraās lair map? I tried to recreate it using my own tile sheet and the character doesnāt move!
Hello charliepilotti, I plan to make such a tutorial in the future, but have not gotten around to it just yet. There might be many reasons why the character doesnāt move. Could you explain all that you have done so far? Is it just the grid manager placed on top of a tile sheet? The first thing I would check is to see if your tiles have collision enabled and are set to block PathTrace. If that does not work, please explain what you have done in a bit more detail and I will try to find the problem.
hey man I actually got it working, I hard to restart my editor. Even though I added the path trace to collision it wasnāt showing up until I restarted. Another thing I actually had a question about is what use is the dungeom tilemap base? I canāt see where itās actually being used, but iām still new to visual scripting.
Good that you managed to get it working, though it is weird that it required restarting the editor. Iām not at home and cannot currently check the toolkit, but I believe there are three different tilemaps: one containing all walls, one containing all floors and one containing both. I think the third one is tilemap base. In any case, the one containing everything is the one I used to make the entire dungeon, so I knew how it would look with both walls and floor tiles in place. I then made two duplicates: one where I removed all the walls and one where I removed all floor tiles. Then I made the one with just the floor tiles block path trace and the one with only walls to have thicker collision boxes (pointing up towards the camera) and block range trace, so that walls would block visibility. I kept the base tile map in case I needed to go back to it for any reason, but it does not serve any real purpose in the finished toolkit.
Hi!
A little curious when the next update is coming? Weāre especially interested in the cover/accuracy system.
Hi there! Itās going forward, but a bit slowly. Work has been busy, and in addition Iām getting married in a week and then going on an extended honeymoon, so Iāll be pretty occupied for the next few weeks. I have however implemented both a cover and accuracy system that is probably pretty close to what Iāll end up including in the update. Iāll explain my solution in this post so that anyone who needs a cover system quickly can replicate what Iāve done.
First to create some context for the blueprints below, Iām creating a new example map to include features like cover and accuracy. Since I do not consider these features generic enough to include in the base toolkit (to avid it from getting cluttered) Iāve added these features in child actors of the original actors. The example map has the working title SciFi because of some SciFi themed assets Iām using, so the child actors are called for instance BP_GridManager_SciFi and ATBTT_PlayerController_SciFi. In the blueprints below I will frequently be casting to these child actors to get access to their functions and variables, though if you want to replicate this yourself you might not want to use child actors and could just modify the base actors themselves.
The goal of my solution for cover is to have everything be pregenerated based on the terrain placed in the level, both to save time for the users and to speed up processing during gameplay.
For cover I have created a new array called Cover Array in BP_GridManager (or really BP_GridManager_SciFi). This array is a nested array of structs. It is an array of arrays, where each nested array is an array of structs containing an index integer and a cover float. The main array is resized to be the size of the grid. The idea is to have each index of the array represent a tile on the grid and each member within the nested array represent a tile edge of each tile, pointing to which index the edge is facing and what its cover value is (hope thatās clear 
).
To auto generate cover at the start of the game I have created a new trace channel I call Cover Trace. I then trace between all tiles two times using this trace, one quite low and one quite high. If the high trace is blocked I count this as full cover between tiles (with a high cover value). If the high trace is not blocked, but the low one is I count it as half cover.
Iāve made the following function to check whether a tile has cover from another tile. If the attacking tile is on the other side of the cover edge, accuracy is always reduced by the same amount, regardless of how far to the side of the cover the attacker is standing. This is both easier to calculate and probably for a player to understand.
For calculating hit chance I want to take into account more factors than just cover, so I have made the following function to take distance and other modifiers into account:
All functions so far have been contained in BP_GridManager_SciFi. I have also created a new unit child actor currently called Unit_Player_SciFi_Weapon (so called because Iām experimenting with units carrying weapons that can be switched). This unit has new attributes called Accuracy and Dodge. Accuracy is a value between 0 and 1 representing the base percentage chance this unit has to hit another unit with its attack. Dodge is a similar number subtracted from the accuracy of any unit trying to hit it. Here are the nodes I use in the event graph of this unit. These nodes are inserted as part of the Attack Victim event, before Attack Animation, but after all other nodes.
It is still a work in progress and I have also added more functions for displaying XCOM-style shields for cover and such. What I have described above should still hopefully be enough to get you started. I hope I have explained it well enough, but feel free to ask if you have any questions. Like I said I will probably not have any time to work on this until I return from my honeymoon in August.
I had to read that several timesā¦
Like many following your progress, Iām greatly interested in the cover system. The way youāre setting it up has cover precalculated, is it possible to then run the cover traces in game? Iām thinking about when weapons fire or explosives destroy cover during the game, requiring a recalculation of what cover covers what pawns. I assume that if the traces are run during the game there would be a bit of a performance hit on large grids to run so many line traces so you donāt want to do it every time a weapon is fired?
I seem to remember actually that there was a bit of slowdown in XCom whenever cover got destroyed. Could be that they used something similar to your system.
And congratulations on the wedding and honeymoon !
Thanks! Yeah, it was a bit tricky to explain 
Maybe I can make it a bit clearer. Below are four array elements (of which there would be a number equal to the size of the grid). Each of these contains a nested array (of four elements each in this example, though this would vary depending on the number of edges of each tile). Each of these array elements contain an integer and a float. The integer points to an adjacent tile (the edge being between this tile index and the tile index of the array element in the main āparentā array) and the float defines the cover value of this edge.
****[int,float] [int,float] [int,float] [int,float]] ** ****[int,float] [int,float] [int,float] [int,float]] ** ****[int,float] [int,float] [int,float] [int,float]] ** ****[int,float] [int,float] [int,float] [int,float]] **
It should be possible to re-run calculating cover for a smaller area. Just use the Get Indexes In Range function in the area where cover may have been destroyed and then run the same cover generation code for these tiles as was originally done for the entire map. I designed the cover system with this possibility in mind, and though I have not tested it out yet, I see no reason why it should not work.
I think I did actually misunderstand a little originally, thanks for this explanation. Yes the way you have it here running the cover trace in game in a given area should be reasonably efficient - I was anticipating that the whole level would have to have the traces re-run at once but thatās not the case.
One further question (if you have time) - how does this work with multi-level grids or altitude differences?