Jovus Posted June 22, 2016 Share Posted June 22, 2016 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: 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. 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. Quote Link to comment Share on other sites More sharing options...
Speadge Posted June 22, 2016 Share Posted June 22, 2016 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) Quote Link to comment Share on other sites More sharing options...
djungelorm Posted June 23, 2016 Author Share Posted June 23, 2016 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. Quote Link to comment Share on other sites More sharing options...
djungelorm Posted June 25, 2016 Author Share Posted June 25, 2016 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! Quote Link to comment Share on other sites More sharing options...
Kahuette Posted June 26, 2016 Share Posted June 26, 2016 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. Quote Link to comment Share on other sites More sharing options...
Agathorn Posted July 2, 2016 Share Posted July 2, 2016 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. Quote Link to comment Share on other sites More sharing options...
Agathorn Posted July 9, 2016 Share Posted July 9, 2016 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. Quote Link to comment Share on other sites More sharing options...
djungelorm Posted July 10, 2016 Author Share Posted July 10, 2016 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) Quote Link to comment Share on other sites More sharing options...
Agathorn Posted July 10, 2016 Share Posted July 10, 2016 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 Quote Link to comment Share on other sites More sharing options...
djungelorm Posted July 10, 2016 Author Share Posted July 10, 2016 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) Quote Link to comment Share on other sites More sharing options...
Agathorn Posted July 10, 2016 Share Posted July 10, 2016 Ah thank you! Quote Link to comment Share on other sites More sharing options...
Dunbaratu Posted July 10, 2016 Share Posted July 10, 2016 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? Quote Link to comment Share on other sites More sharing options...
Agathorn Posted July 10, 2016 Share Posted July 10, 2016 I was thinking the same thing actually. I even almost installed kOS just to get the tagging. It is a good idea. Quote Link to comment Share on other sites More sharing options...
djungelorm Posted July 10, 2016 Author Share Posted July 10, 2016 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? Quote Link to comment Share on other sites More sharing options...
Agathorn Posted July 10, 2016 Share Posted July 10, 2016 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. Quote Link to comment Share on other sites More sharing options...
djungelorm Posted July 10, 2016 Author Share Posted July 10, 2016 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. Quote Link to comment Share on other sites More sharing options...
Agathorn Posted July 10, 2016 Share Posted July 10, 2016 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. Quote Link to comment Share on other sites More sharing options...
djungelorm Posted July 10, 2016 Author Share Posted July 10, 2016 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. Quote Link to comment Share on other sites More sharing options...
Agathorn Posted July 10, 2016 Share Posted July 10, 2016 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(). Quote Link to comment Share on other sites More sharing options...
djungelorm Posted July 10, 2016 Author Share Posted July 10, 2016 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) Quote Link to comment Share on other sites More sharing options...
Agathorn Posted July 10, 2016 Share Posted July 10, 2016 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 Quote Link to comment Share on other sites More sharing options...
djungelorm Posted July 10, 2016 Author Share Posted July 10, 2016 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? Quote Link to comment Share on other sites More sharing options...
Agathorn Posted July 10, 2016 Share Posted July 10, 2016 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. Quote Link to comment Share on other sites More sharing options...
dewin Posted July 10, 2016 Share Posted July 10, 2016 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. Quote Link to comment Share on other sites More sharing options...
djungelorm Posted July 10, 2016 Author Share Posted July 10, 2016 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? Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.