[SUPPORT] Advanced Turn Based Tile Toolkit

[Monokkel]

ok, sorry for the long abscence. The last week has been a bit crazy, but things are better now. I'll answer your questions in the order based on how difficult they are to answer, so I'll do orlovpavel, then kup and then 猫狗乱舞.

Hello! I ask for help! Sorry in advance for my english. The path of the character's movement is not shown for me, from this error (as it seems to me). Also, the characters do not move along the designated path, but somehow randomly. I recorded a video and showed errors.
https://drive.google.com/file/d/1HZm...ew?usp=sharing

from the names of the folders and blueprints I see that you are using a really old version of the toolkit (several years old). If you open such an old version of ATBTT in the most recent version of UE4 you are bound to get issues. I would recommend creating a fresh project with the latest version of the toolkit.

Create a new ATBTT project from the Vauld in the Epic Games launcher and choose 4.25 as the engine version and that should resolve your issues.

[kup guitarplayer]

ok, sorry for the long abscence. The last week has been a bit crazy, but things are better now.

It's alright, no worries, glad you're back .

By the way, yesterday I've found an issue in my code with range detection, so now the full code looks like this:



However, I'm still in stagnation in finding way to exclude backwards tiles (marking tiles as "unwalkable" or whatever it can be called).

UPDATE:

Finally, I did it (I very hope so)! First of all, I used a "MakeTileImpassable" after separating "unwalkable" tiles from the "PathsMap":



Then, I added a "MakeTilePassable" function and clear the "PathsTempIndecies" array BEFORE switching from actor to actor:



So, now all works fine... I guess... But, I'll be appreciate you check my code.

[Monokkel]

...

Hey, glad you figured out something that worked for you. It can be done a lot cleaner and more efficient, though, and I think you will run into some issues once you introduce walls etc, since MakeTilePassable will not take into account surrounding walls etc. when it adds new edges. Removing and adding back all those edges each time you run pathfinding is excessive, and I would recommend just modifying the pathfinding directly. I am going to suggest a specific solution, but I need to clarify one thing with you first. What should happen in this sort of situation:

Would you want it to work like this (how it would work with your current setup, based on the rotation of the unit):


Or something more like this (based on which tiles are behind if we say the start of the game board is on the bottom left):

[kup guitarplayer]

It can be done a lot cleaner and more efficient

It's a pity, but this words are not giving me enthusiasm . However, it's your asset, you know best.

I think you will run into some issues

