Be warned that I can take quite a while before something like this is added in an update. If you want to try it yourself it basically boils down to having the movement to each tile be a separate action. In SimulateMove, I add an ActionQueue for each move step instead of queuing the single, large move action. For each step in SimulateMove I check whatever properties of the grid I want for the tile that is being exited and the one being entered and use that to choose the specific move step action and/or input variables to modify the movement.
hi
Thank you very much! Thatās exactly the lead I needed
You are a ace
I think there is another bug (or maybe I did something wrong):
Warning: Script Msg: Attempted to access index 6 from array āInitiativeArrayā of length 6 in ā/Game/AdvancedTurnBasedTileToolkit/Core/BP_TurnManager.BP_TurnManager_C:MoveActorToInititativeIndexā - it happenes when enemy unit awake.
When I mark in the editor in the Multiplayer option - the number of players to 2 (it does not happen in another mode), there are a few log warning saying: that in blueprint - bp_unitstealthcomponent (envent begin play) cant read callfun turnmanager - remove item.
its not happenes all the time, but a lot of the time. you have a delay node set to 0 (just after the isvalid for the gridmanager) , so when I set it to 0.5 there is no warning.
I know you donāt have much time know so its not that important, just check it when you can.
Thank you. It was a quirk of blueprint scripting that it ran twice when attaching from a āfloat + floatā node. I set a local variable to the result and used that in both cases and it worked.
In my game, I can also lower the tiles using the abilities. So that the tile can go below 0 in the Z position. I have set the height map to be -500 to 500 on the Z-axis and the tiles are clamped within -150 to 150. Is there any reason would stop pathfinding from working for tiles below 0 in the Z-axis?
The second problem, I am doing an AOE raising of a tile. If I do this close to the edge of the gird it raises tiles on the other side of the grid. I am currently using the GetTilesInRange function to find the indices of the tiles that need to be raised. Any tips on how to fix this?
After these are fixed my next venture is to have a unit which does not count toward the victory condition. This unit will be off the grid, will have a turn, not be attackable by other units and only usable by players. How would you suggest I remove the unit from the victory/lose condition?
Hmm, yeah Iām seeing the same thing. I should have checked the log more thoroughly after making the initiative changes in the last, update, it seems. Again, the warning does not seem to matter for gameplay, but Iāll find out what is causing it and fix it.
Good to hear it worked. I donāt think there is any reason why having tiles below the height of the grid manager should not work. Just make sure that the minimum height is set to lower than your lowest possible tile in the Procedural settings and ensure that CollisionPlaneWalkable is false; or else the collision plane will block any traces that cross it.
Odd that you are getting tiles on the other side of the gridā¦ Iāve designed GetTilesInRange so that this should not happen. Iāll look into it.
For your victory condition, check the function that checks if the game has ended, which is attached to the KillUnit event in BP_Unit, I believe. In the for each loop that checks through all units you can compare the units to a reference to your special unit and skip it if encountered, using a branch.
Ok, good to hear it wasnāt something wrong with the toolkit.
I am redoing my project partly due to the recent updates to this toolkit and Iām wonder the following:
Is all of the activation of the ATBTT tied to the Activate ATBTT event in the GameMode? Leads to 2nd question:
My game will have 3 different āstagesā, one stage where you enter when you start and you can create a party and a session. Next stage is a Lobby-like stage where clients can connect and do certain things like create a character and customize that character. The third stage is how gameplay in your toolkit looks. Previously Iāve had these stages been quite seperated due to me working on the in parallell but now Iām wondering, all of this should be able to be done without switching GameModes, PCs, Game and PlayerStates etc correct? As long as I donāt activate ATBTT until Iāve traveled seamlessly to the desired level?
Ok, question two kind of took over, I hope you understand what I mean. If you donāt I will gladly try to explain again in more detail
Hello! Iām trying to make a bar that is displayed above a unit, which shows how much energy they can use on different abilities. I thought the best way to do this would be to create/modify a duplicate of the Health Bar (the component, SetUpAPBar function, and ModifyAPBar function within one of the existing units based on BP_Unit) and set it up to display the Action Points. Then I would modify (or for practice purposes, create a duplicate and modify) BP_Ability_Move to queue an action (perhaps in the āclickā section) that calls the ModifyAPBar function with the APCost as input. Is this the best way to do this? Is there a built-in AP display Iām missing? Any tips/advice?
Basically everyhting, yes. There are some blueprints that have independent startup stuff happening on BeginPlay, but the chain of events that sets up important blueprints, sorts units in initiative and starts the game is all tied to the ActivateATBTT event.
I believe yes. As long as you donāt activate ATBTT it should all wait for you while you do all the UI stuff.
Sounds like a reasonable approach. There is no built-in AP display, no, but you should quite easily be able to make your own by following the example of the health bar, as you suggest. Just be absolutely sure that any time you modify AP the queue to modify the bar is called (and the other way around), so there is never a discrepancy.
Ok, good to know! Now I just need to think on if this is the optimal way to do it, but then at least I know it should be doable should I decide it. Thanks!
Iād like to let everyone know about a Kickstarter that was just set up for a game that used ATBTT in its creation. It is called Grand Guilds and is a game that combines turn based combat on a grid with card-based combat abilities. It looks and sounds amazing and already have a great demo you can download from their Kickstarter page. Iāve already backed it, so let it be known that if any of you guys make a great kickstarter for a game that uses ATBTT youāll instantly recuperate the cost of the toolkit
I wanted to ask if you had any advice on the best way to create a function that takes in an array of tile indexes and spawns edge tiles for them? I want to use this to achieve the same edge grid style but without the use of path finding but only a set of index tiles. An example would be displaying the impact of a grenade where I have the impact Index, I get the diamond range indexes with the range functions and then pass the indexes into a function that would create edge meshes around the perimeter (index array).
Great plugin mate, keep up the great work! And Grand Guilds looks great wish them the best.
Have had some fun experimenting today. Iāve tried changing up some of the functions to be more agnostic when it comes to grid size and it has opened up some possibilities. One of them is sub-grids! These look similar to the grid manager, but are mostly empty save for some variables defining their size and relative position to the grid manager. On setup the grid manager gets all sub-grids and includes them in generating the GridLocations and GridEdges maps, resulting in the sub-grid being treated as an extention of the main grid. Very handy for stuff like long and winding dungeons, where the grid is covering a large area but there is a lot of empty space. Take a look:
There are a few different ways to do this, though Iām not perfectly happy with any of them. Outlines is one of the things on my todo list to improve. But if youāre happy with the way edges are spawned in the 2D example that is fairly easy to extend. Take a look at BP_Ability_2D and the MakeEdgeMeshTransforms function. This function takes as input an array of tile indexes, like what you are asking and sets up an array of transforms for spawning edge meshes (which happens as an action). For your function you can basically do the same thing, only instead of checking whether a tile surrounding one of the indexes is in the PathsMap or RevealedGridIndexes set you would instead check whether it is in your own custom array of tile indexes using Find.
Have had some fun experimenting today. Iāve tried changing up some of the functions to be more agnostic when it comes to grid size and it has opened up some possibilities. One of them is sub-grids! These look similar to the grid manager, but are mostly empty save for some variables defining their size and relative position to the grid manager. On setup the grid manager gets all sub-grids and includes them in generating the GridLocations and GridEdges maps, resulting in the sub-grid being treated as an extention of the main grid. Very handy for stuff like long and winding dungeons, where the grid is covering a large area but there is a lot of empty space. Take a look:
i want that my unit will be of class -character or pawn (like it was in the older build). i need it for my game (there are parts i am using third person view with free movement). i am a little bit lost with the change to actor class.
if i want to implement character class as my units, i made a unit class, bp_unit(pawn) do i need to do something else ? do i need to change something in one of the blueprints? if i change the unit class from actor to pawn do i loss some other possibility?
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.
Well it will be a little bit long and so I apologize in advance
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.
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
