[SUPPORT] Advanced Turn Based Tile Toolkit

[Remisiel]

@;370975

Sounds reasonable! I’ll look into it at the next opportunity, and will probably include it in the update. Let me know of any other minor (or major) annoyances you might encounter

For sure! I will have a look around at my changes and let you know anything else I come across in the future.

Thanks!

Any plan to switch to Math Expressions within the toolkit now that they are going to be at least 2x the speed?

[Remisiel]

@ : Ended up rewriting all of the Hex Grid portion of ‘Get Indexes in Range’ to use Math Expressions instead of singular nodes. Tested, verified, and much faster considering my use case for it. Let me know if you want it for the update and I will send it over.

[Monokkel]

Hey, I planning to do just that Good to hear it did in fact make it faster. Sure, it would be great if you could send it over. Will save me some time.

[anonymous_user_c2655a011 (anonymous_user_c2655a01)]

@;371129

I started with some line/sphere tracing but it was pretty heavy lifting when all I really needed to do was set indexes based on grid size and direction. (Quite a bit more math to it then that, but looping through Integers is so much more efficient than line tracing imho)

May still use some line tracing to change the attack tile indexes if the attack starts on the Unit, but that will happen a bit later

Yes I know that it could be done with some grid math, but thinking of a next multi-level grid implementation I thought it was better to get pawns through sphere traces (if I have two units, one above and one below a ladder I could get both of them with a sphere trace).
And about the performance I can say that result is not heavy as it seems.

[Remisiel]

@Wisdom-: For your use case I can see that making sense I guess. Although you could also use Max-Z-Distance to accomplish the same thing (per your example). If you are doing multiple grids for say a ‘rooftop’, you could create a component tag on the CollisionPlane for a Child BP_Grid_Manager and do the initial line trace to collide with whichever CollisionPlane has that tag as well.

Lots of ways to do it, but I would say stick with what you know works

[Monokkel]

Both soloutions sound good. When I begin working on multi-level grids I’ll probably be using grid-math due to personal preference, but I’ll be checking out multiple solutions.

@: I’ve tested out your math expression, by the way. There was a slight speed improvement, though a bit less than what I had hoped for. I used a sight range of 40 tiles (as a sort of maximum reasonable case), and here the Get Tiles in Range function saw roughly a 10% speed increase. When running the entire Find Tiles in Range function the total gain was about 3%. That’s still enough that I think it’s worth implementing, though. I’m all about opimization

[Remisiel]

@;371925

@: I’ve tested out your math expression, by the way. There was a slight speed improvement, though a bit less than what I had hoped for. I used a sight range of 40 tiles (as a sort of maximum reasonable case), and here the Get Tiles in Range function saw roughly a 10% speed increase. When running the entire Find Tiles in Range function the total gain was about 3%. That’s still enough that I think it’s worth implementing, though. I’m all about opimization

Glad to be of assistance! I was hoping for roughly 2x speed increase as they stated in the 4.9 patch notes, but any speed increase is awesome!

[Monokkel]

Yeah, thanks man! I didn’t expect it to be twice as fast, as that would be the case if the entire function could be converted to a math expression. It would have to be some fraction of that, and it seems that there are other parts of the function that are much slower than the pure math parts.

[Mr_SquarePeg]

Hey - Is there any plans for a price hike to the Pack?

Just curious as - I am wanting to buy this but I am short on money until payday. :\

[Monokkel]

Hi HeadClot! I’m considering increasing the price at some point, but that won’t be until I’ve added several more of my planned features. With the time it takes to make this stuff you should be very much in the clear to your next payday

[Mr_SquarePeg]

@;372296

Hi HeadClot! I’m considering increasing the price at some point, but that won’t be until I’ve added several more of my planned features. With the time it takes to make this stuff you should be very much in the clear to your next payday

Thanks for the info .

Glad to hear that it will be a while before the price hike.

[anonymous_user_c2655a011 (anonymous_user_c2655a01)]

@;

Hey . That same question was asked on the previous page of this thread, where pasted a modified version of a function I sent him some weeks ago for doing just this. I’m finally back home, though, so I can finally post my own current version. Here is the WIP function for spawning units at runtime (BlueprintUE link):

It still has a few small issues, but it’s mostly complete. I’ll explain what it does. First it spawns an actor of the Unit_Parent class (the specific one is specified outside the function) at a certain location. The user can choose to either spawn the unit at an index or a transform. If transform is selected the location of this transform is first run back and forth through the VectorToIndex macro and the Vector Field Array to return the location of the closest grid cell center to the transform entered (don’t want to spawn the unit between two tiles). Then the index value of the actor is set to the index of the tile it is spawned on. After this the unit is added to the Pawn Actor array and its faction to the pawn array, both at the index of the tile it was spawned. Lastly it is added to the initiative order, or it will never be selected. This always adds the spawned unit to last in initiative, and might cause issues if you allow switching between units (the default toolkit assumes players and enemies will have distinct turns, which might be altered if you alternate adding enemy and player units).

