0
\$\begingroup\$

This is my first time using Unity (and my third time creating a game in general), so I hope I can provide the needed information to solve this problem. This is my options menu When I start my game normally through the Unity Editor (is this the right name?), everything works fine. Everything is interactable and the functions behind the buttons, dropdowns etc work as well. Since I can't test resolutions, fullscreen inside the Unity Editor, I decided to build my game and test it there. Everything still works fine, but the Options A Dropdown (this shows the resolutions), the Fullscreen Button and Graphics Dropdown arent interactable anymore.

After some testing myself, I found out, that the functions still work. If I click on the volume slider and go up through the WASD Keys, then I can still use the UI Elements and functions behind them still work.

What I tried:

  • I got the help to put my Event System to "Always enabled", which didnt helped.

Side Information:

  • The dropdowns are from Textmesh Pro, dont know if this is important or not.
\$\endgroup\$
4
  • \$\begingroup\$ Not an answer! But i guess this might be the problem of Unity Alpha version as you are using "Unity 2019.3.0a3". 'a' in the version stands for Alpha. so i suggest try this project unity stable version may be "Unity 2019.2" . \$\endgroup\$
    – Swati
    Sep 26, 2019 at 11:37
  • 1
    \$\begingroup\$ What you are describing sounds like you have another UI component on top that consumes your clicks. But can't verify this in given image. Depending on your setup of your rects, you could in theory get unintended overlaps on different resolutions or aspect ratios. Text consumes mouse events by default, meaning that if the text rect (not the actual text) overlaps a button, it will consume your input. To check if this is your problem, make sure that 'Raycast target' is disabled on the text components that can't be interacted with, like 'VolumeText'. (in tmp_pro this sits under extra settings) \$\endgroup\$
    – troien
    Sep 26, 2019 at 11:51
  • \$\begingroup\$ Yes I use the alpha version. Does switching to the stable version not ruin my whole project? The only two things in my scene is my "MainMenu" GameObject and my "OptionsMenu" GameObject. I just checked the Textmeshpro text and yes.... there was is Raycast target and YES this was the answer. Didnt even knew, that was possible. \$\endgroup\$ Sep 26, 2019 at 12:10
  • \$\begingroup\$ @troien your comment seems to be an answer to the question. I suggest write it down as answer so other people may get some help of it. \$\endgroup\$
    – Swati
    Sep 26, 2019 at 12:39

1 Answer 1

0
\$\begingroup\$

Based on the comment I gave earlier, I'll write a more detailed answer here.

The description you gave often means that 'something' is in front of the buttons you are trying to interact with. If this only hapens in build, this could be because the build runs at another resolution or aspect ratio. When creating your UI, you should make sure that you support all resolutions that you want to support.

This problem is easy to spot when an Image is overlapping a Button, as you can see that on screen. But when a Tex Rect (not the actual text) is overlapping a Button, you can't see that in build (or game view), making it harder to spot whats going on while (by default) Text components do consume pointer input.

If this is indeed the problem, then there are 2 ways to fix this.

  1. Make sure that the 'something' that is consuming the input doesn't consume input if it doesn't need to. For any graphic component, including Text components, this can be done by unchecking the 'Raycast target' checkbox. (For textmesh pro, this checkbox is under 'Extra Settings')
  2. Make sure that the 'something' doesn't overlap the button. This involves changing values of a RectTransform, but which RectTransform and which values depends on your exact setup. This usually happens when you give something a fixed pixel size, which can unintentionally start to overlap other items when your screen gets smaller.

Option 2 would be the best fix for the actual problem in my opinion, that being said, option 1 is a simple quick fix and is something you could opt to do for performance reasons anyway.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .