Don’t see how my code could affect single digit touch precision. Might be the size of the finger, as you suggest.
Great, thanks. I’ll take a look when you send it over.
Checked it out. You need to do the same change to the event graph of the ladder as I suggested you do to the construction script:
https://i.imgur.com/QlaA7kn.png
Things I’m hoping to work out:
Perhaps you can play around with collision boxes here? You could maybe have two kinds of collision boxes for buildings. One that covers the entire building and blocks CoverTrace and one that blocks everything except the corners that blocks RangeTrace. Think something like that should work for your use case?
Making win conditions easier to modify is on my to-do list. I think setting the bGameOver in BP_TurnManger to true and ending the active unit’s turn should get you most of the way, though. You could consider using the GridObjects map in BP_GridManager for your exit points. Make an exit point blueprint (Based on BP_GridActor) that adds itself to the grid through the AddObjectToGrid function. Then you could bind the OnUnitEnterTileSimulate event dispatcher in BP_GridManager to calling the InteractWithObjects function. This will now call that function whenever a unit enters any tile. This will call the Interact interface function on any object in the GridObjects map on that tile. For your exit point blueprint you would add BPI_Interact and define the Interact function as setting GameOver to true and ending the active units’ turn. I think something like that should work. I should really do a tutorial on the object system, by the way. Pretty powerful, but I haven’t really covered it. It is used in the 2D map for items and activating torches.
You could implement it with the status effect system, but if you’re not using a lot of status effects it is probably easier just to add a bDisabled boolean to your units. You can check this when the unit is activated to prevent certain abilities from being selectable and setting CurrentMove to a low number when it activates.
Check out the fog of war stuff in the 2D example. That is pretty similar to this. Though if you do not need to actually hide tiles, but just units it can be done simpler. You could basically run line traces to all enemy units at the end of a unit’s movement (or maybe for each animated movement step) and hide/unhide the actors on the client.
Hmm yeah some of the movement stuff in the abilities is coded a bit awkwardly at the moment. The way things are currently set up, move range is by default equal to current action points * move range - ability point cost of the ability. This seems to work fine for move range (where you would put the cost to 0, as you rather use the movement cost functions). If you have set up to have 4AP and a move of 2 and set move cost to be defined by the pathfinding cost, if you move 2 that will subtract 2 action points, cutting down your following move range by 4 (2 AP cost * 2 move per AP). You had the right idea to divide the cost to get your desired result. Not sure if what you’re seeing in the end is really a bug, though. You have split things up so that moving 1 or 2 tiles costs 1 AP, so if you have AP of 8 you can move 8 tiles if you move in even increments and less if you move in odd increments. Why don’t you instead use a move of 1 and 8 AP?
Thanks for the awesome toolkit!
[/QUOTE]
One way is to set PathfindingType of the unit no NoDiagonalMovement. But perhaps you want to enable diagonal movement, but have it cost 2 AP? In that case you have to modify the default edge cost generation. Here is what you need to add:
https://i.imgur.com/SB5KAOp.png
This is for a map with no heightmap. If you’re using heightmap you need to modify either AddTileEdgesOneLevelHeightmap or AddTileEdgesMultilevelHeightmap the same way.
It is now handled by the specific abilities instead of being one big global toggle. Check out the 2D game example and BP_Ability_2D for how to set it up (specifically the ClientDisplayPath function)