djungelorm

Please could you add kRPC to the library? Thanks! Brief description: " kRPC allows you to control Kerbal Space Program from scripts running outside of the game. It has client libraries for many popular languages including C#, C++, Java, Lua, Python and Ruby." Edit: Actually, it is already in the list but I didn't find it because there's a typo in the name. It's listed as "kPRC" instead of "kRPC"

No, currently just remote tech.

Hi! kRPCs approach is quite different to kOS - there is nothing running "on the rocket" and no concept of physical storage. kRPC just exposes large parts of KSP's API over the network so external client programs can invoke functions. The client script runs outside of the game - in whatever programming environment you like. There is no default file - the rocket itself (and the game in general) doesn't execute the client script. You need to execute it outside the game. There is, however, nothing stopping you from writing a script that continually checks if there is a new rocket on the launch pad, and if so, runs some other 'default' script.

Glad you got it working! I'll put the instructions on the C++ client docs page. I'll also have a look into whether the configure script can check the version of protobuf it finds.

@EmbersArc potentially yeh. Try compiling with -l:libprotobuf.so.11 to force it to use the correct version of the library.

@EmbersArc I tried building it following the same procedure as you, but don't get any errors at all! I used docker to test it out using a clean install of 16.04. The Dockerfile I used is: FROM ubuntu:16.04 RUN apt-get update && \ apt-get install -y \ wget \ libasio-dev \ autoconf automake libtool curl make g++ unzip RUN wget https://github.com/google/protobuf/releases/download/v3.1.0/protobuf-cpp-3.1.0.tar.gz && \ tar -xf protobuf-cpp-3.1.0.tar.gz RUN cd protobuf-3.1.0 && \ ./autogen.sh && \ ./configure && \ make -j8 && \ make check -j8 && \ make install && \ ldconfig RUN wget https://github.com/krpc/krpc/releases/download/v0.3.7/krpc-cpp-0.3.7.zip && \ unzip krpc-cpp-0.3.7.zip RUN cd krpc-cpp-0.3.7 && \ ./configure && \ make -j8 Just to check: which version of protobuf are you using? v3.1.0 is required. Is that the only error message you get? If not, could you post the entire output from gcc?

They are the x, y and z components of the velocity vector, in meters per second. This is worth a read: http://mathworld.wolfram.com/VelocityVector.html

Version 0.3.7 has been released! Happy Christmas! Here's a summary of the changes: Support for KSP 1.2.2 Updated to use Protobuf 3.1.0 Custom reference frames - more info here: https://krpc.github.io/krpc/tutorials/reference-frames.html#custom-reference-frames Support for the Action Groups Extended mod Various additions to the parts API: part highlighting, whether legs/wheels touch the ground and bounding boxes A full changelog is available here: https://github.com/krpc/krpc/releases/tag/v0.3.7

Version 0.3.7 has been released! Happy Christmas! Here's a summary of the changes: Support for KSP 1.2.2 Updated to use Protobuf 3.1.0 Custom reference frames - more info here: https://krpc.github.io/krpc/tutorials/reference-frames.html#custom-reference-frames Support for the Action Groups Extended mod Various additions to the parts API: part highlighting, whether legs/wheels touch the ground and bounding boxes A full changelog is available here: https://github.com/krpc/krpc/releases/tag/v0.3.7

@PeteWasEre I think those issues were due to the pre-release build being compiled for KSP 1.2.0. I'm not seeing the bugs with the latest pre-release build and KSP 1.2.2. Available here: https://krpc.s3.amazonaws.com/deploy/master/756.1/krpc-0.3.7-122-ge9f70cf.zip

Thanks Diazo! I'll take a look when I, hopefully..., have some spare time! Been a bit swamped recently... I don't think any client side changes would be needed. The <= 9 validation check is only done on the server. Look like bugs There were lots of changes to these parts of KSPs API in 1.2.x. Have you tried the latest dev build? Available here: https://krpc.s3.amazonaws.com/deploy/master/742.1/krpc-0.3.7-110-g5267fdb.zip

You can get the in-game time (called "Universal Time") using space_center.ut. Also, you can use space_center.warp_to to warp to a chosen universal time. Should work fine while you're on the launchpad - if I remember correctly MET is always 0 when you're on the launchpad. Indeed you can! All the vessels in the game can be accessed via space_center.vessels, so you can iterate through that list to find the other vessel, then use the functionality in vessel.control as usual. There is however the restriction that, in order to control a vessel, it must be within physics range of the active vessel - I think its 22.5km by default. The latest pre-release for 1.2.x is available here: https://krpc.s3.amazonaws.com/deploy/master/756.1/krpc-0.3.7-122-ge9f70cf.zip Only known issue preventing me from releasing it is a bug with the moment of inertia calculations when using RCS, so the autopilot might be a bit dodgy if you fly with RCS enabled. Other than that it should work fine!

Hi, yes please open an issue on GitHub. It's the best place to avoid requests getting lost!

