djungelorm

Cool project! Here's my feedback, hope it helps: Note that we haven't implemented the SpaceCenter API for KSP2 yet. What we have released so far for KSP2 (called kRPC2) is just a proof-of-concept to see if the server communication works (which it does!) We are actively working on implementing this part, and will likely start with the basic telemetry stuff you'll need. The SpaceCenter API for KSP1 and KSP2 is planned to be (almost) identical. So if you want to get coding, you could prototype your interface using kRPC1+KSP1. It should work with minor modification in kRPC2+KSP2 once we've implemented the required APIs. You can do this, and no you don't need to keep switching active vessel. The API is object oriented (instances of objects in the client refer to objects in the game via a unique id number). You can obtain a Vessel object for whatever vessel you like, and then an Orbit object for that vessel, and call the various methods to get orbital parameters for that specific vessel. (it's abstracted like this, as Orbit objects can also refer to things like planets). The SpaceCenter::vessels() function gives you an std::vector of Vessel objects for all the vessels in the game, and SpaceCenter::active_vessel() gives you a Vessel object for just the active vessel. You can treat these Vessel objects just like a normal C++ object, and call the orbit methods they contain. You can do this (in KSP1). I can't really comment on this regarding KSP2 as it's not implemented yet, but in KSP1 this telemetry is available in any view (and we aim to do the same for KSP2). In the documentation, it says which game scenes you can use the class/method/function in (and if none are specified you can assume it's always available). For example SpaceCenter::vessels() and all the orbit methods are available in all game scenes. SpaceCenter::active_vessel() is only available from the flight scene. The alarm API is for creating/managing KSP1 alarms, just like you would do manually using the KSP1 in-game UI. I don't know enough about KSP2 yet to know if these same alarms exist in KSP2. As for the kind of alarm you describe, this is the sort of thing we want to support and is in scope for the mod. One approach that could work for you are events. In kRPC, you could create a server-side expression for "EC < 10%", create a stream that wraps it, and then wrap an event around it. In the C++ client this would give you an std::condition_variable that gets notified when the EC drops below the threshold. There is an example in the docs that does something very similar. It triggers an event when the altitude of the vessel exceeds 1km: https://krpc.github.io/krpc/cpp/client.html#custom-events One thing that could cause problems for this, is whether the game is actually running the EC simulation for s/c1 in the background while you are working on s/c 2. I don't know enough about KSP2 yet to know if that's the case. Edit: you can also set the rate for a stream. So you could configure it to only check "EC < 10%" once per minute to save on game performance.

New release is out! The python client got quite a bit of work, now with proper type annotations and stub generation. Should work much better with auto-complete and type checking in IDEs like pycharm. On the server, added support for independent engine throttles, plus a bunch of bug fixes. https://github.com/krpc/krpc/releases/tag/v0.5.2

KSPSerialIO does two things: sends you a telemetry stream over serial (using a custom serialisation format) and can receive a similar stream of control data. It's very light weight (so great for things like Arduino). It's also very low level - providing you no abstraction over the interface. And the interface is fixed. kRPC is a more complex ecosystem of servers and clients, allowing you to interact with the game from many different languages (including Arduino using the Cnano client). It runs a server in game that can speak various protocols (including protobuf over TCP/IP, websockets and serial io). Clients call "remote procedures" using these protocols. The various client libraries provide abstractions over this so, as Kerbart points out, you get an object orientated view. These libraries also provide high level abstractions like events, and streams. The server is also extensible. Other mods can add RPCs to the server to extend the functionality.

kRPC2 allows you to control Kerbal Space Program 2 from scripts running outside of the game, and comes with client libraries for many popular languages. This is a continuation of the kRPC mod for Kerbal Space Program 1 The mod is a very early work in progress, so don't expect much! Source code: https://github.com/krpc/krpc2 SpaceDock: https://spacedock.info/mod/3322/kRPC2 Documentation for kRPC1 (which is also relevant to this): https://krpc.github.io/krpc ---- In this first proof-of-concept release v0.1.0, there is a single "service", called SpaceCenter2, with a few properties for basic telemetry. It works with the existing kRPC client libraries (as it speaks the same protocol). However we don't yet provide generated stubs for clients like C++, C# and Java. It has only been tested using the python client, which does not require generated stubs (it can auto-generate them on connection). When the game starts, a server is created with RPC port 50000 and Stream port 50001. There is no configuration for this yet - it is hard coded in. Here's an example in Python, with all the currently available telemetry: import krpc conn = krpc.connect() print(conn.space_center2.horizontal_surface_speed) print(conn.space_center2.vertical_surface_speed) print(conn.space_center2.terrain_altitude) print(conn.space_center2.sealevel_altitude)

Here's a quick bug fix release for a fairly major autopilot/control input bug: https://github.com/krpc/krpc/releases/tag/v0.5.1

Yes there is a pdf in krpc-0.5.0.zip

kRPC v0.5.0 has been released This release includes all the changes from nullprofile's fork, and lots more. Full details over on the github release page. Thanks for all the great contributions! https://github.com/krpc/krpc/releases/tag/v0.5.0

The proto file defines the messaging format that a client should use to communicate with the server. You would need to generate Swift code from the krpc.proto file, using a protobuf compiler. Quick google found this which should generate what you need: https://github.com/apple/swift-protobuf There is also documentation on how client/server communication works in the kRPC documentation at these links: https://krpc.github.io/krpc/communication-protocols/tcpip.html https://krpc.github.io/krpc/communication-protocols/messages.html Edit: To get the available RPCs (i.e the spacecenter/active vessel stuff) you could either look in GameData/kRPC for the files named e.g. KRPC.SpaceCenter.json. These files contain details of all the RPCs. Or you can get the RPCs that a server provides by invoking the KRPC.GetServices RPC call.

No worries. Can you be more specific as to what doesn't work? Maybe post the code you are trying to use and what (if any) error messages you are seeing? We also have a reasonably active discord group, might be better asking questions on there as you might get a more timely response https://discord.gg/bXuaTrj

The kRPC documentation is not intended to be a beginners guide to C#. I suggest you check this out first: https://docs.microsoft.com/en-us/dotnet/csharp/tutorials/intro-to-csharp/ Not currently. Added a github issue to get this added here: https://github.com/krpc/krpc/issues/541

Not currently possible I'm afraid. I've added an issue to the github to get this added: https://github.com/krpc/krpc/issues/541

You can control as many vessels as you like, as long as the other vessels are within "physics range" of the active vessel (this is a restriction imposed by KSP, not kRPC). Off the top of my head I think this distance is about 25km. If a vessel moves outside that range, the game will unload it and it won't be controllable. Annoyingly, doing a spacex style launch is kind of hard due to this restriction, as your vessels will be more than 25km away from each other. There are mods to increase the physics range but increasing it too much might cause issues for the game.

Hmmm something must be broken. It should be there. Will investigate. @chaossands kRPC v0.4.8 is showing up for me in the latest version of ckan, and looks like it was successfully added to the meta data repository 10 days ago. Are you sure you have updated your ckan repository?

Yep - it should work with any version of KSP from 1.2.2 and up

kRPC v0.4.8 has been released! The main new addition is that a lot of functionality is now accessible not just from the flight scene, but from other game scenes too! The documentation website also includes a note by every function indicating which scene(s) it is available in. Support for KSP 1.5.1 and Infernal Robotics NEXT is also included in this release. The "NameTag" mod that allowed name tags to be shared between kRPC and kOS has also now been merged into kRPC, so the separate mod is no longer required. A full change log is available here

kRPC v0.4.8 has been released! The main new addition is that a lot of functionality is now accessible not just from the flight scene, but from other game scenes too! The documentation website also includes a note by every function indicating which scene(s) it is available in. Support for KSP 1.5.1 and Infernal Robotics NEXT is also included in this release. The "NameTag" mod that allowed name tags to be shared between kRPC and kOS has also now been merged into kRPC, so the separate mod is no longer required. A full change log is available here

Looks like there is an erroneous space in your code. Try "LiquidFuel" instead of " LiquidFuel"

Yeah currently you have to be in the flight scene, it can't be from the space center scene. I am however working to address this short coming in the next release.

Yes, this is pretty basic functionality. Documentation on how to do this in the python client is here: https://krpc.github.io/krpc/python/client.html#calling-remote-procedures Here's a python example calling launch_vessel_from_sph: import krpc conn = krpc.connect() vessel = conn.space_center.launch_vessel_from_sph(...) Added! Sorry for the delay!

Thanks for spotting this, should be fixed now. (It's set on the KSP-AVC website by the mod developer, so I have to remember to bump the version manually when I do a new release...)

v0.4.7 has been released - just a few bug fixes again this time, as the spare time I can spend on this has been rather limited of late... The full changelog is available here: https://github.com/krpc/krpc/releases/tag/v0.4.7

v0.4.7 has been released - just a few bug fixes again this time, as the spare time I can spend on this has been rather limited of late... The full changelog is available here: https://github.com/krpc/krpc/releases/tag/v0.4.7

Are you sure its not just that sph_h() is always returning zero? It depends on ref_frame. If the reference frame moves with the vessel, then the horizontal speed will always be zero, and so will delta_spd. If this is the case, try with ref_frame = vessel.orbit.body.reference_frame sph_h() is returning floating point values, which will be passed by value in python, so I don't think that's the issue here? Python only passes objects by reference, not simple types like float and int. I think this is a build issue with the current release of kRPC. This has affected a few other things too (including issue 481 and issue 483). Hopefully this will magically fix itself in the next release (which I plan to do sometime this week). In the meantime you could also try this pre-release to see if it fixes the build issue: https://krpc.s3.amazonaws.com/deploy/master/1196.1/krpc-0.4.7-22-g09e0c1c.zip

I had a look at the code for computing terminal velocity, and compared it to how Kerbal Engineer Redux works and they are very different. It's possible that the terminal velocity calculation in kRPC is just totally wrong - and there are no comments in the code explaining what it's doing. I might just recode it to use the same math as KER. Must be a bug in krpcmj. It was coded for a much older version of KSP, so maybe something changed in the KSP API that breaks it.

Not possible currently sorry! I've added an issue on github to get this added: https://github.com/krpc/krpc/issues/484