Common UI Notes

Here I’m going to put notes about Common UI as I learn them.

Most of it is coming from here: Introduction to Common UI | Inside Unreal - YouTube

but this is a 3 hour video - not good for searching later.

A kind soul has made thorough annotations here:
Epic Games: Introduction to Common UI | X157 Dev Notes

and a good overview with links to every resource that I’ve been able to find as well:
Common UI Plugin | X157 Dev Notes

UE5 Common UI Tutorial via @Mike_Prinke – DarknessFX GameDev – DFX.lv

I’ll be adding some additional notes in following comments

3 Likes

How to use the CommonActionWidget?

WHAT IT IS:
Changes icon based on controller or keyboard/mouse input.

PREREQ:
You need TWO CommonInputBaseControllerData assets. One is set to gamepad, the other is set to controller.

Don’t get confused - it allows you to enter gamepad/keyboard input into either, however the Input Type parameter decides how it gets read.

Set both of them as Controller Data for windows here in project settings:

IMPORTANT:
Default Gamepad name must match the default set in your Controller Data asset.


By default that will be GENERIC.

CommonActionWidget will not work if you do not match the names!!! By default, in project settings the controller name will be windows. You must change it.

Finally, in ControllerData asset and the KeyboardData asset, set the keys KeyBrush Images:

Now the action widget will work.

1 Like

I’ve got a suitable basic framework using CommonUI setup in UE 4.27.

Most everything is working as expected except that I cannot get the universal back key to ever register. I have tried everything shown in all the examples I have found to no avail. However, I a workaround is not difficult. I’ll show that workaround here:

First, I will not detail all of the basic prerequisites for setup already covered in documentation and the links in the first post. I’ll just overview basic setup here and discuss the caveats.

Basic prereq data:

Core elements of this system:

Component is responsible for Pushing widgets onto stack, reverting to game mode when the stack is cleared, and creating the initial base stack widget.

Caveats of note are that the base stack widget needs to be Activated and Deactivated appropriately, otherwise your mouse will appear while in game only input mode.


Why am I checking for a clear stack on Tick? Because otherwise you need a short delay if firing it from an event, and sometimes if you press keys rapidly you can pop the widgets but still remain in UI only mode, which locks the game. Checking on tick neutralizes this problem as far as I can tell.


Menu Stack widget?

Stack widget is just empty widget except the stack. You could use multiple stacks in there if you need.

And the final piece of the puzzle:
image
A common parent class that all menus will be derived from. It holds events for forward and backward travel, but you can add anything extra you want.

The main reason for this common parent is because I cannot get the in-built back handler functionality to work. This is the workaround. But it gives you flexibility for many situations so even if back handler was working as expected, you might still use this setup.

Parent Activatable Menu event graph:

Override OnKeyDown to read inputs:

Note - you might think that you could send input via an interface from the controller. You can, except it wont register if you are in UI input only mode. You could use game/UI but then you have to handle blocking input to the character. That can be done, you just have to consider your games structure.

Reading for input in the widget here does a good job of separating the widget from controller so I prefer that.

Notice that I have made a bool for handling the Go Back case.

An example child of this parent:

Thats the whole setup. Benefits are these:

  • Easy communications between complex widget structure. Just send any data to the component for temporary holding, and each widget can query there as needed. Never a need to contact a container, filter through arrays to identify some widget, etc. Comms are just stupid easy.

  • For the flexibility you get, extremely easy setup. It took three days to figure out the weird little caveats because there is almost no documentation, but now it is working fine and dramatically easier to work with than any other UI setup I’ve seen so far.

I’ve intentionally left this framework to be bare bones so that I can easily migrate to new projects and then tailor it as needed without extra bloat.

Well, it was frustrating to get started with but overall Epic has delivered another massive time saving tool here. I can’t overstate how much easier this is making my life - generally working with communications between UI elements is sooooo slow and tedious. Now its a breeze.

One thing I’d like to see is a few more exposed events to bind to from the stack, such as:

OnStackCleared
OnWidgetRemovedFromStack
OnWidgetAddedToStack

stuff like that would just make it easier to keep some clean communications such that individual menus don’t have to handle cases that are better left to a central manager.

1 Like

Focus is lost after I click anywhere on the screen!

If you have some keys bound (like press esc to exit a menu) and they won’t register after you click somewhere in the screen (and one of your focusable buttons is not hovered and you are not using gamepad), here is simple fix:

On the main overlay or canvas panel, just set it to Visible rather than non-hit testable.

This ensures that you cannot click off of the current activated widget, so focus is never lost. That’s what I assume anyways - I just make the things work,dunno what exactly is happening under the hood.

1 Like

@BIGTIMEMASTER Hello,

Thank you for opening such a topic. Your post was helpful as resources are scarce on Common UI.

However, I ran into two kinds of problems.

  1. Since Ingame HUD is an activable widget (required for common activable widget stack push), the mouse appears in the game and all inputs are disabled. At the beginning of the game, if I spawn the HUD, the player cannot control the character.

  2. When I disable the Ingame HUD and test the Pause menu:
    When the pause menu is opened, all inputs are disabled because it is still an activable widget. I don’t know how to turn it back off with the ESC key. Because none of the inputs work.

I would be glad if you could help me in these matters. I haven’t been able to find the solution since I ran into these issues. I’ve been looking for a solution for about a month or two. Thanks in advance.

I make a distinction between HUD and interactable (activatable) menus.

So I consider any menu that is something that handles input to be an interactable menu (and thus uses this commonUI based system), whereas a widget that only displays information feedback but never handles input I just use the legacy widget classes for.

I’ve also gone to removing commonUI entirely because it has too much stuff that I don’t understand how it works and thus I end up with occassional hard to resolve bugs, and have instead implemented my own system which borrows all of the same ideas but I’ve implemented entirely with blueprint.

In Project Settings > Engine > General Settings, set the Game Viewport Client Class to CommonGameViewportClient so the inputs are first rerouted to UI.

1 Like

Brush override in the data table apparently doesn’t work, it still uses the brush specified in the controller data asset. Or am I misunderstanding something?