[SUPPORT] Advanced Turn Based Tile Toolkit

[Monokkel]

@Snowynight

It is set up to activate ATBTT after everything has spawned in the level. Tried delaying the activate of ATBTT but still the same error. Hope you can help and thank you for the replay.

Also, Im trying to figure a way to remember which unit kills wich units.

Hmm, I’m not able to replicate the issue you are having. Perhaps you are spawning the unit from an actor owned by the client and not the server? Not sure. Are you able to get the same error if you spawn the units from any of the default ATBTT actors? If so could you give me the exact steps of what you are doing so I can figure out what might be going wrong here?

There are several ways to go about remembering what units kill what units. What exactly do you need this for so I can narrow it down? In any case you’ll probably want unique unit IDs. Then you can have a new TMap in the game state and have the keys be the IDs of the killers and the values be the IDs of the unit killed by that unit? One possibility at least. Depends on what you’re after.

@crossmr

Maybe, I’ll have to keep testing and see if I can figure out exactly what was causing this behaviour.

Great if you do that. I did some testing and found a pretty serious issue with multi-level grids that might be causing this. It is easily fixed and was an oversight that is causing this in the newest version only (I think).

The multilevel heightmap generation has an issue where if it finds a new potential location, but that location does not have enough clearing above it to actually add a location it will stop and not continue searching for new potential levels below it. To fix this you must do the following:

Go to the CreateLocationsAndHeightmap function in BP_GridManager. In the second to last branch in the function (the one after the second line trace) the true output (signaling that the line trace checking for clearance above hits the roof) stops the execution of the function. Connect the True execute pin to the next branch in the function (second to last node). Do this change and see if it fixes your problem. I will add this change in my next hotfix.

@crossmr

That top node? Yes, I saw that, I’ll play with that and see if I can get it to work. Any idea why my spline is going through the wall, and yours went straight up the ladder like that?

I have got the ladder working now, I need to move and rotate only the static meshes, not the whole actor to make it work properly. The spline is still an issue though. It is not going up and down the ladder nicely like on the experimental level.

I checked out the ladder actor and confirmed that rotating the ladder does not work correctly. When tracing from the top location of the ladder I am only adjusting for the location of the ladder and not its rotation or scale, causing issues. Go to the construction script of BP_GA_Ladder and make the following change:

as for the display of the spline that is determined by the ability you are using for movement. In the experimental map the unit is using the BP_Ability_Move_Ex ability which has some custom functionality attached to its hover functionality that lets splines be displayed differently for ladders.

@crossmr

Thanks, with so many children of children it can be hard to find references to things.For anyone else wondering how to do this, you need to set the abp ref on the unit again, and on the animation blueprint you need to rerun the function to set the owning unit.

Yeah, unfortunately the toolkit might be teaching some bad coding habits in this regard. You generally want to keep your inheritance hierarchy as shallow as possible. However for my example map I need to make changes that do not alter the basic blueprints (which I want to keep as basic as possible). For people making their own game with ATBTT I always recommend making a duplicate (not child) of BP_Unit_Anim and use this as the base of their own units. If all units in your game use any advanced components add them directly to this new blueprint.

@crossmr

So doing some further testing on this multilevel business, and getting some additional weird behaviour. As you described before, you said that the trace starts in the sky and the first surface it hits, becomes the first level, and then it keeps tracing down and checks below that to add more levels. If my understanding of that is correct, it seems like the roof (so long as it is path traceable) should always be the first level. However, I’m not seeing that in game.

I’m attaching my multilevel settings here as well as a couple screenshots. As you can see I’m having issues on my roof. Some parts of the roof I can path too, other parts I can’t. The parts I can’t, have a floor nearby under them, but there are some issues with this:

Do the change I recommended above and see if this fixes any of your issues.

@crossmr

1. Shouldn’t the roof be set first as the level? If there was going to be a conflict with the roof and the level below it, I feel like it should be the roof that would work fine and not the level under it

Something like this used to be the case, though the opposite. In earlier versions I added levels according to whatever the traces hit. So if one tile on the ground had a bridge high above it and another ground tile had a tunnel below it, both the tile at the top of the bridge and the tile at ground level above the tunnel would be at level 2 while the tiles below then were at level 1. The traces discovered the tiles in the opposite direction of this, but I just changed how it was saved to keep it more intuitive. The way this was done was mostly a necessary hack to minimize the size of the arrays used for storing tile locations. Before I used arrays instead of TMaps and with arrays if you have an array with indexes 1, 2 and 3 and want to add index 1000 you have to add every index in between. With TMaps you just add the keys you need. When switching to this I no longer needed to consider this when assigning the levels of tiles and so I changed to a system in which the level of a tile is entirely determined by its distance from the origin of the grid manager, in much the same way as the X and Y indexes of tiles are determined. SO if your height between tiles is 200 then any tile with a Z location between 0 and 200 will have a height index of 0, between 200 and 300 an index of 1 etc.

@crossmr

2. My minimum height distance is 200, those two levels are more than 200 units apart. They really should be interfering at all with each other should they? I tried raising up the entire roof, and I had to actually raise the roof almost an entire other level worth of distance to get it to path onto the roof properly. Also I can’t reduce the minimum distance to anything less than 200 (not even 190) as doing some just has it stop drawing tiles on the roof entirely.

Check if this is fixed by the suggestion above.

@crossmr

3. It’s actually drawing tiles on the roof (unlike the issue I had before where it refused to draw the tiles) but the mouse will not select them. It jumps to the level below

Just to verify, I disabled my camera function that hides part of the building, and even with the interior tiles hidden, it still tries to path there rather than the roof (as you can see from the spline)

Another interesting point of note is that in the last picture where the spline runes over the skylight, those tiles can’t actually be pathed to normally, my mouse jumps to the lower level, but I’m able to run over those squares. I wonder if this is some kind of mouse issue, and not a grid issue.

Hmm, that is some strange bahavior. This might indeed be caused by issues with the hover events in BP_Ability_Base. I added a fix to a very similar issue in the last hotfix, but this might indicate that I did not eradicate the problem entirely. I’m not able to replicate the issue you’re having, though. After adding my fix if the problem persists can you try to give me the repro steps?

@crossmr

I finally got my prototype built for android. It runs pretty well, but… how are the touch controls set up. I’m not really familiar with this, but your video demo showed you double tapping. I’ve been double tapping till I’m blue in the face here, and I can’t get them to move. Single click abilities like shooting work fine, but using move sprint doesn’t seem to work.

I found out that my awesome health bars don’t work on android, so I’ll have to use an alternative for them. Other than that, everything seems to look good there.

Edit: Okay after messing around it almost seems like I have to press a square with one finger then try to get a second finger to touch on top of the same square. Does that make sense? it’s really awkward to move that way.

Heh, you’re really throwing every feature of the toolkit into a single project, aren’t you Well it is a good stress test to see if everything works together. I have actually not tested touch controls with multi-level grids yet and the ability system interface was not designed with touch in mind. As mentioned time is very short these days so I might not be able to do serious touch control testing until after I’ve handed in my PhD. If you do not find a fix I hope you’re okay with developing for PC for a couple more weeks until I get some free time again.