[Plugin Update] Script RunContext: Enable Parallel Luau & “Plugin” Global Autocomplete

Updates Announcements
#1

Hey Creators,

In 2022, we announced RunContext, a property of scripts that lets you control where they run. Today, we’re excited to introduce the Plugin RunContext, a new option that can be used for scripts in Studio plugins. With this change you’ll now be able to dynamically enable and disable scripts, use Parallel Luau, and access autocomplete for plugins.

Overview

Unlike regular scripts, scripts in plugins would only run once if they’re enabled when a plugin loads. With the new RunContext option they now behave the same as regular scripts, automatically running when they are enabled or if they are cloned into the plugin.

This means you’ll now be able to use Actors in plugins. For example:

Cloning Actors in a plugin

790×404 54.6 KB

With the Plugin RunContext, if you set ActorScript’s RunContext to Plugin, it will be Enabled and cloned, and run twice (once in each Actor). This pattern can be used to spawn any number of Actors to do a large amount of parallelizable work (see Parallel Luau for more information).

Autocomplete for the plugin global

Alongside this update, we’re enabling autocomplete for the plugin global by setting its type to Plugin. Plugin methods will autocomplete in scripts inside of the PluginDebugService, and in scripts with a Plugin RunContext, giving you valuable type information even if you’re developing your plugin outside of the PluginDebugService.

Feedback

If you have any feedback, questions, comments, or concerns about this feature, please post them here!

FAQs

Click here to view the FAQ!

What if I have a Script with the Plugin RunContext in my Workspace/ServerStorage/StarterPlayerScripts/etc?

  • A Script with the Plugin RunContext will only run if it is the descendant of a plugin, and nowhere else. You can use the Plugin RunContext to develop and organize your plugin anywhere in Studio without fearing that its scripts will run when you press Play.

What happens if I change the RunContext of a plugin script in the PluginDebugService?

  • If you change the RunContext from Legacy to Plugin, the script will be restarted and run immediately. If you change the RunContext from Plugin to Legacy, the script will terminate as usual, but it will not restart until the plugin itself is reloaded.

Are there any plans to extend full support for new scripting features to the Legacy RunContext in plugins?

  • No, as this change might create issues for existing plugins that are not designed with the new functionality in mind.

What happens if my plugin script calls plugin:CreateToolbar(...) or plugin:CreateDockWidgetPluginGui(...), and then gets restarted?

  • An error will be thrown if those function calls use the same ID each time.
78 Likes
#2

This topic was automatically opened after 10 minutes.

#3

I’m actually very happy about the plugin object autocomplete

Having to code pretty much blind was the #1 issue I had with plugin development.

14 Likes
#4

This is a plugin creator update, but it’s a massive update in disguise. Thanks for working on this!

For those confused by what this means: Previously when you wanted to, say, import a huge csv file’s worth of data (importing a huge terrain file from another program, for example), all of that data would be funneled into one thread, bottlenecking your cpu and generally making such a task take forever.

This update allows plugin creators to chop the incoming data into batches, and to spawn one thread for every batch, using as many threads as needed to accelerate the process of handling that much data.

Let’s say you needed to import an 8192m block of terrain and do custom processing tasks depending on the content of the terrain.

Before this change, even if you spawned a thread for every 4096m of terrain in a 8192m block of terrain, previously, those threads would still run on the same CPU core, the most speeding up you could do would be to minimize how much processing power was required in one thread.

After this change, the imported terrain can now be properly chunked, allowing the plugin to use 8 threads - one for each 4096m block of terrain. No matter how long your processing takes, the import process – depending on if your CPU has at least 8 “cores” free – could be up to 8 times faster.

If this explaination is still confusing (which is probably is since I’m not that good with words), here’s a video to explain the concept that Parallel Luau Plugins enables. (Yes, I’m aware it’s six hours long, please stop DMing me alternative videos - the entire concept is explained in the first 15 minutes)

13 Likes
#5

These APIs throwing an error show a fundamental issue with how the Qt interfaces were approached.

It is an assumption that these return a singleton (per ID), so why do they throw instead of returing the same object across multiple calls?

Also, this might be a little off topic but can we also please have a Shared RunContext. I have an init script that is functionally the same thing on the client and server, and it’d be nice to dedupe it.

6 Likes
#6

Even though i don’t do plugin development, i am still pretty excited.

For people like me, this means that we will have better plugins. Huge win.

1 Like
#7

:tada: Been waiting for type checking to come to plugins for a long long while! Happy to finally see this enabled!

3 Likes
#8

Sorta unrelated plugin question. I use a viewport frame to spawn a 3d cursor in studio for a plugin of mine. Until recently it worked fine, but now it stutters like crazy. Is there some throttling of viewport frames going on? is there a way we could get higher framerate viewport frames for plugins?

1 Like
#9

Am I crazy or RunContext “Plugin” only works for Local Plugins only?

I have the exact same plugin published to the market and it won’t run while I saved it as a Local Plugin and it ran just fine

1 Like
#10

you served well :saluting_face:
image

5 Likes
#11

Does your plugin consist of a single script? There’s a known issue right now where saving a single script will result in a .lua file, which does not contain RunContext information. You can work around this for now by making your plugin a single folder containing the script you want. We’re looking into a way to fix this that doesn’t break existing workflows!

1 Like
#12

This is what my plugin is consist of
image

image
image490×517 29.8 KB

I’m opened to sending you my .rbmx file upon request

1 Like
#13

We’ll investigate what’s happening here, fortunately it’s reproducible. Thanks for bringing it up!

1 Like