Is this true? If so, how are people supposed to develop plugins? The only way I have ever been able to develop plugins outside of lua-based files is using third party hot-swap plugins (or constantly re-uploading the plugin, updating it in the plugin settings, and then closing/re-opening the place, which is… tedious to say the least)
I don’t even know where to begin with a repro though, since I have very little control over failures like this. I didn’t even consider that the file might have been corrupted, but I thought it was because of updates.
It also might be worth mentioning that this has happened on two different machines
I know from experience it’s possible to cause problems with the parser that might lead to it resetting the file. It should be throwing an error out when it happens though. If you can, keep an eye on the output next time it happens or check the logs for when it happened last.
Another thing I hadn’t considered is it may be an issue with the file being opened from both the server and the client at once, which could be another source of corruption.
This could be related to a change that just went live, where we store installed plugin metadata to the cloud instead of in a local file.
Can you be more specific about what happened? What do you mean by file-installed plugins?
By this I mean plugins that downloaded or created manually as .lua or .rbxm files in the AppData/.../Roblox/Plugins
folder instead of the InstalledPlugins
folder.
Unfortunately, it is still really inconvenient to develop plugins without either using local files, or by using third party hotswap plugins, so I still have a lot of plugins that aren’t uploaded to the Roblox website, but are installed to a local file. These are the plugins which have their settings randomly reset, and all of their settings are stored in the same JSON file with a folder whose ID is 0:
Did the problem get fixed when I turned the feature off?
I believe I understand what was happening with Plugin Settings getting lost, and it should have been fixed when I turned the feature off.
I have fixes for the problems people were observing (hang on delete, missing settings), and those are being reviewed.
Unfortunately it will take a week or so for the changes to percolate through our testing/review/release cycle. So expect to see this re-enabled early to mid Sept.
I apologize for the inconvenience.
If I understand correctly, the feature you were working on (Installed plugins being saved to the cloud) was only activated and turned off just a day ago, whereas this issue is cOLD mOLD on a sLATE pLATE (see the OP was in June), unless you have been making changes that would affect file plugins for the past few months.
And like I said, this has nothing to do with plugins installed from the website, but rather locally created files in the AppData folder (all of their plugin settings are stored together under the id “0”, making it so that any vulnerability will wipe them all out at once).
So really, it depends on when you turned the feature off, or turned it on in the first place; this issue has been going on for months
It’s also hard to tell whether this issue has gone away in the first place, since it seems to be happening very sporadically, unpredictably, and rarely. I have only gotten it three times within the last two months.
Just happened again, when I pressed F7 to start a Server + Players test (I’ve never had this happen in any other case).
edit: happened again, same circumstances
The file that should be holding your settings is in /InstalledPlugins/0/settings.json. You can watch the contents of that file get updated while you run. So an interesting experiment would be:
- open file, check contents.
- run studio, do something that updates settings for plugins.
- check file contents again, confirm your updated info is in there.
- run start server/start play. Check contents, confirm they are still sane.
I expect you will fail that last confirm: after starting start server/start player, contents will not be what you expect.
Since we are not getting widespread complaints about this, and I can’t repro on my end, I suspect that it has something to do with your actual plugins.
Can you share your plugins with me somehow?
This is not particular to my own plugins because it affects other things than my own plugins at the same time (e.g. the View selector is also re-enabled when this bug occurs, since it also uses that settings.json file)
And like I’ve mentioned before, I cannot reliably reproduce this; it just happens once every few weeks or so, sometimes in shorter intervals and sometimes longer. But it always happens after I run a Server + Players test on my Team Create place. I have backed up my settings.json folder and replaced it every time it gets reset, because it happens often enough for me to need to do this, but never reliably enough for me to reproduce it.
FWIW, here are the plugins I am using to try to repro the problem:
Two different plugins, just doing simple read/write with settings:
BreadPlugin.lua:
local toolbar = plugin:CreateToolbar(“BreadForce”)
local button = toolbar:CreateButton(“Mizaru”, “See No Evil”, “rbxassetid://2778270261”)
button.Enabled = true
button.ClickableWhenViewportHidden = true
function getClickCount()
local clickCount = plugin:GetSetting("breadClickCount")
if (clickCount == nil) then
return 0
else
return clickCount
end
end
button.Click:Connect(function()
local clickCount = getClickCount() + 1
print("Bread click count is ", clickCount)
plugin:SetSetting("breadClickCount", clickCount)
end)
CurryPlugin.lua
local toolbar = plugin:CreateToolbar(“CurryForce”)
local button = toolbar:CreateButton(“Mizaru”, “See No Evil”, “rbxassetid://2778270261”)
button.Enabled = true
button.ClickableWhenViewportHidden = true
function getClickCount()
local clickCount = plugin:GetSetting("curryClickCount")
if (clickCount == nil) then
return 0
else
return clickCount
end
end
button.Click:Connect(function()
clickCount = getClickCount() + 1
print("Curry click count is ", clickCount)
plugin:SetSetting("curryClickCount", clickCount)
end)
Are you on Mac or Windows?
Windows. I could send you all of my local plugins if you want as well, but it’s quite a large number since it’s all of the plugins I’ve accumulated over the years while I was developing them.
When the local settings.json file gets wiped out, it ends up completely empty, or just is reset back to some earlier version? Or just some fields are missing?
You mentioned it’s not just fields from your local plugins, it’s also fields from the built-in plugins?
It ends up completely empty, but then gets refilled by whatever default settings are written to it, and this includes fields from my local plugins and built-in plugins as well.
Doing a Control+shift+f search, there is only one line from my local plugins that ever potentially calls SetSetting without any user input:
As you can see from the OP, this is one of the settings that gets written to the file once it’s reset.
The full .lua file (excuse the monolithic and anachronistic code structure; it’s a very early plugin of mine):
Core.lua (170.6 KB)
As Dekkonot mentioned, this could have something to do with parsing/file corruption problems, as plugin settings are rapidly read when, say, a test with 3 studio windows is run at once.
Good news: I was able to write a plugin that repro’ed the problem, and I was able to write a fix that resolves the problem.
Bad news: you will have to wait the standard ~2 weeks for the fix to go live.
Thanks for your patience, and sorry for the inconvenience.
This just happened to me again. Studio crashed (from pressing F5 and then hitting the “stop” icon in the quick access toolbar before the studio test fully loaded), and when I re-opened studio, all of my plugin settings were gone again from file-installed plugins.
edit: turns out these settings being wiped this time are directly related to the crash that happens when I press F5 and then hit stop early in a large place; I was able to reproduce this a second time, although I can’t consistently get it to crash.
This bug is still relevant and still very, very annoying to deal with when all of my plugin settings get wiped.
Reviving this post as I have experienced this exact issue multiple times now.
Issue only occurs in a locally installed plugin. A plugin with the exact same code that was hosted on the Roblox servers (accessibly through toolbox) does not have the issue