DailyFrankPeter

Reversing time with a physics based game sounds terribly hard to pull off (if they are using a physics lib it likely does not do that, so you have to write your own solution from scratch - assuming you have devs specialized in physics), plus there would be no end to the bugs caused (like going back and forth not having quite the same effect each time). Alternatively the game could store state and basically undo it when warp is negative which would require making space to store it (i.e. taking away memory, which is currently used for smooth "forward" gameplay) or drive space (or both). To see for yourself get any 3D package, like Blender, and look into physics simulation rendering/baking.

Decals. Yes. I am for it!

I thought the main thing the devs set out to do in KSP2 was to rewrite the game core, so as to: 1) remove limitations preventing interstellar travel (and I don't mean speed of light , but numeric precision limitations, or memory/CPU for that matter) 2) make time warping more stable - because even more of it is needed for interstellar And, even if I can't speak for 1), they have succeeded at 2) IMO, because in KSP1 I don't remember being brave enough to burn at any other warp setting than 1x (i.e. and if it takes some more CPU/GPU to avoid things like destructive rubber banding, then it's fair enough I guess).

This is one handsome lander!

Yeah, makes sense. Wait... but isn't the latter used in most currencies?

Not sure it has been suggested before but what do you think about adding fractional time warp values, i.e. slo-mo? The two uses I can imagine straight away would be: - easy mode e.g. for aircraft or lander landings/hopping - considering how the faster you warp the lower the FPS, this may actually increase FPS (especially in crucial moments) for folks with lower specs

+1

This should be a menu option because people are completely polarized: some think pressing 1 button is too much, some believe we didn't need that button.

Definitely! Had to revert or load saved game so many times because of it. Alternatively designs could be automatically saved not every few minutes (or whatever the schedule is) but on 'launch' - say, reserve 3 rolling save files especially for that (and give them a clear title).

I think it's a problem if any part makes another completely obsolete.

+1

+1 I was surprised that I had to unlock quite a bit into the 2 tier of tech tree to get the wheel part that would count (it felt out of order), not using many of the probe cores/electronics on the way even once. Also once I did, I cheesed the mission by putting the four wheels on the capsules roof for the launch (without making it an actual rover) which felt like it should not count.

What makes it tip? Perhaps it has reaction wheels (SAS) that you can disable?

If you mean grouping into sets, which are simulated as a whole, then that's the first thing I would also do. There's some real-world intuition behind it, too: - for example a long truss may be assumed to be one piece (it's not built from cubes IRL*) and only connections between it and whatever is at either end simulated; - similarly for some other 'homogenous' groups - small items, like RCS, attached to large parts like tanks do not have to be simulated, because it is the fuel-tank-to-rest-of-rocket joint that gets the most bending force; - or if there is some impact powerful enough to rupture the fuel tank, it also doesn't matter how strong the small attached part was So there's definitely some opportunity to skip simulation. There could be a list of pairs of object types for which joint simulation does not matter. --------------------- *well, it is from triangles, but we can assume engineers have done a good enough job to make it stiff enough to look like 1 piece

Not sure this isn't over most people's heads on this forum - if not your idea itself, then the understanding of what's already in the core game, or planned in the future, optimisation-wise. Maybe you can email the new tech lead. Also... you and I both know what happens when you say the words 'major overhaul'.

Seems like we haven't agreed whether devs should put more m-to-n-node rocket adapters in the game or make you solve custom transitions using nosecones, but I think it became clear that the workaround transitions with nosecones should be looked at in terms of drag.

Short answer: Voyager Long answer: I use trusses for a lot of my builds. You say they have no function - by which you probably mean they have no other function than structural members spanning some distance. This is exactly their point in real life and I like the realistic look they add. In the real world they are also the most economic/lightest way to achieve a given span or stiffness. This is as opposed to using e.g. empty fuel tanks as structural members, which gives crafts a toy-like look I'm not very fond of. And in reality you also would not pay for building a fuel tank, just to never fuel it but use it as a long structural member instead. BTW, the efficiency squad are the very people who invented trusses. Trusst me.

Rovers disappeared. Now they're back but the kerbals are gone > Let me guess.... They mysteriously reappeared in Jool's orbit a few years later. The Kerbals are gone, but instead the rovers emit a spooky sound and everyone sent to investigate them is going mad?

Good to know. Would be even better to see the drag coeff. of current craft (like we can dV).

What if you launch it as two crafts (two launches), dock with the plane to the pod or something similar, fly to target and then undock it to drop it?

I would love dirt effects* *just not on solar panels

@Periple OK, so leaving aside aesthetics, which are a personal thing... I'm worried that kitbashed adapters like these, which often have many, partly exposed, parts (e.g. nosecones half-buried in central core), are treated by the aerodynamics simulation as whole parts exposed head-on to the airstream. This means what looks like a streamlined solution with only 2x the area, can in fact be calculated as e.g. 10x the area and 10x the drag. At least I think this was the case in KSP1. Can anyone in-the-know comment how it works in KSP2?

Procedural adapter. Why not. +1

+1

It can also be solved by: 1) auto-warp - time warp is allowed automatically (or even enabled, like a screensaver, automatically) if every player stays put in their capsule/seat, and is interrupted automatically if any of them is doing something (for @Abelinoss' extreme example it would mean the Duna transfer player will complete essentially their whole mission without the interstellar player ever needing to be at their keyboard, and at some point Kerbals returned from Duna will go idle back at the KSC, at which point the universe will time warp a 1000 years to the interstellar player's maneuver alarm clock) 2) warp master - picking a commander who will control it exclusively (which could be a whole bunch of fun in its own right, because teams will have to communicate and there will be more opportunity for Kerbal goof ups)