[SUPPORT] Advanced Turn Based Tile Toolkit

[anonymous_user_a3cf52a2]

Hey , congratulations on the rating As always, I’m just stopping by to see if you had any progress updates on the queueing of animations while walking?

[Monokkel]

@anonymous_user_a3cf52a2

Hey , congratulations on the rating As always, I’m just stopping by to see if you had any progress updates on the queueing of animations while walking?

I’ve managed to make it work with unit death for the most part. However, I’m getting an inconsistent bug on long-lasting battles that halts the action queue. It is probably something pretty minor that needs to be fixed, but tracking it down is challenging since the issue is so inconsistent. When I’ve fixed that, the new version should be ready, but I have to be certain that bug is squashed, since it is game breaking.

[Dan.Ott]

Ok @ thanks for your help. So far we’ve managed to get the switch working. When ending turnbased combat we remove all BP_Units from grid, when starting combat again we place them on the grid with the specific GridManager functions. But somehow the tiles of the previous position of the character who moves in realtime remain unreachable after continuing the turnbased combat. We couldn’t figure out what’s going on here - is there a method to clear the tilemap or something like that?
https://s3.gifyu.com/images/holesInTileMap.gif

[Methosborgoff]

@Dan.Ott

https://s3.gifyu.com/images/holesInTileMap.gif

When you grab your character and combat is turned off do you notice that the health bar is still in the orginal location? I wonder if the grid manager is still registering something (grid location reference or something other) tied to that unit when you start combat?

[Monokkel]

@Dan.Ott

Ok @ thanks for your help. So far we’ve managed to get the switch working. When ending turnbased combat we remove all BP_Units from grid, when starting combat again we place them on the grid with the specific GridManager functions. But somehow the tiles of the previous position of the character who moves in realtime remain unreachable after continuing the turnbased combat. We couldn’t figure out what’s going on here - is there a method to clear the tilemap or something like that?
https://s3.gifyu.com/images/holesInTileMap.gif

Either your step for removing or re-adding the units to the grid has to be incorrect. How are you doing each of these? For removing you should be able to simply remove the keys corresponding to each unit’s GridIndex variable from the GridUnits TMap in BP_GridManager. To re-add you would need to calculate which grid index corresponds to each unit’s new location. You can convert a location to a grid index using the ConvertLocationToIndex3D in BP_GridManager. Do this for the location of each unit and add a reference to that unit for the corresponding key in GridUnits.

[Dan.Ott]

Either your step for removing or re-adding the units to the grid has to be incorrect. How are you doing each of these? For removing you should be able to simply remove the keys corresponding to each unit’s GridIndex variable from the GridUnits TMap in BP_GridManager. To re-add you would need to calculate which grid index corresponds to each unit’s new location. You can convert a location to a grid index using the ConvertLocationToIndex3D in BP_GridManager. Do this for the location of each unit and add a reference to that unit for the corresponding key in GridUnits.

We are removing the units from the grid via BP_GridManager’s method “RemoveUnitFromGrid”. The healthbar remains at the last tile on the grid as the position of the units is only updated when realtime is over & turnbased combat continues. To continue combat we use the method you mentioned (ConvertLocationToIndex3D) and the new location & grid index is calculated correctly. Here we use GridManager’s “AddUnitToGrid” method. Everything seems to work fine except for the remove part, we’ll try out removing / adding the keys in GridUnits TMap instead of using RemoveUnitFromGrid now.

EDIT: Allright, clearing the GridUnits TMap instead of using RemoveUnitFromGrid worked

[Monokkel]

@Dan.Ott

We are removing the units from the grid via BP_GridManager’s method “RemoveUnitFromGrid”. The healthbar remains at the last tile on the grid as the position of the units is only updated when realtime is over & turnbased combat continues. To continue combat we use the method you mentioned (ConvertLocationToIndex3D) and the new location & grid index is calculated correctly. Here we use GridManager’s “AddUnitToGrid” method. Everything seems to work fine except for the remove part, we’ll try out removing / adding the keys in GridUnits TMap instead of using RemoveUnitFromGrid now.

EDIT: Allright, clearing the GridUnits TMap instead of using RemoveUnitFromGrid worked

Great that it worked I didn’t think about the heath bar thing until now, however. How are you moving the unit? If you move the entire actor the health bar should come along for the ride. Are you only moving the skeletal mesh or something?

