Widget Switching

Question for you guys. I’m trying to get my ability system to use one slot for each type one for white magic and one for black. All of the tutorials I’ve seen have a row of slots. I looked and around and was told about the widget switcher but wasn’t sure if this was the right direction. I want to be able to filter through the spells using the same button, and cast it with an other without having to click on it. How would I go about doing that?

I have the dark souls reference because if you’ve played it you’re able to filter through these slots.

Sure, this could be done with a switcher. Here’s how you could cycle and cast:

Switcher can have multiple widgets inside but displays only one at a time. When the user presses X, we increase the index and display next item in the switcher. The modulo (%) wraps the value around so we can cycle indefinitely. When the player presses Q, we check what is set as the active widget in the switcher and use the ability in the skill. When anything else is pressed, nothing happens, the keypress is passed on to the player controller instead - Unhandled.

This looks like exactly what I was thinking. Can you tell me what “get key” means and would you mind showing your cast function to get an idea of how to set it up that would really help. Thank you!

Get Key is the keyboard key the widget detected being pressed down when it had Keyboard Focus (you will need to enable *isFocusable *flag on the widget that has the switchers - it’s in the details panels).

The *Cast *is a custom event in the skill widget - it’s not connected to anything as I don’t know what your spells do… that’s up to you to implement the logic you need.

Ok sounds good. Thank you this will definitely put me on the right track!! I really appreciate it.


Possibly a dumb question but where do you set up the skill index. I would assume that is the list of all of your abilities. Would that be an enum?

As far as setting up the “X” and “G” keys did you set them up in the project settings to do anything?

Also, the blueprint you showed me was it set up in the graph of your ability slot or somewhere else?

This is currently how I how the ability system.

It would be extremely helpful if I knew how you had things set up since I’m going against how the tutorial is going for this part.

The skill index is an *integer *variable - it helps fetching the *next *element from the switcher. Think of the switcher as if it was an array of widgets - like tabs in an internet browser where only one tab is active - rather than clicking on the tabs, we switch to the *next *one. It’s a generic approach where the switcher does not care what’s inside, it gets its next child instead - whatever it is; but you can also ask the switcher to pull up a specific widget directly, providing you have a reference already. Perhaps you have a hotkey for a specific ability?!

I did not, *Get Key *returns the pressed key and then we *compare *== , asking whether it matches either X or Q. You can choose it from the dropdown on that compare node.

