kRPC support - Githubissues

dylanede commented 7 years ago

kRPC (an RPC server for KSP) supports extensions to the remote API through "services". For automation purposes it would be useful to provide an implementation of such a service for remote access to things like the flight planner, trajectories (given a reference frame) and predicted apsides.

pleroy commented 7 years ago

If you want to contribute to this, that would be great :-) The first order of business would be to write a design document describing the API that Principia should expose through kRPC (or alternatively gRPC). We use protocol buffers internally, so that might be a good starting point for the API.

drac555 commented 6 years ago

Has any work been done on this? Seems like no one is putting any initiative towards it, but it'd be really awesome if Principia had an API for kRPC.

pleroy commented 6 years ago

No work has been done as far as I know. See my reply above regarding us welcoming contributions, and about first designing what the API should look like and why.

A limited effort has been to expose a stable API for guidance purpose (#1659) but this is for well-scoped requirements and it is not going through RPCs.

erplsf commented 3 years ago

I have started having having interest in this topic and had some small success in my local setup.

So here's where my interest lies - I want to query Principia as a source-of-truth for physics and orbital data to do transfer calculations and other math, and to be able create Flight Plans and manœuvres from kRPC for easy/visual confirmation/usability.

Sadly, most of this data, (as-far-as-I-looked) is not exposed via ExternalInterface or other easily-usable C# interface.

As stated here, you can enhance C# code with attributes, and kRPC will find them and generate it's code/interface for client/server parts. So I have a question:

Should I fork, and try adding/exposing more of this functionality as C# code so it's easily accessible by kRPC?
Or should this be a separate project which loads Principia by using reflection and tries/access internals of C++ implementation via private adapter that's present in ExternalInterface, and in turn exposes it as C# code which is then turned into kRPC code?

pleroy commented 3 years ago

First off, it's a terrible idea to do reflection on our code, as whatever you do will break in a few months. The interface between C# and C++ is automatically generated, and it literally changes all the time; for context, see the history of journal.proto.

So you have to go through ExternalInterface, as it's the only API that we commit to maintaining. I am fine with adding attributes to the functions there if it helps.

Once this is done, I guess that the next order of business would be to extend ExternalInterface to accomodate your needs. Please understand that ExternalInterface is a big liability for us as we'll need to maintain it for years, long after you've lost interest. So we must follow an orderly process:

Please write a design document detailing the APIs that you want added, with some indication of why they would be useful to users. Keep the API as narrow as possible: don't go exposing everything "just in case", we will push back.
Once we have an agreement, you can send us PRs. Keep the PRs small (ideally one function at a time) as it will make reviews easier. Be prepared for demanding code reviews: Principia has more than 130,000 SLOCs, we won't survive if we don't insist on high quality code.

We would prefer that you don't fork the mod, by the way. It will be impossible for you to track our releases (how many mods release every months for years?) so that would be a disservice to the community.

erplsf commented 3 years ago

So just to rephrase if I understood correctly - ExternalInterface is the only stable class among C# code, and any other C# class/code is subject to internal changes?

If that's the case, I'll probably still have a try at going the reflection route - just to get feeling of what I actually need and would use from the internal API, so I can have a better sense what to write in a design document and how to sensibly expose the internals I would need. (I'm still scratching my head a bit on how is anything able to be called on a final Plugin instance...) And if that horribly fails I'll try write a document just as an end user.

Thanks for the contribution to the community and your time.

pleroy commented 3 years ago

ExternalInterface is the only stable class among C# code, and any other C# class/code is subject to internal changes?

That is correct.

If that's the case, I'll probably still have a try at going the reflection route - just to get feeling of what I actually need and would use from the internal API, so I can have a better sense what to write in a design document and how to sensibly expose the internals I would need.

That may be a perfectly valid way to experiment, with the understanding that some of the code that you will write will have to be thrown away in the final version.

erplsf commented 3 years ago

I've tried to go via reflection route (and not just forking the project/extending it with new methods/classes) to keep things clean, but hit a glass wall it seems. Most of the methods that I want to call - FlightPlanExists(vessel_guid) CreateFlightPlan... are behind the Plugin() call, which is an IntPtr defined/initialized in PrincipiaPluginAdapter. I got the reference to this object - please have a look here, but I have no real idea how to call anything over this IntPtr boundary, or how it is achieved in original project.

erplsf commented 3 years ago

As my goal wasn't to create a standalone interface between Principia and kRPC, I've decided to fork the project and add what I need for testing. When I gather enough data I'll prepare a proposal. For now, here's the link the reference to the call/code I've implemented.

mockingbirdnest / Principia

kRPC support #1621