Indeed. But, I have, at least, one idea how to fix it in my project (the situation you've described, I think, simply can't happen because of the project's specific, but I have one bug, yes).

I am going to suggest a specific solution, but I need to clarify one thing with you first.

I'll let you know tomorrow, how it will be look alike, alright?

PS: Sorry, but now I have 1:30 after midnight, and I'm dying for sleep.

[Monokkel]

It's a pity, but this words are not giving me enthusiasm . However, it's your asset, you know best.

Sorry, it was not my intention to be disparaging in my comment. You've put a lot of great work into this, and you are trying to modify some of the most complex parts of the toolkit and ones that I have not done a great job making tutorials for. The fact that you have something that is more or less functional is impressive, and I'm sure it has helped you understand the toolkit a lot better. But like you said, it is my asset and I have worked on it for many years, so I tend to have some pretty strong intuitions about the best ways to modify things.

I'll let you know tomorrow, how it will be look alike, alright?

PS: Sorry, but now I have 1:30 after midnight, and I'm dying for sleep.

Still early in the afternoon here Let me know when you can explain things a bit more (my question with the two pictures) and I will try to give an explanation where I both give you a suggestion and also try to explain the specific reasons why something might or might not be a good idea.

[猫狗乱舞]

……

Thank you very much, I also think this involves big unit, and AI, it is very complicated, my head exploded

[Monokkel]

Thank you very much, I also think this involves big unit, and AI, it is very complicated, my head exploded

You are right to be overwhelmed. This is some of the most complicated stuff you can do with the toolkit. AI is one of the most complex thing to work with in any turn based strategy game and having to deal with units occupying multiple tiles is a complexity multiplier that makes it more difficult to add almost any feature. That is why I generally recommend people not to use big units unless their game depends on it. There is a reason XCOM 2 chose to drop the multi-tile units they used in XCOM 1. Too much hassle.

But I am up for the challenge. I added the big unit functionality to the toolkit, so I'll have to live with the consequences. I will have to do this in steps, though, since this is no small task. First we have to add a knockback ability, then we have to make it work with the AI and then we need to make it work for big units. So I'll start with the knockback ability. You can try to reproduce what I make and see if it behaves how you want it to. If so I can proceed to the next step.

Ok, so let us add the knockback ability. First lets implement the game-logic side of knockback. In BP_GridManager I have created a new function called FindKnockbackIndex. It takes a target index (where the target of our knockback efffect will be standing), a source index (where the knockback is coming from) and a distance (how far do we want to knock it back. This function finds the resulting GridIndex we want to knock back the unit too and returns if it is valid (if the tile does not exist or is already occupied we return false):



Ok, next we want an action for displaying the knockback effect. I've decided to add the action to BP_Unit_Anim. Here is how it looks:


The timeline is as follows:


Then I create another function that handles calling the Knockback action and moving the unit on the grid:



Next I create a knockback ability. What I have done is to duplicate BP_Ability_Move and create a new ability called BP_Ability_Knockback. You will get two compilation errors here where you need to delete and add back the event dispatcher calls for it to compile.

Then in the CheckIfValidTarget function (checked when a tile is clicked), I return valid if the tile is empty OR if it contains a unit that will be knocked back to a valid tile after we move onto the unit:




I also decouple the part of ServerHover that prevents a path from being displayed if there is a unit on it:



Finally, in ExecuteAbility I set up code for calling movement and knockback as appropriate:



I add a couple of units to the map, set their default ability to the knockback ability, and there we are. Pretty basic, but a starting point:



See if you can reproduce it on your end and if it works like you want it to. If so we can move on to the next step, where it gets more complicated.

[猫狗乱舞]

……

Thank you. It’s great to watch GIFs, and it can correctly identify the direction of the attack.
This is also the part I am studying recently. I will look at the blueprint again, because it’s late at night and I have to go home.

My idea is a turn-based Soullike game, so there will be only one enemy of the big unit, so finding enemies based on the big unit is even more important


If there is only one big unit enemy, would it be simpler





I found that the function "find big indexes from indexes" is very useful, through which I achieved the "fear effect", but there may be conflicts in the "search and add adjacent tiles big" (post two days ago), so I don't Determine whether there are other association conflicts, and not sure whether it can take effect in AI, so come for help

[猫狗乱舞]

This is a parabolic knockback, which is also a great way to show (I can even make a throwing ability)

but can you tell me the way to Another type, which is closer to forced movement,



It seems that I should "BindOnUnitEnterTileSimulate" check for collisions when moving? (I want to add an effect status to them when they collide)

unitA is the unit of being repelled. This is not his round.

If i want him to move ，will be an error in "run pathfinding"


Thank you again, Originally, I didn’t want to trouble you anymore, I wanted to modify it myself, but I found that the two types are quite different.


this type of knockback can also be applied to the movement of the monster as a side effect (the monster knocks back all units on the path during the movement, The same is to check the unit on the moving path)

showing its rampage

[Monokkel]

This is a parabolic knockback, which is also a great way to show (I can even make a throwing ability)

but can you tell me the way to Another type, which is closer to forced movement,



It seems that I should "BindOnUnitEnterTileSimulate" check for collisions when moving? (I want to add an effect status to them when they collide)

unitA is the unit of being repelled. This is not his round.

If i want him to move ，will be an error in "run pathfinding"


Thank you again, Originally, I didn’t want to trouble you anymore, I wanted to modify it myself, but I found that the two types are quite different.


this type of knockback can also be applied to the movement of the monster as a side effect (the monster knocks back all units on the path during the movement, The same is to check the unit on the moving path)

showing its rampage

haha, just when I thought it could get more complicated you also want to have actions within actions Hmm, in this case I would consider a slightly hacky soluton to avoid it becoming too complex. I would not queue the knockback actions (but do all the stuff affecting gameplay logic). Then I would add some overlap collison to the big monster unit and the smaller units (enabling collision on all units that will be knocked back before the movement action is animated) and animate the knockback animations as the collision volume of the big monster overlap the smaller units. You could store the knockback location within each unit, probably.

I'm not sure I understand your figure. "type 1" is the one I made, right? I don't understand the other one, thoug. Is Unit A moving onto unit B and then bounces off?

[猫狗乱舞]

……

Haha, yeah, I did a lot of actions in the action, and I try to make the sequence of actions in advance
I feel that the queue type "immediately" will bring some problems
But it's still working well


Yes, you did is TYPE 1. Your understanding is correct, that unitA collides and bounce with unitB during the process of being forced to move to position 8 due to being knocked back (assuming knock back distance 7，knockback index 8)

[Halrawk]

Found a bit of a oversight in GetTileInDirection in BP_GridManager_Hex
It doesn't add the grid index to the retun node, meaning the return is always just a base edge integer. Fixed easy enough by just adding a int + int node right before the return node, but it did mess me up for some time

If anyone else runs into the same, images below show fix.

[Monokkel]

Haha, yeah, I did a lot of actions in the action, and I try to make the sequence of actions in advance
I feel that the queue type "immediately" will bring some problems
But it's still working well


Yes, you did is TYPE 1. Your understanding is correct, that unitA collides and bounce with unitB during the process of being forced to move to position 8 due to being knocked back (assuming knock back distance 7，knockback index 8)

sorry, but I'm still not sure I understand how this is different from what I did. are there two different types of knockback in your figure or just one? Perhaps it is simplest if you show two pictures from the toolkit. One of where the units stand before collision, one of where the player clicks and one which shows where the units should end up afterwards.

Found a bit of a oversight in GetTileInDirection in BP_GridManager_Hex
It doesn't add the grid index to the retun node, meaning the return is always just a base edge integer. Fixed easy enough by just adding a int + int node right before the return node, but it did mess me up for some time

If anyone else runs into the same, images below show fix.

****, sorry about that. I'll make sure to fix it in the next update. That function is actually never used anywhere in the base toolkit, so this omission escaped my notice. Thanks for letting me know, and sorry for the headache!

[猫狗乱舞]

hi,Sorry, I put two types of effects on one picture, which caused you trouble


The current one is parabolic



Another method is to check whether it encounters obstacles and collisions during the rejection process.


unitA should be knocked back to 8 normally, but collided with unitB（barrier） at 4 and stopped at 3.

[Halrawk]

****, sorry about that. I'll make sure to fix it in the next update. That function is actually never used anywhere in the base toolkit, so this omission escaped my notice. Thanks for letting me know, and sorry for the headache!

No worries at all! I just treat it as a way to learn the toolkit better