K^2

Are you... Are you Kraken-driving this thing to hover, so that the engine can look like it's a burner?

Lighter-than-air buoyancy is even easier, actually. With water, you have to worry about a surface, and that's the tricky part - you have to estimate how much of a part is actually submerged. It's very simple for some colliders, like spheres, and gets progressively harder for others. Even for a cube, if it's tilted, computing the precise volume displaced at any given position is surprisingly complicated. Of course, there are very simple estimates, like you can just take the top and bottom extents and see where the water surface falls relative to the two. If it's between, take a percentage of the collider's volume. It's not quite right, but it's good enough for a lot of games, and I wouldn't be surprised if KSP1 did something like that. For lighter-than-air, there is no real surface to worry about. Yeah, there is a cutoff for atmosphere in KSP1/2, but by that point, the atmosphere is so thin as to be irrelevant. So you can always use exactly the same formula for displacement lift while in atmosphere: gravity * volume * atmospheric density. All of these are available to the components in the game, so it'd be very easy to write a module that handles this. This would be very simple for Intercept to add if they decide it's something they want in the game, and it will be very easy for modders to add if Intercept doesn't. The only barrier right now is lack of the SDK, and even that might not be a blocker already.

I know people figured out how to add modded parts already. It'd be trivial enough to make a part that has a negative weight, but, of course, that would float straight to the edge of SoI, which is not exactly great. You could also make an "engine" part with an infinite ISP and a custom altitude profile that allows it to only go up to certain pressure altitudes, but then you could angle that and get an infinite thrust, which is also not ideal. Proper atmospheric buoyancy would require a custom module, I think, and I don't know if anyone got that far with modding the game. It's certainly possible, but I don't know if anyone has done the work yet. I'm also not sure if that level of modding is in agreement with forum rules, given that SDK isn't out yet, so that might have to stay on the outskirts of Discord until official support is added. But I'm definitely looking forward to some sort of lighter-than-air builds in KSP2. It seems like it would very much fit the style of the game.

