Add better support for PartModules from mods

[602p]

I'm not really sure how @djungelorm would want to implement this, but I would like to see a way to allow mod authors to support KRPC for their PartModules in the same way stuff like the specific subclasses for stock PartModules are (e.g. Engine, LaunchClamp.) So for example I could add support for getting the FailureModule from a part and check it's age, without using the (functional but ugly) Module system of HasField and GetField. I would like to be able to write something along the lines of the LandingLeg class for it that would allow important fields as KRPCProperties.

Maybe allow PartModules to implement an ISupportsKRPC interface that has a function public Module GetRepresentation() to return an instance of a specific subclass of Module that is passed over the connection when the client asks for the functionality of that PartModule? I'd like to hear how you would do this.

Then add methods SupportsRepresentation and GetRepresentation to the Module class to check if the PartModule implements ISupportsKRPC, and if it does call GetRepresentation() and pass that back.

[djungelorm]

I agree that this is something that needs to be added!

I see one option for this as follows. First, annotate FailureModule (or whatever your custom part module class is called) with the KRPCClass attribute, and annotate all its properties/methods that you want to expose through the server. Then kRPC will know how to pass instances of FailureModule to clients.

The challenge is then how to let clients access instances of FailureModule. With the current parts API, to get an instance of the Engine class for a part, you'd call Part.engine. So ideally we'd want to add a property to the Part class called something like Part.failure_module which would return an instance of FailureModule.

The design of kRPC's scanner requires all classes/methods/properties to be declared statically - so we can't add this extra property dynamically at runtime. We could instead do something akin to C#'s extension methods. Define an 'extension class' called PartExtension that contains our custom property, and annotate it with KRPCExtensionClass(Extends='SpaceCenter.Part') to inform kRPC that it should add the contents of the class to the Part class.

Here's an example of what the mod's code might look like:

[KRPCClass (Service='DangIt')]
public class FailureModule : PartModule {
  ...
  [KRPCProperty]
  public float Age { get; }
  ...
}

[KRPCExtensionClass (Service='DangIt', Extends='SpaceCenter.Part')]
public static class PartExtension {
  [KRPCExtensionPropertyGetter]
  public FailureModule FailureModule(SpaceCenter.Part part) {
    ...
  }
}

(As we can't pass arguments to properties, we'd have to declare the property using separate getter and setter methods that take the instance as a parameter.)

Then in the client python code:

...
print part.failure_module.age

I quite like this approach as it has the added benefit of allowing other parts of the SpaceCenter API to be extended. For example, you might want to add some methods to SpaceCenter.Resources for some custom resource that's added by your mod.

[602p]

Alright, that sounds like a great approach to me. My only concern is that I would rather not have to link DangIt to KRPC (unless i've misunderstood, I'd need to compile it against KRPC to get KRPCClass.)

[djungelorm]

Ah yes, I hadn't considered that! Maybe there is a way to provide a 'soft' dependency on those attributes, for example linking against a dll that just contains the kRPC attributes, and nothing else?

[602p]

That would be OK. But I'd rather have a solution where you or I could bundle a dll linked against DangIt and KRPC that would tell KRPC how to find and how to annotate existing functions in DangIt. If I understand correctly, the Attributes are really only markers, so in theory there could be a separate lookup table of extension classes/properties/methods.

For example the Scanner could be extended to also find static classes implementing IKRPCExtention and run an install method that would add services, classes and methods. Not sure how feasible this would be, but I would prefer a solution like that rather than compiling against another DLL.

That might be adding an unneeded layer of complexity that you don't want, so I'll leave it up to you.

[602p]

Another option is using something like described here to write a patch DLL to add attributes from KRPC.dll to DangIt classes at runtime.

With a little tooling I think that could look pretty nice.

E.G. Have KRPC.Scanner find and run all classes implementing IKRPCExtentions method install that would then run TypeDescriptor.AddAttributes(typeof (FailureModule), new KRPCClassAttribute());

[djungelorm]

That's pretty neat! I too would like to avoid having to make people link against an extra dll if at all possible, and this looks like a nice solution.

Could be implemented by having an additional 'scanner' that's runs before the existing one to add all the attributes - then KRPC.Scanner doesn't need to be modified at all :)

[602p]

Sure! I'm not really sure how you want to implement the Metadata for adding attributes to classes. Some sort of IKRPCPlugin interface where all implementing static classes are run (it would define a function like install.) Then the ExtentionScanner would have some extension methods to wrap the kinda-contrived reflection invocations to add Attributes that would be called by the plugin class.

Additionally, a part may have more than one FailureModule (actually subclasses) so I'm not sure how you would want to handle that. Maybe add some sort of functionality to cast a Module to a FailureModule that has been patched with KRPCClass?

