MarcAbaddon

I think there are substantial hints that you indeed need to collect exotic resources from specific other bodies instead of just collecting generic resources. With automated delivery runs and no money just collecting generic resources at each colony adds very little to the game, since you could just ship everything you need there (as long as it can be gotten from Kerbin, the Mun or Minmus). You already mentioned Helium on the moon, but that could include Helium-3. Metallic Hydrogen which was mentioned early on as a possible engine tech, might be something you get from gas planets (though realistically speaking the extraction would be a challenge). It could easily be something in the middle where each of the rarer resources can be mined from multiple locations, but where you still need to do to at least one of them.

Whether the progress in those patches was sufficient to warrant faith is of course open to discussion. But thankfully there is very little need for faith at this point in relation to the Science Update that is the main topic of discussion here. If you already bought the game, it doesn't really cost you much to check out the science update. If not, then you can wait until you see some videos and discussions on it. Either way, you'll see what you'll get without having too invest much in it. Faith is only required if you want to buy the game now for the end-of-roadmap features such as Multiplayer and Interstellar. Which personally I would advise against, unless science manages to impress a good many people.

Maybe light is just faster in the KSP Universe? Anyway, with it using Newtonian physics (simplified in terms of Gravity) there's nothing magical about speed of light in-game anyway. I don't think signal delay is really a critical thing for the game to have.

As with all these kind of requests it's possible but putting a decently detailed Solar System into the game is a huge effort which I feel the dev team could much better spend on new bodies, especially as it does not fit sizewise or thematically into the rest of the game.

While infinite electricity is without a doubt I find the entire discussion of it in terms of docking baffling. Even if I dock on the dark side of the body I can't think of the last time I ran out of power on either vessel in the process. I had some massive space stations which I did not want to rotate due to fragility, that is the only real issue I ever had where I could not use it. So with electricity not really being constraint, why harp on that one cheat so much? In >95% of situations it makes no difference at all. I think it's an issue that one of the classic docking maneuvers leads to bugs, and it's not a trivial one.

I already did my 10, but I remembered one other item I would have at the top... the new trajectory preview is neat in principle with accounting for burn time, but I think it needs an update to better handle orientation. For example, if I am in a low orbit with something like an ion-power craft with slow burning, if I want to 10 minute prograde burn I do not want to burn 10 minutes into the direction that is prograde at the start of the burn (you can actually deorbit like that), I want to burn 10 minutes while keeping the craft pointed prograde. As a corollary I think we really need some basic rotation support in timewarp. Long-term I would really like the game to be handle Expanse like constant-burn trajectory for fast transits, and then we need a maneuver planner who supports that.

Precise maneuver like interface with circularization and turning orbit up and down SCANSAT functionality. It's great from gameplay as it both supports what you do normally and offers gameplay challenging by needing to be in a more or less precise polar orbit with some power consumption for the scanners More engaging science system Alarm clock system with integrated transfer window planner Have AI controlled civilian flights and bases as the game progresses. Not a fully agency, just some independent rockets. Can make for exciting rescue missions. And it would be cool to find annother rocket in Duna orbit (on repeat missions, so you should still get the feeling of being the first one to get there) Some very simple autopilot functionality, only for flights you already did yourself in the past A gameplay mechanism that encourages but not force you to use as simple a rocket as possible, just as funds did in KSP 1 Not flippy, stable rovers Rover auto-driving Comets

As some others say it depends on the details. Just having more parts to add and click doesn't make the game better. Just look at KSP 1: you could have combined the barometer and the thermometer and nothing of value would have been lost, since they have exactly the same mechanics. Likewise, the mystery goo and the material science bay mainly differ in that the science bay has more volume and weight. But what could easily have been done is 'integrating' the goo into the science bay, so that the science can completely replace it. I would rather have more depth to the system. Have different multipliers and biome differentiation for the different parts . For example, what exactly would you gain from using a barometer in the 5th vacuum biome on the same body? Have some measurement take a longer amount of time. Require certain conditions for others, like needing to be in free fall or moving through the atmosphere. So depth >= number of parts. But no mini games please.

