K^2

Yes, but capture inherently can only give us net zero. We're so far behind the curve that we have to be developing net negative approaches as well that can be deployed worldwide. We basically have to do all of the above. Replace emitting processes with non-emitting, especially in energy production, have mandatory capture anywhere greenhouse gasses are produced, and develop methods for carbon capture that can be used elsewhere. Part of the problem is that global average temperature increase leads to all kinds of additional outgassing, mostly from melting glaciers, but also from reduction in permafrost, heating up of old bogs, etc. This means that even if we reduce our CO2 production, we still have more net CO2 released in atmosphere than can be naturally absorbed, meaning, the CO2 will continue climbing, and we don't know for sure whether the process is a complete runaway or will simply lead to an equilibrium at higher temperature. Either one's bad for us, though. We have to start taking CO2 out of the atmosphere in addition to cutting production to as close to zero as we can manage.

Plastic presents problems because it does degrade into microplastics that tend to get everywhere. Plus, the way we manage landfills. If it was another polysaccharide instead, something that mostly stays put, and the parts of it that don't revert back to some simple sugars, we could let it just accumulate in the jungles and make them heavily carbon-negative.

Yeah, apparently virtually all of the world's coal deposits are from that time, when trees were already a thing, but fungus that can break down cellulose wasn't, and trunks of dead trees would just accumulate. Which is both amazing and terrifying, seeing how we're releasing that carbon back into atmosphere for the first time in hundreds of millions of years. That does lead me down a thought path, though. What if we were to engineer a cellulose alternative that would be just as viable as building material for the plants, but that existing enzymes are useless against, and just started planting forests upon forests of these instead of regular trees. Could we use that to lock up enough carbon to make a difference? It's ok if these engineered trees aren't as competitive biologically, as when you plant a grove, whatever you planted has a significant advantage of being there first. Bonus points if it's actually a viable construction material too, giving us a wood alternative that doesn't rot and is just as or more environmentally friendly. Might be a good angle to get funding for it based on this as well. From perspective of genetics, ecology, and energy use, this seems viable. But my organics and biochem-fu is weak, so I have no idea how hard it'd be to even come up with a structure that is still essentially sugar based, is strong, and is resistant to the array of enzymes other organisms use to break down cellulose and other polysaccharides already.

Seems unlikely. The more oxygen you get in atmosphere, the more flammable everything gets. Historically, the highest that the partial pressure of O2 got to was about 0.35 bar. Oxygen toxicity to humans starts at about 0.5. But there are a lot of other life forms that can be far more sensitive. Also, excess oxygen allows for a lot of life that isn't possible now, like giant flying insects which will simply suffocate in flight in modern atmosphere. So the consequences to climate, flora, and fauna can be very dramatic. But I don't think it will be directly poisonous to humans.

Now, sure. But between major releases during GTA III and GTA IV eras, modding community is what kept the interest in the games alive to a large degree. I've been a moderator of GTAForums for well over a decade and community member even longer. I wasn't too heavily involved in the mod development, but I've been participating here and there, including some early testing of Open IV. Modding community is what kept the game alive during the slow years, and is a big part of why it managed to stay relevant through longer dev cycles of later titles. It will be moddable regardless. It just would be nice to be able to publish mods openly rather than through back channels. A built-in mod manager would be great too.

GTA modding scene is huge, and it's a big part of why the games have been popular through the years. T2 taking action against modders was a huge slap in the face to the community. The problem is that T2 has attacked people who were making modding tools, not people who were using said tools to get DLC etc. Likewise, tools have been used in the past to cheat in GTAO. Which, you know, if you are a competent developer, you plug holes in your online title and not rely on client security for it, but suing members of community is easier, apparently. So yeah, there are some ugly precedents here. Hopefully, without multiplayer getting monetized, there wouldn't be nearly as much of an incentive to create barriers. There are also limitations in tech. GTA runs on a proprietary engine, so there were a handful of people who knew how to build tools to work with said engine. With KSP2 running on Unity, a whole lot of tools are already out there and more will be made. So it's going to be very hard to stop modders. With any luck, that's enough reason for T2 to leave KSP2 alone. But some sort of crackdown on modding at some point on the future is not out of realm of possibilities.

It's not that it won't work. It's that it's less efficient than a bunch of other, simpler options. There is nothing wrong with the concept on the fundamental level. Ultimately, what you're trying to do is making propellant depart your ship as rapidly as possible. You have two principal ways of achieving this. You can either make propellant really hot and let thermodynamics do its thing or you can apply electromagnetic forces to accelerate propellant. If you are going with any kind of thermal engine, the limiting factors are temperature of the chamber and how light the particles of propellant are. The lighter the particles, the more velocity they'll have at the same temperature. With water exhaust, a LH2+LOX engine is already really, really close to the limit before your combustion chamber starts to melt. There are some clever ideas for afterburners, but they're more about augmenting thrust than ISP. So the only way to get better efficiency is to have exhaust that's lighter than water. Realistically, that's helium or hydrogen. And there are few reasons not to go hydrogen at this point. At this point, you'll have to start adding heat from external source. How you do this is kind of irrelevant. An electric arc is fine, but you can also just use a nuclear reactor. That's all that NTR is. You pipe hydrogen through core of a reactor and use the heat to drive the rocket. And the thing is, the ISP of an NTR is also just limited by temperature at which components start to melt. And you can't go much past that. Even if you decided to recombine atomic hydrogen into molecular, you are still temperature-limited, so you aren't getting a better ISP. There are two ways to circumvent it. First, you go even lighter. Don't recombine hydrogen and use atomic hydrogen for propulsion. This can let you get more ISP at the same temperature. This is where I thought you were going with all of this. It is, however, very energy-inefficient. Your other option is to have other means of confinement. Basically, instead of working with a gas, you start working with plasma. VASIMR rockets do precisely that. They are essentially thermal rockets with a plasma bottle for a chamber. Here, instead of wasting energy on splitting hydrogen, just increase the energy you put into plasma and get more thrust. There is just no reason to deal with atomic hydrogen once you are working with plasma until you get into absolutely absurd energy ranges, but then the question becomes what your power plant is? So in the end, there just isn't a niche for atomic hydrogen in anything remotely like modern rockets.

A lot of linear accelerators are built as banks of cavities with applied RF field providing electrostatic potential to drive charged particles through it. Not all thrusters are going to use the same principle, but there is going to be some sort of equivalent where more power gives you more thrust. No. You don't want batteries in your ion drive engine. They are too heavy for the amount of energy they can hold. You are better off just burning kerosene at this point and using exhaust directly. The whole point of an ion drive is that you have something with enormous energy density that you can use to generate high ISP by accelerating propellant directly. For example, you might use solar panels which can't give you a lot of power, but they can give you an huge amount of energy over the life time of the panel. Currently, the only attainable power sources that give you both the high power and high energy density are nuclear. So if you're designing an ion drive engine, you're always going to be either building for a low thrust application with solar panels or nuclear RTG, or a high power system that's powered by a full nuclear reactor. No other existing power sources are remotely adequate.

If the game isn't coded to do the algorithmic tradeoffs, which they usually aren't, very little. Once you hit a bottleneck, that's what determines performance. RAM is actually the worst, as the fallback for running out is starting to write to disk, and that is very slow. The ISP gain only really makes sense at a given temperature or a given power limit on your accelerator in an ion thruster. If you have excess energy to put into splitting H2 molecules, just double the cavity potential and get the same ISP with molecular hydrogen instead.

Shouldn't. Some integration methods could have trouble, but I would imagine Wolfram to handle it correctly. Is your load something like c1H(L/2 - x)H(L/2 + x) - c2δ(x-xs) - c2δ(x+xs)? (I'm assuming load isn't structural and sags, distributing weight evenly, and supports are applied at a point.) I can't think of any reason why this would result in solutions that aren't symmetric. One thing you could try, and what I'd do to simplify the problem, is to enforce symmetry by solving for positive x only with additional boundary condition that deflection and slope at x=0 are zero. That way your loading is just a Heaviside + delta, which should be a lot easier to integrate, and then maybe do all the math in Fourier space to go back to continuous functions if I was doing this by hand. Of course, that doesn't help explaining what went wrong in your computation. Do you want to share a bit more details about the steps you've taken?

