pincushionman

Because a big part of manufacturing these kinds of things successfully is in the manufacturing techniques, which are harder to steal because they aren't just drawings and documents? There's this prevalent attitude in management that documenting everything about what you do automatically makes you more successful as a company, but the reality is in successful companies there's still a huge ammount of tribal knowledge that can only be passed on by experience.

Right-click the game listing in your Steam library and select Properties. In the window that pops up, select the Local Files tab and click "Browse Local Files." It is recommended that you copy this whole folder to a new location and put mods in that copy instead of the Steam one. To run such a modded install, you can either: Browse to that folder and launch from there Add the new location to the Start Menu apps Pin the new location to Start point CKAN to that directory and use CKAN as your KSP launcher (recommended) in Steam, in the File menu, "Add a non-Steam game" and point it to the new location.

Yes, the maximum fuel and oxidizer flow rates are shown in the engine descriptions, stated in units per second. The unit mass of each propellant can be worked out by comparing tank capacities and masses.

I dunno, man, Keep Talking and Nobody Explodes is in the category, too.

I've re-checked my math using a fresh pull from HyperEdit v 1.5.3 in KSP 1.2.2, and it's pulling different values for Sun surface gravity multiplier (1.746846561) than what I had previously pulled using HyperEdit 1.5.2 in KSP 1.2 (1.7462500333786). Using the newer value I get a sun GM of 1.17233E+18, which in turn gives me a year of 426 d, 0 h, 32 m, 24.6 s, which is what we want. Looks like I'll be doing a fresh pull of all the body data; I haven't re-computed the elliptic orbits yet anyway. However, it brings up another quirk - the GeeASL HyperEdit is pulling for Kerbin (the surface gravity multiplier) is 1.000341605, where you would expect it to be 1.0. If you multiply this by the (new) standard gravity of 9.80665, you get...9.81. Makes you wonder why they even bothered to change the g0 constant in the game, if they were just going to hack the gravity back to its old value. It's obvious they adjusted the M values of the planets to get the old GM values back regardless of the G value. I haven't checked to see if any of the engine performance measures have changed as a result of this (and probably won't), that's the only other place where I remember this showing up.

I've been working on an orrery for the Kerbol system and I've run into a couple of issues with regard to the length of Kerbin's year. Using values from the wiki and extracted from the game (suppposedly) using HyperEdit, I've managed to calculate this year length: Parameter Symbol Value Source Gravitational Constant G 6.67408 ∙ 10-11 m3/(kg ∙ s2) From patch notes Acceleration at Kerbin SL g0 9.80665 m/s2 From patch notes Acceleration at Sun surface (in g’s) gS,g 1.7462500333786 ∙ g0 Extracted with HyperEdit Acceleration at Sun surface (m/s2) gs 17.1248629 m/s2 gs,g ∙ g0 Radius of Sun rs 2.616 ∙ 108 m From wiki / verified in game Sun gravitational constant GMs 1.171932456926 ∙ 1018 m3/s2 gs = GMs/rs2 Kerbin SMA rk 13599840256 m Extracted with HyperEdit Kerbin orbital period Tk 9205116.471 s T = 2π√(rk3/GMs) This works out to a Kerbin year of 426 d, 0 h, 58 m, 36.471 s. And there are two problems with this value. First, I can't replicate this in-game. I placed a satellite into a 13599840256 m orbit around the Sun using the debug menu orbit editor and compared the apoapsis and periapsis of this orbit, and I get a difference of 213 d, 0h, 16 m, for an orbit of 426 d, 0 h, 32 m. You'll notice my math gives a different result by some 27 minutes, give or take a minute (.0173%). This may not seem like much, but given the precision needed for successful small-body encounters in KSP, accuracy to the game's physics is key. So one of two things is happening: either my math is wrong or the values I'm using for my calculations are. Please check my math, and if anyone knows any methods to determine these values correctly, I'm all ears. Second, you'll notice this isn't an integral number of days, no matter which one is used. So, like Earth, there should be leap years. Given my math above, the sequence would be one extra day every six years, except for the 258th year of each cycle (like how on Earth we have one extra day every four years EXCEPT for years divisible by 100 (like 1900) UNLESS it's also divisible by 400 (like 2000)). But given the year length in-game is a little more than 426 d 1/2 h, it would be one extra day every 12 years, except on the 180th year of the cycle. Or something odd like that. But I've timewarped for 15 years and saw no evidence of a leap day in any of those years. Does the game simply do 426-day years and let the "new year" point drift backward by 1/2 hour each year? Now, I do understand that the math as it is now is going to be dang close. However, objects in-game are moving faster than in my model. I'd like to be able to plot user-defined trajectories as well as the planet positions, and if the orbital motions are off by even a small amount, the data the tool gives about encounters is going to be bad information. Plus I'm a little obsessive about accuracy. Either way, I'd like to avoid this kind of error if I can. Thanks in advance for your help!

We'll need a picture of the un-coupled ship to know for sure, but it sounds like the payload-side port has been rotated 180 degrees (as in you rotated it "forward" twice to get it to point the right way) and you're using it as the control point (but the axis is in the correct direction). On the Clamp-O-Tron there is a line on one side of the face which indicates "down" in the docking port's frame of reference. If this line is on the forward side of the port (the line is closer to the cockpit), then when the "control from here" is on the docking port, the cockpit will see the control inputs as: Port pitch up -> cockpit pitch up Port yaw left -> cockpit roll left Port roll left -> cockpit yaw right Port translate up -> cockpit translate aft Port translate left -> cockpit translate left Port translate forward -> cockpit translate up If, however, the line is on the aft side of the port (further from the cockpit), then the cockpit will see: Port pitch up -> cockpit pitch down Port yaw left -> cockpit roll right Port roll left -> cockpit yaw right Port translate up -> cockpit translate forward Port translate left -> cockpit translate right Port translate forward -> cockpit translate up I've emphasized the directions that get "changed" in each case. Now, if the line is on one side or the other instead, it's even more catty-wumpus (I've done this). Does that sound like what's happening? Oh, and there is no "male" or "female" for the stock docking ports - they need to face each other and it appears you've done that correctly, at least.

The simplest thing to do is to use two Junos, one on each side of the fuselage. Just like on a real-world business jet.

Wait wait. I don't know anything much about the code, but is the problem that "all the transformations reference the same axis (and it would be a PITA to find them all and change them to reference an arbitrary cord)", or "in all the transformations, the transformation to cord 0 is implicit in the math?" Because one of those problems is way more approachable than the other. After all, we already jump around between coirdinate systems, what with SOI changes and the whole shifting-origin behavior.

I 'spect "the available light at 2014 MU69" vs "the available light at Pluto-Charon" isn't that significant. Both some variation of "not very much".

What did you set Laythe's SOI to be? If you use Laythe's default SOI radius, it overlaps all of Kerbin, and the inner SOI takes precedence.

This is why index cards were invented.

Might want to try the Minecraft forum rather than one dedicated to a whole different game. Lot of overlap in the players (as @Mjp1050's post should attest to), but since this is your first post here (rather than one about KSP), you may not get a whole lot of response. That said, welcome to the forum.

What you can do is take advantage of multiple axes assignments and different control modes. As you can see in this image, I've set left-right on my stick to apply roll while in "staging" mode, but apply yaw when in "docking" mode, and the opposite for my twist. This is backwards from what you're going to want to do because you'll want to be able to stage while in "rocket mode" and are less likely to need to do so in "plane mode" (space bar is stage in staging but switches between rotation and translation in docking mode), but this is how you'd be able to switch on the fly using only the in-game options available to everybody.

Just now getting into the spirit? I got stuck on the roof* putting up Christmas lights more than two weeks ago. Where you guys been? * as in, the wind blew the ladder down. I'm in Kansas; this sort of thing happens.

Not only is it prone to burning up - as you've discovered - but it's also light and draggy, so even if it does survive down to the lower atmosphere, it's prone to catching the thicker air and flipping your ship out, which is all kids of bad, and the recovery bonus is not worth the effort of bringing it all down. Especially since you've already safely extracted the science. So instead of having it spin you right round like a record, put it on the same side of the decoupler as the engine and the tank so you can drop it like it's hot and your capsule can land safely and easily, letting the dead weight burn, baby, burn.

"Localization" being "allowing the user to select a language for game text." What they've been talking about for the past couple of weeks has been changing the game text itself, but what they've said here is that there are a number of images and part textures that have English text in them. Since this isn't actual text data, you can't dynamically swap it out. So they're recreating the images (or parts thereof) with the appropriate words. Which sounds like a lot of work.

In terms of terrestrial power production, it absolutely is, just like most coal or natural gas plants. They're all glorified steam engines,

Thought real hard about Elite: Dangerous + Horizons, but it turned out the Frontier site had, essentially, both items plus most of the Commander Pack for the same price (on Steam it would have been an extra $20). I'm not too big into skin packs, but if it's essentially free I won't turn it down.

The PUR-1 reactor at Purdue is only 1 ft. x 1 ft. x 2 ft, but it's only the reactor core itself. It's the 8 ft. x 17 ft. pool it's in that makes it big. It also only produces 1 kW of heat, none of which is useful for power generation. You also need to keep in mind how you're generating power with it. You can't just slap a reactor core on a satellite and say "Hey, I have power!" - you need the heat to do work somehow. Terrestrial power reactors usually use steam turbines, which are pretty large and complex themselves, but they do the job very well. They're also worthless in space.

Also look in your recycle bin. Saved craft are just files, after all. Unless the file handler bypasses the trash.

There's a way to turn of Cortana and get the standard, actually-sorta-useful file search back, but you need to crack out regedit. Which, really, isn't nearly as scary as everybody seems to make it out to be. Get some instructions from a site you trust, make a copy of the registry in case you flub it, open up regedit, go to exactly where the instructions tell you, make exactly the changes suggested, and GTFO.

The only time you can enter a target's orbital plane is at the ascending or descending nodes (AN/DN) between your orbits, since those times are the only times you're already in-plane. "Set as target" on your target and these nodes will magically appear in map view. If you set up your transfer burn such that your Mun periapsis is roughly at one of the nodes, it's easy to close your orbit around the Mun with AP just inside the SOI and aligned with the node, and do the plane change at AP when large changes are cheap. Alternatively, you could combine your capture and plane change burns into one, which makes small changes very cheap. Or a combination of both. But best would be to add normal or antinormal to your transfer burn such that when you enter Mun SOI you're already in-plane with your target or close to it. The amount of normal/antinormal you have to add if you do this is a spit in the bucket compared to the transfer burn itself. Then you've done most of the hard work up front, and only have to deal with small changes to effect the rendezvous. But all of these suggestions assume you're not time-constrained by life support or contract deadlines, because it can take some time for Mun to move into a favorable position for this. If you choose a bad time and come in on a trajectory perpendicular to the target orbit, it's gonna be very, very expensive. Planning ahead is very much your friend here.

What does this have to do with the camera?

…unless you're using FAR. Then it will make an enormous difference.