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.