Standard model, for sure. Relativity doesn't really care. Relativity prescribes how massless particles should behave, but it doesn't really care if massless particles exist or not. It does provide us with some experiments that can help us determine if something has mass, of course. So neutrinos are a great example. In most ways, they behave every bit the same as photons, but we've found evidence of flavor oscillation, which relativity says can't happen if neutrinos are massless. Researchers have looked for evidence of similar "aging" of light from distant sources, and found nothing, but from perspective of relativity, that can simply mean that photon mass is too low to be detectable this way. Standard model, in contrast, cares very much. In standard model, bosons are consequence of local symmetries. Photons are kind of an interesting case. They are closely related to leptons (electrons etc) which have two intrinsic degrees of freedom with related symmetries. There is the phase of the wave function and there is the spin. If you only had the phase, you'd still have photons, they could be massless or massive depending on whether they couple to something else, and then we'd be happy either way. With spin in the mix, you get four photon-like particles. And in order for them to get mass, the symmetry has to be broken making them into Goldstone bosons. In case of photons, what we have is the symmetry between the four bosons of the electroweak interaction being broken by the Higgs mechanism, which necessarily gives us one massless boson and 3 massive bosons. These are photon, Z0, W+, and W-. The thing about this mechanism is that it's not that a specific boson has to get zero mass, but rather, they are fully interchangeable and mixable before the symmetry is broken, and symmetry break causes a particular mixture to be massless, which is what we call a photon. Before we found Higgs boson, there was a period of time where people had increasing doubts about the nature of photons. Higgs mechanism implies existence of the Higgs boson, and initially, we thought it'd have to be a lot lighter, so the fact that we were turning up zilch in particle accelerators was making people weary. Consequently, people looked for alternative explanations for the electroweak bosons, and some of them would have implied that photons do have a bit of a mass, and people were looking for this. But then eventually the estimates on Higgs were refined, the mass was found to be much higher than initially thought, and it was finally discovered by LHC experiments, which finally had the energy range capable of creating detectable Higgs particles. So consequently, now we have a pretty big chunk of experimentally verified math that would have to be re-explained in the standard model if photons were to have mass. There would have to be something going on that's consistent with the known symmetries, provide a mechanism to create Goldstone bosons, account for Higgs, and still be different enough from Higgs mechanism to allow for mass of the photon, which would be quite a trick. And if something like this were to exist, it would certainly have other consequences. Too many very fundamental principles are at play for it not to. So if photons were discovered to have mass, it'd turn standard model upside down. Final note, there is still an ongoing search for something that's occasionally referred to as heavy photons. This is a distinct particle that has properties very similar to these of a photons but is very massive as far as particles go. I don't recall the exact context in which it appears in theory, nor really what the consequences of it would be, but it's just to give you a heads up that not all experiments looking for "heavy light" are trying to disprove massless photons. Most, in fact, are looking for a completely different particle. Not that there's a whole lot going on in that regard at the moment.

