Jump to content

Incarnation of Chaos

Members
  • Posts

    1,204
  • Joined

  • Last visited

Reputation

728 Excellent

2 Followers

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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
  12. I wouldn't pay a single cent for that, Jesus people there's literally thousands of other games you can play in the period while you're waiting for ksp2. Hell you can even take up a new hobby, I rather enjoy lifting weights nowadays and I started over a year ago. The entire reason KSP 2 exists is that there's so many things you just can't patch in after the fact. Asking them to repeat the same mistakes just because you're impatient is absurdity of the highest order.
  13. Because methalox won't be practical for even the "shortest" interstellar transfer. And I'm going to clarify what I mean by practical here. Yes, in theory you could loft enough methalox into orbit to complete a transfer to another star. Especially when you have a minmus/mun colony, but the sheer quantity of tankage would make the craft fragile under acceleration, and frame rates would likely be measured in minutes per frame... And by the end you still have the biggest issue, which is turning the whole thing around and cancelling enough velocity to capture at the other star. Now most of these issues can be solved by clever staging, and the final craft that reaches the destination very well could be over 1/32 the size of the original. But that's a significant amount of time, money and resources you used both IRL and in game to achieve the same result using a much smaller and more manageable Orion or more advanced craft would've accomplished in a shorter time. As for the rest? Energy density is king when you want to optimize the amount of mass per volume of fuel you have to carry. If I want to make a small, compact lander. There's very little that beats RP-1 and LOX, but as mentioned above I might not be able to find them at my destination (let's say jool). I know I'll find plenty of hydrogen and oxygen at laythe in the form of water, so hydrolox for my lander might be preferred despite the bulky nature. Duna I know I'll find plenty of CO2 to make methane though, so methalox is actually viable the whole way.
  14. Didn't these spew the highly radioactive fragments of the core alongside their exhaust, require a reactor pile closer to submarine levels of enrichment (20-40% U235) and a massive lead bulkhead to separate the crew from the active reactor? Don't get me wrong, I've always loved the idea of nuclear thermal turbojets/fans/ramjets. And Kerbals don't know fear nor radiation, but I've never seen any really good proposals for alternative designs.
  15. Because mobile sucks Play a game at 24 fps, then 60. And no, I don't just see it because I want to. I literally have gone back to 30 and 60 fps, and the difference is incredible. Everything is slower, animations chug, input lag is oppressive. Again, you can read about this all day but until you actually play with higher refresh rates you won't understand what I'm saying in the slightest. Also the refresh rates of TV have far more to do with the amount of data you can push over a given frequency than anything else. 50 hz is less information, so less wattage at the station for the same transmission.
×
×
  • Create New...