I just upgraded to 4.9 from the latest 4.8.
Different from 4.8, 4.9 the UI swallows mouse events, even if there is no visible widget. This menu is composed of several UserWidgets, all their canvases cover the whole screen.
The lamp actor in the middle should receive OnBeginCursorOver(), OnEndCursorOver() and OnClicked(), which is not happening anymore. Worked perfectly yesterday with 4.8.
If I hide the whole menu (SetVisibility(ESlateVisibility::Hidden) ) the messages come as expected.
sorry for not checking back sooner and thanks for your effort.
I did some more testing and found out:
Even if the menu does not have any widgets at all and also does not have a canvas the problem still persists. Only hiding or collapsing it allows for mouse messages to reach the actor in the world.
Extensively clicking on the actor lets it receive OnBeginCursorOver() and OnEndCursorOver() sometimes, but never OnClicked().
1.) Create a FirstPerson example project in 4.8
2.) Convert it in place to 4.9
3.) Set up the PlayerController to receive mouse events using this tutorial: Mouse Control Setup | Unreal Engine Documentation
4.) Create a C++ based Actor and add mouse event handling (see ‘MyActor.cpp’ in ‘Source.7z’)
5.) Create a BP Actor based on C++ class MyActor.
6.) Change the AFirstPersonGameMode.cpp like in ‘Source.7z’, so that a BP Actor is spawned and mouse cursor is shown in StartPlay()
7.) Disable AFirstPersonCharacter::OnFire(), (see ’ AFirstPersonCharacter.cpp’ in ‘Source.7z’)
8.) Create a UserWidget BP. Add nothing to it. Canvas only in enough.
9.) Create BP from your AFirstPersonCharacter if not already there.
10.) In the BP of AFirstPersonCharacter at event StartPlay spawn the UserWidget BP, set it to viewport, and SetVisibility to hidden.
11.) Compile and Start simulation. There should be a box spawning near the player. If you hover the mouse over the box, the cursor should change. If you click on the box, it should disappear.
12.) Change the BP of AFirstPersonCharacter. set the visibility of the UserWidget to visible.
13.) Compile and start again. This time the box should not receive mouse events.
Thanks for taking your time. I am not an expert, but I’ve slimmed it down to 700mb zipped and 1.3gb unzipped. Can’t share publicly, but have private link via dropbox.
You can email me and I’ll reply back via max at fullbeast . com
ok, I boiled down the project as much as possible and uploaded it (25MB):
When loading it in the editor, it will ask you to rebuild missing dlls. Just rebuild, it should work.
When the editor opens,it will complain about missing content in the StarterContent. Just ignore the warning, the projectile will not be instantiated.
To test:
1.) start simulation. A box should fall down near your character.
2.) hover the mouse over it. Mouse cursor should change. Click on it. Box should disappear.
3.) Stop Simulation.
4.) open Blueprint: /Game/FirstPerson/Blueprints/FirstPersonCharacter’
5.) At the end of the execution queue of Event Begin Play SetVisibility to Visible
6.) Compile and restart simulation.
7.) The box does not react to the mouse now as it should be. This is the bug.
The menu that is created at 5.) is just a UserWidget that contains a canvas. It is probably swallowing all mouse events to the world.
After looking over your project I was able to find that this issue you are are experiencing (in the project provided) is due to the widget being set to visible. The canvas panel by default is set to “Self hit Test invisible” This means that it is “visible” to the player but only as art (does not consume click events) and that it only effects itself (not its children). This means that when you set the widget to visible (as seen in the screen shot from your project below) it will set all widgets in the widget blueprint to “Visible” this includes the canvas panel. The “Visible” setting allows widgets to interact with the cursor. This means that it will then consume mouse inputs. You will need to make sure that the canvas panel is set to “Self Hit Test Invisible” to avoid this problem. I hope that this information helps.
Nope, that wasn’t it.
Checked it in my main project. Set all canvases to SelfHitTestInvisible by hand after changing visibility. Bug still remains.
Btw this would have meant a major design change, because in 4.8 the canvas obviously didn’t change visibility with it’s parent widget, because everything works like a charm.
Ok, I’ll stick to 4.8 until someone fixes it.
Thanks for your help anyway and have a nice day.
Solved it!
I previously tried to set only the canvases of the menus to EVisibility::SelfHitTestInvisible, but that didn’t do it. Setting the whole menu instead of canvas worked like a charm. Interestingly it’s buttons still work if menu is set to EVisibility::SelfHitTestInvisible, so visibility seems not to be propagated through hierarchy.
