@CycloneUprising @Subcritical_alt Most of my plugins are broken until this gets fixed
Will spend some time on this on Monday. Will also turn off what I suspect is related FFlag.
Can you post minimal plugin that displays this problem? Like simplest possible example?
I also can’t test to see if this plugin in particular was one that broke because you flipping the flag fixed it, but the first link is a simplified example, and the second link was definitely breaking.
OK now I am little confused:
I have not done anything yet (no fflag flips to turn off FFlag).
So you are saying that the problem seems to be fixed now?
If so, it must be unrelated to the FFlag it was related to last time, as that FFlag is still on in prod.
Please clarify?
Yes, it did seem to fix itself for some reason. So if you didn’t change any flags, that’s really weird, and I’m not sure what fixed it.
@DataBrain Just curious:
“It could also be the fact that I use the same plugin toolbar (“Databrain’s Plugins”) for multiple different plugins.”
How do you do this? When I write two different local plugins and both create a toolbar with same name, e.g.
local toolbar = plugin:CreateToolbar(“Shared: Two Button Toolbar”)
it just winds up making two different toolbars that happen to have the same name.
As far as I know, there is no support for two different plugins writing buttons into the same toolbar.
How are you doing this? Or am I misunderstanding what you’re saying?
If you somehow make the toolbar referable from other scripts, you can just call CreateButton on it from another plugin. This can be done by parenting it to CoreGui, tagging it with CollectionService, etc.
Plugin 1:
local tb=plugin:CreateToolbar("My Super Cool Toolbar")
tb.Name="My Super Cool Toolbar"
tb.Parent=game:GetService("CoreGui")
tb:CreateButton("plug1","this is a test","")
Plugin 2:
local tb=game:GetService("CoreGui"):WaitForChild("My Super Cool Toolbar")
tb:CreateButton("Button2","test","")
And here’s a function that can be used in place of CreateToolbar if the user isn’t guaranteed to have both installed:
function createToolbar(name)
if not game:GetService("CoreGui"):FindFirstChild(name.."TB") then
local tb=plugin:CreateToolbar(name)
tb.Name=name.."TB"
tb.Parent=game:GetService("CoreGui")
return tb
else
return game:GetService("CoreGui"):FindFirstChild(name.."TB")
end
end
OK Yikes I didn’t realize that was a Thing.
@DataBrain are you trying to add two different buttons with same id to this toolbar? Like in two different files,
local button01 = toolbar:CreateButton(“some_id”
re-using “some_id” across two different files?
Oh… I’ve been making lots of plugins in the past, under the impression that the first argument was the name of the button rather than its “unique ID”. Since the fallback behavior when you provide no “text” argument for the button is to use the button’s ID, I’ve been leaving this argument as "" in some plugins so that it would only show an icon, and never the button ID.
Historically, this has never caused any problems for me, and usually two plugins with the same toolbar name would also be grouped together rather than separated, but I guess that’s no longer intended behavior? I use the same toolbar name for different plugins because, in the past, that would group them all together, even though that has no longer been the case for a while now (which I presume to be a bug, not a feature). And I used blank IDs because, in the past, that would use the plugin icon without any text (which was especially helpful back before the ribbon bar was a thing).
It seems like I’m not the only one who’s left the first argument as an empty string so that a plugin wouldn’t show its ID, and would show its icon only. This would explain @DrEgguin’s screenshots, the screenshots in the OP, and many of my own cases.
These are really old plugins which I haven’t touched for many years. I’m willing to update them if I’ve been using the API wrong, but the errors emitted aren’t very informative to telling me that I am using it wrong (It prints out the button ID with the plugin ID appended, rather than just the button ID, which is super confusing), and it seems like I’m not the only one who’s made this mistake anyways.
It would seem, for the sake of backwards compatibility, the best option is to support two buttons with the same unique ID.
1 Like
I agree the message about button id conflicts could be more user-friendly. I will work on that and get it out ASAP.
On the bigger question of whether we should allow two buttons on the same toolbar with same uniqueID: I have asked product people about that and will defer to their decision.
Thanks for your patience!
Well, it looks like one of the main issues here is that plugins with the same ID will create the same toolbar. As a byproduct of this, file-installed plugins (which share the same plugin ID of 0) will create the same toolbar, and if two of them create a button on that toolbar with an id of '', that will cause problems under the changes you’re trying to release.
It appears some of my plugins (different files) get grouped together, and most of them don’t
Even among file-installed plugins though, it seems to be inconsistent about what gets grouped together and what doesn’t. I am not using any of the hacky methods to get them to combine, simply creating toolbars of the same name, with the expectation that they will group together, which I guess is no longer what’s indended to happen, but it does still happen inconsistently for me.
Overall, the toolbar/button API kind of sucks, as you almost always end up with 1 button for every toolbar, which really clutters the “Plugins” tab.
Thanks for the feedback. More questions:
“file-installed plugins (which share the same plugin ID of 0)”. Do they? Where/how are you seeing that?
“Even among file-installed plugins though, it seems to be inconsistent about what gets grouped together and what doesn’t”
Can you produce a minimal test case where two separate local plugins consistently write to/create the same toolbar? I am not able to repro that.
1 Like
Hold on this: there is a discussion going about changing the API altogether so that button/toolbar Ids are generated implicitly, in which case there’d be no need for error messages or whatever. We’d just automatically assign every new thing a new unique id. Stay tuned.
2 Likes
Well, all I know is that they write to the same settings.json file in the InstalledPlugins folder; every plugin installed by file will have its settings located with other plugins at AppData/.../Roblox/(userID)/InstalledPlugins/0/settings.json
I was also getting this same error earlier, but only with cloud_0 button IDs, suggesting that these plugins had an ID of 0: This toolbar cannot create more than one button with id - #26 by DataBrain
These two were in the same tab from my example, both placed directly under the “Plugins” folder:
SmoothNoOutlinesEverything.lua (1.2 KB) AnchorEverything.lua (710 Bytes)
Why do you do this:
plugin = manager:CreatePlugin()
Why not just use the “plugin” you implicitly get when you run a script as a plugin?
1 Like
FWIW, that is the problem: that’s why the plugin toolbars get smooshed. You are creating two new plugins, which don’t have unique IDs (error on our end), and so toolbars in these plugins get mooshed together.
I am not clear on why the CreatePlugin API even exists, what exactly it adds.
1 Like
It’s a legacy API, deprecated but my old plugins still use it. It’s also the case that Script Analysis still says “Unknown global plugin” when you just use the plugin global by itself, and the plugin global was also not supported in file plugins for a while so there have been cases where I used plugin = plugin or PluginManager():CreatePlugin() in some older plugins I believe.
1 Like
This is the primary reason. I also do this in all my plugins so I don’t get a warning in script analysis. I’m not sure what the best solution here is since normal scripts won’t support plugin so there’s not an easy way for script analysis to decide when the global should be valid or not.
1 Like
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.