If KSP2 was reworked, what would you change?

[Pthigrivi]

35 minutes ago, Lisias said:

So every vessel has its own "spacetime bubble". What means that it's also a single player problem. What means that once they solve the problem for single-player, multi-player will have it for free.

You know, sometimes it pays to be crazier. They moved the timewarp problem from multiplayer to the mainstream singleplayer, where they would be able to get more exposure and, so, develop the thing with more confidence before going MP where everything is way harsher to work with.

I don't know if I'm less crazy than I look, or if they are as crazy as me - in a way or another, I will not be alone in the asylum!

On a side note, instead of "reconciliate" the spacetime bubbles, I would create a "temporary" container with it's own spacetime and then "translate" the private spacetimes into it, in the same way every object has it's own origin and such origin is translated into the 3D World it will be rendered into.

Something like what's happening on the Serenity Robotics - the root cause of most of the problems is exactly the transformations being applied directly into the PartModule, making it susceptible to float errors being accumulated (and not only due time warp) and ending up drifting away.

Such solution would prevent a lot of problems that a "reconciliation" would create - and perhaps reuse the same tools, but extended to a 4D transformation matrix? Someone "out there" had already worked on something like this?

I suspect you labeling it as "craziness" may be related exactly to the same problems, but on a wider audience now: 4D spacetime.

Yeah the fundamental problem is that with multiple concurrent missions every player maneuver and every interplayer interaction needs to maintain continuous linear causality with the motions of the relevant celestial bodies over time. The only way to maintain that is to have a moving official chain of events and players warping independently making revisions to the official chain. If one player is making a 2y transfer to Jool while they do a 300d transfer to Duna and a dozen KSOI missions all of those vessels need to depart and arrive with coherent times and dV expenditures to everyone else playing and timewarping their own multivessel, multicolony programs forward in time. I’ll post below the only workable sketch Ive come up with for this. I think it’s interesting but would  be kind of a disconnected headscrew for your average teenager hoping to smash buggies with their friends.  Any other scheme for cheat-syncing results in unresolvable causality paradoxes like docking with a station that doesn’t yet exist or pulling fuel from a colony before its been harvested if anyone has multiple vessels flying around, which they will. 
 

Edited January 16 by Pthigrivi

[Lisias]

9 minutes ago, Pthigrivi said:

Yeah the fundamental problem is that with multiple concurrent missions every player maneuver and every interplayer interaction needs to maintain continuous linear causality with the motions of the relevant celestial bodies over time. If one player is making a 2y transfer to Jool while they do a 300d transfer to Duna and a dozen KSOI missions all of those vessels need to depart and arrive with coherent times and dV expenditures to everyone else playing and timewarping their own multivessel, multicolony programs forward in time. I’ll post below the only workable sketch Ive come up with for this. I think it’s interesting but woukd  be kind of a disconnected headscrew for your average teenager hoping to smash buggies with their friends. 
 

Interesting. This is essentially GIT applied to Space Time: you can move you local HEAD to any point in the past as long is read/only - if you are going to interact and change something, you need to move your HEAD into the TOP of the current "branch".

And you can have many different "branches" being "committed" concurrently by different people, being the "reconciliation" you doing "checkouts" from another branch into your "vessel".

I like it.

Spoiler

