Need a bit of Help with My conquest Mode

[BaseReality]

Breif:
I want create a conquest mode Similar to the classic Battlefield games like BF2/2142, so I created 2 teams and some capture points.

How it Works:
when either team enters the capture zone it makes a decision based on an integer value of either

0 = neutral Nobody has control
1 = Team 1 has control
2 = team 2, has control

If the opposing team has control it will remove there points and set it to neutral control, Then start to capture it.
All working great so far.

Issue:
I have a Hud widget with some icons on it that will represent the Control points and I want them to change color to display its control status
I know how to connect them to the hud to update an icon, But Im confused how do do it with multiple capture points in the map without making the icons static and tied to each point .
Ideally I would like the icon Captures to move from left to right for team 1 and right to left for team 2 like in this video top center of screen.

Battlefield 2142 New Map for 2142 Operation Power Failure Good CQ Map with Close Control Points

[MostHost_LA]

Not sure I understand entirely - the top portion of the video seems like an overall score. I suppose the blue/red squares could represent captured zones…

Either way, the widget needs to be dynamic. As I’m sure you have already considered given your question about not making them static.

The map needs to take care of adding however many widgets to represent each location at runtime (on begin play).

• to do this you would probably loop through all actors of class “trigger” or with a custom tag for “capture point” and generate the widgets to add to the HUD with it.

Doing so, means that the values of each widget can all be separately instanced and updated. You can even output a capture percentage or fill an image bar based on the value of the total points / 100 rather then just flip between red and blue (or team colors).

IF you want to re-organize the order to have it be fixed then you would have to modify at runtime based on what is getting conquered. You can somewhat easily do this by changing the Row order of the widget element at runtime.
The option is available when you place the widgets inside a container that supports it. like a grid.

As an example of creating widgets procedurally:

On player start I’m creating A widget and filling custom variables with info.
Whenever the widget is added to the screen it will contain those variables (if you use the instanced pin ofc.)

The widget automatically creates what it needs based on the variables:

A good way to call for updates is to create an interface and add it to the widgets so that you can quickly loop through all the ones that implement the interface. However, if you just create your own widget type to add - like in my case the WidgetPart Button class, you can use that to loop though. Just make the class something specific to the captures so that it’s unique.

A custom event can loop through all the widgets, find one that has a matching a variable name tag or whatever other means you choose to identify them and allow you to update the displayed data.

Or, each widget class can updated itself with the on-tick function (maybe reduce the timing of the tick event for it).
I would even go as far as just implementing an interface for it.
then you can call the updates directly from the area without having to do much of anything - when the trigger/overlap of the capture zone happens you can just issue the interface call to update all the widgets.

[BaseReality]

@MostHost_LA

Not sure I understand entirely - the top portion of the video seems like an overall score. I suppose the blue/red squares could represent captured zones…

Either way, the widget needs to be dynamic. As I’m sure you have already considered given your question about not making them static.

Spot on!

Thanks for the Reply, MostHost LA

Lots of ideas and and potential solutions to digest there.
I’m not really keen on the procedural Widget method as I already have a single hud widget with all the Icons for the Capture points.
I like the Method of calling all actors of class to get all instances as I was stuck on how to call them all instead of just one.
My initial idea was to have each Capture point Directly update the hud widget each time the control status changes, and then somehow add the values up in the widget bp.
I dont really to much with the level BP and normally try to avoid using them as I dont like to tie things to any specific level and prefer to make thing more modular and reusable,If that makes sense.
But I might have to for this as I cant see how I could be calling all actors of class if there are not in the world.
Going to see what I can pull of and get working.

[MostHost_LA]

I prefer levels because they are directly tied, but this would actually be a good functionality to put into the Game Mode.

you just need make sure the level is fully loaded before calling the functions…

[DomusLudus]

@BaseReality

Spot on!

Thanks for the Reply, MostHost LA
My initial idea was to have each Capture point Directly update the hud widget each time the control status changes, and then somehow add the values up in the widget bp.

That’s the correct idea, all you have to do is create the widget in the Capture point actor itself and save the reference in the begin play and send an event to the hud with the widget to add it as a child.
With the reference in the actor himself you can do anything you want, even remove and it will be seen in the HUD.
Any actor can have their own widgets

[BaseReality]

@MostHost_LA

I prefer levels because they are directly tied, but this would actually be a good functionality to put into the Game Mode.

you just need make sure the level is fully loaded before calling the functions…

That’s Exactly what I was planning to try, I’m just figuring out game mode / game state and how I can use them for this kind of stuff. Good to know Im in the right track.

[BaseReality]

@DomusLudus

That’s the correct idea, all you have to do is create the widget in the Capture point actor itself and save the reference in the begin play and send an event to the hud with the widget to add it as a child.
With the reference in the actor himself you can do anything you want, even remove and it will be seen in the HUD.
Any actor can have their own widgets

That’s already what I have setup, I always try to directly update widget variables directly from a ref, that I already setup in an actor.
I find it cleaner as the Widgets not constantly having to chase actors for update info and casting to them.
Im not a programmer but this seems better to me.
Anyone feel free to correct me, if Its the wrong approach.

[BaseReality]

I’m Back! and I bring gifts in the form of pictures

So basically I have everything working now and tried to put together a nice bit of code that was both simple and efficient. to figure out which instance of the capture point it was. But I have the problem of it not working with more than one instance.

So In my capture point BP I have a integer value called control that is set by the capture point itself,
I also have a similar integer value called **control **in the game mode BP.
As you can see in the pic below I am setting the value of the game mode **control ** integer, with the value of the Control integer inside the Capture point BP.
I’m also passing along another integer value called Control point number which will become clearer later.

