[SUPPORT] Advanced Turn Based Tile Toolkit

[Monokkel]

@crossmr

Yes, in this case, since we have a reference to BP Unit as the owning unit, I simply added some variables and functions to that, so they’d be inherited by my actual characters. I don’t change any existing code. I do believe I originally made my characters a child of BP_Unit_Anim, which is good, because it’s easier to make changes once than over and over. So When i needed to set up some new variables and things they’re propagated easily. I haven’t run in to any issues doing that so far. I made a new weapon that shoots multiple beams, not all at the same time, so I needed to key that to the animation, but I couldn’t find any reference to the ability in the animation blueprint (but again, there are a lot of interfaces and structs and things so I may have missed it). That was easily solved by having the ability register itself to a variable on BP_unit, which the animation blueprint could access via the owning unit variable. I guess i might be able to drill down through owning unit, to the ability component and then try to pull the specific ability out of there that I need, then find the function, but it seemed much easier just to have the function register itself on the unit.

You’re free to organize things however works best for your game. For my toolkit I’m prioritizing modularity, flexibility and expandability quite highly, which is why a lot of things are handled in blueprints that can easily be slotted out (abilities mainly). For creating a generic toolkit I think this is very beneficial, but for a developer of a specific game that knows the precise requirements of that particular game there are often ways to do things quicker and simpler, so go with what you feel is the easiest to work with.

@crossmr

What I can tell you, is that there are 3 levels there on top of each other. The first level is at a Z level of 0. The unit can path to that level no problem, the second level is at a Z level of 300 and it can path to there no problem. The third level is at a Z height of 600, but it cannot path to that level when it is directly over the 300 height meshes. if I pick a tile that is over the stairs (lower Z height) or over an open area, he can path to those tiles no problem on the roof. I’m fairly certain this is some kind of snapping issue as you described.

The only other place that I have 3 levels on top of one another in the level has the following Z heights: 0, 300, 900. The top level is one additional floor up, and it works perfectly fine. if I take the roof at 600 and raise it up to 750, he’s able to path properly across the tiles. I’ve attached another screenshot showing that. As I showed you before though, my minimum distance between two levels is set to 200. 300 is beyond that and 400 is twice as much beyond that but even at 700 he couldn’t path properly. A little more testing and I can get it down to 725 and still have reliable proper pathing.

As you can see in the screenshot, if I start my unit in a tile I can’t path to, he’s fine. He works okay and he can move. He cannot path to any adjacent tiles though and can only path to the tiles further away that aren’t over top of the floor below. This makes it really apparent that the tiles are actually fine, but my mouse just won’t snap to them. In terms of trying to repro this, I would start by making 3 levels as I have at the distance that I’ve listed above and see if it happens to you or not.

I suspect your thinking about hover events is probably more in line with what is going on here. if I pull the roof up quite a distance it does work fine, so I know there isn’t any inherent problem in the collisions, or the meshes, or anything like that. It’s only related to the distance between the two levels.

Additional note: It also fails to work properly on mobile as well. I forgot to move the unit before testing and so I tried it on mobile and he couldn’t path there either on mobile. But he could path over those squares just the same

Not able to replicate the issue, unfortunately. Seems to work fine on my end:

without being able to replicate the issue it is unfortunately difficult to solve. It is very likely an issue with the function FindCloseValidOverlappingGridIndex in BP_AbilityBase, however, so if you want to do your own bug fixing that is the place to look. For me to fix this you will need to find even more precise replication steps. Preferrably using only assets available in UE4 or ATBTT. If you do that you can PM me a copy of the project and I’ll take a look at it when I have time.

@crossmr

I just looked around the code, and on the touch screen controls the Click Attempt function had “touch” set to false despite being for the touch controls. I checked that and moving is now really easy. Click to select the square, tap it again and it moves. Great. However, now I can’t shoot. Clicking selects, but that’s it. Double tapping, trying to double click doesn’t seem to make it shoot at all. Kind of strange.

So I believe that touch is supposed to be checked. I assume that is why it is there, to indicate touch controls are being used. And this fixes movement. Movement is smooth and nice and perfect with it, but the laser ability is not. So I’m going to investigate that and see if I can figure out where it is breaking the laser ability, but it’s been really hard to track exactly where this input goes and how it gets to the laser ability with all the interfaces and functions and stuff that are in between.

