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

Updates Announcements
#10

you served well :saluting_face:
image

19 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!

9 Likes
#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

8 Likes
#13

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

7 Likes
#14

This is really nice.

It would be awesome if plugin scripts would have an automatically run property so we could distribute plugins as packages with our current studio build per-place.

5 Likes
#15

But parallel Luau is a vanity feature thanks to this unsolved “”“bug”“”:

4 Likes
#16

Literally was going to make a plugin for “plugin” autocomplete. Thanks for this!

4 Likes
#17

I’m sure this would be useful for those who write plugins as they can now write multi-threaded plugins. I have never wrote any plugins (I haven’t found a need to) so this won’t affect me very much.

2 Likes
#18

Is this new feature working for anyone? It just doesn’t work for me.

2 Likes
#19

Global autocomplete for shared when? :slightly_smiling_face::scream:

6 Likes
#20

Remember, it only took us 10 bajillion years to reach this point

goodbye, local plugin: plugin = plugin

4 Likes
#21

We found a last-minute issue that somehow bypassed testing. See my update at the top of the post!

3 Likes
#22

A fix is on the way in the next release or so! For now, you can work around the issue by using the PluginDebugService, which will run Plugin RunContext scripts in plugins correctly.

2 Likes
#23

Will plugins be able to require modules without caching them in the future? This would be really helpful with some plugins where ModuleScripts are written by the user for configuration purposes.

3 Likes
#24

I don’t think this behavior should be changed and it would break a lot of already existing code

A work around for this is to Clone the module and then require it

2 Likes
#25

I am aware of this, but cloning an entire folder of modules probably isn’t ideal for performance…

I was thinking a new method for plugins only, rather than changing existing require behavior

2 Likes
#26

The plugin global has now been set to the Plugin type, enabling autocomplete! Thanks for your patience!

4 Likes
#27

image

This setting overrides all the other stuff and lets you have plugin autocomplete in any script.

I wonder if this is intended, otherwise, I don’t know why this wasn’t listed instead of just the RunContext and PluginDebugService stuff. Anyways, for anyone who didn’t know, this setting exists.

This setting used to not work (you still had to use the local plugin: plugin = plugin thing), but now it does, so like, hooray I guess.

Oh, also, a script with a Plugin RunContext will just bypass this setting completely now.

2 Likes
#28

Hey any update on this? I’ve been wanting to use this new feature in my plugin for better reliability and stability, but so far the plugin RunContext has not worked once for me :frowning:

I am also not sure what PluginDebugService is supposed to do because it didn’t fix anything for me after I enabled it.

4 Likes
#29

Yes! After a surprisingly long release period, the fix for the Plugin RunContext is now released. Thank you for your patience :sweat_smile:

2 Likes