We found a last-minute issue that somehow bypassed testing. See my update at the top of the post!
3 Likes
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
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
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
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
The plugin global has now been set to the Plugin type, enabling autocomplete! Thanks for your patience!
4 Likes
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
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 
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
Yes! After a surprisingly long release period, the fix for the Plugin RunContext is now released. Thank you for your patience 
2 Likes
I’m still not sure if this is working or if I’m doing something wrong on my end.
When I have the plugin in the PluginDebugService it works fine, but otherwise I get the following error:
Actor:SendMessage may only be called on Actors attached to the DataModel.
I can confirm the actor’s full path in my case is:
user_Photobooth.rbxmx.PluginRoot.Utilities.Parallel.ParallelModule.Actors.1
Is this an implementation mistake on my end or is this still broken?
2 Likes
I am getting the same issue.
Also, how do you put your plugin in PluginDebugService? I am trying to parent the plugin singleton to that service but it only leaves me with an error message in the output. Perhaps I am missing something here?
Thanks for the reply. The RunContext seems to work now! However, it is not possible for Parallel Lua to work due to the error message mentioned by @EgoMoose before.
I also noticed this error message when trying to save my plugin as a local plugin. Not sure if it is related to this update, but I believe it is worth mentioning. As now, I need to publish my plugin to Roblox (as a private plugin) everytime I want to test it since the “Save as local plugin” button doesn’t work anymore. Am I the only person with this problem?
The process is documented here.
1 Like
I am having the same issue when publishing my plugin. Actor:SendMessage may only be called on Actors attached to the DataModel.
It works wtihin PluginDebugService just fine, but not published. I tried moving my actors into PluginGuiService under my UI, but that didn’t even run them at all.
My full stack:
Actor:SendMessage may only be called on Actors attached to the DataModel.
cloud_333507912.LinesOfCodePlugin.backend.process-dispatcher:164
cloud_333507912.LinesOfCodePlugin.include.Promise:172 function runExecutor
cloud_333507912.LinesOfCodePlugin.include.Promise:299
1 Like
Thanks for the reports, everyone. A fix for SendMessage is on its way!
1 Like