I honestly don’t expect anyone except me and a couple more people to have used this plugin, but I’m struggling to understand how are you supposed to work with UIExtension.
I added an extension point, I then register a widget using UIExtensionSubsystem, which gives me a UIExtensionHandle. So far I haven’t found a way to get a reference to created widget, so I can populate it with whatever data I need or just keep a reference of it.
Is there a reason you can’t do this? It seems like Epic REALLY want you to make your extensions pull data themselves instead of supplying it to them, which sounds kinda backwards and uncomfortable. So if I register a hotbar, it’ll have to check it’s owner, check if owner has an inventory, get data from it and display whatever is in there, instead of the owner just giving the hotbar a reference to the inventory.
You need to define a new type of UObject which will be used to ‘configure’ the extension point. The way it works is tricky. You access the UI Extension Subsytem from BP, then you use Register Extension (Data /for Context) , and use Construct Object node to create a class of your custom UObject data type. Pass that constructed object as the Data parameter.
If you use a version with context, you need pass a Local Player object as the Context object parameter. This is for multiplayer games where widgets need to be player-specific.
In the UI Extension widget details panel, in UI Extension subcategory, you will need to register your UObject data type as an entry in the Data classes array. Then, finally, you need to bind both provided delegates:
The ways these delegates work is Get Widget Class for Data receives your custom UObject data type, which allows for discriminating for a Widget class.
Configure Widget for Data receives an instance of that class and also the UObject data type which can then further be used to customize the widget.
This solution is obviously for configuration at init time. For update during runtime, use an event dispatcher.
It’s been a while since I wrote my answer, but if I recall you can pass any UObject into the node Register Extension’s Data pin (see image 1), and on the other end, in either the Get Widget Class for Data or Configure Widget for Data bindings which you can create (see image 2), you will have to cast to your type to recover the original data intact. Does that help you in any way?
Would be nice to get more info even if its from epic, somehow they have all of the data stored in a special data asset “LyraExperienceActionSet” which i am assuming most cannot use unless you override the default gamemode for the lyra gamemode system. So unless you are building off of lyra, because lyra doesn’t even bind those events (unless they already bound them in C++ someplace). They really need to figure out how to incorporate lyra systems into the engine without completely wrecking game mode since it would break a lot of peoples projects unless it was optional. I guess for now, I will look into recreating the LyraExperienceActionSet and see if i can bind the widgets through the data asset. I would prefer not to use their “binding” since those are tick.
This system has nothing to do with Lyra really, besides coming with the game sample, and can be used without it. ContextObject is of type ULocalPlayer and Data can be any UObject.
LyraExperienceActionSet is a UDataAsset which modularly activates certain content and calls these functions behind the scene. But it sits on top of this and isn’t required to use UI Extensions.
