@Hinato: Ok, I would recommend also making some new hex tiles that block all three edges on one side, as it will probably make your work quicker and greatly reduce the number of invisible actors (even though this has low impact on performance). If the amount of invisible actors should ever become a problem you can simply destroy them all on even begin play after they have been added to the edge array.
For your new question, don’t bother with casting. Just get the edge array directly from the Get all Actors of Class node. As long as the default value of the Grid Manager class variable is set to Grid_Manager (Grid_Manager_Child_Hex might also work, but is not necessary) it should work fine. Just tested it out.
Edit: Quick example of how to print the faction of the pawn on index 1 of the grid from ATBTT_PlayerController:
If you want to do this kind of stuff often it will save time to save the output of Get All Actors Of Class (Index 0) in a separate variableso you don’t have to get all actors each time.
That’s the only part of the blueprint that differs from the old atbtt version. The pawn can walk through the gap in the wall if the door isn’t placed and can’t walk through if it’s there. If the door is opened he could walk through in the old atbtt version but this doesn’t work now. Edge cost open is only ‘1’ at each entry, therefore the pawn should be able to pass
Going to look at it again tomorrow… maybe I’m just missing something obvious.
Thanks for all the help!
Edit: Even manually setting all edge costs of the door to 1 doesn’t let me pass. Also I added ‘Set Collision Enabled’ –> ‘No collision’ as well as ‘Set Collision Response To All Channels’ –> ‘Ignore’ to the above function (target is the door mesh). This also won’t solve the problem.
@Hinato: I’m not entirely sure what you’re doing wrong here, so I’ll ask some questions to try to narrow it down:
Grid Manager Ref has a default value, right? I know I keep asking, but I’ve done this mistake so many times myself.
Is the blueprint above contained within your door blueprint? How are you calling it? Have you tried putting a print string in there to make sure it fires when you think it does?
Edge Cost Open is a variable contained within your door blueprints? All edges are set to 1?
Why are you running pathfinding within your door? Why from index 0 with move 0? What are you trying to accomplish by doing this?
It might possibly help you to know the order in which I do things:
Edge costs of tiles are stored in their edge cost public variables that can be modified in the viewport.
When the game begins, the “Add viewport terrain to arrays” function is called within the Grid Manager, adding the edge costs of the different tiles to the edge cost structs contained within the edge cost array at the indexes corresponding to the tiles placed in the level.
When pathfinding is called it calculates a path based on the edge costs that are in the level at the moment pathfinding is called. If edge costs are changed after this, it will not be applied until the next time the pathfinding function is run.
Grid Manager has a default value, the above BP is part of the door and get’s activated on user input. I already used strings to verify that the function fires and the edge cost open is all set to 1. I just copied pathfinding from further behind to show that it fires afterwards (without setting any entries) but I’m pretty sure that pathfinding function is run correctly since it’s almost the same as last version (where everything worked).
The main problem seems to be that even if I select the door in the viewport and set all edge costs to 1 by default my pawn still can’t pass through the door! But if I remove the door completely he can pass. Afaik the pawn should be allowed to pass as soon as all the edge costs are 1 or is there some other condition I’m missing?
@Hinato: Something occurred to me. Are you using auto edge cost based on height? If you are and the door has collision and blocks path trace and is taller than height impassable cutoff, the edge costs would be set to 0 at startup. If this is not the reason I’m confused as to what’s wrong. Maybe we can figure it out over Skype?
Wow never even thought of that… Disabeling ‘AutoHeight’ solved the problem! The door is now working exactly like in the old atbtt version, thanks a lot!
@Hinato: Good to know that solved it! I went through my mind off differences between the two versions that could have caused this, and it seemed the only possibility. If you want to keep auto height enabled, just set the collision of the door to ignore PathTrace and it should work.
Wanted to get some feedback from you on some alterations I want to do with the tool kit
I want to alter the path finding for a hex grid map.
The goal is to make it so some units will have to do forward movement before turning one hex side. Examples:
Infantry can turn when ever they want so there are no restrictions on their path finding
bigger units might have to travel one hex before switching one hex side (Say it is facing north and wants to face south it would need to, 1. Move one hex forward, turn NE, move one hex, turn Se, move one hex, turn south
My solution so far includes
Two different path finding blue prints: the standard one and another that forces the forward movement before turning
Units will need some C++ code in the background to work along with the blueprints for the special units
As for the special path finding I was thinking
a. give each unit an int value stating how many forward movements they need to do, and a bool to let the system know if they can turn.
b. Then in the path finding check to see if a turn is allowed; if not path only in the direction the unit is facing (which I believe is already stored) if true then path find in three direction, the one the unit is facing and one on each side of that
NOTE the reason I was going to have a bool in the unit class was to allow movements to carry over. If a unit moves one space this turn it can turn at the start of its next turn
@nrm21122: That’s some interesting stuff you want to do. I look forward to seeing how it turns out, and I’ll try to do my best to help you out.
I think your solution makes sense. I agree with your decition to have two different pathfinding blueprints. That way you can be sure that your alterations will not slow down pathfinding in units where they are not needed.
As for C++, that I know very little of, and have so far managed to accomplish whatever I want using blueprints. Whether or not using C++ is better for your purposes is your call.
I’m unure if you need a bool. If I’m understanding thing correctly you could just use an integer counter that starts at a certain value depending on the unit, reduce it by one every step it takes and allow turning when it reaches 0. This can carry over just like a bool could.
The facing of pawns is not currently stored in the system, so you will have to implement that yourself. One way to do this is using the parent integers stored in the move structs in the Can Move To array. Any unit moving along a path found within a certain Can Move To array will always be facing the tile opposite the parent of the tile it is standing on, relative to itself. Another would be to use the yaw of the pawn to see which of the six directions it is facing and take it from there.
(Note not sure what happened, I responded yesterday but my post is not here)
Thanks for the quick feedback
I was thinking C++ because then I can do things in the class that may not be possible with blue prints. Case in point, I was going to use a bool instead of an integer (like you suggested) but after rethinking it I may go with the integer option. This way I could put modifiers in to effect the turn radius if that becomes an option
As for storing data I miss read the coding where you had the directions (north south ext) stored with a value of 5 for each. What I am going to have to do is do figure a way limit the directs the Ai will search when doing path finding. While I could do it the old school way where the players had to move the unit one hex at a time this would not be the best option
I will look into your suggestions and see what I come up with
One other question
You hinted a few post back you would be making more up to date videos for the kit. Any idea when you plan to have those available
@nrm2122: Ok, good luck on implementing your custom movement. I’m pretty sure what you want to achieve is possible, and I would personally have started by finding a good way to get unit facing at every step of the pathfinding. Hit me up if you’re having a hard time progressing.
As for new videos, I have been delayed because of a very annoying cold, but I will soon be making a new video. The plan is to make it on wednesday, since I’m busy the next couple of nights.
Edit: I forgot to mention that I have added annotations to the old tutorial videos on all points mentioned in the old videos that have been modified.
So noob question here. I purchased from the marketplace, when you update will it just show that it is available like it does when a new engine version? Or will I have to re-download the plugin again?
@daniel311311: I’m afraid I’ll have to answer your noob question with a noob answer as I’m a bit unclear on this myself. I have seen marketplace items update in the same way the engine does, with the orange exclamation mark and all, but there have also been cases where that didn’t happen. That might be because I check regularly after I’ve sent Epic and update and update the toolkit before it has been fully updated in the launcher (might be a two-step thing), but I really don’t know. I would re-download the toolkit before starting a new project if I’ve recently made an update just to be sure.
Hey ! After some time I really have to say that I like the new version very much!
Another (hopefully quick) question… Where or better how and when are the ‘Tile in movement range’ and ‘Tile in attack range’ meshes placed? I want to remove the blue ‘Tile in range’ meshes when a button is clicked and show red ‘Tile in attack range’ meshes instead (within a range that I can specify).
Good that you like the changes, Hinato As for your question, it depends a bit on what you are asking. If you just want to change the appearance of the tiles in move range/sight range, they can be changed in public variables in the grid manager. If what you want to do is instead to prevent tiles in move range to be displayed at all, that can be changed by unchecking the “Display tiles” box in the Pathfinding function which can be found in the “Begin Unit Turn” part of ATBTT_PlayerController. If you want to go even deeper, you can go within the pathfinding function to the part where it runs the “Spawn Tiles In Move Range Markers” function and modify that. I hope one of my three solutions is the one you needed.
Sorry maybe I should’ve made myself a bit clearer. The last part is what I was looking for… didn’t think to look in the Pathfinder… THX!
I’m working on a hotbar and as soon as a hotbar button is pressed the possible (blue) move range shouldn’t be displayed anymore. Instead there should be red tiles which show the ability range (like with melee and ranged attack). Finally, after the ability was used, movement tiles should be displayed again.
I’ll try to run pathfinding again and set stuff up with that… If that won’t work I’m going to start with looking into pathfinding some more!
Ok, in that case you shouldn’t have to change the pathfinding function itself. Just run the “Clear All in Range Mesh Markers” and clear the “Can Move to Array” (both are contained within the grid manager). Then run the “Find Tiles in Range” function for displaying tiles in range. See the “Begin Unit Turn” and at the end of “Initiate movement towards and/or attacking target” within ATBTT_PlayerController for examples.
I’ve finally uploaded a new tutorial video. This one shows how to use many of the new features in the latest update. Make sure to enable annotations, as I have made a few minor changes after the latest update which have not been uploaded yet, which are noted. Hope the people using the toolkit will find the new video useful.
Simple question: if I have one tile index, how can I know that tile class? More deeply, how can I possibly cast it to Tile_Parent?
I don’t know if there’s already such a function (or workaround) in ATBTT, meanwhile to clear this issue I’ve created a new public array in the Add Terrain to Viewport function of the BP_Grid_Manager (I don’t remember the exact name, sorry) which contains a struct of Index and Tile_Parent.
Is the one above a good solution or I missed something in the tookit?
@Wisom-: The way you’ve chosen to do it is a good solution if you want to access the indexes of multiple tiles during a single tick, when speed is very important. The downside is that you need to add a new, large array, but that’s not that big of a problem. If you do not need to access the tile parents at certain indexes every tick a simpler solution would be to get all actors of class Tile_Parent and run a ForEachLoop where you check the index of each Tile_Parent until you find the one with the correct index.
Here are my changes:
As for your question, it depends a bit on what you are asking. If you just want to change the appearance of the tiles in move range/sight range, they can be changed in public variables in the grid manager. If what you want to do is instead to prevent tiles in move range to be displayed at all, that can be changed by unchecking the “Display tiles” box in the Pathfinding function which can be found in the “Begin Unit Turn” part of ATBTT_PlayerController. If you want to go even deeper, you can go within the pathfinding function to the part where it runs the “Spawn Tiles In Move Range Markers” function and modify that. I hope one of my three solutions is the one you needed.