PolishRenegade

That one is easier to answer; as an artist you should know that most development goes into tools & architecture and not the actual gameplay. Retooling everything from Unity to Unreal and re-hire every programmer (doubtful everyone is as proficient in Unity than in Unreal (C# vs C++). So it's a no brainer they can't just change engine.

I am wondering why @Intercept Games hasn't updated their engine version for almost a year. 0.11 is running Unity 2020.3.33, April 2022 vs latest is 2020.3.46, March 2023. Worse, it's running an old version of the LTS release stream of Unity (2020.3 vs 2021.3). As a Unity Dev for 13 years, this makes no sense. Especially considering the intention to move to HDRP. There is a substantial amount of fixes, physics optimizations and overhauls between 2020.3 and 2021.3. And to be honest, for a game in Alpha, I was expecting them to use the Tech-Stream 2022.2+ at the very least. Would be curious about any insights they have on this.

Thank you! It fixed it!

Hello pap1723, I have installed a few of the supported mods you have there (and only the supported mods and their dependencies for the exception of chatterer), however, quite a big number of tech nodes just don't have any parts or are simply missing. By missing, I mean that they are empty but still shown in the tech tree (see album bellow). I am doing something wrong? Using 1.3. http://imgur.com/a/5WBdW Thank you.

Just wanted you to know that I love your work on the tech tree. Yours is the only tree that properly incorporates all the major KSP mods and actually keep the stock tree while providing a decent challenge. Continue your good work. Thank you.

Crazy moon mission! (for me at least...) in career mode which I absolutely LOVE. All or nothing Sent a 3 stage rocket to the mun. Second flight to the mun for Jeb, first attempt to land. All stock, no MechJeb. Lift off! First time I try my brand new "Pegasus Mk2" Rocket. MK1 was okay for a quick visit to the mun's orbit and back... So far so good, I get to orbit, notice my lander is pretty darn heavy but I still manage a not so bad gravity turn. But when I separate my stage 1... I hear a "BOOM"! Holy crap, what just happened!? I look at all the system, deploy the legs, test my stage 2 engines... everything looks okay :\ "Mission control, we are still a GO!" Jeb is a bit stressed. I then start my Stage 2 burn to the Mun! It's long... too long... oh god... I have a bad feeling about this. I get to Mun capture with 10% of my stage 2 fuel. NOT GOOD. I'm no where near Mun orbit! Jeb is really stressed, he knows this mission won't be easy. What now? We can abort or do a slight change of plan; forget Mun's orbit. Straight to a landing trajectory, first spot available! Stage 2 burns out fast. Jeb is no coward. "Mission control, it's all or nothing!". He didn't know how true those words will end up being. After some calculations, the optimal, fastest trajectory is set and we separate stage 2. We're down to the last stage, the one supposed to get Jeb on to the Mun AND back. After some tricky maneuvering Jeb gets himself onto the Mun's surface... on the inner surface of a pretty steep crater... but a landing nevertheless! Hey we got science to do! 3 Science labs, 3 Goo labs and plenty of reports to do send! So, we planted a flag with a plaque. It's time to back, let's look at our fuel shall we? So.. we still have 40% right? right? Jeb stares at his fuel gauge, and a big 5% stares back at him. Mission control, we have a problem. Well, we still have some mono-propellant. A lot actually. ~500 units. We've got to get Jeb back. Jeb utters his now famous words again; "Mission control, it's ALL or NOTHING!" Stage 3 burn starts, all RCS thrusters with it. Not 10 seconds later and barely 40k from the Mun's, we're out of fuel. RCS-only now. Jeb's is no fool, he positioned his craft at 45 degrees. Both vertical and lateral RCS are working... itching 1... 2... m/s of velocity. We might make it.. we might make it! After a very long 2.5 minutes of manual RCS trurst, the Mun's escaped! Can't believe the mission is not over! But, no time to celebrate... we're now at a very-high orbit above Kerbin, still have to get back, with under 100 units of mono-propellant left. Let's be intelligent about this; best bet is do an orbit around Kerbin and when at the Apoapsis let's do it again: "Mission control, it's all or nothing!" ONE minute of RCS burn later... 5 units of mono-propellant left in the tank... Jeb looks at the trajectory map computer. Something is wrong... it says that at the next orbit he'll get captured by the Mun.... AGAIN! Oh no, oh no!!! How close was he? How close is the Periapsis??? He rotates the view around Kerbin, his eyes (MY EYES) see the projected altitude marker; 30KM. 5 Kerbin hours later, on the great ocean, a *splash* is heard on the far side of Kerbin. "Pegasus has landed! Pegagus has landed! ...with 5 units of mono-propellant and a lot of SCIENCE!!!"

From all the talks about physics and the lag problem, there is very little talk about how game engines work and the source of the lag. Due to the nature of the internet, here's a bit of a background; I'm a Unity developer professionally, mostly tackling optimization issues with rendering and memory. Ensuring object culling from the GPU is as efficient as possible. That said, Unity's physics engine is outdated while also being a heavily customized version of PhysX (part of the reason it's outdated; difficult to support). From my experience with the game, in order to save on computing time, a lot of the parts (rigidbodies) can start 'sleeping'. This means that until some delta value is applied to them, no physic calculation is applied other than for the parent transform value changes (like pivot points, there is a hierarchy of objects made from the parts). This raises the question on how much KSP is really a 'realistic simulation' and how much is 'emulation'. I believe, in order to optimize as much as possible, physics-wise, the latter is probably more true. In that perspective, I also believe that most of the discussions in this thread are moot. The OP's idea is definitely something that can be implemented and could be emulated correctly, just like how most of the computations are emulated now. Striving to go _100%_ realistic in KSP is asking to have a super-computer do the calculations with custom software. That's not even close to the realm of the possible. On the other hand, rendering wise, 'showing' what's inside the fairings, is _very light_. It's the physics that makes this whole engine lag beyond any recognition. As you might guess, 'emulating' the physics inside the fairings, with 0 rigidbodies inside, is definitely a huge-boost in performance. At the end, my personal opinion is that I prefer a lag-free experience. KSP's emulation is darn good enough and can be tweaked but I don't expect nor believe it can ever be a simulation simply due to the engine's limitations in that particular domain. *Edit; The poster before also tackles most of those points. +1 to him.