this is neat!! awesome work !
Thank you! 
I haven’t posted in this thread for a while but if you have any questions, feedback or suggestions let me know!
Hello everyone, its been a while. I’m pleased to announce an upcoming update for this plugin! The update introduces grids with different height levels for both square and hex grids. Tiles now have a terrain type and a height level, which can both affect a unit’s movement and targeting. Have a look at the videos below:
USAGE
Height level specification and retrieval
Height levels can be specified in the editor or at run-time. When specifying in the editor, height can be specified together with the terrain or separately (overrides the terrain height). At run-time, you can set the height using the LevelGrid blueprint function SetHeight(X, Y, Height). This can be called even after the game has started.
The example game mode and maps visualize the height levels. If you want to use your own world space base height and height step size, simply change the LevelGrid actor’s GridTransform values. The visualization and all units will automatically update. If you’re planning to use a custom solution to visualize the grid, then the LevelGrid function GetHeight(X, Y) can help you with your own tile placement by returning the discrete height level (int), the world height (base height + height level * step size) and the world height offset (height level * step size). Use whichever value is most convenient for you.
Unit interaction with height
You can specify per unit what (discrete) height differences the unit can traverse and the movement cost for doing so. Also, you can specify per unit at what height difference the unit can still attack. In both cases you can have different behavior for upward and downward height differences. Recall that any actor that implements the included IGridActor interface can be placed on the grid. IGridActor now also has functions that allow you to specify how the unit should interact with height differences. Your implementation of the function CanMoveVertical( int DZ ) : bool CanMove, int Cost defines whether the unit can move ‘DZ’ height levels up or down in one step, and what the extra movement cost is for doing so. Your implementation of the function CanAttackVertical( int DZ ) : bool CanAttack defines at what height differences the unit can still attack.
Examples
Since units now interact with height and with terrain, one can make many interesting combinations, for example:
- A helicopter that can move up and down at will without extra movement cost
- An infantry unit that can climb up to one height level up or down, at the cost of one movement point
- A tank that can ride down ledges but not climb back up
You can also choose to just use the height differences to make the grid match your non-flat floor and not have it affect unit capabilities.
RELEASE DATE
I’m finalizing this update soon and submitting it to the Marketplace the upcoming week. Stay tuned!
Wondering if you can overlay a texture on top of your grids without affecting the grid functions. Ground, roads, floors etc. Also, I assume it’s possible to add walls, etc and have them on tiles marked as impassible?
Yes to both, you can overlay textures without affecting grid functions and you can add wall geometry on top of tiles marked as impassable. To read about how this would work in practise, check out Section 3.2 in the user guide: http://www.zkshao.com/downloads/TBStrategyGrids_UserGuide.pdf
There you can see how you would be able to define walls in the editor (define an InitialTerrain area with a blocking terrain type) or set these via blueprint (SetTerrain with a blocking terrain type). Hope that helps. Since you can set walls via blueprint, its also fairly easy to create a wall actor that would auto-detect which tiles it overlaps and flags them as impassable at run-time. The plugin has utility functions for that (world position to grid position conversion, for both square and hex grids).