You can install the pre-release python client using pip too! Just pass it the path to the zip file. Or use this and it will download it too: pip.exe install --upgrade https://krpc.s3.amazonaws.com/deploy/feature/ksp-1.2/714.1/client/krpc-python-0.3.6-61-g0f6458a.zip

Don't worry - streams aren't going change! I just meant that I'm going to build an efficient event system on top of them

That's the same stack trace I was getting. Should be fixed in the latest pre-release build https://krpc.s3.amazonaws.com/deploy/feature/ksp-1.2/708.1/krpc-0.3.6-46-gc1e39ed.zip

Here's an updated KSP 1.2 compatible pre-release, including a fix for maneuver nodes: https://krpc.s3.amazonaws.com/deploy/feature/ksp-1.2/708.1/krpc-0.3.6-46-gc1e39ed.zip Getting closer to a release, but I still have some failing test cases. Working through the issues as quick as I can!

Thanks @ThomasD! I'm planning to add something exactly like this in the python client library. While your code improves things on the client side, it doesn't address the issue that you have to constantly pull data from the server to check for the event. I plan to add a bit of logic to the server so that we can effectively have the `listen_flight_attr` code run on the server. The client will subscribe to a stream of boolean values, for which it will only receive an update message when the event occurs.

Your code looks good. Although it might depend on the situation the vessel is in when you run it. Could you edit GameData/kRPC/PluginData/settings.cfg and set verboseErrors to True then run it again? Then it'll give us a full stack trace in the error message which might help track down the issue. Is this using the pre-release version with KSP 1.2? There are some issues with maneuver node creation with that version that I'm currently working on a fix for.

Hi! The autopilot is intentionally quite simple. It just provides the functionality to point the rocket in a chosen direction, as this is a basic requirement for writing your first launch script. I consider anything more than that to be beyond the scope of the SpaceCenter service. This is because a more complex autopilot could be implemented as a client program, and my time is limited and I'd prefer to focus on other aspects of the mod such as exposing more of KSPs API (lots of new things to add for 1.2!!!), fixing bugs and adding support for more languages - gRPC coming "soon"..... hopefully!). Of course if someone else fancies writing a more complex AP a pull request on github would be welcome! Re. your specific questions: 1 and 2: I'm happy to make small changes like this, as these changes are just modifications to the interface used to configure the autopilot, not actually changes to the autopilot itself. 3. An auto-throttle controller is pretty easy to do client side using a simple PID loop, so I won't be adding this to the server. For example in my python toolkit I wrote such a thing: https://github.com/djungelorm/krpc-toolkit/blob/master/krpctoolkit/throttle.py 4. I don't plan to add these. Sorry! But it should be possible to do these from a client script. 5. There are some issues with the math behind the current tuning approach, although it's a bit over my head. There is more discussion of this here: https://github.com/krpc/krpc/issues/310 Have you tried tweaking the stopping time and deceleration time parameters? A combination of them should reduce the APs "control authority".

Yes, you can control multiple vessels. However, they must be within physics range of the active vessel. Otherwise, KSP puts their physics simulation "on rails" and you can't control them. I think the default physics range is 22.5km. You can get hold of other vessels via the space_center.vessels list and then control them using their control object.

A kRPC pre-release for KSP 1.3 is available here: https://krpc.s3.amazonaws.com/deploy/feature/ksp-1.2/687.1/krpc-0.3.6-16-g7940236.zip Expect bugs! Also note, this doesn't add support for any of the new features in KSP 1.3 (such as the comms network). It's just a build of kRPC v0.3.6 that is compatible with the KSP pre-release.

@gowthamn Also, regarding parts from other mods, if the part isn't directly supported by kRPC, you can manually access a PartModule's actions, events and fields. See this: http://krpc.github.io/krpc/csharp/api/space-center/parts.html#module

I've not tested it, and I'm not familiar with dmagic. Depends what PartModule it uses. If it's ModuleScienceExperiment then it should work fine. I've written scripts with update rates of about 10Hz, and that was sufficient for precise rocket control. As for a single call to get lots of data - these are coming soon! I'm working on a protocol overhaul in v0.4.0 which will add the ability to do "batched" RPCs. I.e. send multiple calls in a single network message and get all the results back in a single message. However, if you just want to get data out, and do it repeatedly, then you should use streams. Internally, stream update messages are batched together, so one message is sent per physics tick regardless of how many streams you create.

The choice is pretty much one of personal taste, and the pros and cons the language for your particular use case, not the client library itself. For example, if you want the maximum bare metal performance, go for the C++ client, as C++ is compiled to a native executable. If you want an interactive environment, fire up a python console and use that. If you have some existing C# math library you want to make use of, use the C# library. Internally, the client libraries all work in the same way. The fact that KSP is written in C# doesn't affect the choice of client language. The clients all use the same approach to serialize requests and send data over a network socket. Apart from the Lua client (which doesn't support streams) all the client libraries are feature complete. They are also all thoroughly tested (with continuous integration and unit tests). Not sure why you say the Java client is updated late? The Java client was the most recent addition so might not be as mature as the others. All the client libraries are updated when bugs are found, and then released in lock step with the server plugin release - so that all the version numbers match to keep things simple.