PDCWolf

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.