artwhaley

Your facebook doesn't include enough information to identify you? That's it's entire point. And take a look at the ads if you'd like to know what information they have on you and share with others. Does it seem odd that those ads just magically seem to relate to whatever you were googling two days earlier? And Amazon doesn't know your name, address, and banking details? What exactly do you think TT is going to harvest that those companies haven't already figured out how to grab and monetize? And... yeah... well... you pretty much said it there. If this was that big a deal, you'd uninstall and delete your account. Sticking around is you flat out agreeing 'yeah, the game's worth putting up with the EULA.' And that's what they're counting on... and why they aren't going to change it. If a few thousand people HAD uninstalled all at once... they might have blinked. But tantrums in the forum... I doubt they've noticed that yet.

I DID read enough to gather that this is YOUR concern. My point was... your identifying data is so completely available to anyone that wants it. Who, exactly, do you imagine is going to buy a list of people who play KSP and do something insidious with it? Getting all of our identities legit stolen would be a gigantic disaster for Take Two and would still expose them to criminal and civil liability. So they're not going to risk that exposure. Are they going to some day sell a list of our identities and whatever they know about our purchase habits to someone else that wants to sell us something that they think we might be a good fit for? Quite probably. But if you don't think those people could have also gotten your contact info and shopping habits from a couple of dozen other sources... you're nuts. Do you trust Facebook more than Take Two? Amazon? Google? But.... given this concern... my question is... why are you still here? Uninstall the game and delete your forum account to limit your exposure. If that's your real concern, address it. It's kind of you to martyr your personal security to try to save all of us.... but your point's made. Save yourself! Unless... the point of all of this is less 'I'm legit worried' and more "I wonder how much I can stir up?"

I've been gone from KSP most of a year. I really tried to read through this whole thread. I really tried. But... seriously people. This is a non-event. If it SEEMS important to you, by all means, go play something else. Preferably something you code from scratch in assembly without a bootloader... so you aren't subject to anyone else's Draconian EULA. Truly it's a testament to how good your life is that this is what you have to be upset about! It's good to be you. Remember that. Do you guys all remove your cell phone batteries and dump the phone into a bucket of water before you play KSP to keep the NSA from tapping in and finding out how you get to Duna?

Suspension is overrated. Lol. I hate parts that touch the ground. I, for one, won't judge if you skip suspension and just make it super hard to break. I don't really have time to get Unity reinstalled and get back up to speed... but if you post a screenshot of the unity hierarchy and the cfg file... we might figure it out from there? I've made it work in the distant past...

I want to say a thank you to all the modders, and to those that have piped up to show support. The OP here is very new... so this might be his first update... so he's NOT going on my list of people to passive aggressively ignore when he asks for mod support in a few weeks... lol. Not that there's a list. But the mod authors DO remember who's been a supportive fan and who's been demanding! We change our interests and schedules just like other players of the game. I go a few months without playing KSP... and if I'm not playing it... I'm probably also not finding the time to work on my mods or other people's. There are great resources in existence if you'd like to help maintain a mod that just 'seems to have trouble keeping up.' There's also - THE STOCK GAME which is the only thing you were guaranteed when you paid for the game, and is developed by the people who you paid that money to! I'm glad I'm not the only one who shrugged at the 1.4 announcement. Thanks, Squad, for at least being honest this time that there would be a follow up. I'm going to wager with the extent of the changes coming with the expansion... we'll actually see a 1.4.2 pretty quickly too... huh? Anyone need help this week recompiling against 1.4.1? I don't have OODLES of time to dig into deep issues, but if it's testing and chasing down a few renamed items in the API, I'm happy to work on a few of them?

