UI is clickable now and I cannot build with this system


#1
  • I use GUIs in my game to change the brightness and mood. I enable these early on as I build so the build can seamlessly work with the UI I’m going to apply. These are full screen images which include but are not limited to vignettes. I can no longer work on these builds as long as this UI is clickable. It makes Studio feel extremely broken that I cannot click anything in my world. Active and Archivable properties do nothing to stop this, and deleting or reparenting the GUI is not a solution.

  • In the case that this change is unintentional. I’m on MacOS on the latest software. This has just started happening tonight after the update.


Release Notes for 342
New Updates for the UI Editor
#2

I can’t deal with it, I was fine all day until the update when I opened studio and now it opens the UI editor thing every time I click a UI element and it puts yellow squares everywhere…


#3

What I’d do is turn ShowDevelopmentGui off as its a property of StarterGui but now has its own button for it.


#4

This doesnt help because now all my UI is gone


#5

I need the GUIs visible, it affects what I’m working on. It’s why I have them on in the first place when building.


#6

It helps with the building problem but in my opinion this update is more useful to people new to UI development as when I am working on small UI the yellow boxes get in the way.


#7

I think that this feature should be able to be turned on and off by the user rather than being enabled by default. It is a pretty cool feature, but can be annoying for instances such as this one.


#8

This does not help, I could have just reparented, disabled, or deleted the GUI. We want the images visible while we’re working on the build behind the images.

It’s great for when you’re working on UI, but it should not always be on.


#9

I was going to make a thread about this and ask how to get rid of it.

I am using a Plugin to help me with Positioning Gui Objs and this new Feature breaks it by overriding it…

Jeez add a Setting so we can Turn it On or Off, isn’t that mandatory why do we even have to ask for this kind of stuff… it’s annoying!

Remember the “Plus Icon” at the end of every Instance in the Explorer?

That’s annoying and we had to ask for a Setting so we can Turn it On or Off.

I don’t understand why you Engineers keep making the same mistake.

Don’t get me wrong the new Features are helpful but they aren’t perfect, they could be better is what I’m saying.

I really like this new feature it’s really good but the downside of it is you can’t turn it off which is annoying more than helpful it’s harder to work while it’s always On.


#10

I’m sure it was just an oversight. It’s hard to cater to all work flows :grimacing:


#11

Ive just ran into this problem like 20 minutes ago. Its really annoying to use for me, and i have to disable development gui so i can use the 'Class Converter" plugin.

Just please add a On/Off feature


#12

I just hope that the person behind this new Feature will add a Setting so we can Turn it On or Off soon, so everyone can be happy :grinning:


#13

I like the update where I can make all my UIs invisible without having to put them in the ServerStorage but I agree a lot of my UIs are broken now as well


#14

I love this update, but it was a massive oversight to release it with no way to turn it off. It’s like having parts without having the Locked property - it gets incredibly frustrating when trying to click and drag.

Speaking of clicking and dragging, why can’t we select more than one element by clicking and dragging the selection box?


#15

StarterGui.ShowDevelopmentGui has been a feature for a long time.


#16

You may want to consider parenting your UI in CoreGui instead


#17

@asimo3089
The changes are intentional indeed - we are trying to make UI development easier for everyone. As you noted, it’s difficult to know all the possible workflows in advance, so first, Thank you for bringing up this case.

I’d like to know more about your situation. Why do you use UI to change the brightness/mood of your scenes instead of lighting?


#18

I think Volt shows really well how big of an impact these GUIs can have for builders. We don’t want these disabled while building because it affects how the game itself looks.

In Volt, we’re using multiple fullscreen layers to simulate old television screens. This includes fuzzy horizontal lines, a central glow and darkened “vignette” edges. These effects have (in my opinion) large affects to the quality of the build and I find it really important I keep them on while building. These layers begin to bring out objects like clouds that’d normally be hard to see. I’ve provided a “with” and “without” below showing the impact these images have.

Without the layers, I can’t anticipate how the game is looking while it’s being built.

These are best viewed fullscreen to show the true difference and I hope it shows well in screenshots. Take note how the tiles change color, and clouds change in visibility depending on these layers.


#19

Its also a pain to have the UI editor open and have yourself accidentally change a UI element without noticing when your entire workflow is based off editing UI in the properties tab…


#20

Interesting! Ok, thanks for those screenshots.

I was trying to see if your issue would be better solved by having different lighting options, but it sounds like you would be better off with a “Locked” equivalent for UI objects, as Chaotic_Cody mentioned. (I’ll share your post with our Rending Team anyway so they can take this into account when devising future Lighting improvements)

However, if we implemented “Locked” for UI objects, that would not solve your issue, as (just as with Locked parts) the Locked UI would block clicks. It sounds like you need a property on UI that would allow clicks to pass through?
Would said feature have other valuable applications outside of this case?