Question Plugin that programmatically controls another plugin

eb123

New member
Messages
9
Reactions
3
Points
3
Hello!


I have the following task:
I’m writing a plugin that, when enabled, should automatically enable another plugin (in order not to duplicate someone else’s logic, I want my plugin to work together and expand functionality)

I want to programmatically check whether another plugin is loaded and if so, then call its functions (the simplest thing I want is to manage enable/disable), if not, then write an error in the log: “plugin XXX not found, please connect it to the scene..


It was not possible to find any working example, please tell me how this can be implemented.

This is some sample pseudocode.

Java:
public void  onMyPluginEnalbed(boolean isEnabled) {

        Plugin plugin = findResource("RegEXp_or_pluginAutor.pluginName.xxx");
        if (plugin == null) {
            System.err.println("Plugin pluginAutor.pluginName not found, please init first");
        } else {
            plugin.enabled = isEnabled;
        }

    }

Thank you in advance!
 
Of course I can implement the use of my plugin like this:

1) Add my plugin
2) Add a second plugin
3) Implement several triggers that will call the functions of the second plugin.

And this will have to be repeated for each new scene. I would like to avoid point No. 3 by programming this once.
 
Upvote 0
Code:
Atom atomContainingThePlugin = ...
var plugin = atomContainingThePlugin.GetComponentInChildren<MVRScript>().FirstOrDefault(s => ...find the plugin...);
plugin.enabledJSON.val = true;
plugin.GetFloatJSONParam("some param").val = 12345f;
plugin.GetAction("some action").actionCallback();

If the atom in question is parented getting the script is a bit more complicated.
 
Upvote 0
Option 1
You can put multiple plugins in the same *.cslist file. See my Life plugin for example, which utilizes a modular approach of plugins working very tightly together. If you do it like that, all plugins are in the same compilation context and can call each other's public methods and members. However, this kind of thing usually only works if the plugins are specifically build for this kind of collaboration.

Bonus:
Inside a *.cslist you can also reference plugins in another VAR, simply add the full VAR file path there, for example:
Code:
MacGruber.Utils.1:/Custom/Scripts/MacGruber/Utils/MacGruber_Utils.cs
However, due to a bug in VaM dependencies in a CSLIST are not handled correctly during VAR creation and you need manual fixes of your meta.json. So only recommend if you know what you are doing ;)

Option 2
As mentioned by the others already, triggers are an alternative if your plugins are not in the same compilation context. Keep in mind that performance of triggers isn't too good, so don't call triggers 100x per frame or something. For occasional calls it's absolutely fine, though.


Option 3
A third option is using Unity's message system, which has even worse performance. But it allows plugins to call each other easily, without needing to know on what Atom exactly the other plugin is placed on or whether there are multiple plugins in the scene, etc. Keep in mind that this messages ALL objects in the scene, so make sure your method names are pretty unique.
See MacGruber.Utils SendMessageToPluginsInScene.

An example would be how VirtualLock communicates with my FocusArea plugin (see Connect).

Plugins can hook into Acid's Keybindings with a similar system, I think IdlePoser might be the only one actually doing that.
 
Upvote 0
Back
Top Bottom