Kerbart

I think it’s generalization, but it also is an essential part of the game. While we try to avoid them, seeing things go “boom” is way more satisfying than some cracks drawn across the screen “windshield”) or your vehicle just stopping dead on the surface without significant damage.

I am. I’m pretty certain @Gargamel meant “if they can figure out multiplayer, the complexities of special relativity are trivial”

The burn time is very long because the listed thrust is (very close to) zero. Fuel is not the issue as the tools are listing the dV, so it has to be something else. If the engine burn full thrust during ascent then there’s something causing the wrong readout but that is the direction you need to look at. The problem is not the long burn time; that’s just a consequence of the root problem, the low thrust readout. By the way, what exactly is the Near Future: Reduce Thrust Settings Config mod doing? Just curious given the issue you seem to have.

Not handling bugs is for wimps. I bet they use time acceleration as well! And electronic calculators, instead of slide rulers!

You mean 1.11.1? Because 1.10.1 still has a “0” in the name. So will 1.10.94

I highly agree with this. I'm going to assume the OP is not very experienced in C# programming, or programming in the first place, given the nature of the questions asked. That's a loaded question. Not because the answer is difficult; C# in KSP mods is not any different than regular C#. But because what you're not asking: if I learn regular C# can I create mods in KSP? Consider this question: Is regular French any different than the French the fans of Paris Saint-Germain speak? Well, no, but do you know anything about the club? It's history? How they've been doing recently? Soccer in general? Oooh, so I should read up on the club instead? No, no, no... you will need to learn French, and in addition, you'll need to learn about the club. It's the same with creating mods. You'll have to learn about C#. And you'll have to learn how C# interacts with KSP. There's documentation and youtube videos for that (I assume) but all of that is going to be pretty meaningless if you don't understand C#. Keep in mind that programming by copy & pasting fragments you find online is like building a car from scratch based on youtube vidoes about car repair. The videos might show a lot but they don't show what they're not showing, and if you don't realize what they're not showing either you'll never get that car built.

I think the OP means the 12,000,000 reward...

The problem with KSP's control model is that effectively you control RPM, not throttle. In most internal combustion airplanes you'll have (sets of) three levers; from left to right: throttle, pitch, mixture. Throttle is just that - how much fuel is going to the engine. Add more fuel, and the engine will work harder. Cut back on fuel, on the engine will work less hard. Pitch we discussed - it's the "gear" of your propeller. High pitch gets you high velocity, but also high resistance. Low pitch gives you low velocity. Throttle up at low pitch, and the engine's RPM will increase until the resistance of the air beating the propeller matches the engine's power. To make the "game" more difficult, usually your engine will proved more power at high RPM's, but that also heats up the engine a lot. So when you're done climbing to a desired altitude you usually can cut down on RPM (less power needed) but increase the pitch to maintain velocity. Finally as most small ("general aviation") airplanes are self-balancing, the controls work reverse of what you'd expect. Increase throttle will indeed increase speed at first, but that will result in more lift and the plane starts to climb, losing speed again. In a similar fashion, pulling the stick will pull the nose up, increases lift, plane climbs, loses speed. Increase throttle and your plane will usually "settle" for the same velocity but with a higher rate of climb; pull the stick and your plane tends to stick to the same rate of climb but with a lower velocity. Flying with full throttle controls in MS Flight Simulator or X-Plane (or in a real aircraft) is a fun exercise that comes fairly natural after a little while but it's very different from how you control planes in KSP.

Actually most propeller planes, especially the larger ones, do have variable pitch. You can also change the RPM of the engine, that's how drones do it. Throttle usually is power while you can think of pitch as the gear you're in. While cruising you want a "high gear" but you don't want to rev the engine, just like you'd do on a bike (compared to, say, climbing)

Have you written anything in C# (“C-Sharp,” hence the CS extension) before? You probably want to start with that first.

That would be a C# source file — it’s unlikely the compiler creates that. Perhaps one was missing, and VS creates it for you?

A fan makes hardly any noise and I prefer it where possible. My office is in a cool spot of the house and I rarely need an AC there. Other rooms in the house practically require an AC.

You can use The Claw

Doing endurance training on my scooter board, going 20 mph (which is quite the decent speed on a scooter board) and catching a big fly in the back of your dried out throat. At that point no choice but to swallow it. Happened on multiple occasions. Good times.

Well, there's KRPC - it's not Kerboscript but you can retrieve data from your vessels and control them with a Python script - no reason why it wouldn't work inside Jupyter Notebooks.

Ok, I am stupid. EVA struts are not visible when I try to attach them in 1.10. The strut "blocks" are there but when you try to attach them to something the struts themselves are not visible. I know I had the same problem in 1.9, and there was an easy fix for that. I have no clue what that fix was, and I can't find it. Help!

Funny that you mention that; having an unrestricted view is the reason I play with the navball moved as much to the left as possile I'm not too worried about the digital clock as it looks right now. Yes, it's hard to read - but I'm pretty sure QA will flag this as a concern and have it fixed.