A shout-out to MinerBat on YouTube (I don't know if they have an account here) for building a full return mission to Jool. It uses a Kraken drive for the final bit of flight with rotors to gain altitude enough for the Kraken drive to work, but even with that drastic reduction in weight of the final stage, this is a very ambitious build, and it's a good watch.

That clearly works from the energy perspective, but I instantly have a lot of "How?" questions. Like, how do you inject oxygen into that (also run it through NTR to get the gas up to speed?), how do you design an afterburner that works at these temperatures and flow speeds, and how do you build a nozzle that survives this kind of an abuse? Do you happen to have a specific design in mind, perhaps, that you can point to? None of these problems seem unsolvable, just really hard, especially in concert, and if somebody already put in the work to try and figure it out, I'd be interested to see what they came up with.

It should be noted that you absolutely have to take an efficiency loss somewhere to generate electricity from an NTR, but for a lot of the missions, the efficiency loss might be insignificant compared to the advantage of not having to rely on some other source of electric power. You do have a bit of a choice of what sort of efficiency loss to take. If you try to utilize heat flow from the fuel to heat exchanger, which is trivial enough with some NTR types, you will have to take a temperature drop in the exchanger, resulting in slightly lower ISP. If instead, you divert some of the reactor heat, you can keep the exchanger just as hot, but you'll need a slightly larger reactor, making the engine heavier, taking the cut in TWR. Finally, if you go for an MHD generator, you'll be slowing down exhaust, which will harm both the TWR and ISP.

The underlying principle is the same, yeah. Though, if you are limited to treating a satellite as a rigid body, all you can really do in practice is move about the argument of the periapsis and the longitude of the ascending node. Great if you just need to spread satellites into a constellation or want your orbit to precess with a fixed speed, but it won't let you climb to a higher orbit or change eccentricity in a controlled way.

The funny thing is, you can generate thrust in orbit. There are so many different ways ranging in degree of practicality all having to do with the fact that you're not operating in a vacuum. The most obvious are solar sails, of course, but you can use any "imperfection" to push from. Magnetic tethers have been of much interest, since they can generate considerable thrust in Earth's magnetic field. Most creative, of course, is noting that since you want to gain momentum, the symmetry you want broken is spatial, and if you have a gravity source, that symmetry is inherently broken already. The second clue is the spherical symmetry is there, so you'll have to live with the conservation of angular momentum*, but unlike linear momentum, we know how to store it - just make the object spin. And that trivially leads to an obvious solution. Two satellites, a tether, and an electrically-driven winch. Start the two at slightly different elevation orbits. As the lower satellite starts to lead, winch it in, then, after they cross over, give the tether slack, and allow the two to separate again. With every swing, you'll be climbing to a higher and higher orbit, while the satellite pair starts gaining a counter-rotation matching perfectly the orbital angular momentum gain. Keep it up, and you can actually build up to the escape velocity**, at which point you are ejected from the system, and you now have linear momentum. But that was always allowed, as you've used the entire planet as your propulsion mass. But this doesn't have the word quantum in it, so people aren't interested. Maybe if I call it a "Gravity Drive", people will throw money at it, but I am, unfortunately, not good with fundraising in general. * Yes, Earth, and planetary bodies in general, are not perfect spheres. Their gravity has features, ranging from elongation due to rotation, to slight variations in the gravitational field due to elevation changes. You can, technically, use these to dump angular momentum as well, allowing a craft to escape the planet's pull using nothing but electricity and depart without any sort of rotation, but that will take a lot longer. ** If your tether is long and strong enough. You will have to absorb a lot of angular momentum to escape. Of course, if you only need one of the two satellites to escape, that does open up additional possibilities...

Oh, I assume a lot of goalpost moving to be involved, certainly. I have a feeling the QD team will also be shifting theirs when the launch fails to demonstrate any amount of thrust distinguishable from an outgassing due to unequal heating of the craft. That's just how that game is played. But despite my eyes having rolled back so far upon seeing yet another impossible propulsion method being excused with the word "quantum," that I was able to see my own thoughts, I don't really mind this kind of a stunt, because, like I said above, it's just another few million into a ride-share, which carries a bunch of legitimate equipment, and really, this money is funding the launch. So we're going to get something good out of this whole thing. Just won't be from that specific box of circuits. So if they can keep milking it, and keep effectively subsidizing research payloads, I'm ok with it.

To continue this analogy, imagine that you're investing a billion dollars into an expedition to a long lost temple. There's a lot of myth surrounding that temple, but you're also pretty sure that whatever you dig up in terms of real, material goods will be worth the investment, and the lead on the location of the temple is pretty solid. Then somebody approaches you and says, "You know, for a million more, we'll check if the tooth faery is also there," and before you can kick them out of your office, they pull out the pamphlets where they show a pretty good advertising spin tying the tooth faery to the temple and its legend. And at that point, what's another million for some free publicity from the buzz? That's basically what this is. This whole thing exists because some people look at it, and say, "Well, they're putting millions into that, so there must be something to it," all the while this isn't a huge endeavor. It's a pile of store-bought sensors on a metal body with some magnets going up to measure noting but noise as a part of a ride-share with literal tons of legitimate scientific equipment working on real discoveries. P.S. Also, if you call it a Quantum Tooth Faery Effect, I'm not convinced you wouldn't be able to raise a few millions to investigate it.

I mean, they're not disproven the same way tooth faeries aren't disproven. It's not, though. It's a mathematical consequence of the underlying symmetries of space-time. And if these symmetries weren't there, absolutely all of the general relativity and quantum field theory would be wrong. This is something that's backed up by every critical experiment we've been able to perform, some to ludicrous precision. For there to be anisotropies of space-time so far undetected, the effect would have to be on the order of 10-15 or less. If the effect existed at all, which as pointed above is about as valid as assuming you can ask faeries to push your rocket based on our current understanding of physics, it would have to be so weak as to be entirely useless. Attaching a flashlight to your spaceship and using recoil from the photons would literally be more efficient than any possible exhaust-free propulsion allowed by the limits on the statistics of the experiments we have performed. You "only" need 300MW of power for every 1N of thrust with a photon drive, after all. If something more efficient was possible without generating exhaust, we would have found obvious discrepancies in particle resonance frequencies and binary neutron star orbits. If the anisotropy was significant enough to be a viable violation of the 3rd law to any practically measurable degree, we would have known about it for decades and have a working theory of it, and not some snake oil venture capitalist bait. This is 100% a scam. Just reading through the company's press releases, which mentions zero relevant physics is a perfect indicator of said fact.

Has the patch been anything less than I've suggested it was going to be based on my assessment of the team? Again, I don't think you understand how the game development is planned and executed on at the high level.

To be fair, robotics parts do present some additional challenges for some kinds of physics optimizations that were considered for the game. I don't know if these optimizations are still planned - it doesn't look like any of that is happening in the current version of early access, but even just having them in mind might have been enough for someone to make the call not to include this as a feature at the release. Robotic parts are also if not an outright problem for multiplayer, at least a speed bump that would make getting multiplayer out the door a lot easier if the robotics just wasn't a part of it. This doesn't have to be just a cash grab is what I'm saying. Though, I'm sure someone will make a call to exploit it as one regardless of the original intent, so yeah, I would expect robotics to be a part of DLC at some point.

In early 8086 architecture, interrupt wasn't a bug. It's just how the CPU talked to the program. Audio card ready for another packet of data? Interrupt. User pressed a key? Interrupt. Some fixed amount of time passed, as set by the timer registers? Interrupt. Having a divide-by-zero generate an interrupt wasn't seen as a problem. You can literally write a two instruction handler that says "set answer to zero, then resume," and you're done. You get your x/0 = 0 behavior practically for free if you want it, but you can also do something fancier if you needed it. It just wasn't a problem. And then 80386 happened with its 32 bit addressing only available in the protected mode and over the next decade the interrupts went from something the programmer takes care of to something the operating system takes care of. But the design choice of division by zero always raising an interrupt remained, because that was legacy behavior that had to be maintained. In principle, there was a design choice to be made with all of the modern operating systems to handle that interrupt differently. After all, a key press still generates an interrupt under the hood, but the operating system takes care of it without generating a signal. So we never think of a key press as a bug. But because division by zero is a signal, along with fun things like general protection fault and illegal instructions, they are handled by a programmer in a similar way to a genuine error. Or, if unhandled, will terminate the program. Was this the correct choice for the operating systems? Hard to say. But given that both Linux and Windows adopted this approach in the early 90s, by now it's basically just a fact of life. If you want to write your own operating system, or even just a kernel mod for Linux, that handles division by zero differently, it's absolutely an option. This does bring up one more curiosity. Floating point is different. Unlike the integer division by zero, which always raises an interrupt, floating point division by zero may raise an interrupt. There is a CPU flag that controls whether this happens, and it is off by default for any new process, meaning the programmer has to opt-in to receive floating point division by zero as a signal. Otherwise, that division is ignored, and you get either INF or NAN result. This was partially done because on 386 the FPU was originally a co-processor, but I suspect at least in part because it was anticipated that this will happen more often with floating point computations, and an interrupt should absolutely not be the default way to handle this, especially with protected mode enabled. The ability to set up floating point traps is absolutely amazing for development, and I do wish that more people would know about it. I like to run debug builds with FPU interrupts, because then if I didn't do the correct checks in my collision detection code, for example, and generated an unchecked division by zero, instead of finding out about it after hours of debugging a weird collision glitch, I can simply get an interrupt when it happens. There are, however, some compiler optimizations that come into conflict with this. One that caused me most gray hair back in the day was when Microsoft decided to emit SQRTPS signal for the sqrt() call in SSE-optimized code. So any time you take a square root, there's a chance that some of the unused values in the MMX register are negative, and that will trip an exception handler which is slow! So the fix for it is writing your own sqrt() function that emits SQRTSS and hope it doesn't wreck the optimization. Naturally, it's not a great strategy for production code, but it's good for debug builds. So I still recommend doing this, but it is a bit of a hassle. And don't forget to make sure it's disabled in production.

That was for a sublight torch, and I'm making no accounting for shielding. Purely energies required to accelerate up to speed, then slow down again. We don't have a fully working model for a practical FTL ship, but what we have suggests that the requirements will be higher if it's at all possible. Likewise, wile a strong enough magnetic field should resolve a problem of shielding for the voyage, that will induce drag, which will also increase the amount of fuel needed. Though, it will also make stopping a little easier, so it might not be as extreme. I will leave working out the math of hyperrelativistic drag to someone with more spare time. Nonetheless, this is a lower bound on the kind of energy you need for an interstellar ship of any kind, and it's a horrifying planet killing weapon in the wrong hands under the rosiest of estimates. Something a bit more realistic we might not want to let closer to Earth than the Oort cloud. Yes, or I'd be a recipient for sure.

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.