You are correct. The wiki is out of date. And has been... I think... since I bought the game a few years ago. Reading through the Mechjeb release or development threads are a good start... though of course they're miles long by this point, so sometimes you just have to post your questions there even if they might have been hashed out 20 pages earlier already. I've been out of the game a while - so this may be inaccurate - but atmospheric flight has not been a priority for the Mechjeb dev team most of the time... so I always expect the air plane bits to fail some. That said, when I reloaded the game the other day, I tried the autoland and it DID work for me on my unscientific single point of data test. The aircraft autopilot sure didn't used to do anything... if it does something now, that's an improvement. The Mechjeb thread is where I'd ask about what does work and for some tips on getting started with it. Your other specific questions... Mechjeb... and a lot of 'machine controlling values based on measurements' systems uses a "PID" controller - where those stand for proportional, integral and derivative. To super simplify - let's pretend we're talking about throttle for a mun lander. We'd measure descent speed and control the throttle to get it where we want it right? A PID controller makes three pretty good assumptions about the behavior. 1. The more wrong the speed is, the harder we should correct the throttle. That's the P = proportional. When you set kP you're telling Mechjeb how hard you want it to adjust for instantaneous errors. The higher the value the more Mechjeb tries to correct for these instantaneous wrong values. 2. The LONGER we've BEEN WRONG... the harder we should correct the throttle. That's what the I term does. setting kI is telling Mechjeb how much weight you want to give to this function. The higher the value, the harder it will try to correct for errors that have existed a while. 3. If we're getting closer to correct, ease back on the correction. That's the D or derivative term. This keeps us from overshooting because it softens the correction if the values are already getting closer to right. So when the P and I start to get results, the D term weakens the correction so that hopefully everything evens out around zero instead of oscillating wildly. So the higher you set the D term, the stronger this resistance to over correction is. There are whole BOOKS on how to tune a PID system, but what I just explained is enough to start playing with it! If it takes to long to start correcting, increase the P. If it gets CLOSE... but never gets right on the money... increase the I... if it over corrects... increase the D. If it is behaving really weird... turn them all down and start back at the P. Q is short hand for 'dynamic pressure.' Think of it as the force of the atmosphere trying to slow or break your rocket. The faster you're going and the lower you are in the atmosphere, the higher Q is. If your Q is too high, you're wasting delta-v fighting your way through the soupy lower atmosphere. So you limit Q during ascent so that Mechjeb will throttle back at a certain speed and keep throttle low until you're high enough that the air resistance losses are acceptable. When you watch real rocket launches you'll hear them call out Max-Q as they pass that point... and then shortly after they'll call a "Throttle Up" Where they ramp back to maximum power. The Force roll bits have two numbers - one for the vertical ascent and one for the pitchover of the gravity turn... and they do what they sound like they should do - set the roll angle of the rocket. This is handy for situations like the space shuttle where it needed to roll a certain way for gravity to counteract the off center thrust.... but in game... it's more useful for things like making sure the SRB's are perpendicular to the ground before you separate them... which decreases the chance of one falling back into your main engine.

I've done a lot of work with docking ports, including multiple ports on a part, so I think I can help you get part way. Are you putting individual transforms with unique names in the model for each port, and then pointing a different ModuleDockingNode at each of them? Doing THAT will get the docking working. THEN - giving each port ANOTHER transform, this time with (I'm going from like 2 year old memory here) the GREEN axis pointed out in Unity. (So it's co-located with the dockingNode, but oriented differently!) These nodes also each need a unique name - and they get assigned as the controlTransformName for each ModuleDockingNode. That will make 'control from here' work on all of the ports... Though they won't be labeled... you'll just have 6 'control from here' buttons and have to guess which is which. As for making the ports targetable... well... there you might be screwed. There's SOME possibility that it could use whichever 'control from here' you'd last selected? I haven't tested that. More likely... not... unfortunately. I can't think of a good way to make this work. You MIGHT look at SSTU as well... he also uses multiple docking ports, and I know there's a plugin module involved, but haven't investigated what it does or if it solves this problem. In stock... 'set target' is by part... I can't think of a way to tell it to select a specific port. If you figured out what transform it used by default.... you could animate it to move to the right docking port based on a menu selection... maybe? Sorry! I could only get you part way!

The above suggestions are good- make sure your docking node is located outside the collider. It looks like you've got the blue arrow on the docking node pointing out into space correctly? Blue arrow points towards where the other ship will be when docking, just to be clear. Working correctly in the VAB means your reference attach node is working properly. It shouldn't need to be said, but there's no reason not to... so you might as well explicitly define the docking node - nodeTransformName = dockingNode

I love this idea! I'd considered something similar before... and was thinking about a modmaking wiki where we'd try to get the community to maintain all of the current wisdom on a particular type of part on each page... and then maintain 'reference parts' like what you've done as well - so instead of sorting through 10 tutorials and having to ask 'what still works?' and 'what's best now?' you could have a single place that was always current. I'd be happy to help out if you'd like? I could contribute an engine and a docking port at some point? Also - single most useful thing ever would be someone contributing landing gear and landing legs. Those still confound me half the time after 2 years of modding. I didn't see the Unity file in the release zip? Was that intentional?

Crap. This might be me. I think I added those bits to the orbit class, and I wasn't being imaginative enough to come up situations where it wouldn't be a vessel. Unfortunately, I think I cheated and used an API shortcut to get those numbers, so even looking at the C# code for those methods in the orbit class won't help you figure out how to derive it by hand. And off the top of my head I can't remember whether anything in that shortcut would make it possible or impossible to adapt the same method to celestial objects... I'm buried in RL and never find time to play at the moment, and barely follow this thread, but if I get a chance I'll take a look to at least see how hard it is to add this function to the orbit or celestial body class... or if I can come up with a smarter way to help. I tried to brainstorm a stupider way to help too... something like spawning a vessel and giving it an identical orbit... but those functions don't really exist either! Hmmm.

Hey, I saw some of SpaceX's look rougher than that! You didn't have a fireball that obliterated the camera filming it like they did one time I was watching! I don't know if it helps with your approach at all, but in the library at https://github.com/krpc/krpc-library/tree/master/Art_Whaleys_KRPC_Demos my landing script has a python port of the mechjeb suicide burn algorithm (with a couple of changes. I think I do a better job of clearing terrain obstacles because I test them along the descent path, not just at the projected landing site... and I make my calculations and fly my landings assuming 95% of max thrust, but with the loop testing if we're ever over speed and boosting to full power when necessary, for an extra safety factor.) It works pretty reliably for automated landings on the mun, but that's the only test case I'd done with it. It doesn't consider atmospheres at all, but still could be useful to you in that final landing burn phase. It looks like you're chasing the retrograde bug there at the end, and an over correction takes you too far from vertical? Perhaps a final phase is in order where if the horizontal speed is less than some threshhold, it simply locks vertical instead of trying to chase down those last few meters per second and landing on it's side? Good idea on passing spacecenter.ut to the pid instead of just time.now() which IS totally what I've been using in my PID loops! I'll look at rewriting it this way so it adjusts for lag!

