Currently I’m using UIScale as a way to easily scale my UI across platforms. If you have a UIScale instance inside of any GuiObject, it does not respect the Max/MinSize of UISizeConstraints. If this were to be fixed, scaling UI properly could be done extremely quickly with little-to-no effort.
A temporary workaround is to destroy the UIScale if the AbsoluteSize exceeds the MaxSize, but it would be a lot easier to not have to do this. Thanks for your time!
I think I actually assume that the UISizeConstraint is not respected right now (.i.e. scaling occurs after all other stuff), but situationally it would be nice to change this behavior for the reasons outlined above.
Hi @unroot - the way UISizeConstraint is described here, it does sound as if it should be enforced when scaling is applied:
For example, if the MaxSize is set to {200, 200} and the MinSize is set to {100, 100} , then the constrained GuiObject cannot scale to be larger than 200 pixels wide and 200 pixels tall or smaller than 100 pixels wide and 100 pixels tall.
I’ve filed a bug to investigate this. Thank you for reporting this issue! Take care.
Hi @DrRanchDressing, I was just wondering if there had been any update in the progression of fixing this bug. I just recently ran into it, and I am not sure if there is any other way to solve my issue.
I currently have some UI, scaled using UIScale similar to OP. Inside of the UI is a Holder, with ClipDescendants set to true. In the Holder is a series of grid images which need exact sizing (for a minimap UI), but these are being scaled by the UIScale, which is not wanted, as it affects my calculations. I was expecting that adding UISizeConstraint would force these images to be of a constant size, but that is not the case.
@DrRanchDressing Hi, could we get a status update on this issue?
I use UIScale for all my UI, and its scale is dynamically changed as the screen resizes. This has advantages over using normal scale sizing. I want to easily use a UISizeConstraint to limit the maximum size of the UI.
Hi @Qualadore - thanks for bumping this thread. This bug is still in our backlog and hasn’t been prioritized for a fix yet.
I agree this behavior is confusing, or at least, the wording of UISizeConstraint and MaxSize is misleading.
Does it make sense to have a UISizeConstraint that is scaled by UIScale? For example, if you are authoring UI purely in offsets, you might apply a UIScale at the root of your elements to provide a scaling for multiple screen sizes.
That being said, an absolute cap on maximum size is valuable as a use-case as well. One concern is that if we “fix” this behavior, this could break existing games that rely on the current functionality. So one challenge for resolving this is identifying a way to expose the fix in a way (new property, component etc.) that won’t break existing games.
Either way, this is something that I’ve bumped in our backlog and hopefully something we can address soon. Appreciate your patience with this!
Thank you for your reply, I really appreciate the attention to this issue.
This is what I do, designing UI in offset for the smallest supported resolution, then dynamically adjusting the UIScale factor as the screen resizes (fitting it to maintain aspect ratio).
An upper limit would prevent some UI designed for small phones from scaling too large on a normal desktop monitor. While my code could impose an upper limit for UIScale factor, one UIScale may control several distinctly sized Frames. UISizeConstraints in those Frames would be a solution to this if this behavior changed.
Hi @Qualadore - thank you for the reply! So you would need UISizeConstraint to be configurable (essentially) to work with both use-cases:
1/ Allowing the size constraint itself to be scaled by UIScale, and
2/ Ignoring the effects of UIScale (in other provides, provide an “absolute” upper limit on size)
@Qualadore got it. Thanks for the reply! We’re hoping to get some additional resources to address our bug backlog early next year. I’ve bumped this in our backlog for now, thanks again for the info and hopefully we can get this resolved relatively soon. Appreciate your patience!