Surprisingly, no. Well, a little, but it depends. So if you want to get really technical, there is an entire branch of physics called perturbation theory. This is how you compute, for example, precessions of orbits. Things like Monlniya orbit are solvable and computable because we have perturbation theory. It usually deals with periodic perturbations that cause periodic motion to drift predictably, again, such as the precession of orbits, but it can also be applied to non-periodic input. Specifically, we'd be talking about Hamilton-Jacobi Equations. Math, loads and loads of math, but the bottom line is that instead of integrating forces applied to a craft in orbit, you can integrate the change to orbital elements directly based on engine thrust only. The advantage is if applied force is small, or at least comparable to the gravitational forces, the error is much less than if you integrated directly. But the math, Thor Odinson on a pogo stick, the math! In practice, it works out that you are better of using your basic Newtonian mechanics and a fancier integration method on a finer time step to get the same precision with less computation. Unless, of course, you have some special advantage of going with perturbations, like the periodic case mentioned earlier. So in practice, for what we're dealing with in KSP2, the fact that without engine thrust you're just flying a patched conic doesn't really help you get better results when engine thrust is applied. The advantages of going to a fancy method where that matters are outweighed by increased complexity of computations you have to perform for every step. So you just do the math, applying engine thrust and gravity forces to the craft, and in grand scheme of things, whether you have just one source of gravity or a whole bunch doesn't really matter. The reason why I think Intercept still wants to keep patched conics rather than just go N-body is because while it makes no difference to the craft flying under thrust, majority of objects that the game tracks are going to be passively orbiting, and for these objects, of course, the fact that you're on patched conics means you can just keep them on rails. That is, you still have to do SoI checks, but within a particular SoI, you just update the anomaly and keep all other orbital elements fixed. So while I think caching can, in general, be used to improve the performance a whole lot here, trying to compute the entire trajectory upfront seems impractical. I haven't tried writing an implementation for this, so I might be entirely off base, but going off the fact that KSP absolutely struggles to keep up with updating positions of on-rails craft at 100k time warp as is, simply because of SoI and planetary collision checks, even if we pin a lot of it to bad optimization, the idea that you'll perform the much harder computations of integrating trajectories several minutes ahead effectively instantly seems like a bit too much. Now, obviously, some sort of trajectory has to be projected forward, but I have a feeling this is another place where corners will get cut, and the future trajectory is going to be a very rough estimate for cases where you have the thrust on. I'm sure it will end up very close if there are no SoI encounters along the way, but it's these exact edge cases that make me worried and the reason I don't think simply storing this loose trajectory is going to cut it. You are going to have to recompute the integration in real time. Which is exactly where problems with flying multiple missions at the same time are likely to arise. Of course, I am making certain assumptions here about what is and isn't deemed as acceptable precision. Intercept might view this entire problem in a completely different light, and be perfectly happy with integrating trajectories ahead of time at whatever precision allows it to be feasible and simply storing the results for time warp. It's not how I would solve it, but I'm not the one making this game.

This is sort of what the eventual goal of HARP project was. Idea being that it's possible to build a sabot that will allow a rocket to survive a brief G-shock and remain operational. Then any cargo that can survive being fired out of a cannon is fair game. Alternatively, skip the rocket and use a skyhook instead. That requires a lot more infrastructure, but also makes bulk cargo launches dirt cheap. And skyhook itself is a megastructure, of course, but is not nearly as much of an engineering challenge as many other proposals. Plus, you'd be able to use the same skyhook with human-rated launches of much smaller/lighter rockets. So it's a great combination of launch systems to have if you are serious about space exploration.

Mhm. The unfortunate consequence is that as time step goes down, at some point, you'll have to start reducing warp factor as well if you want CPU to keep up. Which means that if you are flying multiple missions, a probe that's doing a slow burn to raise it's orbit in the home system could be limiting maximum warp of your interstellar mission. But this might be something we just have to live with, and you'd have to plan your missions accordingly. Or there could be some other workaround that I'm not thinking of. *shrug*

I thought we were trying to reduce energy use here. Of course, if you enclose the stream in some sort of a tube and confine the plasma, you can recycle it on the other end. But then you are just back to launch loop, and you might as well have a train riding in the tube.

Honestly, I'm more worried about the game handling it than players. Rotation is inherently non-linear and does bad things to numerical integration. It's fine when your simulation runs at a framerate much higher than the rotation rate, but for long voyages under warp, that just isn't an option. On a related sort of note, I do hope we'll eventually get some programmable parts. Building custom scripts to help with some navigation and control problems could be an interesting challenge for some. Though, that's another thing that I don't think will be available under warp as fun as it would be.

It might be actually be ice. Or some chute packing materials, maybe? I don't think this is indicative of any problem. Ultimate strength of steel can be about 50% higher than that of carbon fiber composite. This is approximate, because "steel" varies a lot, and so does carbon fiber. In contrast, density of steel is 4-5 times higher. So by weight, you need about a third of carbon fiber that you do steel. Again, roughly, depending on the exact materials you use and properties you're looking for. But it's very clear that while it helps close the price gap a little bit, it's still many times more expensive to build out of carbon fiber than steel.

