Hey all, sorry again for the slow support these days. It will get better fairly soon.
ok, great. thanks for the info.
Both of those are high on my list of things to delve into when time allows. Having the first tap count as hover and the second as click is indeed how I want it to work, and is how I set it up initially.
Best of luck, then! If you think of some clever solution to this be sure to let me know
If you donāt have too many abilities doing this manually for each is of course a possibility, even if it feel inelegant. If most of your abilities are just different kinds of firearms you could consider implementing this functionality in a parent gun ability and have the other weapons be children of this ability.
Does indeed sound like a discrepancy between what happens server side and what happens as part of the action system. Maybe a rounding error or something like that? You can try printing the values that are input to the code for animating units being hurt and changing the health bar and comparing it to the values being subtracted from CurrentHealth to see if there is a discrepancy.
As @crossmr said, the early tutorials are unfortunately quite dated. I plan to make new ones relatively soon, but I understand that this is of limited help if you need to implement stuff right now. There is no Heightmap Example map in the current version, but the underlying blueprints are still there. If you check the JungleRaid map in Maps/Advanced there are two platforms there that go translucent and become click-through when you zoom in. If this is what youāre after take a look at that map.
Looks neat!
Hmm, it should work in theory. This is basically what Iām doing in the menu in Maps/MP. If you just load a level it should work. Have you tested this with the included example map and get the same issue? Might you be changing the game mode or something like that? You can try adding print nodes to various points along the game startup execution chain to see where things break down. The execution chain starts at BeginPlay in BP_ATBTT.
Unfortunately itās not exactly a standard system. Most of the weapons will likely end up having somewhat bespoke camera actions, like the sniper kill cam isnāt really going to run the same on anything but the sniper rifle. Luckily itās mostly a cut and paste job, as Iāve laid out most of it on a separate graph. Just need to insert the binds and some other logic to handle a few things. I spent the night bug hunting it, and it seems solid now, so I can go ahead and start creating the various cameras I need and tidying that up.
Scratch that. Itās not solid yet. There is some lingering bug. It seems to work for a few rounds, and then something seems to go out of sync with it. After working through multiple rounds and multiple shots, then suddenly itāll get to a point where attempting to shoot has it start the camera action and then it ends the action without doing anything. Doesnāt make much sense to me. I must have something wired incorrectly but even with breakpoints, I canāt seem to see anything. It comes back to the delay and queue action on the event graph and instead of continuing on, if Iām stepping through the debug just cuts out there. In this latest test where I was only doing aimed pistol shots, and nothing else, I must have gotten 8-9 rounds in with about 2-3 action cam runs per round before it started acting weird. One odd thing that pops up during the debug is that sometimes, the āOwningUnitā on the pistol aimed ability returns ānoneā, which doesnāt make any sense to me. Interestingly while it returns none, the target still returns the correct target value. Iām also getting some errors in the log which Iāll post if they tell you anything. it seems somehow my unit is getting unset? or Iām losing track of it, but Iām not sure how. Iām not leaving the function anymore. All the camera work is being done in the shooting ability using casts to the camera and binds within it.
This actually seems to be related to a unit dying. I notice when a unit dies, for some reason there is a slightly extra delay. I did change the dying animation, but I put the anim notify on it that it is supposed to have, and no bug seems to be produced when shooting without all my special camera work. I just ran for 9 rounds without a bug, and then finally killed 2 units both that produced this slightly odd pause after their death and after that, the shooting ability started messing up with the camera. Iāve just verified this. I started another game and moved everyone in close, so that I could kill someone as quickly as possible. As soon as the first unit died, the very next unit couldnāt do a pistol shot with the special action camera. This is really really odd. It also gave that same error that I posted in the screenshot, but doesnāt really give details as to where this is happening. The output log gave that same yellow error, but the error log didnāt produce any errors that could be clicked to show where in the blueprint the issue was happening. Iāll post some screens of how I changed the ability. What Iām seeing in game is that when this error is generated and it messes up, it seems to be getting to the lerp, the camera slides and then the ability suddenly ends without anything else happening. But it does seem to be shooting in the code. e.g. units are taking damage and will ādieā on the code side of things, but the animation doesnāt match because the ārender beamā and other second half code from the ability never seems to get run.
Iām also going to attach a video so you can see what happens. this time it was slightly different. I was able to shoot one or two times normally after the unit died, but then it went sideways on a move, you can see the camera jump away before the move is finished and the walking sound just continues. After that shots which use the action cam donāt work, but the shotgun blast (which doesnāt use it) works fine. Each time I had an action camera shot fail, one of those yellow faction errors was generated in the log. It also looks like my error handling code was working somewhat correctly. For my test I had the units to always use the action cam 100% of the time, but the two shots after the unit dies are both done with the normal camera and not the action camera. That means the owning unit was being read as ānoneā for those shots.
After more testing, this seems entirely related to a unit dying. A unit dying does something to break this and all my other camera work, and Iām not sure what or why. Any insight on that might be appreciated. I havenāt changed anything regarding death except to return a bool on ātake damageā, but I donāt use that now for anything and to change the death animation. I put the included one back in, but it seems to make no difference. It also doesnāt matter how the unit dies. I killed the unit with regular attacks (no special cam) and special cams were still messed up
One more note, I opened up that fresh unedited copy of the toolkit that I made and ran the jungle map, whatever this āunitā bug is, is present there. If you start the toolkit and start the jungle map, and then click on a grenade ability, youāll get that error in your error log as soon as you click on the ability. This will show itself right from the beginning of the game.
**EDIT: It seems that I had forgot to untick loop on the dying animation on one of my animation blueprints causing it to loop over and over. This fixed the camera issue, it did not however fix the āunitā error message which is sometimes returning no unit. This seems like a fairly serious bug if the game suddenly loses track of which unit itās currently controlling. **
Camera performance isnāt bad on mobile, but itās going to depend a lot on the map in question (based on my assets). The large bank map which has a lot of stuff on it, has a slight FPS dip when I do a spinning camera move and the bank is in the back ground. I believe these assets were made with mobile in mind, but I am going to do an LoD pass on those at some point just to be sure. Overall Iām quite satisfied with the performance on mobile. This isnāt something thatāll run on weak phones, but even on 2-3 year old phones it works okay.
Unfortunately it only happened once and it was on a shipping build on my phone. I havenāt seen it happen since either. If I have a chance while Iām digging through the blueprints Iāll see if I can spot any nodes in there that might round something differently.
Good idea with the āprint string.ā First off, it doesnāt work with the example map either. I have been able to narrow the problem to the Turn Manager. It doensāt seem to be able to receive any calls to its events. On āsetup core blueprintsā in atbtt state, the āinitializeā event is called. Before and after this in ATBTT state, a print string will display. As far as I can tell, in every other BP, print strings are displayed. In the āinitializeā event in Turn Manager and in the āNotify Play Readyā event in Turn Manager, neither of these will print strings. I did try changing whether it was replicated and/or reliable and this didnāt change anything.
**Also, I should add that Iām using the āexecute console commandā and doing server travel, rather than doing the open level function. I guess my research lead me to do it this way so that it was less impact on the memory and so that information could travel with me and the connected players. **When I did this with the āopen levelā function it works, but I think that in the end this isnāt going to work for my game.
Why wouldnāt it be receiving calls when I do the server travel way? And any thoughts on the way around this?
Iāve experimented for 2 days now without any luck. Might be time to askā¦
Iām trying to insert an event right after the camera is centered on the actor/pawn(and before the player can start to move), but unsure where the camera centering is actually happening. Any idea where this would be suitable? I can insert the event before(BP_TurnManager and immediatly after BeginActorTurn custom event) the camera is centered but not after. Any other tips for this would be appreciated.
I sent you a PM about a possible solution earlier, but Iām replying again here for the benefit of others. I had a similar bug with actions seemingly starting and ending early in a test build. The issue turned out to be the death animation being set to loop. The units turned invisible after the first loop, but it continued repeating the animation while invisible. This activated the anim notify at the end of the animation every time, triggering EndAction and thus mucking up the action queue. Check your animations and make sure none of them are sending notifies more often than they should and check if that solves things.
Checked it out and confirmed the bug. This is not an issue that should have any impact on gameplay, but Iāll fix it in the next update. To remove the warning, input OwningUnit into the Units input of the āActivateā QueueAction macro in the event graph of BP_Ability_Grenade.
Good to hear that mobile performance is decent even with your fairly complex game.
Hmm, honestly I have no idea why the open level function would work, but using the console command will not. Why isnāt Open Level going to work for your game? Do you know what central ways these two approaches should differ? Networking is not something I have a complete overview over.
Well, there is not any in-built event that signals when the camera has stopped moving. The camera centering on a new unit is handled by the FollowTargetTick function in which is connected to the tick event of GridCamera. If PanToCustomLocation is true and ActorToFollow is a valid actor then the grid camera will pan to that location using a lerp. I guess you could add a check in the event tick of where you compare the actor location of the camera to the location of FollowTarget at the end of the function. If they are nearly equal you could fire your custom event. You would control access to this check through a gate node, which you would open at the start of a new actors turn and close after your custom event has fired. That is one possible approach, in any case. Hope it is enough to get you going.
Welcome Those are general topics that are not unique to the toolkit, but here are a couple of good resources.
For extending to c++ you should of course first have a good knowledge of C++ (which Iāll assume you have. If not learncpp.com is a great resource). For combining blueprints and C++ I recommend starting with UE4ās documentation.
That definitely fixed it. Looks like you were replying while I was editing. With the camera straightened away, Iām in pretty good shape now. Mostly polishing cameras/animations, multiplayer and the touch controls
Okay, so this is something specific to the ability? Should this be hooked up in all abilities? When things were breaking because of the death animation, i was getting that error a lot. So I just wonder if we should connect that to all abilities as a matter of good practice.
One thing Iād like to work on though is shooting out of cover like xcom. Animation wise Iām fine, itās an issue of modifying the trace system and basically making the pawns return a possible āhitā in all squares around them. I think I can work it out, Iām just wondering if you have any standardized functions or things built in for return the grid squares directly around the unit, e.g. return the square 1 space to the right or left.
Evening , and everyone! Ran into a (possibly noob-ish) road block, I have my game set up to have the activation of atbtt done manually. The goal is to have start of play for placing/spawning actors in a pre-battle phase. When starting the game my issue is that I cannot get controlls to work (aside from clicking my ābattle startā button). No camera movement or mouse clicks aside from clicking on hud buttons. Bindings are not the issue, controls work great when atbtt starts and in editor. Just not before. When starting the game (pre-battle) grid camera is possesed but no movement. I have checked out played controller, game mode/state and having no luck. Any ideas? Thanks for your help. Hope all is well and your PhD coming along!
Wonderful! Glad my suggestion worked. Was worried that it was something more serious.
Kind of. The grenade ability and several others call on the Activate action of BP_Ability. For abilities that show markers, such as the move ability, I input a unit so that I can check the owner of the unit and make sure the tiles are only displayed to that player. The grenade ability does not have any such markers, so such a check is unnecessary. Because of this I did not pass the unit input, but BP_Ability still tries to check it. A cleaner way to solve this is probably to set up is to add a new check in the activate action of BP_Ability that skips the check if the unit input is invalid.
Not sure about the best approach for exactly what youāre after, but there are a few different ways to get the neighboring tiles. In order of most flexible to most performant they are FindTilesInRange (gets tiles at any range. Can check if they are visible/too high up etc.), GetIndexesInRange (can specify range) and GetNeighboringTiles (only gets neighbors).
Thanks! If all you need to do is spawn units before starting the game proper and donāt need to do any major alterations to the grid itself you do not need to delay activating the game mode. If you try running the game without any units placed you will see that a special ability will be activated (BP_AbilityBase_Idle) which is simultaneously active for all players. It is a good starting point for an interface to spawn units through. Then when you are ready to start the game you can run BeginTurnBasedCombat from the turn manager.
Iāve attached a grid here to explain what Iām looking for here. Basically I need to first check if a unit is in full cover. If they are, I need to rerun their range trace from the yellow squares. So, from the unitās location I need to be able to detect the north/south/west/east squares (not diagonal ones for this) from the unitās position. If any of those are full cover, then I need to recheck the range trace from the 2 appropriate squares. I could have an array of the 3 squares, remove the one that is opposite the one with full cover, and rerun the range trace from the remaining two and store units that can be hit from those traces in a different array (I need to keep a record of this so that I know which square to animate my unit to step out into to fire).
On the opposite side of things. If a unit is in full cover, I should have it āoccupyā the squares around it (red and yellow) so that when a range trace is done it returns that the unit can be fired at. Iāll need to change all my full cover things to block range for this to work properly I believe, which is why I need to do additional traces and cover additional tiles. Do any of these functions which returns tiles return them in a way that I can sort of āseeā the grid around me? Like Can I return only the north/west/south/east tiles on a square grid and know which direction they are?
Iāve thought about this a bit in the past, and I think it might be more hassle than it is worth. Iām pretty sure XCOM just checks visibility from behind cover and then just animate the stepping out and leaning. For this you would still want to find the adjacent tiles, of course. By default tiles to the north and south of a tile will have an index +/- 1000, while east and west will be +/- 1. So if your cover has an index 1000 higher or lower than the unitās tile you could get the āyellowā tiles by getting unit index +1 and -1. I would recommend against changing the mechanics based on this. To get this to work for the AI you would need to triple the amount of sight calculations in many cases, for a benefit that will probably be opaque to the player. If youāre dead set on implementing this Iāll give it a bit more thought, though.
Great! I added that ability in the last update precisely for these sorts of use cases, so Iām glad it works
Hmm, okay that sounds a little easier, but I think the xcom check is a little more involved than that. Iāve attached a diagram.
if the target is in cover, the side the shot is coming from needs to have an empty (or half cover) square there. Otherwise it needs to be blocked. Itās pretty easy to animate the attacker, but I think the function to return valid targets would still need to be modified kind of like this pseudo code:
if (unitisinfullcover && attackingunitisattackleftorrightside)
if (pinktileonattackingside == full cover)
return notavalidtarget
For the attackers, I think it still needs to be changed. If you allow range trace through cover to return a hit, that means any intervening cover would also allow a range trace, at least the way itās currently set up. Units behind cover who are peaking out shooting can be shot at, but units further back where line of sight is totally blocked by the cover shouldnāt be able to be targeted. At least in my mind. Also for attacking units, if their pink squares have full cover in them, they shouldnāt be able to lean out that direction which means they shouldnāt return a possible hit on that side.
So the attacking unit also needs a bit similar code:
if (attackerisinfullcover)
Check (targetisonleftorrightside)
if (pinktileonthatside == full cover)
return notavalidtarget
So I donāt need to run additional line traces, but I do need to run a check on both the target and attacker to make sure they would genuinely have line of sight to each other in this case. If I just allow range through full cover without checking, they could shoot through normal walls, etc. These two bits of pseudo code solve most of the issue. The only remaining issue is the intermediate full cover that would block line of sight, but return a hit on a unit hiding directly behind it. If we allow full cover to let a range trace through, it wouldnāt block a shot in that scenario, and if we block it, it wouldnāt return hits on units in their cover. Almost need to do something like:
if (linetracehitsrangeblockingtile)
check (tilebehindfortargets)
if (unitexists)
return validtarget
Hello . I want to use this system to make a game similar to descent.
Where would I look to find fog of war functions? I would like them to hide units and all hexes in the fog. Would copying the line of sight code and making it hide all gray squares work? I know itās located in the 2d map but the video explaining it doesnāt seem to match up with the blueprints anymore and I canāt find it.
I want to split movement up. Would any of this be hard using your system?
Move after move
Move after attack
Possibly split actions up between players and ai. So a player could move then another player could attack and then the first player could continue moving/attacking or whatever they would decide to do. Preferably they could do it at the same time should they chose to do so.
Iāve finally had a chance to come back to the touch controls. I havenāt exactly worked this out yet, but I think itās a fairly simple fix. Again with my pseudo code:
We already have btouch passed along the input route. I think we basically need to do this on bp_ability:
coming off āevent server interactā
if (btouch)
if (currentselectedtile == lastselectedtile)
execute ability
else
lastselectedtile = currentselectedtile
call hover event
we basically need a check on tap to see if weāre tapping the same tile weāve already selected and then either run hover or execute. I think that would solve input, but there is still a bit of an issue of the jumping around with the swiping and it sometimes jumping when tapping.
Ok, some super quick answers. Iām aiming to hand in my PhD thesis on Monday and will be working every hour of the day until then, so I likely wonāt post here again until Tuesday. But from then on support should quickly become as good and frequent as it was a year ago.
@crossmr: donāt have the time to go into depth on this, sorry. But this is quite different from XCOM, I think. In XCOM cover does not block line of sight, but only provides a cover bonus. If cover blocks line of sight coding this stuff becomes quite a bit more difficult, but your suggestions seem like a good sart. I will begin looking at this in-depth, including the touch control stuff, next week.
Like the board game Descent: Journeys in the dark? Iāve played that quite a bit. Fun game, and should be doable with the toolkit. The fog of war stuff is located in the 2D map as you guessed. Look at the grid manager 2D child blueprint for the setup of the fog at begin play. What tiles are revealed are stored in a Set there. Then tiles are revealed as part of the movement and BeginPlay of Unit_2D_Hero.
Move after move, after attack etc. can be done. It is mainly about choosing the action point costs for your various abilities (in their variables) and disabling use ends turn.
Alternating between the player and the AI can be done. You would basically call end faction turn from the turn manager whenever an action is done so that the other faction could act. You would have to change how action points refresh, though, as this is normally done for all units once the initiative order has been looped through once. The biggest challenge here is probably to have the AI treat this intelligently. You would want to have the AI loop through all possible actions for all available units to figure out not only what ability is the best to use, but what unit should act now. Can certainly be done, but you would have to keep this in mind while designing the AssessAbilityValue events for abilities, as well as possibly run the code over multiple ticks to prevent frame drops while calculating if you have large AI teams. Hope this is enough to get started on. Post here next week with your progress and Iāll give you a more in-depth answer.
Trying to load your more advanced UI(like the one in Jungleraid) in the example map but canāt seem to find it and your world settings look the same. Any idea? Thanks.
@ No worries, get your PhD finished up, when you get back, Iāll attach an image someone uploaded which explains how LoS and cover work in Xcom: Enemy Unknown. As I suggested earlier, it seems that full cover blocks LoS, but only when the target or attacker are unable to step into an adjacent square to get LoS. So they can shoot around corners, but if youāre in the middle of a 3 tile wall, there is no way for you to shoot through it. Also if the unit is further back, they canāt get shot. https://i.imgur.com/eqnBg.gif seems like the real key difference between xcom and your kit is the ability to step out.
Started the first bit of work on touch controls, in the first image I added a little bit of code to BP_Ability this code checks if touch controls are being used, and if they are, it does the click check that I was talking about. Iāve also disconnected tick in the playercontroller for that mouse hover stuff. This also includes the changes I mentioned earlier. Iāve noticed the following (very odd) behaviour:
When Shooting, you can now click the unit once, and it will āhoverā on that unit. You can now easily check the hit percentage before firing. However to actually fire, you still need to multi-tap. I have no idea why. By all logic, the next tap should try to run execute but it isnāt, you need to tap 2-3 times before it triggers.
Moving still works on a single click. Again, not quite what Iād expect here. Sprint, executes after a single tap. I was expect it to select the tile, then wait for a second tap to actually execute, but it does not. Edit: Nevermind, I just realized that Sprint has an override for server interact, Iāll have to change that one there.
a little more testing and Iāve gotten the following results: I tried rewiring all kinds of different things to see if anything helped this along, the answer was no. I tried adding a similar check in to the sprint ability but it didnāt seem to help, all it did was hover for a split second and then require 2-3 furious taps before itād move. This may be related to some ājumpingā of the location. Itās hard to print location data on an android phone, maybe Iāll have to rig up a debugging UI for this, but I am getting the sense that the location is jumping around. This may be related to the click attempt function in BP_AbilityBase. If the check hovered location fails (which Iāve ticked the touch box for) it returns a click invalid with a location of 0,0,0. Also, I wonder if you tap very fast, if the rest of the function works correctly. If you press touch, itās supposed to (if not released) run a check for the location and set that, so that itās available on release. I wonder if there could be a race condition here where if you tap too quickly, if the code doesnāt properly finish checking the location of your tap and may return an old location or 0,0,0 in some cases.
@ When trying to organize the folders I get an error about a private graph. Iām just trying to either put the main ATBTT folder into another folder or rename it but it wonāt let me do either without breaking it. Every time I try to allow it to find the chains it just fails and cycles the same error. Any way to resolve this?
Good luck with your PhD ! Looking forward to more ATTBT updates when youāre more free, and +1 from me if the Cover systems could be expanded on, like what crossmrās XCOM mechanics describe.