I'd happily look at implementing this, but I probably won't have a lot of time until the school year is out 😄

[602p]

Alright, took a look and it turns out it's not really possible to dynamically add Attributes. The (incredibly misleading) tools in ComponentModel only effect some weird representation of the class and are not recognized by System.Reflection.

Maybe we need for the plugins just to modify the ServiceSignature stuff directly. I'd love to hear you input, as I don't fully comprehend the architecture.

You can see my progress here if you want to look over the plugin system. Everything works, but none of the Attributes added are recognized by the Scanner 😢

[dewiniaid]

Having been looking at this for awhile now, I agree with the need to allow dynamic addition of things to the scanner.

Other than potential API confusion, it makes sense to be able to extend existing KRPC internals this way as well in some cases. For example, Part:

        [KRPCProperty]
        public ResourceHarvester ResourceHarvester {
            get { return ResourceHarvester.Is (this) ? new ResourceHarvester (this) : null; }
        }

        [KRPCProperty]
        public Sensor Sensor {
            get { return Sensor.Is (this) ? new Sensor (this) : null; }
        }

        // [....] documentation removed for brevity

If I want to support a new PartModule, it's entirely possible within KRPC to to enumerate all parts on a vessel and find that part module... and then call out to some other entirely different service to get it in a usable form (including things that may not be exposed as KSPFields). It'd be even better if I could go Part.MyPartModule and get its built-in representation right there.

Here's my take on it: (which started turning into 'desired API documentation' halfway through, sorry.)

Reflection

Add and document public methods to inspect and register services/procedures/etc. Essentially, Reflection of services and service signatures. Most of this looks like it already exists in *Signature so the real challenge is making it discoverable and handling modifications at runtime. It might also be possible to useful for overloads to do some functions like "Add a class but don't use its real class name", etc. This ties in to the next bit:

Extensions

Adding classes and enums, to an existing service should be fairly trivial using the above reflection-esque bits.

For the others: Add the following overloads:

public void AddProcedure (object surrogate, MethodInfo method);
public void AddPropertyMethod (object surrogate, string propertyName, MethodInfo method, String attribute);  // note current version is private
public void AddClassMethod (string cls, object surrogate, MethodInfo method);
public void AddClassPropertyMethod (String cls, string propertyName, MethodInfo method, String attribute);  /// note current version is private

Where, upon using the overloaded version with a surrogate, the surrogate (which may be null) is used as the first argument in the ultimate call to MethodInfo.Invoke(), and the first argument is whatever would have been there if there was no surrogate. Thus:

// current ClassStaticMethodHandler's end result
method.Invoke(null, [arg0, arg1, arg2]);
// surrogate version
method.Invoke(surrogate, [null, arg0, arg1, arg2]);

// current ClassMethodHandler's end result
method.Invoke(instance, [arg0, arg1, arg2]);
// surrogate version
method.Invoke(surrogate, [instance, arg0, arg1, arg2]);

Note: While this allows a non-null surrogate to be used for this on method calls, it will be the same instance on all calls to that method (even on different instances of the kRPC-side class).

Partmodules

As a simplified version of the above which likely covers most of the useful cases for extensions:

(possibly using generics, but omitting for simplicity)

public void AddPartModule(Type moduleClass, Type krpcClass, string name = null, string pluralName = null); 
public void AddPartModule(Func<Part, bool> moduleExists, Type krpcClass, string name, string pluralName = null); 

Register a new part module with the Part and Parts classes.

The first argument determines whether the part module exists on the specified part. (Equivalent to the Is() method of current part modules). The first forms is true if part.InternalPart.HasModule(). The second form is true if the delegate (which accepts Part as an input) returns true.

If the part module exists, the kRPC class for it is instantiated using type.GetConstructor(new Type[] { typeof(Part) }).invoke(new object[]{this});

The registration process creates the corresponding properties on Part and Parts using the extension methods above (i.e. they don't/can't modify underlying the C# class):

• name determines the property name on Part. If null, it defaults to moduleClass.Name. It cannot be null if using the second signature.
• pluralName determines the property name on Parts. If null, it defaults to name + "s"

[djungelorm]

Nice - I like the design :)

Modification at run-time should be fairly straightforward. We just need to update the KRPC.Service.Services.Signatures dictionary. When the python and lua clients connect they get the available RPCs from this dictionary, so will auto-discover any new RPCs when they connect.

The C#/C++/Java clients are a bit more complex. These clients aren't dynamic - they have stubs for the available RPCs compiled into them. However, these stubs are generated using a publicly available tool (https://pypi.python.org/pypi/krpctools) so a mod author could generate the stubs for the additional RPCs and release them along with their mod.