TheOtherDave

I’d guess it has something to do with data marshaling and getting things preloaded into cache. There was a company I used to work for that had an entire thread dedicated to just walks trees/arrays and loading pointers to keep data in cache before the main loops (yes, plural… there were a lot of threads) started processing things. I don’t recall the details, but it was absolutely essential to get performance where they needed it. (I kept meaning to ask our contacts at Intel why they didn’t add cache management instructions so that we wouldn’t have to play games with the CPU to get it to guess correctly, but never got around to it.)

And I’m still slightly annoyed with MS for delaying the Mac version for a couple years after they bought Bungie. (Yes, I know they bought Bungie so they could have an Xbox exclusive… exclusives annoy me, too.)

If it’s not just going to be an “official” reimplementation of kRPC, I vote for Python since it already has so many scientific libraries.

+1 on the mach numbers… they’re often more important than airspeed for determining maximum safe speed and how an airplane handles (especially in the transonic areas). Being able to walk around inside the bases and stations sounds like a really cool idea. I’m not sure how it’d affect the gameplay, but sounds great.

Modern remote control hardware doesn’t really vary in size when you add more things it can control. Or rather, it probably does, but we’re talking about millimeters — extra pins on a computer chip — not anything that’d make a difference on meter-wide parts. It probably mattered quite a bit for early remote control tech, though. Maybe more capabilities could trickle down the sizes as more research is put into miniaturization?

Maybe we need a “boat assembly building” that’s next to the docks?

I disagree, but more in terms of approach than in result. I think players should have to remove the hatch in question in order to place another part that’d block it. If there aren’t any hatches left, that can trigger an error message about there not being a way to Kerbals on/off the vessel.

I figured those were for SpaceX-style “return to launch site” boosters. Helicopters would be cool, too, though. I guess I’ll have to get a new joystick with something to function as a collective. The surface shape looks nice, but the way the surface textures are mapped over that surface shape makes it seem like someone is vigorously shaking a giant bowl of loose jello.

I suspect I’ll agree that reaction wheels should be nerfed compared to KSP 1, but I don’t think we really know enough to say whether they’ve got it right at the moment.

Well, it is next to the ocean…

Yeah, either a toggle or some at least semi-realistic logic for when they’re generated would be great. I’m already imagining virtual sheets of contrails coming off of airplanes with lots of wing segments (because I didn’t see a way to have multiple shorter ailerons per wing so there’ll still be a reason to have several segments per wing). Edit: They do look cool, just a bit overdone is all.

Early access would totally be for me, if only it had macOS support.

Hah! Now that you say it, I wouldn’t be surprised. I’m not even that good, but I know I’ve been playing long enough to forget what it’s like to not know the basics.

Oh, sorry, I didn’t mean to come off as really arguing about anything… My post was only meant to be interpreted in the “well, if we’re going to do this anyway, here’s my thoughts on who might be a good fit for it” sense. I wasn’t really intending to express an opinion on whether the VOs should be redone in the first place. My apologies for not making that clear.

Given the subject matter, I think Scott Manley would do better than NDT. As long as we’re fan casting the VOs, though, Tim Dodd would probably be my first choice. IMHO, he gets the tone perfect in his documentary-style videos, and that’s mostly what this is about.

Disagree… for me the wobbly rockets/airplanes were pure frustration.

I’m pretty sure that’s more a CPU thing than GPU.

If a rocket (or space station) is noticeably bending, it’s probably already cracked and a complete failure is at most seconds away. At least for stuff early in the tech tree. The composite wings on some newer airplanes can bend an absolutely shocking amount without being damaged, but they’re made from really advanced stuff that wasn’t available until relatively recently.

“Meets the minimum specs, but is a Mac and I’m not sure I have room for Windows, Steam, and KSP 2”

When they add macOS support. I'm planning on building a linux box at some point though, so maybe if it runs on that.

"\" instead of "/" implies the spaceships are running Windows, which seems like a bad idea. Unless, of course, they're gonna add a failure mode where the spaceship reboots itself for an autoupdate during a landing burn or something.

There are downsides to every CPU arch. In the case of x86, "high power consumption" and "a lot of hardware baggage so that email software from the 1980s can still run" come to mind. To keep making improvements, at some point you have to drop hardware backwards compatibility and do it in software (or not at all, if there isn't enough demand for it or you're making a new platform or whatever). Did Apple make the right decision both in switching to their custom ARM implementation and in doing it when they did? Dunno, IMHO it's still too early to tell. These things can take a long time to play out, and Apple's barely into their 3rd year. I think between ARM and RISC-V, though, we're at least entering an era where x86 doesn't have complete dominance and won't necessarily be the default choice. Everyone's rushing to find out what they can make hardware do if it doesn't work the x86 way, and the results are interesting. It certainly hasn't been the ARM/RISC-V/POWER blow-out that everyone who isn't Intel was hoping for, but there are definitely some wins to be had (especially for a company like Apple who's now in a position to customize their CPU for how their software works). Does switching arches leave some old software behind? Probably. Really fast emulators such as Apple's Rosetta 2 can do amazing things (and I hear MS's emulator for Windows on ARM has gotten a lot faster, too), but there'll likely always be some piece of software that doesn't quite work right. However, if you've come to the conclusion that x86 isn't the best arch for you anymore, there's not really a way to avoid the situation. Well, I suppose except maybe only using open-source software, but there's several asterisks and a few whole other conversations involved in that "solution". As far as games being compatible with the ARM CPUs Apple's using is concerned, if the developers write their software against Apple's current APIs and are using Apple's current tooling (and they didn't use any assembly code or anything), adding ARM support is mostly just clicking a checkbox in the Xcode project settings and making sure everything still works right. Now, optimizations made to the data structures and algorithms and such that were made for x86 might not work as well (or at all) on ARM systems, but that checkbox will likely be enough to get it running. If the game is written against some other API like Unity or Unreal Engine or something , the developers will have to wait for that vendor to add support and that can take a while or already be done. AFAIK, not only does Unity run fine in Apple's x86 emulator, but they've offered native ARM support for I think about a year. Whether either version of KSP has been updated to use one of those newer versions of Unity to get native ARM support is another matter.

Does anyone know where the proto file defines all the data structures? I'm trying to create a client for Swift and all I'm getting out protoc is some request and response types that don't have anything to do with "space center" or "active vessel" or any of the other stuff that's in the example code.

I could see an argument for having an “officially recognized” realism overhaul/realistic progression plugin, and I can even see an argument for that being a 1st party thing, but the vanilla game needs to be fun and have as wide an appeal as they can get without losing sight of the core vision, and this compromise seems reasonable to me.

Oh, I hadn’t thought of seaplane parts! Yeah, that’d be cool! “The Spruce Ultra Mega Goose”, here we gooo!