Haven’t made a wiki before, so I’m not 100% sure how it all works, but I think it should be a good fit. Having edits pending approval could be a good way to do things, but if it is possible it might be better to give the possibility to post freely, but to add a header signifying if I have read through it or not.
Hehe, some slight misquotation going on there, but point taken. Making tutorials on the grid arrays is the most pressing, I think, and most support request I’ve gotten in the last couple of weeks are tied to such things. It is also a prerequisite to be able to explain the big unit functionality.
Good start, but some changes need to be done. The biggest issue is how edge costs are normally handled by the toolkit. The cost to enter a tile is stored in the tiles that can enter the tile (normally the tiles that surround it). So the GridEdges TMap for a single grid index really stores the cost it takes to leave the tile, but not to enter it. To do this you need to get all the surrounding tiles and modify their edges (using GetIndexesInRange, for instance). Then you would need to store the costs of all of these tiles before modifying them so you can restore these costs later.
This is a tiny bit cumbersome, but not terribly difficult to set up. However, it becomes more challenging as soon as you have multiple corrupted tiles at the same time. Say you have two corrupter units that corrupt tiles that are adjacent. The first spawned corrupt tile modifies the edges of all surrounding tiles, which will overlap several tiles modified by the other corruptor’s corrupt tile. When the second corrupt tile is spawned it stores the current state of the GridEdges TMap for all tiles, which includes those modified by the first corrupt tile. When it is destroyed it will thus use these values for the edges of surrounding tiles, meaning that the surrounding tiles that overlapped would never be restored to their original value.
This is basically the same problem as I faced when I added big units to the game. These units modify a GridBigIndexes TMap whenever they move, and the tiles they modify in this fashion can be modified by multiple units at once, which might die or move in any order. I solved this through a fairly complex solution, where I also store the number of units that modify a specific tile and keep track of which units modify each tile in what way.
As you see in your case this creates lots of complications for what should ideally be a pretty trivial thing to do (temporarily modifying the cost of a tile). Luckily for you I added a feature a few updates ago to simplify exactly these sorts of problems. If you set bUseSimpleCosts in BP_GridManager to true and set the PathfindingType of all your units to Simple it will allow you to use so called simple tile costs. These are a single integer for each tile that represents the cost of entering this tile from any direction (zero being impassable), and are stored within the relevant grid index itself and not the neighbors. If you use the Simple PathfindingType the cost of entering the tile will be whatever is higher of the cost stored in GridEdges and GridSimpleCosts. Now for your corrupted tiles you can quite easily modify the GridSimpleCosts TMap and hopefully get the result you are after.
Since you aren’t modifying tile costs in the normal way I would recommend basing your corrupted tiles on BP_GridActor (the parent of BP_GA_Tile) and not BP_GA_Tile. I tested this out, and here is how I set my corrupted tile up:
I set the SimpleCost to ExposeOnSpawn and did the following to test if it worked:
Note that if you have already activated a unit so that RunPathfinding has already finished and then add a corrupted tile it will not affect the current pathfinding, which was calculated with the state of the edge array when it was run. To have the corrupted tile affect the currently active pathfinding you would have to run RunPathfinding again.
Hope this gets you close to what you’re after. Note that if you want your units to modify specific edges and not the cost of an entire tile you’ll have to go with the more complex solution outlined above.