[SUPPORT] Advanced Turn Based Tile Toolkit

Monokkel · January 19, 2019, 11:37pm

Sorry for the late answers, people. I’ll get to all of it now.

crossmr:

Right now I’m just sorting out the execution flow and how it may differ between the two abilities.

Touch Input->ClickAttempt->ServerConvertLocationToIndex->ServerInteract(FunctionCall)->ServerInteract which seems to be implemented on BP_Ability. As it both movesprint and the various shooting abilities have BP_Ability as their parent. With both abilities having BP as the parent, I’m a little confused as to why they behave differently (move as 1 touch shoot as 2 touch). I’ll keep digging in to those.

I’m going to try to adjust the camera glitchiness today where it sometimes refuses to pan or jumps around or at least see if I can figure out what is causing that.

There is one sort of large issue I did notice with the touch controls. The UI doesn’t block them. So if you fat finger your abilities, or click the information box, then you can accidentally click a move square. I’ll see if I can figure out how to block that from getting through to the grid.

Ok, that is good to know. Like I said I never had touch controls in mind when I designed the abilities for the advanced tactical map, so the cause could be any number of things. I’ll let you know when I have the time to check the touch controls.

crossmr:

The idea is that the camera follows the bullet to the target, from the snipers gun to wherever the target is. I have it called if the target would die from the damage received on the sniper ability that time. I’d like more ability to completely interrupt the ability, and I almost had it, but then it just refused to end the ability. On some moves I’d like to do a bit more cinematic camera work, but because of the decoupled system, I’m struggling to see where and how I can interrupt an ability. Obviously the best place to interrupt the ability is before the unit/animation is split. The problem I ran in to, is how to come back to the ability? I had it set up where in the shoot function, it would first calculate the random damage and compare it to the target’s current health. If it was going to kill the unit, then it would branch skip take damage but return a new bool “bTargetDead” which would be checked in the main event graph, which would then skip render beam and call a function on the gridcamera which would do the stuff I wanted, it would also pass a reference to itself (the ability) to the gridcamera, which, on finish, could turn around and call back to a function on the ability to call “end ability” (after calling take damage and queue action for the death at the right time). Sadly this didn’t work. The camera stuff worked, the unit died and animated at the proper time, but when the grid camera called back to the ability to run “end ability” nothing happened. The ability didn’t end, and I couldn’t move on to the next unit. You can see the sniper ability around 8:17 in the video I posted. He gets the kill shot on a unit and there is a bullet chase, but that’s not quite how I want it.

For the sniper ability, moving the camera from the sniper gun to the target fast enough can kind of get this in sync, but it’s faster than I’d like, and I can’t do any of the other camera stuff I wanted to do in this case. For other death camera sequences I had in mind, it isn’t as easy, unless I set it up so the camera ignores the target and focuses only on the unit initializing because I can control that easier. What I need is a way that I can pause/interrupt an ability for a special event (usually a camera and, but not always, animation sequence), then go back and end that ability when I’ve handled that. Calling a function on the camera, which called a function on the ability, really didn’t seem to work.

I think it should be fine to build it into the ability. One generic solution for jumping out of an execution chain to an arbitrary event graph and then jump back again to where you left off is to use an event dispatcher to bind the node that continues the execution of the ability, run your camera code, call the dispatcher, unbind the event and continue the execution chain.

crossmr:

I don’t recall this happening the first game. As I play more games against the AI, I’ll try and make notes on any odd AI behaviour I see like this.

Just played another game and mid-way through the game the same unit had issues. It ran around, took cover, fired a few times, but then at one point they were on the opposite side of a window with an enemy unit and had a chance to shot gun blast in the face and just ended their turn. Nothing to do with the window though, because other units had no issue, Right beside it was another unit in the same situation and it fired through just fine. I’ll see if I can debug and find something wrong with that particular unit. I thought I had cleaned up an errant collisions, etc on their components.

Edit: Regarding the unit giving up, part of it seems tied to the shotgun. Is there a trace done from the end of the gun when checking to shoot? I saw another unit with a shotgun also exhibit the same behaviour. In front of the window, another unit on the opposite side, they couldn’t shoot (they normally can there is no minimum range). They just skipped their turn. They didn’t even step back to fire. So i’m wondering if there is a trace done from muzzle or something that the AI is failing on because the shotgun muzzle would be in a different location. The gun is otherwise set no collision to avoid that issue I had before.

Hmm, not sure what the visibility thing could be. Visibility traces are always done from the same place, which is from the center of one tile to another at VisibilityTraceHeight (defined in the public variables of BP_GridManager). What you describe does indeed seem like the sort of discrepancy where the AI in the ability evaluation phase decides that a unit can be targeted, but when it actually attempts to do so it fails out. Not sure what would be causing this, however. You could try logging the values the AI stores in TargetIndex and MoveTarget index of the shotgun ability when AssessAbilityValue is called in BP_Ability and compare it to what happens on AiActivate for the specific ability. If you can consistently replicate the issue at the same point in the combat you can add a breakpoint that activates at that time and step through AiActivate to check what goes wrong at that point.

You can always add C++ code to a blueprint project. Just choose File and New C++ Class and you should be good to go.

Ah, dang. Seems there is still one more thing to change. Just as easy to fix, though. Go to the FindVisibleUnitsInRange function in BP_GridManager and attach the DiamondShaped input variable to the input of the two CheckIfTileIsVisibleFromOtherTile functions. That should do the trick.

Thanks! My deadline is approaching a bit quicker than what is ideal, but I’m positive I’ll make it.

Unfortunately that experimental way of displaying a movement frame did not pan out. The function in BP_Ability_MoveAttack is just one I have forgotten to delete. I still have many ideas for possible ways to implement movement frames, but this has been a feature that has been surprisingly tricky to find an ideal solution for. For my current best try check out the 2D example map, which uses a post process material to display the movement frame. Works well for flat maps, but gets pretty glitchy with height differences, unfortunately. I’m basically waiting for inspiration to strike to get this feature fully implemented.

Here is the link

crossmr:

So a bunch more testing here. I’ve been looking at the camera controls since yesterday. I’m not entirely sure what is causing the behaviour. Following the execution on this, everything seems to be plugged in correctly, and I can’t reliably reproduce the behaviour. It seems to happen most if I’m trying to scroll across a larger map quickly, but it also happens when I’m swiping slowly. Basically, you could describe it as rubber banding:

I touch in some direction to pan the camera, swipe across the screen, the camera moves, but when I let go, the camera jumps back to its starting location.

I thought this was a fast swiping issue, so I changed the pan speed to give more movement on swipe to make it less necessary to swipe rapidly to move a short distance, but even when I take a noticeable pause in between swipes, it will still jump like this. My best guess is that it is somehow misinterpreting some kind of swipe as a press or something.

It’s hard to debug this kind of stuff on the device itself. Especially when it can’t be reproduced accurately. Just a little testing that might help. I’m moving on to ability clicking and see if I can’t get anymore insight in to that.

Further testing of these three things:

1 - disconnecting tick as there is a comment saying it should be for tick
2 - checking the touch bool on click attempt
3 - hooking up the node on ability base

After experimenting with some combination of these three things, leaving tick and the ability base node connected and the bool checked gave the best results for controls in game.

Thanks for the detailed account of your testing. It will be helpful when I get around to fixing it. I’ll try to make it a priority to look at once my thesis is handed in since you’ve put so much work into this.

Hmm, very hard to know what is wrong without more specifics, unfortunately. If the issue is caused by your own changes it could be almost anything. Could you explain a bit more? What are the main differences between the two maps? Are you using the same abilities?