Profugo Barbatus

Why's it gotta be one or the other? Management screwed over the devs by forcing out the gate if they did so - but the devs screwed over management by struggling to contain their scope so well. In a perfect world, management would be responsible for keeping scope in line right from day one, but in a realistic world, the bean counters don't want to spend too much time diving into game design - they know its not what they're good at, so when the team says "Yea we think we can do it" a good management team trust the devs and lets 'em try. Success and Failure are shared across the space, most offices aren't like TV and funny internet stories where management slinks off from disaster to disaster leaving the team holding the bag. I've seen more leadership shuffled than dev team shuffled in my own career experience because good leadership goes to bat for a team, and tends to take the hit when push comes to shove.

Pushing to steam depots sucks, so either they're running a very robust CI right to steam, or much more likely they're already in Release Candidates for the first patch. That being said, they get a month or the first content patch before I start to really set expectations - first weeks will be a smorgasboard of random fixes entirely based on a mix of sense of priority, and whatever the devs happened to know how to 'quick fix' out the gate. The quality of the first content patch will be what defines it for me as it'll give a sense of what they feel is acceptable to release going forward - if the new bugs don't match the content scope, or if the content is being significantly prioritized over fixes, that'll raise some alarms. But if its reasonably balanced between fixes and new toys, for the first while at least, I'll be pretty optimistic. However, if the first major bug squashes take more than a month, I'll be pretty worried.

Right now, yes, I think this is what the patience deserves. Mostly because we only had two settings enabled at the same time - demanding the game to be 10x better than the prior game, at any cost, in every aspect, and also demanding the game come out ASAP let me play it right now dear god I can't wait. So naturally, the scope ballooned out, and there was a constant building pressure to give us something, anything at all. The scope expansion and associated delays would have also put management pressure to get out and get something. KSP2 was starting to threaten to look like a money pit from which nothing was coming. Lockdowns would have amplified this, cratering productivity for 2-6 months as teams suddenly learn a new way of working and coordinating, and team members develop techniques and spaces to properly focus while working at home. Eventually, it snapped, and the call was made that its gotta release by a drop dead date. This call was probably made too late for the team to prioritize away from building 'all the things' and shift over to "Ok we just need KSP1 functions". The sense of poor prioritization is from the people suddenly dropping colonies and modloaders and resource harvesting, to fix the VAB serializer, and implement science and heat and other stuff that simply wasn't a priority when the goal was "Finish the game". Which is why my litmus test of how much of a disaster this is will come from the first couple patches - both cadence, and focus. If they're relatively prompt (Measured in weeks, not months) up to the science release, then it indicates they were really just spread out and only had to focus on polish and the 'start' point very recently. If they're also of good quality and fix more issues than they introduce, then it reinforces the idea that they just didn't focus much on the quality at the time - it was 'good enough' implementation to support the other core pillars they were working on, so the assorted issues weren't as important as getting X working. We got what we wanted, a huge game super early in development, and its a disaster. I'm not gonna blame them for giving us what we wanted, I was out here with pitchforks last year in salt after the delay. I'll eat my crow here and move on. And if the upcoming patches aren't fixing things, are making it worse, then I'll start to be genuinely concerned. As it stands, all the disabled content and floating hooks I see in the game tell me there's a lot here, and they were just hacking things out in a panic to get it working for release, not that they haven't been doing anything all this time.

Its unknown if roles are returning and what they might look like, but its most definitely a bug for the game to eat your crew, that will assuredly be fixed.

The lighting is beautiful, I haven't had a single moment that had the slightly plastic toy feel that KSP1 can get when under significant lighting conditions. It runs great, admittedly on a beast of a rig but I haven't had any hiccups. Its one of the buggiest EA launches I've partaken of, but its also been the kinds of bugs that make me laugh, as opposed to constant nagging frustrations - Even the mission enders are funny situations. The new ship building feels good, UI gripes aside, and I'm already giving my workspaces 'family' name structures - So I can iterate and develop a really nice launch rocket, then save it, then develop a really nice mission lander, and then at some point in the future when there's a tech tree, I can upgrade the individual segments, and create mission specific variants as required. Its an absolutely incredible quality of life feature that I see no end of possibilities for.

S'pretty janky, but I've not encountered anything that's bad on a fundamental design level, just poor implementation and the usual expected bugs. SAS is pretty bad. Timewarp needs work, with the 'smart' behavior of timewarp to encounter not working when it goes to max timewarp, then starts slowing down at the encounter so that by the time it spools down I've already all but left the SOI. The new VAB is really nice, but the new UI constantly eats inputs and behaves in a relatively unintuitive way. I don't mean 'old muscle memory' but that things like 'centering the camera' centers the part in screen space, but the parts window means your actually offset significantly and it 'feels' wrong. Or how you can't drop parts blindly into the menu to 'clear hand' and have to drop them specifically in the little bin in the bottom, which might take a few clicks to register. Usual physics bugs too, coming out of timewarp caused my lander to ping off the surface and have a terminal encounter before I noticed, since I was watching my course. Watching my course was apparently pretty useless, because after landing, my lander refused to generate a trajectory path, so I was blindly eyeballing that encounter. Proud that I made it within 5km still, but issue persisted after a quickload. Definitely janky, but the reassuring part of all these issues (As much as 'its broke, jim' can be reassuring) is that none of these are insurmountable problems. Its a bunch of janky behavior, but its janky cuz of non-design issues, its not bad because it was built bad. Most of these issues here are just tuning, coding, and catching the kind of situations that only wider exposure brings out. The only thing I don't like, that has been brought up already and is a poor design decision, is the VAB Parts list and Part manager interface. They're good ideas, but why the hell are they so big. Its ok scale for a laptop user, and maybe the UI scaling just didn't make the EA cutoff, but on a 27 inch screen, it takes up 1/3rd of the part manager vertically to display the 3 options for a single engine, its ridiculous. With UI scaling it will be great, but right now its miserable. Same with the VAB Part list, give me a 'compact' option that just shrinks down the elements to half or quarter size. I'm still getting most of my info form the extended details pane anyway, so I don't need to see the part in super high detail to figure out "which one do I need". Edit: Oh, and let me rebind the Aerodynamic overlay please, F12 is the default steam screenshot key, and its a pain to screenshot twice just so the second one actually closes the popup.

I'd also really like to see it release the last control setting when I take over and start giving inputs, like in KSP1. "Up" is great for controlling descent speed for landing, but when I'm trying to tilt to now kill the remaining horizontal velocity, it comes in and keeps trying to hard pull me to 'up', so I'm fighting controls constantly. Since the only hotkey is "On/Off" I just have to give up on SAS in landing approach and wing it.

I popped a fairing and instead of poofing outward, it just went loose and sat on the front of the ship anyway. Disappeared after 30 seconds. I think the fact I manually jettisoned instead of staging it away may have done it, but manual jettison split fairings in KSP1 so I wasn't expecting it to go wonky.

Yes, heat's not quite ready yet, the launch patch notes specifically call out that they're still tuning it so its briefly disabled. For now, relish the fact that you can aerobrake anywhere, anytime.

Put a nice little stayputnik into orbit, way overestimated the D/V I needed - Is it just me or are these rockets more energy dense than what we used to have? Ended up in a 300km orbit before I even realized what I'd done. Gonna run an orbital docking over lunch to play around with manned craft too, saving a mun mission for the weekend.

Only thing that would come to mind is the USI Colonization WOLF stuff - In which you fly a route from a source biome to a destination biome, which consumes a certain amount of transport credit (Fuel/Pilot capacity) and provides a certain amount of payload, depending on how much cargo space you brought with you on the trip. Once you've established the route, its immutable, but you can change what's moved on the route freely. The interface was basically a list of capacity and current use tbh. I don't really have a good screenshot, but its nothing to write home about. I imagine KSP2 will be similar, you will have an established route, and you can simply assign resources to that route, or remove them. WOLF tracks everything in just arbitrary 'Capacity' for performance reasons, but KSP2 looks like its standardized resources around Tons, so I imagine you'll have a tonnage of capacity, not an arbitrary value. They might also skip it entirely, and just presume that if you can move the 'Cargo' module, you're set. Maybe capacity will come from colony buildings and not just running extra flights manually.

I've seen stupider settings left on/off in release copies of games that caused no shortage of trouble. Callisto Protocol basically tanked its launch reputation by forgetting a single engine level setting to precompile shaders. Forgetting about a physics checkbox because "there's more important things, that's easy so I'll fix it later I won't forget" happens all the time. I'm even guilty of it in my dayjob.

Because the expensive part of physics calculations is resolving collisions, not existing/moving without collisions. Colliders are hella expensive, and parts wobbling into each other would basically stack a collision every physics frame. That being said, fuel/resource drain is certainly a potential candidate. Collisions shouldn't be that expensive, and the new resource system for drains and faucets is new - wouldn't be surprising for it to recreate old bugs, if in novel new ways.

Remember the ultimate goal of colonies, from their design perspective. Colonies are an incentive to explore additional worlds, to find resources and fly additional, potentially complicated missions between them. The reward for pursuing colonies is new launch sites for your ships, provided you established a supply of materials. Those new ships then make it easier to explore distant worlds and colonize them to repeat the process. They are not the end-state of the desired game loop, they are a step in service of "launch more rockets to new places". Their complexity will match that desired state. If colony management becomes more complex and involved than exploring the universe, it ends up detracting from that design goal, forcing players to invest more time into that aspect as opposed to the one that Intercept wants to promote. As I said, I guarantee the modders will go full ham on exploiting the paper full potential of colonies, complicated production and all. But while colonies are a primary feature and goal for some of us, myself included, rockets and spaceflight are the primary goal of Intercept. Colonies and resource exploitation are in service of that.

I ended up upgrading my PSU and GPU for Dead Space Remake just a few weeks back, if that hadn't done it then this would have. It was due for an upgrade anyway, with my hobbies I already need a beefy rig. Autocad and game dev ain't the best on stale hardware.

I'm fairly confident that the KSP2 vanilla production chain will be simple. Colonies will probably have rudimentary life support (Gardens/Farms, etc), rudimentary resource needs and production, and the chain will be fairly simple. Expect Ore -> Metals and Minerals -> Fuel for the relevant fuel chain in a bespoke building, with a handful of each. Fancy production chains will almost assuredly lie in the world of modding, where someone will create a hardcore community resource pack to challenge factorio, with you sending scanning ships out to find Chromium ore to acquire chromium to go with your Vanadium and Iron and Carbon to create high strength steel alloys, to be used alongside your simple microcircuits, complex CPU's, mechanical bearings, electrical motors, aerospace aluminium, and Silica glass to create a MK1 lander can.

I'm excited to actually colonize the worlds, to have a reason to travel to them beyond "That looks cool", to build cities in the stars and across their surfaces.

I'm not sure why so many people are still confused/hung up around the liquid fuel rebrand. They wanted to give it a real name to ground it in a bit of science, methalox is a known option for widespread simple ISRU (IE, Tier 1 colony fuel production), is decently performant, and doesn't step on the toes of Liquid Hydrogen, which is what your RS-25 would be running off of IRL anyway. Oil derived fuels like Kerosene aren't a great idea for a 'baseline' engine what with them trying to stick to general principles of availability. Its all a game of 'close enough' while being simple enough for all skill levels of rocket surgeons. I'm sure Intercept trusts modders to put every fuel under the sun in the game inside of the first month, for those of us who want every little detail to be perfect.

Bingo. I don't really like it. I also don't really hate it. All I really got to say is "Its not the choice I would have made" and that's about it. They clearly have a mental image for the tone the game communicates to the player in, between this, the part description text, the end mission window, etc. I'm pretty sure anyone who finds the tutorials annoying will do what people have been trained to do for a decade now, search youtube for "KSP2 Tutorial moon landing" and go on their merry way.

I started playing KSP like a week before the Mun was introduced. I've seen the grand jank, lol. I guess this is part of why I'm both disappointed and optimistic about the game - I want the features, but I also really like the foundations I've seen. We didn't get reentry heat until after we got a solar system. Used to travel to the mun without solar panels, didn't need electricity. We've come a long way, and I'll make the climb again.

Bingo. I'm playing on a modestly modded install, no graphics mods and some content mods. Despite running on an i9-9900k, 32gb ram, M.2 drive and a 4080 gpu, opening the VAB is a "tab out and wait for the music" moment, launching a craft requires me to wait 10-15 seconds for the physics to settle down a bit. And god forbid I hover a complex assembly over something that was made radial, and the game decides to give me 2fps for 30 seconds until it registers my mouse is no longer there and it should stop making 6 clones of it. I'll gladly take the graphics upgrades and mechanics upgrades we've been given to not have the game freak out every time I open the VAB, and I'll happily deal with a few framerate hiccups in an early access product to not fight bugs from mods battling the inherent limits of KSP1. I basically rage quit for a day from losing a days worth of gameplay because USI life support bugged out and forgot it had any hab time left, which turned my colonists who were in training into tourists, and then broke and didn't turn them back when they were recovered, leaving me stuck with 8 tourists I couldn't do anything with and none of my needed people for colonization. That very nearly made me abandon the save, with the salt I had, and was only saved by a well timed manual quicksave 100 game days earlier. KSP1 mods are pretty amazing, but they are janky as Kraken soup, and I really think we have to step back and recognize that the game is built for its fans, but us heavily modded people still playing the game hard to this day are the upper percent of the 1% of the audience - Our expectations are far from representative of the experience and actions of the average player. Your average player isn't dealing with compatibility between graphics mods, or putting up with scatterer making landings harder for them. They were never running Near Future Propulsion, or running 800 part grand tour ships. Us wildcards are basically the living walking examples of the worst things KSP2 will be subjected to, and the designers can only do so much to accommodate our insanity. They've already given us a promise of stabling integrating the largest, most impactful mods both mechanically and visually. We have vastly improved scatter - Not full Scatterer, but its still vastly improved. We have vastly improved planets - Its not Parallax, but its still vastly better. We have a vastly extended parts tree - Its actually already confirmed to be at least as deep as Near Future, and probably Far Future, so full points there. We have vastly expanded colonization - Sorry USI/WOLF, but you never stood a chance in KSP1. We have vastly expanded travel targets - Kopernicus gave us new worlds, and now we're getting them base. We have vastly expanded multiplayer capability - Mods did exist for these, but I suspect they were not very good just by virtue of the limits of KSP1. And that's all without bringing in KSP2 modding. Its impressive enough that KSP2 is not just a pure knockout defeat out against KSP1 Modded in comparison. I guarantee you that as modding opens up, the teams responsible for those leading edges in KSP1 will either create or inspire successor mods that continue to push that edge. But the fact they can do that doesn't take away from the impressiveness or the achievement of the KSP2 team in making this version of the game, as it stands today. The fact you can get beautiful individual results atop a janky core for lower specs does not invalidate this more stable core or its demands.

If only it were so easy - Multithreading of programs is practically a science all of its own. Separating off-screen, non-dependent elements like unloaded vessel resource utilization and such is relatively easy. Spreading active gameplay load over cores is a huge burden, and can actively be significantly performance detrimental if the separated loads aren't 'big enough' to make the extra overhead worthwhile. Its also a problem when a program is wired to the gills for an expected number of cores, and it doesn't have them, so you'll usually find that programs well optimized to multithread still cap out between 2-4 threads. More than that can cause serious problems to the normal folks running 4 and 8 core systems (Even if it only uses 4, other programs are running, and threads need to be available for them) which is the console and home computer lower average. The fact that part support is even limited at launch has me concerned. Its basically an open statement that mod support is functionally non-existent out the gate, which is disappointing. Its understandable that its not a priority, but its less understandable how it hasn't been developed ground up to support even just parts and params being dropped in freely like that. We will have to see what expanded support actually looks like in practice, but considering it was a shortfall worthy enough of being called out in release notes, I'm going to assume its falling on the bad side, as opposed to 'recreate any system kind that already exists'.

I thought he already iterated that he was recording videos in KSP1 for this week to hype up to release in that youtube short he did. The prior community manager mentions was that they could reveal gameplay from the event, not implying they had early copies of the game yet. I'd temper expectations for anyone to give us anything that wasn't event recorded.

Excuse me, that's completely misrepresentative. Its a simulation of a stellar cloud, not a solar system. Way more bodies and interactions, way more floating point math to keep track of, way more space for me to fill with lost kerbals that need to be tracked. /s But really, I get everyone being a bit salty about this, but as I said earlier, their min spec is half decade old hardware. That's not in the slightest way unrealistic, even disregarding the particularly high level of power required to run a robust simulation of any kind, much less what is functionally multiple simulations stacked atop each other, capable of being accelerated to compute at speeds at a minimum 100,000x the real time level. More, probably, Interstellar probably will have an extra tick on the time warp. That is not easy to do anything at that level, and we need it as a basic game fundamental. Then throw in the inevitable asset chaos of loading a massive colony while a player suicide burns on a fusion drive with a large vesse towards a rapidly loading in planetary surface, while running physics, resistance and heat numbers and occlusion across the entire vessel, without the game breaking on a fundamental level. And it just so happens a lot of physics and simulation loads are actually excellent work cases for operating on a GPU, which is designed for mass simple mathematical calculations in parallel. By comparison, rendering graphics atop a relatively constrained simulation like firing stat sticks at each other in cyberpunk is a fairly modest ask. There is far more in the equation that sheer visual spectacle. Were it so easy to make the simulation half of anything run performant, my game dev hobby would be making me a millionaire right now.

Oof, thems some big numbers. Glad I upgraded to a 4080 back before Dead Space Remake came out, I'll need it here. 32gb ram and i9-9900k, should be able to crank it still. I'm not surprised its this high - I guarantee you the plan is a lot of DLC for a long time on KSP2, with a lot of supporting content features. Take2 sees a chance to monetize a very enthusiastic, if smaller, audience base similar to the flight sim crowd. So they're probably assuming that over the lifecycle of the game, this will become fairly normal. Still, ripf to everyone rolling some old silicon. I'll put something shiny (but appropriately low res) on the mun in your honor. Edit: I will amend to this that the 20 series is almost 5 years old, and the 10 series are almost 7. That's an eternity in computer hardware.