As I’m sure your aware, Plugin Documentation is lacking in some places, so I thought I’d take it upon myself to document some interesting and useful features in plugins, aswell as some extra functionallity that was enabled for a short period and then was re-disabled?
Structure
Lets start off with the structure of a plugin when it’s loaded, this isn’t documented and I feel it’s useful to know to reduce the complexity of having to parse the plugin global around.
When you export a plugin, and then it’s loaded, that folder/script/model is placed inside the plugin object that the plugin was loaded with
The parent property isn’t even locked so you could write a hacky line of code to expose the plugin into workspace (If you dont have PluginDebugService enabled)
plugin.Parent = workspace
The best part about this is that you can just get the plugin itself in modules without having to parse it around, Browser actually does this in a few places
The Plugin VM is shared across all plugins
This one’s a bit technical, basically, all script contexts have a globally shared shared table that can be accessed with shared.
All plugins have this table, and it’s shared among them, as well as this, it’s also possible to make plugins talk to each other with BindableFunctions (or with the RobloxScriptSecurity method, plugin:Invoke)
Basically, I could put a reference to this plugin’s Roact module in shared, then another module could pull it out. Or a more technical usecase, a Run function that another plugin can call.
Plugin 1:
shared.run = function(sourcePlugin)
print(sourcePlugin.Name .. " called me!")
end
Plugin 2:
shared.run(plugin) --> Plugin2 called me (from Plugin1)
This does result in a race condition and therefore shouldn’t be used on loadup, only after all plugins have loaded.
StandalonePluginScripts
StandalonePlugins were a feature that were temporarily enabled back in Feburary, however they dont serve much usecase outside of accessing a pseudo-datamodel of Studio itself.
Either way, if you Instance.new() a StandalonePluginScripts object, and then place a script in there, it’ll run when Studio loads, not when you open a place.
Standalone Plugins also have their own VM environment.
Extras
- It’s possible to create built-ins by disabling a DFFlag, but that’s not for here
- QWidgets are cool, shame they’re RobloxScriptSecurity
- Loadstring works in plugins, but only in Edit Mode
- Local Plugins dont request HTTP/Script Injection permissions
- Local Plugins and BuiltIns share the same settings.json file
- BuiltIns have LocalUserSecurity but regular context plugins dont
- It’s roughly possible to guess a plugin’s identity level by going off it’s name
| Plugin Prefix | Identity Level | Notes |
|---|---|---|
cloud_ |
5 | |
user_ |
5 | Does not request permissions |
builtin_ |
6 | Also has LocalUserSecurity |
sabuiltin_ |
6 | Runs scripts in StandalonePluginScripts as soon as studio starts |