If I change a parameter of a widget, the change does not appear in the designer but only during gameplay.
Here is the example:
This is a widget with an image. It has a default material applied to it (the icon).
In its construction script, I create dynamic material instance and assign it. Purely cosmetic, no gameplay involved.
But when I use the widget, say in my in-game displays, I can set a new material, but in the designer, still the default material is shown:
However, during gameplay, everything looks as expected:
While it is fantastic that it works during gameplay, it makes the design of a complicated UI system (think of the iDroid in MGSV) like a game of blind chess… :o
So it would be nice it widgets would update on parameter change
Cosign. I have a standard widget for certain buttons/sliders… Really hard to design a menu when it the wodgets in the designer read “MENU MENU MENU Button Button Button Slider Button Slider Slider Button Slider Button” instead of showing the text those various widgets would display.
Yup - been thinking about how to do this safely. Considering something along the lines of a preview tab you can bring up and keep up that spawns a preview world, maybe player controller and game mode. Not sure how far I want to take it, the closer I can get it to the real game environment, the better. But then taken to its logical conclusion, the correct action should be to get the compile/replacement system in blueprints solid enough to work in the running game - but that’s super tricky especially for the widgets since the mix of Slate/UObjects (they don’t respond well to uobjects being replaced out from under them), so a toy world that can be completely thrown away and reset might be the best / safest option.
I have to do something like that - just running your code in the designer would corrupt the state of things, could potentially crash if you’re calling a native function that doesn’t anticipate the preview environment of the designer…etc.
I admit that I dont know much on how UMG and the whole widget visuals are implemented, but it seems that widgets do not draw themselves.
Why not? If widgets had the capability to render themselves onto their owners canvas, they could do that with their individual parameter settings.
A widget containing other widgets would, on instance creation, create its contained widgets, so their construction scripts run in sequence.
This ties a bit into my other request for UMg widget inheritance.
Even if only cosmetic things are done? As the node tooltip says: Only cosmetic things are allowed in widget construction scripts.
If users stick to that (no gameplay stuff), then it should be safe.
All the widgets are concerned with at this stage is to look good, based on parameters.
If you speak of an isolated preview world, in what world do Blueprints live when I click on “Simulate” ?
The UWidgets are just wrappers around Slate widgets. Widget Inheritance is non-trivial. That requires the designer become aware of merging multiple widget trees, extending from multiple roots, it’s a whole thing I haven’t had a chance to tackle.
Cosmetic just means isn’t run on the server - cosmetic things can still be dangerous and destructive to the state of things. The designer is the state of things - I can’t allow you to run code that would change the state of it, that could cause havoc. If you want - you can do what the Paragon team did and subclass UUserWidget and expose a special “IDoWhatIWantAtDesignTime” function that you call from native code, into blueprints that lets you run arbitrary code at design time. Once I do the template/preview inversion I have planned it will be slightly safer.
It’s a UWorld, setup to be a ‘Preview’ world which are special worlds in the editor we use all the time to render meshes and simulate things. As opposed to the ‘Game’ world we spawn when you use PIE.
Interesting, I had wondered why this wasn’t already in place, since it clearly wasn’t a practical limitation.
Nick, I haven’t looked through in detail, but off the top of my head I’d have thought it might be possible to implement a partial solution where you didn’t run a user widget’s blueprint Construct event, but merely reflected changes to an embedded user widget’s properties so any of its internal widgets binding to them would display appropriately.
I quite likely haven’t really thought this through, but if it were possible I think that would be a big improvement in the designer, regardless of plans to create a full preview system.
