Studio Plugin Unloading Changes

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

3 Likes

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

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

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?

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.

4 Likes

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.

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

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

1 Like

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

1 Like

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?

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

4 Likes

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

Awesome, glad to see my feature request come to life :slight_smile:

In accordance with this update, I’m thinking it’d be useful to have a way to manually trigger reloading all plugins. Perhaps a “Reload Plugins” Studio action. This could be a quick fix for misbehaving plugins without needing to restart Studio after the update goes live to kill plugin scripts after they’re unloaded. It’d also come in handy when you modify your plugins in one Studio window, and want to update your plugins in a second one.

15 Likes

Yes, connections are automatically disconnected when scripts are stopped.

Yes, this fires both when a place is closed and when Studio itself is closed.

5 Likes

How much time do we have to clean up then? It says immediately after the event, but if that were the case we wouldn’t be able to clean up at all would we? Or even receive the event? If we have particularly long/slow cleanups, will they be unexpectedly aborted even without yielding?

Just to confirm, this would run before the place is saved right? Otherwise any artififacts that are cleaned up would be saved in anyway? What about publishing?

And if so, Is there potential for a malicious plugin to, say, delete everything in workspace on unload, silently wrecking a developers local copy when they close studio, going unnoticed until they next work on that particular place, which could be awhile?

The amount of time does not matter as long as your code does not yield.

This will not fire when saving a place. If you want to make sure instances in the DataModel are not preserved on save or publish, you should set the Archivable property to false.

Got it, thanks

Always forget about Archivable, thanks.

Whats the point of firing on studio/place close, then? Anything it might want to clean up will either be unarchivable, or saved in the place anyway? Will this slow down studio/place closing? Could a malicious plugin enter an infinite loop to freeze studio on unload? Would such a plugin have to be manually uninstalled?

edit: to clarify, when i said “before the place is saved right?” i meant “before the place is saved, when closing the place”

Personally, Archivable didn’t come to my mind until I saw your post above. Unloading did, however, and I implemented it a day ago in my plugin. There’s an indirect solution (set Archivable = false) and a direct solution (remove it on Unloading). I, personally, wouldn’t have thought of the indirect solution on my own. Many others won’t either.

Additionally, plugins unload on place close. The Unloading event fires when a plugin unloads and that’s great.

2 Likes