K^2

It's harder for me to make an estimate for a catastrophic failure of a black hole drive. On the net, it's safer, and an accidental failure is likely to release most of the energy in a pair of beams. But that would make intentional release more deadly, potentially, as you can direct the peak output at the planet. So there's a pretty wide range here. But the ballpark should still be like what we expect from a matter-antimatter explosion, which I can give estimates for. The output will be a gamma burst with a peak somewhere in tens to hundreds of MeV. Dental X-Ray is under 100keV. Nuclear blast mostly peaks in a similar range, with some radiation into low MeV ranges. So we're talking harsh gamma radiation. Now, lets look at the intensity. First, we need to know how big our ship is. Say we want to carry a crew of about 100. Now, I have no idea what the standards are going to be like for interstellar travel, but I think applying metrics for cruise ships should give us a ballpark. Typical occupancy factor is about 30kT per passenger, giving us a 3MT payload. Lets load it for a one way 10ly journey. Note that a 1g torch gives us a factor of a * 1ly / c of almost exactly 1. That means the half-way Lorentz boost factor is 1 + 1ly/yr2 * 5ly / c2 = 6. (Oh, yeah, torch ships be scraping that interstellar space. We're not even talking about how to mitigate that here.) The relevant rocket equation for a light drive torch is v/c = tanh(ln m/m0). And, of course, tanh-1(v/c) = coth-1(gamma). Or in other words, ln(m/m0) = cosh-1(gamma)* This gives us m/m0 for our hypothetical starship of about 12. Of course, then we have to slow down, so we have to square this for a total of 144. Rounding that a bit, we're looking at 4.5GT or 4.5x1012 kg of matter-antimatter loaded up for this one way trip. Lets say we parked this beauty about half way to the Moon. That's a 4*pi*(200,000km)2 sphere to which 4x1029J of energy will be spread. Each square meter of Earth's surface facing the ship will receive 8x1011 J of energy. To put this into perspective, Earth's surface radiates about 500W of energy from every square meter under normal ambient temperature. It would take about 50 years for Earth to lose all that heat at 300K surface temperature. Of course, Earth's surface temperature would be nowhere near 300K following such an event. So lets see how much effect an atmosphere of Earth would do against this. Lets say, the atmosphere absorbs most of that. There are about 10T of air above every square meter of the surface. It takes about 700J to heat up 1kg of air by 1K. So we're looking at an atmospheric temperature of well over 10,000K. That's hotter than the photosphere of the Sun and would give the entire atmosphere an average kinetic energy of the gas well above the escape velocity. That means, first, the surface would receive a massive burn from direct contact with a star twice as hot as our Sun, followed pretty much immediately by half of the atmosphere of the planet heading off for interplanetary space. Realistically, at 10MeV+ energies, a lot of direct gamma radiation would be getting through, but it hardly matters whether it's the superheated atmosphere or the gamma radiation that slags the surface. To paraphrase a Simpson's character, "Ze atmosphere, it does nothing." tl;dr: A detonation of a matter-antimatter photon drive torch designed for a one-way 10ly journey with a crew of 100 and parked half the way to the Moon would evaporate the atmosphere from the side of the Earth facing the explosion and slag the surface. What happens on the shadow side is left up to the imagination of the reader, but it's not good(tm). The effects of the release of these quantities of energy are so devastating, I'd hesitate to allow any sort of a practical interstellar ship within the orbit of Jupiter. * Since this is a useful equation for napkin estimates, given the topics that come up in this forum, in general, if you have a torch ship that needs to travel a distance X at acceleration a, the relativistic rocket equation is given by: cosh((ve/c) ln(m2/m02)) = 1 + a (x/2) / c2 The squares on masses come from having to speed up and slow down. The thing that makes this so much easier to work with is that if you work with optimal light drive torch ship, a = 1ly/yr2, c = 1ly/yr, and ve/c = 1. So as long as you do x in light years, every other variable is 1 except for ln(m/m0) which is the thing you need to compute. You still need to compute hyperbolic trig functions here, but at least you don't have to look up a lot of obscure constants. Edit: P.S. Because people probably aren't that familiar with hyperbolic trig functions, while you do want to pull out a calculator (or do a couple of series terms if you know 'em) for low factors, cosh(ln(z)) tends to 1 + z/2 for large z. Past 50ly or so, the above formula is really just (m/m0)2 = x for ve = c and a = 1ly/yr2. So you literally can do a torch-ship rocket equation estimate in your head by taking the distance you wish to travel and squaring it. Square it again for round trip. And yes, this does heavily imply that while getting out of your own star system is really hard, once you can go past your few nearby stars, you can go just about anywhere.

I don't think you have proper appreciation for how high energy density works. I've built an electric bicycle recently, and when testing things out, had bad temporary connection from the battery to the motor. It wasn't even a short - just really bad contact coupled with inductance of a 750W motor creating a voltage spike and an arc that instantly turned about an inch of thick copper wire into white-hot molten spray leaving scorch marks on all it hit. The steel clamp I used to hold thing down had holes burned through it, but fortunately everything else suffered only superficial damage and no fires got started. That wasn't the whole battery going up in flames. That was just a spark it caused. The whole battery packs a punch of nearly a pound of C4. Of course, it's not that impressive for a thing that's over 4kg in total, but then again, when I'm starting to compare a bicycle battery to a quantity of high explosives that you don't joke around with, that should start putting things into a perspective. We've got desensitized to just how much of a boom can anything that's good energy storage cause. People worked really, really hard to first find and then improve on something as stable as gasoline and diesel. These things are absolutely shockingly stable for the energy they hold. So we're used to think of the energy storage for moving a car as nothing much, but this isn't at all normal. Of course, we aren't talking about moving a car. We're talking about moving a starship. And here we are in a completely different class of energy densities. This isn't a nuclear energy, which is about a thousand times more energy-dense. We have to go a factor of a thousand on top of that. We're talking about means of energy generation where the mass defect comes with the territory. You have to convert a significant portion of the rest mass into energy. These things cannot be made safe. Nor compact. They have to have the mass to expend into the energy you are trying to harness. And really, we only know of two principles that can even work for this - we're talking about either black holes or matter-antimatter reaction. Neither of these can be safeguarded. Neither of these is going to be something you plug in as a battery. As @JadeOfMaar correctly pointed out, any starship is a potential planet killer. And I'll add to it, that it doesn't at all need to land on the surface to be devastating. Having it go up in a blaze of gamma rays in orbit will still sterilize a third of the planet surface and make the rest uninhabitable for a very long time.

From a venture capitalist perspective, there are two ways you make a return on your investment in a startup. It either starts making huge profits, or you sell the company to someone else. I'm pretty sure all of these space startups are in the latter category. I don't think anyone investing in these expects them to start making independent space stations. The expectations is that they get bought up by someone like Boeing, Lockheed, or SpaceX for work on a gov't contract. Whoever gets the contract to build the Lunar Gateway, for example, might be looking to buy three or four of these startups just to get access to their talent. That's not to say that people working at these startups think that way. Many of them might actually believe in the idea of building private space stations. And heck, one or two of these might actually get contracted to build something and could even grow as a company that way. But it's not the sort of hope on which you invest money.

It will lose hydrogen over time, turning into a carbon deposit. Hundreds of millions years from now, cephalopod geologists will wonder why there were two carboniferous periods in Earth's history.

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.