[SUPPORT] Advanced Turn Based Tile Toolkit

[Monokkel]

So I'm sorry this is the second time iv posted this but no one has given me an answer and i am a massive noob in unreal with only a small amount of experience but I'm really struggling to get custom huds for each class of unit after a good week of trying to do it myself I can't seem to figure it out. Iv done some screenshot which I'm hoping might help people answer my question. Thank you in advance

Hi Paddysonn! I'll do my best to help you with this, but it would be helpful to me if you could tell me a bit more about what your end goal is here. Are you trying to display the stats or name of the current unit on the screen, or is this something more complex? Are the widget blueprints for the different units fundamentally different, or could they be driven by the same widget blueprint with some parameters altered depending on the current unit? If you could describe what precicely you want to happen in game I can probably provide you with a good solution.

At the moment what I can do is point out a couple of errors in your code. Calls to parent events aren't meant to be used like you do in your second screenshot. Any call to a parent event should be part of the execution chain of that event. If you call EventBeginPlay in your bottom screenshot, Parent:HudMelee will not be called, as EventHudMelee was never called. Disconnect Parent:HUDBuilder from Parent:BeginPlay and add a call after Parent:BeginPlay to EventHUDBuilder (not Parent: HUD Builder), and the execution chain makes more sense.

Also, in the Owning Player input node in your top screenshot you should add a reference to the player controller (use get player controller). That part probably won't make a difference, but it is best practice.

Even if your solution works after making these changes, please describe what you are trying to do anyway, as I might be able to suggest some better ways to implement it.

[Monokkel]

Unreal Engine 4.18 is out, and the current 4.17 version of ATBTT converts just fine without any issue.

Edit: What I described here earlier has been fixed. It should now be possto create a fresh 4.18 project without issue.

[Paddysonn]

Hi Paddysonn! I'll do my best to help you with this, but it would be helpful to me if you could tell me a bit more about what your end goal is here. Are you trying to display the stats or name of the current unit on the screen, or is this something more complex? Are the widget blueprints for the different units fundamentally different, or could they be driven by the same widget blueprint with some parameters altered depending on the current unit? If you could describe what precicely you want to happen in game I can probably provide you with a good solution.

At the moment what I can do is point out a couple of errors in your code. Calls to parent events aren't meant to be used like you do in your second screenshot. Any call to a parent event should be part of the execution chain of that event. If you call EventBeginPlay in your bottom screenshot, Parent:HudMelee will not be called, as EventHudMelee was never called. Disconnect Parent:HUDBuilder from Parent:BeginPlay and add a call after Parent:BeginPlay to EventHUDBuilder (not Parent: HUD Builder), and the execution chain makes more sense.

Also, in the Owning Player input node in your top screenshot you should add a reference to the player controller (use get player controller). That part probably won't make a difference, but it is best practice.

Even if your solution works after making these changes, please describe what you are trying to do anyway, as I might be able to suggest some better ways to implement it.

Thanks for the quick reply my end goal was to have a build button on the widget appear when selecting the builder class and then have it disappear when selecting the melee. And I shall try exactly what you said adding call after event being play, or would an update function or tick function be better for this?

[Monokkel]

Thanks for the quick reply my end goal was to have a build button on the widget appear when selecting the builder class and then have it disappear when selecting the melee. And I shall try exactly what you said adding call after event being play, or would an update function or tick function be better for this?

I'll give you one possible way of doing it. Tick events should generally be used only when absolutely needed, and it should not be necessary in this case, since you only really need to update the HUD at the start and end of a unit's turn.

I would also advice against adding stuff to the viewport from individual unit blueprints. That way you can quickly lost control over where all the widgets are added from. I would recommend keeping the control of widgets in a singleton blueprint. The player controller is probably a good choice here, since it holds the nodes for beginning and ending a unit's turn (which is when you want to update the HUD) and it exists only on the client, which is where you want to display you HUD if you are ever to add networking.

I would add a User Widget Class variable to the Unit blueprint. I called the variable UnitWidget. Then, in the playher controller, somewhere after the Activate Unit event, clear any unit widgets already there (if valid), create a new one based on the widget class held in the UnitWidget variable of the newly activated unit (if valid) and add it to the viewport.

