Glad it worked 
Ok, so I guess the next step is to have a unit move through the spaces of multiple units and knock them all away during movement. I relaized when I started working on this that I will need some more info from you.
Say I am in this situation. I want to move through all of these units and knock them back along the way. what tiles would each of these units end up on?
https://i.imgur.com/0JU3Buv.png
Very thoughtful hypothesis, even added obstacles
So I think it can be simpler
Use knockdown (a status) replaces knockback on the path, only when the final position occupies another unitās tile, knock it back
When at the border of the map, knock back randomly to the left or rightļ¼Suppose the knockback distance is 5ļ¼
Hi ,
Iām redirecting here the question from Questions section on the EGS page:
My pawn starting āAttackā animation prior to finishing āWalk/Idleā animation. Where can I specify that the next animation should be played after finishing the previous one? Below is an example:
Iām little bit lost in the structure of blueprints and cannot find where I can diagnose queueing delay for performing animations or tick on a check box for playing next animation after finishing previous.
I was following your tutorials of custom skeleton animations by simply replacing animations and didnāt modified action manager(at least tried). Iām pretty sure that Iām asking very noob question
Thanks.
ok, so work obligations the next few days means I donāt have the time to test this out for you until later, but Iāll give you what I was planning to do and you can see if youāre able to get it working:
the final knockdown part is pretty close to done now (not counting big units and AI). You just need to get the appropriate random tile. You could use GetIndexes in range, loop over the indexes and filter out those at the appropriate ranges. Then you could check if those tiles are blocked for knockback (based on the function I provided). If not you would proceed with the knockback. If they are blocked you would continue looping over the indexes in range until you found one that was not blocked.
As for knockdown you probably want to use status effects for knockdown. Check out the mind control status effect for an example that isnāt too different. It has an effect on activation and when the unit ends its turn. You might want to have an effect at the start of the unitās turn for getting up instead of at the end of its turn.
The status effects would be added to units while the big unit is moving. Before unit movement you can bind an event to OnUnitEnterTileSimulate (called on the GridManager from BP_Unit). In this event you would check for any units on this tile and add/activate the knockdown status effect to these units. This would handle the game logic part of the equation.
Next for animation. This is trickier as the toolkit doesnāt play too well with interruped actions (this is one of the things Iāve worked on improving in the coming update), but we can get there. The most āproperā way might be to make use of event dispatchers and OnUnitEnterTileAnimate, but we should be able to achieve the same thing more quickly and easily, if a bit more hacky, using collision. For this you want to add collision capsules to your units. They should overlap each other, but other than that not block or overlap anything. When your big unit is moving you would check for overlap events. If it overlaps a unit you would look for the AbilitySystem component and see if it contains a knockdown status effect. If it does you would play your knockdown animation. You would not need to use an action if you do it this way since it is not queued and happens immediately (though you could use an action set to immediate if you wanted to be able to also call the knockdown animation as a queued action for something else).
Ok, that is the outline of what I want to try. See if you are able to make it work, and if not get back to me and Iāll give it a try once I have the time.
Hey, there could potentially be a few different things causing this. Perhaps you are ending an action too early or not queueing them appropriately. Could you show me your code for how you are calling these animations? Make sure you have seen my action system tutorial if you have not done so already. There I get into how you can get things to play in sequence.
Thanks, thank you for your guidance, I also prefer to do it myself, better than copying homework
But I have some understanding to confirm
āBindOnUnitEnterTileSimulateā
Will this happen?ā The enemy on the path has been knocked down before the character moves.ā
Should I use āBind OnUnit EnterTileAnimateā to be more reasonableļ¼
Due to a small problem, it was not verified,
The result of āfindā is Executor himselfļ¼
Of course, using ācollision capsulesā seems easier, but it feels a bit different from the whole system.
If you suggest me to do this, I will try to use:)
When I was reviewing, I had a doubt, what is the difference between āremove unit from gridā, āadd unit to gridā and āsetActorLocationā in Telepoterās tutorial
report
the ācollision āmeets expectations
I have chosen to ignore
it will repeatedly collide with bp_gridcamara
Even bp_gridcamara Set Generate overlap events to false
But this is a small problem, just affects efficiency. Can be optimized
If you want to use these you need to do both, actually. Simulate for the game logic (adding the status effect etc) and animate for when you animate the knockdown effect. To see an example of this, check out the overwatch status effect in the Experimental folder which uses both simulate and animate. It is pretty close to what you are after.
hmm yeah. did not think of that. the simulate event happens after the moving unit has entered the tile, replacing the previous unit reference on that tile with a reference to itselfā¦ Hmm, that is a bit tricky to fix. I guess you would have to modify SimulateMove for the unit so that AddUnitToGrid is not called until movement is done, so it does not override the references of the units along the path.
Youāre right that it goes against how the system is designed. You might consider waiting until the next update, actually (out in a couple of weeks). I have made it a lot easier to add actions that interrupt other actions.
Add and remove from grid affects the game logic, so the GridUnits map variable. SetActorLocation moves the actual āphysicalā actor, but does not affect game logic at all, which is determined by the arrays.
Ok, glad that it partly works, but I would change this a bit. If you choose to use collisions it should only be used for animating the effects and not for anything that affects gameplay. Anything affecting gameplay should happen instantly and not be a result of the asynchronous action queue. What I meant was that you could add status effects during SimulateMovement, but animate those status effects happening during movement using the collision capsule setup.
Hi, Iāve followed your tutorial on Action System again, but still canāt figure out what is causing instant animation. Here are screenshots of blueprints:
[SPOILER]
BP_Action manager:
[/SPOILER]Now itās the big unit and AI problem. The target selection has been made,
I donāt know how to get the pathfinding right. AI is a black box.
maybe i need a switch to add decal in AI SimulateMovement, will be better for debug
Assuming that uA is the target
if my understanding is correct, uA should be ReachableUnits in ārun pathfindingā(Should be use ārun pathfinding until index foundā as an AI?)
And I hope he can ignore the Unit(uC) and obstacles on the path (the monster will destroy him)
As a big unit, it seems that uA can be attacked in both the blue area and the yellow area.how to control the choice of AI
I am now using āSearch and add adjacent tiles pass through friendā to modify, adding a Monster Type, but there is no big unit modification
Thanks for the screenshots. I canāt really see anything that would be causing this issue. Are you using the included default abilities or have you made any modifications to them? What ability is the unit using?
Finding targets to attack is not really a problem when it comes to big units finding small units as targets (big units as targets is a bit more tricky for AI, though, but luckily you donāt need it in your game). The range of the big unit just needs to be increased to include all tiles around itself, which is done by default in the included abilities.
For your pathfinding you need to create a new pathfinding type based on Big, where tiles are still added to LocalOpenListChildTiles even if there is a unit on the tile. Your small units still need to use the regular Big pathfinding type to prevent them from entering one of the spaces of the big unit.
With this in place, both uA, uB and uC should appear in ReachableUnits, provided they are in move range. You should not have to restrict the pathfinding by using ārun pathfinding until index foundā. All that does is to cancel pathfinding when an index is found. If you know beforehand what your target is going to be then using it might save you a tiny bit of processing time, but it has no other benefits.
I just remembered that you need to be aware of one more thing. Normally when you are using big units you want your small units to have a size of 1 and not a size of 0. What this does is to modify the big tile sizes so that big units are not allowed to move onto adjacent tiles where they would overlap the unit. The big size map is not modified when units end their movement if their size is 0. Since you want your big units to move onto the spaces of small units, small units in your special case should have Size set to 0.
pathfinding type based on Big
Just connect it like this?
The size modification did not work. On the picture, the monster chose 5002 as the moving target, obviously because 5002 and 5004 are the same distance for him.
And with unitA as the target, move to 5002 is not right
I understand that the possible problem is that the pathfinding type is changed in the loop
Since I donāt know the principle well, Iām not sure if this is the problem, and I donāt know if it should be modified.
Hmm, Iāll have to do some testing myself to figure out what might be going on here. Lots of different systems interacting here that I donāt normally use together. Might be a few days before I have the time, but here is something you can try before then: Store GridUnits in a temporary variable, then clear GridUnits. Add back the target unit and the big unit to GridUnits. Then run all the AI code. Since all units but the target are not in GridUnits they will be ignored and treated as empty spaces (this presupposes that the units all have a size of 0 so that the big indexes are not affected by them). After the AI unit has found a path to the target reset GridUnits by setting it to the values in your temporary variable. Then proceed with the ability as normal.
I have a few questions in regards to targeting. recently you helped me with the movement system. I guess ill start my understanding of how it works and how it applies to my goal so far.
for me that is alot of information cause it lets me know what i need to work with. soo my understanding goes something like this
sooo now on my goal
i figured i could do one of two methods to make this work.
obviously i would prefert to do method 1 however if thats not possible i can proceed with method 2. the only issue i would have with method 2 is that i would always have to make the enemy ai go first in order to get locations for players to target. i would also have to preset each unit per map into the outside program in order to insure every enemy was properly target-able.
with all that said, any opinions? did i misunderstand something?
soo in an attempt to add a blueprint function library, i ran in to this error.
@LuxJahi: Hi, the AI faction priority seems like something that could be handled within EvaluateTargets or FindTargetValue in your ability. If you override FindTargetValue you can modify the value of a unit based on its faction. Check out FindTargetValue in BP_Ability_Laser for an example of how to modify the value assigned to a target based on some property (in this case its health and distance from our unit). Iām a bit confused about part of your question, though. Do you want to target a unit based on its name, faction or both? If you get everything working the way you want it how would it look in game?
Iām afraid I donāt know the reason for your error regarding the function library. That is a more general UE4 question than an ATBTT one, though, so you will hopefully be able to get help in the regular UE4 support channels.
Hello, I tracked the value and found that except āpassThroughFriendlyā, this loop will not be triggered, resulting in the output value of StartIndex
Eventually it will be converted to passThroughFriendly, making PathFindingType inoperative
Hey
Hopefully a simple question, How would you get the post process material to work in 3d as it does in the 2d example level?
Hmm, the pathfinding change I suggested seems to work on my end. Here are the steps.
https://thumbs.gfycat.com/CheerfulChillyCardinal-size_restricted.gif
As you can see, the big unit moves into the space of the front one in order to attack the one behind. This is the result you want, right?
Hi 9Task, it is both a really simple or very difficult question depending on what youāre after. If you have a 3D map with no or very slight height differences between tiles it is simple to use the post process approach. You need to do the following:
And there you go:
https://i.imgur.com/30yT3uB.png
Looks nice, doesnāt it! And provided you have a pretty flat map youāre happy.
However, the problem arises as soon as you have height differences that are such that tile markers from higher levels overlap the ones on lower levels, and you get the following depressing result:
https://i.imgur.com/BdKGNZX.png
If you can figure out how to fix this problem I owe you a beer 
But perhaps youāre using flat maps or are fine with designing your levels so that these sorts of overlaps will not occur. There are other ways to create outlines and I have experimented with various approaches, but so far Iām yet to find one that is clean and performant enough that Iāve wanted to include it in the kit.
Hello,Thank you, Thatās it.
i modified āability_moveā before. It seems that the logic used is different from āMoveAttackā.
But using this method, there is a problem
range is 2ļ¼And in the unit config, the range will be forcibly setļ¼
I tested it, the range seems to be the red area centered on the grid index
the range does not seem to be affected by the big unit, so the wrong position will appear
I think the correct melee range (range 1)
So the idea with locking the range for big units works well for units of sizes 3 and 5. A unit of size 3 that wants to attack units adjacent to itself needs to have a range of 2, since a range of 1 will extend only to the tile it is occupying itself (from its center). For units of size 2 and 4 it is a bit more tricky, since the units donāt have a center tile, but are instead offset to the top-left of their center. This means that we will have to trim away tiles to the top and left of tiles in range or we get the following:
https://i.imgur.com/Da9drVS.png
This can be remedied by making the following changes to GetIndexesInRange:
https://i.imgur.com/pWeOvBJ.png
Which gets us this:
https://i.imgur.com/L24tEdb.png
Dependent on the AI of your abilities this might be sufficient.
