Hello again. This may seem like a simple question but I cannot figure this out.
Is there a way to check which object is at a certain index in the Grid Manager? What I am trying to do is to have a custom pathfinding that will treat certain kinds of tiles as impassable for units using that pathfinding (Otherwise it is a normal no-diagonal square pathfinding).
Glad it worked! You have to re-run pathfinding if you want to change the pathfinding type of a unit mid-game that has already calculated pathfinding using a different method. So what I would do is to simply rerun the Pathfinding function the moment a unit lands, using its new pathfinding type.
There are a few ways of checking whether an object is at a certain grid index, though which one is most suited depends on what you are doing. The simplest to implement is to get all objects of the class you are interested, loop through each and inputting their locations into the VectorToIndex function in BP_GridManager, checking the outputted index against the index you are interested in. This works fine if there are not too many of this particular object in a map and you do not intend to do so multiple times in the same tick. Since you want to check this for every step during pathfinding this solution is way too slow. In this case you can do what Iāve done with the Pawn Array. Make a new array for your objects, resize it to be the size of the grid, loop through all your objects and use the VectorToIndex function to SetArrayElements at the correct indexes to references to your objects. Then you design custom pathfinding that checks if this new custom array is empty at any checked index (in the same way I do with the Pawn Array). As a rule when creating a custom pathfinding function the ordering of the branches should be set up from most to least likely branch to fail out, so put this new branch near the end (same as with my branch checking for units).
Hi I tried this and got some compile errors, not too sure why its not working considering I did what you said to do. The errors are below and heres a screenshot of what Iāve done, if you need any more information then let me know.
Warning Canāt connect pins Unit and Self : Unit Parent Reference is not compatible with Self Reference.
Warning Canāt connect pins Self and Unit : Self Reference is not compatible with Unit Parent Reference.
Warning Canāt connect pins Target and Victim : Self Reference is not compatible with Unit Parent Reference.
Warning Canāt connect pins Victim and Target : Unit Parent Reference is not compatible with Self Reference.
Warning Canāt connect pins Self and Item : Self Reference is not compatible with Unit Parent Reference (by ref).
Warning Canāt connect pins Item and Self : Unit Parent Reference (by ref) is not compatible with Self Reference.
Warning Canāt connect pins Item and Self : Unit Parent Reference (by ref) is not compatible with Self Reference.
Warning Canāt connect pins Self and Item : Self Reference is not compatible with Unit Parent Reference (by ref).
It seems like you duplicated Unit instead of creating a child blueprint of it. Because of this all of the nodes that assume the unit is of the Unit class are not working. Right click on the Unit blueprint and create a child actor. Then modify this actor how you want.
Your suggestion with a grid-sized array worked for me. And since the layoutit doesnāt change mid-game, it also made sense to set it up during set-up. I need to make the blueprint looks nicer now but it works just fine.
How have people using this kit implemented a way to store many pawns? I assume a struct containing all the pawn information needed and a data table, but as Iāve never really worked with data tables Iām not really sure if this is the best solution. Iām curious as to how anyone has approached this and the strengths and weaknesses of the approach. I myself am aiming to have many pawn characters of which the player can choose to use in each map. My pawns will be quite unique from each other, having their own specific stats and skills.
Iām doing exactly that. I simply have them all present in the level with a flag marking them as spawner entities which are then taken at startup and stuck into a list provided they meet specific criteria (ie: belong to the player) which can then be selected from by the player to decide who to use in that level. Iām not sure whether this is the best way of doing this, since I will need persistence for their stats later on between levels, and I havenāt gotten to the point where I have a save feature, but thatās how Iām handling this at the stage of development Iām at.
Ok, great! If you later find that you need to make modifications during gameplay this can be done quite easily. Take a look at my Spawn Unit and Spawn Tile functions in the grid manager in that case.
I havenāt tried anything like this out yet, but I have given it some thought and I agree that data tables are probably your best bet; at least if you are storing a lot of different units.
Hiya, yes this fixed the compile errors, I now somply have to set it all up the way I want it to play, thanks a bunch!
Also is there a changelog of and a way to check the version of ATBTT that I am using in my project??
Great! Check the second post of this thread for a changelog. The version can be found in the project settings. Or you can look at the Version variable in BP_GridManager.
Hey there, I love the tootlkit. Is there a possiblity in the Sci Fi Gamemode to instanly wake the units instead of when they spot me?
Ty
You mean to make it behave like the regular toolkit in this regard? That is as easy as deleting the SortPawnsInInitiativeOrder custom event in the event graph of ATBTT_GameMode_SciFi, which makes it default back to the base game mode for creating the initiative array.
New tutorial is up! In this video I go through some of the new features in the newest update. For the most part the skill system included in the Jungle Raid example map. Enjoy!
hi guys
thank you for the great work, i bought this pack and honestly i have a little problemā¦having a map with hexagonal grid, when i try to put a walk on grid, it doesnāt attach on it.
what could be wrong?
Hello Fabry,
Iām not sure exactly what you mean. When you say walk do you mean a pawn/unit? And by not attaching do you mean it does not automatically snap to the grid? Are you using a fresh version of ATBTT without any modifications? I donāt see any reason why this should happen. Is it the latest version of ATBTT and Unreal Engine? If so, can you tell me the steps I need to reproduce it?
I have an open question to anyone reading this thread about units taking up multiple tiles.
Iām working on adding this feature for the next update and Iāve found a solution Iām pretty happy with. However it only works with units that take up an equal number of tiles in the X and Y axes (22, 33 etc.) and not units that cover rectangular areas (23, 42 etc.). I can try to find a way to work this in, but this would take time, make pathfinding quite a bit slower to be able to account for rotation and would require some way for the player to input the desired end rotation when selecting a target tile. In addition I might have to rework unit rotation during movement to avoid units from clipping through terrain. Iām leaning towards not adding this, but if there are several developers in need of this I might reconsider. If so I want to know of other grid-based TBS computer games that use units occupying an uneven number of tiles so I can figure out how they solve some of the problems Iām facing. If anyone knows of a game that solves this in a good way, please let me know!
Hi . Personally Iād be happy with 22 or similar and can imagine the difficulties with calculating the rotation of units that arenāt equally sized in X and Y. From memory I think XCom Apocalypse had multi-tile units, but I canāt recall whether they were all 22s. The earlier versions of XCom also stored the direction of the unit and there was an AP cost for changing which way you faced (not something I necessarily miss!), so that might be helpful to look at?
Have you found a way for this to work with hex grids, or is this limited to square grids only?
EDIT: Actually Iāve just checked and the Multiworm did indeed have a 2*1 tile coverage. I seem to remember some minor bugs / interesting features with how it moved though - at times it would appear that the worm took up 4 tiles when it was changing direction through a diagonal.
Thanks, Kev. I think 21 would be a lot easier than say 23, as you could simply use regular pathfinding and have half the body trail behind on the previous tile. This would cause issues with diagonal movement on square grids, though, which is why I assume they take up 2*2 tiles when moving diagonally. I would need to set up some hybrid system, in that case, but I think that is something I could add on top of what Iāve already got at some later point.
I just recalled that Heroes of might and magic II and III had units taking up 21 tiles, but this is pretty simple since they always face left/right and never rotate. Iām having trouble finding a TBS computer game with multi-tile units that take up an unequal number of tiles where both dimensions are higher than one tile. It seems like Card Hunter uses such large units in older screenshots of the game (might just be mock-ups), but Iām not able to find a gameplay video showing it in action. In all videos I can find, large units take up 22 tiles.
Descent and some editions of D&D are board games/pnp rpgās that use asymmetrically large units, but they can leverage the processing power of the human brain to figure things out from a simple set of rules.
Yeah I must admit I couldnāt think of many tile based games that do this. Those with large units that I can recall frequently make the actual tiles larger so a normal sized unit has quite a lot of space around it whilst a larger until fills the tile. Youāve said many times in this thread that the best way to implement multi-tile units will depend on game mechanics and be different from project to project - I think youāre right.
If I was utilising large units I think Iād look for some way to have large tiles and then think about allowing more than one smaller unit to occupy a single tile. That seems to me a potentially easier way to go about this.
Iām actually come pretty far in implementing multi-tile units already, so there will be a solution to this implemented in the next update. It will not be ideal for all games, but I think it should do the trick for many. However it only really works with units taking up equal amounts of tiles in both axes (is there a shorthand for saying this. Really cumbersome to type 
). Thatās why Iāve asked here in the thread. If games using units with irregular sizes are very uncommon I figure there is good reason for this, and I will make it a low priority.
