I mean of course, sorry for not giving it in the first place. Also sorry for a whiny post. [Here]](Player Death =/= Game Over posted by anonymous | blueprintUE | PasteBin For Unreal Engine) is a super simplified version of the execute ability system I run. The real version has some stat checks and only single Queue Action is in for each loop that will determine which units will attack and their damage, but those aren’t necessary to reproduce the bug. The paste I provided is for BP_Ability_MoveAttack, but the same bug can be reproduced on BP_Ability_Attack. I am running UE version of 4.21.2 and I use square grids if that is a necessary info for you. Here are the steps to reproduce:
Obviously, copy the execute ability stuff.
Put one unit for each team on a grid. Increase the damage of both units to 50, so the initiating unit can die to the second attack.
Attack with player unit. When player unit dies, the game doesn’t go to game over screen, instead the enemy gets to do a turn. The game over screen spawns after enemy has ended their turn.
You can also see that it doesn’t happen to the enemy faction for some reason. Let the enemy unit engage in battle instead and die to player’s second attack and the game over screen will spawn instantly.
Hmm, you’re right to be confused. Something weird is happening here that I’m not quite seeing. The CheckIfGameOver event is run the same on both AI and player turns, but for some reason GameOver seems to be set to true after the AI has already been selected for its next turn… My guess is that one of the tick delay nodes added for AI optimization is the culprit, though I’m not 100% certain. Probably an obvious answer here somewhere, and I’ll let you know if I see it. It seems to work fine for the regular toolkit, though I still want to understand what is happening here. For your project here is a quick workaround that will ensure the same behavior for both players and AI. In the EventGraph of BP_TurnManager in the “Begin Actor Turn” comment box, replace the boolean that checks the value of game over to the full game over evaluation function, like so:
Ok, two new tutorials are up. These are the first two of a series where I delve into the underlying data structures of the grid. I’ve tried to find a good balance of theory and practical examples and hope many of you will find it useful. Making these videos are a necessary foundation for making videos on more advanced aspects of the toolkit, such as big units. Coming up next after the two I’ve made now will be videos on pathfinding and modifying the walkability of the grid during runtime. I likely won’t have time for this until next month, though. A month from now I will be defending my PhD thesis, so I have to spend most of my time until then in preparation. After that I will get a lot more free time again, and intend to make several new videos.
Hi . Really appreciate the new tutorials, I’ll be sure check them out tomorrow!
I got hopefully a small and simple question this time. I got a bit stuck on figuring out which blueprint handles the unit switching? (Clicking on allied unit to take a control of it instead of the one you are currently controlling.) I have to activate something whenever that gets activated, but finding it has been somewhat tricky.
Sorry for the almost daily questions, I’ll try to slow my pace down… Good luck with your thesis!
All clicking is handled by the player controller through the curently active abitlity. By default the abilities that have unit switching enabled call the “DefaultClick” event from BP_Ability. Check the bottom right of the Click comment box in BP_Ability_MoveAttack for an example of the implementation. The DefaultClick function is probably a good place for you to add your custom code.
New Kickstarter is up for Grand Guilds! It is a fantastic looking game combining turn based strategy and card game mechanics The game was made with the help of this toolkit so I’d love to see it succeed! They had an earlier Kickstarter that did not reach its target but they’ve made a lot of improvements since then and just a few hours into the campaign it is already more than halfway to its target. If you back during the first 24 hours you can get into the cheaper "early bird tiers. Take a look!
Hey Kon, sorry about skipping your question earlier. For someone’s first post Epic usually take a while to approve it, to prevent spam, so it did not show up for me until now.
Interesting question, though. In your case you basically have two different grids, where one is overlaying the other. One way to do this would be to make a separate GridEdges TMap for large units, which connects 1/4 of tiles to each other. That is probably the most efficient and clean way of doing things, but it would require running an additional, modified version of the GenerateGridEdges function at startup. In this function you would loop through the GridLocations keys, but skip any tile that is not in the “upper left” of your 2*2 tile sets. You could create this rule by checking the GridIndex and only adding edges for tiles where both GetX and GetY for that GridIndex is an even number.
Now for each of these filtered out tiles you would connect them to all surrounding 22 tiles. This would mean using AddEdgeBothWays to [CurrentTile - 1998], [CurrentTile - 2000] … -2002, +2, +2002, +2000, +1998, -2]. The trickiest part would be making a modified function for removing edges that are blocked by terrain. This might involve something like using the regular TraceForWalls implementation, but changing from a line trace for walls to a box or sphere trace (maybe the size of a tile), where the start and end locations of each trace is shifted by +100,+100,0] to trace between the centers of your 22 tile clusters.
Lastly you would have to make a modified custom pathfinding function. You could modify the SearchAndAddAdjacentTilesBig function so that it uses your new custom GridEdges TMap instead of the regular one.
Off the top of my head this is what I think I would do in your situation. There might be a solution that is simpler to implement where you can hack the SearchAndAddAdjacentTiles function to search for all tiles as usual, but only return the relevant ones, but I’m not able to think of a way right now. It would in any case be less performant.
Thank you, that’s very kind of you to help!
A quick question: in the new version, do we still have camera bounds to restrict the panning and edge scrolling?
Dear ,
Good day! Do not worry about the missed message, everything is fine!
Thank you so much! I did it, it works!
This is incredible, without your clues, I would spend much more time.
The more I dive into the toolkit, the more I understand how much work has been done. This is amazing. Thanks again, and when the time comes, I hope we can surprise you with our game!
:o
Is there a way to give specific tiles different attributes? Like if I wanted to set a tile on fire to make it do damage if walked through and give the unit a status effect of “on fire”?
That is not included in the latest version. I have not added it back since I did the major refactoring. I will put it on my list. Adding it is pretty simple, though. You can check the location of relative to some bounds defined by variables, or if it is no longer overlapping a defined boundry. Add a branch in the camera movement code that prevents it from executing if the resulting new location does not confirm to these bounds.
Great! I was unsure if my reply was detailed enough, but I’m glad it worked! This toolkit has been in continuous development for almost five years at this point, so I’m happy it shows that I’ve put work into it
Sure, that is certainly possible. The way I would do it is to leverage the object system. You can see this in use in the 2D game example for picking up items, opening doors and activation switches. You could modify the SimulateMove function in a Unit child blueprint so that it calls the InteractWithObjects function in BP_GridManager every time it takes a step. You would have stored the object in question (your burning tiles) at the appropriate tile in the GridObjects TMap using the AddObjectToGrid function in the GridManager.
In your burning floor actor you would add the BPI_Interact interface and add an EventInteract interface event (again, check the items in the 2D map for examples). In this code you would then add the status effect to the unit passing through it. The trickiest part is getting the action system to display the burning effect at the appropriate time. You could perhaps do this by checking for collision with the flame object during animated movement.
Okay so I think this problem is more of a me being a newbie on UE/coding in general, so this might be a wrong place to ask this but here goes:
I’m trying to make a some form of battle forecast window. I have the necessary stats set up on my units, (And alternatively on my ability) but I have no idea how to get the stats to my widget. What are the first steps to achieve this? Like I said I’m aware that this might be more of a UE4 thingy than ATBTT, so I’ll do some research tomorrow and update if I manage to do that on my own.
You’re right that this is more of a general Unreal Engine question. I recommend looking up documentation and tutorials on blueprint communication. What you want here is to access unit blueprint references through your UI. One way to do this is to get the initiative order array from the TurnManager through the singleton interface added to the game state. So basically, get a reference to the game state in the UI, get the TurnManager from it and then get the initiative order array to access the units and get their stats.
I did a lot of experimentation last week on an overwatch ability and got something that worked okay. However, while doing so I found a better and more general solution for playing actions within other actions, that worked for overwatch as well as other features. However I struggled to get it working with networked multiplayer. I want to fix that before uploading the next update. However, as I’m defending my PhD thesis on the 8th next months I don’t have much time to develop before then. Therefore I have decided to simply upload the converted 4.21 project to Epic as the 4.22 update and add the new feature update as soon as it is done, which will hopefully be one or two weeks after my defense. Sorry about the delay, but life got in the way, and I don’t want to release a half-finished feature to the developers here which is likely to change drastically just a few weeks later.
More to come very soon.
Good luck with your thesis! 