Hey! That's looking like GREAT progress! If I had to wager a guess without seeing the code or testing anything here... I'd actually guess it's a matter of scales that can be fixed with a simple bit of arithmetic. Pitch and roll return values between -180 and 180 and heading returns values between 0 and 360. If your unity model can have it's pitch, yaw, and roll set as 0 to 360 values, or you can convert pitch, yaw and roll to the format you need, make sure you've done something like - if(pitch<0) pitch += 360; if(roll<0) roll += 360; I may be missing something, but that's my first guess!

You should pass the reference frame as you request the direction. There may be a default that gets assumed if you don't specify, but the documentation doesn't tell us what it is. Something like : var vesselDirection = vessel.Direction (vessel.SurfaceReferenceFrame); The example here shows some ways to work with that. https://krpc.github.io/krpc/tutorials/pitch-heading-roll.html Without TOTALLY thinking through the 3D space implications.... it sure SEEMS to me that the roll, pitch and heading values ((again, from a flight(vessel.SurfaceReferenceFrame) object)) COULD be used to rotate your ball? I hate 3D rotation math... so hopefully someone smarter than me volunteers how to actually relate one to the other!

The Navball seems like it ought to be relatively simple in Unity, since you're really just rotating a 3D model in front of a camera? As to a map view... if you're doing it the hard way... I've got this - It's ancient C# code from when I was playing with Telemachus years ago and it's terribly documented - and was just a test - all the orbital parameters are hard coded in. It's only giving a 2D display, thus only really works for two vessels when their planes are matched, and I'm SURE there are a BUNCH of cases under which it doesn't work right at all, but it might get you STARTED on thinking through the steps to draw an orbit. I make NO guarantee that it's RIGHT at all... and don't claim to really remember how it worked if it did! It draws the planet, the atmosphere line, the ellipse of the 'active vessel's orbit and a dashed line to show it's current position along that ellipse, then the target vessel's orbital ellipse and current position line. float planetr = 600; //radius float planetatmo = 70; //atmosphere thickness in km float biggest = 0; //determines what the biggest ellipse that needs drawn is float scalefactor = 1f; // multiplier, used later float windowsize = 390; //myship variables float shipsma=751; float shipsmi = 713; float shipapa = 151; float shippea = 75; float shipmea = 3.1415f; float shiplan = 15; float shiparg = 15; //arg of periapsis PointF shipcenter; float shipscaledx; float shipscaledy; //targetship variables float targetsma = 751; float targetsmi = 713; float targetapa = 151; float targetpea = 75; float targetmea = 3.010101f; float targetlan = 180; float targetarg = 15; PointF targetcenter; float targetscaledx; float targetscaledy; //myship next orbit variables float nxtsma = 751; float nxtsmi = 713; float nxtapa = 151; float nxtpea = 75; float nxtmea = 3.010101f; float nxtlan = 45; float nxtarg = 15; PointF nxtcenter; float nxtscaledx; float nxtscaledy; //graphics crap - including pen colors Graphics g = panel1.CreateGraphics(); System.Drawing.Pen planetBrush = new System.Drawing.Pen(Color.Goldenrod, 3); System.Drawing.Pen atmoBrush = new System.Drawing.Pen(Color.Goldenrod, 2); atmoBrush.DashStyle = DashStyle.Dash; atmoBrush.DashPattern = new float[] { 10f, 10f, 5f, 10f }; System.Drawing.Pen myBrush = new System.Drawing.Pen(Color.Cyan, 1); System.Drawing.Pen targetBrush = new System.Drawing.Pen(Color.Green, 1); System.Drawing.Pen nxtBrush = new System.Drawing.Pen(Color.Blue, 1); //Figure out what the biggest thing we have to draw is and scale that to the window's resolution. biggest = Math.Max(planetr, shipsma); biggest = Math.Max(biggest, targetsma); biggest = Math.Max(biggest, nxtsma); scalefactor = windowsize / biggest; scalefactor = (scalefactor * .4f); //rescale everything planetr = planetr * scalefactor; planetatmo = planetatmo * scalefactor; shipsma = shipsma * scalefactor; shipsmi = shipsmi * scalefactor; shipapa = shipapa * scalefactor; shippea = shippea * scalefactor; targetsma = targetsma * scalefactor; targetsmi = targetsmi * scalefactor; targetapa = targetapa * scalefactor; targetpea = targetpea * scalefactor; //draw planet Point planetcenter = new Point((int)windowsize / 2, (int)windowsize / 2); Point planetcorner = new Point((int)(planetcenter.X - planetr), (int)(planetcenter.Y - planetr)); g.DrawEllipse(planetBrush, new Rectangle(planetcorner.X, planetcorner.Y, (int)(2*planetr), (int)(2*planetr))); g.DrawEllipse(atmoBrush, new Rectangle(planetcorner.X-(int)planetatmo, planetcorner.Y-(int)planetatmo, (int)(2 * (planetr+planetatmo)), (int)(2 * (planetr+planetatmo)))); //draw ship float angle = shiplan + shiparg; // rotation of orbit's SMA relative to Origin of Longitude float centeradjust = 0.5f*(shippea - shipapa); shipcenter =new PointF((float)planetcenter.X-centeradjust,(float)planetcenter.Y); Point shipcorner = new Point((int)(shipcenter.X - (int)shipsma), (int)(shipcenter.Y - (int)shipsmi)); using (Matrix rotate = new Matrix()){ GraphicsContainer container = g.BeginContainer(); rotate.RotateAt(angle, planetcenter); g.Transform = rotate; g.DrawEllipse(myBrush, new Rectangle(shipcorner.X,shipcorner.Y,(int)(2*shipsma),(int)(2*shipsmi))); g.EndContainer(container); } float progressangle = (shipmea * 360) / 6.28319f; progressangle = progressangle + shiplan + shiparg; Point shippoint = new Point(); shippoint.X = (int)((windowsize) * Math.Cos((Math.PI / 180) * progressangle) + planetcenter.X); shippoint.Y = (int)((windowsize) * Math.Sin((Math.PI / 180) * progressangle) + planetcenter.Y); //textBox1.Text = shippoint.X.ToString(); //textBox2.Text = shippoint.Y.ToString(); //textBox3.Text = progressangle.ToString(); g.DrawLine(myBrush,planetcenter, shippoint); //draw target angle = targetlan + targetarg; centeradjust = 0.5f * (targetpea - targetapa); targetcenter = new PointF((float)planetcenter.X - centeradjust, (float)planetcenter.Y); Point targetcorner = new Point((int)(targetcenter.X - (int)targetsma), (int)(targetcenter.Y - (int)targetsmi)); using (Matrix rotate = new Matrix()) { GraphicsContainer container = g.BeginContainer(); rotate.RotateAt(angle, planetcenter); g.Transform = rotate; g.DrawEllipse(targetBrush, new Rectangle(targetcorner.X, targetcorner.Y, (int)(2 * targetsma), (int)(2 * targetsmi))); g.EndContainer(container); } progressangle = (targetmea * 360) / 6.28319f; progressangle = progressangle + targetlan + targetarg; Point targetpoint = new Point(); targetpoint.X = (int)((windowsize) * Math.Cos((Math.PI / 180) * progressangle) + planetcenter.X); targetpoint.Y = (int)((windowsize) * Math.Sin((Math.PI / 180) * progressangle) + planetcenter.Y); //textBox1.Text = shippoint.X.ToString(); //textBox2.Text = shippoint.Y.ToString(); //textBox3.Text = progressangle.ToString(); g.DrawLine(targetBrush, planetcenter, targetpoint); g.Dispose(); myBrush.Dispose();