Then, in your various unit child blueprints set the UnitWidget to whatever widget class you want to display. Keep the variable blank if the unit should not have a widget associated with it.

I think that should do the trick. Let me know if this works like you want it to. Here is a screenshot of my player controller implementation:

[Paddysonn]

I'll give you one possible way of doing it. Tick events should generally be used only when absolutely needed, and it should not be necessary in this case, since you only really need to update the HUD at the start and end of a unit's turn.

I would also advice against adding stuff to the viewport from individual unit blueprints. That way you can quickly lost control over where all the widgets are added from. I would recommend keeping the control of widgets in a singleton blueprint. The player controller is probably a good choice here, since it holds the nodes for beginning and ending a unit's turn (which is when you want to update the HUD) and it exists only on the client, which is where you want to display you HUD if you are ever to add networking.

I would add a User Widget Class variable to the Unit blueprint. I called the variable UnitWidget. Then, in the playher controller, somewhere after the Activate Unit event, clear any unit widgets already there (if valid), create a new one based on the widget class held in the UnitWidget variable of the newly activated unit (if valid) and add it to the viewport.

Then, in your various unit child blueprints set the UnitWidget to whatever widget class you want to display. Keep the variable blank if the unit should not have a widget associated with it.

I think that should do the trick. Let me know if this works like you want it to. Here is a screenshot of my player controller implementation:

Thank you so much, that was an great explanation of what needs to be. Sorry again for being such a noob with UE4 this is my first solo project away from my usual position (audio) and the team i work with. But this has helped me massively to understand where features go, thank you again.

[behrtron]

Hello, after altering the Event Tick Camera panning function in bp_grid camera i removed 7-10ms/s by using Timers instead, this brought me from 30-35fps to 50-55fps and was a Huge performance boost for me, just thought id mention this to you all

[Monokkel]

Thank you so much, that was an great explanation of what needs to be. Sorry again for being such a noob with UE4 this is my first solo project away from my usual position (audio) and the team i work with. But this has helped me massively to understand where features go, thank you again.

Happy to help! Have fun learning

Hello, after altering the Event Tick Camera panning function in bp_grid camera i removed 7-10ms/s by using Timers instead, this brought me from 30-35fps to 50-55fps and was a Huge performance boost for me, just thought id mention this to you all

Thanks a lot for letting me know. That is an absolute massive performance boost, and quite surprising. The grid camera was quite far down on the list for my refactoring of the toolkit, and I had considered delaying it until the update after the next (since it is more or less independent from the rest of the toolkit). I haven't altered camera functionality much since early in the toolkit's creation, so I suspected it to be somewhat inefficient, but I had no idea it was this bad. I'll make it a priority to fix this.

[behrtron]

Happy to help! Have fun learning



Thanks a lot for letting me know. That is an absolute massive performance boost, and quite surprising. The grid camera was quite far down on the list for my refactoring of the toolkit, and I had considered delaying it until the update after the next (since it is more or less independent from the rest of the toolkit). I haven't altered camera functionality much since early in the toolkit's creation, so I suspected it to be somewhat inefficient, but I had no idea it was this bad. I'll make it a priority to fix this.

anytime! Tick is a killer! :P

[Monokkel]

anytime! Tick is a killer! :P

I've been looking into the tick event of BP_GridCamera to try to figure out what is taking up so much resources. There are certainly a few unnecessary things here, that I have already weeded out in my WIP build, but even if I delete everything I am not seeing framerate improvements anywhere near what you are reporting. This could just be caused by us using different hardware, and this not being a bottleneck in my case, but could you do a small check to see if the framerate drop is not caused by something else?

Have you tested the two different grid camera setups back to back? Also, might you have had a blueprint graph window open while testing the old camera setup (which often greatly reduces fps). Could you retest two projects back-to-back with no blueprint windows open, back-to-back for the original camera and your altered version?

And if you do still see large fps drops, could you try disconnecting one and one of the functions connected to the tick to find out which part is the culprit. I'm going to make several changes to the grid camera no matter what, but it would be useful to know, since I have not been able to replicated it on my own.

