Studio Plugin Unloading Changes


#1

Hi Developers,

Studio plugins are essential for productivity in Studio because they enable you to customize your workflow to best suit your needs. To continue enabling productivity, we are making some improvements to how Studio plugins work. If you are a plugin creator, you may need to update your plugins accordingly.

New Plugin.Unloading Event

Plugins now have an Unloading event which fires right before a plugin is updated, disabled, or uninstalled. This enables a plugin to clean up after itself before its scripts stop running, e.g. to remove unnecessary instances from the DataModel. If a plugin does not clean up properly, users will be forced to close and reopen the place which is a bad user experience.

It is not necessary to clean up plugin-related instances such as PluginButtons or DockWidgetPluginGuis because they will be automatically removed when the plugin is unloaded.

Plugin Scripts Will Stop Running After Unload

Starting April 15, plugin scripts will stop running immediately after the Unloading event fires. Currently, a plugin’s scripts continue running even after that plugin is unloaded. Code listening to the Unloading event must not yield because it will be aborted before it finishes executing. Please update your plugins now to take this into account.

Let us know if you have any questions or concerns about this update! For more information about developing plugins, see our Intro to Plugins article.


February Monthly Recap: What's Happening the Developer Community
#2

This post was flagged by the community and is temporarily hidden.


#3

Glad to hear that this has been added. It will help plugin developers keep things clean.


#4

Finally, a clean up method so I don’t have to hand remove all the data models the plugin inserts while running.


#5

Glad to see such a useful thing coming to studio.


#6

Thank you!

I really hope this is the one solution to potential and existing bugs caused by plugins. People could potentially use this as a way to close up a plugin the proper way removing any data leftovers. Bug free… I like it!


#7

Couldn’t this be used maliciously as well?

If a plugin creator wants to, they could theoretically use this event to spread malicious code around a game before uninstalling/deactivating/updating. Not sure how to solve this, but it is something that crossed my mind.


#8

Right now, the only way I’ve gotten around this whole shenanigan is to disable the plugins I want, then install and/or uninstall a random plugin so that the toolbar refreshes. I’m glad to hear that an Unloading event will be added so I don’t have to refresh my toolbar or re-open my places.

It can sometimes be very annoying when plugin scripts continue running. When I disable them, I’m expecting that their execution ends and that I’m therefore unable to utilise it.


#9

Undifferent really. There is no difference other than the timing.


#10

I really just want to know how much time it takes before the code stops after the unload event.


#11

Was just working on a new plugin and was concerned about this. Good thing you posted this! :+1:


#12

Couldn’t this be used in a malicious way or am I reading this wrong. Example:

Let’s say a plugin doesn’t want people uninstalling it and if it detects that it’s being disabled,uninstalled,etc it could place some malicious script in a area where it cannot be seen in the explorer. Couldn’t that happen?


#13

There is some potential for abuse. However, plugins do not know why they are being unloaded – it could be because the plugin is being updated, disabled, uninstalled, or the place is closing.

If I were a malicious plugin developer, I would want my code to always be present in the DataModel so even if the user never uninstalls my plugin, the code lies dormant. So I am not sure that adding an Unloading event changes the game significantly. In any case, the upsides of exposing this API outweigh the potential risks.


#14

Yeah that seems reasonable. If I were to download a plugin and thought it was doing something malicious anyone could just find the source code of such plugin and see whats really going on.


#15

Yep. There is additional work we would like to do around protecting developers from malicious plugins. Will keep you posted.


#16

Sweet! I was moaning about this a few months back. Glad to see it made it into the API. :slight_smile:


#17

Very happy to see ROBLOX is making changes to studio. Very happy to see these changes.


#18

What about plugins like the Studio Command Panel, which run silently in the background? Will these need their functionality patched/changed/etc in order to respect this?


#19

Will connected events be automatically disconnected too when the script stops? Or do we need to use the Unloading event to disconnect events?


#20

This is AWESOME! Just to clarify, does this also fire when Studio is closing?