Gydra54

I used to think these takes were mean unfounded speculation, but I have come to adopt the same opinion over time. I don't think anyone on the KSP2 dev team is a "bad dev" per say, I just don't think most of them are the right devs. You cannot make a KSP with normal game devs. You need someone that is highly skilled, highly creative, someone that can take real physics concepts and translate them, sometimes in very unintuitive ways, into something that works in a video game. If you pick the right people, you can probably make something significantly better than KSP1 with half the employees as IG. Take the clouds for example. Yes BlackRack had a few years modding head start on clouds, but the improvement was absolutely enormous. In the same amount of time KSP2 has been in development, BlackRack already had a far superior cloud and atmospherics solution, on their own. This is the impact of having "the right person." Honestly, seeing that default KSP atmospheric renderer in KSP2 gameplay videos was a massive red flag in hindsight. It feels more and more like IG was just apeing KSP1's solutions, and just trying to tweak them because they cannot come up with innovative solutions of their own, or are even unaware of pre-existing superior solutions in the modding community. Both are unfortunate possibilities. Obviously this is all speculative, there could be any number of things in IG hindering development, but I think this is definitely a factor. I can only hope by some miracle this all leads to a transfer to a different team that has better composition, but I doubt it.

It's perfect. I like normal KSP Mun, but more realistic planet designs has always been something I've been interested in.

Why not have procedural tanks but also have presets in the part picker. That way, new players and people that prefer building lego-like can still do that and completely ignore the procedural system, while those that do care can utilise it.

I wonder if anyone complaining about the navball position have tried it in KSP. I expected to agree that it should be in the middle, but after playing KSP1 with the Navball moved to the left it's actually not bad at all and I think I even prefer it. Honestly, the more I look at the new UI the more I think it actually makes a lot of sense. Not saying anyone is wrong in their preferences, but I would at least recommend trying out leftside Navball, or just waiting for KSP2 to come out and see how it is then. However, I do agree that they should 100% make the GUI customizable, as much as possible.

Wouldn't the whole "confusing new players" thing be solved by things like, a Tutorial, notifications about fuel/engine incompatibility, easily accessible in-game info, good UI design to make sorting and picking out different fuel types much much easier, progressively unlocking different fuel types in a "career" mode... etc. Like, initially I was also opposed to the idea, but it honestly doesn't seem that complicated to implement without being confusing. So long as it's much more clear than in KSP1, I don't see the issue. There's so many ways to do that. In fact, I just came up with another one: detect when the player mismatched fuel types and highlight the offending parts in red, with a nice little text box on the screen with a warning symbol exclaiming "Incorrect Fuel Type Tank/Engine!". Make the notification toggleable in the options for players who know what they're doing. Colour code Engines and Fuel Tanks based on resource in the part picker. Or give them a little icon. IDK, there's so many things you could do, I can't see this as necessarily turning off new players tbh. And this is coming from someone who always installs "LFO only" patches to mods using LH2!

Frankly, the fact that they have stated they will be making custom planets easier to create is already enough. RSS2 will be one of the first custom planet packs and it will be done incredibly quickly if the game actually delivers on in-built planet creation tools. Then Realism Overhaul 2 would come, and would again probably be even easier to make and put together if what the devs say about improved modding support is true. There is no point in spending dev time trying to put in an optional hardcore RSS mode that the vast majority of players wouldn't even realise exists or make use of, especially when modders will be very very quick to add it to the game regardless.

Nah, AT MOST a single early playable demo or something, but even that I don't really agree with. Let them develop the game and release it when ready. I don't care even if they have to delay to 2025, I am willing to wait for a proper game.

Nate mentioned that he has an interest in procedural parts, but did not comment beyond that. That is one thing I remember, but I tuned in last minute. I'll have to rewatch the interview from the beginning.

Clouds! We already knew but I'm so happy every time I see them. Also like the way the planets are styled, looks more "real" and finely detailed. Also I feel like we've heard this before(?), but Nate said release is Fiscal Year 2021, "sort of going into march" or something along those lines. Hmmm, might be stream compression as well screwing with it. But yeah I'm sure they'll improve.

I can't be the only one that's shuddering at the concept of latching onto a skyhook at interplanetary speeds... the window for hooking on and matching velocities would be absolutely abysmal, you'd have to perfectly line up and catch it in the span of what must be just a few seconds! No taking your time to cancel velocities and approach at really small speeds, if you're not careful, that thing is gonna drift away from you real quick. And if you don't catch it... off back into interplanetary space you go! Doesn't sound impossible, but certainly a very tense situation. I wish I could simulate this in KSP, sounds like a fun challenge. Not a programmer, but I think this could be implemented, it seems like it would have to be a very "special case" thing though with a unique solution. Maybe some very smart modders will implement it somehow. I see some talk about it moving at very fast speeds and "skipping past ships", but it seems to me like the intended purpose is to only interact with it at low speeds (<100m/s). Unless I'm missing something, there's no need for super accurate collision simulations in this case, any more than any other ship. If you for some reason rendezvous at ridiculous speeds and it goes straight through, how is that any different from any other hyperspeed rendezvous with other craft? There's no material I can think of that could withstand the G-forces from latching on at the speeds at which this would be a problem anyway. Basically, what I'm getting at, is that there's no need to simulate the entire skyhook at once at the same level of detail and at ridiculous accuracies. If you simplify it, the only real interaction seems to be with the "hook" itself, which you can treat as any other craft except with its own special case trajectory. There's also the cable, but you can make assumptions like assuming it will always be taut so that it's rigid. It doesn't seem that bad if you just simplify it to the things that acutally matter to player interaction. Just throwing out ideas, IDK, again I'm not a programmer, so maybe I'm just spouting nonsense.

