Writing plugins for RasterPropMonitor

Having struggled enough with Squad's silly plugin loader, I know it can be painful to link to a foreign plugin in KSP. The problem with integrating multiple plugins in KSP is that while normally, you would just reference a plugin and call it's member classes directly, KSP plugin loader will reject your plugin upon loading if the referenced plugin is not already loaded. You can ensure your plugin loads later than the plugin you're referencing, because KSP loads them in alphabetical order, but then, if the referenced plugin is not present, yours won't load at all anyway, which is in many situations unacceptable. This problem can be solved using reflection and delegate functions, but the solution is quite cumbersome. Well, the trick with RPM API is that:

• You don't have to hard link to RPM. You don't need to reference RPM's DLL. You don't stop working if RPM is not installed either and you don't need a separate assembly.
• You don't need to know anything about reflection, either. It's enough that RPM knows enough about it.

Interfacing to RPM is done by creating classes that contain methods with specific signatures -- that is, which take a certain list of parameters in a specific order, and return specific things -- and writing RPM configuration files which tell RPM what the names of all these things are. RPM will then take care of instantiating those classes as appropriate and calling the methods you name. These classes can be part of your own assembly, and are thus allowed to directly manipulate the internals of your plugin that otherwise does something independently. As long as RPM API doesn't change, which isn't expected to happen, you can expect to continue working with any conceivable future version of RPM, as long as one exists, with no changes.

The entire mechanism is used internally for much of RPM's own advanced page configuration, so you can see examples in RPM's own code -- every handler works as one, but JSIFlightLog.cs is particularly instructive, as it's commented throughout specifically for this purpose. The particular things that can be plugged into are:

• Page handlers -- Modules that tell RPM what to print on screen.
• Background handlers -- Modules that get an RPM screen to draw graphics on.
• Action handlers -- Modules that can be triggered by RPM-driven switches to perform an action of any kind and report any kind of on/off state.
• Variable handlers -- Modules that add extra variables that RPM pages can use.