The code tags! On the markup/formatting bar click the <> button and that will pop up a window to type your code into, and you can even tell it what language to get it to color it correctly if it actually is code! And a fully automated mun mission wouldn't be trivial, but it's certainly doable. I think almost everything you need to accomplish it is in my version of the library repository - https://github.com/artwhaley/krpc-library/tree/master/Art_Whaleys_KRPC_Demos There's a launch script that's self explanatory, Then in the rendezvous.py file you'll find methods for a hohmann transfer - they'll have to be recoded because I think they intercept a vessel only, but swapping the target_vessel for target_body ought to be just about the extent of it. This would work fine for giving you a rough Transmunar Injection Burn. Then you'd enter munar SOI and have to write a bit of code to burn radial + or - to adjust periapsis. Then you'd circularize at periapsis (similar to how it's done in the launch script at apoapsis) Then there's an automated landing script in the folder that handles reasonably efficient landings on vacuum bodies! If I ever finish the code for the KRPC mechjeb service, it's WAY easier. When I had that hacked together without reflection, it was about 20 lines of code to launch and transfer and land on the mun... because you were just feeding parameters to mechjeb an then activating the autopilots.

I don't think he's trying to modify the plugin, I think he's trying to make a client... if I understand right! I'm a novice too at c# - mostly learning as I hack at KRPC's server code for various reasons, and I haven't done a c# client yet, but I THINK what you're looking for are the classes in the client. Now, spaceCenter() is accessed as a method, so you probably would need to use reflection to grab it... and I hate reflection. BUTTTTT I think I can get you going without that. I haven't TESTED this code but it didn't throw errors in visual studio and SEEMS like it would work. You can explicitly define the type of a KRPC.Client.Connection object, and hold THAT in your user defined class... then access it's spaceCenter method when you need to. A quick example would be - KRPC.Client.Connection conn = connection; KRPC.Client.Services.SpaceCenter.Vessel vessel = conn.SpaceCenter().ActiveVessel; And I also explicitly defined the type for a vessel. There... may WELL be a way to explicitly define the type for a spaceCenter object as well... but my five minutes of poking through the autocomplete suggestions didn't show it to me, and this SHOULD get you going until smarter people chime in and make it easier for you.

