TheOtherDave

I’m hugely in favor of this.

Yep. I haven’t played it since there’s no macOS support yet, but that’s the only thing holding me back. I haven’t seen anything that makes me worried about the quality that KSP 2 will have when it hits v1.0.

I thought that was an odd argument… I played with Lego a lot as a kid, and for obvious reasons I’d always use one longer piece instead of multiple shorter pieces whenever possible.

Oh, good! That always drove me batty.

"Developer" is a pretty broad category, though. It's not like every single developer is working on one problem, then every single developer pivots to another problem — they're almost certainly split up into teams. Are the people from one team going to drop what they're working on to help other teams? Maybe, but in a project this size you've gotta consider the on-boarding time and any other inefficiencies that might come from moving everyone around. Of course, I'm not saying it'd literally add 0 days to the schedule to do n-body, but I'm not sure the choices are binary as (my interpretation of) what you're saying makes them sound, either. Of course, even if it did literally add 0 days to the schedule, that still doesn't make it the right thing to do for the game as a whole — it'd definitely complicate the maneuver planning and that might turn off a lot of people — it's just something that I, personally, would like to see.

Thanks! That's certainly better than nothing.

I understand some of the math, and I think planets/moons being on rails is an entirely reasonable compromise. As is ships ignoring the gravity of other ships. Otherwise, I'd prefer they'd do the full n-body simulation for how each ship is affected by the planets/moons/asteroids. Or I guess at that point it'd be "the partial n-body simulation" since the vast majority of the total gravity from those n bodies would be from objects which are on rails. There's also the possibility of running planets/moons on some sort of "partial" rails, where their motion is calculated using n-body physics, but without including the spaceships (or maybe just without anything below some mass ratio, since an asteroid wouldn't meaningfully affect the orbit of a planet but it might do so to a small moon) so that their motion can be calculated asynchronously in the background, separate from the gravity part of the "main" physics engine. I mean, on the scale of a planet vs even a large spaceship, the ship is, at most, a rounding error. Such an approach would probably require the devs/modders to run some calculations on solar systems before publishing them to ensure they'll have the desired stability on the timescale a game is likely to encompass (emphasis on the word "desired", since unstable systems could make for some interesting "maintain the resource networks after everything falls apart" late-game challenges), but that doesn't seem like the end of the world to me. I'm not sure where asteroids would fit in... Compared to the mass of spaceships and on the timescales of a fly-by, they're huge, but it's clearly not the same thing as the mass of a planet vs the mass of a spaceship. However, on longer timescales the gravitational influence of the spaceship on the asteroid can really add up (to the degree that, AFAIK, a "gravity tug" is considered to be a plausible way to get asteroids off a collision course with Earth). Plus, given the success of the DART mission, it's pretty clear that "player-sized objects" can affect the trajectory of an asteroid even on short timescales when impacts are involved. So you can't really just ignore the interaction between asteroids and spaceships, either, but maybe you can if there's not some minimum distance between them? I'm not sure.

I hope that's the case! I also hope there's an easy mode for people who aren't me and wouldn't find that level of detail interesting or fun.

I looked around and didn’t see one… apologies if I’ve just gone blind. Anyway, it seems like it could be helpful if there was a place to go check if whatever problem you’re having is a known bug or whatever feature you’re requesting is already on their todo list.

Why would they do it if it’s not necessary?

Well you keep talking about space shuttles, so I'd guess you're hinting at the RS-25, but otherwise I have no idea... they're all just bell nozzles (or aerospikes) to me. Do you really expect players to be able to recognize any engine on sight? I think we'll be lucky if most first-time players already know whether the nozzle is supposed to point up or down. I'm not aware of any IRL engines named anything like "Vector". It certainly doesn't resemble "RS-25". The IRL space shuttle engines? Well, AFAIK SpaceX is the first to use methalox, so it's not that... <shrug> "liquid fuel"? It's not like there won't be a Realism Overhaul mod... I'd If the devs' research says it's more important to sacrifice of all things fuel variety for the sake of making the core game fun enough to attract a large player base, don't understand why it's so important to dissuade them.

I'm not sure I am going to get it, at least not until there's official macOS or Linux support. But if/when I do, it'll almost certainly be on Steam.

It would've been a lot more defensible if she'd claimed we smelled like garlic, but no, "you ARE garlic!!!" How do you tell which fuel an engine burns just from looking at it?

There's a difference between "listening to" and "agreeing with". Like, I listened when my niece repeatedly and emphatically declared myself and her grandmother to be "garlic", but seeing as how I and my mom are both, in fact, human, I didn't agree with my niece's assertion.

Interesting idea! WRT placing the planets in stable orbits, the problem is that we don't really have a way to know if a system is stable indefinitely. Like, IIRC, we can calculate that (absent a fly-by or something by some other star or planet) our solar system will be pretty stable for the next few million years or so, but at some point the math gets too chaotic to really know for sure. AFAIK, all we can really do is place planets where we've seen them IRL (either in our solar system or others) and run the clock forward for a while to ensure nothing goes crazy too quickly. To be clear, I'm not expecting KSP 2 games to last millions of years — it's just that life probably needs relatively stable solar systems to get going, so you don't want to start in a system that wouldn't have lasted more than a few thousand years since the kerbals have ostensibly been evolving and living there for millions of years. WRT how numerous and how heavy the planets should be, I don't know. WRT how to determine whether a planet should have an atmosphere and such, I don't know, but I'm pretty sure that's something which could be googled. Also, the "frost line" is probably worth looking up. WRT generating the planets themselves, back in the late 90s and early 00s there was a website called something like "the super fun and bouncy and stretchy site" which had a ton of algorithms. IIRC, the algorithm it had for generating planets was roughly: Start with a sphere Pick a random plane that intersects the sphere (it's fine if it happens to go through the center, but don't make them all do that or your planet will be entirely too symmetric) Shift the part of the sphere on one side of the plane in a random direction by a random amount (subject to reasonable constraints) Repeat steps 2-3 probably somewhere between 1k-100k times (IIRC, the more iterations you have, the less it matters what the "reasonable constraints" are in step 3) I don't remember if you can start with shapes other than a sphere for moons or asteroids too small to pull themselves into a sphere, but IIRC it makes pretty nice "raw" planets. It doesn't account for weathering or cratering, nor do I know any algorithms for figuring that out, other than to say they'll both at least partially depend on the planet's atmosphere and age. Also, keep in mind that if there's going to be an ocean or "long-term lake", the surface below sea (or lake) level will weather differently than the areas above sea (or lake) level. I'd imagine you could maybe drop it into existing weather prediction software to do some statistical modeling WRT where rain would normally fall, then use that to inform where you model rivers cutting into the surface and such, but I've never tried it so I don't know. It might also help you determine where things like rainforests or desserts would naturally form, too, but it's not an area I have any expertise in... I just vaguely remember that algorithm. Of course, it only accounts for "height maps", not different soil compositions and such. Also, I have no clue how to know what a "realistic" resource distribution would be, nor how to balance that against what's needed to make the game fun.

It's not being released tomorrow; it's going into early access tomorrow. The version shown at the ESA event was 0.1.something... v1 is still a long way off, and I don't see the point of being "disappointed" by anything yet. Other than the timeline, I suppose

I met him once, at a talk/KSP event he was doing at the Chabot Space & Science Center. AFAICT, your impression of him is accurate. He was a great and gracious event host, too. This was back when the Lego Saturn V had just come out, and he let me look through his instruction book to see how it was constructed internally (I'm pretty sure I was the only person more interested in that than in seeing the completed model ).

I don't think we were necessarily using a lot of AVX instructions, but I never saw the internals of the code. I remember my boss wanting to use Intel's compilers for better auto-vectorization, though, so maybe it was something they were in the process of switching to?

Yeah, but only because KSP 1 uses watered-down jello to hold things together. Struts were/are about the only way to make joints useful... autostruts just make that process easier.

"Hideous" is quite an exaggeration, IMHO. It's probably not the font I'd choose, but I don't know what the other options are or what drove the decision to use a font without descenders, so I'm not inclined to criticize them much for it. I'm sure there'll be a plugin to change fonts, anyway.

Yeah, if procedural tanks will reduce the parts count (and they will), they I say bring them on. I’m less sold on procedural engines, other than to say that having the mechanism in place would probably make things easier for modders who are trying to add different sizes.

You could build similar shapes out wings in KSP 1, so you'd know the same way you knew there.

Putting the "CoM behind CoL" is how air works. There's nothing to re-learn in that regard.

I’m mostly excited for multiplayer and colonies. Although procedural parts without a plugin sounds pretty great, too.

Why not? It’s just a data transmitter. These days everything’s the size of a chip… you could control the ISS from your cellphone if NASA exposed the commands.