Patch Two On Approach

[LeroyJenkins]

1 hour ago, InterstellarDrifter said:

single marshmallow kids...

HA! And this is what I imagine them as.... LOL 

[Mitokandria]

I may very well switch to KSP 2 primarily once Science is introduced. Till then I'm just enjoying some KSP 1 goodness.

[DerkyJerkyWreaksHavoc]

On 4/7/2023 at 2:54 PM, Nate Simpson said:

don't be so nice to them

Will do! or not! i don't know! What i do know is that KSP2 is about to become more fun and engaging. Patch 2 is another big "W" for the KSP community.

Edited April 9, 2023 by DAFATRONALDO2007 IN SPACE

[TickleMyMary]

All good news but nothing that is really going to pull me away from KSP1 at this stage... That said, I'll be there on Wednesday with everyone else (who has the game in here) seeing what improvements we got and how it all feels! 

[Wheehaw Kerman]

13 hours ago, InterstellarDrifter said:

It seems there are many kerbonaughts here that are single marshmallow kids...

I would have thought that the whining would have subsided with time, and that they would have drifted away to find something else to complain about, but apparently my optimism was misplaced.

9 hours ago, DAFATRONALDO2007 IN SPACE said:

Will do! or not! i don't know! What i do know is that KSP2 is about to become more fun and engaging. Patch 2 is another big "W" for the KSP community.

Things can only get better.

[KerbalabreK]

Just cant wait!

[schlosrat]

On 4/7/2023 at 11:00 PM, Little 908 said:

It may have been a bandaid, but it was needed, we still need the bandaid until the wound has healed 

It was and is needed in KSP1. No questions there. KSP2 is a different beast. It may look outwardly similar to KSP1, but under the hood there are differences, especially in how parts are handled. This is why it's been much quicker to get some mods out than others. We have very few parts mods at this time, even though a number of very smart people are actively working on them for the simple reason that parts work differently now. Even in non part mods I can absolutely tell you some things are different. So, please trust me, or feel free to jump in and join the modding community, but KSP2 =/= KSP1.

So, yes, KSP1 needed autostrut. Not disputing that. Please don't get hung up on a bandaid solution that worked for KSP1. We don't need bandaids, we need a system that doesn't need bandaids. If the developers don't give us such a system, then the modding community will jump in with a bandaid because players need a way to be able to make craft that work and not rocket-noodles. But please don't start by asking for the bandaid. Instead, please DO start by asking that the devs give us a game that doesn't even need them!

[schlosrat]

On 4/8/2023 at 9:59 AM, PDCWolf said:

Don't speak for yourself alone.

Just curious @PDCWolf, who should @The Azizspeak for if not himself?

[Tharwat]

is the game locked to 25 fps or my gpu can't run it with more than that?

[Kerbin Launch Coalition]

Has to auto-save issue been rectified in this patch?

[Tazooka]

1 hour ago, Kerbin Launch Coalition said:

Has to auto-save issue been rectified in this patch?

We'll find out in the patch notes tomorrow

[LameLefty]

13 hours ago, Tharwat said:

is the game locked to 25 fps or my gpu can't run it with more than that?

It’s not locked at 25 fps for me. Like most Unity-based games, it’s usually going to CPU-bound for any kind of complicated ship larger than a dozen parts or so. 

[TheYeetster]

46 minutes ago, LameLefty said:

It’s not locked at 25 fps for me. Like most Unity-based games, it’s usually going to CPU-bound for any kind of complicated ship larger than a dozen parts or so. 

And since KSP2 isn't all that optimized yet - it's both CPU and GPU bound on some systems.

[DerkyJerkyWreaksHavoc]

On 4/9/2023 at 8:53 AM, Wheehaw Kerman said:

Things can only get better.

wait... isn't that a quote in the song used during the Early Access Trailer? I am Kerlock holmes

https://youtu.be/STTTp9nDFOE

Edited April 11, 2023 by DAFATRONALDO2007 IN SPACE

[Dunas Only Moon]

On 4/8/2023 at 8:57 AM, PDCWolf said:

-1 for suggesting mods, +1 for being anti-wobble.

Sadly, Nate thinks wobble is a feature.

Reminder:

Wobble is not realistic, is not analogous to anything realistic, and stems from a problem that is the default unity joint system (which oh surprise they're using again on that "new" "strong" "foundation").

With that previous list + "ksc lighting", it's looking very lackluster on what's proper headliner fixes.

I'm gonna do what you shouldn't and establish a pace based on 2 patches and their content: It's gonna be 6 months per "major" update, maybe 1 month between these small patches once they're done trying to regain goodwill 

Im one of those players!

On 4/7/2023 at 7:50 PM, kennyc222 said:

THe performance starts decreasing on my PC (with RTX3060, i7 10700 2.5GHz and 32 GB of RAM DDR4) when I start planning of maneuver. ANd going to eve is very challenging for me!

That is my setup! and as a console player i cant get used to this

[AlphaMensae]

On 4/8/2023 at 7:57 AM, PDCWolf said:

-1 for suggesting mods, +1 for being anti-wobble.

Sadly, Nate thinks wobble is a feature.

Reminder:

Wobble is not realistic, is not analogous to anything realistic, and stems from a problem that is the default unity joint system (which oh surprise they're using again on that "new" "strong" "foundation").

Unfortunately, there is only so much you can do with KSP's lego-style and Unity-PhysX besides spam ever more joints, which is what Squad did, what autostrut did, what KJR does, and what IG will end up doing if they haven't already. Unity and PhysX simply aren't set up to handle multi-hundred part assemblies we call "vessels". It's a legacy of Felipe (HarvesteR) wanting the lego-like building system for KSP, where you mash "space bricks" together to make cool and fun vessels.

The only real solution is to use a full procedural part method and built-in part welding to greatly reduce the number of rigidbodies in a craft, but that's not the KSP way.

[pandaman]

33 minutes ago, AlphaMensae said:

 

The only real solution is to use a full procedural part method and built-in part welding to greatly reduce the number of rigidbodies in a craft, but that's not the KSP way.

I'm not sure I'd go quite that far. ..

The procedural wings work great, and the fairings (although nit perfect) do work ok from a construction point of view.

I think the non tapered / adapter style tanks, beams and trusses, maybe SRBs too) should all be variable length, but probably in 'steps' equivalent to the current shortest length.  That effectively keeps the same 'Lego' style, but greatly reduces part count and size of the parts list.

[PDCWolf]

1 hour ago, AlphaMensae said:

Unfortunately, there is only so much you can do with KSP's lego-style and Unity-PhysX besides spam ever more joints, which is what Squad did, what autostrut did, what KJR does, and what IG will end up doing if they haven't already. Unity and PhysX simply aren't set up to handle multi-hundred part assemblies we call "vessels". It's a legacy of Felipe (HarvesteR) wanting the lego-like building system for KSP, where you mash "space bricks" together to make cool and fun vessels.

The only real solution is to use a full procedural part method and built-in part welding to greatly reduce the number of rigidbodies in a craft, but that's not the KSP way.

The point is what you can do with Unity default joints and "HarvesteR's legacy" shouldn't be a thing, since we were allegedly getting a new, optimized, specialized codebase as proper foundations for the heightened kerbal experience that KSP2 was supposed to be. As it stands right now, KSP2 is hitting its head against the same barriers KSP1 did, so it's like they've learned nothing from KSP1.

57 minutes ago, pandaman said:

I'm not sure I'd go quite that far. ..

The procedural wings work great, and the fairings (although nit perfect) do work ok from a construction point of view.

I think the non tapered / adapter style tanks, beams and trusses, maybe SRBs too) should all be variable length, but probably in 'steps' equivalent to the current shortest length.  That effectively keeps the same 'Lego' style, but greatly reduces part count and size of the parts list.

Making non-procedural size variants trades less colliders for a lot more resources wasted on extra parts where you could do the same with just one.

The Lego style would still be there, you just go from building whatever with your limited bucket of Legos, to building in a proper interface like Lego Digital Designer or BrickBuilder and ordering the exact blocks you need without wasting on extras.

 

[little star]

22 hours ago, Tharwat said:

is the game locked to 25 fps or my gpu can't run it with more than that?

I've also noticed this
at first I thought something was lovey with v-sync, switched it on and off and the problem didn't go away 
the same thing happens when I'm in space: the framerate just won't go above or below a certain value 

i can't really test it right now, but, if you're using an nvidia GPU, i'd check it's control panel

[AlphaMensae]

15 minutes ago, PDCWolf said:

The point is what you can do with Unity default joints and "HarvesteR's legacy" shouldn't be a thing, since we were allegedly getting a new, optimized, specialized codebase as proper foundations for the heightened kerbal experience that KSP2 was supposed to be. As it stands right now, KSP2 is hitting its head against the same barriers KSP1 did, so it's like they've learned nothing from KSP1.

