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.