[SUPPORT] Advanced Turn Based Tile Toolkit

Hey leo. With the new version, both tiles and units share a common blueprint parent called BP_GridActor, which is used for calculating the actor’s GridIndex, snapping to the grid etc. If you simply reparent BP_Unit to Pawn instead of BP_GridActor, BP_Unit will no longer have access to the GridIndex variable, which is used in several blueprints. You can add the functionality from BP_GridActor manually back into BP_Unit, of course, but then you need to go through all blueprints and change the old GridIndex reference with the new one. The compiler will thankfully help you with this by marking all such occurences with an error.

Another possibility is to reparent BP_GridActor to pawn. I have tried this and it seems to work fine. This will add a lot of unneeded functionality to things like BP_GA_Tile, but I don’t think it should have any real impact on performance.

This is if you just need the pawn functionality, though. In the earliest versions of the toolkit, BP_Unit was based on pawn. In later updates, up until a couple of updates ago (when I changed the parent to Actor), it was rather a child of Character. If this is what you want then it becomes a bit more complicated. Character comes with a capsule collision component that cannot be removed and a skeletal mesh component that cannot be unattached from this capsule component. If you want to use the skeletal mesh included in Character you cannot use my setup in BP_GridActor where I use a custom scene component as an “anchor” for the grid snapping functionality. Instead you have to use the capsule component, which annoyingly has its origin in the center of the capsule and not the ground. Because of this you will need to add offsets to account for this in any blueprint that changes the unit’s position on the grid.

It was because of all of these extra annoyances and clunky workarounds that had to be coded in to more easily allow for using UE4’s character movement component, which I consider to be a bit of a corner case, that I decided to use Actor as a base instead. If this is what you want to do you have two options: Either code it in like it was done in earlier versions (you can download an earlier version and search the blueprints for CapsuleComponent to find all such places) or you can cheat. By cheating here I mean using one character for all your Character movement component stuff and when you want to change to ATBTT-style turn based combat, hide the characters and replace them with BP_Units using identical skeletal meshes.

Without knowing more about exactly what you want to achieve, these are my best suggestions.

hi knut

Well it will be a little bit long and so I apologize in advance :slight_smile:
ok now thanks for your answer i understand more about my problem.

what i need is character class - as you wrote i need the skeletal mesh component, movement component and the option to be posses by the controller (although this one is not that important to me).
I would be very happy to know what you think will be the best solution and I understand that in order to do this you need to understand a little better what I want to achieve, so it goes like this:

After long trials I came to the conclusion that the best way for my game mechanics is to combine two worlds: one is like in your project a turn based game based on a Grid. Only when the turn of a player’s begin(not an ai) and the first action is movement its done in real time by movement in a third-person view with full control over the player to the moment phase and not by path finding . Then the shooting or other abilities are back more or less same as done by the toolkit. this feature of real time full control by the player for movement phase is very critical in my game which in turn have a lot of affects on other things.
At a certain point I thought that it would be better not to use the toolkit at all because I do not have much need for it if I base it on the engine’s navigation system. But after many trials I came to the conclusion that the best way is to use both worlds because the toolkit gave me much more control on every aspects of the game and the combination of the two gives more accuracy and solve a lot of problems the engine navigation have.

After really many trials and long stretches I have finally reached the conclusion that i will diffidently have to use the toolkit and most of the feature in it.
In order to implement this (the movement stage of the player), the best way I thought was by using character Class, since the flow of elements already built up in (components) in this class. I’ve already built a unit with all the feature using a character Class that gives me a good answer to all the scenarios I need. but i am open to change it if i need to.
I hope I have given more light on my project and what I need and I will be happy to hear from you how to implement all of the above.

another question i have is with the Implementation of the move by third person view in real time control by the player, is with the action manger which a little bit confusing.