I need a new phone every 18 months, but Voyager is still working fine after nearly 40 years - using "8-track" magnetic tape for storage between transmissions? Something's up. I wonder if I can change the tape in my phone and get another year out of it?

I just started this - Ignition, by John Clark. The whole text is free online. He was a researcher with the U.S. Navy between the 40s and 60s when the major work was being done on liquid propellants. I'm enjoying it thoroughly, and thought you guys might too! Link - https://archive.org/details/ignition_201612

@sarbian Gets MORE people blaming him when they can't launch a rocket that has giant fins on the very top and a fairing closed around the SRBs than any 10 of the rest of us combined. He has saintly level patience when it comes to dealing with people asking for support. He said he's already tried to duplicate the problem even though nobody gave him logs, which he is VERY clear about as a basic requirement before he'll feel obligated to help out. Then he told you it was going to be a while before he got back to it. I didn't take his post as 'punishment - because you were naughty I'm going to refuse to support it for two weeks to teach you a lesson!' It was simply him saying he was going to be busy. And he doesn't OWE us support. Shrugging and saying "I dunno... I guess don't use this mod?" would be a perfectly reasonable answer but instead he said he'd work on it more, even without logs, but that it would be a while. What more do people want from him? If we looked at the number of hours I've played this game... vs the number of hours I'd have played this game WITHOUT mechjeb to take care of both the routine and boring (launches!) and the difficult and tedious (interplanetary transfers and maneuver planning), I'd say Squad probably owes Sarbian about 80% of what I paid for the game. And then include the fact that a lot of my KSP time has been since I got interested in modding... and... I don't know what plugin author HASN'T at some point had to dig through Mechjeb's code to figure out how to do or access something... I bet I'm not the only one who can say that well over half of my enjoyment of this game has hinged on work sarbian is involved with.