Then In my **Game mode **I’m calling a function that I created Inside the Hud widget, and passing the control Integer value along with the control point integer and also an control point actor ref.

then inside that function I am trying to filter out which control point it is and then set the status color for it.
I Tried to do this by adding a Tag to each control point instance, and also the control point number value ant I set on the details panel of each instance I added to the map.
But its only ever working on One control point instance

I need help finding a way to be able to have 5 or more control point instances and have them all update Independently of.
as you can see in the pic below It works on one block as its turned red as I captured it.

[DomusLudus]

This is exactly the opposite of what I was saying. See if I have time later and do a minibp

[MostHost_LA]

Kinda has nothing to do with my suggestion either.

It seems likely that the game mode is not correctly setting the ID of the widget or that your widget function on the hud is not correctly finding the widget.
You definitely do not need to check the tag again. The call should already contain the correct widget reference.

BTW, a standard interface may be a better way to go.

[BaseReality]

@MostHost_LA

Kinda has nothing to do with my suggestion either.

It seems likely that the game mode is not correctly setting the ID of the widget or that your widget function on the hud is not correctly finding the widget.
You definitely do not need to check the tag again. The call should already contain the correct widget reference.

BTW, a standard interface may be a better way to go.

I just want to be clear That I’ve been using the term Hud and widget interchangeably, All I have is a single widget BP that is being added to the view port by the game mode so All players get this same overlay screen with the control point and match timer info.
Sorry for any confusion.
I will admit I prob didn’t understand the idea of having the Control points creating widgets Didn’t want to look stupid , But I think I may have just got it!

Did you mean break the status icons down in to single widgets where its just the little square box for each control point and adding them to the main widget screen?

[BaseReality]

@DomusLudus

That’s the correct idea, all you have to do is create the widget in the Capture point actor itself and save the reference in the begin play and send an event to the hud with the widget to add it as a child.
With the reference in the actor himself you can do anything you want, even remove and it will be seen in the HUD.
Any actor can have their own widgets

I think I was having DUMB day when I read this. But I finally think I get it now. And If in understand this correctly It actually very robust, but this method is a first for me so I not to surprised I couldn’t picture it.
Going to try this out

[DomusLudus]

This is just to give you an idea, it would be better to have an event in the HUD that is what the add child does and a couple of other things. All the code is in one object.

[MostHost_LA]

Wolf, are you familiar with blueprint interfaces?
create one. Make a function for toggling the state.
Create a blank widget.
Go to class settings. Add the interface.
Save and compile.

Create the function for the interface.
You can do whatever here, add local components to represent the square in the view mode.
Make the interface function trigger the color as you wish.

With this widget you can now drag and drop it into the widget you are using for the hud.

If you have a fixed amount you just customize them with tags. Or whatEver, but it won’t really matter if you link them up to the trigger.
​​​​​​
​​​​​​which is what I originally suggested.

On begin play on either the level or the game mode loop through the zones for conquest, and for each one you add a widget (created with interface) to the hud. ​​​
​​​​You also memorize this widget locally so that whenever re-entering the conquest zone you can automatically trigger the change.
Because of the interface you literally just call the function from the reference.

that’s that.

[BaseReality]

I have been exploring both solutions today and made some progress but have so issues.
first I tried DomusLudus approach and copied what I saw, in the last pic.
but None of the add child widget logic, or the change Slate brush colors worked from inside the Control point BP.
They only seemed to work from the game mode BP But I have some issues with the colors changing correctly at the moment

Good news is adding the get actors of all class and creating a widget for them automatically adds the icons to the screen , the more Control points I place in the level the more control point widgets are auto placed

Then I created an interface and added it to the Control point widget that the game mode is adding to the main widget.
But Its not working. I tested these functions I made inside the Widget using the construct node and at the start of the level the icons go green as I set control integer to do. but they wont update.
You can see from the other pic Im calling the interface Message right after the control status is set and passing it along to.

I think the issue Might be because I dont know what Widget instance is the target, as its the game mode that created them and not the Actual Control point actor. Ive been trying to sort out for ages now and feel lost as to why It wont work like the pic I copied and add the child widget to the main widget.

I’m getting this When I try to add child widget inside the control point.

Blueprint Runtime Error: “Accessed None trying to read property Conquest HUD ref:”. Blueprint: CapturePoint Function: Execute Ubergraph Capture Point Graph: EventGraph Node: Add Child to Horizontal Box
Blueprint Runtime Error: “Accessed None”. Blueprint: CapturePoint Function: Execute Ubergraph Capture Point Graph: EventGraph Node: Add Child to Horizontal Box
Server logged in
Play in editor total start time 0.672 seconds.

[MostHost_LA]

In the interface graph… do you not need to apply the color after selecting it like you did in being play???
I mean, if you bound the variable it may do it on it’s own, but usually you have to apply the brush no?

Cop point icon - or whatever you named it is the LOCAL variable of the widget reference, so calling the interface from that reference should only affect the related widget that was created by the control point.

I think you just need to set that brush…

[BaseReality]

Ok think I fixed it , It was because the control point was trying to get refs from the Game mode before it had finished creating them! As they were both creating and trying to get them on begin play,So I put a small delay in the control point to make it slower than the game mode, Then the refs were finished being created when the control point asked for them.

[MostHost_LA]

You could bypass the problem without a delay by changing the code in the control point from begin play to a function and calling the function in game mode for each control point - much cleaner and will never mess up even if the FPS drop or something messes up the delay.

[BaseReality]

Thanks, I will do just that. I defiantly learned some new things today