krpc
Add services for MechJeb2 and Kerbal Engineer Redux
Supporting apps like KAC with services is awesome.
It would be very useful to be able to access the functionality presented by MJ and KER via RPC. Programming ascent and landing guidance and maneuver nodes would allow for essentially pre-programmed missions which would make the game more fun -- at least for me! :-)
@artwhaley made a MJ service which you can find here: http://forum.kerbalspaceprogram.com/index.php?/topic/62902-112-krpc-remote-procedure-call-server-v034-25th-may-2016/&page=14#comment-2421277 https://github.com/artwhaley/krpcmj
I'm not sure how complete it is. We were planning to merge it into the main kRPC release, but I haven't gotten around to it yet.
Honestly I'm even more interested in a KER service. I know I should be able to do the exact same calculations by streaming telemetry but I am no rocket scientist hehe. Some things like "time to impact", "suicide burn dV" etc sound relatively complicated to calculate manually, but I might be wrong. Arguably, it could even be simpler to create a relatively small aerospace-oriented maths library in pure Python!
I'm going to make some more progress on the MJ service in the next few weeks, because someone else was asking about it too! In the meantime, https://github.com/krpc/krpc-library/blob/master/Art_Whaleys_KRPC_Demos/landing.py contains an example of calculating and performing a suicide burn entirely in Python with KRPC. As a note, it imports the PID controller from the same folder... so just grab the whole folder if you want to use it out of the box.
That folder has some other implementations of functions you might be interested in too - the rendezvous script demonstrates Hohmann transfers, plane changes, and matching orbital velocity, for example...
@Cheaterman as an alternative, there are a number of projects out there bringing equivalent functionality to what MJ and KER offer to https://github.com/KSP-KOS/KOS. There are some essential differences between KRPC and KOS, but KOS may be worth looking at. An example project that works with KOS is https://github.com/xeger/kos-ramp (full disclosure: I am a contributor to this project) which allows users to focus on higher-level concerns while mostly automating the lower-level stuff.
That being said, I'm super excited about the possible integration of MJ and KER with KRPC as it will definitely make for some interesting code. :-)
@artwhaley whoaaa this sounds awesome, basically all the difficult parts of a simple orbital maths library as I evoked earlier are already made and maybe they just need to be consolidated into a nice Python package (or whatever language other people want)?
@mathuin kOS sounds good and all, but I'm really a developer and I can't give up my awesome coding tools for some toy language like kOS if I can actually drive my spaceships with Python! I mean no disrespect but I hope you understand I don't really feel like learning a more limited scripting language if Python can do the job :-)
@Cheaterman No disrespect taken! I have a few years of professional experience with Python (yay Django) but I found kOS to be a lot more compelling for internally-directed missions. With my gameplay style, kRPC's strengths are in telemetry and remote activation, but actual mission programming is pretty straightforward in kOS especially with libraries that abstract away gravity turns and the like with RUN LAUNCH(120000). and so forth. But it's a big big game and there's room for everyone! This addition to kRPC will help all users of the software, and I'm still a big fan of it being added.
@mathuin actually that's a fair point, too - having an option to program things from inside the game does sound even more appealing than kRPC for single launches and as a more general tool for doing most (simpler?) things. But as you said, that doesn't remove any interest from a potential orbital maths library ^__^
EDIT: Maybe, since kOS provides all of this, it might be interesting to create a module that tries to match kOS API somewhat as well, which could also be useful as a transition/translation tool for users who want it?
EDIT2: Oh, actually, what about extending kOS using standard programming languages? But that's a whole other topic...
I had a quick look through the code for KER and the API is public - so should be quite easy to expose stuff through a new service for kRPC. Only possible issue is making sure KER updates values without them needing to be displayed in game (it does this to limit the amount of things it needs to calculate per frame).
Regarding what to expose through the KER service, I think I would only add high-level things (like time to impact and suicide dV) and omit basic things (like vessel mass or speed). Basic things such as these can be obtained from kRPC's SpaceCenter service quite straightforwardly, so it would be extra and somewhat unnecessary effort to add and maintain another API to obtain them. We'd need to work out a list of what qualifies as "high-level" enough to include.
@Cheaterman Regarding adding API to kRPC that more closely matches kOS -- I don't really want to do that in the main mod release as it would double the effort to maintain it and would pollute kRPCs API and actually confuse people more if there were 2 ways to do everything... If someone else wants to make such an API as a third-part addon that's fine though! Also the way kOS and kRPC work are quite different so I'm not sure you could even make the API match perfectly.
I think extending kOS to execute other "real" programming languages has been discussed on the kOS github/forums before. The main problem with this that I see is that the fact that kOS runs inside the game, means that the compiler and runtime also has to run in the game, and therefore be able to run within Unity's C# environment. So for example to embed Python in kOS, you'd either have to implement a full Python compiler and runtime in C#, or somehow get the existing Python implementation to talk to C# via native libraries or something.
Wow! First I'd like to thank you for your involvement in this issue and for actually taking the time to look at KER code and API, that's super cool!
I agree about not exposing duplicate values of what the SpaceCenter already offers. However, other than these, I'm not quite sure what we would want NOT to expose - assuming it's not costly to fetch values from KER since you mention they seem to use some sort of cache. Obviously we'd also need a way to force values to be updated as you mentioned, ideally we might want to know if KER is already updating them to avoid making things computationally expensive. But in any case, I'm not sure any of the KER values (other than the ones we already have direct access to thanks to the SpaceCenter service) can reasonably be dismissed, as they might be useful one day or another?
About matching kOS API, it was mostly something I threw out there without thinking too much about it, but thank you for considering it seriously anyway! I certainly didn't mean to include it in kRPC directly but more of a third party package as you mentioned, if only to avoid duplication/confusion and the burden of maintainance that it would cause, again much like you said. But indeed, it's worth keeping in mind kOS is its own language, so things might not be easy... although arguably it could be an interesting "pet project" to write a kOS parser and translate it to kRPC directly... :-)
Which brings us to the last part you mentioned, but I might want to talk to kOS devs about this instead: if someone writes a third party kOS-like service and therefore exposes it to all languages, then everyone can use the kOS API from their favorite language, and even extend the ingame language with their own modules? (by registering them remotely - feature would need to be added to kOS obviously)
Thanks for reading, and thanks again for your involvement, it's really appreciated ^__^
2018-04-18 18:40 GMT+02:00 djungelorm [email protected]:
I had a quick look through the code for KER and the API is public - so should be quite easy to expose stuff through a new service for kRPC. Only possible issue is making sure KER updates values without them needing to be displayed in game (it does this to limit the amount of things it needs to calculate per frame).
Regarding what to expose through the KER service, I think I would only add high-level things (like time to impact and suicide dV) and omit basic things (like vessel mass or speed). Basic things such as these can be obtained from kRPC's SpaceCenter service quite straightforwardly, so it would be extra and somewhat unnecessary effort to add and maintain another API to obtain them. We'd need to work out a list of what qualifies as "high-level" enough to include.
@Cheaterman https://github.com/Cheaterman Regarding adding API to kRPC that more closely matches kOS -- I don't really want to do that in the main mod release as it would double the effort to maintain it and would pollute kRPCs API and actually confuse people more if there were 2 ways to do everything... If someone else wants to make such an API as a third-part addon that's fine though! Also the way kOS and kRPC work are quite different so I'm not sure you could even make the API match perfectly.
I think extending kOS to execute other "real" programming languages has been discussed on the kOS github/forums before. The main problem with this that I see is that the fact that kOS runs inside the game, means that the compiler and runtime also has to run in the game, and therefore be able to run within Unity's C# environment. So for example to embed Python in kOS, you'd either have to implement a full Python compiler and runtime in C#, or somehow get the existing Python implementation to talk to C# via native libraries or something.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/krpc/krpc/issues/288#issuecomment-382451246, or mute the thread https://github.com/notifications/unsubscribe-auth/AADVthUxIGsWyr9VgmpqSujtvYdXQjI7ks5tp2x9gaJpZM4IznIR .