It would be good to have a true rationale for space stations, so I am hoping that science lab can also be built in space. And I think a mining vessel that lands and picks up ore for processing should also be a thing in KSP 2, even if colonies are in. Preferably the advantage of colonies should be automatization and offworld launchpads. Otherwise, I think everyone should be doable without colonies, just not quite as smoothly.

I have also tried the new version after I think last playing 0.1.2 and have to agree that it has improved a bit. My standard test of where KSP 2 is now at is to do a fairly simple Mun Landing mission with an overengineered rocket (close to 8k dv) to make it simple on myself. In the previous version I ran into game-breaking bugs each time, this time I was able to complete the mission without having to reload and with a fairly stable framerate. That's a good thing, and I hope the science update will start with a higher quality than 0.1.0 did. There were still some issues I ran into, I assume all of them will be well-known to people having played the game, but if not let me know and I can do a bug report. On first launch I didn't get any sound effects (for the rockets), just background music. Revert and relaunch fixed this. When staging I often had to press space twice to make it happen - I am sort of assuming this is due to me having deleted some empty stages in the VAB, but them still being active and staged through in flight? When I landed back on Kerbin, the ground was flickering strangely around my rocket.

I did in the first Early Access version. There were some things, but nothing that was even close to fully implemented. Some rudimentary code for delivery routes, some science stuff, some multiplayer stuff that seemed like they did just include basic unity lobby code, some minor references to colony founding as a part module. Admittedly there is some code related for modding in the future. But feature complete? Not by a far stretch. If anything the posts by Nertea show how much they are in the design phase on basic features.

I wouldn't want a hard limit on length that is simply artificially enforced by the game but not reflected by in-game physics. That'll place too many constraints on creativity. Doesn't mean there shouldn't be structural limitations on it in practice, just that should be ways around it with proper construction.

I agree with this take, but I also feel that if you decide to go with 1 from the start you shouldn't make claims about how you are going to or at least trying to slay the kraken. Another problem I have here is that I feel that it's something that should been tackled earlier in the Dev process. It's one of those central things you have to plan around early when you make another KSP using Unity physics. It'd be one thing if they tried a solution early on and it turned out a dead end, but it seems they are talking conceptually. Which again, seems a bit late.

I agree that there should be a lot of room for optimization here - in fact, I am surprised the impact is currently as high as it is since there is no heating at the moment & if the engines are off there is no resource usage either. It seems like you'd have to work at it to make the slow-down as large as what we currently observe, which is why people assumed it was due to running physics. Something must be very inefficient in the current implementation. This is another blow against the 'colonies and interstellar were almost completely implemented before forced EA' theory that sometimes floats about, as this behavior would make those almost untestable. On this bug about time warp orientation: I was assuming this is intended behavior or at least known behavior, so it is strange for me to see that it under investigating. But maybe it means investigating to see if it can be improved? It should definitely not be investigation about whether it exists! If it is a bug I would also like to note that thrust under time warp has other issues: for example it behaves incorrectly when thrust is not in line with center of mass by not sending your craft spinning. See my old post here: I think there is a fundamental issue to solve here, in that thrust under time warp won't work at all with the current system when you need to rotate the craft, as then you would need the entire physics for the craft to run.

Just my 5 cent, but showing that tool with a bit of explaining text and a few pictures would likely be much more informative than this talk was, which just repeated points that were made in the past. And it would be a more convincing demonstration that there is progress and not just talk - the issue with these talks is that people (rightfully or not, different discussion) feel that past communication hasn't bee reliable.

Personally I think science update will show if there's a chance to turn it about. The patches since release so far haven't been sufficient to make me more optimistic, if anything it was the other way around. The science update will show whether this was because the larger part of the team was busy getting science done well or whether the patches show that there are structural issues that prevent them from making progress at a decent speed.

