I’ve found myself in several cases where I wish that you could separately set the border transparency.
I want to make buttons with a rectangular border but I wish the background to be transparent. This is currently not possible.
As an example of what I’m talking about, see the CND, RAD & EFF buttons here:
Was going to make a feature request but found this in the search. Having to use four frames to create a simple border outline for a transparent frame is not cool ): BorderTransparencyModifier pls
As you can see, the border in the inner frame is nearly invisible. I want to make it visible, but then I would have to create frames in order to get around this!
I was going to request exactly this, but then I found this… better to bump I believe.
Instead of having a BorderTransparencyModifier and having to make calculations, why not simply have a BorderTransparency value, that ranges from 0 to 1, and keep it independent from the BackgroundTransparency?
Yes dav, and what about old games? What do we do to ensure their GUI’s aren’t changed or damaged?
Uhh, upon the update, when creating the values, keep BorderTransparency = BackgroundTransparency. As simple as that I believe.
So perhaps, would you like this feature to be released?
Thanks for the heads up on the polls. I will consider that on future posts.
I admit the existance of that issue, but that’s not a thing that has no solution. If we could do this, using a boolean property to determine whether the system will use the current behaviour (BorderTransparency == BackgroundTransparency) or the requested one (BorderTransparency and BackgroundTransparency are independent) would be the solution. This has two advantages in my view:
If defaulted to the current behaviour, old code wouldn’t break;
People who still wish to use the current behavior do not need to change their code.
We try to avoid boolean properties whenever possible because they’re a red flag we’re not implementing a change properly. A toggle between old/new behavior is great when we truly need to toggle between them (FilteringEnabled/PGS Physics Solver), but not when old behavior is clearly inferior to the proposed changes. We want to hide obsolete behavior instead of bloating the API with tons of toggles for every feature change – imagine if we had booleans to toggle border transparency type, enum/int font size, whether to use a custom anchor point or not, and even more GUI features.
In this case I think a much better approach is to deprecate all border-related properties and move them into a UILayout. Existing GuiObjects would retain their appearance, and existing scripts would still be able to modify these properties. GuiObjects inserted from this point out would default to having no border (BorderTransparency=1). Inserting a BorderUILayout into a GuiObject would overwrite its deprecated border property settings and would be the new way of creating a border. This would also allow us to expand on border features e.g. corner radius without cluttering the properties window of GuiObjects.
Im so sick of making new frames to make the appearance of nontransparent borders, I now keep a copy of premade borders on stand by because it’s a nuisance to keep remaking it for this ackward behavior. I never use ROBLOX’s borders, I’m always turning them completely transparent for years because of how they behave.
