Kerbart

Why, practice, practice, practice!

The rocket equation, how it’s derived and how it marches up to what you do. Combine it with the vis-viva equations and you can show how much propellant is needed to go from one circular orbit to another.

The secret to easy docking is scribbled on the walls of the bathrooms in Carnegie Hall. If you don’t know how to get to Carnegie Hall, just ask.

As you mentioned, people get frightened. The number of players on this forum who got better at math, by the simple act of being forced to use it, is likely stunningly large. But show them one line of Algebra and they turn away in disgust (or used to, in the past...) It’s the same with automation. For experienced coders, one line of code is clear, simple, trivial. For the uninitiated it’s frightening and close to Greek, but if they see a diagram they can easily decipher it. I don’t think recording macros is the solution. As soon as you want your recording to handle different scenarios making a generic recording (more so in Excel than in Lotus-123, ironically) becomes difficult. But a diagram-based VPL that translates to a script? That sounds good to me. Simple automation can be done graphically, and the graphic “language” doesn’t have to be overly complicated, because the underlying script language is meant for that.The macro language in MS Access works like that; non-programmers can automate simple actions with it, and if it needs fine-tuning they cN be translated to VBA and customized in a much more precise manner. If I’m nit mistaken, Kerboscript emerged from the initial KOS terminal, with (again) a simple need to automate things, and was on purpose a bit klunky in the syntax to give it that Kerbal feeling. I never warmed up to it for that reason. But a real scripting engine, working out of the box? I don’t care if it’s Lua, Ruby or even Javascript, those language can be learned. It would enhance the game in ways hardly imaginable. And add a VPL shell to give everyone that experience.

And I think that the wisest words my late father spoke were “Nothing is impossible for the man who doesn’t have to do it himself.” I’ve seen similar “easiest problem to solve” claims before and they turned out to be not as trivial as claimed. Given the specs of various parts going up and down over the different releases I don’t think the exercise is that easy.

That hinges on a couple of assumptions that do not necessarily hold up: Gameplay is more fun when it is more challenging. Not everyone agrees with that, and this certainly would fall in the “more realism for the sake of more realism” reasoning. More realistic isn’t always better. A smaller system with smaller planets means faster to/from orbit times for instance. I don’t need my launch-to-orbit times to double, and I’m sure I’m not the only ones Advanced players need a more challenging environment. A real sized solar system addresses the need for realism Given the need to rebalance the entire portfolio of parts (which certainly will be larger than it is in version 1), will the investment required be worth “enticing” the existing player base? If it increases sales by 5% but drives development cost up with 10% the proposal is less of a no-brainer. So, I think the real request should be: “make it easy to mod the universe without the need for something like Kopernicus” I have nothing against Kopernicus, what I mean is that not needing a mod to change the planets will surely improve reliability (if only because there’s less mods to clash with each other)

You’ll get a lot of “I program in X, pick X” answers. I’m not sure if that will help you. My feeling is that if you have no experience with programming at all, starting with Python will pretty much reduce your challenge to one problem—learning to program. Python is pretty easy to pick up. If you do have experience in programming (you mention Turbo Pascal at college), then you might jump into C/C++ if you want. Expect a lot more struggles but also deeper insight in how a computer works. It never hurts to get confronted with the finer nuances of memory allocation and pointer arithmetic, even if you won’t touch that for the rest of your life; just like it pays to know how a combustion engine or a gearbox works, even if you’re not a mechanic. Either way works, and the second language is always easier to learn than the first one, because you only have the language to learn. Do keep in mind that different languages have different paradigms you will need to master too; writing C++ as if it’s Python will fail equally as miserable as writing Python as if it’s C++. It’s like writing a TV show for different languages; grammar and vocabulary are not enough, you also have to consider cultural differences. In the end, as @Cydonian Monkmentioned, the only way you learn to code is by coding. Consider the answer to the question “I’m going to work as an expat for two years. Should I learn Spanish or Chinese?” Most likely it’s “well, where are you going?”

RELEASE THE KRAKEN!!

Mount some solar panels on a hinge. Extend the hinge, extend the panels, enjoy the kraken party

