I have a character selection widget that shows up first, then the camera shifts to my character where another widget pops up. However, the second widget hides/disables the mouse no matter what I throw at it.
My first widget ends like this:
This is how I trigger the second widget:
And this is the construct of the second widget:
Anyone have any idea why the second widget fails to show/enable the mouse?
Thanks in advance!
One thing I’d try is swapping the order of the calls. Set Input Mode UI Only first, then Set Show Mouse Cursor. In some cases the input mode call can override cursor settings.
I also noticed several Set Focus nodes. Unless you specifically need them for keyboard or gamepad navigation, I’d temporarily disconnect them while troubleshooting. They shouldn’t affect mouse visibility, but removing them helps eliminate another variable.
Minor point, but inside widgets it’s generally preferable to use Get Owning Player rather than Get Player Controller, since it guarantees you’re using the PlayerController that owns the widget. In a single-player project both usually work the same, though.
If changing the call order doesn’t help, I’d search the project for any other Set Input Mode Game Only, Set Input Mode Game and UI, or Set Show Mouse Cursor nodes that might be executing afterward (PlayerController, Level Blueprint, Character, or another widget).
If you’re not sure whether another widget is being created, you could temporarily use Get All Widgets of Class (UserWidget) and print each widget’s display name. It’s a quick way to verify which Widget Blueprints are currently active and whether you’ve accidentally created multiple instances.
DonBusso,
Thank you for taking the time to write a thorough suggestion. Unfortunately, none of these worked but I greatly appreciate your time.
I did manage to find a solution but to me it seems like a hack. When I put a small delay after my Widget Construct event, it works as intended. However, this doesn’t seem like an appropriate solution…
Above is the code flow in my widget class that ended up working.
Any idea why this worked?
Definitely agree with the point above regarding the Set Input Mode call order. I’ve run into similar issues where changing input modes mid-transition ends up overriding mouse visibility. Quick question is that second widget built using Common UI by any chance? The cursor visibility logic there can sometimes act up depending on the widget’s activation settings.
Both widgets are built the same, using the in-engine tools? Not sure what common UI is specifically.