Like, 95% joke, 5% "Wouldn't it be cool, though?" And I seriously think it would be a better startup than Spinlaunch. At least, it aims to do something you can't do with another method better already.

Sort of? But without need for maintenance. Not much of a fountain if you just yeet one piece of infrastructure per launch.

That's it. This is how we do it. A solid or hybrid motor rocket takes off as normal, and we fire fuel for its second burn out of a cannon timed for them to meet at some point during ascent. You get "gentle" acceleration for the cargo, making it potentially viable for human launches, and you still get to avoid building a massive first stage.

The only reason I can think of that this might be slightly problematic is if you want to start keeping track of resources required to adjust orientation. If we are happy with a fiat that the ship at this point has enough authority to adjust and maintain orientation with vectored thrust or what have you, then it's no harder to integrate e.g. prograde hold than a fixed orientation. So long as the direction of acceleration doesn't change much from one time step to another, it's fine.

As pointed out, that's the plan, but I also wanted to chime in to mention that this is actually a very hard problem, which is part of why KSP limited physics warp so drastically. To start with, each craft is a simulated object. Applying thrust can cause parts to flex, changing orientation of the engines, potentially, altering the net force if there are multiple engines working in concert. Even with a good simulation and optimizations, running this at 100,000x might be problematic to put it mildly. If the simulation still runs on PhysX, it's flat impossible. Of course, there are ways to work around that. Likely we'll see craft simulation "frozen" once it settles down and you can then increase the warp to a high factor. In a similar vein, orientation of the craft matters. If your craft is tumbling at a few revolutions per minute, well, your effective time step can't be larger than a few seconds. Again, if you're trying to run simulation at 100,000x for long transfers, this will be a problem. This is another place where we'll probably see orientation frozen, just like it gets frozen under time warp in KSP. Will this lead to players cheating and time-warping ships with unbalanced thrust? Maybe. Though, perhaps, a similar solution will be employed where your ship has to remain in fixed orientation for a bit before you can warp. Then we get into problems that are harder to work around. First, gravity is inherently a hard problem to integrate. Standard methods, even ones that are a touch fancy, like RK4, introduce fairly large integration errors. Even without thrust, an object you are simply integrating as it orbits a planet will be gaining energy. There are very clever methods, like ones used by JPL in their Solar System simulations, that do much better, but it gets computationally heavy and complex. For a game, you can get away with just making sure your time steps aren't too large. And it helps that this is more of a problem when you're close to a massive body, where you usually have a lower warp. Next we have SoI transitions. This one's a bit of a nightmare, as a glancing pass through one can give you wildly different results depending on where exactly you entered the SoI, and if your integration step was too large, you're going to miss it. Worse, as your integration step changes as you adjust warp, your predicted trajectory will jump. It also means that SoI checks are part of your integration routine, and while not terribly expensive, it's significantly more math than each integration step would have been otherwise. So it's going to be a significant CPU hit both in terms of computation complexity and reduced time step to preserve accuracy. Finally, the part that wouldn't be so bad on its own, but which can be a huge pain in the rear if you take all of the above into consideration. What happens if you are flying multiple missions in warp? Even in single player, ability to switch between several probes that are accelerating under thrust would be desirable, so you want to be able to time-warp multiple ships at once. In multiplayer this is absolutely a must. But does that mean you can't go to higher warp on your current probe if another is flying too close to a planet? What if the one you're currently piloting gets very close to something causing everything to drop out of warp entirely? What happens to all the other probes currently under thrust? Does their physics simulation remain frozen? If not, how do you fix any that might become unstable? This is one of these problems that becomes more complex the more detail you consider. And it has to be solved right in order for the game to be playable. So we'll just have to see what happens with all of this. I suspect, we'll have some hilariously broken exploits at the release that will get patched out as the game matures. Hopefully, nothing that will prevent people from having a good time with the game from the start, though.

Getting 2km/s from the ground isn't a stupid idea. Combine it with a skyhook and you can do away with a rocket all together. Spinlaunch just happens to be the worst way to do it.

This is what I'm thinking. I could swear we've seen some publicity images that included only the PS5 and XBSX logos...

If they got along and worked together, which requires the greatest stretch of imagination so far.