Hi @noot20000 - thank you for the bug report and for the video demonstrating the issue. This is an issue where AutomaticSize is incorrectly taking the canvas size of the scrolling frame into account rather than the ScrollingFrame’s Size property. I’m working on a fix for this right now - if you have time to attach a place file, I can verify whether the fix I have will resolve the issue (I believe it will, but good to double check).
Hi @BoxBloxes - there are a few reported issues of UIScale not working properly with ScrollingFrame. If you have time to create a place file that reproduces this issue, that would be great!
I found that when using UIPadding with a frame that has automatic size, it does something weird the first time I open the UI. As soon as I interact with it though, it gets back to normal.
The only way I found to go around this bug is to use create my own paddings and not use the UIPadding Property.
Having issues with this feature. With TextLabels, I can’t get the AutomaticSize to work as expected; it either remains the same size or becomes extremely wide (much longer than the actual text’s length).
I’m also having trouble getting it to work as expected in this situation. I select the descendants of the Frame I want to have AutomaticSize X on at the start to show their total size. Then I toggle AutomaticSize on & off near the end of the video. As you can see, it extends far past the boundaries of the actual contents.
It seems like UIListLayout breaks the property somehow, making it think that its contents are much larger than they actually are.
Hi @gui110 - we’ve noticed a few issues similar to this where the layout state isn’t updating until interaction occurs. We’ll get this resolved! Thank you for the bug report, and for your patience.
Ideally, I wish this could be extended to all UI constraints, with a toggle for each, so I wouldn’t have to work off of a hacky solution using folders. But really, anything to just blacklist AutomaticSize would seal the deal.
Hi!
With AutomaticCanvasSize enabled is there a known way of getting the CanvasSize of the Scrolling Frame? When enabled it sets the CanvasSize property to {0,0},{0,0}, and I don’t want to find the CanvasSize using math when its already being computed. There is a AbsoluteCanvasSize property, but it is locked and only useable by CoreScripts, which is a shame.
Hi @gui110 , we have recently deployed a related fix, you can probably try updating and verifying if that resolves your issue. Please let us know if you have any questions or updates. Thanks!
I’ve noticed an issue with AutomaticSize which may(???) be related to using a UIListLayout inside a frame that’s being automatically resized. I say may as the difference between the expected and actual size gets larger as more GuiObjects are added to the frame, as though there was some kind of padding issue.
Here’s an image of the issue, the red outlines are UIStroke’s parented to the AutomaticSize Y Frame:
Hi @rachjumper , we are currently looking into cleaning up Automatic Size issue and trying to enable this feature for all games. So if possible, could you please provide a place file or rbxm file that contains the structure of the control panel in this picture
, where we have found AutomaticSize doesn’t seem to work well with. (any other place files you’d like us to verify with are also welcome!) So that we can make the fix and verify it for you. This will ensure that our future update won’t break your game again. Thank you!
Edit: I’ve found one bug exhibiting this behavior that is definitely a bug:
I’m running into some cases where AutomaticSize is changing due to descendants’ sizes instead of just childrens’ sizes. Is this intentional? It’s making it very difficult to add traditional Roblox UI effects. It seems to go against how the rest of the Roblox UI system works. I’m having to resort to Lua sizing code now to handle these weird cases.
Particularly, I have a case like this:
A: AutomaticSize XY
B: AutomaticSize None {0, 100, 0, 100}
C: AutomaticSize None {0, 100, 0, 500}
For some reason, C being large affects A’s size. I would intuitively expect A to only rely on B’s size, and if I want A to rely on C’s size, then I need to do that by setting B to AutomaticSize too.
As it is now, I’m having a lot of difficulty making this work for stylized UI since adding any effects, images, shadows, etc. even as children of non-AutomaticSize frames is causing size to change.
There are things I want to add to the UI that I’m working on that shouldn’t affect sizing and should only be auxiliary, visual elements. I can’t add these things right now due to the above issues.
Some common cases you might see this sort of thing done, and why it’s necessary. All of these are typically added as children to a frame:
Adding a background to a frame
Adding a visual flair to the top right and bottom left of a frame. Think a 100x100 image that moves with the edges as the frame resizes (automatically!)
Adding a “notification dot” or other “notifier” element – you’ll typically see these at the top right or top left of a frame, half-way off of it so as not to block the readable content
Adding a background that’s bigger than the frame itself
Adding drop shadows. These often go outside of the frame they’re added to.
Adding “depth” to buttons or frames. These sometimes go outside of the frame they’re added to.
Adding an upper- or lower- overlapping element, especially one that is a similar size to its parent frame
It looks like the behavior I’m experiencing makes it impossible to combine any of the above with AutomaticSize.
I’m having factual trouble with some of these, and I’m sure the issue(s) I’m experiencing affects all of these. The only behavior I’m sure is confusing and wrong to me is the “automatic size depending on descendants (instead of just children)” behavior – I’m really hoping that’s just a bug, right? Or non-finalized behavior?
This is actually quite a big issue the only thing that you need to reproduce this to its full extent is to just add around 30-40 gui objects in scrolling frame that has AutomaticCanvasSize enabled.