Incarnation of Chaos

Have actually coded quite a bit myself, it's one of the reasons I'm not confident they'll improve performance significantly. The performance we're seeing almost looks like a debugger is hooked up (can't be the case because it's a retail exe, but that's the example that comes to mind) We were promised no early access and a full game on release, and we got early access and only sandbox mode that's a 20 FPS slideshow that needs more hardware than games that look 10x better to do it. I do understand that milliseconds and cycles matter, even a loop that's running a few ms slow can add up to massive performance issues depending on how often it's being called. The fact that the physics is still causing lag is also a pretty grave concern for me, because either they don't have their physics LOD enabled or weren't able to get it working. That's a low-level, tightly integrated system that likely cannot just be "patched in" due to the dependencies of parts/colliders/meshes etc. So if that's not working, one of the biggest things that KSP2 was going to do to optimize just went straight out the window. And if they have all this performance still on the table like everyone seems to be thinking, why ship? Game was already delayed three years, I seriously can't fathom 2K coming down and being like "yeah bruh you gotta send it now" after 3 years of delays lol None of it makes sense, and none of it bodes well for the future of the game. But all I see is people who want to believe it'll all work out without any hard evidence, praise and ignoring the fact that this is another broken promise on top of the pile. That's the crux of the issue, the hardware requirements are a symptom of a much larger issue than just "muh fps". Could they prove me wrong in time? Maybe, but they're certainly on a losing streak as of late.

My post said explicitly I wasn't planning on buying it, so not sure why you mentioned that. Second you're absolutely right that in most cases you can't reliably extrapolate past experiences from different companies to each other. Game performance though, that's a different one. In the best case it remains the same from launch to final version, in most cases it regresses as more features are added on in each following version. Is it possible that they completely botched their multithreading implementation and the performance would improve once resolved? Sure! Could they have completely flubbed the setup of their render pipeline? 100% But all of these are issues that don't need a slew of paid beta testers for them to see or resolve, they'd know already.

How many times have I heard that same thing? Performance will improve with time. You know how many times I've seen that actually occur? Maybe once, twice in my entire gaming experience. You know what else they said? We'd get a complete game and not this early access hackjob. I've been willing to give intercept immense slack, but this is just downright shameful. Forgive me for not caring about what they say about their plans at this point, because they have proven time and time again they won't hold themselves to it

So after three years they decided to go EA, and somehow managed to make this game suck down a RX 6800 for medium at 1080p. Full disclosure, I meet the specs. Ryzen 9 3950X and a 6800 with 32GB of RAM. That doesn't make me any less surprised at the sheer amount of compute power that Intercept has managed to make KSP2 use for graphics that honestly hardly look better than a 10 year old game. I know I don't have to buy it in EA (wasn't planning on it), but I seriously doubt they're going to improve performance significantly over the years. KSP 1 improvement was from moving to DX11 from DX9 in the later versions, KSP2 really has nowhere similar to go from here. If nothing else, I hope we get a good postmortem of KSP2s development. Until then, discuss below. *Activates flame shield*

Go write a basic compute shader for physics and say all of this again. GPU is a different beast programming wise, and it's a very different model and syntax than conventional programming. That's not to say it's impossible, but that you need to use a different set of math and a different syntax for programming instructions for a GPU That isn't to mention the big elephant in the room, which is getting this all to work cross platform. CUDA won't work on AMD, so you really only have openGL / vulkan as an option. And then you have to compile your compute shaders at runtime for every individual machine deal with some nasty parallization stuff so you don't run into deadlock or infinite loops. So if you have two options, one being to optimize the crap out of what you know and get great performance or to attempt writing a entire physics system from scratch just to make use of the GPU that you're entirely unfamiliar with... the first makes much more sense. Can it be done? Yes Was it financially practical for the ksp2 devs? Apparently not vs just optimizing what they had.

Where wheels can't go, tracks will laugh at the terrain. The main reasons you might want legs are completely demolished once you realize tanks routinely scale 70 degree inclines (albeit slowly). Also at this hypothetical crossover point, consider the flexion you are having to impart on the legs to obtain the same speeds. How that affects the joints, and what reinforcement is going to be necessary to prevent the entire thing from shaking/ossilating itself apart. This adds weight, and now your top speed is lower. Also any failure of a Walker's legs is catastrophic, and easily lethal for the crew. A tank throwing a track still isn't a good day, but you're alive and stationary at least. Just some food for thought If ksp2 has robotics, I think walkers will be easy to create. I just want tracks in stock, since using wheels never made too much sense for me personally

I wouldn't be surprised if they were all in a folder somewhere in the ksp2 install itself, and you could just copy them wherever you wanted. Only potential hurdle would be if they're not in a easily used format, but I'm sure the community would roll a tool to convert them to MP4 in time.

None really beyond the normal pain of keeping track of two separate computers across the world and synchronizing things between them. But all of this would've already been solved for the PC multiplayer, so there's nothing unique about console cross play besides getting Sony and Microsoft's blessing to allow them on their networks.

darthgently got it 100% correct The degree of mod support KSP2 gets on consoles is entirely up to the console makers themselves, not Intercept/Take 2 If they haven't been in negotiations from day one for mods on console, it's not happening.

This is a fantastic way to create null pointer errors, overlapping colliders that cause unexpected behavior and just generally cause instability. Voxel would absolutely destroy a game the size of KSP, since for each point you have to be constantly updating the other three. Basically there's a reason SE is much smaller than KSP. They could have premade, premeshed cave models that they clip into the terrain, but that's about it.

They already had playable builds by then, even if they weren't stable or entirely representative of the current game physics is something that you implement from the beginning. I seriously doubt they have any additional physics optimizations beyond their physics lod, otherwise we'd have a dev blog or three about them. But that's still huge, since their implementation scales poorly with the number of elements. Being able to treat 300 fuel tanks as one for most of the crafts life is still huge. Note my explanation isn't perfect and I'm sure I got some elements wrong, but I'm glad I could help.

KSPs implementation of it requires that the next calculation have a value available from the previous one. So essentially you can think of it like trying to solve a system of equations with two parallel threads. If the first equation is "2x-4=256" (idk if this even is solvable, just making something for an example) And the second one is "X-3y= 64" then you cannot solve the second without first having the first to use as input. So if you spawn two threads, you end up with either deadlock (second thread somehow executed first, cannot solve and just stops the entire system until you hard shutdown) Or absolute gibberish like that somehow equaling negative 3 or 0. You can use locks, semaphores and so on to force the computer to wait until the first one is solved, but in this specific case it would actually be slower than just using one thread. So all of this to say basically I mispoke, there are ways to do multithreded rigid body simulations. But the way KSP and KSP2 have implemented their specific rigid body solver is not able to be threaded. And it never will be, since changing this literally means the entire game, all the objects,parts and potentially even the planets have to change with that. So they're over 2-3 years in development, and changing this now would likely double that at least. And quite likely much more, because debugging multithreded software is one of the most f u n experiences a programmer can have. Insidious, seemingly random bugs just because your code executed a function just a tiny bit early that's also incredibly hard to replicate reliably. It honestly is an art lol But anyway That's what I get for talking in general statements I suppose.

Yeah KSPs craft physics is way simpler than that lol In theory you could use a particle system to represent the joints, and that's parallizable. But that's not happening at this point in development, so they have to make sure physics lod works well.

Maybe how it's traditionally depicted is far fetched, but making a dome of plasma wouldn't be too far from possible. It would require massive amounts of power to maintain it, but you could vary the diameter and thickness of the field by just adjusting power and the quantity of gasses used. Hard part would be not cooking everyone inside or blinding them.

Read their development blogs in full, they're still using rigid-body physics for craft. That means no multithreading, full stop. They will work around this with their "physics lod" which will treat large collections of parts as a single entity if certain conditions are met. That alone will do wonders for performance. The original Xbox and PS4, and even the " enhanced" versions will never close the gap, they're using kavari APU with absolutely abysmal single thread performance. Even compared to the first i7 CPU you're looking at a 50% IPC deficit, and compared to Ryzen 3000 and modern Intel CPU it's over 100% PS5 and Series X have a Ryzen 3000 CPU, so they will run KSP 2 just fine. Everything else is going to be painful even with their physics lod