[leo_bar]

hi

there is a problem with the initiative order I think. in order to reproduce the problem, try the following setup:

1. place a adv.grid manger on the level

2. place 2 adv. bp_unit on the grid (player)

3. place one adv. bp_unit on the grid, make it enemy ai and check the unaware

when you play you cant swap between unit (you can only for the first click). Of course the same happens if you don’t place an enemy.

I got some fix but its Only true to a particular situation and its not a good generic solution.

if there is one thing that is very Confusing and a little problematic is the initiative setup

Any help will be appreciated

cheers

leo

[Dan.Ott]

Great that it worked I didn’t think about the heath bar thing until now, however. How are you moving the unit? If you move the entire actor the health bar should come along for the ride. Are you only moving the skeletal mesh or something?

We’re spawning a character on BeginPlay as a child object of the BP_Unit which copies the skeletal mesh of the unit and then destroys the mesh components of the unit. We’re only moving that character in realtime and set it’s position at the beginning of turnbased combat.

We found a confusing issue with the ConvertLocationToIndex3D method: there is a “CorrectedVector” output vector which we understood as the corrected position of the center of the tile but in fact it is an inversion of the input vector. Workaround for this: add ConvertIndexToLocation at the end of the ConvertLocationToIndex3D method as seen in the image. Or is the inversion of the input vector intentional and we missunderstood the purpose?

[Monokkel]

@leo_bar

hi

there is a problem with the initiative order I think. in order to reproduce the problem, try the following setup:

1. place a adv.grid manger on the level

2. place 2 adv. bp_unit on the grid (player)

3. place one adv. bp_unit on the grid, make it enemy ai and check the unaware

when you play you cant swap between unit (you can only for the first click). Of course the same happens if you don’t place an enemy.

I got some fix but its Only true to a particular situation and its not a good generic solution.

if there is one thing that is very Confusing and a little problematic is the initiative setup

Any help will be appreciated

cheers

leo

Hey Leo, you’ll get no objections from me on the initiative system being clunky. It has too many assumptions built into it, which makes anything but a D&D or XCOM-style initiative system a bit awkward. There are also just some weird choices in there in general, as this is a part of the toolkit I’ve been continuously tweaking instead of overhauling, leading to several sections that are somewhat hacked together. I’m finally getting around to refactoring it now, however, and I’ve begun work on refactoring it. Creating something that is both simple, clean and works as a base for several different types of initiative systems is challenging, but I can at least make something better than how it currently is.

To your particular issue, this arises because I’ve forgotten to update the SwapToUnit function to account for the TurnManager as an actor in initiative order (which was not the case originally). To fix this issue. Connect up the following Execs:

@Dan.Ott

We’re spawning a character on BeginPlay as a child object of the BP_Unit which copies the skeletal mesh of the unit and then destroys the mesh components of the unit. We’re only moving that character in realtime and set it’s position at the beginning of turnbased combat.

We found a confusing issue with the ConvertLocationToIndex3D method: there is a “CorrectedVector” output vector which we understood as the corrected position of the center of the tile but in fact it is an inversion of the input vector. Workaround for this: add ConvertIndexToLocation at the end of the ConvertLocationToIndex3D method as seen in the image. Or is the inversion of the input vector intentional and we missunderstood the purpose?

Aha, I see. The cleanest solution if you want to keep the health bar might be to make a new one for your character, or possibly to attach the whole invisible unit actor to the character temporarily.

As for the CorrectedVector, I think that is something left over from an earlier version, and not something I think I’m currently using. Having this output the center location of the tile makes sense, though. I might set it up similarly to what suggest in the next version. You do not need to use the convert function after the GridManager has initalized, however. Just get the location from the GridLocations TMap, which is more efficient.

[Dan.Ott]

Hey ,

thanks for your helpful replies
We now realized that there’s a grid size limitation of 200x200(causing an infinite loop error in this dimension - we did not get grid sizes above 128x128 working). As we reduced tile size to 1x1 meter and our levels have a size of ca 1x1 kilometer we need to reposition & recalculate the grid every time realtime movement ends & combat begins. We could not figure out by ourselves how to cleanly reposition the grid and reinitialize it according to the new location and surrounding obstacles etc. Simply recalling the methods which are in construction script does not solve the problem.

