What's the best way to communicate between addons without referencing an object?

[Xyphos]

so I'm scratching my head on this one, and open to suggestions.

I'm attempting to write a utility addon (UTIL), that other addons (OTHER) can optionally use without referencing UTIL, so the OTHER addon won't require UTIL to function, but still could use if the UTIL addon is installed.

if UTIL is present, I need a way to exchange data in both directions to/from OTHER, again, without referencing either one.

my first attempt was obvious, GameObject.Find("OTHER") but that still required the OTHER addon to reference UTIL, which created a hard-dependency, which I'm trying to avoid.

second attempt at this was to use BroadCastMessage but the problem is that BCM isn't target-specific so data is broadcasted to ALL listeners, which can cause lag, data collisions, interference, etc, and required the OTHER addon to sift through dozens of possible actions, which was a freaking nightmare.

third attempt was to use System.Reflection wrapped in a simple API class that could be dropped into the OTHER project, but as I quickly found out, Exception Thrown: OTHER.API cannot be converted to UTIL.API
as these assemblies do not share the same object type, despite being the same drop-in file, preventing me from obtaining an object reference to OTHER.API from within UTIL.API

Edited October 15, 2020 by Xyphos
fix formatting

[Xyphos]

Update: I'm going to try NamedPipes next, but I'm still open to suggestions.

[peteletroll]

Reflection should be the way to go. You can't turn OTHER into UTIL, but you can use OTHER as a "proxy" to UTIL: OTHER and UTIL have the same methods, and OTHER just calls UTIL methods via reflection.

[Xyphos]

20 minutes ago, peteletroll said:

Reflection should be the way to go. You can't turn OTHER into UTIL, but you can use OTHER as a "proxy" to UTIL: OTHER and UTIL have the same methods, and OTHER just calls UTIL methods via reflection.

Tried that, the OTHER.API would hook into UTIL.API but passing the object reference OTHER.API caused the aformentioned exception

[peteletroll]

2 minutes ago, Xyphos said:

passing the object reference OTHER.API caused the aformentioned exception

Can you share a code example? I'm not sure what you mean.

[Xyphos]

Just now, peteletroll said:

Can you share a code example? I'm not sure what you mean.

I deleted the code, currently implementing NamedPipes.

API is a singleton class, upon instancing itself, it looked for UTIL and if found, Invoked AddAPI(API api = _instance)
upon invoking, the exception is thrown because API produced different object types that wasn't castable between addons

[peteletroll]

You definitely can't cast API objects, but you can store them as Objects and access them via reflection.

[Xyphos]

1 hour ago, peteletroll said:

You definitely can't cast API objects, but you can store them as Objects and access them via reflection.

hmm, why didn't I think of that before? *derp*

thanks a ton, I'll give that a try.

[Teilnehmer]

Here, I’m doing this in my mod CriticalTemperatureGauge using System.Reflection:
https://github.com/formicant/CriticalTemperatureGauge/tree/master/CriticalTemperatureGauge/Wrappers

The wrappers provide access to the methods of Linuxgurugamer’s ClickThroughBlocker and ToolbarController mods, also providing a fallback behavior when the mods are not installed.

Unfortunately, I had to write a lot of code to wrap the custom delegate TC_ClickHandler.

However, if both UTIL and OTHER are your own mods, you have more freedom to make the access via Reflection less complicated. Delegates of types accessible from either mod (such as Action<…> and Func<…>) are much easier to deal with.

Edited October 27, 2020 by Teilnehmer

[Teilnehmer]

Here’s a silly minimal example of two-way communication between two mods via Reflection:
https://github.com/formicant/ModCommunicationSample

The Util mod detects the current vessel’s throttle changes and invokes throttleChanged events.

The Other mod changes the current vessel’s cargo bay door deploy limit according to the throttle evel received from the Util mod. It calls the methods of the Util mod to subscribe to the events or unsubscribe.

The UtilApiWrapper and UtilApiAlternativeWrapper do the same thing but are written a bit differently.

Edited November 4, 2020 by Teilnehmer

[Xyphos]

@Teilnehmer You're AWESOME!

thanks so much for your example!
I forked it just to keep it around if needed in the future.
Thanks again!

Edited December 12, 2020 by Xyphos