When you select multiple object you are not able to move all at once. you must select them one by one to move them to target position
Could you please implement a drag copy system ? like if you keep crtl ou alt while dragging you create a copy of selected widgtet(s) and move them to the position to where the user release the mouse button
When using copy paste, could you please reuse the position + a light shift of the copied objet and not put it immediatly to 0,0 postion?
Could you please enable the move of the selected widget(s) with the arrow? it can be more precise tha mouse dragging and more efficient that having to type all the expected values.
Provide some advanced samples in ShooterGame by example. Like a scoreboard where you have to list a score widget by player. For example, I don’t as of today if I should recreate the widget at each frame to take into account the changes of nb of player & value or if I should reuse the widget and just update the datas. This sample will highlight how to reuse a widget as a child to show the score and mange a ScoreManager widget that will do a loop on all the connected player, create the score widget to put as child in its list and update the value of each player.
Thanks for the feedback Elvince. Those are all on the list to do soonish. Except for maybe the (+ a light shift), we may have to do something where each container type gets a chance to customize duplicated contents, like a grid may want to move it to the next cell over or something, since it doesn’t really have absolute layout capability, and you can’t really shift anchored items that are copy pasted…etc. But whatever, we’ll come up with something.
The upgrade to ShooterGame to UMG has had some work done, but it’s an ‘as we have time’ task currently. Eventually all the samples will be UMG based.
Hey Nick, i experimented a bit with UMG 3dWidget, and if it’s not on the road, i’d like to point some issues / suggestions.
When we use “create widget” (for 2D Hud), we can chose what Widget to use, and then, immediatly from the return value output, we could access all exposed variables of the widget. Like this.
With the 3D widget, it doesn’t work, whatever the way we create it, by adding a Widget component in the blueprint component, or even through function, we are unable to get variables.
Is it getting worked on ?
Also, i made a post on the forum and Answer hub, but i still get unanswered; concerning VR support, and the several ways to interact with the 3D widget.
Currently, i only found mouse to be usable. As there are no doc yet to cover other methods. (Maybe other methods are not ready yet).
So using mouse is okay but in VR it’s real pain, as the cursor can be only on one eye at a time. So we has to close one eye to see where it actually is.
Some other addition could be made like:
-Adding a value to button.
I didn’t find a way to set a value to a button, to it returns it when clicked.
So i got to do it manually. It would be a real time saver.
You can access variables on 3D UI. You just have to get the object it’s attached to, get the UI component, then cast it to your UserWidget. Then all of its properties will be available.
Casting fails every time, and it seems someone else has the problem. Even if anyone can get it working, i just wanted to point that with the “classic” widget, there was no need to cast.
i’ll wait to what “incoming features” are. I hope it will mostly be stability fix also
You should make a new user widget that encapsulates the functionality of that button, and just re-use it, put whatever properties you want on the user widget.
That would require some kind of type ducking, mixin crazytown. The WidgetComponent is the UWidgetComponent class, it can’t suddenly expose the properties of the widget it spawns unless we generated some kind of descendant version on the fly that mixes in the exposed public members of the widget you’re spawning with the component. Like Jared said, just use the cast. Casting should work, may not work on Construction script time (because I don’t think it’s created yet), may need to wait until Begin play, that’s what I use in all my tests and works fine.
The blueprint node that you see is super special, the node is actually generating all the setter nodes + the actual construct call based on the exposed properties when the blueprint is compiled.
So here’s what I did in my game. It’s a game about retail management. Here we have my register blueprint. It has a 3D UI UWidgetComponent attached to it for an in-game screen that displays register stats like amount tendered and stuff.
And here in another blueprint I use to access the UI, I first get the register blueprint that owns the UI, get the component that houses the UI, then get User Widget object from the component and cast it to the correct UUserWidget type. Note I’m using a pure cast here, you don’t need to. Especially if you’re testing to see if it will even work. Then I assign it to a variable, but you needn’t worry about that. What comes out of the cast should work.
Nope, the copy paste fix that maintains as many properties as it can for the slot you’re in, is in 4.8 though. Requests don’t really go in that quickly - the stuff we plan to put in the release needs to be in the TODO queue about a month before we release the previews - and then it needs to be high enough priority. By the time you see a preview post for a release, we’ve already branched, and locked it down, no new features just bug fixes.
I understand the timeline but as you mentionned that most of the remarks were on your TODO, I thought this may have been put in the dev phase for the next version.