[Monokkel]

@Dan.Ott

Hey ,

thanks for your helpful replies
We now realized that there’s a grid size limitation of 200x200(causing an infinite loop error in this dimension - we did not get grid sizes above 128x128 working). As we reduced tile size to 1x1 meter and our levels have a size of ca 1x1 kilometer we need to reposition & recalculate the grid every time realtime movement ends & combat begins. We could not figure out by ourselves how to cleanly reposition the grid and reinitialize it according to the new location and surrounding obstacles etc. Simply recalling the methods which are in construction script does not solve the problem.

No worries For huge maps you can increase the loop limit in Unreal Engine in project settings -> General Settings -> Maximum Loop Iteration Count. If you’re uncomfortable with having the loop limit very high during runtime when it is only needed at startup you’ll need to do a bit more work. I don’t think you can reduce the loop limit through blueprints, but I assume this should be simple to do in C++. For a pure blueprint solution you would have to split the grid setup stuff over multiple ticks. I have some custom macros for doing this, but it will still require work.

[leo_bar]

hi all

1. • as usual thanks for the help and the time

[Monokkel]

@leo_bar

hi all

1. • as usual thanks for the help and the time

Happy to help. Let me know if you run into any other issues. Thanks for making me aware of this one.

[Skulldug]

No worries For huge maps you can increase the loop limit in Unreal Engine in project settings -> General Settings -> Maximum Loop Iteration Count. If you’re uncomfortable with having the loop limit very high during runtime when it is only needed at startup you’ll need to do a bit more work. I don’t think you can reduce the loop limit through blueprints, but I assume this should be simple to do in C++. For a pure blueprint solution you would have to split the grid setup stuff over multiple ticks. I have some custom macros for doing this, but it will still require work.

Dan.ott, also do you have pregenerate gameplay grid checked in your grid manager ? Also I found in some docs setting max loop iteration limit is 2 billion… that is what I have mine set at. Also, Ramas victory plugin (extra nodes) has a node to for max loop iterations that I have not tried, and I think you can use it to restart loop at certain loop count(have not really looked into it)

Also if you have alot of for each loops they all add up… I have a map with 4 100x100 grids at different heights and alot of units and have not had a problem… YET.
Hope this helps.

[Dan.Ott]

No worries For huge maps you can increase the loop limit in Unreal Engine in project settings -> General Settings -> Maximum Loop Iteration Count. If you’re uncomfortable with having the loop limit very high during runtime when it is only needed at startup you’ll need to do a bit more work. I don’t think you can reduce the loop limit through blueprints, but I assume this should be simple to do in C++. For a pure blueprint solution you would have to split the grid setup stuff over multiple ticks. I have some custom macros for doing this, but it will still require work.

Thanks! : )
Increasing the loop iteration count won’t increase the maximum grid size I guess? So we need to figure out a workaround for the 1km x 1km sized map - of course we don’t need turnbased pathfinding for the whole map in a single turnbased fight - so positioning the grid to the player’s position when the combat starts would be fine. Which methods from the GridManager’s construction script are required for repositioning the grid at runtime? Do we need to clear arrays or TMaps etc?

[Dan.Ott]

Dan.ott, also do you have pregenerate gameplay grid checked in your grid manager ? Also I found in some docs setting max loop iteration limit is 2 billion… that is what I have mine set at. Also, Ramas victory plugin (extra nodes) has a node to for max loop iterations that I have not tried, and I think you can use it to restart loop at certain loop count(have not really looked into it)

Also if you have alot of for each loops they all add up… I have a map with 4 100x100 grids at different heights and alot of units and have not had a problem… YET.
Hope this helps.

Do you use sub grids to get four grids in one level at the same time?

[Skulldug]

@Dan.Ott

Thanks! : )
Increasing the loop iteration count won’t increase the maximum grid size I guess? So we need to figure out a workaround for the 1km x 1km sized map - of course we don’t need turnbased pathfinding for the whole map in a single turnbased fight - so positioning the grid to the player’s position when the combat starts would be fine. Which methods from the GridManager’s construction script are required for repositioning the grid at runtime? Do we need to clear arrays or TMaps etc?