Edit: On that front, checking the “touch” bool, and connecting set clicked location on the touch branch on BP_AbilityBase to “check ongoing actions” seems to partially solve the touch controls. Move changes from a 2 touch, to 1 touch and shooting becomes 2 touch. That’s not quite what I want, but it’s closer. I’d like them all to be a 2 tap thing, once to select, once to confirm. Without connecting that node, moving is 2 tap and shooting doesn’t work at all.

Hmm, ok. Thanks for doing the testing. I did some limited mobile testing not that long ago that seemed to work fine, but something might have gone wrong. Do you get the same problem when just running the example map on an unmodified project? The idea for the hover events with touch is that one tap shows what would be shown when hovering over a tile with the mouse, while a second tap on the same tile will activate the click event.

Seems like basically all the issues you are having are related to changes I made in the last, big update. A bit annoying that these bugs were not discovered until now when I have so little time, but better late than never, I guess. Sorry for the hassle it is causing you. I’ll do my best to get this fixed as soon as I can find the time.

@Juxtapox

I bought this pack a long time ago. Decided to look into it now. Is any starting tutorial even worth watching? It says in the first video that I should use grid manager, but then an annotation that it is now split up. How do I get started? Do I even use the grid manager anymore? And how do I use BP_Unit now which seems like the general unit placement actor instead of the various different pawn actors? So many questions and while not sure what information is outdated.

It’d be nice to just have a simple short setup video that tells you what assets to use and how, or even some documentation even.

Unfortunately several of the tutorials are indeed quite out of date; the early ones much more so than the later ones. A lot of the same functionality still exists, but it has been organized differently which can make it confusing to developers who are new to the toolkit. I apologize for the early tutorials being so out of date and creating a new tutorial for beginners is one of my highest priorities for the toolkit right now. Unfortunately due to work I will not have the free time to do so for a couple more weeks, but after that things should get better. Until then feel free to ask me here if you run into any problems.

For your specific questions, BP_Unit is now a base unit blueprint which does not have any animation, health bar etc. It basically holds all the shared functionality of a unit besides what is displayed on the screen (meshes, animations, health bars etc.). BP_Unit_Anim is an example for how to set up a unit with a skeletal mesh and animations and is what I recommend as the starting point for making your own units. If you want the same sorts of units that were in the first video (an enemy ranged unit, player melee unit etc.) you can create child blueprints of this blueprint and change their faction variable, material, range and health.

As for the grid manager you can find BP_GridManager in Core/Grid. If you want a hexagonal grid you should instead use BP_GridManager_Hex.

@Snowynight

Hey, Thanks for replying and you help. I fix the error; It was because I was activating BP_ATBTT after completing the loop to spawn them all. For some reason it did not like that, my best guess it has something to do with me using the convert to index to location native. But I don’t know; It works now though that I activate it before looping the spawning units.

Ok, great. Makes sense that that would fix it. The activation of BP_ATBTT basically starts the cascade that starts up everything, including spawning the turn manager, so if you are adding anything that needs immediate access to the turn manager, action manager, the filled in grid values of BP_GridManager etc. all of this needs to be done after that setup has run its course.

@Snowynight

So as for the tracking which unit kills which one. So what im trying to do is, When a unit kills another unit, I want it to remember which unit it killed. Then add xp to that unit and increase the trust var in all other units on the same team for after use to increase there bound, so they work better as a team. As well as remember which units were killed so it can remove them from my index ID array. I already have them all with IDs. Hope you can help, thank you for all your help. I hope you have a nice day.

Thanks You can store this in many different ways, and it is really up to you. But first you would need to be able to know when a unit dies what it was killed by. You could do this by adding a new BP_Unit input variable to the TakeDamage function in BP_Unit called DamageSource. Then in the same function if KillUnit is called you would call a new function on the source unit that takes as input the ID of the killed unit (do this directly before KillUnit is executed). In this new function you can add the id to an array or set of IDs + add XP. You would also modify the trust value here, though where this is stored and handled depends on how you intend trust to work mechanics wise.