In this very scenario, it should be in the widget that has all the switchers for skills / spells / abilities / items - the Dark Souls reference image. This way whenever a keypress is intercepted, it can be sent to one of the 4 (?) switchers. Never played Dark Souls, I’m imagining those slots can host multiple elements the player is free to cycle through (hopefully both ways since DS is apparently already a pain in the neck… :wink:
The logic for populating those switchers could look like this:

  • have the character create the widget with the switchers
  • have the character loop through their abilities / inventory items / spells and whatnots, creating and adding widgets to the appropriate switcher
  • bind the widget’s event to the ability in the actor of your ability system
    I suggested what I originally suggested because you explicitly asked about the switcher. If your abilities were *just *widgets, switcher would be a great choice. But since you have full blown actors serving as skills, it seems redundant and unnecessarily complicated.

It could be done the other way round. You could have the skill selection logic in the player (easier to handle inputs); cycle through the abilities and ask the widget to display the currently selected one. This way you do not need a switcher at all - probably a better solution overall. The *Use *ability is in the player and simply updates the widget display rather than relay on the widget updating the actor containing the logic.

Cycle through the abilities, select one and show it in the widget. Since you do not need a clickable / interactive interface, the widget will serve as a visual element only and have next to no logic of its own apart from some fancy highlights and animations perhaps.

Thank you so much for that in depth answer. So with it being better to have the widget being the ability itself I would get rid of all the actors that I showed above. I’d definitely like to do it the more efficient way as possible.

So if I set up all of my abilities as widgets I would basically just have the image in there and that’s it right? If I do put all of the skill selection logic into the player ( I assume your talking about your blueprint you showed me) what would be the best way to reference all of the different widgets in my character? Also with the use ability being in the player I see how it can be easier once you have the understanding of how to set it up.

I guess I’m not following how you would cycle through the abilities in the player. Would you set up all the abilities in the same category in the player then cycle through them that way? What would you use to cycle through them in the player without using the switcher. Do you have an example of this set up or know of a tutorial I can follow?

I’d say it’s the opposite. When I said:

I meant that having widgets handle logic is redundant and unnecessarily complicated. I’d definitely use *actors *or actor components for spells / abilities. Ideally something with inheritance.

In a fairly similar way:

The character holds a bunch of abilities (they create their own widgets and hold onto a reference *wAbility *here) in an array. We press X, get the next ability, store its reference as *Currently Selected Ability. *At this point you should update the display to show the appropriate widget this ability has. This may or may not be a switcher.

When pressing Q, we trigger the *Currently Selected Ability *actor’s function / event. A much more sensible approach imho.

Oh ok I must have missed understood you when it came to using widgets instead of actors. I’m following you now. So the ability layout I showed above seems like I’m on the right track laying out the abilities. Also, where would be the best place to store that blueprint in? The characters I would assume.

Since they belong to the character, it makes sense to store it there, sure. Easy to access, too.

@Everynone I’m working on trying to set this up and I’m confused about what all variables you created and are using. I guess I’m not also following how you’re using your character to cycle through all of the abilities because I would assume you’d have to be using widgets for each ability. I guess you’re using one actor as the parent and the rest of your abilities are children of that parent. Is that what class you have selected in spawn actor? Also what about the spawn transform variable? Would you be able to show me how you bound your widget to an ability?

I also started on the “on key down” function but I don’t know what to plug the “in key event node” into when I go to place the function. I started with this route because using the switcher made more sense to me with the configuration. I’ve attached some images showing where I’m at currently.

You need to override the widget’s key down, do not create a custom function for this:

There’s no need to call anything in construct.

I’m really confused by this. I presented you with 2 methods. One that is using just widgets (since you asked for a switcher implementation), and one that is using actors (since I later learnt actors are used as abilities). Now I’m under the impression you’re mixing and matching both - which is fine but will add to complexity. Perhaps choose one and stick with it for now. You can always refactor later (famous last words).

I created only one variable for this, the index which you’re already using. The rest of the nodes are widget functionality, here helping to correctly handle input from the player. But do ask if you have something specific in mind.

Yes. In the first example, abilities are just widgets with no actors handling the logic. In the second one, you’d have an actors handle the logic and their corresponding widgets display results / state.

“Now I’m under the impression you’re mixing and matching both - which is fine but will add to complexity. Perhaps choose one and stick with it for now. You can always refactor later (famous last words)”

I wanted to use the more efficient way like you stated which was to use the character to drive the ability but I wasn’t sure how you were doing it exactly. All of the tutorials I see use the widget and bind the widget to the actor functionality is my understanding. I’m just not understanding I guess how to do all of this through the Third Person Character. How do you tie all of the widgets together to filter through them?

I maybe making this more complicated than it really needs to be because I’m not able to get this working. I’m trying to not get frustrated. This is the first time I’ve done something like this without using a tutorial or something so I appreciate all the help.

Ok so moving forward with just using the third person character blueprint to drive everything it looks like the variables I need are:

  • NextAbility - which is an integer (How do you tie this back to the ability actor?)
  • CurrentSelectedAbility (How do you tie this back to the ability actor?)
  • Abilities - which is an array of all the abilities

The for each loop is what is cycling through the abilities the “index” integer variable. But how do you tie the index integer to the abilities?

The spawn actor node is using the class of all of the ability actors correct?
Then the spawn actor is making the abilities an array through the add node?

So this is the only blueprint I’ll need to cycle through the abilities in the third person blueprint?

So I’ll need a widget that just has the image and a button for each ability, and in the actor I would add the widget there correct?

Also, on the W_ability? What exactly is this variable? What do you mean by “add it to whatever display you need”?

If it helps any this is the tutorial I was following if you’re interested. I don’t expect you to look at the whole tutorial but I just wanted to show you were I was coming from.

This is currently what I have. I have the for loop on the begin play in the Third Person Character to filter through the abilities. I place the BlackMagic Action slot on my HUD, but I’m not able to cycle through with “X” I don’t know what I’m missing.

Have each ability actor create a widget - the action slot; you can do in the ability actor itself, make sure each ability actor keeps widget reference, similar to what you do with the HUD but don’t add it to the viewport.

When you cycle through abilities, get the widget reference from the selected ability and have the HUD display it. You may want to hide the previous one first.

Once you have that working OK, you can try to incorporate the switcher:

  • spawn the abilities which create widgets
  • each widget is added to the HUD’s switcher
  • when you cycle, request the HUD’s switcher to switch to the same index, or even to the ability widget directly

Ok I’ll see if I can get it working. Thank you.