Cross DataModel Plugin communication - any ideas?

Help and Feedback Scripting Support
1

Hello,

I am currently developing a plugin that could benefit from communication between its Edit Mode and Run Mode versions.

Since there hasn’t been much discussion on this, I was wondering if anyone knows of a way to achieve cross DataModel plugin communication?

This was the only lead I’ve found, which itself dates back to 2020. Also, it appears that the functions mentioned are no longer available to plugins, as their security level has been reverted to RobloxScriptSecurity…

Any ideas are greatly appreciated!

2

I’m not aware of any API that specifically intends to serve as communication between plugin instances created in different environments. Here’s a few methods you could try depending on what sort of communication you need exactly between a “studio edit mode” plugin and a “studio run mode” plugin:

  1. Creating instance hierarchies somewhere in the data model (ex. ServerStorage)
  2. Using plugin setting APIs, plugin:SetSetting() and plugin:GetSetting()
  3. Some form of communication over localhost using HttpService
1 Like
3

The _G variable is shared between plugins, you could use that to maybe store references to bindable events to send data across plugins. I would advise caution with this since you cannot control the order plugin’s load, so it may cause some racing conditions, but I’m sure that with some clever trick and maybe a module loader you could set it up.

1 Like
4

Standalones dont even work for user plugins anymore. Support for that was dropped a while ago.

I think I should explain which how plugins work when it comes to contexts. Fundamentally, Studio can summon up to 4 different instances of your plugin in different spaces, these being

  • Standalone - the standalone context (start page etc.), not currently usable by user plugins.
  • Edit - edit mode when the game isn’t running, I’m unsure if starting a game pauses execution of this plugin
  • Server/Client (seperate contexts) - when a game is actually running

The APIs for this are actually SetItem, GetItem and OnSetItem. One thing you need to be aware of is that DataModels are memory isolated, this meaning you cant send Instances across the ocean, so if these APIs do ever get unlocked again, keep that in mind.

There’s also MultipleDocumentInterfaceInstance which is solely meant for the standalone datamodel, and tells you when new DataModels are created or destroyed. This is also currently only usable by Roblox-created plugins.

I guess you could use settings but theres no event logic for that, and edit plugins dont get restarted, only suspended. this was wrong lol.

image
image676×121 5.73 KB

1 Like
5

I’m loosely familiar with how standalones work(ed), as I’ve previously made plugins which used the StandalonePluginScripts container and made use of the Standalone context/DM.

That said, after recently returning to plugin development, I was confused when I noticed that standalones don’t work for user plugins anymore. At first I thought that I was missing something, however after some time I realized that they simply no longer work.

Honestly, it’s a shame that they dropped support. I actually messaged a staff member about a month or so ago to ask for more info on why standalone support was dropped, as well as any additional info that could be documented, however I am still waiting for a follow-up on that message.

Looking back at the API’s history it’s clear that there was some sort of a plan for cross DM communication, but for whatever reason it was scrapped.

Any ideas as to why they’ve dropped support for standalones and APIs such as SetItem, GetItem and OnSetItem?

6

Don’t quote me on this, but as far as I’m aware (can’t really check if this is true or not right now), _G variables are not shared between DataModels.

Anyway, I’ve actually given up on trying to find a reliable way to communicate between DMs. The closest you can probably get to cross DM communication is by using plugin settings, as @East98 mentioned in the first reply.

That can be a great way to communicate globally to all currently running plugin instances (even in other Studio processes), however that is not what I was looking for.

I won’t get into the details of my case, but I can say it would have required a lot of work to implement, and even then the system would only work reliably about 50% of the time.

7

Just did a lil testing and here:

Plugin 1: (Put in a script and then save as local plugin First)

_G.Test = "Hello World"

Plugin 2: (Put in a script and then save as local plugin Second)

task.delay(3, function()
	print( _G.Test)
end)

Output:

Screenshot
Screenshot5120×406 85 KB

So you can technically share data across plugins but its scuffed and probably not efficient.

I figured this was the case since this is how Moon Animator lets you get more themes by buying other plugins for it.

But anyways I guess this doesn’t really help you tho :frowning: Apologies.

1 Like
8

It seems there’s a bit of a misunderstanding here.

Of course, no need to apologize, as there is nothing to apologize for.

Yes! You are correct, data is shared among different plugins through _G and shared tables.
It is in no way scuffed, and to me it is a pretty reliable way to share data among two different plugins.

However, that’s not the issue I’m facing in this post.
What I’m referring to is cross DataModel plugin communication. Let me simplify things, a lot:

Imagine you have a plugin, let’s reefer to the plugin itself as “MainPlugin”. Once you save it/install it, it runs in your studio. We all know that.

But here’s the catch - depending on what mode you’re in, you’re actually seeing a different version of MainPlugin:

  • When you’re editing your game, MainPlugin is one running version of your plugin.

  • When you start playtesting your game, you are not seeing the original MainPlugin version (the one mentioned above), instead you are seeing another version of your plugin which runs when your start playtesting your game.

If you have a lot of plugins which also have their own windows (widgets) and if you potentially have a slower system, once you start play-testing, you might see small windows appear in the center of your screen for a brief moment - those are your plugins starting up in the playtesting mode.

So, when I say “cross DataModel plugin communication”, I mean:

I want for the two different versions of MainPlugin to communicate with one another.

In my actual case, I need the version that runs while I am editing my game to communicate appropriate data to the version that starts up when I start playtesting my game.

In other words, this isn’t about two separate plugins talking to each other, it’s about two seperate instances of the same plugin, running in different DataModels / Modes, talking to each other.

For more appropriate and non-simplified information about all this, check out metatablecat’s reply, pretty much this whole quoted part explains all of this.

9

If you dont mind frying your disk, you could do it with settings I guess? Just poll GetSettings every second for a new message.

We really need the item API to be unlocked.

1 Like