Pixel Crushers Forum

Hello!

I'm very new to Unity and programming in general, hence I'm sorry if anything I ask for help here turns out to be very simple and easy to fix...

So, I've imported the Main Menu framework from the Dialogue System's extras page to my game and set it up by following the steps listed on Tony's first response on this other topic, but I had the following issues while trying to make it work as I desired:
⠀

• Clicks with the mouse still influence the game, even though the mouse is hidden and both the "Submit" in the Project Settings' input manager are set to be only the "e" key or the joystick button 0. If I'm selecting an option with the arrow keys, for example, the color of the button shifts to the pressed one whenever I press any of the mouse buttons, even though the option only follows through when I press the ones mapped to "Submit". This also happens in dialogues, in which the continue button's and the response options' colors flicker between selected and pressed. I couldn't find where to properly disable the mouse itself, so I included this here.

• When I open the quest log from the "Quests" option from the pause menu, the panel opens behind the menu instead of over it, while its resolution doesn't scale with the screen size even though the canvas of the Dialogue UI is set to do so. Also, my inputs can briefly go over to the pause menu buttons while the quest log is opened instead of staying "locked" inside the log's panel. The other options from the pause menu, such as Load Game, Quit Program, Options, etc, all work fine, appearing over the menu's panel.
  Ideally, I would like that my pause menu was a horizontal bar with its options sorted via a horizontal layout, which, when pressed, would open their respective panels in sort of a dropdown manner. I imagine I can do that by just messing with the panels' positions, sizes and layout sorting, so that wouldn't be a problem and could also circumvent the issue of having the quest log appear behind the menu (since they wouldn't be fighting for the same space in the screen), but that wouldn't solve the problem of the pause menu disputing inputs with the quest log and the problem of having the quest log under the semi-transparent black screen from the game pause.
  In conjunction with that, I would like to ask: is it possible to achieve a similar layout and appearance for the pause menu as the one shown in the image contained below by the method I said I could go by (only changing the transform component and such) or is something else needed for that to work?:
  Example Pause Menu

  

⠀
For a better understanding of the matter, I have recorded the problems I encountered:

Hi,

For the Quests button:

• Set the Dialogue Manager's Canvas > Sort Order to a higher value than the Menu System's Sort Order. This will put it on top of the menu.
• Or, better yet, create a second canvas under the Dialogue Manager and point the Instantiate Prefabs component's Parents field to that canvas. Set its Sort Order to a higher value. (Giving each UI its own canvas results in more efficient graphics rendering than putting all UIs in one canvas.)
• Or configure the Pause Menu's Quest button > OnClick() event to first call the PausePanel's UIPanel.Close method, then the Menu System's Pause.OpenQuestLogWindow:

For the mouse cursor, are you using any frameworks or other assets that control the mouse cursor? If you want to tell the Dialogue System to not control the mouse cursor's visibility, UNtick the Dialogue Manager's Input Device Manager > Control Cursor State checkbox:

Hey! Thanks for the quick response :)

I've applied what you advised. It worked for the most part, but there were some minor problems:

About the Quests button, I followed your instructions and made a second canvas under the Dialogue Manager for the Quest Log UI, later adjusting their sort order. The quest log correctly appeared over the Pause Menu, as I wanted! The scaling was still of, though, even with the "scale with screen size" mode, so I set the reference resolution of the Quest Log UI Canvas to be 1920x1080 (instead of the 3840x2160 I put before to match the Dialogue UI Canvas'), and doing that fixed the problem instantly.

Adding the configuration to first call the close method on the pause panel worked, getting rid of the issue of both panels disputing inputs. However, when I close the quest log with the "Cancel" button, it comes back to the pause menu and the game unpauses with it open, letting me move the player character while still navigating the menu. If i close the quest log with the "Submit" button while selecting the close button of the panel, though, the quest log closes and the game resumes without coming back to the pause menu. If I play directly in the gameplay scene, everything works fine, but this comes up when starting from the main menu. How could I make it so that when closing the quest log by any of the two methods, it leads me to the pause menu while the game remains paused the whole time?

Now, about the mouse cursor. I'm not using any frameworks or assets that control it. I unticked the Control Cursor State checkbox, but it made it so that the mouse was visible the whole time. Since my idea is that the mouse would be essentially disabled so as to not interfere with anything when inside the game, I made it be hidden by ticking the Control Cursor State back, setting the Mouse Move Threshold to 0 and unticking the Detect Mouse Control. But, pressing the mouse buttons was still getting computed, resulting in the change of color of the selected option's button to the one assigned to "pressed", as demonstrated in the video I recorded before. Clicking with the mouse doesn't actually activate the buttons, though, so it seems to be more of an aesthetic problem.

I managed to fix the issue I talked about previously regarding the pause menu and the quest log by configuring the following methods on the Quest Log's Standard UI Quest Log Window > On Close():

Now the pause and the quest button work as intended! :)

Hi,

Great! Sorry for the delay in replying. I'm glad you got that one settled.

For the mouse cursor, if you want the mouse hidden and locked away at all times, inspect the Dialogue Manager's Input Device Manager component. Set Input Device to Joystick. UNtick Detect Mouse Control.

Hello.
No worries, your help is greatly appreciated!

I've done what you instructed, but, regardless of where the mouse is located or if it is hidden and locked, clicking with it still entails in that flickering behavior of the selected button's colors.

I attached an image of my Input Device Manager down below so you can see if I followed along correctly or if there's anything out of place:

Input Device Manager

I first thought that maybe this was just something that pertained to the Unity Editor, so to check I ran the current build, however the issue persisted. It is something very minor, though, and since the clicks don't really do anything besides the visual change of the buttons, it's alright if there's no specific fix for it in the Dialogue System's configurations.

Try disabling or removing the Canvas(es)' Graphic Raycaster components. This will make them ignore mouse clicks.

Hey!

I tried disabling the Graphic Raycaster components, but that didn't solve the problem either, so I looked up possible solutions to this in Unity Answers and found someone with the same issue: https://answers.unity.com/questions/119 ... input.html

I just had to make sure that the new Event System with the keyboard-only input module script, talked about in that post, was present in all of the scenes for the solution to work like a charm. Before, I was leaving the Event System to be automatically created by the framework, but that resulted in the generation of a default event system, which seems to accept mouse inputs alongside keyboard inputs even though there was no Graphic Raycaster to compute them. Now, everything works fine.

Thanks for your help!

Hmm, without Graphic Raycasters the canvases shouldn't have been able to detect mouse input. Maybe something was enabling or adding Graphic Raycasters back onto the canvases. Anyway, your solution is solid because it guarantees that there will be no mouse input.