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.
Unfortunately it didn’t.
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
Just trying to make something interesting :). It’s a shame you replied before my update, I didn’t notice that. I think you have an issue in those touch controls. I’ll repeat it here as I suspect you missed it
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.