PDCWolf

And KSP2 doesn't, which is the point of the watering down and throwing away features argument.

Yes, and that easing-in is called tutorials, or going to sandbox and playing around with designs before career, or just starting your career over (which you can do with easier settings in KSP1 too).

You go back and load a previous save, or start over.

Oh no, I don't, it was about a month, in a copy of Orbiter I had to pay hours of time on a cybercafe for it to download. Sure, Orbiter allowed me to just restart the mission, but the consequence in that case was losing 8 minutes to multiple hours of missions, and I never managed to go interplanetary in that sim. Oh, and there were no tutorials, only a replay of a shuttle launch to look at and guess what was happening.

Yes. And it's fine to do so until proven otherwise. To not be completely confrontational though, I'll appeal to the puddle depth of "For Science!" as my main exhibit that "watering down" is what so far they've done. That's not even going into how what they have communicated so far is a watered down version of mods that already exist for the prequel, and they plan to do it on a flimsier, more limited foundation. COVID was 4 years ago, Star Theory died 5 years ago. Anyone still hanging onto that for anything has clearly ran out of options to justify what's always been unjustifiable. God forbid there's a semblance of consequence for being bad at a videogame.

You... can set that manually. If anything there were (and of course, still are and probably worse) very lax restrictions on re-entry survival, vehicle configuration and such. Making gigabuses to do like 50 tourists/rescues at a time came with no downsides. I disliked the kerbal xp grind, but I believe careers with proper bonuses (rather than arbitrary and dumb restrictions) could be very good to incentivize keeping kerbals alive rather than just hiring randos to pilot your septillion dollar flagship mission.

Well... check the news. Which news sell more and convince more people that they're the correct outlook on stuff that happens? positive or negative ones? At this point, save for like 5 people (which, listing in my head, are always the same), the subreddit in its entirety is convinced the game has been abandoned or left to a skeleton crew to harvest any possible sale. The climate on the "Some Improvements on the Way" thread is "KSP1 devs were better", "Blackrack is so good", "I hope they know about/fix this other bug", "They limited dV to your current vehicles capabilities because they have no idea what the people want from the game", "These posts need to be weekly", "Remember when these were weekly?", "Don't forget Dakota confirmed there's yet another patch before colonies, disappointing", "Devs must not be working full time". And before the obvious, beaten-to-a-pulp-horse comparison with Hello Games: They had already released Atlas Rises by this point, that's their third major update, and not just that, by the 15 months mark since release they were on the 8th patch for Atlas Rises. The "let actions speak" spiel doesn't work if there's no actions.

Loving the fixed engine effects, the concave pyramid was a sight for sore eyes knowing it was just wrong, also blackrack's clouds are gorgeous, hooray for both better looking and more realistic. Kerbin's atmosphere is barely more compact than ours in its first layers so I don't see why it wouldn't be more similar in looks rather than simpson's-ish clouds. Whilst I see the possibility of crashing into colonies and having them be destroyed like ships as definitely fun, I'm exceedingly worried about the mounting pressure on the serialization and non-active vessel simulation systems. Any reassurance we can get on that front that giving active physics to colonies is a worthy endeavour? are they the same physics as spacecrafts? any part # target for colonies? Also what about the font issue?

The last optimization for KSP1's loading was a GameDatabase system overhaul released in 2013 in version 0.20 . "Optimization" is not lineally correlated to time, it's not even guaranteed to happen as sometimes it's just not possible to make an algorithm better, or not worth it to pursue an overhaul/refactor under budgetary and practical limits. Don't sit out hoping for magic optimizations to come, specially when some very foundational systems can't really be optimized thanks to the way they have been designed. It's primitive because parent-child systems have been as old as... the need to sort data. In the case of KSP1 a part has nodes, and anything that attaches to those nodes is a child, save for the node that attaches to a previous part which is the parent part, all the way up to the root. In the case of surface nodes, they're an arbitrary node created at arbitrary coordinates where another branch of the tree spawns as a child, pointing to the surface attachment node of the new child part. Almost every engineering game uses this method because it's proven to work, it's fast to cycle through all the nodes, and you do not need to check for recursions in circular structures. As for alternatives, I can't just produce an answer because that goes beyond my skill level, but don't take that as "something different than tree based" but rather "let me use the 1 to 3 adapter, and then a 3 to 1 at the bottom without it not connecting 2 of the nodes." Currently, such a thing would mean that bottom adapter has 3 parents, something not possible as they're inheriting force, fuel flow, and other data from the parent part. It's also why the game dies when you dock vessels to themselves as it reconfigures the tree in real time. The PAW has to be one of the worst crimes against everything good in UI/UX design. "Let's make a UI that shows everything at the same time"... then they fond out it obviously lags the game to hell to load tooltips for all parts at the same time and that people are having a hard time finding something specific in a sea of parts that share the same names. The first is somewhat fixable... the other not so much, it's just one of those "we have to be different at any cost" things even if the cost is making an objectively worse feature. That and the amateur navball design/positioning.

