Hi, sorry for the very late answer. You had not given me permission to view the video so I was unable to view it. I am able to see it now, though. The problem here is that you are trying to assign a blueprint actor to a variable that requires a skeletal mesh input.
[quote=āser.man94, post:3909, topic:21930, full:trueā]I make not wolking tail but is the same problem the fly unit can ignor walls and go to next hex
Hmm, hard to know what is going wrong here. If you follow the tutorial and use terrain types that block movement for ground units and not for flying units it should work. Maybe the tiles you have placed on the map block WallTrace or something? Iām just guessing here, as it is a bit hard to know. The terrain you have placed there are just GridActors right? Not BP_Tile actors with edges etc.?
sorry i make linc canāt see any one but something get wrong. and i give the access. exist a possibility to create a variable between skeletal mesh and blueprint? i buy some assets and all creatures are maiced in blueprint.for building and wall is not a problem but for puppet is need to do spmething. thank you for your time
yes i make from video tutorial step by step the price work great but they can ignor the wall.
Iāve been away from UE4 for a while so please forgive the silly questions. There is another asset on the Marketplace that has a similar movement format to ATBTT except that instead of just highlighting a square to move to, he uses a movement cylinder (not a big deal) but when the cursor (cylinder) moves adjacent to cover a ghosted version of the UE4 mannequin appears in a cover animation (i.e. if you click to move the character will do so and then assume a cover pose based on the cover ā high or low, like in ATBTT. While that is quite interesting to me, there is a further plus in that when you move the cursor to the edge of the cover the character will assume a peeking animation (well, I think itās cool). All that said, the other asset has nowhere near the functionality of ATBTT(nor the level of support) so, naturally, I want my cake and eat it too. Would mechanics like these be doable in ATBTT or would I be looking at a complete exercise in frustration? Thanks
For the skeletal meshes, you canāt simply add the blueprint you bought on the marketplace as a puppet. You will have to do some manual work. I recommend checking out my three āPuppetsā videos on YouTube. You should watch all three, but the last one goes into how to add puppets with non-standard skeletons.
For the issues you have with walls it is still hard to know what might be wrong here. Here is how I would do it, building upon my tutorial. If you are doing anything differently, please let me know. Using the terrain system you can define for each unit what terrain they can move through. So to have walls that flying units can move through I would create a āWallā terrain type. Flying units would be set up so that they are allowed to pass through the āwallā terrain type, while other units would not. The walls would just be Grid Actors that add Wall to the GridTerrain map variable at the appropriate tiles. This would not be a tile actor that has any edge costs set up or that has collision blocking the Wall channel. Is this what you are doing?
Hi Dijon, long time no see! What you are describing sound very doable in ATBTT. That is just visual stuff with no impact on gameplay, and the way ATBTT keeps visuals separate from gameplay code means that you donāt need to do any major refactoring in the code to set something like this up.
Changing the move marker to a cylinder is trivial. Just replacing the mesh in the GridUI you are using. Showing the ghosted mannequin will take some more work, but the principle is similar to how I show the hover meshes arround surrounding tiles. You could use the same setup I use for finding which adjacent tiles have cover and then place and animate the ghosted mannequin as appropriate.
Note that in the last update I added crouching animations for when a unit moves into cover (in the new Demo map). This should give you a starting point for adding your own cover animations.
@ Indeed, itās been a long time. I was unaware of the most recent change so, yes, that will be a big help. Regarding the setup that you have for determining which adjacent tiles have cover, could you point me to where you do this? Itās going to take me some time to get around this again.
Also, as usual, thank you for the great reply. I wish all devs were this good.
Thatās awesome, thanks. I seem to recall that, once upon a time, you had a video tutorial that talked about program flow. Does that sound familiar? When I look, for example, at your image, there is a āGridManagerRefā but itās not immediately obvious where that reference is obtained? Iām also curious about the difference between Move and Sprint.
Some actors have a grid manager reference set during BeginPlay or in their ConstructionScript, but for those that donāt you can now use a Get Grid Manager function, which is contained in a function library, so that it can be accessed by any actor.
There are a few different move abilitites included. Move is the most basic one. Very straightforward without anything special. Sprint is designed to be more like movement in XCOM. It shows movement that costs more than 1 AP in a different color and shows cover icons around surrounding tiles when moving the cursor.
By the way, another new thing since you last worked with the toolkit is that we have a fairly active Discord channel now. Feel free to drop by! Link is on the marketplace page.
Thank you. Iām glad that the size of the community is getting larger; this truly is an amazing asset. Would you prefer that I post future questions to Discord or do you prefer them here?
Yeah, kind of wish I had started such a community sooner. Means it is easier for devs using my assets to help each other as well. For longer questions that require that I reply with multiple screenshots, this discussion thread is better. For shorter questions Discord is more practical.
Iām working through the first tutorial on custom puppets and I noticed that you donāt touch the Child Actor setting in your example with Golden. The skeletal mesh of my duplicate unit_anim_bp stays at the default mannequin. Dragging the character into the scene and changing the puppet there works as yours does, but on the Jungle map, it doesnāt take cover.
So, is it normal that the base unit anim bp and its children only show the default mannequin, and what would you recommend as a starting base class? Would it still be bp unit anim and then just add abilities, or is there a better starting bp for cover and things like that? Thanks.
So for the first one you will likely have to change the puppet a bit. Animation of puppets in ATBTT works through the AnimateMovement and AnimatePuppet events. Normally these call interface events on the animation blueprint of the skeletal mesh. In this case you have multiple skeletal meshes with (Iām guessing) multiple animation blueprints. If this is the case you will have to loop over all of these and call AnimatePuppet on each.
For your second issue, you are adding the ability system to the puppet, which will not work. The puppet is only for stuff that is not relevant for gameplay. Rather add the ability system to the Unit (not Puppet).
I generally recommend to create your own version of BP_Unit_Anim (so a duplicate) as a starting point, so that it is easier to modify stuff, but a child actor of that works as well. BP_Unit_Anim serves kind of like a binding between the Unit and the Puppet, so Unit_Anim (and its children) have added and overriden functionality over BP_Unit so that it queues actions etc., using the Puppet as input. The crouch and climb stuff is in BP_Unit_Anim_Demo. This is something you can look at when deciding how to build your own Unit_Anim variant.
Hi Monokel,
I have āTowerā units that do not move, only attack. Is there a way to skip unit activation if there are no enemies in range? When there are a bunch of towers, it can take a while for the game cycling through the towers doing nothing that would be better if skipped.
Thanks!!
Hi, so the way unit selection currently works is that when a unit is selected an action is queued to show the selection. For AI units, determining if an ability can be used happens after this action has been queued, so without modification this will always trigger, even if no abilities can be used. Also there is a constant delay between turns which is set in BeginNextValidActorTurn in the Turn Manager.
To achieve the result you are after, the action must only be queued after we know that an abiliy will be used. Also, we will need to modify the dealy between turns if no ability was used. Where and how to do this depends on if your towers are using the AbilitySystem component or not. Are they using it or just going by their DefaultAbility?
Ok, try this as a starting point: In the example map set the enemy unitsā movement to 0 and their ranges so that some will reach the players and others will not. Set their DefaultAbility to BP_Ability_Attack.
Now, in BP_Unit make it so āShow Unit Selectionā is only queued if the activated unit is not AI controlled. Next, in BP_Ability_Attack you similarly call Show Unit Selection only if the unit is AI controlled and is actually about to execute the ability (meaning it found valid targets). If you do it this way youāll have to set up all abilties your AI will use in a similar way, so might be able to find something less clunky if this gives you something close to what you had in mind.
(incidentally it seems the first branch here is something left over from some testing I did, which should not have been included in the released update, so you can safely skip that part)
Let me know if this is similar to what you had in mind.
Another (hopefully) quick question for you. In most modern tactics games, the player is able to click on enemies to see their stats, attack range, etc. Currently in ATBTT you are unable to click on enemies at all? I tried adding āevent ActorOnClickedā to Units but the event never fires. Is it possible to make enemies clickable? Thanks!