Hmm, “get all actors” should work fine. Are you getting an array of all the actors and geting the actor on index 0? That should normally do it. If you are using a class reference to get all actors from, make sure that its default value is not 0.
For finding the distance between tiles this is something that is actually not in the current version of the toolkit. It will be in the next update, which should hopefully be done next week. Here is the function for getting the distance (in tiles) between two tiles using either hexagons or a square grid with or without diagonal movement:
For equipping wepons and similar this is something that will also be included in an example game in the coming update. The solution I have found is a bit clunky, though, so there might very well be better solutions. It works pretty okay, though. I have created a weapon class that holds the appearance, damage and range of a weapon. This is a 2D roguelike example so I’m using a paper sprite for the appearance, a float for damage and an integer for range. My custom hero unit in this example has a variable that holds its current weapon (of the weapon class). When the unit deals damage it gets the damage variable stored in this weapon variable. When the unit changes its weapon it runs this function:
You were right, somehow the defaults had been reset. Strange.
The range finding works perfectly, finally got my hit chance calculations working. Thanks.
As for weapons, I figured that the easiest solution would be to just change the range and damage, but that only seems to update at the start of each turn?
Ok, great to hear you got it working! Yeah, my solution for weapons might be a bit much in many cases. Changing damage and range should work well. Damage should not be problematic to change at any point as it is only checked when doing an attack. Attack range however is checked only at the start of a unit’s turn or when it has completed its move. If you want to change range in the middle of a unit’s turn you would have to call the Activate Unit function in ATBTT_player_controller again after you have changed the range variable.
So that worked, but I encountered a weird issue where if I have a range of 1 and try to do a diagonal attack after moving the unit it will simply do nothing and end its turn. However, if it has not moved it will teleport to index 0 and attack from there.
Hi again. Sorry for taking so long to reply. For some reason I did not get an email notification about the new reply this time. I have added something I think is similar to what you have done and I am not able to replicate your problem. Teleporting to index 0 is something that can happen if parts of the pathfinding returns 0 for some reason. Can you try to use my simple solution and check if you are still having the same issue? This is what I have added to ATBTT_PlayerController for testing purposes:
This simple blueprint in ATBTT_PlayerController switches the current unit’s range and damage between two arbitrary values each time ‘1’ is pressed and reactivates the unit. The execution pin going off to the right is connected to the “Set Current Tile Hover” part of “Display Path on Hover” to ensure that the spline showing the movement path to the target/ranged attack path is changed if appropriate.
I just bought the Toolkit two days ago and am trying my best to unravel its many mysteries! I’m an artist and level designer with no real aptitude for programming, but I bought your kit because I want to use it as the basis for a grid-based-movement system in a first-person VR game. The idea is that you’d toggle a widget cursor in the center of your 3D view by hitting X on a gamepad, then you’d look at the in-range tile you want your player to move to and click A to warp there (either instantly, or by racing along the spline path at a player-defined speed without acceleration.)
I have a theory that I can dismantle the top-down camera, parent it to a socket on the Unit_Player_Melee pawn’s neck and then make him invisible. I haven’t gotten that to work yet, as there is a lot of complexity in how the camera operates. Also, I’d like the player to be able to advance one grid square in any direction just by clicking the D-Pad. Have you considered VR as a use-case for your Toolkit? Do you have any suggestions for how I could accomplish this? Thank you for this awesome kit, and for your consistent efforts to make it cooler and better!
So I’m finally done with the 1.5 update! This one took a very long time to make, so I hope you guys will like it. It is the biggest update I’ve done until now, both in terms of new features and reorganization. Still some of you might think that is a smaller update than what you would expect from the amount of time I’ve spent on it.
The biggest reason for this is that I have done a lot of experimentation and changed many features in various ways. Some of this led to dead ends while other times I had to reiterate several times before I had something I was happy with.
What remains are the changes I finally landed on after much trial and error. Some of these changes are large and modify core aspects of the toolkit. For those of you who have already come far in making games using the toolkit the hardest change to implement will probably be the one that changes the old Edge Array into a nested array.
Because of the sheer amount of changes I have not marked these with a version boolean as I have in previous updated. I will instead be making a video later that goes through all changes I’ve made in detail.
Since it is close to the holiday season it is likely that it will take some time until Epic uploads the new version in the Launcher. Until then here is the changelog (less detailed than for other updates due to the size of this update):
v1.5 (being processed by Epic)
Changed the edge array to be a nested array of structs, with each struct representing a single edge. This change required major changes to all parts of the toolkit that utilize edges, but makes pathfinding even quicker and opens for grids with customized connections between tiles.
Added touch controls and an option for rotation 90 degrees at a time (currently default, but can be unchecked in BP_GridCamera)
AI has been improved significantly. AI now selects from all possible tiles to attack its target from, choosing depending on a personality enum. The AI will now move as close as possible to units it cannot reach if the path is blocked by a friendly unit.
Player units can be set to display all possible tiles that can be attacked from all tiles in move range, similar to Fire Emblem and many other TBS games.
Tiles in Sight Range and Move Range can be displayed as a frame.
Improved commenting and organization across the board. Variables and functions are now grouped in categories.
Included a variety of utility functions in BP_GridManager such as spawning units and tiles during gameplay among other things.
Split up the Event Graph of Unit_Parent into several sub-graphs for easier modification. Unit_Parent’s event tick now only fires when it is needed for movement, improving performance.
Added several “slow loops” which spread loops over multiple ticks. These can be used to improve performance when necessary. These are used by default when displaying all possible visible tiles for player units, since this is a demanding operation, and when an AI unit is activated.
Added an example game called Hydra’s Lair that demonstrates how the toolkit can be tweaked to create a 2D dungeon crawler. This includes many experimental features such as fog of war, weapons and armor.
The example game contains sprites from Dungeon Crawl Stone Soup, which are licenced under Creative Commons Zero and can be found here: Dungeon Crawl 32x32 tiles | OpenGameArt.org
I have big plans for future updates and cannot wait to start working on the next one. This time I intend to keep the scope smaller so that I can release updates more frequently. For the next update I’m planning to add true multi-level grids, a cover system and a faction system.
The features in the game example aren’t as polished as the ones in the main toolkit, but should hopefully serve as inspiration. Example maps give me an opportunity to experiment a bit more wildly with the toolkit and add features that are more game specific and that do not have to work for any genre of TBS games. It also shows how it is possible to modify the toolkit to create very different games without touching the default blueprints at all, using child blueprints and the like. Expect me to make more example games in the future for various TBS genres. A simple XCOM clone is next in line, two updates from now.
: Do not be too sad The next updates will be quite a bit smaller than the last one, so the two ones combined should probably take less time then the last one. I actually just added multi-level grids after a couple of days of intense work. It is still a bit wonky, though, so I’ll need to add a lot of polish. It wasn’t as hard to do as I feared, though. I laid the groundwork by changing how edges work in the update you guys will soon have.
@Joel: You mean like loading a new level after every enemy has died? That is very easy to set up. In the update I’ve sent to Epic I’ve already added code that ends the game when all enemies are defeated. Just connect a “load level” node to this and you should be good.
Does this kit have the ability to pathfind for pawns that are multiple squares/hexes in size? I have been working on a TBS game and wanted to use the navmesh to avoid a grid but it looks like that might not pan out so as an alternative I am looking for a grid with more granularity.
Hard to tell, I’m afraid. The Epic marketplace staff is usually swamped with work and I sometimes have to wait weeks for them to upload new files or reply to requests. Since it is currently the holidays this will probably cause it to take even longer. I will let everyone know in this thread when the new update is up. I’m sorry that I cannot be more specific, but this is outside my control.
Not a problem! I already went ahead and purchased it since I felt like creating some nice-looking tiles already. I’ll simply port these over once your update is out.
Just a quick suggestion I’m going to give that I’ve added that I felt was quite useful and easy to add, feel free to ignore this if it doesn’t match what you’re going for:
Random tile rotation: In the Tile_Parent blueprint, I’ve added a random stream. In the constructor script, this stream will then take in the index to generate the seed, thus making it unique per tile. This seed is then used to generate a number between 1 and 6, which then is converted to degrees. I then use this number to apply a random rotation to my tiles. This can be made optional by adding a simple boolean of course.
Ok great! Thanks for the suggestion. So you are adding a random rotation to all tiles in order to make the grid look “wobbly” and less uniform, am I right? I’m not sure I’d want to add it as a default feature as it would be only for aesthetic purposes, and I’m trying to keep the base toolkit simple and clean. I might use something like that in a future example map, though. Could you show me a screenshot of your results?