I doubt that's true and I had a look at the code myself back then. There are some things about colonies (mainly delivery routes) in, but I wouldn't call it mostly complete. The multiplayer stuff was mostly standard lobby stuff, nothing super specific. From the latest sets of Nertea it seems there is quite a lot of work left to do on colonies. The state of the non-implemented features is one of the largest unknowns at the moment for me, and it's one of the reasons why some people don't have a lot of trust left, since there were interviews where the devs stated the new features were done and now it was just about putting them all together... On a different note Take Two remains the company who has the final say. Even if you trust the original team, as long as you think Take Two is completely untrustworthy there's no reason to be very optimistic.

Strong disagree with this - the reduced scale was one of the best and most important design choices of KSP 1. As Periple mentions, few players want to spend 10 minutes every single time just to fly a rocket into orbit. Or to take a few hours to get to certain parts of the planets even when flying at Mach 3. Sure, I have played with the real solar system mod too, and it is a nice additional way to play the game. But the reduced scale is a much better fit for the main game. Also - I don't really get the feelings things are super small. Maybe because Kerbals small too and I tend to compare to them?

I agree with the first part mainly because IG/PD has to deliver everything in the most positive way positive for them, since the team has a vested interest in success and the game is (in the public's eyes at least) in a bad shape. For that reason, I am not interest personally in communication like "velocity is good" or "morale remains high" or "the publisher is really committed", but details about how features will work are always welcome. I think some skepticism about good news is warranted at the point, since the team overpromised in the past. Jumping to calling them liars would definitely be too much, at least without evidence arguments. But in the end I think at this point people aren't waiting so much for news, but for actual progress and features. Releasing a buggy KSP 2 without substantial new features/gameplay goals than KSP 1 was a huge mistake. KSP 1 may have been buggy at the start, but it could easily be forgiven since it offered something new. Had we gotten the same bugs but with colonies then the reception would have been more positive. The issue is of course is that there is room for a lot skepticism about how far along those features actually are, with people either assuming they haven't started or that they are almost finished implementing them in a separate branch. As always it'll be somewhere in between but the last post by Nertea (e.g. supply routes) seemed to indicate to me that there's a lot of design work yet to do, let alone implementation.

That's criticism doesn't feel convincing to me. To put it in generic terms, someone made the argument A and you reply with oh, but it could also been a1, a2 or a3... so why do you jump to A? But your a1, a2 and a3 are special cases of A. For example, 'lack of experienced talent' is just an example of something 'seriously wrong with how they are doing things', unless maybe you think talent retainment and effective hiring is somehow not part of the wider team's job.

Don't believe you can say that for sure. Given that the shape the game is in and the fact that's they are working for the publishers, they just have a strong incentive for being polite and positive at the moment. Is there still genuine niceness and positive feelings behind it? I don't think we are in a place to tell.

As mentioned previously: there is a lot to criticize about Unity's decision. And it was a terrible stupid decision to go after installs instead of purchases. But on purchases the 0.2$ charge would be entirely reasonable, especially if it goes into engine development. But the insider trading thing regarding the CEO is silly. We are talking about 80k $ in shares from someone in a position where sales have to be pre-registered. If anything look at the investors and not the CEO for this move. The CEO (even though he behaved terribly in the past) has been in charge for a long time.

Not much - but the Unity charge is really the least problem here. It's not even on the same order of magnitude as the other items.

I do have concerns about the change, especially the practicality, but it still seems to be cheaper than using UE, so I am not sure why people want to move to that? Until now Unity had no pricing that scaled in any way with game success unlike Unreal which takes a flat 5%. For the maximum charge of 0.2$ being equal to 5% you would need to sell a lot of copies at 4$ each. Only real issue really is using installs instead of sales. Tracking installs seems like a way to get around certain platforms potentially underreporting sales? But there seems to be a really tight rope to walk between collecting excessive information and run afoul of GDPR or having insufficient data to be able to really confirm that the installs are valid new installations.

I don't believe that the way KSP is designed that the size reduction makes the gamer easier. Sure, if you keep everything else the same, then using true scale sizes would increase dV requirement and make the game harder. But the engines and fuel tanks are all nerfed compared to real world parts, which offsets the effects of the size tweak. Lower stages real world engines have much higher thrust, upper stages have more ISP, fuel tanks have less dry weight, etc. With real world performances a single-stage-to-orbit rocket with a large payload would be very trivial in KSP.