A procedural part system with preset parts in the part selection menu would be ideal IMO, if they could make them as visually appealing as what we'd get with preset parts. I don't care either way though, I'm sure a procedural parts mod will be made eventually anyway.

No you didn't, don't be disingenuous. You made claims that Unity is a terrible game engine for KSP and that KSP2 will run into exactly the same performance issues, and you presented zero evidence for this other than the fact that your grandma can make a game using it (????). Obviously people are going to argue with you if you make bold claims with literally 0 evidence and a non-sequitur to back them up. If you don't want to start an argument, next time don't make confident assertions with no supporting evidence.

I don't get this. If I'm reading it right, OP is suggesting player-caused failure, not random part failure, which is what most "part failure" mods do (and that should absolutely stay in the modding community, random failure outside the player's control is terrible game design (EDIT: well not for some people I guess, otherwise there wouldn't be mods for it :P) and is not realistic as it is often claimed). I see no issue with part failure induced by player error. How is it any different from, say, failing to add struts and watching your rocket consequently wobble itself to its doom?

Yeah I used to be so scared of mods like FAR, thinking the realism would make it less fun. Turns out all it changed practically is my rockets actually have less drag (though slightly less stable) and doing 90 degree flips with big ships annihilates them. Like, is it really more intimidating than stock aerodynamics? I doubt newcomers would be scared off by it. If anything, watching your unstable rocket flip over and consequently disintegrate would surely make for good entertainment.

The only solution while keeping patched conics throughout most of the game is to have N-Body physics take over inside the binary system's sphere of influence as a specific special case. I can't understand how else they would do it without janky behaviour near the planets.

You're 100% correct, it is totally unrealistic. But then again, the planets in KSP are all ludicrously dense and evidently don't care much for real world limitations. That said, yeah it doesn't need to be as fast as escape velocity. I just want it fast enough that you are forced to use creative means to stay down on the equator (hooks or burning into the ground). Because if it's not that fast, although it would still challenge unsuspecting players when they try to match surface velocity 10km up only to realise that makes their orbit even higher, landing itself wouldn't require any kind of unique design solution compared to any other planet.

If they include anywhere near the same graphics options as KSP1, you won't have a problem tweaking graphics settings way down. Besides, it's not your GPU limiting your frames in KSP, it's your i3. Lots of physics-based calculations going on.

In general I would love more ship effects. Improved reentry effects, freezing, condensation, sound effects, dirt/dust effects etc. I want dirty, damaged re-entered craft! On topic, I want a retrograde planet, super eccentric comet/asteroid orbits, and a Planetoid rotating faster than its escape velocity, exactly like Inaccessible from Krag's Planet Factory/Sentar Expansion. And finally, I would really like to see a rogue planet in the game; somewhere away from or in-between all the star systems. No light, freezing cold. Would provide a challenge in terms of Solar Panels being useless and requiring lighting on your craft to see what you're doing. They should also disable ambient light boost on it specifically otherwise it's kind of pointless.

I think they mean that colonies don't slowly grow without you doing anything. So you even if you timewarp 100 years into the future, the colony will have the same population. The colony only grows when you supply more colonists or accomplish things in the game.

Major focus on modding, no DRM (for singleplayer at least), way more efficient simulation (high frames and high part counts), massive and vastly upgraded VAB, overhauled planet terrain and axial tilt support, rings with rocks in them, enhanced explosions... the more I read about this game, the more I feel like I'm gonna suddenly wake up and be disappointed it was all a dream... it honestly sounds too good to be true sometimes. I hope it can live up to the hype!

Seems we will be getting a gameplay demo. Wonder if its the same pre-alpha build we've seen or a much more recent one?

We shouldn't forget that we can build colonies on other planets along with launch sites. This means you can get axial tilt as a challenge in terms of affecting launches without having to change Kerbin's tilt.

Well, I guess that would be the point right? To be careful with fast movements. There is already a G-Force option available in KSP1, though I don't use it. I think it would make sense to have rotational g-force accounted for as well.

It's hard to think through something that clearly wasn't thought out well in the first place...

Well, hopefully they would provide you with information about the degree of axial tilt and relative inclination to the equator. That would solve that problem.