djungelorm

Cool. There is no server UI in krpc2 (yet). It does auto start a server with default settings though

+1 This is particularly annoying when developing mods, where you frequently quit and reload the game. Add unnecessary delay to the code -> compile -> test loop!

I guess if you are batching lots of telemetry data into a single web request, you mitigate the overhead of making the request. So if you can do that performance should be ok. Not sure if that approach is very extensible though. You'd still need some mechanism for the client to tell the server what it wants included in the response, and doing that as an HTTP request rather than ahead of time would add overhead. I guess in "technical speak" this is the difference between a stateless RESTful API (like KWP/Kerbal Telemetry) and kRPCs stateful approach (where client connection to the server is persistent, and has associated state that persists between requests).

The UI for Kerbal-Telemetry looks awesome! Looks like they are using an HTTP web server running in the game from which you can request a json file via a GET request to get the telemetry. Server code is here: https://github.com/yagiziskirik/Kerbal-Telemetry/blob/master/Kerbal Telemetry/Class1.cs#L356

Oh I didn't realise KWP was a KSP1 mod too. I can't seem to find any trace of it though, do you have a link?

I wasn't aware of Kerbal Web Program, thanks for bringing it to my attention! Looks like it's in very early development so take the following with a giant pinch of salt... I had a quick look over their code on github. It provides an HTTP server (version 1.1 I think?) that listens for HTTP requests, and sends HTTP responses. I guess you'd call this a "REST API"? I can't find any form of structured serialization - looks like everthing is passed around as strings. There is some mention of websockts in the client code, but doesn't appear to be implemented in the server. Not sure what you meant by "front end architecture already built"? AFAIK making REST API querys from JS is essentially built into the language... Based on its internal architecture, I wonder if it is a good fit for your use case, as you want to stream lots of telemetry for multiple vessels at the same time. The overhead of doing that with a request/response REST API would be pretty high, and might limit how much data you can get out of the game per-frame without tanking the game performance. You would also need to do active polling for your alarms. kRPCs streams don't require this back and forth between client and server, once set up, the server just acts like a hosepipe sending you the data. If you want to go the JS route for your frontend, kRPC does speak websockets, and there is a JS client made by someone else https://github.com/eXigentCoder/krpc-node (although not sure how up to date it is). You also don't have to use a client to interace with kRPC. You could send protobuf messages to it yourself - it's a fair bit of work to set this up though.

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