[1.12.x] kRPC: Control the game using C#, C++, Java, Lua, Python, Ruby, Haskell, C (Arduino)... (v0.5.4)

[Jovus]

Just discovered this, and I'm going to use it extensively to convince myself that, no, I'm not just playing games; I'm studying!

 

Two questions have come up as I'm poring over the documentation, though:

1. Can one use KRPC to control non-focused vessels? I'm guessing no, since KSP probably won't be able to process commands for them, but I figured it'd be worth asking. Setting up my own automated refueling busses would be awesome.
2. For Engine and RCS, what exactly does the propellant_ratios() method return? Is it literally a ratio of propellants - so some resource will always be, and the others will be relative to it? Or does it return something more like individual fuel flow rates? I guess I'm asking what's it a ratio to

Thanks so much.

[Speadge]

to 1:

u might want to study the development thread as well

On 20.6.2016 at 11:11 AM, Speadge said:

In addition, i wonder if you can control a vessel that is NOT your "Active Vessel". Alltogether - for really hardcore-player - you can assemble kind of a control room like in RL.

-just an idea

 

 

On 20.6.2016 at 5:18 PM, djungelorm said:

Yep you can already do this! (As long as it's in physics range of the active vessel)

[djungelorm]

12 hours ago, Jovus said:

For Engine and RCS, what exactly does the propellant_ratios() method return? Is it literally a ratio of propellants - so some resource will always be, and the others will be relative to it? Or does it return something more like individual fuel flow rates? I guess I'm asking what's it a ratio to

Propellant ratios are the amount of each fuel that an engine burns. For example, if a engine has ratios where Liquid Fuel is 0.6 and Oxidizer is 0.4, then that means for every 0.6 units of Liquid Fuel the engine burns, it burns 0.4 units of Oxidizer. The values themselves are unit-less. They are also scaled so they sum to 1.

[djungelorm]

kRPC v0.3.5 has been released!

The major changes are:

• Overhauled the autopilot, so it should handle vessels of different sizes better. It auto-tunes the PID parameters based on vessel MoI and torque, and uses a different approach for the target angular velocity calculation. I wrote a tutorial on how it works, how to configure it and the maths behind it here: http://krpc.github.io/krpc/tutorials/autopilot.html
• Support for KSP 1.1.3
• Added science parts - allows you to run experiments, transmit the data etc. http://krpc.github.io/krpc/csharp/api/space-center/parts.html#experiment

Full changelog available here: https://github.com/krpc/krpc/releases/tag/v0.3.5

Enjoy!

[Kahuette]

13 hours ago, djungelorm said:

kRPC v0.3.5 has been released!

...

Full changelog available here: https://github.com/krpc/krpc/releases/tag/v0.3.5

Fantastic!

I've generated new service files for the Haskell client to be compatible with this version.

[Agathorn]

Is there a way to detect what biome the craft is in/over?  I can't seem to find anything in the documentation.  Seems like something that should definitely be there so i'm assuming i'm just overlooking it.

[Agathorn]

Any suggestions on how to find a specific part when you have multiples of the same one?  kOS had a method of tagging a part in the editor so it was easy to find later in script, but I don't see anything like that in kRPC.

[djungelorm]

On 7/2/2016 at 0:15 PM, Agathorn said:

Is there a way to detect what biome the craft is in/over?  I can't seem to find anything in the documentation.  Seems like something that should definitely be there so i'm assuming i'm just overlooking it.

I'm afraid not. Will add it to the next release.

2 hours ago, Agathorn said:

Any suggestions on how to find a specific part when you have multiples of the same one?  kOS had a method of tagging a part in the editor so it was easy to find later in script, but I don't see anything like that in kRPC.

This isn't possible for parts in general, but is for docking ports. I guess we need to add something similar to kOS.

If you have the Docking Port Alignment Indicator mod, you can get the name of a docking port using DockingPort.Name (http://krpc.github.io/krpc/csharp/api/space-center/parts.html#property-KRPC.Client.Services.SpaceCenter.DockingPort.Name)

 

[Agathorn]

Generally it isn't an issue, I just use the stage to discern, but I ran into a situation where the parts were in the same stage

Another question if I may.  I'm having some confusion dealing with orbit information.  I'm seeing really odd numbers.  For example:

>>> print vessel.orbit.inclination

1639.13998943

My orbital inclination is 28.6 degrees

[djungelorm]

32 minutes ago, Agathorn said:

Generally it isn't an issue, I just use the stage to discern, but I ran into a situation where the parts were in the same stage

Another question if I may.  I'm having some confusion dealing with orbit information.  I'm seeing really odd numbers.  For example:

>>> print vessel.orbit.inclination

1639.13998943

My orbital inclination is 28.6 degrees

Ahhh you found a bug! According to the docs it should return the inclination in radians, but it's doing the conversion incorrectly.

This workaround should give you the inclination in degrees:

vessel.orbit.inclindation * (math.pi / 180.0)

 

[Agathorn]

Ah thank you!

[Dunbaratu]

1 hour ago, djungelorm said:

This isn't possible for parts in general, but is for docking ports. I guess we need to add something similar to kOS.

(This was RE: kOS name tags)

When we added the name tags system to kOS, it occurred to us that we could have made the name tags an entirely independent mod.  It's basically just a standalone PartModule plus a ModuleManager config that adds it to each and every part in the game, and what the PartModule does is just so... simple and basic.  Pretty much the only reason we didn't was we couldn't think of any reason anyone who wasn't doing scripted autopiloting could possibly want it.  ("Okay so I named my part... and???  Why did I want to do that again?")

We could try making it separate (and then telling CKAN that it's a dependency for kOS, rather than it being packaged as part of the kOS ZIP itself like it is now).  Then people who are doing a mix of kOS and kRPC could have the same name tag used for both, instead of having to set two different name tags under two different PartModules to do it.

Does this idea interest you?

[Agathorn]

I was thinking the same thing actually.  I even almost installed kOS just to get the tagging.  It is a good idea.

[djungelorm]

12 minutes ago, Steven Mading said:

(This was RE: kOS name tags)

When we added the name tags system to kOS, it occurred to us that we could have made the name tags an entirely independent mod.  It's basically just a standalone PartModule plus a ModuleManager config that adds it to each and every part in the game, and what the PartModule does is just so... simple and basic.  Pretty much the only reason we didn't was we couldn't think of any reason anyone who wasn't doing scripted autopiloting could possibly want it.  ("Okay so I named my part... and???  Why did I want to do that again?")

We could try making it separate (and then telling CKAN that it's a dependency for kOS, rather than it being packaged as part of the kOS ZIP itself like it is now).  Then people who are doing a mix of kOS and kRPC could have the same name tag used for both, instead of having to set two different name tags under two different PartModules to do it.

Does this idea interest you?

Yes definitely interested, and your approach makes perfect sense! If you want to add it as a separate mod on CKAN I'll link it as a dependency from kRPC too?

[Agathorn]

I've been beating my head on this one all day with no success, so i'm hoping maybe someone here has already done this in kRPC or could help me figure it out.

Basically I am trying calculate relative target inclination the same way as MechJeb does.  Here is MJ's code for it: https://github.com/MuMech/MechJeb2/blob/7a0561ddd867bb7698b97b00d45184137b498165/MechJeb2/OrbitExtensions.cs#L495

As I understand it, it is simply taking the angle between the normal vector of the two orbits.  One of the orbits being your craft and the other being the orbit of the target.  

Like I said i've been futzing with this all day long and i'm sure it has to do with reference frames in some manner, but yeah i'm just all confused.

 

[djungelorm]

32 minutes ago, Agathorn said:

I've been beating my head on this one all day with no success, so i'm hoping maybe someone here has already done this in kRPC or could help me figure it out.

...

The following agrees with MechJeb's output (only done some basic testing though)

import krpc, math
conn = krpc.connect()

vessel = conn.space_center.active_vessel
target = conn.space_center.target_vessel
if target is None:
    print 'No target vessel'
    exit(1)

def dot(u,v):
    return u[0]*v[0] + u[1]*v[1] + u[2]*v[2]

frame = vessel.reference_frame
n0 = vessel.flight(frame).normal
n1 = target.flight(frame).normal
print math.acos(dot(n0,n1)) * (180.0 / math.pi)

Only thing to note is that you have to pass the same reference frame to vessel.flight() and target.flight(). It doesn't matter what reference frame, just that they are the same so that the returned normal vectors are in the same reference frame.

[Agathorn]

Oh thank you.  I totally missed that the normal vector was available from those objects.  I was trying to do it by basically taking the 0,0,1 vector from the Orbit and Vessel and convert them to the same reference frame using SpaceCenter.

So apparently I was totally off.

 

[djungelorm]

4 minutes ago, Agathorn said:

Oh thank you.  I totally missed that the normal vector was available from those objects.  I was trying to do it by basically taking the 0,0,1 vector from the Orbit and Vessel and convert them to the same reference frame using SpaceCenter.

So apparently I was totally off.

That approach should also work, it's just a bit more complex.

[Agathorn]

Ahh this will only work if the target is another vessel.  If the target is a body, like the Moon in my case, then I can't use target.flight().  

[djungelorm]

24 minutes ago, Agathorn said:

Ahh this will only work if the target is another vessel.  If the target is a body, like the Moon in my case, then I can't use target.flight().  

here you go

import krpc, math
conn = krpc.connect()

vessel = conn.space_center.active_vessel
target = conn.space_center.target_body

def dot(u,v):
    return u[0]*v[0] + u[1]*v[1] + u[2]*v[2]

frame0 = vessel.orbital_reference_frame
frame1 = target.orbital_reference_frame

n0 = (0,0,1)
n1 = conn.space_center.transform_direction((0,0,1), frame1, frame0)

print math.acos(dot(n0,n1)) * (180.0 / math.pi)

 

[Agathorn]

Huh I thought that was what I was basically doing before.  Maybe I messed something up.  I'll check this out in game and compare it with what I have.

By the way, though maybe I would post this here.  I've gotten a lot of people interested in kRPC after I did this.  This mission, originally done as a livestream, is 100% run by kRPC.  From liftoff to splashdown, including the camera views (I wrote a custom kRPC service to control the FlightCamera), and UI telemetry all handled by kRPC.  I just started the script on my Macbook, and then handled commentary.  KSP runs on my Windows machine so not only was the entire mission run by script, it was run by script over a network

 

[djungelorm]

3 minutes ago, Agathorn said:

Huh I thought that was what I was basically doing before.  Maybe I messed something up.  I'll check this out in game and compare it with what I have.

I tested it with a craft in orbit around kerbin, at a non-zero inclination, with the mun set as the target. Maybe your vessel was in a different situation for which this code does not work?

[Agathorn]

Just now, djungelorm said:

I tested it with a craft in orbit around kerbin, at a non-zero inclination, with the mun set as the target. Maybe your vessel was in a different situation for which this code does not work?

Possibly.  My vessel is still sitting on the launch pad, as I want to use this number to help determine when to actually launch.  However even a vessel on the launchpad has an orbit.

[dewin]

So, I'm working on a mod that aims to add a bridge between kRPC and kOS together for a variety of reasons.  My forum thread is already outdated but has some information on the "Why", but I wanted to mention some of my headaches involving kRPC's API.

One of the big hangups early on (before I ended up just splitting my mod into two assemblies -- and then after some changes it's back to one) was trying to figure out how to "optionally" use kRPC -- the current way of using attributes is simple but doesn't work so well if I'm using reflection.  It would have been handy if there was an additional way to register with kRPC that could be done after startup.  (It's no longer a concern for my project, but thought I might mention it).

Right now, though, my main interest is finding out about connected clients:

• I haven't found a (non-private) mechanism to find all of the currently connected clients.
• Likewise, being able to register for the client events (OnClient{Disconnected,Connected}) would be handy.

The kOS side of the bridge will allow targeting messages at individual vessels or kOS processors.  I'd like to be able to mirror that on the kRPC side (with a message queue per connected client) if I can, otherwise it'll be a single queue on the kRPC side.

[djungelorm]

12 minutes ago, dewin said:

So, I'm working on a mod that aims to add a bridge between kRPC and kOS together for a variety of reasons.  My forum thread is already outdated but has some information on the "Why", but I wanted to mention some of my headaches involving kRPC's API.

One of the big hangups early on (before I ended up just splitting my mod into two assemblies -- and then after some changes it's back to one) was trying to figure out how to "optionally" use kRPC -- the current way of using attributes is simple but doesn't work so well if I'm using reflection.  It would have been handy if there was an additional way to register with kRPC that could be done after startup.  (It's no longer a concern for my project, but thought I might mention it).

Right now, though, my main interest is finding out about connected clients:

• I haven't found a (non-private) mechanism to find all of the currently connected clients.
• Likewise, being able to register for the client events (OnClient{Disconnected,Connected}) would be handy.

The kOS side of the bridge will allow targeting messages at individual vessels or kOS processors.  I'd like to be able to mirror that on the kRPC side (with a message queue per connected client) if I can, otherwise it'll be a single queue on the kRPC side.

Cool idea Not sure I quite understand your design but will go have a read on the thread.

The issue of optionally using kRPC actually came up over a year ago, when someone was concerned about having to create a hard dependency against the DLL from any third-party mod that wants to add RPCs. Unfortunately I put this feature request on the back burner and never got around to it! It should be pretty easy to add an API to register RPCs - I think it's just a case of opening up some of the "service scanner" internals.

For your other two concerns, the relevant APIs exist but are indeed private. I can put together a dev build with the those APIs made public so you can play around if you like?