It's still Unity and PhysX, and though it is a newer version (but not the latest) it's still Unity rigidbody physics at its core. Still works the same way. And KSP2 is not an all-new "rebuilt from the ground up" codebase. What's been revealed is that it's just mostly a refactoring of the KSP1 code, started by Star Theory, and then continued by a bunch of all-new coders at Intercept who had no idea what they were doing. Some of the KSP1 code has been dumped, and there is new code present, but the reaon we're getting all the old KSP1 problems again is because KSP2 is just KSP1 with better graphics and sound/music.

Juno: New Orgins shows what can be done with an all-procedural part system:  far less rigidbodies (i.e. parts) needed and non-wobbly rockets.

[The Aziz]

1 hour ago, pandaman said:

I'm not sure I'd go quite that far. ..

The procedural wings work great, and the fairings (although nit perfect) do work ok from a construction point of view.

I think the non tapered / adapter style tanks, beams and trusses, maybe SRBs too) should all be variable length, but probably in 'steps' equivalent to the current shortest length.  That effectively keeps the same 'Lego' style, but greatly reduces part count and size of the parts list.

Procedural wings exist because the slappy rectangles were a hassle to set up. Stacking up cylinders is easy.

And the semi proc tanks would ONLY reduce the size of part list. Part counts would stay the same because there still would be upper length limit, so after making one long you'd still have to add a second one when needed.

[PDCWolf]

20 minutes ago, AlphaMensae said:

It's still Unity and PhysX, and though it is a newer version (but not the latest) it's still Unity rigidbody physics at its core. Still works the same way. And KSP2 is not an all-new "rebuilt from the ground up" codebase. What's been revealed is that it's just mostly a refactoring of the KSP1 code, started by Star Theory, and then continued by a bunch of all-new coders at Intercept who had no idea what they were doing. Some of the KSP1 code has been dumped, and there is new code present, but the reaon we're getting all the old KSP1 problems again is because KSP2 is just KSP1 with better graphics and sound/music.

Yes, I know, and it is almost exactly what I said.

It should not be that, it defeats the whole purpose of a sequel.

[AVaughan]

6 minutes ago, The Aziz said:

And the semi proc tanks would ONLY reduce the size of part list. Part counts would stay the same because there still would be upper length limit, so after making one long you'd still have to add a second one when needed.

Assuming that semi-proc parts let you build longer/bigger tanks than are available in stock, then part counts for many large rockets would shrink.  (If the tanks were twice as long, then you only need half as many tanks for the same amount of fuel.  If they are twice the diameter and twice as long, then potentially you could cut tanks by up to a factor of 8).  

Optionally you could also add optional switchable nose cones and engine plates as part of the tanks, further reducing both part count and unity joints.  If the optional nose cones were the same as the existing nose-cones, then you can actually retain most of the lego style rocket building.

Yes there will be cases where the part count remains the same.  Some of that will be because players are building curved structures from the existing parts, and a simple semi-proc tank implementation probably isn't going to help with curved structures.  There are potentially also players who will build as big a rocket as they can, perhaps limited by the performance they are willing to tolerate. 

[LeroyJenkins]

21 minutes ago, AVaughan said:

If the tanks were twice as long, then you only need half as many tanks for the same amount of fuel.  If they are twice the diameter and twice as long, then potentially you could cut tanks by up to a factor of 8

You are forgetting the impact to the TWR. Yes you may have less parts in your rocket, so Unity works better. However, for the same rocket engine performance your TWR decreases if you double the diameter and double the length, or any variation thereof without changing the performance characteristics (Isp) of the engine you attach. Less tanks (with same amount of fuel) does not allow for attachment of more engines  to get the TWR one would need necessarily. This is why asparagus staging is a benefit. More engines (Higher total Isp) for the same amount of fuel, and as the fuel decrease you shed the weight of the rocket housing at each stage, thus maintaining TWR or improving it as you ascend. Though I am for procedural part/tanks etc, they need to be designed and built with this in mind. In engineering we always should assess how one design benefit effects the rest of the system and to look for the drawbacks. And there always are drawbacks, no free rides when it comes to physics or engineering.

Edited April 12, 2023 by LeroyJenkins

[Observe]

1 hour ago, AlphaMensae said:

It's still Unity and PhysX, and though it is a newer version (but not the latest) it's still Unity rigidbody physics at its core.

I wonder if the game would benefit from a different physics engine? One such, is Jolt, discussed here for example. Though, perhaps that would be barking up the wrong tree for all I know.

" By switching to this new engine, the studio saved memory, executable size, and were able to double their simulation frequency while using less CPU time."

Edited April 12, 2023 by Observe