Maybe, but it's interesting to see that Microsoft announced they "went too far" and is bringing back colored icons for its apps in windows (calculator, video editor, settings,, etc). The wind that's been blowing through Design for the last fifty years has indeed been one of simplicity, but I don't think it's "fashion" that leads to ever simpler designs, but rather pushing the envelope of what's possible. Consider the humble button in a GUI interface. Early on they had to be three dimensional to entice users to "push" them, something everyone used to text-driven menu systems had to be taught. But a 3D effect is expensive in terms of screen real estate, so as soon as that could be dropped we went to flat buttons, buttons without a visible outline, etc, etc. It's not a mere fixation on simpler for the sake of simpler; the more you leave out, the more is available for what is left. In one the more recent updates, Microsoft Office went through a round of simplification of its toolbar ("ribbon") icons. Subtle enough that most users can't even figure out the difference - only that it is different - but leaving more room for accents and highlighting on an icon what is important. Apple didn't drop "glossy" icons out of fashion considerations; flat icons need less pixels to show the same image, and allow you to fit more on a screen - or make the existing ones easier to read. But why were they glossy in the first place? To look like "real" buttons, because users had to overcome their unfamiliarity with touch screens. Now we don't know any better and the effect is no longer needed. The same goes for limited use of colors. It's not just fashion; it also means that when you do use color, it really stands out. A red traffic light (or green) will stand out less in a sea of color than in a mostly black/white environment. There's an interesting balance between providing hints in your design for what is needed, and what the end user already knows (consider red=warm, blue=cold on faucets). That balance shifts all the time, and sometimes not as fast or in a way that's anticipated, which why not every design change sticks. It's "fashion" in the sense that there are trends visible over time, and everyone follows the same trend. But it's not "fashion" in that it's leading the way in interface design, but rather the other way around; big players adapt interface improvements over time, and those changes then become fashionable.

Let me tell you a little story. A long, long time ago, when I was only a young Kerbart and had aspirations, I went to college to become an engineer. At one of my internships I worked at a factory for kitchen countertops and medical furniture (side tables, etc). At one point we had to work on a new small table that, attached to a stand, could be put next to a nurse or doctor to put their gear on while working on a patient lying in bed. I was excited, because here I saw real design in action. Surely, my boss would whip out some tome of medical standards that described how far off the ground said table surface needs to be. What followed was an eye opening disappointment in How Things Are Made. "Kerbart, come over here. Pretend you just inspected someone's ear with one of those scope things and now you want to lay it on our table... STOP RIGHT THERE!!!" As my hand was about to lay the pretend ear-scope on the pretend-table surface, my boss whipped out a tape measure and measured from the ground to my hand what the required distance was. That's your medical standard for table height right there... On another occasion we made small serving trays as a Christmas gift for customers. I brought one home and my father was delighted to learn how we defined the intricate not-quite-an-ellipse-not-quite-an-oval shape. He'd love to learn from his future engineer son what the math was that was involved in such curves. "We traced a tupperware container" was my sheepish answer. Moral of the story: don't always look for grand explanations of why things are the way they are. Sometimes the underlying reasons are shockingly ordinary.

You're asking the wrong question. Should we land Gilly on the craft?

To be fair, I don't think "I don't see a reason..." is generally interpreted as "I will never change my viewpoint." but rather as "you'd have to come up with something really compelling that we haven't seen yet" Mun is pretty old. I don't mean "billions and billions of years," I mean in the lifetime of the game, and introduced at a point where pretty much anything was added in an experimental way. The theory of the "burn meridian" is a charming theory. One might even argue it has merit. There's one very serious issue with it. Back when Mun was introduced, how would you know you're crossing the 0° meridian? Especially when it's no secret that Harvester's take on the game was always "fly by the seat of your pants, not by the numbers" - unless there's some recognizable terrain feature at 0° I just don't buy it. I agree with 5th Horseman here; Occam's razor applies. They applied a texture map to Mun. Someone said "that looks stupid, why don't we rotate so we have those features facing Kerbin?" and the decision was made to implement that by rotating the moon.

No, it's not. Spyware raises certain expectations on what the software (allegedly) was doing, and KSP was doing none of that. It is true that it was bundled with certain telemetry software, but calling KSP "spyware" for that reason would be akin to calling someone who received a speeding ticket a "recidivist career felon." So, no.

KSP1 was sold as an incomplete product at an incomplete price. KSP2 is sold as a premium product - so yes, I do expect a wider selection of parts including robotics. It's not a show stopper for me but I'd be disappointed if those kind of parts were not included.

That's not completely fair to the people who came up and implemented it in the first place. It would be good to note that the original game had nothing in place to provide any goals; it was sandbox and nothing else. Then Science came along and someone (I forgot who) came up with a mod that provided contracts; that system was later integrated in the game. Let me repeat that: there was nothing. NOTHING in the game to provide any story/action/adventure/gameplay. Let me show you how much there was: ... That's right. Nothing. To claim that this is all due to someone who had no clue what they were doing is injustice to those who, in the early days of the game, set out to create something out of nothing and had to scale The Wall Of Interesting Play will little more than two elastic bands and a handful of thumb tags. Stating that the contract system was build on very little concrete foundations in the game resulting in where we are now would be a more fair representation and a bit more kinder to those who spent a good amount of their time and talent early on in the game to turn it into something more interesting.

A couple of things to keep in mind: Do you click on "control from here" on the docking port on your ship you're docking with? DPAI will give you readouts based on your control point, which can appear unexpected/erratic/glitchy results if the measurements are taken from the pod and not the docking port (the port might be too far to the left, but your pod is to the right, etc. Also: orientation) When I started out I'd use docking mode exclusively, because, well, that's what it's for, right? I've since learned that docking in regular mode is much easier (AWSD for orientation, IJKL for translation) - that might reduce some of the docking panic. Keep practicing. Docking used to be a white-knuckle experience for me. Now it's as much routine as a lift off. You'll get there!