Ok, thanks for the explanation. In that case, here is my suggestion: Keep BP_Unit as is and have a separate character blueprint for the player movement. Have a reference variable to the BP_Unit in your character and to your character in BP_Unit. BP_Unit should here have no mesh and so be invisible. You could attach it to the character blueprint, move it manually once the character movement is done or even move it per tick. For animating attacks, since you want to do this ATBTT-style you would do something similar to what I’m doing in BP_Unit_Anim, only that you hold a reference to the anim BP of your character blueprint instead of one contained in the unit itself.

Maybe a bit hacky, but I think this is a way to achieve the result you want with the least amount of headache.

ok after a lot of work manage to get it going. hope i wont have to go through all of that on every update :slight_smile:


How about that! Sorry, I read your message pre-edit earlier today, but had to get done with work before I could get to it, since I felt I needed to give an in-depth answer. I had time now, but if you figured it all out on your own all the better :slight_smile:

hi knut

i manage to do it but i am struggling with the reference to the grid index (its now not in my unit, only on the grid actor) and all the other blueprints need this value from the unit.
what is the best way to do it?
and its ok i understand you are busy so no problem at all


I take it you’ve set it up so that you are using a custom made unit class that does not inherit from GridActor? I’m going to assume this. If so, you can make a new GridIndex variable for your custom unit blueprint. Take a look at the construction script of BP_GridActor to see how it is calculated. Then, for every place in the toolkit where GridIndex is normally gotten from BP_Unit you need to change it to instead get it from your custom unit class.

i made the bp_unit re parent to character so noting from the gridactor. i did what you said and made GridIndex variable in my new bp_unit, but it just seem like i doplicate almost everything from the gridactor to my bp_unit. even the consturction script. am i out of it??

Yep, that is basically how it worked a few updates ago and one of the reasons I decided to refactor it. You need to more or less copy over everything from BP_GridActor if you want it to work this way.

yep got it, i feel so stupid:) its not so complicated but somehow i struggle for hours. but its good i learned few things.
thank a lot


No need to feel stupid. I’ve also struggled for ages to fix things up when I’ve changed something in one of the blueprints and forgot to change it in the other, or use the wrong GridIndex or whatever. Good riddance too it, and I’m happy I refactored it. It is unfortunate that it makes things a bit trickier for these kinds of corner cases, of course. All of this would not be necessary if Epic included things like the movement component etc. as components that are fully available to all blueprints, but oh well. A man can dream.

hi knut

ok everything is working fine now with no error, but my character start to fall into the ground the moment he start moving. any idea why?

I have problem with animation in diffrent skeleton. I’ve setup new BP for animations, and Unit (I copied BP_Unit_Anim and change mesh, Animate Movement, Animate Ability and cast) and still my movement is not working. I don’t know what else I must change.
Second problem that I have is when my new unit attacks enemy game stops in some kind of loop and nothing is happening.

Could you be a bit more specific in how it is not working? Is the unit stuck in T-pose? Does it have an idle animation, but does not change to the move animation when moving? Something else? For the game stopping after attacking, I’m guessing EndAction is never called. Take a look at the included ABP. You’ll see that the animations include notifies that call back to the event graph of the ABP to end the action. If you’re not doing this or something similar the game will have no way of knowing the animation has ended after attacking, and so the game will not proceed.

Idle animation is working and it’s not changing to move animation, but in BP when simulating speed float has value and it’s passing to Animate Movement. I will check EndAction.

Hello, I found this events on animations, thanks for showing this! Now all is working good!

Great to hear! Let me know if you run into any other issues.

Hi Monokkel ! How makes unit do not shoot through each other ?

hi knut

I need your advice…
i want to activate the ability system only when i posses my player and its in the third person mode. i dont want the ability system will be active when i am at the top view. so basically i need a way to toggle the ability system on and off when i need it.
Do you have any advice for me how to implement this?
and another question, way when i put the default ability to idle i cant swap between unit anymore??


Hey, @Lexx ! Visibility is determined by whether or not the trace channel RangeTrace is blocked. You can make units block line of sight by adding a collision box to the unit that is set up to block RangeTrace in its collision settings. Other than this you need to make sure that the unit does not block its own line of sight, so on unit activation set collision to false for this collision box, and then set collision to true again on unit deactivation.