Increasing loop iterations only affects how many computations that can be done… thus you can increase the size of grid and do more computations…
I dont think moving grid is a good idea because all the math for tile finding would be off…
Are you using alot of “foreach” nodes by any chance ? if you are try putting in a macro with “foreachwithbreak” setting break to 0.1 or 0.2 and make sure “oncomplete” has a return node, or use “foreach” with a delay of 0.1 - 0.2
try using “pregenerate gameplay grid” for sure…
Hope this helps some…

@Dan.Ott

Do you use sub grids to get four grids in one level at the same time?

I have an old copy that has a multi level map and using that as template, My map is set up like a 3d chess game and only way to reach another level is through a teleporter/wormhole.

[Monokkel]

: Ah, now I see what you’re getting at. I’ve indeed capped the grid size to 200 in the variable settings of BP_GridManager, though you can easily increase this cap. I’ve added the cap to signal that you’re going beyond what the toolkit is tested for. I’ve tested at roughly twice the size of the largest Civ and XCOM maps, but if you start going greatly beyond this it is mostly untested.

In principle you should be able to have very large grids without issue, as it mostly boils down to storing some large arrays, but modern computers have very high limits when it comes to that. Unlike in early versions of the toolkit, there are no functions run during the game that loop over the entire grid, so it should be pretty scalable. The exception is the startup code for generating the grid, which explains the loop limit stuff you’ve run into.

How big do you want to make this grid, though (in terms of number of tiles X*Y?). If you want to do something very big indeed you might not want to generate the entire grid at startup.

Edit: By the way, subgrids are not used for multi-level grids. For this select MultiLevel in heightmap settings for BP_GridManager. The subgrids are used for extending the size of the grid in the X and the Y axis beyond the base size of the grid, which can be useful for optimization in cases where you have a total play area that conforms very poorly to a rectangular shape.

[Dan.Ott]

Thanks for your replies

Increasing loop iterations only affects how many computations that can be done… thus you can increase the size of grid and do more computations…
I dont think moving grid is a good idea because all the math for tile finding would be off…
Are you using alot of “foreach” nodes by any chance ? if you are try putting in a macro with “foreachwithbreak” setting break to 0.1 or 0.2 and make sure “oncomplete” has a return node, or use “foreach” with a delay of 0.1 - 0.2
try using “pregenerate gameplay grid” for sure…
Hope this helps some…

I have an old copy that has a multi level map and using that as template, My map is set up like a 3d chess game and only way to reach another level is through a teleporter/wormhole.

Would be perfect to figure out a way to move the grid and recalculate the reachable tiles and realign the tile decals.
Yap - we tried pregenerate gameplay grid, will definitely use that in the build version! No, currently there are not many foreach nodes in the blueprints.

: Ah, now I see what you’re getting at. I’ve indeed capped the grid size to 200 in the variable settings of BP_GridManager, though you can easily increase this cap. I’ve added the cap to signal that you’re going beyond what the toolkit is tested for. I’ve tested at roughly twice the size of the largest Civ and XCOM maps, but if you start going greatly beyond this it is mostly untested.

In principle you should be able to have very large grids without issue, as it mostly boils down to storing some large arrays, but modern computers have very high limits when it comes to that. Unlike in early versions of the toolkit, there are no functions run during the game that loop over the entire grid, so it should be pretty scalable. The exception is the startup code for generating the grid, which explains the loop limit stuff you’ve run into.

How big do you want to make this grid, though (in terms of number of tiles X*Y?). If you want to do something very big indeed you might not want to generate the entire grid at startup.

Edit: By the way, subgrids are not used for multi-level grids. For this select MultiLevel in heightmap settings for BP_GridManager. The subgrids are used for extending the size of the grid in the X and the Y axis beyond the base size of the grid, which can be useful for optimization in cases where you have a total play area that conforms very poorly to a rectangular shape.

The biggest map has a size of one squarekilometer - whilst our tiles are one squaremeter (half the size of ATBTT’s standard tiles). So we want the grid to be 1000x1000 tiles big. But of course it would also be nice to just relocate a way smaller grid as we actually only need a grid 128x128 sized grid for the combats, so in terms of performance simply relocating the grid to the player’s position when ever a combat starts would be great - but unfortunately we’re facing many problems when changing GridManager’s positon and it’s unclear which functions of e.g. SetupCoreBlueprints such as SetupCollisionPlane etc we need to call at what moment in order to get the grid align to the new location & it’s obstacles / heightmap.