If I could get it configured correctly, I'd use the HECK out of it in Blender and Unity when modding the game. THOSE are two applications where the ability to manipulate my view while manipulating objects separately would be fantastic. I find myself frustrated with getting the view I want in those applications very commonly. What you're doing looks great, though as others have said, in KSP the view doesn't actually NEED all that much manipulating, and almost never does it need to be manipulated quickly, so I'm not sure KSP gamers are the right target for your product. But a 3D mouse aimed at the graphics and 3D content creation markets would be something I think you could sell a lot of!

What @SpannerMonkey(smce) said. This line in the .cfg file is telling KSP that the docking connection point is an empty game object in Unity, with the blue arrow pointing out (as in, towards the other ship that will dock with this port) named dockingNode. To make it work, all you have to do is create and position this empty game object correctly!

Hey, you're making lots of progress! On your UV map - it looks like you've got something you can work with, which is a great start! For the best possible results, you want to arrange and size all of those 'UV islands' (the separated chunks of your model) so that they fill as much as possible of the square image. The reason for this is 'texture density.' If you scale everything up as large as you can on the image, you've got as many pixels as possible to hold visual information. If things are scaled down small on the UV map, they will look grainy and 'low resolution' when they get into the game. We really need to push the blender tutorials a bit more, I think. Lots of people find that (excellent!) wings 3D tutorial and jump into this with Wings... and then run into the problem that none of us who are active here to help actually use it. Most people are working in Blender (as far as free software goes.) So your Wings specific questions are just going to take more time to get answers, because there are fewer people who know how to help you. As to the question of export - I don't believe there's a way to go directly from Wings to .mu. You'll use unity to create your .mu, which is the recommended method even for people working in blender which DOES have a direct to .mu plugin available.

Reading the devnotes and seeing bits about how some low level functions are being worked on to allow making history to deal with objectives and placing vessels onto surfaces and such... got me wondering - is Making History going to include changes to any of the API DLLs that mods typically compile against? If so - will there be a general stock update that rolls out a 'Making History capable' set of DLLs, and then you'll either get the DLC and USE the new features, or you won't? I ask because if it means there will be two sets of Assembly C# and Unity Engine DLLs in the wild at the same time - every plugin mod would then need a Stock and a Making History build... and that seems like it might well cause some major headaches? Has this been given thought yet?

Well, then... that experimental version of the SpaceCenter dll ought to help, as it lets you grab density for any point in space. Let me know if there's anything else that would both help, and be broadly applicable to others. I think all 4 methods in that PR fit the bill. I always try to strike a balance between those two with contributing methods to KRPC, and Djungelorm has been pretty patient with me so far! lol.

I gave this a try... and am getting results that agree exactly with the aeroGUI window... so I think it's working. I temporarily had a method to get the temperature out, and that agreed with the aero GUI as well, and was considerably warmer than the FlightGlobals.getExternalTemperature results, so I THINK it's getting the correct temperature adjusted for latitude. var adjustedPosition = referenceFrame.PositionToWorldSpace(Position.ToVector()); var altitude = InternalBody.GetAltitude(adjustedPosition); var latitude = InternalBody.GetLatitude(adjustedPosition); var pressure = FlightGlobals.getStaticPressure(adjustedPosition); var temperature = FlightGlobals.getExternalTemperature(altitude, InternalBody) + InternalBody.atmosphereTemperatureSunMultCurve.Evaluate((float)altitude) * (InternalBody.latitudeTemperatureBiasCurve.Evaluate((float)latitude) + InternalBody.latitudeTemperatureSunMultCurve.Evaluate((float)latitude) // fix that 0 into latitude + InternalBody.axialTemperatureSunMultCurve.Evaluate(1)); return FlightGlobals.getAtmDensity(pressure, temperature); Here's a VERY experimental version of the space center dll, that should replace the one in your gamedata/krpc/ folder... TEMPORARILY AND WITH CAUTION. https://drive.google.com/file/d/0B3q8VwW68f8AdXhEQVR3UlpPWUk/view?usp=sharing It adds four methods to the celestial body class that have been spawned by this discussion - latitude, longitude, and altitude, and atmospheric density from position methods. Is there any need to be able to get temperature or pressure at a given position, if you already have the density? They're easy to implement, but if they're unnecessary I hate to clutter up the API. The code for the changes I've made is all visible in my fork, via the pull request.