The way you have done it has a few issues, and I’ll point them out so you can understand the inner workings of the toolkit better. When you add the unit to the pawn actor array, what you are doing is increasing the size of the pawn actor array by one by adding the unit to the end of it. The Pawn Actor array is the size of the grid with each index representing a grid cell, so if you add a unit to the end of it it will be placed at the last tile index +1, outside the bounds of the map. Instead you should use the Set Array Element node and set the index corresponding to the unit’s location. “Has acted this turn” defaults to false, and so you do not need to set this to false when spawning a unit. Place actor at anchor and ignore snap to custom grid are variables that only have an effect when you’re working on the game in the viewport, and not when you’re actually playing the game, so modifying these at runtime serves no purpose. Lastly if you always want the max move of the spawned units to be 4 you would be better off modifying the default value of this variable in the unit’s own blueprint.

I hope this helps you with your problem. And congratulations on reaching your Kickstarter goal

Hi !

I’ve tried to use your function (and thank you for posting that) but I’ve found a strange issue.
After spawning the actors, I can see that Custom Grid Anchor component and SkeletalMesh are located in different places!

Maybe below screenshot can explain the situation better (my pawns are the green ones):

I cannot understand why it happens. Below is my Blueprint where I call the Spawn Functions (and function is the same of yours).
Please notice also that I’ve added the anchor function of the Grid Manager otherwise also the anchors will be outside of the map (and I cannot move any unit) :

Can someone help me?

[Monokkel]

It seems I forgot to add one thing to the Spawn Unit function. It actually has nothing to do with the grid anchors (so you can remove that bit). I’m guessing your grid manager is not placed at location 0,0,0? The reason you’re having this issue is that the function is not taking the location of the grid manager into consideration when spawning units, and thus the function only works if the grid manager is zeroed out (I really should stop testing with the grid manager placed at 0,0,0 as I keep making this mistake ). Add this to the function to make it grid location agnostic:

To explain further the grid manager thinks the units are at one location, since the pathfinding and other functions are already made to take the Grid Manager’s location into account. The Vector Field Arrray hold vectors that store the location of tiles relative to the grid, so when you spawn a unit directly from a vector from this array it will show up in the wrong place if the grid manager is not zeroed out.

[anonymous_user_fff38ccc]

Hi,
is there a way to change it so the grid manager has less spacing/no spacing between the tiles?

[Monokkel]

Hi eviltenchi, there isn’t actually any spacing between the tiles (in terms of the undelying blueprint logic). The reason there seems to be spaces between the tiles is just because of the meshes I’ve chosen. Use flat planes for the default tiles or increase the scale of the Tile In Move Range and Tile In Sight Range meshes and you can lessen/remove the space between them.

[anonymous_user_c2655a011 (anonymous_user_c2655a01)]

@;374343

It seems I forgot to add one thing to the Spawn Unit function. It actually has nothing to do with the grid anchors (so you can remove that bit). I’m guessing your grid manager is not placed at location 0,0,0? The reason you’re having this issue is that the function is not taking the location of the grid manager into consideration when spawning units, and thus the function only works if the grid manager is zeroed out (I really should stop testing with the grid manager placed at 0,0,0 as I keep making this mistake ). Add this to the function to make it grid location agnostic:

To explain further the grid manager thinks the units are at one location, since the pathfinding and other functions are already made to take the Grid Manager’s location into account. The Vector Field Arrray hold vectors that store the location of tiles relative to the grid, so when you spawn a unit directly from a vector from this array it will show up in the wrong place if the grid manager is not zeroed out.

Thank you for the precious help, it works perfectly now.

[Monokkel]

@preetlove;374978

Good information dear… thanks for share and am use it for sure.

You’re welcome!

@Wisdom-;375104

Thank you for the precious help, it works perfectly now.

Good to hear! Sorry that I missed it the first time.

[Anzak]

@ - Do you have an ETA on when you release a 4.9 version? With the infinity blade collection released it looks like there are a lot of really nice assets that I would like to import into the tool kit to spice up the appearance.

[Monokkel]

That stuff looks awesome! They’re a fantastic fit for the toolkit too! The next update is stille some ways to go, but just convert a 4.8 project to 4.9 and it should still work. There are some errors in the log, but they are inconsequential.

[Monokkel]

I’ve sent a minor update to Epic that makes the toolkit fully updated to 4.9. The 4.8 version worked fine in 4.9, but now it should give no errors in the log. The large content update is still being worked on. Here is the changelog of the new, minor patch:

v1.43 (being processed by Epic)

1. Changed all Set Visibility nodes of markers to Set Marker Visibility Functions to prevent an error in the log.
2. Removed Clear all Instances from the Clear range array, reachable pawns array and path meshes collapsed graph in the Find Tiles in Range function in BP_GridManager to prevent an error in the log.
3. Changed all Get World Location/Rotation And Distance Along Spline nodes to the newer Get Location at Distance Along Spline (with coordinate space set to “world”) nodes.
4. Removed unnecessary cast in HUD_Faction_Turn and changed the name of Tile Spawner 2 to Grid Manager Ref to make it consistent with other blueprints.
5. Replaced the landscape in the landscape example level as it was having some collision issues.