Incarnation of Chaos

Gents I'm talking stock KSPs behavior in VAB, and how parts will occasionally "snap" to literally the last thing you wanted. And how moving parts certain ways can send them several dozen meters through the VAB with no way to get them back in focus. These are some of the primary reasons I always run hanger extension mods, even if I'm not making huge rockets. VR isn't going to change the snap system, just abstract it away from people. Which is fine, but my overall point basically was. "they probably should make sure KSP2s implementation of snap and construction is way less quirky before even considering VR"

Yeah I think you're spot on, so KSP2 would just have to move some of the functions out of specific actions and into a more general panel of options.

Are reference frames even a thing in the conics approximation? You can't have a reference frame for a separate body when you are deciding a specific one is basically the center of your universe at a given point. Well, that's partially lies. You have one reference frame, which is the body that you're within the SOI of. That all said, there had to be a way. Otherwise manuever nodes and interplanetary transfer wouldn't even work. So I'm kinda stumped on the details.

I really hope there's at least an option to roll your own server using a client program or SDK. That way player count would essentially be limited only by the users willingness to pay for suitable hardware, and the electricity to run it.

VR building sounds like a nightmare tbh, imagine the part you've spent the last few minutes carefully positioning suddenly snapping to a booster and clipping through the VAB along with your hand. I just don't want any development time spent on the feature currently because only 3 people will actually use it. And there's way, way more interesting and gameplay changing things they can do. Patching it in later or as DLC? That's fine. Even if I had an HMD, I'd stick with my M/K for KSP2 lel

Just make kerbal alarm clock stock....no other nodes required other than ones you've already used. No needing to know ejection angles, you just plug in the body and wait for the approach.

Don't expect that to do anything except a second display out or accelerate excel calculations. You should be planning on getting something around the RX 580 or GTX 1060 level if not a tier above. KSP has basically no graphics, the load is entirely CPU. KSP2 definitely won't require a supercomputer to run, but even a GTX 1050ti 4GB would be a world of difference for you.

Yeah so screw MacOS and let the penguins (Linux) have it. They'll probably end up finding most of the issues and fixing them for us Windows users despite never touching the OS.

Wow, nearly 70% on PC. And people wonder why they aren't prioritizing the console versions. (It's almost like they did their homework)

The developers have said on multiple occasions the accessibility is coming from better onboarding and actual tutorials. They've been very upfront with their desire to keep KSP2 grounded in the unforgiving mathematics of physics with all the challenges that imposes. Can it all be lies? Yep, but until an actual game releases I'm honestly convinced that they aren't trying to pull a bait and switch with this specifically.

It'll be out when it's out, any answer other than that is just setting up people for frustration and disappointment.

K^2 is probably more thinking that it would mean they have the mathmatical background to make KSP2s rigid body implementation far superior to KSP1. Deformable meshes per part would absolutely crush performance without very special handling ah la Doom Eternal. And they didn't have to worry about the dismembered parts being in orbit lel

Oh yeah, I'm just commenting on the level of effort on display here. Nothing more. Also it's KSP, the moment the madness ends is the moment something has truly gone wrong lel

So you have to write custom exception handling for all of these rogue patches that were abandoned just so they don't nuke MM patching, specifiing the author responsible and then determine if the specific patch even needs to be rejected? At that point I would have almost found it easier to reimplement the patches. Mad respect for you and your work.

...in SQL land that would overwrite all rows with the values given, so are you saying that MM wildcards can potentially patch every single part with potentially erroneous values?( unlike SQL MM doesn't have any type checking...)

Multimonitor breaks everything, windows doesn't clean up the virtual displays gracefully, GPU drivers break or send output to phantom displays and suck performance. I only ever use it on machines I essentially use strictly for word processing.

Switch would choke so badly on KSP with 4gb of RAM....

I'm just going to be real here, if you make the demo too limited people are just going to Torrent the full game. Now they might come around and buy it legit, but relying on the generosity of pirates is a bit of a risky business decision. Personally i think the demo (If it exists) should be as fully-featured as possible, but still leave the player at a point eventually where they need to make a decision. Start them on Kerbin, give them access to the game's systems and let them get to the Mun. Then it should basically stop progression beyond that point, that's well over 30 hours of gameplay to see and decide if you want to buy.

Yikes, and that's on top of the normal fun stuff when working with >1 thread.

I concur, while i wasn't too cynical about KSP2's potential from a performance standpoint even a year ago. Just knowing the developers are tackling issues like this head-on and squeezing every last bit of performance possible from their implementations makes me very, very happy. @Johannes Thank you so much for your time btw. I really do appreciate you (and other KSP2 developers) taking the time to answer my questions. I've been hearing about DOTS for almost 2 years at this point, but as far as how far along it is from a production/usability standpoint you'd have to ask someone far more familiar with Unity specifically than me.

SSTO design is honestly a lot of trial and error. The first issue is getting something that you can take off, go supersonic, decelerate, and land successfully. The second issue is then getting that same craft to make orbit, and then have enough DV left over to perform your desired transfer burn OR go to the mun/minmus and mine to refuel. If the result of solving the second issue is changing the design, then the first issue comes back up.... The third issue is getting this unicorn of a craft to complete reentry gracefully, and maintaining control while doing so. if the result of solving the third issue is changing the design, you loop back to 1 all over again. Meanwhile you can take whatever payloads you want, split them up, lob them into orbit and rendezvous with them and send a mothership with a mining lander wherever you want with conventional rockets. This craft can then remain in orbit after the initial mission is complete, and serve as a tour bus or w/e you need it for...while also saving a crap ton of time vs an SSTO. I'm not saying this to discourage you, just imparting that a SSTO from Kerbin to Duna is going to be a lot more involved than knowing the ratio of X engines for Y amount of tonnage.

Because developer time costs money, and once the initial milestones are completed for a task there's likely very little time between that and them moving to the next job down the tracker/list/flowchart. If they just sat around cranking out systems, KSP2 would never be complete. Giving the community the tools to do so allows the best of both worlds, without endless procrastination sinking the project. Plus just from what KSP2 has shown so far, i honestly can't see what more you'd want? KSP1 had one stock system, with a few bodies that even had atmospheres. KSP2 has binary systems, ocean worlds, the original Kerbol system.... And I'm surprised they even had that much tbh

M O D Z

Yep, and honestly most issues in KSP are from the lack of a custom implementation instead of the stock one. No engine or API would change that, and thus is why we have KSP2.

Awesome, that's what I was hoping for. One more question about this though, since you already have multiple points and are using vectors is there anything spun off to additional cores/threads? That would be a potential game changer for higher conic settings and just increase performance in general. (I feel like it would be a pain to program that though) Or is it just good enough on a single thread? Especially since you could probably use some instruction sets like SSE or AVX to accelerate.