is there any way to do it in a blueprint
how would you do it in a blueprint
or is that an inferior approach
It’s still the same answer. Use World Location to place anywhere in the world. Or Relative Location to place it next to the component its attached to.
1 Like
ok then you are saying i must stick to it as a widget component and not try to do it while it is a widget
got it
thanks
That’s not what I said at all.
stick to it as a widget component and not try to do it while it is a widget
That “while” makes no sense here. A Widget Component is one thing and a Widget is another. It never becomes one thing. If you use a component, you have 2 separate entities to worry about.
And if you use the World Space mode, you also get a Render Target and its material. So 4 things to worry about.
it is a widget component but like i said it (the widget component) has a widget blueprint class and i work in that some so sometimes i have a widget reference and not a widget component reference
so i will rather think of the widget as a widget component rather than a widget and will not try to use the widget reference to set the widget component transform
Why even use a component if you must override what it’s doing. Skip the middle man, get rid of the component, create a widget, deproject world → screen. You’d save on the memory footprint front, although this is irrelevant if there’s just a few of those.
The whole idea of having a component is for it to manage widget position for you. But you want to do it yourself. When working with comps, your job is to move the comp, not the widget.
I must admit It’s a bit awkward the way you want to use it. Widget components have their own screen layer. I don’t think they even know about the viewport, and I don’t think you can manipulate their viewport position. Can you? It’s such an odd idea that I never tried it. 
…and I was around BEFORE widgets even existed, heh. We only had HUD, bless.
You can, of course, manipulate offsets and transform inside the widget itself. Just note that no container will ever respect that. If you place a widget that was translated inside a container, the container will have no clue what is going on, it will be unable to determine Desired Size which is used for pretty much everything when it comes to the layout.
Good luck!
1 Like
like i said, widgets are not that straight forward as it seems
especially to one who does not have a lot of experience working with them
it may seems like simply an i/o box but it is far more complex than that
i had no problem using / thinking about widgets and widgets componenets interchangeably because a widget component derives from a widget blueprint
i use widget components instead of widgets as it organizes better and it actually better borrow from its supposed parent
but i also like to work inside the widget component original widget blueprint
i have now reverted to a widget component reference to set the widget location and it works technically but it hardly moves its position
simply changing the widget component location in the actor viewport is ok too but not always
still seeing what works best
i get what you are saying but you are saying stuff that i doubt the average person even knows about
have a new question now but maybe i should switch to a new post
setting the widget component transform via set world location seems to work better than setting its transform via the blueprint viewport
because it offers more accuracy
and it is easier to place (less relative and dependent on your eye)
and it also seems to be dependent on your map size
(map size amplifies the relativity)
is there a way to convert between screen space and world space and back
i know how much i more or less want to offset the widget component relative to the actor in screen dimensions, not so much world dimensions
and i set the widget component transform in world dimensions not screen dimensions
so i more or less want to convert screen dim to world dim and add it to the widget component world location
Probably, with a bunch of math that accounts for FoV and resolution / screen dimensions.
Ditch the component, you get all the control:
Now you can manipulate both as you see fit as there is no component in your way.
1 Like
lol
thats why i love to talk to you you always suggest the opposite of what i decide to do
let me ask this. i think it will help me in the future
when do you use a widget component?
had it as a widget and not a widget component now
but the widget component moves better than the widget
the widget moves too strongly with the camera
widget component is more stable in that regard
What does it even mean? It sounds there is an issue with the way you move it. Without context and details the statement makes little sense (to me, at least).
Too many cases to write down. Generally speaking people choose a comp when they:
- want world space mode - the widget must be 3d; because it’s VR, because we have no mouse to interact with it, because product design dictates so, because it can look cool
- do not want to move the widget manually, they want it to auto track its owning actor (or any world entity) and it requires no (or infrequent) resizing
- need convenience, which actually comes with caveats - performance hit, additional maintance, increased memory footprint and complexity. And sometimes it’s very OK to go this way, sometimes you have just a few widgets and the price is negligable or you’re fine with the cost. Choosing the correct tool for the job and so on…
- they want the widget to work even when off-screen; non-component instantiated widgets do not tick outside of screen space. Comps help with this.
- since widgets are so volatile and their inheritance is an afterthough, the general consensus is to minimise scripting inside the widget. Their job is to show stuff and dispatch input, format incoming data but avoid any heavy lifting, rely on an event driven approach. An underlaying component can be overwritten and provides a means to the above - a layer where you can script logic that drives the widget.
- edit: auto
zSorting! Screen space widget components will actually do it for you automagically.
1 Like
i have a top down camera with large view as opposed to 1st or even 3rd person camera view so that large view has a significant impact
and when i move the camera away from the actor with widget, whether that widget is a component or full widget has a great impact then
It should not matter at all. If you need help, please demonstrate with script how you manually track the widget with no component.
i think you have given me enough pointers etc so i think i will manage from here
thanks
think i know better what it is about and what the ropes and tricks are
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.