Shipping is mostly done with containers these days, which are funnily enough measured in foot and inches. But there is serious pain with refrigerated containers, which get shipped internationally and thus have their set points in Celsius, Something shipping companies keep emphasizing to their customers, who keep insisting shipping their meat at a balmy 15° because, well, that’s frozen in Fahrenheit.

For docking? We're talking about docking ports 10m removed from each other. This is not where "I have to burn away from the target, to get a lower orbit, to get closer" applies. That's how I read the question, at least. I've docked hundreds of times and I never take orbital mechanics into account at close quarters. Never.

Within reason, yes, you can treat docking as if you're not orbiting. Orbital mechanics aren't even an issue for the least 5 km—what most of us will refer to as rendez-vous; it's only a factor when you're trying to match orbits and positions. Generally speaking* when map view is helpful, orbital mechanics matter, if it makes more sense to navigate by camera or navball, it doesn't. * Rule of thumb. I'm sure there will be dozens of exceptions pointed out to me.

We’ve been hunting the Sasquatch and they have become so good at avoiding us, that there are even people who think they don’t exist.

What are you suggesting... (JK)

Why would you development of the game after the initial 2.0 release to stop? Wouldn’t it be more fun if it were continuously developed, just like we’re now at 1.8?

And that is just what a Star Theory developer would post... I don't blame you. It's more the forum in general. If Squad rolls out an update that focuses mainly on fixing bugs, there's complaining that it's an update with "no content." When there is content, it's "fix bugs instead." I feel that they just can't win! I suspect it will be the same with Star Theory. They could post more, though. Even if it's just one part every week, they'd have enough content to keep us excited.

Star Theory works instead of posting updates: Y U NOT POSTING UPDATES Star Theory post updates: Y U NOT WORKING

I don’t want to come over as argumentative, but I think that providing a few samples would bolster confidence in your statement. I haven’t seen any compelling argument that KSP’s perceived lack of performance is, in fact, due to Unity, and not due to inefficient code. I can write exceptionally bad performing C++ code that uses, say, the Unreal engine, to “proof” that C++ and Unreal are exceptionally slow but that doesn’t proof anything. Looking at the development history of KSP it’s a lot more tempting to put the money on “not utilizing Unity the right way” than on “LoLz iT sUcKs BrO” as the reason it’s not as fast as we want it to be.

Read Jared Diamond’s Guns, Germs and Steel. The thought that “smartness” had anything to do with it borders neo-colonialism and misplaced supremacy. The reality is that Columbus was raised in an environment that, mostly by chance, give him various advantages, probably the most important one being carrying a large amount of bacteria that the natives had no proper immune response for.

The slash (/) key will stop time-warp at once. No need to tap keys multiple times.

In addition, the vote-icon on the left is intended to “up-vote” the most-helpful answer, as you mentioned and not as the “like” button on the right. It seems that the two are being confused.

To paraphrase John Clark: the Flea has one good property, albeit a truly magnificent one: it is available.. I don’t think there’s anything wrong with early game engines you only pick because there’s nothing else. It’s the very definition of progress. NASA does not use the original engines that were used on the first Atlas rockets either. But if they were that bad then why did we use them in the first place? We know the answer to that; the same reason we use the Flea; until something better comes along.

The current game rewards certain traits in players, and that is what makes it appealing to them. The game throws up challenges, and rewards planning and foresight. Plundering wreckages and buying parts at outposts undermines that element. I can see how encountering a chance wreck could advance scientific research, but that’s as far as I think it should go.

Money, money, money... that would require extra developers. It makes more sense to use the developers who are already familiar with the product, once there is downtime in the PC development cycle. Developers are a limited resource pool, you can’t just do everything at once and stay in business.

Things that are expected from KSP2: better performance better graphics less bugs Without anything else I’m pretty sure 90% of the forum longtimers would already consider that a worthy version 2. Sure, voxels sound and look great, but where in the above would it fit in? What would be so compelling aboutit that it’s worth sacrificing the above attributes? How to convey the devs? Give them good reasons that are hard to argue with. Hint: “it would be great” is not a good argument. It lacks depth and insights.