Gotta agree to disagree then, that was a painful read. Whilst you're free to like what you like, I fail to agree on any of the things you like, and some other things are plainly not a matter of personal opinion, like not being able to read the fonts on the UI, or loading times, or "potential" and so on. For loading times, on a new and clean game, the loading speed difference between KSP1 and 2 is minimal. Sure, the initial load is faster, but at the end of the day, a game made 10 years ago loads a whole *checks notes* 15 seconds slower from startup to flight. And that's with KSP2 still being in its incomplete infancy. Potential does not define a foundation. Foundation is a word reserved for how well the codebase and the game systems are put together. If "what I believe this game can be" was a metric, then every game in development has infinite potential and thus the strongest foundation. That's just not how it works. In reality KSP2 has the same engine as the prequel, the same middleware for some features, but a much heavier save system, and also a much heavier inactive-vessel simulation. KSP2 will be thwarted by that in the future. It also still builds and saves vessels as a tree, it still calculates fuel flow mostly the same way (something something "inspiration" from the code of the previous game), it still handles the atmosphere like the previous game, but thanks to that passive simulation and bad saving system, vessels popping into range still kill your game, orbits change randomly, and the game grinds to a halt with vessels and partcounts much faster than the prequel, to the point systems (like heating) have to be "streamlined", and part-counts have to be hammered down with new, revolutionary "all in one" science modules, station modules, and in the future colony modules too... or having the logistics layer be abstracted to numbers instead of seeing your vessels come and go. Right now, saves are just a couple vessels for 99% of players, let alone making any vessel in the hundreds of parts for maybe the last couple missions, and most people play serially too (fully complete one mission before launching the next). So really, KSP2s limits haven't yet applied to most people and thus it's no wonder they really think the game is better off. When colonies and interstellar arrive, along with more resources to keep track of... it's gonna be a mess, yet devs refuse to address it and have let the bug report sit unattended, and only mentioned the problem once in the K.E.R.B. and that's... the opposite of potential. So yeah, you might slowly start to realize why people who talk highly of the foundation, potential, and what not don't seem completely grounded in reality to me, and why the lack of proper technical talk in devblogs is worrying. I don't care at all for how they failed to replicate eclipses, or how they had to tesselate a line to draw a circle, I care to know why we're still stuck on something as primitive as tree based vessels, and how they plan to deal with high part counts, or even something as basic as what their target is.

Well, then you aren't looking enough. Sure, those people don't post a lot anymore save for... one or two, but god if I didn't had to read people absolutely unloading on KSP1 to somehow justify the existence of KSP2 and how whatever we have now is better and provides a better foundation (even though it literally doesn't). I wish I hadn't read the literal opposite at least once.

And the proper codebase to support them rather than self-destroying after a couple thousand parts like KSP2 does and will do for the foreseeable future. After all, isn't "bad foundation" one of the complaints for KSP1? Then why'd KSP2 get a pass being made in the same engine and including a timebomb as big as their current unloaded vessel simulation and save serialization are? Oh right, because "wahh KSP1 was bad" is not an argument, it's a cope, and a double standard when KSP2 is part of the conversation.

Better engine, deeper simulations and features, life support, bigger planets, maybe different planets, better robotics with capacity to program routines or outright just write code for the game like kOS, a proper race to space type career, budgeting, literally anything that isn't just the first game with "better" graphics + 3 mods and thinking that's somehow ever gonna be worth $50.

They aren't cancelling because KSP is really the golden egg goose, that's why they're taking literally 0 risks and only selling us a coat of paint and the top 3 most popular mods of KSP1.

Great writeup, good to see more people being realistic about the absolute disaster this project is on all fronts. Yes, they've got a game that somewhat works now and has something to do in it provided you're not mind-numbed after the 3rd time clicking that flashing blue light trying to harvest some dopamine. Sadly, you really don't speak for everyone. Some people are happy this mess is what it is and will seclude themselves in positive-chambers to repeat to each other that if they can wait more, and enforce positivity, it'll all be fine.

At least you have something to do in them until that happens, and they're not so broken that a 4090 and a 12th gen i7 like the pcs at the media event chug when trying to run them. Me, and maybe 100 more people, and we're really stubborn about the game, so really our input is a drop in an ocean of... not caring about the game, or having walked away already.

The keen eyed quickly realized and tried to warn people that what they were showing were barely asset mounts, editor scenes, and pre-rendered stuff, and the stuff that wasn't was noticeably bad in performance, in a trailer. Warnings weren't heeded. That type of uninformed hype is also why people held a lot of hope that the next 4 delays would make the product nothing but better, and it's not like that wasn't exactly what the statements said again and again. Of course, all that hot air made release a thunderous failure. Star Theory's management is what survived the metamorphosis into Intercept Games, it's the same people behind this project. So has PD's management remained the same, and much more T2 (even though after thousands fired and 8 quarters of net loss that might change).

Well, the joint system should be the obvious example here. Then there's the hard 2.5km limit if you want any semblance of precision (and even then we get kraken attacks), basic rigidbody physics being a mess (hello wheels), the default multithreading is unusable, updating your project's unity version will probably break it, the garbage collector is probably still broken (causing random frame spikes at times), and just you wait till we get multiplayer, we're gonna make so many amazing, fun discoveries on that netcode! Also this isn't going specifically into the limitations of the middleware. There's definitely more, and a lot of it stems from being an engine made for the greenest of the green. It's an amazing engine but it's never been suited to big projects without severely limiting what they can do, and "spaceflight physics simulator with lots of simulated subsistems" is not a thing Unity is fit for.

Unity does come with a lot of features that are outright insufficient if you want to do a game like KSP. However, in reality, I'm 100% sure a custom engine runs contrary to what seems to be the very concept KSP2 is built upon: cash out fast by delivering a quick "modernization" of a very successful indie game. The franchise is made, the game is done, you can even reuse the off-the-shelf toolset like Unity and the same middleware, add 2 or 3 of the popular mods in a non committal way (Resources, Colonies, Multiplayer but no LS as to not force players to use any feature) and sit back to watch the cash flood in. Meanwhile the community wanted KSP2 to be almost entirely different and to wipe away the errors of the first one... how the turn tables.

After the brand damage that was firing Paul Furio, the engineering lead of a project that had just gone under the public eye, I doubt we'll know anything unless they actually axe the project, which doesn't seem to be the case. Imma link a more in-depth analysis that I agree with, and why I believe this project isn't affected. TL;DR they bought Gearbox but fired people they didn't need, on top of gearbox firing their own earlier this year. https://www.gamesindustry.biz/a-double-take-on-take-twos-layoffs-this-week-in-business

We're not waiting for 0.3 currently, the next expected patch is a fix pre-colonies. I do believe colonies will arrive faster than science, maybe july/august.

Wrong. By half of the year we knew: It was coming near the end of the year. It was gonna include "lots of fixes". It was going to be the first iteration of the heating system. A heating system we already had a devblog for and not "here's how I failed to make an eclipse". Some parts had been shown. The concept that parts were gonna be an all-in-one solution was explained. We were told the system was going to be incomplete, as it was going to be partly carved out by resources and colonies. Heating itself had not just a devblog, but 3 iterations of VFX demoed. Then after all that info, FS! was barely a remix of KSP1 in the end, and people got blindsided by a horrible surprised because they never showed proper gameplay up until like a month before release, kinda like how after 4 years the game changed from full release to barebones early access. THAT is why they don't have the community's trust. And we know lots of theory stuff about colonies already as well, allegedly, provided they don't go back on their previous words and we don't get another surprise like FS! where the boxes are checked but it is just bad.

Short of FS!, which did nothing but add new complaints and concerns for a lot of people, most feedback hasn't been addressed (addressed as in game changes, not words on a forum) for 14 months. It's no wonder every thread ends in the same spot. See, normally I'd absolutely buy a statement like this, and I applaud your effort whilst definitely not envying your position. Where we are now, this statement sounds like one more for the pile. Promptly hoping to be proven wrong.

Having played only 90 minutes of it, I had a blast and it was clear to me there's a lot of stuff he has learned from and made better. From simple details like center-of and node indicators not being spheres for extra precision, to internal views, a very deep controller interface config screen, and keeping what works and not making it different just because (looking at you VAB controls). Building is more detailed but not more cumbersome, physics are more detailed but without all the scary ghosts of scaring users away some here were seeing. In the grand scheme of things, sales numbers, reviews, community sentiment, KSP2 hasn't gotten a pass. It's only people here and on the discord that are ready to give it the pass because either they genuinely like it, or they really feel bad about having spent $50 on it or some other reason... This is what makes KSP wheels so whack, you're forced to either build a whole suspension system dealing with the wacky physics, or you'll have to use the single-piston, non-coordinated, default suspension, and at the speeds we work with in KSP, that just doesn't cut it, so it feels like you're skating on ice.

"one kerb in a month" is, at least logically, capable of resulting in 2 K.E.R.B.s spaced by ~60 days, provided one shows up the first day of month A, and the other at the end of month B. Funny coincidence? Thought that statement is probably just a way giving themselves some leeway, as it's technically correct so long as they release a K.E.R.B. before the 30/31st of X month. Some months the K.E.R.B. might come faster, in others they might have absolutely nothing until the very last day when there's no chance but to post what they have. It's laughable that we have to go to these extents to skirt around their non-statements and incapability of producing a periodic report.