This should be fixed as of yesterday. Apologies for the inconvenience.
1 Like
I’m getting this again for file-installed plugins (with ID ‘cloud_0_…’), and now all of my local plugins are broken.
Is the “Plugins” folder in AppData supposed to be deprecated? I still get this issue as well as this one, and it feels like Roblox doesn’t really want to support offline plugins anymore. The second issue I linked has not been fixed for almost a full year, but I have a lot of older plugins that I still have installed as files within the Plugins folder.
We do still support local plugins. This is a bug introduced by a flag flip yesterday, the flag flip has been reverted.
@DataBrain
So I cannot find a trivial repro on my end (I can still build and run a basic local plugin).
Could you please post an example of a local plugin that was not running (generating errors/exceptions) for me to play with?
I’m not sure which ones were breaking together like this, since the flag flip fixed the issue for me, but here’s a smaller one that was breaking:
AnalyzePartDensity.lua (16.7 KB)
You may have to have two local plugins running at once, since this issue seems to conflate the IDs of two separate plugins; IIRC the error was showing up multiple times with the same ID ‘cloud_0_vip’ or something akin to that (this is the plugin that the error was referencing the ID of multiple times: Core.lua (170.6 KB) )
It could also be the fact that I use the same plugin toolbar (“Databrain’s Plugins”) for multiple different plugins.
I think we figured out what the disconnect was. @EchoReaper suggested it’s because you are opening the place directly from the web (like clicking “edit” on website to edit place), as opposed to opening studio to start page then selecting a place to edit.
When I did the “open from website” version I was able to reproduce problem. (At least ‘a’ problem, not 100% sure it’s yours.
Anyway, punchline:
- @EchoReaper is the best.
- We should test launching from website more (when testing I always just open studio and open a place from start page).
- I have a fix which I hope to get live soon.
3 Likes
Getting this again when opening any place through Roblox Studio. All of my local (id 0) plugins are broken.
I’ve started getting the same error as of a couple of days ago. It seems that all of my local plugins are producing this error, although all the errors give the id of the same plugin. When I remove that plugin, the error ids just point to another plugin. It’s like it loads one plugin, then tries to load the rest under the same id. Because of this, only 1 of my local plugins will end up loading when I open a place, and the rest don’t show up at all. The one that does load works just fine, however, so there’s that.
Also, this happens not just when I open a place from a browser, but also when I open Studio first then select a place.
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.