Felicidades :j ! Te lo mereces.
Trying to figure out where the āPossible Moveā integer value is set for BP_Ability_MoveAttack. Iām having trouble getting the entirety of moveable tiles to show up as available to move to. Is there some math thatās producing this value? Where?
Ok, people. My PhD dissertation is handed in and my support should improve markedly from now on. I still have a lot of work that needs to be done that I pushed forward when working at my thesis, but Iāll still have a lot more free time. Beginning today Iāll again be giving more thorough support in this thread and will try to reply every day. Iāll also begin on a hotfix based on what has reported here the last weeks. In a couple of weeks Iāll start planning new tutorial videos. I intend to start by making updated versions of the basic tutorials, before handling some of the more advanced topics. Itās good to be back 
Hi Mars, the easiest way to do this is to change the places where the EndActiveActorTurn function is normally called to the EndEntireFactionTurn function (which is in BP_TurnManager). In the normal example map this is done in BP_PlayerController_ATBTT (at the right side of the WidgetInput comment box), in BP_Unit (right side of the Select Actor comment box), and in BP_MoveAttack (bottom right of the Click comment box). Hope that gives you the result you want.
Yeah, sorry I did not look through your post thoroughly enough and was less than clear. My point was not really whether the removal of the specific units was done before or after my sorting function, but rather that it would be more efficient to do it within the function. Like so:
Iām guessing that maybe you forgot to disable collision for the tree mesh so that it blocks line of sight?
Thanks! It took a while, but I got it done in the end. Feels good
Thanks 
It is set in the UpdateAbilities function in BP_Ability. A tip for finding out where functions or variables are used in UE4 is to right click them and select FindReferences. Then you click the little binoculars icon to search for them in all blueprints.
@crossmr: Your issues will take a bit longer to look into than the rest here, since it is pretty extensive. Iām on it, however. There is a lot of information to read through between your posts and PMs and youāve solved a lot of stuff on your own. Would it be possible to give a quick summary on what your outstanding issues are, and what issues you had but was able to fix? Iām going to figure this out anyway, but it will be quicker if you can put me on the right track to begin with.
Okay no problem.
-
Touch controls seem to be working fine now. The only issue I see is if you play zoomed out too far, the touch controls donāt seem very precise. Maybe just due to the size of human fingers. But zoom in a bit and theyāre totally accurate.
-
The multi-level mesh is totally fixed with the changes I made. Iāll still try to get you a copy so you can see the problem yourself.
-
The spline for the ladders is bugged, so that needs to be fixed. It only displays properly in the ladderās default rotation.
Things Iām hoping to work out:
-
The xcom shooting system. I think I can mostly do that myself, there are just 1 or 2 outstanding questions with that Iāll post as I go along.
a. As mentioned before, there is a bit of a complication based on that image I posted. There are 2 kinds of cover. Thin cover like a wall with a window you can look out of, and thick cover like a pillar or the corner of a build. On the first case, you should have a wide field of view, maybe 120 degrees from the point of the window itself (not the unit set back because traces will hit the wall around the window. For a pillar or corner of a building, you can really only trace straight ahead. However the issue lies with targets being in full cover. If theyāre in full cover, which they can peak around, then they should be targetable. If theyāre not, they shouldnāt. So in a scenario with 3 full cover tiles, A B A if the unit is behind either A they can should around the corners or be targeted, but if they are behind B, they shouldnāt be able to shoot around or be targeted from the other side. You could simply have full cover not block range, but then you run in to a scenario where units behind B can be targeted. Some kind of calculation needs to be set up to check if theyāre actually visible or not. I may be able to work that out. For the shooting unit Iāve got it worked out in my head, but the issue is the target. Iām struggling with how to return a fail if theyāre behind B, my best guess is this: All full cover doesnāt block range, but when a unit is returned a check is run: if the square beside the unit on the side the other unit can shoot from is also full cover then return no target. so in this case if a unit was in B and returned a target, it would then check to see oh, the attacking unit is on the right and that square is also full cover, so no target. -
Alternate win conditions (like bank robbers getting to an exit point)
-
Disabling units, as Iām doing cops and robbers, I may try and set up a system where the cops can āarrestā the robbers, which would essentially disable them. I donāt want to kill them, Maybe the best case scenario would be to remove all their non-movement abilities and give their movement a huge penalty (max 2 squares movement instead of 6). That way the robbers might still have a chance to escape for points if the cops completely ignore them or donāt guard them after arresting them.
-
Since this will be two player, I also need to work out vision cones and in multiplayer only show the units that can be seen to the other team. Can this be done with your tool set? In local multiplayer, Iāll pause the game between each turn and they can pass the phone to the other player who can push a button to play their turn. Maybeā¦ Iām still deciding on how to handle local multiplayer, but definitely want this for online multiplayer.
Thanks. For some reason when i was trying to find references, it wouldnāt allow me to. I think it was because I had the variable selected when trying to right click. Anyways, thanks, that helped alot. I think the problem actually was the way I set it up. Now Iāve got it working.
Couple things I noticed while playing around:
- When you set the Move amount higher than 1, (say 2 for example), it works fine initially, but after clicking on a tile like 2 tiles away (should amount to 1AP), it only allows you to move 4 more (I put a max and current AP of 4). This is using movement costs aquired from pathfinding. Especially with even numbers, I would think you would have 6 tiles left to move. Seems like the pay move cost associated with pathfinding doesnāt take into account the Move value of the unit? I did a test and divided the pathfinding cost by the Move value of the unit, and that did help. But I still got odd results. Same situation as before, with 4 AP, Move of 2, moving in 2 grid space increments, the last move (Fourth one) will not exist, even though I have 1 AP left (I also set the cost of the MoveAttack Ability to be 0). Iām not sure why.
- Diamond Shape Visibility doesnāt seem to be working for tile movement? Only way I could get diamond shape movement working was turning off diagonal movement in the grid manager. Itād be nice to be able to do the diamond shape movement, but still be able to move diagonally. I dont know if iām just setting it up wrong?
Thanks for the awesome toolkit!
Hiya, where did the āDisplay Path As Splineā setting go after the update? I want a single mesh to be displayed on each tile as in your tutorial video.
@ Thank you it work like a charm. I gona dive deeper on unreal and come back if you need help. Thankās again for your awesome toolkit.
Donāt see how my code could affect single digit touch precision. Might be the size of the finger, as you suggest.
Great, thanks. Iāll take a look when you send it over.
Checked it out. You need to do the same change to the event graph of the ladder as I suggested you do to the construction script:
https://i.imgur.com/QlaA7kn.png
Things Iām hoping to work out:
Perhaps you can play around with collision boxes here? You could maybe have two kinds of collision boxes for buildings. One that covers the entire building and blocks CoverTrace and one that blocks everything except the corners that blocks RangeTrace. Think something like that should work for your use case?
Making win conditions easier to modify is on my to-do list. I think setting the bGameOver in BP_TurnManger to true and ending the active unitās turn should get you most of the way, though. You could consider using the GridObjects map in BP_GridManager for your exit points. Make an exit point blueprint (Based on BP_GridActor) that adds itself to the grid through the AddObjectToGrid function. Then you could bind the OnUnitEnterTileSimulate event dispatcher in BP_GridManager to calling the InteractWithObjects function. This will now call that function whenever a unit enters any tile. This will call the Interact interface function on any object in the GridObjects map on that tile. For your exit point blueprint you would add BPI_Interact and define the Interact function as setting GameOver to true and ending the active unitsā turn. I think something like that should work. I should really do a tutorial on the object system, by the way. Pretty powerful, but I havenāt really covered it. It is used in the 2D map for items and activating torches.
You could implement it with the status effect system, but if youāre not using a lot of status effects it is probably easier just to add a bDisabled boolean to your units. You can check this when the unit is activated to prevent certain abilities from being selectable and setting CurrentMove to a low number when it activates.
Check out the fog of war stuff in the 2D example. That is pretty similar to this. Though if you do not need to actually hide tiles, but just units it can be done simpler. You could basically run line traces to all enemy units at the end of a unitās movement (or maybe for each animated movement step) and hide/unhide the actors on the client.
Hmm yeah some of the movement stuff in the abilities is coded a bit awkwardly at the moment. The way things are currently set up, move range is by default equal to current action points * move range - ability point cost of the ability. This seems to work fine for move range (where you would put the cost to 0, as you rather use the movement cost functions). If you have set up to have 4AP and a move of 2 and set move cost to be defined by the pathfinding cost, if you move 2 that will subtract 2 action points, cutting down your following move range by 4 (2 AP cost * 2 move per AP). You had the right idea to divide the cost to get your desired result. Not sure if what youāre seeing in the end is really a bug, though. You have split things up so that moving 1 or 2 tiles costs 1 AP, so if you have AP of 8 you can move 8 tiles if you move in even increments and less if you move in odd increments. Why donāt you instead use a move of 1 and 8 AP?
Thanks for the awesome toolkit!
[/QUOTE]
One way is to set PathfindingType of the unit no NoDiagonalMovement. But perhaps you want to enable diagonal movement, but have it cost 2 AP? In that case you have to modify the default edge cost generation. Here is what you need to add:
https://i.imgur.com/SB5KAOp.png
This is for a map with no heightmap. If youāre using heightmap you need to modify either AddTileEdgesOneLevelHeightmap or AddTileEdgesMultilevelHeightmap the same way.
It is now handled by the specific abilities instead of being one big global toggle. Check out the 2D game example and BP_Ability_2D for how to set it up (specifically the ClientDisplayPath function)
Happy to hear that!
Yes, Iām sure it is. Also the angle that you press the screen at Iām sure comes into effect. Iām not sure exactly how Unreal determines the exact point of contact. Itās obviously choosing a pixel perfect point, but I donāt know if it simply chooses a center based on your first contact with the screen or how that works. I do think one issue is the angle. since itās at a bit of an angle, the trace seems to go straight from your finger, and if you tap closer to the upper body of a unit, I think the trace can end up hitting the tiles directly behind the unit. So when tapping you have to be sure to target itās lower body and not around the middle/upper body. It may be possible to modify the touch controls to return a hit if it traces to the body of a unit or somethingā¦but those are all set no collision. Iām not sure whatās a better use scenario there. It might be somewhat intuitive for the player to think they can select a unit by tapping anywhere on that unit.
Thatās not a bad idea, on the surface it solves just about every issue except doors. As a door is a wall that can be changed. Iād have to find a way to return no hit while the door was closed. Are range traces done fresh every time? Could I have the door be a 3 tile piece, that has the two adjacent tiles set their range blocking on the fly? When itās open just set the two walls attached it to allow shots and then if the door is closed, set them to block range?
Iām not really expecting other status effects in this kind of game. So iāll look at that. How would the AI handle a unit that has no attack abilities? At some point I may have to start working on the AI as well to make it a little better and handle my specific scenarios (like encouraging robbers to escape and cops to arrest robbers)
Edit: Another thing Iām trying to address here is hiding move tiles on floors above the floor Iām on. To make it easier to move around. So for example, in that convenience store building, if there is a ladder on the back and there is a unit near that, they can move around in the store but also up the ladder to the roof. The issue I have now is that moving to the roof is easy, but moving inside is a bit of a mess because the roof move tiles are on top of the inside move tiles. I already have some buttons on my UI for āchanging the floorā. what this does is change my path trace for hiding meshes between the camera and capsule. So by moving up a level it makes the building roof visible so itās easy to move around there without being distracted by the lower level stuff. Is there someway I can return the move square tiles and what properties are available for them? Can I get a Z height of all the tiles and then try to hide the ones that are āaboveā the current floor selection?
Hey, I got it to work, except it always displays from 0,0,0. It seems the AnchorOffset is always at that vector. Could it be that in BP_Ability_2D you get Revealed Grid Indexes from BP_Gridmanager_2D, but in BP_Ability_MoveAttack thereās no such thing? Because I notice you cast to it in the 2D example.
The AI loops through all its abilities and generates an estimated value for each. It chooses to use the one with the highest value, but if none have a value higher than 0 they just skip their turn. If they have no abilities they should just skip their turn.
The tiles in the included abilities are either instanced static meshes or decals. The ISMs are especially tricky to modify one at a time, but it can be done. You can loop through all instances and use GetInstanceTransform, removing or moving the ones over a certain height. You cannot just hide ISMs, though. One option is to have separate ISM components for each height level, so you can destroy/respawn all tiles at a certain level, but again you could not hide them and would have to store their locations somewhere so you could respawn them. It might be easier to switch to regular static meshes, which can be hidden. While spawning them you could populate a map with grid indexes as keys and static mesh references as values. That way you could look up their grid indexes and hide/reveal them as appropriate. All of these methods are a bit awkward, but it is the best I can think of at the moment.
Anchor offset should not affect it. That is just if you want to offset all tiles, which is currently only used for multi-tile units that have a center between tiles. Iām guessing youāre not passing the vector locations to the action properly. Not sure what could be wrong here. Could you screenshot your setup and post it here?
I started taking screenshotsā¦and noticed I had deleted 1 branchā¦ inserting it again made everything work. I wish the compile would sometimes notice these things kinda like missing a semicolon when coding
Sorry for your time , thanks for answering, and happy for you turning in your PhD!
Glad you fixed the problem, and thanks!
This worked great. Only problem is I have to modify the grid manager in core (or i could always create a duplicate). Iād like to be able to just create a child, and then override that function, but for some reason it does crazy things when I try that.
EDIT: Actually, just figured this out. I had to clear the local edges variable I was using (Because itās overriding a function that not does not end in a return node, it just creates an event in the event graph, so i canāt use local variables, so i had to create a new normal variable for it). Now it works perfect! Thanks for the info!
How can we control that? I have an aimed and snap shot. If they donāt move, they can aim and have a better hit chance, if they do they can move and snap shot with a lower hit percent.
Ok like I said in my previous message, it work but I noticed something.
If I move a unite and donāt attack or end my turn I can move others unit too.
What I want is if I take the decision to move a unite I canāt move other unit until my next turn even if I donāt attack or end my turn. Because I want player to be able to move only one unit by turn.
Thank you for you support.
The updated videos on the basic stuff would do me real goodā¦Yeah, like you said, I had to tweak collisions. Itās all very basic stuff Iām dealing with I think: now Iām trying to correctly make this child unit BP die; everything is working fine except the static mesh I added stays on the grid even after the unit dies and the tile is freed.
I canāt understand some aspects of the BP_Unit events. There is a āKill Unitā event, triggered from the Take Damage function, which I assumed is responsible for removing the unit from the game once itās dead. However, after debugging with breakpoints it seems it only is activated on the last kill before win/lose condition is achieved?
Itās so bizarre, since the Branch condition is a simple āif the unitās health is <= 0āā¦And yet the game only pauses at the breakpoint on the last kill of a faction unit, AFAIK.
Also, whatās a good debug way to find out what blueprint is calling another blueprintās events/functions? Print pins and breakpoints donāt allow you to see what came before them, and the Reference Viewer doesnt include references made outside the current BP.
Overriding functions in blueprints is a bit weird like that. Youāll notice that quite a few of my functions have a boolean output variable called bSuccess that isnāt really used. This is mainly so that child blueprints overriding this function will have it overridden as a function and not an event.
If youāre basing your abilities on BP_Ability_Laser the AI value calculation is largely based around hit percent chances. It loops through all tiles in move range and checks the hit chance to hit various enemies from each tile, as well as the chance of being hit from those units at each tile. You can add your hit chance modification into that code as well. The simplest way to do this is to modify the FindAbilitySpecificTileValueModifier function of Laser. Something like this should do the trick:
Iām assuming youāre basing the abilities of your units off BP_Ability_MoveAttack. The code for switching to another unit for this ability is held in the DefaultClick function of BP_Ability. You need to add a check here that prevents you from switching units if the current unit has already acted (which in the default toolkit means that it has less than its max AP). This should work:
Yep, I know updated videos are sorely needed. Iām planning to start working on that next weekend. The code for destroying units is a bit weird in the toolkit, and it is because of the action system and multiplayer. You donāt want to destroy a unit actor as part of the server side code, because all that stuff happens instantly, before animations are run. The units cannot be destroyed before all their animations have finished running. However, the unit still needs to be dead as far as the game logic is concerned, so it is removed from the GridUnits and InitiativeOrder arrays/maps (The RemoveUnitFromGame function).
Also, if the game is multiplayer we cannot simply destroy the unit immediately after the death animation is done playing on the server, as the clients might lag behind due to poor connections. Because of this a special action is called using the action system (called QueueDestroy). This action is run by the action manager, setting a life span to destroy the actor. This is by default set to 30 seconds, which should prevent issues for anything but the most extreme network issues. Iām not that happy with this hardcoded timer, though, and am currently working on a more flexible and intelligent solution to this particular problem.
Anyways, for your particular unit this means that you need to add functionality that hides it after it is killed, from the reference point of the client, but is still not destroyed, from the game logicās point of view. Check out BP_Unit_Anim and the AnimateDeath event where the health bar is hidden. You want to hide the unit mesh here as well.
Thats actually the only thing that is keeping me away from buying your toolkitā¦ videos are tooooo outfdated :eek: