pincushionman

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.

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.

Two questions: What sort of game are you interested in modding, and what games do you already have/play? And more importantly, what kind of mod do you want to make? These should inform your decision as much as the ease of modding.

This not enough? Like, you need antennas on both ends?

Didn't there use to be an "awesome" value in settings.config that controlled that?

Quick question. When I start a fresh save, then open the Planet Editor, are the values shown the ones pulled from the game itself or are they from a list HyperEdit keeps on its own? I'm trying to make sure I'm getting the most accurate information I can get for an Excel tool. The math I've done with it checks out - if it's not the actual game data it's pretty dang close. Just wanted to verify. Thanks!

Agree with the statement about buttons beyond 19; can't comment. I was replying about the comment about "Unity doesn't understand hats or POV," which is why I cut down the quote to only that portion. I just wanted the OP and other readers not to get the wrong impression and assume that hat switches don't work at all. They might, or might not, and it's gonna depend on what exactly the hat maps as - and what exactly you're trying to map it to. You of course know your controller much better than I do And KSP may indeed drop an egg on it. But I know I went for some time assuming that my controller's hat "buttons" weren't working at all, until I found out quite by accident that this wasn't the case, KSP just saw that control differently than I had assumed. And that other Unity games were much more flexible about how that same hat could be mapped. Many apologies for the confusion.

I'm sorry, I misunderstood when I read the OP as "why are they ediding old crappy collider meshes when they could be making fresh ones that work instead", and was quite confused why anyone would assume that's what they're doing. But it's not what you're talking about. Now it makes sense.

Not entirely true. I can't comment on the behavior of sticks that signal hat switches as a set of individual button presses (since mine does not, though 8-way hats might have to), but your hat might instead be an additional set of digital axes. That's how my Microsoft Precision 2 maps in KSP, and that's consistent with how the Windows joystick calobration/test utility views it. But it's also a KSP issue, not a Unity one, if it can't do what you want - I play Sky Rogue, another Unity game, and it has no trouble mapping my hat to discrete behaviors.

What makes you assume that "fix these colliders" doesn't include replacing them with one that works a lot better?

I've got to second what others have said: find a project first that interests you. This will dictate the tool (language) you need to learn. You will learn what you need to solve the problem, but if you don't have a problem to solve you'll get bored and quit. For instance, I've had training in F77 and C, and tried to learn C++. But I never really use it. Why not? Because I have no reason to, and thus no motivation.. But I do use Excel for engineering at work, so I can write VBA all day without breaking a sweat, even though I've had no formal - or really even informal - training. If you don't have a project for yourself, look to the FOSS community. There are thousands of program projects out there from simple text games to commercial-quality media editors to the very programs that run the backbone of the Internet. And they all have bugs. Lots of bugs. Many of which would be beyond a beginner's ability to fix. But not all. Some of it is just annoying little misbehaviors that just need someone to go and fix. Not very glorious, but you get to see a lot if code that [mostly] works so you can begin to understand programs that actually do something. Also, as Edison said, "success is one percent inspiration and 99 percent perspiration," and that's true in coding as well. Be willing to be the perspiration guy, and not only will you learn a lot, people will notice, too.

You'll need a bridge to add enough height so the body doesn't interfere with access to the string on the right side. And that would introduce separation between the string and the…fretboard, in this case (making it harder to push the strings down), so you'd need to bend the neck down to alleviate that. And that would put predsure in the middle of the top, which might crack it. The curved saddle would help with bow access to the middle strings, but they'll also be further from the fretboard than the outside strings. And if it's a guitar (is it actually a toy guitar, or is it a ukulele?) that means there are four "middle" strings to deal with.