(by I'm crazy!!!)

 

[Pthigrivi]

Just now, Lisias said:

Interesting. This is essentially GIT applied to Space Time: you can move you local HEAD to any point in the past as long is read/only - if you are going to interact and change something, you need to move your HEAD into the TOP of the current "branch".

And you can have many different "branches" being "committed" concurrently by different people, being the "reconciliation" you doing "checkouts" from another branch into your "vessel".

I like it.

  Hide contents

(by I'm crazy!!!)

 

I mean basically yeah. We run the same principle with CAD files in our office so multiple designers can contribute to the same working draft without overwriting eachother’s work. 

[Vexillar]

4 hours ago, Lisias said:

Interesting. This is essentially GIT applied to Space Time:

So... a Kerbal Multiverse it is, then!

[cocoscacao]

6 hours ago, Lisias said:

every vessel has its own "spacetime bubble".

No. Each player would have a bubble. You can time warp independently from other player, until two vessels meet. Then reconciliation happens. 

This has several problems. How DO vessels meet, if they're on different timelines? 

If you're the one lagging behind, and reconciliation starts unfolding, your timeline speeds up, potentially crashing other vessels to planets/moons.

At least, this is what I gather from Nate's talk. I will try to find the source. If this is the case, then it's crazy. 

[Lisias]

50 minutes ago, cocoscacao said:

No. Each player would have a bubble.

Well, so apparently we found the problem.

The spacetime bubble should be vessel wide, not user, and you explained yourself the reason.

What you described is pretty similar to what happens on KSP1 when you extend the physics range too much and the float imprecisions start to screw grounded vessels.

Ok, completely different problems, but the analogy sticks: expanding the timewarp bubble to all the vessels of the user at the time will screw the "distant" vessels the same - in spacetime, time is just another dimension...

Edited January 16 by Lisias
Kraken damned auto-correctors!

[Fizzlebop Smith]

17 hours ago, Pthigrivi said:

Yeah the fundamental problem is that with multiple concurrent missions every player maneuver and every interplayer interaction needs to maintain continuous linear causality with the motions of the relevant celestial bodies over time. The only way to maintain that is to have a moving official chain of events and players warping independently making revisions to the official chain. If one player is making a 2y transfer to Jool while they do a 300d transfer to Duna and a dozen KSOI missions all of those vessels need to depart and arrive with coherent times and dV expenditures to everyone else playing and timewarping their own multivessel, multicolony programs forward in time. I’ll post below the only workable sketch Ive come up with for this. I think it’s interesting but would  be kind of a disconnected headscrew for your average teenager hoping to smash buggies with their friends.  Any other scheme for cheat-syncing results in unresolvable causality paradoxes like docking with a station that doesn’t yet exist or pulling fuel from a colony before its been harvested if anyone has multiple vessels flying around, which they will. 
 

I somewhat disagree. There doesn't *need* to be any over arching casualty outside the immediate sphere of influence. 

I have always thought something akin to Lisias suggestion would be viable.

There would be a separate clock in the Virtual Space. Upon leaving you would rationalize with your own timeline.

The host or person who sends the group invite would essentially gain am SOI that impacts the world clocks.

Other than that you would see a mission timer.

Each time a person logs off they are in limbo and return the the celestial clocking for the person furthest.

You want to track a launch window.. it tracks the days until.. but no totals.

An over arching timeline where a dozen people build and mine resources at various times doesn't really work outside of a sandbox element with a lot of hand waving .

Career I feel would have to focus on a different approach.. like working within Single systems, and focusing on cooperative missions or having a space race style where first to reach object wins.

This would need with the aforementioned ghost mechanic.

I hate time warping for more than a day. Maybe with a super long burn but it bother me.

I have played career games where the goal was to establish contact with far off places and have time warped 2 years at a time.

But I prefer to run a bunch of missions where I have something to do every day.

So what happen if you are in my future and want to build a base on a location.. but I build there *first* .. will there be red ghost / blue ghost? Or I want to play with you, but you are super far ahead and every planned maneuver for the next five years will go out the window?

 

It maybe rather simple in truth.. but I would think tracking multiple time lines (one for each person building) and trying to synch all that up across how ever many people will lead to some really messy errors and problems trying to rationlize.. 

or possible give birth to some deformed version of skynet.

 

Edited January 16 by Fizzlebop Smith

[Pthigrivi]

3 hours ago, Fizzlebop Smith said:

I somewhat disagree. There doesn't *need* to be any over arching casualty outside the immediate sphere of influence. 
...
An over arching timeline where a dozen people build and mine resources at various times doesn't really work outside of a sandbox element with a lot of hand waving .

The problem is you absolutely do need an overarching causality chain and it can't be handwaved away. As Lisias points out time is a dimension. When I press time warp its not just the one craft Im controlling that moves forward in time. Everything moves forward in time--planets, moons, active vessels, everything. It's an astrolabe, and when you crank the handle everything moves. This is absolutely necessary so any vessel in transit departs and arrives at bodies that are themselves progressing along their orbits. When I press timewarp all of my active craft need to progress along their trajectories and the relative locations of all bodies need to move in unison for encounters to occur. A game in which only one player has control is a turn-based game with 5 to 30 minutes between turns. It's utterly unplayable. So each player needs to have the ability to press time-warp at will and watch the entire universe (from their point of view) move forward in a continuous chain of causality. You start with the planets in the position they're in on day zero and progress along a continuous timeline as they move relative to each other. In order for two players to synch they need to literally synch. All of my planets need to be in the exact same position for me as they are for you, otherwise any vessels we have in transit would find their destination planet has spontaneously moved and miss their targets. That means we can only be synched if we literally catch up to each other at the exact same time and date on the master calendar. And yeah! This kinda sucks. It means if we have a group space station in low kerbin orbit and you take off from KSC in a shuttle and fly toward it, but before you reach it I arrive back from a 6 year Jool mission in your future, you now have to park your shuttle in orbit, timewarp forward a 6 full years to interact with that station, and manage any and all transit flights you have in the process so they don't miss their capture burns over those 6 years of time-warping. How often will that happen? Kind of depends on how well your playstyle and average playtime matches with your multiplayer mates. Its gonna happen sometimes though. These big weird leapfrog jumps aren't probably very fun, but its absolutely necessary for a working spaceflight game in which multiple players have multiple vessels on simultaneous interplanetary transfers. This fundamental flaw is why I think KSP multiplayer will never actually be what players expect it to be. 

Edited January 17 by Pthigrivi

[Starwaster]

Thermodynamics.

[Lisias]

11 hours ago, Pthigrivi said:

The problem is you absolutely do need an overarching causality chain and it can't be handwaved away. As Lisias points out time is a dimension. When I press time warp its not just the one craft Im controlling that moves forward in time. Everything moves forward in time--planets, moons, active vessels, everything. It's an astrolabe, and when you crank the handle everything moves.

In Newtonian physics, yes. But not in Relativity.

What my suggestion left implied is that the time model of the game must be relativistic - it's the inescapable consequence of each vessel living is their own "spacetime bubble" - what, if you read Relativity, you will find that in reality, we really do - Gravity is a too weak force to significantly distort spacetime around us, but there're evidences that our atoms ages differently on the head and on the feet.

Now, timewarps are not relativity, it's an (ab)use we are taking in order to make the game palatable, and so we have to cope with problems that Relativity doesn't (as far as we know), as time paradoxes. This is what the "Reconciliation" aims to do, prevent time paradoxes - but it's problematic on a Newtonian Space as explained above - but can be feasible on a Relativist one.

Do "reconciliations" as needed, and not preemptively for everything. Let each vessel living if their own spacetime bubble until there's no other way but to "reconciliate" it with another one. Rinse repeat.

We do it for decades already on programming - Delayed Initialization is a Design Pattern.

I'm proposing a Delayed Reconciliation.

 

14 hours ago, Fizzlebop Smith said:

I somewhat disagree. There doesn't *need* to be any over arching casualty outside the immediate sphere of influence.

As long you are alone in the Universe. In the exact moment two entities "meet", you have time paradoxes that need to be tackled down - where "meeting" can be absolutely any phenomena with causality.

For example, Vessel A is orbiting Kerbin, and you took Vessel B to a Mün Transfer and settle her up on Münar Orbit - and you used timewarp on the transfer.

Now we have a time paradox between Vessels A and B - how they will see each other on the sky?

The proposition above has a solution: "time branches". Vessel B creates a "time block chain" that it's used to allow A to visualize B from their spacetime bubble. The problem will be how Vessel B will see Vessel A, because B will be in a "future" where A didn't reached yet. This is a problem we need to solve in order to implement this stunt.

Another example: communications.

Vessel A sends a message to Vessel B while B is in warp time - how to send a message to the Past? Because A is "living" in the past related to "B" now. Vessel B can send a message to A, however, as long the message is queued on the A "bubble" and presented only on the correct future time in the A's bubble.

You see, we are literally dealing with relativistic problems here.

Basically, we solve these two time paradoxes somehow, we can implement Relativity in the game - and, boy, this will make things incredibly interesting. With an added bonus: it can be easily "squashed" to simulate a Newtonian spacetime by time warping all bubbles at the same time, if the user don't want to cope with Einstein, and so the same mechanism can be used both on single and multiplayer, fulfilling another useful requirement.

 

9 hours ago, Starwaster said:

Thermodynamics.

Relativity.

  

14 hours ago, Fizzlebop Smith said:

So what happen if you are in my future and want to build a base on a location.. but I build there *first* .. will there be red ghost / blue ghost? Or I want to play with you, but you are super far ahead and every planned maneuver for the next five years will go out the window?

It will be not drawn for you! It's the nice thing to add time into the Vessel's origin, you can filter everything outside your Light Cone by merely clipping crafts where the time dimension is unfit, in the exact same way we clip things behind the camera by clipping the Z axis.

Edited January 17 by Lisias
brute force post merge

[GluttonyReaper]

On 1/15/2025 at 4:59 PM, PDCWolf said:

The biggest problem KSP2 has, is the people who already had played KSP1. As far as the sequel got the challenges were still the same, so the spark wasn't there. The loop was the same: Get an orbital mechanics related challenge (get to orbit, get to a difficult orbit, get to another body, put a satellite here, get a dude from there) and build a rocket for it. That's it, that's the stone KSP1 never got over. Even science was more of the exact same loop, just like in KSP1 they could not figure out a way to expand that past adding "but without this part" to that previous loop.

On 1/14/2025 at 10:43 PM, Pthigrivi said:

1) Focus on KSP2 as an actual game

Honestly I wonder what KSP2 could have been if it was handed to a team with less familiarity (or perhaps just much less attachment) with KSP1. Other than proper orbital mechanics, a few art details, and the Kerbals themselves... there isn't really any mechanics from KSP1 that couldn't have been tossed away, replaced, or in many cases just added where it was very lacking. Unfortunately a lot of the choices made for KSP2 seemed to have purely been made on the basis of "well that's how KSP1 did it" - e.g. I'm not convinced there was ever any consideration for whether the science system (or some variation thereof) was actually the best choice for a cohesive game. Perhaps the planned features that were never finished could have been different, but things didn't really get far enough to present anything that I think was "surprising". 

Tangentially, it's neat to imagine how KSP could have turned out if it had stuck to its more cartoonish roots rather than getting swept up in the realism chase. Think of it - setting up a resource networks to harvest rocket fuel from Eve's oceans to fuel your motherships that you've constructed from Dunanian ores...

[PDCWolf]

3 hours ago, GluttonyReaper said:

Honestly I wonder what KSP2 could have been if it was handed to a team with less familiarity (or perhaps just much less attachment) with KSP1.

I don't think I see the same attachment others see. From my perspective their vision was:

1. Take KSP1
2. Add the three most popular mods (Interstellar, resource harvesting, colonization)
3. Add a couple extra hurdles, like some resources only being available on some planets.
4. Profit.

I'm sure it was a very smooth pitch to throw at PD's offices, versus Rocketwerkz going overly technical and without images, and whoever was the third offering god knows what they presented.

That's not attachment, that's finding an easy way to make money. Meanwhile you have the fanbase, the actually attached people, who were thinking technical terms: a custom or at least more capable engine, ways to reduce physics cycles with part welding, a better celestial body system that can support axial tilt, a non pqs solution for spherical terrain, and so on. That's attachment, that's being so attached you know what 1 lacked to go further.

3 hours ago, GluttonyReaper said:

I'm not convinced there was ever any consideration for whether the science system (or some variation thereof) was actually the best choice for a cohesive game. Perhaps the planned features that were never finished could have been different, but things didn't really get far enough to present anything that I think was "surprising".

And their design proposals + the unwillingness to share details once things turned sour don't paint the idea that the missing features were the stronger ones. Just to say that again: they did not ever answer technical questions. And even refrained from sharing anything from the design side of things when their heating blog and their "here's how we draw a circle" devblog got battered. I'll never buy that they somehow got offended and went silent from that, I'm fully invested into thinking that was their best.

When I call them amateurs, I don't mean the poor guys that were hired for dirt cheap salaries in their revolving door politics, I mean the people in charge of having a vision and designing it.

3 hours ago, GluttonyReaper said:

Tangentially, it's neat to imagine how KSP could have turned out if it had stuck to its more cartoonish roots rather than getting swept up in the realism chase.

From HarvesteR, we know he'd have either gone the aviation route, or the game would've remained a fireworks simulator. I think the best a "cartoony" game can do with orbital mechanics as a secondary element is The Outer Wilds. That game is great in telling a story and everything, and the orbital mechanics have been made incredibly simplified. What you get is a game you play once or twice and never again.

That's why I believe in realism, consequences and deep player involvement with having a learning curve to master, that's what makes people stick. And the people that don't like that don't play KSP, they play some playstation interactive movie and you'll never sell KSP to them, no matter how simplified.

[K^2]

1. Engine. Unity is just not a good fit in 2025. Lacking budget for something dedicated, Unreal is a much better foundation.
2. Rigid physics for crafts. Look, there's flex to real structures, but it's hard to simulate in a way that works. You're better off simulating the stress across a rigid structure. You'll still have failures of overstressed parts, but no flappy rockets.
3. Assembly building and part manager are a mess. This is less concrete - it just needs work. From setting up unit tests on saving/loading the craft so that the system isn't broken half the time, to the UI/UX side of things.

[Fizzlebop Smith]

10 hours ago, Lisias said:

In Newtonian physics, yes. But not in Relativity.

I'm proposing a Delayed Reconciliation.

That's what I think as well but lack the vocabulary

"Each time a person logs off they are in limbo and return the the celestial clocking for the person furthest."

No one care  where planets are Relativite to anyone other than themselves until time to kick it.

It would have to or ...  that person plays without TW and covers minmus will disrupt your fuel station will one day be.

It only matters *when* it matters.

--

PS .. Kerbal Lives Matter

Bring Mack Mission Specialists .. maybe a few more.

Edited January 17 by Fizzlebop Smith

[wnderer]

I haven't played KSP2 and I don't know if this stuff could be done with mods. What I want are better design tools. Something like this.

I think there is too much trial and error. I want to design stages to have so much thrust, for so much time with a starting mass and ending mass. I want my stages to have so much acceleration above gravity and account for air resistance and want graphs and tables of data to help me work it all out. Adjusting how much fuel there is and how much thrust doesn't help unless I know how long it is going to burn. I want wind tunnel tests. I want to collect data I can analyze after rocket flights. To me, there seems to be a lot of science and engineering built into the simulation but very little built into the game.

As for game play, I think linked anomalies would be fun. You start with an artifact which gives you a clue of where to look on Kerbin. That anomaly tells you where to look for the next one and so on. Maybe there are keys you need to find that open artifacts to get Easter eggs about alien civilizations.

Or linked science. You build satellites to map the planet, that gives you maps you can look at. When you deliver it some scientist tells you more tests to setup and that leads to some Easter eggs that tell you about the evolution of the planet.

[Scarecrow71]

1 hour ago, wnderer said:

I think there is too much trial and error. I want to design stages to have so much thrust, for so much time with a starting mass and ending mass. I want my stages to have so much acceleration above gravity and account for air resistance and want graphs and tables of data to help me work it all out. Adjusting how much fuel there is and how much thrust doesn't help unless I know how long it is going to burn. I want wind tunnel tests. I want to collect data I can analyze after rocket flights. To me, there seems to be a lot of science and engineering built into the simulation but very little built into the game.

Micro-Engineer kind of does this, but not to the extent that you want.  It certainly doesn't give you after-the-fact output, but it cannhelp you with the up-front.  This is actually a really great idea, especially as far as new players are concerned.

1 hour ago, wnderer said:

I haven't played KSP2 and I don't know if this stuff could be done with mods. What I want are better design tools. Something like this.

I think there is too much trial and error. I want to design stages to have so much thrust, for so much time with a starting mass and ending mass. I want my stages to have so much acceleration above gravity and account for air resistance and want graphs and tables of data to help me work it all out. Adjusting how much fuel there is and how much thrust doesn't help unless I know how long it is going to burn. I want wind tunnel tests. I want to collect data I can analyze after rocket flights. To me, there seems to be a lot of science and engineering built into the simulation but very little built into the game.

As for game play, I think linked anomalies would be fun. You start with an artifact which gives you a clue of where to look on Kerbin. That anomaly tells you where to look for the next one and so on. Maybe there are keys you need to find that open artifacts to get Easter eggs about alien civilizations.

Or linked science. You build satellites to map the planet, that gives you maps you can look at. When you deliver it some scientist tells you more tests to setup and that leads to some Easter eggs that tell you about the evolution of the planet.

Another great idea.  I think this is where they were headed with the radio signal stuff on Mun, Minmus, Duna, and Tylo...but they never really got there.

[Skorj]

On 1/17/2025 at 3:15 PM, K^2 said:

1. Engine. Unity is just not a good fit in 2025. Lacking budget for something dedicated, Unreal is a much better foundation.
2. Rigid physics for crafts. Look, there's flex to real structures, but it's hard to simulate in a way that works. You're better off simulating the stress across a rigid structure. You'll still have failures of overstressed parts, but no flappy rockets.
3. Assembly building and part manager are a mess. This is less concrete - it just needs work. From setting up unit tests on saving/loading the craft so that the system isn't broken half the time, to the UI/UX side of things.

I think any team that consults with HarvesteR will get 2 sorted out.  Looked like he nailed it for KitHack.

3 was a mystery to me why it's so bad.  If we can abandon the "rooted tree" structure of crafts and just have parts stick together as needed, then sub-assemblies become easy and you just need a workspace where you can have multiple chunks of craft handy - like a probe bus and 3 probes - which you stick together for the final craft.  Just need some place on the screen that's clearly the "real" craft and everywhere else is an area to work with sub-assemblies (or "modules" as a better name).  I think it could be made very clear visually and still be far less clunky than KSP1's sub-assemblies.

7 hours ago, wnderer said:

As for game play, I think linked anomalies would be fun. You start with an artifact which gives you a clue of where to look on Kerbin. That anomaly tells you where to look for the next one and so on. Maybe there are keys you need to find that open artifacts to get Easter eggs about alien civilizations.

I would love to have an actual story or at least linked objectives (and also sandbox mode, of course).  I agree anomalies are are a good way to do it, with far more rich mechanics about satellites to find them,  building specific craft to go get them and so on.  I'd love to see caves so you have to drive a rover in, or an underwater one on Laythe.  Maybe a large alien base to discover and explore down into to get interstellar tech.

Anything to make missions more than just "do I have enough delta-V"!

[wnderer]

On 1/17/2025 at 4:15 PM, K^2 said:

1.  
2. Rigid physics for crafts. Look, there's flex to real structures, but it's hard to simulate in a way that works. You're better off simulating the stress across a rigid structure. You'll still have failures of overstressed parts, but no flappy rockets.

The first mod I added was KerbalJointReinforcement. Sometimes I think the developers spent too much time giggling. "Haha, Jello ships!". I think more struts are also a burden to simulation time and memory. I think hiding parts from the simulation behind shrouds would improve performance.  Ladders, parachutes, landing gear and other hidden stuff would add payload weight while reducing effective parts count for the actual simulation and give faster simulations and fewer crashes.

[PDCWolf]

11 minutes ago, wnderer said:

Sometimes I think the developers spent too much time giggling. "Haha, Jello ships!". I think more struts are also a burden to simulation time and memory.

Right on the later. As for the former, it's a vicious cycle:

1. You might want some sort of visual indicator that ship parts are under stress, and the thing bending is a very obvious one.
2. Cue in the early days of KSP, where parts on a rocket would "randomly" explode on ascent.
3. Turns out this was "le funny joint wobble xD" making parts crash into each other.
4. You still want the bending to happen because you've failed to build a system that shows part stresses yet.
5. Cue in middle of the road KSP where parts on the same craft cant crash with other parts of the same craft so they ghost into each other
6. Now you have a mess of most times unintuitive ghosting but hey, spaghetti looks funny on youtube videos!
7. Players don't like wet noodles for rockets, it's unrealistic, and struts are both unrealistic AND ugly.
8. Reinforce the joints, now rockets remain very rigid BUT the play between joints is still there, so you get compression ghosting (lower parts closer to engines ghosting into parts above).
9. Different size joints (say, a big part joined to a smaller part) become a very insidious problem too.
10. Cue in current KSP, with a bandaid fix such as autostrut (adds arbitrary joints between parts), rockets can be diamond rigid, but they internally use 3X more joints, becoming a performance hog.

It can't be fixed, it doesn't do its job properly, and requires unintuitive and sometimes buggy behavior to work... and now we're stuck with a solution that heavily degrades performance just to arrive at something as basic as rigidbodies being rigid. Further enough the lead creative for KSP2 was a clown and liked wet noodle rockets so we're stuck with the same garbage in the sequel too.

18 minutes ago, wnderer said:

 Ladders, parachutes, landing gear and other hidden stuff would add payload weight while reducing effective parts count for the actual simulation and give faster simulations and fewer crashes.

Those parts, most at least, are physics less. They're effectively infinitely rigid, some are not counted for aerodynamics calculations, but they have their own suit of problems, like how for some reason X amount of physicsless parts on a hybrid craft make the game less performant than giving those parts physics (not sure if this was ever fixed).

[boolybooly]

Off the top of my head, as I said elsewhere, two things I would like rejigged are the progression gameplay and coupled to that the tech tree.

My other hobby horse would be playing with the concept of the low g economy.

 

With progression I would like to start in a barn with a pile of rusty battered old farm silos for tankage or something like that. Something imaginative like having to buy in Kerbal govt surplus rocket engines then working your way up past renting launch time on a disused airfield leading up to bespoke private Co's  making engines and other parts for you and your own VAB and launch pad and R&D campus etc. It should be a struggle, currently its all too shiney and handed to you on a plate, too much too soon.

 

With the tech tree, I am biased by the 4X way of MoO but would like to direct science at fields of research , so engines, structure, electronics, aerodynamics, payloads, thermal. Something like that, so when I research an engine I get an engine, not a basketful of stuff. Liquid fuel designs on a different branch to  solid fuel. Guess I am a bit of a monotasker. 

Then each step in a branch may have its own requisite dependencies. So bigger solid rocket boosters and liquid fuel tanks might only be available after you research structure subfield of tensile strength to the point you can get struts. But then I would like to see a specific mission to research struts using prototype struts (which also has a strut tute option).

Then I would like to see research feeding back into existing parts e.g. struts become more drag efficient if you research aerodynamics for example. Tankage dry weight gets lower with tensile strength, i.e. parts improvements as a result of tech synergies.

Would also like to be able to design your own parts and then research them by doing test flights (with objectives) e.g. procedural engine bells, where shape effects isp but adds/removes weight, also procedural mixers change max thrust and isp efficiency but also engine heating. Then I want for the engine weight to bell size ratio to improve with tensile strength research along with max mixer size and for thermal build up and explosions to improve with  cooling efficiency which might be part of thermal branch, along with heat shields, radiators (also procedural) etc. Result being many combinations of tech producing custom parts and potentially an infinite tech tree by improving theoretical branches indefinitely, with diminishing but useful returns.

I want this kind of interactive tech web where you can change the parameters of your craft in game through research gameplay and have an incentive to test potentially unstable devices, with all necessary safety precautions, of course.

Would also like specific missions to provide research boosts to corresponding research options and be designed to be relevant as with the strut example. Another example could be thermal, see how fast you can go in the upper atmo and how hot you can get the test part, achieving a threshold means you get heat shield but also advance of theoretical cooling efficiency depends on how hot you get it. So that could be iterative, you might return to repeat the mission once you have got better cooling efficiency in the first mission, to improve the cooling efficiency of the new test craft allowing you to get the test part even hotter, without exploding it of course... or the ship.

Stuff like that.

 

Withe the low g economy, I wonder if they were thinking about this already but the orbital shipyard idea mooted for constructing interstellar craft also becomes a resource gateway to tie in the ore drilling gameplay. Some ideas about this are, that ore brought to a shipyard in orbit could be sold for cash and maybe the ore could be differentiated into say ice and metal. So ice could be less valuable than metal but either sold or refined to make fuel while metal could be refined if you have a metal refinery at your shipyard to make more valuable metals like steel and nickel which sell for more or can be used to defray costs of building large structures in orbit which would otherwise cost a lot of a lot more. So ice from Minmus, moderately productive metal ores on Mun and find the super dense asteroids for almost pure nickel iron ore, then see if you can build a refinery there and ship pure metals back to Kerbin orbit or even build a shipyard in the asteroid belt. 

 

[Dakitess]

I would just want KSP2 to be an up to date KSP1, technically and aesthetically speaking... And would already be happy with that.

But knowing that I am not looking for any kind of new gameplay, it would definitely need to be a 2023+ game, not an aged garbage that already runs bad and look horrible at its launch. We need a NEW REAL KSP, new core, new foundation, new engine, new code, new optimization, etc.

God, just give us a good and well developed KSP based on nowadays techs, plz, c'mon, that's all what matters the most, everything else can be build on top of that just like Mods did in the past. Better have an Exact KSP1 looking gorgeous and running well than a pile of nothing with new gameplay and weird decision. I know that a game should not rely on mod : that's why being a copy of KSP1 is already fine as long as we don't need any kind of graphics mod at first to make beautiful, not weird workaround to get it working right, playing more with Windows files and GPU libraries than Kerbals themselves. KSP1 was already feature complete to some extent : i'm surely biased since I play it 100% vanilla for 8000 hours, except for graphics mods, but c'mon, just don't aim for new things you won't be able to dev correctly without introducing tons of bugs, crippled perf, and so on.

Let's have a base new KSP game that will then evolve, enhance, grow with new content, new gameplay. Of course some things need to be thought at the begininning of dev, but not everything... And ditch MultiPlayer if 'its a major obstacle.

Edited yesterday at 09:56 AM by Dakitess