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().

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.

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.

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

Ah thank you!

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

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.

Not dead, just not at the top of my list but i've been chipping away at things. This would leave me free to focus on the core and be content knowing that the complex system of research requirements can be handled by your amazing code, so that would be awesome.

@nightingale in regards to "Science System Overhaul Mod"... I have been working on such a thing for a long while now, called RealScience. Would you be interested in collaborating? There is one part of it that deals with experiment conditions that would be right up your alley as it is very similar to the various contract requirements systems you have built for CC. https://github.com/jwvanderbeck/RealScience/ and https://github.com/jwvanderbeck/RealScience/wiki/Refactor-Design

TestFlight 1.7.0.0 Changes Lots of work on reducing TestFlight's Garbage footprint Performance improvements FIX: When assigning R&D to a part, first immediately apply any applicable tech transfer data FIX: KSC TestFlight window is now available even if TestFlight is disabled in that save FIX: Cleaned up left over direct log statements that were polluting the output_log file FIX: Fix NRE in TestFlightCore outside of Flight scene FIX: Fix how modules are enabled and disabled due to interop changes that was causing some modules to never become active when they should FIX: Fix NRE in the TestFlight Editor window. FIX: Fix issue with part selection locking for R&D Window in Editor CHANGE: TechTransfer and MaxRnD now stack UPDATE: Recompiled for KSP 1.1.3 UPDATE: Recompiled for RealFuels 11.3.0

It should indeed be using whatever your locale dictates as the date format. I'm not exactly sure where that is set though. The existing version continues to work fine in KSP 1.1.3, but to avoid confusion I have updated the metadata and released a new version.

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.

This should be fixed in the latest beta and thus should be fixed in the final release of 1.7

Honestly I don't see any reason to mess with kOS when kRPC can do everything kOS can do plus more? I used to use kOS before I found kRPC, and I have never looked back since switching. Really the only thing kOS has is an in game "terminal" which honestly was what I hated about it lol. I can't think of anything else it does that kRPC doesn't.

Yeah looks like we had a placeholder . I didn't know that so very cool.

The Agena is indeed an awesome final stage engine, but I thought you already had the Agena? I have one in my RP0 game, unless we just co-opted one of your other models and renamed it which is entirely possible The LR105 is still my goto second stage engine though. I use the Agena for once i'm already in orbit, for *LI or sat positioning.

LR105? Oh god please be the LR105

I made this "QuickLook" at SSTU for the RO guys, and just thought i'd share it with you here:

Ah ok fair enough. I didn't even consider that our configs could be causing that, as I just assumed the code released when it detected no fuel but I guess it is more time based. For now I can decouple manually. I'll chat with you more in IRC. Thanks!

So if I set the interstage to auto decouple, it is supposed to do that after all fuel in the solid motors has burned out right? For me it seems to decouple while there is still at least a tiny bit of fuel left, causing it to jet forward and crash into the stage above it

Ah excellent!

Sorry. The hope was KSP 1.1.3 was going to fix it, but alas that isn't going to be the case I need to talk with @DMagic , as I thought he already had implemented a work around but if that isn't the case then i'll figure something out.

Ever pulled your fairings, or something else, off a rocket to look underneath or do some work, then put them back on, launched and then realized that KSP messed up your staging with the fairings? This happens sometimes because when you remove the fairings if they were the only parts in the stage, KSP will auto delete that empty stage. There are work arounds, but I personally found this super annoying. So here is my workaround, shared for all if you desire its usage. This is a dead simple mod, one line of code really, that simply tells KSP to NOT delete empty stages in the editor. Download: https://github.com/jwvanderbeck/EmptyStages/releases/latest Source: https://github.com/jwvanderbeck/EmptyStages License: CC BY-SA-NC

1) Pretty sure it is pascals which is what KSP uses. As for the value, it can be whatever it is just a multiplier against the base ignition chance. So 1 would be no change, 0.5 would make it half as likely to ignite than normal, 2 would make it twice as likely to ignite. 2) Seconds

1. Not used anymore 2. The values indicate the base failure rate for a given amount of data units. The key is the amount of data, the value is the base failure rate at that point 3. key is the pressure, value is the modifier applied against ignition chance as a multiplier MTBF is 1/BFR if I recall correctly. But bear in mind that MTBF is more of a derived number provided to present something to an end user that looks good and makes sense to them. As for your last question about ReducedMaxThrust, the default is a 50% reduction if not specified.