[Danjio]

Is there an ETA on the multiplayer update part?

[Chairman Meow]

Hey there, finally I'll get around to spend some time working in UE4 and especially with this awesome toolkit.
For starters I got a question concerning the attack phase.
I want to change the target selection to a free aim kind of mechanic.
So I would like to change the target selection to a crosshair driven system.
Could anyone give me some input on where inside the toolkit I would start building this mechanic?

[Monokkel]

Is there an ETA on the multiplayer update part?

Still a bit hard to say, but I'm aiming to have it done before Christmas. Just got back from a week-long conference in Washington DC and back to working on the toolkit now. The new action-queue based solution for multiplayer seems to be working fine, but there is still a lot of tweaking and testing to be done.

Hey there, finally I'll get around to spend some time working in UE4 and especially with this awesome toolkit.
For starters I got a question concerning the attack phase.
I want to change the target selection to a free aim kind of mechanic.
So I would like to change the target selection to a crosshair driven system.
Could anyone give me some input on where inside the toolkit I would start building this mechanic?

I'll do my best to help here, but I need you to elaborate a bit. What exactly do you mean by a crosshair driven system? Do you mean that when units attack you zoom down to a first-person view and attack by pointing and shooting?

[Chairman Meow]

Hey Monokkel, thanks for the quick response.
You are doing a great job supporting your toolkit.

Well in the end I want a system where you can manually aim your attacks.
My current vision is some kind of cone going from the attackers weapon to the location of the mouse (crosshair) in world-space.
The end of the cone will match the area where the attack might hit depending on it's accuracy etc.
No camera changes or anything intended.

So basically after the movement is done I want to switch to that "mode" and want to know where would be the best spot to start implimenting it?
I figure it could be done like one of the skills in the Jungle Raid map like the laser skill in your tutorial just using different mechanics but I think I want this as default attack mode.

Edit: After reading this again i realized that I should add the part where I want to use physical projectiles / linetraces and destructible environment.
That's why I want the free aiming.

[Danjio]

Still a bit hard to say, but I'm aiming to have it done before Christmas. Just got back from a week-long conference in Washington DC and back to working on the toolkit now. The new action-queue based solution for multiplayer seems to be working fine, but there is still a lot of tweaking and testing to be done.

Will it feature a steam implementation aswell where I can invite people via the friendslist?

[Monokkel]

Hey Monokkel, thanks for the quick response.
You are doing a great job supporting your toolkit.

Well in the end I want a system where you can manually aim your attacks.
My current vision is some kind of cone going from the attackers weapon to the location of the mouse (crosshair) in world-space.
The end of the cone will match the area where the attack might hit depending on it's accuracy etc.
No camera changes or anything intended.

So basically after the movement is done I want to switch to that "mode" and want to know where would be the best spot to start implimenting it?
I figure it could be done like one of the skills in the Jungle Raid map like the laser skill in your tutorial just using different mechanics but I think I want this as default attack mode.

Edit: After reading this again i realized that I should add the part where I want to use physical projectiles / linetraces and destructible environment.
That's why I want the free aiming.

Ok, I see. Using the skill system would indeed probably be the best way of doing this. You can create a new skill blueprint and add an accuracy cone mesh to this. You would add the code for rotating and positioning the cone in the event graph of the skill blueprint, as well as the firing the projectile, dealing damage etc. It is difficult to give you a step-by-step guide to do something like this, but why don’t you start by making a new skill and setting it up as best you can and getting back to me with any problems you encounter along the way? If this proves too difficult you can provide me with a thorough description of what you want to achieve, and I can try throwing something together myself. I’ll have to wait until after releasing the next update until I try my hand at something that involved and time consuming, though.

Will it feature a steam implementation aswell where I can invite people via the friendslist?

I haven’t tested Steam implementation yet. All I’m doing at the moment is to make sure everything replicates correctly across the server and all clients. More specific implementations will have to wait until after this essential first step is done. However, there should be nothing preventing ATBTT from working just like any other networked multiplayer game made with UE4, and I do not see any reason why friends list invitations should not work once everything is set up correctly.