The title is self-explanatory on what I’m asking. I have a computer actor in the game that I want the players to be able to interact with and use like a ‘real’ desktop. I’m not talking about being able to go on a real website, but that the computer has a desktop with different icons representing softwares, clicking on any opens a tab that you can move around and interact with within the desktop.
I made mine with 3D interacting widgets and I was able to make certain opened softwares movable. But I couldn’t figure out things like how would the widget know which open tab is the player focusing on? (since im stuck now with being able to move all opened tabs rather than specific ones at a time).
The question then is, how would you go on about it ? I’m looking for things like being able to open multiple windowed tabs and moving them one over the other. If you click on a tab it gets the highest zorder and etc.
Its a loaded question but its something I would love to learn how to make as I can use it for future projects as well.
Oh that looks perfect! But there are a few ‘issues’ I rant trying to implement this system.
The main issue is that I realized the guy is generating multiple copies of the same widget, and using their object reference to implement the code.
With my case, I would be generating different widgets in different ways (unlike the guy’s solution of creating multiple copies of the same widget), all still behaving the same way as the guy have shown.
Since you can’t create a widget blueprint child apparently (or I don’t know how compared to making child actors for example) I’m stuck trying to figure out how I can have multiple widgets behave the same way and how to reference them in the main widget (the monitor of the computer actor) in order to implement the guy’s code.
The main issue is that I realized the
guy is generating multiple copies of
the same widget, and using their
object reference to implement the
code.
With my case, I would be generating
different widgets in different ways
(unlike the guy’s solution of creating
multiple copies of the same widget),
all still behaving the same way as the
guy have shown.
It was just for the convenience of the example. It does not matter what those widgets are for as long as they’re sitting in the canvas.
Since you can’t create a widget
blueprint child apparently (or I don’t
know how compared to making child
actors for example) I’m stuck trying
to figure out how I can have multiple
widgets behave the same way and how to
reference them in the main widget (the
monitor of the computer actor) in
order to implement the guy’s code.
You can but the feature does not work the way it works with actors (it’s not proper inheritance, sadly). You can reparent widgets:
This means that the children will inherit variables and functions but not the hierarchy…
generating multiple copies of the same
widget, and using their object
reference to implement the code.
Instead of dispatching a widget of specific class - Grabbed Window, dispatch User Widget instead - we really only care about it being a valid canvas slot. Essentially this…
Oh! I didn’t notice, thanks a lot for the replies and help!
And this might be very noob of me to ask, but I want to make sure I understand the process here and how it works.
Would the setup for this system be that I set up the event dispatcher in a parent widget blueprint. then I reparent any other widget to the parent widget, allowing me to implement the system with different widgets and have the dispatcher trigger in the main widget blueprint (the Monitor Widget for example, that holds all the other widgets) ?
And I achieve that by dispatching a User Widget so it becomes type-agnostic in the Event Dispatcher? (adding the Grabbed Offset as a dispatcher data as u mentioned as well)
Wouldn’t that be done already by having those different widgets just be child blueprints of the parent one?
I was not clear enough about this one, my bad. If there was just a few widgets, I’d probably be ok with some casting. You’d need to manually add a dispatcher to every widget type - painful but doable
In regards to the rest of what you said, I had the same exact inclination!
We could also create the widgets or have them already present on the main one and the behavior would still be the same? Cuz I usually do the latter and just set them to invisible, making them visible only when I need to interact with them
Regardless, I’ll set it up on my end and see if it works. But I think you’ve answered and solved my main issue so thanks a lot for that! I’ll set this post as answered once I’ve tested it and see how it preforms
Okay so I tested the code and it seems to work! the only issue I’m having is the widgets seem to ‘jitter’ around between two locations: the one where our mouse currently is dragging the widget, and an arbitrary location.
When the widget is released however, it settles on the same spot we put it. So the jittering only occurs when moving the widgets around. I’m checking the code and all but everything seems as intended
Would the setup for this system be
that I set up the event dispatcher in
a parent widget blueprint. then I
reparent any other widget to the
parent widget, allowing me to
implement the system with different
widgets and have the dispatcher
trigger in the main widget blueprint
(the Monitor Widget for example, that
holds all the other widgets) ?
Precisely, nicely put!
And I achieve that by dispatching a
User Widget so it becomes
type-agnostic in the Event Dispatcher?
(adding the Grabbed Offset as a
dispatcher data as u mentioned as
well)
I was not clear enough about this one, my bad. If there was just a few widgets, I’d probably be ok with some casting. You’d need to manually add a dispatcher to every widget type - painful but doable.
But here’s the version with inheritance and reparenting.
This is my setup:
ParentCanvas is where the widgets sit (the monitor thingy)
wMyUserWidgetBase is the base class which can dispatch a reference to its own type (and, by extension, all inheriting children):
There might be some disparity between onMouseMove which is called every frame and Tick which is also called every frame. Using stale data during Tick could be causing it, hard to tell.
Could you test it by setting position of the grabbed widget in the onMouseMove rather than during Tick?
jitter
Is this jitter closer to 1px jitter / crawl or it seem to want to snap to the upper left corner of the screen kind of jitter?
the jittering seems to be happening randomly. Testing it a few times, it can sometimes snap to the corner but it sometimes snaps to other random locations. Sometimes near where it currently is but sometimes further away.
The solution seemed promising but only temporary. I noticed while testing it out that if i pressed at a location on the screen, then went to grab the window and move it around, the window would jitter and snap to the location of the first mouse click.
It’s a consistent pattern. It sometimes doesn’t let go of the grabbed window when i release the mouse button, prompting me to press and release again in order to let go of the grabbed window.
The solution seemed promising but only
temporary. I noticed while testing it
out that if i pressed at a location on
the screen, then went to grab the
window and move it around, the window
would jitter and snap to the location
of the first mouse click.
It’s a consistent pattern. It
sometimes doesn’t let go of the
grabbed window when i release the
mouse button, prompting me to press
and release again in order to let go
of the grabbed window.
Sounds odd. Can you show how the onMouseMove looks like now?
Not really, sorry. This just works fine on my end. I do not observe any jitter or undesired behaviours. Also, this is a method I use regularly for shifting stuff about.
Can’t recall if it was mentioned above but UE 4.26 does have new & regressing bugs for UMG specifically. I know about 2 first hand, perhaps this is another one.
Is there a chance you could demonstrate the behaviour you’re experiencing in a clean project?
I noticed while testing it
out that if i pressed at a location on
the screen, then went to grab the
window and move it around, the window
would jitter and snap to the location
of the first mouse click.
Okay so i think i figured out what was causing the issues I’m having.
I failed to mention that I’m working with a 3D widget, using the widget interact component on the character and putting a widget component on the Computer actor.
It seems your codes for getting the position of the mouse from On Mouse Move function was causing the issue. Every time I released the left mouse button, the widget interaction component would stop following the mouse and would stay focused on the area I released the mouse button over.
Disabling the functions codes for getting the grab offset and mouse move position fixed this issue. It seems the code isnt compatible when using the widget interaction component. What could be the alternative to this ?
@Everynone I’m sorry for dragging this forum on for so long btw
Every time I released the left mouse
button, the widget interaction
component would stop following the
mouse and would stay focused on the
area I released the mouse button over.
Ah, that’s pretty cool actually (in a bad way). But I learnt something.
Disabling the functions codes for
getting the grab offset and mouse move
position fixed this issue. It seems
the code isnt compatible when using
the widget interaction component. What
could be the alternative to this ?
So we’d need an offset from where the interaction component traces against the quad of the widget component and translate this into a 2d offset? Ha, this is going to be neither pretty or easy.
Nothing comes to mind atm; would have to grab a cuppa on a Saturday morning for this. On top of that, I’ve worked with the interaction comp just a few times, and never with anything serious. Pretty sure it has quirks of its own, too.
How jarring would it be if you got rid of the offset and held the widget by its centre only?
So we’d need an offset from where the interaction component traces against the quad of the widget component and translate this into a 2d offset? Ha, this is going to be neither pretty or easy.
Yea I don’t think I’m advanced enough to even figure out how to do this. But if there’s a way or any documentation I can read, I can give it a try.
How jarring would it be if you got rid of the offset and held the widget by its center only?
Well I guess its not ideal but can see how it would look? It wouldn’t be the exact functionality but I guess my other choice is to either attempt to figure out how to implement the code with a widget interaction component or change the overall functionality of the computer actor.
Pretty sure it has quirks of its own, too.