-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
kRPC support #1621
Comments
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. |
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. |
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. |
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 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.
|
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 Once this is done, I guess that the next order of business would be to extend
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. |
So just to rephrase if I understood correctly - 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 Thanks for the contribution to the community and your time. |
That is correct.
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. |
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. |
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. |
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.
The text was updated successfully, but these errors were encountered: