K^2

I think it's been confirmed that they aren't planned for the initial release version, so it won't be any time soon if ever. Modders have been making good progress, though, so I suspect something like Infernal Robotics will pop up soon enough.

A lot of games send usage metrics these days. It's typically very sterile information to do with game's performance, any error states, etc. A game like KSP2 might send things like craft configurations as well and some flight statistics. And this can generate a lot of noise if it's cranked to 11. We've had some multiplayer games where we had more telemetry than gameplay packets sent when everything was enabled. I would say this is not at all unusual or unreasonable for a game in the early access, since part of the goal here is to collect some data about the game's stability and performance to improve on it, but also, I really wish companies would be front and center with notification that the game will be doing this, and preferably a tick-box to disable it presented on first start of the game and later accessible through menus, and not just doing this by default because EULA says they can. I think, most of us would allow the game to collect this kind of data, but transparency would go a long way here. P.S. If the network noise is causing problems to your network, it's usually fairly straight forward to just block the traffic, and most games will work just fine. They might still try to send the data, but it won't get beyond your own computer, so it's typically not a significant impact on performance, and won't suffocate your internet bandwidth. Good to know that this is, indeed, the case for KSP2, as @paintsincode indicated. A checkbox in the game would still be a better solution, of course. That way it doesn't have to interfere with something like LAN multiplayer in the future.

There's a lot of confusion in there on the scales of objects involved. You seem to be jumping between jets produced by a stellar remnant black hole to the ones spewed out by active galactic nuclei, which are millions to billions of times more massive. These jets are primarily hydrogen, because that's still the main element, not helium. And density is nowhere near sufficient for nucleosynthesis. If these clouds get sufficiently large and sufficiently cold to condense into stars, yeah, these will fuse hydrogen and potentially helium into heavier elements. But that's just your conventional stellar fusion. At that point, it's not really just an end point of an active jet, but rather a young star cluster, typically orbiting the galaxy that spit it out, and will typically merge back into that galaxy. It is one of the ways new stars can be added. It's still not the main one, though. Most of the time, the star systems like Sol are born from a supernova directly. The shockwave is rich in heavy elements, many of which can only be produced in a supernova event in the relevant quantities. The shock acts as a nucleation site in the interstellar medium, resulting in a formation of multiple protostars. These are going to be seeded with some heavy elements from the supernova remnant, but will also pick up a lot of fresh hydrogen, which is very much needed to give you more new stars.

This just clued me in that I can use custom paint scheme with procedural tubes in KSP2 to add accent color strips to any of my rockets, even where I don't need stack separation, and while that was probably not the main intent of this thread, I thank you nonetheless.

I have been able to climb to 40km on Jool. The density at that altitude is below that of Kerbin at 10km, so it should be possible to climb at least that high on Kerbin with the same design. Here is a video, but mind the minor spoilers for Jool. Same general idea, though. Large cages to keep the blades from flying off. I did end up going with a pair of them, which might be unnecessary, but it was easier to build something symmetrical like that for me. The limiting factor is still the centrifugal stress on the blades/cage. The lift force is roughly proportional to drag despite pressure variations, so in theory, as the atmo gets thinner, all you have to do is spin faster to maintain the same lift, and since the reaction wheels provide constant torque, your craft can spin as fast as necessary. Of course, until it simply fails from stress. A better cage design ought to be able to handle more stress, and consequently, allow for faster rotation and higher ceilng. I don't know if this is of any use on Kerbin, but I'm trying to figure out how to build a multi-rotor carrier for an ascent rocket. That should make return missions from Eve and Jool possible. So naturally, I'm trying to gain as much altitude as possible in both of these cases. Jool's atmosphere is not so bad, actually, due to low density, and the surface gravity is low, but escape velocity means that even if you don't have to fight against the atmosphere, the return rocket has to be quite beefy, and that means a big rotorcraft carrier...

I think it's the right call overall, but it needs work. First of all, it obviously needs to be responsive. I don't know what the current code is doing, but that ain't it. Even if you have to rebuild the parts list, you shouldn't need several seconds to walk a tree of fewer than a billion parts. Secondly, it needs to be easier to actually navigate, and maybe keep some parts pinned, similar to the old system, or maybe have a favorites section there? Just some way of not having to hunt for everything all the time. But I do believe in the concept and that it can be better than what we used to have.

Usually, devs don't need the kind of infra that this takes. But if PD invested in their own launcher, they might have invested in the storage and the rest of the backend for rolling out patches as well. An example of a game where it makes sense and is used heavily is Warframe. When you DL it from Steam, you get the most recent baseline, and then the launcher will get the patches directly from Digital Extreme's servers. It's actually pretty good about collecting the diffs you need, and doing it as a single patch, even if you're several behind. For a live service multiplayer game that already has to juggle a ton of storage, where you want everyone to be playing on exactly the same version, and where you might roll out fixes quite often, because, again, multiplayer live service, you kind of want a more direct management of how your patching is handled than Steam provides. For a game like KSP2, as a one-off, it makes zero sense not to just do everything through Steam. But then you don't really need your own launcher, either. Once you have a launcher, and you're using it for a number of games, and you have the funding of T2, and especially if you can borrow some technical backend talent that got their battle scars making Social Club work, well, then maybe you can build your own patching backend and get some convenience out of it. Again, not saying this will be the case with KSP2 now or in the future, but PD fits the profile of a publisher that might, so I don't want people to have the wrong kind of expectations. Personally, I would much prefer for it to be handled through steam, in which case I can create a shortcut directly to the game, and never have to worry about the launcher. Just like I did with the first KSP once the launcher got introduced.

Some games only do the updates through the launcher. I hope that's not going to be the case, because otherwise, the game runs just fine without it.

For both the Steam and Epic Games Store releases, the patch should apply automatically. It will either be downloaded by the Steam/EGS launcher, or the game's own launcher. That specific bit can vary a bit from game to game, but in pretty much any case, it will either happen in the background, or will have to happen before you can play the game. Generally, you have to wait for a patch-to-a-patch or for the Intercept to roll things back, depending on how severe things are. You can, technically, copy the game's folder somewhere before patching, so prior to this Thursday, to have as a backup, then you can launch KSP2_x64.exe directly from that folder. That should bypass the patching and let you run an older version. It works for me on Steam version and I think it should work with the EGS version as well. However, there can be incompatibilities with the save games or some additional server version checks that would render the old version inoperable - it's unlikely, but it can happen with some games. So if you're really worried, you do have this backup option, but in most cases, if there's a severe bug with a patch, the studio releasing the game will either fix it quickly or roll back the update for everyone.

If that was the case, then you would never get anything but a few bug fixes post-release. Corps aren't going to work for free. The improvements are inherent in the promise of the early access - that's the whole point. If you don't trust the company to make the game better, you should not be buying early access. And if you do, then let the company work. Again, that's the entire premise of the early access. I completely understand the situation with some games where the trust erodes over time, but Intercept haven't even had the time to release their first patch yet, which is coming on precisely the kind of schedule that it was expected. (Two week development sprint + a week of testing.) If you have less trust in Intercept after that patch, some of the complaints might make sense. Right now, it's just silly.

I don't recall if this is one of the docking mode bugs - if so, hitting del should fix it. Otherwise, restarting the client does. There's a bug with revert to VAB that puts the game into a broken state and will prevent launch and can stop you from saving. Avoid it. Use the fact that the game allows you to quick-save anywhere and keeps previous quick saves and use save/load instead of reverting. It's a bit of a drag, but not that significant of a time lost compared to reverting to VAB. All of the problems you've encountered are well known in the community, and if you actually have been keeping up with early access games recently, you should know that checking fixes for common problems is a sort of thing that always makes your experience with these better. There are a lot of reasonable complaints about how this game launched, but this thread is mostly full of complaints that shouldn't exist to an earlly-access title. It's rough and requires workarounds. That's what early access should be. If it needs just minor buffing out, release the game and patch it up to a full quality. Early access only makes sense if the game's being made by a team of five people or is a bigger game being released very early. You're looking at the latter case.

We can test it. We are testing it. This is what we're doing right now. For Big Bang, do you have a written evidence or a witness testimony? Again, indirect evidence is evidence. You can use the effects something had as evidence if you understand the chain of causality that is applicable. And in cases where a critical experiment is impossible, that's the only way you test a theory. Instead of performing a critical experiment, you go over the existing observations and see if they make sense. If that wasn't the case, cosmology, archaeology, evolutionary biology, and many other disciplines would be impossible. In order for this to be an argument for a point you're making, you have to assume both good faith and competence from Intercept and Private Division. And if they are both competent and have been communicating with us in good faith, the rest of your argument does not follow. You can't have it both ways. You can't claim that we're seeing delays due to Intercept's incompetence and Private Division's negligence based on the claim that they were competent and diligent in producing the "initially optimistic release window". Unless you can tell me why they were competent in 2020 and stopped being so subsequently. They say you become a senior engineer when the amount of code you're deleting becomes greater than code you're adding. It's tongue in cheek, of course, but we rip out so much of the code all the time. Yeah, if you have a working product that you're expected to support, ownership and continued maintenance of the code is a must. But while the project is being built, stuff gets thrown out the window all the time. Again, if the original version of KSP2 was based on KSP1 code and was supposed to be developed in shorter time, and what Intercept worked on was built on a new code base from scratch, then not throwing away most of ST's code would be silly. Yeah, I'm sure one could salvage something, but most of the code would be modification of KSP1's, which is getting thrown out. It'd be harder to adapt it to new code than to write it from scratch. And we have strong evidence that Intercept's KSP2 is new code, because all of the craft and save files are JSON now with completely different structure. And the way the game loads modules is completely different. I haven't done as deep of a dive into modding as some people on Discord have, but what I've seen so far also indicates something completely new. The only reason Intercept would be keeping Star Theory's code is if Star Theory was already writing KSP2 from scratch, without reusing any of the KSP1's code. And if that was the case, Star Theory did not have the time, given their limited engineering, to build a game by 2020 in the first place. The only reasonable thing to assume based on all of this is that Star Theory was working off of KSP1 code, and Intercept wasn't. And if that's the case, then your argument to code reuse is invalid, and without it, the rest of the argument collapses as well. If Intercept only started on KSP2's code in 2020, there was no way to release the game in 2021. So I don't know why that release window was ever given to us, but there are a whole bunch of possibilities for this happening from mistakes to misunderstandings to lies, and all of them are more probable than the idea that Star Theory was going to write all of that by 2020 or that Intercept was going to get it done by 2021.

#WhoWoreItBetter (RIP Mad Mike)

Worst time I had in a lab bar none.

We've never weighed an electron either, yet we can compute its mass indirectly. Indirect evidence is evidence. If you have a model you have no reason to doubt, and you have observations that fit that model only with certain specific inputs for the hidden variables, that's an indirect evidence of these variables. Now, if you have reasons to doubt the model, that's fair. But that's what you should be bringing up and discussing, not just saying, "None of us were there, so we can't know." That's just demagoguery. A model is put in question either with observations it cannot explain or with a better model. If you have a better explanation for why there were job postings in 2020 for positions that didn't exist at Star Theory, lets hear it. The way I see it, either Star Theory did nothing, or they worked on a game that's different enough that they didn't need these positions filled. I find the latter more likely, but either way, that means that production on what we know as KSP2 now started with Intercept. If you have a third scenario, let's hear it.

Addressed in multiple posts above.

The candidate branch update from 2d ago is very promissing, yeah.

This is a touch subjective, but I'm basing this on when people were being hired. Positions that got posted around Feb 2020 and filled summer-fall 2020 are consistent with game going from pre-production to full production. Yeah, these parts I completely agree on. This early access is not for everyone, and that needed to be clearly messaged. It wasn't. It was marketed as something that's a bit rough, but suitable for mass consumption, which is not so. My only point is that I don't think that reflects poorly on dev team by default. You can view it as a red flag, and it's fair. I was saying it in 2020. I can find you quotes if you want. This is why I'm with you as far as disappointment with messaging surrounding this, but also remain cautiously optimistic about development. It's clear that we're looking at summer release even if all goes well, which is a delay by any measure, but not an unreasonable one.

It's annoying, but you can work around it. A bit in advance of where you expect to drop the tanks, pause the game, go into resource manager, and set up the transfer. Unpause the game, and watch the gauges. Once the drop tanks are empty, jettison them. You don't have to time the fuel transfer perfectly. If you start a bit early or a bit late, you'll just be carrying the extra weight a little longer, but you'll still have all the same engines firing, so the loss of efficiency is fairly minimal. Because building up results in very wobbly rockets, despite the inconvenience, I would still recommend relying on asparagus heavily. It gives you good places to attach struts to give your craft the rigidity it needs to survive the ascent gracefully.

I don't know where you're getting an expectation for a faster turnaround, but it's not from anything resembling a real world of a mid-size studio. 2 weeks of work + 1 week of testing is fast-tracking it.

If you tell shareholders that the project is delayed to next fiscal year, you can buy yourself a year to distract them with something. If you tell them it's delayed by three years, you might be replaced right now and not get the chance. Name me a major game in the past decade that had its release slip by more than a year whose delay hasn't been announced in increments. I've held a title of director in a small studio with a modest eight figure funding. I've done engineering and mid-level management on titles well into nine figure budgets. And all of it is recent work that isn't out of date. I have done some indy work, but that was back in the day when I was still a graduate student, before I went into game development full time.

Au contraire. While you might have experience with the engineering, it's quite clear from your comments that your experience in management is, at best, lackluster. I know how I felt about the projects, where they are, and the dates we were given when I was a mid to senior engineer with no access to the decision making, even when I had been allowed to architect major systems, vs what it felt like in the director's seat or equivalent position, going to the meetings, and listening to CEO tell us what the board wants on the business end of things, and how we can make something that at least technically qualifies without compromising what we're actually making. There's a lot of horse trading. There is a lot of definition stretching. And there are a lot of dates that absolutely nobody has any confidence in, but we technically would have had the receipts for it if someone asked for them. Some dates only ever exist as Potemkin Villages, and it has nothing to do with the team not being capable. It has to do with someone pulling a trigger early on the marketing and then knowing how bad it will be to announce a 3 year delay the same year.

Except that it happens all the time. I've played nearly finished, never seen by anyone outside the studio games at every major studio I've worked at. One of these I've worked on myself before it got unceremoniously canceled. I've also looked at a couple of examples of games that did get handed over to another studio, including one that got fairly good response after its production reset. (Over 10M sales) In this case, the original work by the original studio is not widely known. It got ported to a completely different engine, so other than the Maya/Photoshop assets, no work on it survived the transfer. And yes, the version on the original engine was mid-production at least. Except we know this is what actually happened, as pretty much the entire creative team has been ripped out of Star Theory games and brought over to Intercept, including the creative director for the game. You don't do this if you think the team is doing poorly. Game's director is literally the first person you blame for any production problems. If you think the team did poorly, you don't bring the director. You might, however, do this if you can't reach an agreement with the executive leadership of the original studio, and you think you can poach all the talent along with all the assets and take a risk on the disruption. Especially, if you think the development needs to be rebooted anyways, because you think a larger scope will require a tech update. Which is what we saw. Most of the critical hires for Intercept post new studio formation have been in getting technical talent for an overhaul that wasn't needed for the original game. The people that ST would have had to hire anyways, and face delays while these people are onboarded. You obviously never had to deal with a board of directors trying to please investors.

I should preface this with saying that it is a hypothetical - I have no insider knowledge, and I wouldn't be able to share it if I did. So while I'm basing a lot of this on information we've had and my industry experience, there are educated guesses sprinkled in between. Anything I claim about motivations of people and companies behind this is entirely my own invention and I can be 100% wrong. People have seen a rough pre-recorded tech demo behind the closed doors at 2019 E3. Some phone-captured footage of it is floating around. I'm assuming, the original pitch for KSP2 was to base it heavily on KSP, give it a graphical update, and add colony mechanics and a second star system. You know how some sequels could have been a big DLC? That's what I suspect the original scope was. Star Theory seems to have been an even smaller studio*, and with T2 purchasing Squad in mid-2017, proper production of KSP2 at ST couldn't have started until late 2017. In order for them to be ready by early to mid-2020, I can't imagine the scope being much larger than that. In 2019, it was likely decided that there is enough interest to make it a bigger game. I imagine Nate S. was the main driving force behind that push from the Star Theory side, having a bigger creative pitch, one that would eventually become the KSP2 we know now, ready to go. I think the reception of KSP2 teaser at E3 was the big signal that everyone involved was waiting for, immediately giving a green light to that larger vision. So, you know, everyone who cheered for KSP2 at E3, well done. Unfortunately, that didn't go well for the Star Theory as a company. As we know, the negotiations for extended development time and budget broke down, Intercept was created, and KSP2 was effectively rebooted. * Star Theory was reportedly around 30 people before a fraction of these people jumped ship to the newly founded Intercept. Intercept's site currently claims 40 employees, but since ST was independent and Intercept is managed by the PD, I suspect a larger percentage of Intercept are directly involved in game development. So I would estimate the Intercept's dev team to be about 50% larger. That doesn't translate directly into time spent on a project, but it gives you a rough idea. Yeah, we knew that. The customizations have to do with time-warp stability and continuous collisions to prevent tunneling at large relative velocities on collision. There was also some talk of LoD for physics, effectively freezing some joints at certain times, but I don't know if that's been implemented. The actual collision detection, constraint solving, and rigid body simulation is on Unity's side. So this is exactly what we expected to find there.

Generally, a bad alpha is the one where some content is consistently unplayable. If a game-crashing bug would happen every time you approached Duna, for example, that'd be a good example of a bug that prevents you from exploring all of the game's content. If it only happens sometimes, that's par for the alpha. We have access to a good cross-section of parts, most identical to KSP, and pretty much all of the new tech features, save for multiplayer. This is sufficient to demonstrate what the game loop can be like, even if numerous bugs make it too frustrating for some people to play at this time. Again, goal of alpha isn't a nearly-playable game. That's what a beta is. This is like saying that Duke Nukem Forever was developed for 14 years. Star Theory went defunct. It never made the game they started in 2017. Development on KSP2 that we are seeing now started in 2020. There has been some asset reuse, but if you go by that metric, KSP2 has been in development since 2010, because there are some assets that have been upresed from the original KSP as well. This isn't how development timelines work, though. Intercept started production of KSP2 in 2020. If you continue arguing that we should be counting 2017, then start by explaining why we aren't counting from 2010. Or 2005, with first release of Unity. Or 1962, when Steve Russel made Spacewar! for PDP-1. Because, clearly, some concepts from that game have been reused in KSP2. Good state for an alpha, bad state for a public release with a marketing push. I'm enjoying it, but I enjoyed getting HL2 leak to work on my PC, because that's what I do with games. I tinker. Most people want a finished product. If a company starts selling access to something in an alpha stage, I don't think there's a problem with it, but I think better warning to people would have been nice. Some KSP fans clearly had different expectations of this early access. In either case, it's not a problem with how the game's being made. Just with how it's presented to the general public.