I got my modified version of the 4.9 toolkit to work with 4.10 without any issues (Other than gameplay bugs I created myself and that it my fault).
But I do see that the 4.10 version is available in my vault
@ have you seen this?
Looked like an interesting video I watched about the first 15 minutes but have not had time to look at the rest. However my turn based game has to go on hold for a bit. Things have change around my house and I have to look at a few different ideas for projects rather than the sand box I am playing in right now. Hopefully I can get back to my turn based game in Jan but we will see how it goes.
@AxelRantile: The 4.10 version is basically identical to the 4.9 version. The only things I did was to decrease the height of the meshes of the tiles with added movement cost slightly, as they were clipping through the tiles in range. I also rebuilt the terrain in the heightmap example as it had some collision issues. None of these fixes should have an effect on your project, so there is no need to upgrade.
@Anzak: Yeah, Iāve seen that one. That was made the same month that I released the toolkit. Ian Shadden made A* pathfinding in blueprints similar to what I did before I moved to Dijkstraās algorithm (though certainly more efficient than my early attempts). It is a slightly different way of doing things that uses lots of invisible actors instead of large arrays. The procedural generation stuff is also very cool. Iāve looked a bit at the project, but didnāt find much I could use to improve my own work as our approaches arenāt that similar. I take a new look every now and then, though.
Sad to hear you will have to take a break from working on the project. Youāve made some pretty awesome additions that inspire me to take the toolkit in different directions myself. Hope to see you back in January 
probably doing this wrong but I hooked up an int var in one of the enemy pawns bp. put a print in the end to see the results as well. I put 3 of the pawns in a lvl and was hoping that each death would add to the int value. each death just results in the same value with no addition. if this is horribly wrong I apologize for being an artist trying scripting :D. i was just hoping to track the deaths of enemies to do a end lvl/load setup.
Hi Jopel. If you have created a new variable in one of the pawns then each pawn has its own variable and you are adding to each of these separately. You will want to keep your counter in a single blueprint. Which one you choose is really up to you. Using the game state would probably be most appropriate for this thing, but I havenāt included one with the toolkit, and there is little point in adding one just for this. I would recommend keeping your variable in ATBTT_GameMode. Here is an example of how you could set it up in Unit_Parent (after creating a counter variable in ATBTT_GameMode):
awesome. that worked like a charm. Thanks!!! Not sure if its a backwards way of doing it but i was going to use the counter to help determine if a player will move to the ālevel completeā GUI. So even if there are 10 enemies in a lvl, I could just say kill 5 out of 10 to win or whatnot. Wanted it open enough to change up the conditions for different lvls. I was also going to use this but on the player too so if all the players die it initiates a restart or quit screen.
again, awesome. thx.
With permission Iām posting a PM conversation between me and user Bankworthy about implementing a cover system, since it might be useful for others as well:
There are a few different ways to do cover. Below is something Iāve pasted from my forum thread. Which one of these solutions do you think would fit your game the best? If you describe what you want in detail in terms of game mechanics it would help me help you 
The first is a dynamic system using tracing similar to what I currently do for regular visibility. In addition to the head-to-head tracing I currently do I would also do a trace from the attackers head to the defenders torso (and/or legs). If all traces return false (have not hit any cover), this would give the highest hit-chance. This is very simple and efficient, and could work on many different types of map, but itās not my favorite approach, as I prefer something a bit more predictable for turn-based and grid-based games.
My current favorite solution is to have a cover-variable on all tile_parent actors, designating the amount of cover the tile gives in different directions. I would then feed this information into a grid-sized array that would store the cover values in their appropriate locations, granting a defense bonus if the unit in cover is attacked from a direction on the other side of the cover (by simply comparing X and Y locations of units). A benefit of this is that itās both very quick (since most stuff can be pre-calculated), and it can be easily used to display XCOM-style āshieldsā or similar for all tiles in move range, by using the indexes in the CanMoveTo Array to check the Cover array.
Ok, so Iāll go by the assumption that you want something exactly like XCOM. Something similar to edge arrays would make sense. You could even use the same struct (be aware that the directions of north, south etc. donāt really make much sense). I think I would make a new child of Tile_Parent called Tile_Cover or something and make any tiles that can have cover a child of this tile.
For the Tile_Cover tile I would add a new struct (the one with north/south etc. The name escapes me) which would hold cover values for different directions (you could use 0, 1 and 2 for none, half and full or even floats for percentage cover). Then at Event Begin Play (probably in BP_Grid_Manager. You could make a child of this if you do not want to tinker with the main blueprint) I would add a new function that adds this data to a cover array.
First make a cover array (of cover structs) and resize it to the size of the grid (Grid Size X * Grid Size Y just like I do with the othe arrays). Then get all actors of class Tile_Cover and run a foreach loop on them. For each of them look at their cover struct.
For each value of the struct check if it is above 0, if it is modify the cover array index corresponding to the adjacent tile in the appropriate direction. For example if the north index in the cover struct of a tile is 1 get the index equal to the index of this cover tile minus GridSizeX (this would get the tile right above it. I think that is north, but check it out). For the index of this tile modify the south integer of the cover struct of the cover array at its index to 1 (since this is the direction pointing towards the cover. Note that modifying structs within arrays like this is a bit finnicky. Iāll help you out if you find it difficult.
By the way, it is probably unnecessary to use the corners for cover (north east, south west etc.).
Now we have a complete cover array and we just need to take it into account during gameplay. To do this I would do a quick check whenever a unit targets another unit. Check the index of the cover array corresponding to the index of the target unit. We need to check the appropriate direction(s) for cover. A simple way to do this is to simply check the locations of the attacker and the target. If the X location of the attacker is higher than that of the target we know that it is east of the target (again not entirely sure if this is what represents āeastā, but youāll figure it out through trial and error). If so we check the value of the āeastā integer of the struct. If it is 1 or 2 we subtract damage or add a miss change in the Attack Target event of Unit_Parent.
Thatās the gist of it. Does this sound doable and similar to what you had in mind
Makes sense to me when looking through it quickly. You should test it by using my Get Hit Tile Index and Location function (in BP_Grid_Manager) and printing the values from cover_array of the index you hit.
Hmm, still looks ok. What is the default value of your cover tile class reference? It should not be empty.
Hmm, depending on where that blueprint is that might be it. Try using my Get Hit Tile Location and Index directly in the event graph of BP_GridManager.
Ok, Iāll give you my own take. This works as far as the arrays are concerned. So I have made a child actor of Tile_Parent called Tile_Cover and added an edge struct just like I asked you. Here is how I get all the tile_cover actors to put their cover values into the cover array appropriately (at the end of the event graph of BP_Grid_manager):
And here is how I print the values for debugging (also in BP_Grid_Manager):
This works for me. Hope it helps!
Ah yes, that is probably the main reason. When you get the array index you get 0 for the first item, 1 for the second and so on. This does of course not correspond to the location of each individual tile. The index variable I get from each tile is genereated in the tilesā construction scripts which interact with the grid managerās vector to index macro to convert the tilesā locations into array indexes. Good luck in your project going forward! Do you mind if I post part of our conversation in my dedicated forum thread? That way other users can make use of it in the future. For future request I would prefer if you post them there instead of a PM, by the way. That way I can help more people at once.
Hi ,
Will start with the fact that this is a staggeringly awesome toolkit. And your support of the product is top notch.
Iāve been lurking in the wings for a while now, reading through this thread which is loaded with ideas AND the means to implement them (in most cases) for which i have to thank all the others on this thread for weeding out problems and really testing the limits. Although i still only have a tenuous grasp of the toolkit, being mathematically inept (unless you plan on doing a tutorial with sock-puppets).
Although my micro-team made a modest start on our project, i understand an update is looming and i just wanted to ask:
Although the update is primarily for mobile optimization, is it safe to assume there is a decent increase for performance across the board? And if so, is it wiser at this point, taking into account that the update is likely to have some significant changes to core blueprints, to focus on other areas of development until its release? Or would you recommend continuing with the current build if mobile is not my intended platform?
Hi Spartacas,
Iām glad you like it! Youāre right that the update is pretty close, though Iām unable to give an exact date. The update has much more than just mobile support. Thatās the main thing I planned for initially, but I got a bit carried away and ended up experimenting with nearly every aspect of the toolkit. Only some of my experimentation paid off, but there are still several minor and major changes. For the most part, though, it should be fairly easy to port any changes you make over.
There are some parts of the toolkit that have been heavily modified, though, so if you want to prioritize so that you spend the least amount of time reintegrating your changes these are the areas I would avoid tinkering with: Artificial Intelligence (has been completely revamped), pathfinding (has been changed to be a one-directional graph and made cleaner and slightly more efficient), camera controls (though the keyboard controls are mostly the same). Hope that helps you plan forward!
Hey there, planning out some of my AI at the moment and trying to decide if i should wait for the update or not.
Just how revamped is it in the new update?
Thanks
AI is one of the things with the greatest amount of changes, but depending on what you are doing it might not interfere with your plans.
The old AI works basically like this:
Check tiles in range for player units -> if found attack unit with lowest health -> if not check tiles in move range for player units -> if found move and attack unit -> if not do pathfinding up to the unitās max search range -> if unit found move in direction of unit -> if not end turn.
The new AI works more like this:
Check every tile that is within attack range of any tile the unit can move to -> if found move to and attack the player unit with the lowest health while either getting as close as possible/staying as far away as possible/moving the least amount (depending on a personality variable) -> if not search pathfinding up to the unitās max search range -> if no player unit found continue pathfinding from the index of each enemy unit found in range -> if player unit found move as close as possible towards the player unit with the fewest enemy units blocking the path.
Here is a screenshot of the new ATBTT_AI_Controller:
Hope this helps you decide whether or not you want to work on AI now or wait for the update.
Thank you that does help!
I think il wait and have a fun time playing around with the new system
I thought Iād give a little update on the update. I feel a bit bad about it taking so long to get done, but know that it is not because I am not working on it. In fact it was pretty much done a couple of weeks ago when I suddenly found a much better way to store and use edges for pathfinding.
I had my mind set at that point not to be tempted to add any new features to this update and just get it done, but I felt I had to make an exception in this case. I had already made changes to the way edges are handled at this point, so any users who wanted to update would need to update this part of the toolkit in any case.
However, since I know I would then be changing this part of the toolkit again in the following update this would mean any users would have to modify their projects twice. Therefore Iām implementing my latest ideas already in the next update.
This will make pathfinding even faster and will be a lot easier to work with. It also looks a lot cleaner and takes a lot less space. To give an example this is one of the new toolkit functions before my newest changes to edge arrays (this you will now never have to see again):
Here is the same function with my new solution for handling edge arrays:
I hope you can agree that this is a worthwhile excuse for delaying the update a bit Iāll try to get it in your hands as soon as I am able.
As an owner of your product, I prefer the much more complicated BP. <grins>
teak
Howdy ,
Iāve got my cover system all in place and working now, Thanks again!
Even got dynamic cover working, in which the player can create/remove their own cover on the fly
My trouble is now getting the AI to use the cover system,
I can get from which direction the cover is effective, by getting which direction the nearest player pawn is
from here I want to get all tiles in move range which have effective cover
Iāve tried Pathfinding, getting the CanMoveToArray and ForEachIndex, checking whether or not the tile has effective cover,
but having no luck with the CanMoveToArray, itās length is always = to the gridsize,
from there I would add tiles with effective cover to a new array, for the AI to choose from
Wondered how you would get certain indexās within a pawnās move range?
@teak421: Youāre joking of course, but just to be clear the second function does the exact same thing as the first one, but is a million times easier to work with
@Bankworthy: I had the same problem when working on AI in the coming update; namely that the CanMoveToArray is the size of the entire grid, meaning that you have to look through the entire array to do things like this (you could do so with a foreach loop checking if an index has a cost higher than 0, but it is inefficient). To get around this I created a new, shorter Can Move To Array that only holds tiles that can actually be moved to.
This array cannot replace the CanMoveToArray as it is often necessary to know the movement cost of a specific tile (again you could use the short version, but would need to look through every index in the array). I make this array by appending the OpenList array to the short Can Move To Array at the end of each search step in the Pathfinding function.
However, in your case you do not need every tile in the array. You only need the tiles the AI can move to that the AIās target can also be attacked from. To get these you can use the FindTilesInRange function from the location of the target with a range equal to the attack range of the AI. You would look at the array outputted by this FindTilesInRange function and check which of the indexes have a cost higher than 0 in the regular CanMoveToArray (meaning they can be moved to). From this subset of indexes you would then look at their cover values to determine the ideal one to move to. I do something similar to this in the coming update, though not with cover.
I just got the toolkit, itās been an absolute pleasure so far. Maybe this has been asked before, but whatās the best way to make a character who can switch between ranged and melee combat?
Welcome honaj Glad you like it! There are several ways and it is not something I have actually discussed that much before. What solution is best depends heavily on what you have in mind. Can you describe what you want to achieve in a bit more detail? Should the damage vary between ranged and melee? Should it depend on a weapon the unit might be holding?
Iām planning to have a basic inventory system, allowing characters to equip different weapons. And yes, I think melee should do more damage since itās riskier.
BTW, Iām having a strange issue where the unit parent is failing to get the grid manager, game mode and so forth. I havenāt touched that part of the blueprint, and I just donāt understand how a simple āget all actors of classā could fail.