Announcement

Collapse
No announcement yet.

[SUPPORT] Advanced Turn Based Tile Toolkit

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

    Originally posted by crossmr View Post
    I'll attach an image showing my grid settings. The repro steps were to basically load this level, drag the grid manager in and that's it. The only changes that I've made have been the instructions you gave me for deducting the AP points, as well as the changes in the screenshot which I sort of copied from the jungle level. Other changes I've made have just been to create weapon abilities, update the health bar, some camera work to make certain objects disappear when they are in the way and that's about it thus far.

    A little more testing here, and it feels somewhat inconsistent? I'm attaching another video so you can see two of the same characters running between two squares. Also if you put two different copies of the same character in the same square they get different pathfinding results. The two photos are two different copies of the swat character both at the start of the game. if I put the shotgun FBI character in that spot, he can move normally to all adjacent squares.. that makes little to no sense. All of the character BPs are duplicates of each other with very little changed on them beyond the skeletal mesh, and some accessories for those that need them (the SWAT character has no accessories it's a single mesh, as is the FBI character, some of the robber characters have additional things like hair/masks/etc put on them).

    I've now tested all the characters in that spot from the police side and only SWAT are giving odd pathfinding on that square.

    After a little further testing, I seem to have solved this issue. This had something to do with their weapon. I have no idea why, it seems most prominent on those with assault rifles (also the robber with the AK-47) but setting the SM_Weapon to "no collision" suddenly allows them to move normally. Your code is quite deep with a lot of functions, so I'm still getting used to where everything is and how to find exactly where I can look to start debugging things, but my guess would be that whatever path trace is being done for the unit is somehow impacting the gun and reading as a wall or something like that. The collision isn't special, I've attached a screenshot of that. I'll just make sure all the weapons are set no collision from now on.


    Okay, that makes sense. The grid is generated using collision traces. Specifically PathTrace for finding tiles that can be walked on and WallTrace to check for walls between tiles that should block off walkability. If your unit meshes and weapons block these trace channels you will end up with some weird behavior, so make sure that PathTrace and WallTrace is only blocked when needed.



    Originally posted by crossmr View Post
    Yes that's what i was wondering thank you. So.. "run pathfinding" this is what is run when the game starts correct? If so, do I need to bother using the "add/remove edge" function? The door itself can trace as a wall, so if I rerun pathfinding, won't it just detect the wall between the tiles and break that connection? or is that a separate function?
    Sorry, I was unclear. RunPathfinding does not generate the edge map that holds which tiles can be moved between. This is done by the grid manager at startup. What I meant is that if you run pathfinding for a unit (which checks what tiles it can move to from a tile given its move range) it calculates this move range using the current state of the GridEdges TMap. So lets say a unit starts its turn next to a closed door and you run pathfinding to find what tiles it can move to. The door blocks pathfinding so no tiles in range will be displayed at the other side of the door. But now you open the door through a custom function (Using AddEdgeBothWays, lets say). Now the GridEdges TMap is updated, but since Pathfinding was run before this change happened the tiles on the other side of the door are still not reachable. For this the unit will need to run RunPathfinding again. Makes sense?

    Originally posted by crossmr View Post
    Could you expand a little on what exactly allows a tile to be placed? I did some realignment of my grid, but it just refuses to draw some tiles in places they should be allowed. This door for example. It seems like the gap between tiles didn't line up correctly here. So I took all the meshes involved in that door, as a test and set them no collision. It still wouldn't allow a tile to be drawn there. I even deleted all the involved meshes, leaving a perfectly open area, and it won't draw anything there. If I then move my mesh slightly which puts a gap right where the wall would have been, it suddenly draws tiles, but i have no idea why that is necessary. To the right of that room, it's drawing tiles no problem, out in the main area. I sort of get why it it might not want to lay a tile that is part way across the door, but I don't understand why it refuses to draw a tile when the door is completely deleted from the level.I've even tried sliding the wall back so that it's in a gap between two tiles and it won't work.

    I have the same issue at a second door, same mesh set, but a third door works just fine. So it isn't an issue with the door itself.
    Hmm, not 100% sure what is going on here, but I'll give you some pointers. At the start of the game the GridManager finds walkable tiles by firing PathTrace line traces down from the sky to the center of each potential tile (provided heightmap is set to true or multilevel). If this trace is blocked this location will be added to GridLocations. If heightmap is not set to multilevel it will stop here. If it is, the trace will continue down to check for potential new overlapping tiles below this location. After this is done the grid manager loops through all tiles and check the height between them. If it is bigger than HeightImpassableCutoff the connections between the two will be removed. After this, if TraceForWalls is set to true a line trace using the WallTrace channel will be fired between the center of each tile and the center of its neighbors. If this trace is blocked the edge between them will also be removed.

    For your doorway I'm guessing that the top of your door frame is blocking PathTrace causing the grid manager to add the top of the door frame as a tile that can be moved to. If heightmap is not multi-level in your game this is enough to cause the tile below the door frame to not be added. The tile on top of the door frame meanwhile is too high up compared to the surrounding tiles to be connected to them. If you are using multilevel heightmap I'm guessing that the height of your door frame is too small to allow a tile within it.

    I suggest going through all the meshes in your map and making sure only things that should be walked on top of block PathTrace and only things that should block movement between two adjacent tiles blocks WallTrace. Do this and check if it solves all your walkability problems. During the same pass check that only meshes that should block line of sight block RangeTrace and only meshes that should provide cover block CoverTrace. See if this fixes your problems.

    Love the look of your game, by the way. Let me know if you have a Twitter, website or something to follow its development
    The Advanced Turn Based Tile Toolkit (Marketplace page - Feedback thread)

    Comment


      Need help? Trying to get them to spawn on the grid when loaded a battle level.
      Click image for larger version  Name:	J1.jpg Views:	1 Size:	268.8 KB ID:	1571372
      Last edited by Snowynight; 01-11-2019, 04:19 PM.

      Comment


        Hmm, not 100% sure what is going on here, but I'll give you some pointers. At the start of the game the GridManager finds walkable tiles by firing PathTrace line traces down from the sky to the center of each potential tile (provided heightmap is set to true or multilevel). If this trace is blocked this location will be added to GridLocations. If heightmap is not set to multilevel it will stop here. If it is, the trace will continue down to check for potential new overlapping tiles below this location. After this is done the grid manager loops through all tiles and check the height between them. If it is bigger than HeightImpassableCutoff the connections between the two will be removed. After this, if TraceForWalls is set to true a line trace using the WallTrace channel will be fired between the center of each tile and the center of its neighbors. If this trace is blocked the edge between them will also be removed.

        For your doorway I'm guessing that the top of your door frame is blocking PathTrace causing the grid manager to add the top of the door frame as a tile that can be moved to. If heightmap is not multi-level in your game this is enough to cause the tile below the door frame to not be added. The tile on top of the door frame meanwhile is too high up compared to the surrounding tiles to be connected to them. If you are using multilevel heightmap I'm guessing that the height of your door frame is too small to allow a tile within it.

        I suggest going through all the meshes in your map and making sure only things that should be walked on top of block PathTrace and only things that should block movement between two adjacent tiles blocks WallTrace. Do this and check if it solves all your walkability problems. During the same pass check that only meshes that should block line of sight block RangeTrace and only meshes that should provide cover block CoverTrace. See if this fixes your problems.
        Okay, this was very strange. You can see my settings in an earlier post. Somehow, a window or window frame that was easily, 600 units above that tile was somehow blocking it. I had to go up 2 floors worth of stuff and change collisions. That should have been well within the bounds that would have allowed a tile to be generated. Oddly it isn't even the floor above that is causing an issue..its' the floor 2 floors above that is. This change also fixes some of the the other doors I was having issues with. I'll spend some time cleaning up all the meshes, at this point I was just trying to get a grasp on how all the things worked so that I knew what I could do.

        Thanks for the detailed explanation.

        I'm glad it's fixed, but I'm a bit bothered that it's not exactly clear why it wasn't working. My minimum height distance is only 200 but these walls are 300 tall. While the higher walls were blocking path trace, I feel like they should not have actually interfered with the floors below.

        Love the look of your game, by the way. Let me know if you have a Twitter, website or something to follow its development
        Thanks, I'll be posting some stuff about the game on Facebook


        follow up question here, is it possible to rotate the ladder? I'm trying to place it in game, and on one side of a tile, at it's default rotation it works fine (sort of) but on another side of the tile, rotated 90 on Z, it won't make any connection. On the rotation that it does work on, it behaves oddly as you can see in the pictures. It works, but the spline is strange. Rotated ladder is last, you see it won't make the connection there, or anywhere else

        Is the animbp something that gets cached somewhere for each unit on game start? I'm setting up a weapon switch ability that involves changing the BP (pistol to rifle, they don't have the same pose), so I need to change the animBP on the fly. I created a function on BP unit that takes in an anim class from my weapon switch ability, and override that on my pawn. It simply references the mesh and assigns the new class that is passed from the ability. Upon activating the ability, everything appears fine the unit seems to be using the idle animation from the new BP, but after that, nothing works. If I try to move, it gets no speed reference from the unit. If i try to fire, it gets nothing. I already have it set up so that it refreshes the weapon abilities and the UI to display them. If I otherwise start the game with that animbp set, it works fine, in fact I'm using it on the other pistol wielding pawns right now. It's not acting as it should, so I just want to check if there is some hidden node also tied in to this that I'm not aware of. As a point of testing, if I start with the rifle ABP and switch to the pistol and back to the rifle, the rifle also stops working properly. it idles, but when I move, it no longer gets speed or any other player state info
        Attached Files
        Last edited by crossmr; 01-12-2019, 10:40 AM.

        Comment


          Originally posted by Snowynight View Post
          Need help? Trying to get them to spawn on the grid when loaded a battle level.
          Click image for larger version Name:	J1.jpg Views:	1 Size:	268.8 KB ID:	1571372
          From the error it seems like the Turn Manager has not loaded yet. You're probably spawning these units at the first tick, right?Try delaying for 2 ticks before spawning and see if it helps.

          Originally posted by crossmr View Post

          Okay, this was very strange. You can see my settings in an earlier post. Somehow, a window or window frame that was easily, 600 units above that tile was somehow blocking it. I had to go up 2 floors worth of stuff and change collisions. That should have been well within the bounds that would have allowed a tile to be generated. Oddly it isn't even the floor above that is causing an issue..its' the floor 2 floors above that is. This change also fixes some of the the other doors I was having issues with. I'll spend some time cleaning up all the meshes, at this point I was just trying to get a grasp on how all the things worked so that I knew what I could do.

          Thanks for the detailed explanation.

          I'm glad it's fixed, but I'm a bit bothered that it's not exactly clear why it wasn't working. My minimum height distance is only 200 but these walls are 300 tall. While the higher walls were blocking path trace, I feel like they should not have actually interfered with the floors below.
          Well, if you are using multi-level grids there is one more factor to take into consideration. After the trace hits something blocking PathTrace that might potentially be a new tile it will trace directly upwards for HeightBetweenLevels UnrealUnits. If this is blocked the tile is not added as there is not enough clearing. I'm guessing the distance from the bottom of the doorway to the bottom of the door frame is less than this?


          Originally posted by crossmr View Post
          Thanks, I'll be posting some stuff about the game on Facebook
          Thanks, following

          Originally posted by crossmr View Post
          follow up question here, is it possible to rotate the ladder? I'm trying to place it in game, and on one side of a tile, at it's default rotation it works fine (sort of) but on another side of the tile, rotated 90 on Z, it won't make any connection. On the rotation that it does work on, it behaves oddly as you can see in the pictures. It works, but the spline is strange. Rotated ladder is last, you see it won't make the connection there, or anywhere else
          Should work in principle. I built it with this in mind. The ladder is basically just using AddEdgeBetween tiles. It is in the experimental map for a reason, though. I've only done limited testing.There is a public vector widget that needs to be placed over wherever the tile the ladder leads up to is. This needs to be on the correct side of the ladder also.

          Originally posted by crossmr View Post
          Is the animbp something that gets cached somewhere for each unit on game start? I'm setting up a weapon switch ability that involves changing the BP (pistol to rifle, they don't have the same pose), so I need to change the animBP on the fly. I created a function on BP unit that takes in an anim class from my weapon switch ability, and override that on my pawn. It simply references the mesh and assigns the new class that is passed from the ability. Upon activating the ability, everything appears fine the unit seems to be using the idle animation from the new BP, but after that, nothing works. If I try to move, it gets no speed reference from the unit. If i try to fire, it gets nothing. I already have it set up so that it refreshes the weapon abilities and the UI to display them. If I otherwise start the game with that animbp set, it works fine, in fact I'm using it on the other pistol wielding pawns right now. It's not acting as it should, so I just want to check if there is some hidden node also tied in to this that I'm not aware of. As a point of testing, if I start with the rifle ABP and switch to the pistol and back to the rifle, the rifle also stops working properly. it idles, but when I move, it no longer gets speed or any other player state info
          The animation blueprint reference is set up at begin play in BP_Unit_Anim
          The Advanced Turn Based Tile Toolkit (Marketplace page - Feedback thread)

          Comment



            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.

            [QUOTE="Monokkel;n1571701"]

            From the error, it seems like the Turn Manager has not loaded yet. You're probably spawning these units at the first tick, right? Try delaying for two before spawning and see if it helps.

            Last edited by Snowynight; 01-13-2019, 06:48 PM.

            Comment


              Well, if you are using multi-level grids there is one more factor to take into consideration. After the trace hits something blocking PathTrace that might potentially be a new tile it will trace directly upwards for HeightBetweenLevels UnrealUnits. If this is blocked the tile is not added as there is not enough clearing. I'm guessing the distance from the bottom of the doorway to the bottom of the door frame is less than this?
              Maybe, I'll have to keep testing and see if I can figure out exactly what was causing this behaviour.

              Should work in principle. I built it with this in mind. The ladder is basically just using AddEdgeBetween tiles. It is in the experimental map for a reason, though. I've only done limited testing.There is a public vector widget that needs to be placed over wherever the tile the ladder leads up to is. This needs to be on the correct side of the ladder also.
              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.

              The animation blueprint reference is set up at begin play in BP_Unit_Anim
              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.

              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:

              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

              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.

              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.

              Attached Files
              Last edited by crossmr; 01-13-2019, 01:16 AM.

              Comment


                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.

                Further Edit here: 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.
                Last edited by crossmr; 01-13-2019, 08:51 PM.

                Comment


                  Originally posted by Snowynight View Post
                  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.
                  Originally posted by crossmr View Post
                  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.

                  Originally posted by crossmr View Post
                  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.

                  Originally posted by crossmr View Post
                  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.

                  Originally posted by crossmr View Post
                  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.

                  Originally posted by crossmr View Post
                  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.

                  Originally posted by crossmr View Post
                  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.

                  Originally posted by crossmr View Post
                  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?

                  Originally posted by crossmr View Post
                  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.
                  The Advanced Turn Based Tile Toolkit (Marketplace page - Feedback thread)

                  Comment


                    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.
                    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.

                    Do the change I recommended above and see if this fixes any of your issues.
                    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.
                    Unfortunately it didn't.

                    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?
                    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

                    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.
                    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.
                    Attached Files
                    Last edited by crossmr; 01-14-2019, 09:22 AM.

                    Comment


                      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.

                      Comment


                        Originally posted by Monokkel View Post

                        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.
                        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.

                        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.

                        Comment


                          Originally posted by crossmr View Post
                          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.

                          Originally posted by crossmr View Post
                          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.

                          Originally posted by crossmr View Post
                          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.

                          Originally posted by Juxtapox View Post
                          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.

                          Originally posted by Snowynight View Post
                          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.

                          Originally posted by Snowynight View Post
                          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.
                          The Advanced Turn Based Tile Toolkit (Marketplace page - Feedback thread)

                          Comment


                            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.
                            Okay, I'll try making a new project when I get a chance and test it with the default stuff and see what happens. It could be the meshes themselves causing the issue or something else.

                            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.
                            Something I'll test when I get a chance to make a blank project. I think the controls are pretty close with those two changes, if you have any quick thoughts on what might differentiate moving and shooting, I can try and dig into that specific spot, I think it's the server interact that handles passing the input into BP_ability right? And that's where they all get it?

                            Unfortunately I've found a new issue last night, and it's a doozy. I'm not sure if it's related to your toolkit or not.

                            As you know I'd built my app for android, several times in fact and it works fine, but I wanted to add a menu. The first issue i had was that I had a couple levels (from content packs) with the same name in multiple folders, so I needed to give my level a unique name. I changed the name from demonstration->heistdemonstration and then created a simple menu level called "menu", updated all the references, changed my settings to make sure to package the two levels and built it. When I loaded it on android it was complaining that it couldn't find the level "demonstration" in the command line. it would ask if I wanted to load the default level, and on doing so would load the menu which would work fine and the game could start and everything worked perfectly except that pop-up. I spent hours digging through the settings make sure there was no reference to the old name anywhere, and there isn't. Finally I gave up, and changed the name of the other levels, and then I renamed the new level back to demonstration and built that. However, when I run that on android, it completely ignores the project settings which say to load menu as the default map and it loads directly in to the game level. I've never seen anything like this and have spent about 3 hours completely tearing the settings apart. It's like the project is somehow hardcoded to load that level first no matter what, but "menu" is set in the .ini settings and in the project editor as the default map, and it's included in the build. Is there any way this could be remotely related to your toolkit itself? I can't imagine how, but I just wanted to make sure there isn't some setting in the gamemode or something that would try to override things.

                            I finally solved this, leaving this here in case anyone else has a similar problem. I was building the game as a development build. As a shipping build this works as intended. I have previously built windows games as development builds and not run into this problem.

                            I finally got a chance to test the controls on a variety of android phones today here are my observations:

                            Only basically every phone (including my own) the first character to move has some issues. I'm not sure why. But it needs some additional tapping and fussing. After that, any other characters move on a single touch.

                            There are some slightly camera/hover issues with the weapon abilities based on laser. they work, and they're functional, but if you click the weapon ability and click the target, it highlights for a moment but then the target symbol jumps to another spot on the map, however tapping the target once (followed by a target symbol jump) and tapping the same target again does allow the unit to fire. As well when sliding the camera around, it sometimes jumps a bit back to where it is, this can be solved by rotating

                            So my verdict is: the controls are functional, but glitchy. They're at least sufficient with the changes I made above (ticking the bool and connecting that one node) to be functional for testing purposes. I played out a whole game using them and it was fine, with the mildest of frustration. So I'm going to focus on other aspects of the game (like my roof snap issue), if you expect that you may get to the controls in a couple weeks or so. As you are much more familiar with all the guts of this I'll wait for your more detailed checking and feedback on it before I get to it. If I managed to clear everything else that I need to do before you get to it, I'll try to look at it more in detail.

                            Side note on the roof issue: even removing the ladder so that there is no path to the lower levels, still has the cursor unable to snap to those roof tiles. I also note that for your test, you're using BSP aren't you? and not static meshes? the first layer is also BSP or is that from the grid itself?

                            I finally got a clean project made, I can't replicate it there either. At least not on the first pass. That's very strange..

                            I took the jungle map, and just extended the grid a little, and migrated a piece of floor over from the other project, put 3 on top of each other with ladders, and it works okay. Something else must be causing the issue. I assume the grid that is used on the jungle map is stock? it hasn't been modified in any way? To my recollection I haven't modified anything on the grid beyond the settings I showed you. So no changing code or anything like that. Only camera stuff to add pitch, and allow me to use the middle mouse button to rotate and pitch.


                            I've rechecked all meshes involved and can't find any unusual collision settings or anything else. Later I'll try reapplying a grid to a fresh copy of this map and see what happens. Not a huge deal, but I'd like to make sure I have complete coverage

                            So, I just had a test with the default project. I loaded this demo map (it's included with the asset pack), and after dropped in an advanced grid, setting it multilevel and changing the height to 2000, I am noticing exactly the same issue as before. So it isn't any change I made. It's some kind of conflict between the grid system and these assets. I know you're busy, but if you have time later let me know and I'll share some pieces with you so you can check it if you want.

                            Attached a screenshot. Completely fresh project, just imported the map, dragged the grid in, height set to 2000 set to multilevel, appropriate boxes checked (Same as jungle) then dragged a unit up to the top. Then, just for testing, I dragged a copy of all 3 floors over to the right, to make sure no other meshes were involved, and as you can see, even though those lower levels can't even be navigated, at all, the cursor is snapped down.

                            I do notice that with some mad clicking, about every 20 clicks or so, I can somehow get the click to register on the upper floor and he moves to a tile there. But there is no way for me to actually get the cursor to actually hover over one of those upper tiles, so it confirms the tiles are working, and this is a cursor/hover/snapping issue. Why it doesn't show up on your map, or the jungle map, I'm not sure.

                            Breakthrough: This might have something to do with the thickness of those roof meshes. They're incredibly thick. I just deleted the upper one, and dragged up a copy of the second floor to the height of 600, and voila I can path to it. More experimenting to be done. it looks like the mesh is around 100 units thick. I'm not really sure why that should be important, but maybe that tells you something. I tried making a new collision mesh on it that was a thin slab rather than a big thick one, but that didn't help.

                            A little more testing: I first changed the mesh to be thickness 7 (same as the below floor) but at height 85 so that it lined up with the top of the actual mesh. It did not work when there was another floor below.

                            I then changed it to be height 0 on the staticmesh itself so that the collision mesh was hidden in the bottom of the mesh, and voila, I can't see the grid, but my guy can run around (waist deep) in that mesh. There is is some kind of issue with the following scenario:

                            0 (7 unit thick collision)
                            300 (7 unit thick collision)
                            600 (100 unit thick collision)

                            that top collision is now up around 700 actually. So when I was putting it up 725, that was actually 825. So collision mesh tops were at 0, 300, 700.

                            Further testing: I made a copy of the red floor below, and on that copy changed the collision mesh to be 100 thick, even with that, the unit can path to it just fine..so it's not even an issue of the collision? It's almost like it's something inherent to that mesh itself. Which.. seems very strange. I even removed the collision on it and made a custom one, so not an issue with some premade collision.

                            If you give me an email address, I'll give you this static mesh, maybe you can try it out and see if it behaves strangely for you as well.

                            Just started working on a sniper kill cam, this is.. unfortunately not an easy endeavor due to the ways that animation and unit handling are setup. Because they're separated, you need to interrupt the normal process in more than one place. The shoot function calls a take damage, which kills the unit and kicks off the death action, but the damage is still passed through another queue as part of the "hurt" option, I guess. Because completely disconnecting take damage in the shoot function still results in the character running the dying animation when they are hit for enough damage. if I zoom fast enough, it's not that noticeable, but it seems like doing it properly would involve quite an in-depth rewiring of multiple parts. It's not a bad idea to separate those, but it makes certain kinds of things, like x-com style camera work, really difficult because you need much more precise control over the target's dying animation in these cases. I've got the sniper done, but I think I might have to alter my plans for other kinds of kill cams. This is just more of a head's up note for anyone wanting to do something similar, they should know what they're getting in to
                            Attached Files
                            Last edited by crossmr; 01-15-2019, 09:07 PM.

                            Comment


                              Originally posted by Monokkel View Post

                              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.



                              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.
                              I am so happy, It works beautifully. Thank you so much for your time and all the help.

                              Comment


                                Hi, bought the toolkit some time ago and I have been struggling to get Fire Emblem-esque bow range working, but when I give my unit Range of 2 and minimum range of 2 with with diamond shaped vision turned on, I don't get any diagonal tiles. Is this a bug in the toolkit or have I missed some functionalities in the toolkit and how can I fix it?

                                Comment

                                Working...
                                X