K^2

True story. I worked on a game, which shall remain unnamed to protect the innocent, where a bug was reported that was only happening on the full moon. After a few rounds of, "No way" - "But look at the crash reports," it was finally discovered that there was some old code for an event that was supposed to happen on the full moon years ago. The event was no longer happening, but the code checking for conditions and setting the variables was still getting called, and that change in state cascaded to an occasional crash due to unrelated mistakes in code. That bug got fixed, but since then, I take correlations between code stability and phases of the moon a bit more seriously.

This is absolutely true. If you ever hear your management say that the deadlines were missed because employees didn't work hard enough, look for another job. Even if you aren't implicated, start looking. That said, there's a bit of a difference between "Didn't deliver what's promised on time," and "Expectations expanded". It sounds like negotiations weren't just for extra time, but for larger scope of the game delivered at a later date, to which T2 were amicable, all based on reception of the teaser and consequent information in 2019. If the game was to be released in spring 2020, by early fall, the team should have been polishing and fixing bugs. If instead, they were working on new features based on T2 verbal assurances that they'll get more time, then by the time formal negotiations started in late fall, early winter, there was no way to ship the game in spring 2020, and that wouldn't be ST fault. They were working towards later release date in good faith. Nonetheless, it would be sufficient to give T2 grounds for contract termination at this point, because the existing contract did technically specify an infeasible date. We don't know if that's what actually happened. In general, deadline extensions are a tricky business. Both sides have to work in good faith, or at least one will get screwed. If ST continued to work towards spring 2020 release despite talks with T2 about extending deadline, a lot of that final polish work would have to be re-done. The game would take even longer to release, and it would cost more money to make, which would have to be reflected in new contract. If ST starts working towards new release date immediately, then they are technically in breach of contract until new contract is signed, giving T2 a lot of leverage. Of course, it's also possible that spring 2020 was never a realistic date, and that the game was heading for a delay even under original scope. That would give T2 a lot more reason to be upset. But it still doesn't explain why Take Two was happy to just hire back majority of these people, including creative director, to continue working on the project. If you have a studio that slips deadlines and negotiates in bad faith, it's never just one or two people at the head of the studio. It's always a team effort of at least several senior people in the studio. Primarily, because good managers simply won't work for awful ones. So the fact that T2 hired a huge chunk of leadership suggests things couldn't have been all that bad with the delay. Naturally, all of this is still speculation. It's hard to say exactly what sort of promises were made behind closed doors, and what sort of mistakes people made based on partial information rather than due to malice or negligence.

First, let me address physics. I lead an engine team, and animation and physics are my focus areas. We have an in-house physics engine which can compete with what's on the market, and will probably surpass Unity in a few important ways. What I've seen from KSP2 development on physics is not encouraging, and it has nothing to do with the time they have, but the very approach they've taken. Kraken shouldn't be a thing in KSP. Never should have been even in the original version. Certainly should have been fixed by now. KSP2 was a new start that would allow them to build it correctly from scratch, and they clearly haven't made use of opportunity. Given that vacancy for physics engineer is open, I don't see how they'd change such fundamental thing as craft physics by release. Lets start at the beginning. The fundamental concept in mechanics simulation is rigid body. It's an object that we take to be perfectly inflexible and incompressible. In KSP, pretty much every part is a rigid body. Some parts that have built-in joints have multiple rigid bodies, but if you think of things like fuel tanks and engines, each is a rigid body. You can't stretch them, can't bend them, and you can't break them into parts - only destroy the part entirely. (Which might spawn new rigid bodies for debris, but that's a separate story.) The rocket is built up of multiple rigid bodies, and there are several approaches of dealing with that. The most general approach is what game physics engines are all about and that is joints. If you want parts to stick to each other "solid", you use a weld joint. That's a joint that prevents relative motion and relative rotation of two rigid bodies. So if you attach two fuel tanks together, you can throw a weld joint in between, and now they behave like one fuel tank. Mostly. See, joints aren't perfect. They can't be, because there is finite precision in the simulation and the solver. I can read several lectures on details, but what it ultimately comes down to is that in pretty much every simulation used in games, any weld joint comes down to a very stiff spring. And that means that if you apply enough force, the joint will bend and stretch. And if you don't have enough damping, it can even have resonances. This is how the standard solver in Unity works, and Squad simply leveraged it for KSP. [Kraken is now following this thread.] But we didn't have this problem with a single rigid body. We can simulate it as a perfectly rigid object and have no worries. Well, we can do the same thing when we join things together. Instead of treating two tanks stuck together as two rigid bodies and a weld joint constraint, we can treat the two tanks stuck together as a single rigid body. The mass is just a sum of the two, new center of mass is easy to compute, and there is a formula for how to combine the two moment of inertia tensors, so that the combined object responds to torques correctly. This has been known for hundreds of years. What's the problem? Well, real rockets aren't actually rigid. Technically, no part of them is, but the full rocket certainly flexes under enough stress. And it's also not indestructible. Apply enough stress and it will snap. Obviously, ability of the rocket to break is something we want to preserve for the game. Fortunately, this is still pretty easy. We can actually solve for the motion of the rocket as a rigid body and then use that solution to figure out what the forces on all the welds would need to be. This approach still gives us a rigid rocket, but it lets us find out when forces got too much and lets us break the rocket if that happened. But what if we really want the flex? For a typical rocket, this really shouldn't make a noticeable difference, but if you look at wings of an airplane in flight, for example, the flex is quite visible. So if we want to be realistic, that should be accounted for. Fortunately, the amount by which any given part can deform before breaking is strictly limited. We can actually treat this as a linear problem. Compute stress on each part, and based on that, output the deformation. The simulation still treats the body as rigid for purposes of kinematics, as the shape hardly changes overall to a significant degree, but visual model and collision model would flex under stress. This would let the airplane wings flex under load, and even cause part collision if flex causes them to come in contact. The amazing bit is that all of this is computationally cheap and can be done in Unity entirely within C# component scripts. This can still cause destructive resonances, but only if you have forces that would oscillate with flex. So if you attach engines on long poles, the ship could shake itself apart, just like the real one would. But there would be no Kraken. Absolutely no way for a ship to just spontaneously explode, because there are no unbalanced internal forces! [Kraken has reported this post to moderators.] An argument can be made that KSP was initially built to leverage Unity physics without building a custom system. Later, Squad chose not to completely redo the physics, so as to keep the game working roughly the same way. I question this somewhat, because Squad clearly tried to address Kraken with multiple joints thrown in on connections and tuning the system, changing craft physics and strut-to-tank ratio in the process, so they could have replaced the system entirely with a better one, but they chose to tune the existing model instead. And things got better, but never fully under control. Regardless, KSP is the way it is. KSP2 could have started from scratch and built that system right. A good physics engineer would have. I don't know if ST didn't have one, or if that engineer got overruled by people who don't understand how any of this works, but we clearly didn't get a replacement system. Early footage of KSP2 shows a regression to how KSP used to look early on, with boosters bouncing all over the place, causing self-collision problems. And that's a real shame. This is something that just shouldn't have been a thing in KSP2. At this point, even if they hire a good engineer tomorrow, I don't know if they have time to fully address it in a year. On to other factors. KSP can have fairly complicated interactions between components. In KSP2, a lot of component code needs to be synchronized across network for multiplayer. There's a lot of custom code for UI, controls, and space center management. All of these things can use polish. They can always use polish. Lack of polish can cause performance issues, from bad framerate to lag spikes, and it can cause loss of network sync and crashes. The more time the team can spend on all of these the better the game will be. We aren't talking about game playing differently, but rather just players having better experience. Smoother framerate, smoother controls, less disconnects, less crashes. All good stuff. Can we expect these improvements? Hard to say. On top of delay, we also have disruption of work due to team transition. And keep in mind that if the game is shipping on consoles, Intercept now has less than a year until they have to submit code. Yes, it takes that long. And they're still a bit short on staff, on top of making up for whatever uncertainty there was in the past few months. From perspective of general stability, they'll definitely at least make up for it by having pushed out the date this much and maybe even get a little ahead. I expect that UI will be more polished and responsive and possibly the game overall will run smoother as a result of additional time. Multiplayer is a red light right now, because they did have to hire a new networking engineer and they are still looking for a multiplayer designer. Realistically, I'd expect some network stability problems at launch. Shouldn't impact single-player, hopefully, but you might want to be prepared to delay building that Mun base with your friends for a few months after launch to avoid disappointment. I'd like to be wrong on this, but I also think it's better to have low expectations that get exceeded in this particular case. One more thing we can talk about is rendering. There's not a whole lot you can do about rendering engine - it's Unity. But you can do a lot with shaders, which is a kind of programming. I have a lot less experience with graphics than other parts of the engine, but typically, this is just the case of the more time you have the better. The early pre-alpha footage we've seen needed a LOT of graphics work. But a lot of that could have been lack of content. It looked like Star Theory spent a lot more time working on assets for the ships than environment early on, and maybe that makes sense in terms of getting to alpha, but I really hope they've been putting some work into environments since, as that really helps to make the game look beautiful. So long as there is not a lot of work having to be abandoned and restarted due to whatever changes, artists and technical artists should just be making the game better and better looking with every month. It also sounds like a lot more of their creative team survived the transition, so I think this is going to be a pure win. On the net, if the game was to be rushed, I would expect Kraken special even on relatively small vessels with unplayable multiplayer, occasional lag spike, and some blandness or obvious flaws in graphics. If instead given sufficient development time, I think they'll tune the physics a lot better, but at release it's still probably going to be worse than KSP is right now, the network will probably be at least playable, but I still expect at least some stability problems, and the graphics is where I expect most gain due to delay. Both rockets and planets should look better for the wait. What remains entirely unclear to me is how much of the delay is to cover the "the game's just not even finished", which at least some of it clearly was, and how much will go into polish. That will shift the balance between the two extremes above. I suspect, it will land somewhere in the middle and we'll get the rest of the way with patches. And, of course, I'm basing all of this on VERY limited information, armed more with my experience with other studios and knowledge of Unity engine than facts about KSP2 development specifically.

Yeah, this is part where things get messy in Russian. The Russian word "shpaga" is derived from the name "espada ropera", but actually refers to an épée. The actual Russian word for a rapier is "rapira" and is derived from the name "espada ropera", just like the English analog. Yes, they took two separate words from the same Spanish name and applied them to two different, somewhat similar swords. To make things worse, the same two words are used for modern fencing foil and épée. Why yes, it does confuse people, how did you guess? English Language: "I'm weird". Russian Language: "Hold my vodka."

I mean, granted, cheap proton beams are comparatively simple, but this reminds me of, "We can build room-temperature controlled fusion right now. All it needs is inexpensive muon beams." Or my personal favorite, "We can have cheap nuclear isotope batteries with million times the capacity of LiPo. All it needs is inexpensive hard gamma beams to charge." Unfortunately, if you want inexpensive, safe(ish), and high energy and current, the only ones we've managed are electron beams. And even there, to get the kind of current you need for applications fancier than dental X-Ray, it's actually quite a challenge. I can build a proton accelerator with sufficient energy in my living room, unless my wife stops me, but I won't be able to generate a current that lets me go beyond detectable outputs without a budget of a modest particle accelerator and hiring people who know what they're doing to handle the build. Most accelerator designs just don't scale in terms of getting necessary currents. That's why magnetic confinement fusion still isn't a thing beyond experimentation. Still beats using neutrons. So maybe this approach has legs.

Yeah, a brief search hasn't pulled up anything terribly illuminating, but the more historical looking paintings depicting musketeers seem to show something that looks a lot more like French short sword. I don't imagine majority of them would have a dedicated dueling swords, so épée does seem like a stretch. But épée de combat is the sword that the upper class would use in a dust-up or a duel around that time. I wonder if Dumas made a mistake calling it an épée because it's a weapon he was more familiar with, intentionally called it that as a concession to his expected audience, or if people really did call short sword military used an épée, perhaps as a joke or reference to the fact that they're using it more often in duels than in combat. Or maybe I got it all completely wrong, and musketeers would actually walk around with épée de combat. I'm really curious now and would like to hear a take from somebody who's way more versed in bladed weapon history than I am.

In the original French, it's épée, which is also the English name for that sword. Pronounced a little differently, of course. Russian translation used Russian name for that type of sword, "шпага" - "shpaga", which is actually formed from its Spanish name, "espada". English translation of the novel, for whatever reason, just calls it a sword, which is probably why it was difficult to find the correct word. For what it's worth, I don't think a typical sword of a real Musketeer, or somebody who wants to become one, would be an actual épée, but Dumas called it épée, and it was portrayed and used as such in the fight scenes, so for the fictional character, I guess that's what it was. At any rate, épée is definitely the word you're looking for.

I would actually say that it is, in fact, uncommon to pull what T2 did. Screwing over contractors in general and even in-house studios isn't that uncommon, unfortunately. But this move combines the general horribleness of how major publishers treat small studios with extremely unprofessional recruiting behavior on top of questionable negotiation tactics. None of it is unique, but I really can't think of another example where publisher has gone this far. Though, yes, EA has certainly made strides in that direction. This one's also particularly painful because it was done via Private Division, which puts me in the mood for quoting Episode III, and that's just not a good mental place. I guess I can see why this doesn't look like all that big of a deal from outside. And one might even accept that it was done for the good of the KSP2 project. The problem is that if KSP2 really was in trouble, the best thing for it would be to pull the IP and give it to a studio that is entirely unrelated. Pulling in a significant chunk of the Star Theory means you're pulling in the process and culture. So if delays were the fault of Star Theory, they'll keep happening in the Intercept. Like I've said before, having to pull IP is not that uncommon, but you don't pull IP and give it to the same team. Not if you're doing it for the good of IP. And while Take Two's literal reason for existence is making money, meaning you can't really blame them for being motivated by profit above all else, the fact that they are disrupting development of KSP2 without a clear benefit for the game is, in fact, a breach of consumer trust. Whether or not to consider this an outrage worthy of boycott is honestly everyone's personal call. This feels a little personal to me, because I do work in the game dev, and I can understand that it doesn't touch everyone the same way. I have personally worked in a studio that had two months of negotiations with a major publisher for a contract or buyout. They intentionally dragged their feet, because they knew we're running out of money, and the contracts got signed on the last week we were able to keep our lights on. Ultimately, we didn't get a terrible deal, and while nobody got rich off of it, only one person, whose visa just literally could not be extended, lost their job. Most of us actually got a raise out of it. But I do know how it feels to have a major corporations intentionally make negotiations difficult, just so that they can get you desperate. Just so that they have leverage and final say. It's not a good feeling. What I can say objectively is that this was not a smooth transition. I mean, I'd be surprised if it was, but there are actual signs. Private Division still has job openings for some key engineering roles, some of which are difficult to fill with qualified people. I can't say for sure that all of them are due to transition, because I can't find exact dates that the openings were created, but this is an unusual number of specialists that they are looking for for a team this size at this stage of the project. It is, however, entirely expected if you transition the team from one studio to another. And this happens for other reasons with other studios and isn't that uncommon, but it's always disruptive. If Private Division and Intercept take their time and not rush things, all this really means is a delay. Possibly even one they already have factored into current release date, and this could still be smooth sailing for KSP2. The fact that they are lacking a physics engineer and a multiplayer designer only a year and change out is a concern, but not necessarily an alarm. That is, so long as we trust the developer and publisher to do the right thing for the game and not just rush it before the holidays regardless of whether it's ready. It all comes down to trust. I'm not going to give anyone buying advice. I'm not a neutral party twice over. First, because it is a little personal for me, and second because to be entirely honest, I'm probably working or will be working on project that will at least partially compete with something Take Two either published or will publish in the future. I can't think of anything specific, but I'm working under a broad umbrella, and T2 has a broad catalog of games. Instead, what I would recommend to KSP fans as a KSP fan and a game developer, is to pay closer attention to development now, especially as information starts getting revealed. Read reviews a little more careful. Reply in comments. Provide some feedback. I think Intercept are still trying to make a good game. I think Take Two will let them, so long as they see financial gain in releasing something that fans want, rather than a cheap knockoff that they can sell and run with money. Show them that they have to earn the trust back if they want return on their investment.

YongYea also did a coverage of this on his YouTube channel now. It seems to be catching. (Not going to link, since link to Jim Sterling's coverage link got removed, I'm assuming because of the harsh language used, and this one's no better.) I also want to add, I keep seeing some people talk about this as if it's par for the course. I've been working in game development for a while now, in studios covering a broad range of sizes. This crap is not the sort of thing that's done. Pulling the IP, that happens occasionally. T2 does own it, and if they have no trust in people developing the game they can pull the IP and give it to someone else. This is always sad to see, but it happens. That's not what happened here. First of all, poaching from contractor is EXTREMELY poor taste. I wish I could say it never happens, but it's rare, it's frowned upon, and even when an employee from a contractor firm comes to you and says they want to switch to your company, it's usually handled with care. Poaching a third of the studio in one go? That's extremely bad look. You buy the studio, then you offer contracts to everyone in the studio you acquired. I've been part of such acquisition, one that has been done purely to get the team, and acquisition is how it's done. Not a LinkedIn message. And these two things in combination? That's just bad. The fact that you're hiring back people from whom you've taken IP, including the team's leadership, screams that you're not doing it because of lack of trust in ability of team to develop the product. This is extremely scummy. Even by standards of large publishers this is bad. My trust in T2 handling KSP IP has hit an all time low. I'm also worried about the timeline now. Knowing the attitudes in game development, outside of a few team heads who were undoubtedly lured with very high salaries, people who went over to T2 are the ones who are less certain in their work, who are not sure they can find another job, and these are not your best people. All of the people who were critical to the project's smooth transition almost certainly left, because they can get another job even during a pandemic and they aren't going to take this crap from T2. (Our studio is still hiring, so are most others. I constantly get invitations from head hunters for jobs all over the country. It's not quite as easy as it was before pandemic, but getting game dev job is still not hard if you're good at what you do.) I'm sure Intercept will be able to staff these positions eventually, but that takes many months, sometimes over a year, and that means Intercept will not be firing on all cylinders for the near future. Looking at the current openings, they are missing some critical people, primarily in senior engineering roles that are notoriously difficult to fill, and which are absolutely required to ship a performant, stable game on a tight schedule. And this is entirely self-inflicted wound by T2, which will reflect on the quality of the product.

Jim Sterling released a video on this today, based primarily on the article, so this is going to be gaining popularity. Given Schreier's past journalistic work exposing bad studio/publisher practices, I'm inclined to trust it. Curious to see how T2 will respond. Warning for harsh language.

Confinement plays a very different role in fusion and fission. In fusion, you have to have high density and high temperature to get the process going. In fission, increase in temperature actually slows down the reaction, and the only purpose of increasing density is preventing neutrons from flying out of the fuel without contributing to reaction. There isn't actually a need for proximity between nuclei. Because of that, there are limits to how much you can decrease critical mass by compressing the fuel. And that's basically where all of this breaks down. You can take a fuel "pellet" that's significant fraction of critical mass of uranium and get it to split. Congratulations, you just invented a nuke. You cant go much smaller, because there is no amount of pressure that will get it to critical. Alternatively, you can try and look for fuels that will make explosions small enough that you can harness this energy inside a power plant. So something with critical mass in milligram ranges or less. Now we're talking about isotopes that have a very short half life and that you can't practically store, because even at decent spacing, placing enough of them to power a plant in one place is likely going to make the whole store critical. If you somehow manage to avoid that, the background radiation is still going to be quite significant. And all these isotopes will have to be manufactured by some other process. There have been proposals for making a big cave, dropping in a nuke every once in a while, and using heat of the walls to drive turbines. That is the only practical way I'm aware of of making a nuclear fission reactor that uses inertial confinement.

"If it was methane, it would be igniting in the flare, correct?" - *FWOOSH* Timing is everything.

Computers changed, in particular in the past decade, deep learning algorithms. Things they can pull from what seems like pure noise are pretty nuts. Like, mapping building interiors from Wi-Fi noise. Of course, I only have a bit of a view on the civilian side of things, and most of that is research, so as far as what they're actually installing on modern subs *big shrug*.

Cables and any other thin structures can generate cavitation noise at pretty low current speeds. So if there are anchoring cables, my guess would be yes on audible, but I have no idea if it's something that would be distinguishable from any other background sounds. Otherwise, I think the bigger problem is how the sounds are scattered. An artificial hull has very different properties from seabed, so even if the structure produces zero noise of its own, the background noise coming from its direction is going to be different, and I believe, modern passive sonars are designed to look for things like that specifically because it lets you find subs that are trying to play dead. As for how reliable that would be, what kind of ocean conditions it depends on, and what sort of range this might have, I got no clue. Realistically, I expect cutting edge on this to be heavily classified.

Western terminology. I'm talking about Блок И. There's no way it will be traveling fast enough before stage separation to coast to equator, so without ability to relight the engine, no way to do inclination change. Might work. TWR on RD-0124 is a bit on the low side for this, but I guess if people are discussing it, it's sufficient to make it work. I'm also guessing the main use would be for TLI, which should give you something like 2km/s reserve after parking in LEO. That's plenty to do the inclination change in question.

Soyuz spacecraft are suitable for fine maneuvering and spacewalks. So maintenance of something like Hubble by Soyuz crew is theoretically possible. The tricky part is getting the spacecraft to correct orbit. Hubble is inclined 28°, and Baikonur is 45°N. So a Soyuz launched from there would have to make a 17° inclination change. That's a whopping 1km/s of delta-V if you do it in orbit. The current variant of Soyuz spacecraft, the Soyuz MS, typically rides to ISS on top of the Soyuz-FG rocket. The later is capable of lifting 7,800 to LEO with Baikonur inclination. Soyuz MS is designed for launch mass of 7,000-7200kg. That's just too fine of a margin to try and start making inclination changes with. However, there's also Soyuz-2, which is designed to operate at least with Progress ships, and so might be possible to adapt to a Soyuz MS launch. Soyuz-2 can get up to 8,200kg to LEO, and that's a significant improvement. So what you do is you strap Soyuz MS to a Soyuz-2 rocket. You start a normal launch until second stage. Instead of burning to orbit, second stage inserts you into a rather unpleasant ballistic trajectory that gives you a good, clean opportunity for an inclination change at the apex. Because part of the acceleration is reserved to this stage, the inclination change actually costs a lot less than 1km/s. The downside is that failure to reignite second stage here will result in an extremely unpleasant re-entry with higher than normal G forces. But should be survivable and this is the emergency in-flight mission abort option, so that's fine? Maybe? Anyways, this gets you to Hubble's orbit, where you can do a spacewalk, using orbital module as an airlock, perform maintenance, and do a fairly routine return from orbit. Caveat on that last bit is that you couldn't land in Kazakh steppes. The most suitable landing spot for a Soyuz landing from Hubble's orbit is probably going to be in Australia with backups in Africa and maybe Texas? All of these are already on the list of potential emergency landing sites, but primary landing site would have to give agreement for a non-emergency landing. Australians certainly don't welcome spacecraft crashing on them without permission. *cough*SkyLab*cough* Naturally, nobody's going to do this. Not worth the risk and probably not the expense, either. But if there was more of a do-or-die sort of reason to pull something like this than fixing a telescope, I think it could be done.

Well, sure. You ram a high enough energy particle into medium, you're going to get photons. So a scintillator will light up for basically anything. Get enough high energy neutrinos flowing through, and that will do it too. You'll just need a really high neutrino flux or A LOT of scintillating material.

Not at all an expert on lasers, but two things come to mind. First, in order to get good coherence, you do need the light to bounce a considerable number of times in lasing cavity. That means, as you increase the length of the gain medium, clarity might become a factor. Depending on your gain medium, this might start getting to be a problem after a few dozen meters or after many kilometers. Increasing the length will also increase lasing threshold, requiring more pump power, and might reduce the overall Q factor. Second is pump power itself. There are a whole bunch of factors determining lasing threshold, primarily concerning properties of the gain medium and geometry of lasing cavity. Some of these might be adjustable, like dimensions and purity of gain medium, while others aren't. Metastable state of any gain medium has a finite and actually quite brief lifetime, which even at 100% efficiency on everything else puts an absolute minimum on energy density provided by the pump before lasing just can't happen. Unfortunately, I don't know even remotely where the limits would be. I have a tiny amount of lab experience with helium-neon lasers, but that's about it. Given that you need to fit a gain medium to scintillator, you need something tunable, so the only thing that comes to mind is organic lasers. And about all I know about them is that they cover a huge range of operating wavelengths from thermal IR to near UV, but it's also a huge topic with a lot of complexity.

You mean as a pump? Sure. You still need lasing medium, which is separate. Lasing medium needs to have an unstable state above a metastable one. The pump needs to take ground state electrons into the unstable state that almost immediately decays. As long as healthy fraction of it decays to that intermediate metastable state, you're good. The other requirement is that the pump doesn't interact with the metastable state. That is, there isn't a good state to raise these metastable electrons to. If you keep the pump running, you eventually get population inversion between ground state and the metastable state, and that's a medium ready to lase. What you use for the pump is entirely irrelevant. Soviet space laser gun prototype used flash powder, similar to what was used in old flash bulbs for photography. IR lasers use thermal excitations. And yeah, if you match scintillator to the lasing medium to act as the pump, it should work. Note that we're not talking about scintillator matching the actual laser wavelength. The pump wavelength is always shorter, and there's often an entire spectrum of energies that will work, so I'm sure there's a viable combination.

Entangled states can be as complex as you want. You can have an entangled state of three photons of which exactly one is left-handed photon, and other two are right-handed, with no way of knowing which is which. In that case, measuring a right-handed photon collapses the other two into a conventional entangled pair of one left and one right, while if you measured first one to be left-handed, you immediately know that both of the others are right-handed, and it's no longer an entangled state. In fact, this is part of what quantum computing relies on. All of the qubits of a general purpose quantum computer are in a complex entangled state with each other until you read off the answers. Even the simple QCs we're using now, like the quantum annealing computers are technically in entangled states. These states don't cover the full spectrum of entanglements possible with thousands of qubits, but they are still a subset. Another thing you can do is "amplify" entangled states. Calling it "amplification" is a bit forced, but that's primarily to distinguish from copying, which would violate the no-cloning theorem. So if I give you a photon in some superposition of left and right polarizations, it's not possible to create a second photon in exactly the same state that is NOT entangled to the first. That would be cloning and would allow us to find out the exact state of the photon through multiple measurements of the copies. But an entangled copy is fine. You can place a second photon in the state that has exactly the same weight of left and right polarizations but is also entangled to the first. So if first is measured to be left-handed, so will the second and vice versa. This is used in all sorts of schemes in both facilitating and breaking quantum encryption. For example, it's not possible to listen in on a quantum channel without it getting detected, but it is theoretically possible to create amplified entangled "copies" of the quantum key which can be analyzed after the original message is received to produce a copy of the key which lets you intercept communication. In practice, this can get very complicated, so I don't think anyone has been able to demonstrate a physical setup that can break quantum encryption. There's mathematical formalism for all of this. Essentially, any combination of pure states is treated as a coordinate in the state vector describing the system. Various operations and measurements are described with matrices. Operations with two photon entangled states are described with 4x4 matrices. For 3-photon entangled states you need 8x8 matrices. So things get very complicated very fast.

You wouldn't use the same, or even similar frequency for uplink and downlink even if you had separate antennae. You never do that when relaying signals. I'm not aware of a single telecom sat design that uses separate dishes for uplink and downlink. There are satellites with multiple dishes up there, but all of the ones I've looked at simply use it to increase the coverage area. My sample size was quite small, though, so it's entirely possible there are designs that split them up, but it's certainly not a requirement.

There are a lot of options, actually. Something like geosynchronous telecom satellite will have both the source and destination of the broadcast in the same general direction. So a single dish is just fine. If you have a bit more of an angle between the two, but it doesn't change all that much, you might use a single dish, but have transmitter and receiver in different places in the focal plane of the dish. That will allow receiving from one direction and broadcasting in another. Of course, if the angle changes, you'll need to be able to move at least one of the two, receiver or transmitter, and that's bound to have mechanical limitations as well as limited response time, but might still be better than having two separate dishes. There is also a limit to how much you can steer the beam from a dish antenna before you're no longer getting benefits of using a dish. Finally, there are antenna arrays. These can receive from multiple angles and broadcast to multiple angles, while still having all the benefits of having a focusing dish. There's also almost no time delay in steering the beam, as there are no mechanical parts to move. All you have to do is change relative phases. You can also build arrangements that can cover significantly more angles. In fact, a spherical array can basically be omnidirectional. I have no idea if anything quite like this has ever been installed on satellite, but flat arrays most certainly have, and they will likely completely displace dishes in satellites, as their only disadvantage is the cost.

Back when I did climbing, I knew a girl who couldn't do a single pull-up, but she was still a better technical climber than me. On the other hand, if you want to go up fast, that's a different matter. Speed-climbers tend to be very muscular, because it does take a lot of strength to go vertically at speeds they do. Since most climbers lift primarily with legs*, stairs are actually a decent point of reference. Almost anyone remotely healthy can climb a set of stairs. If you want to be able to walk a hundred floors, you need to be in good overall shape and might need a bit of endurance training. If you want to run up to the 100th floor, you need to be in top shape and do a lot of training for it. * Some technical routes intentionally put more emphasis on arm strength, and speed climbers use their entire body. But it's not critical for climbing in general.

Yeah, that's a very good point, actually. Do you think there's any problem with wider pipes for methane, though? This definitely sounds like extra costs, but if one set of plumbing can handle both, it's not too bad. Maybe some of the valves will have to be duplicated introducing some branching? The nozzle should be fine. So long as chamber pressure is comparable, which is why running fuel-rich is important, and overall flow rate isn't higher than what it's designed for, all you're losing is performance. I wouldn't want to use the LH2 in atmo with this engine, because you'll probably blow out the bell due to early separation and turbulence from it. But in vacuum it should just have less than perfect performance. There is still a possibility that a different working gas will result in a different set of resonances. That means engine has to be designed and tested with both sets of fuels, which is a significant overhead, but I think that sort of went without saying from the start. And I honestly didn't really think about injector plate. Yeah, that's a big one. I was picturing this like the injection in a turboject engine, where I'd say, "Worst case, install two sets." Just took a look at what typical injector plates look like, and nope! Not going to work. Yeah, I don't have a fix for this... Maybe some sort of retractable rods that change effective diameter of the holes in the plate? I have no idea... As an aside, it just occurred to me that we actually have an example of a formerly operational space ship that used two sets of fuel. LH2 and MMH, which is a hydrocarbon. That ship, of course, being the Space Shuttle Orbiter, used separate engines, separate tanks, and separate plumbing to achieve that. Real world rocket engines aren't as proportionally heavy as they are in KSP, but they are very expensive. If you have a reusable vehicle, having two of everything and a drop tank is entirely viable as demonstrated in practical use.

So this is a tricky one, because the engine is BY FAR the most complicated bit, and I won't pretend to understand every aspect of engine design, but naively, two main areas where you have problems with fuel substitution. Combustion chamber and pumps. Hydrogen, normally, burns a lot hotter in typical mixture and generates higher pressure. That's a big part of why you get better ISP out of it. But in theory, if you run your engine fuel rich at a lower thrust, an engine built for methane should do ok with hydrogen fuel. You aren't getting anywhere near the ISP of an LH2 rocket. Heck, you're probably not getting ISP of kerlox out of it. But then, you don't need to lift this fuel out of a gravity well. It's "free" fuel, so who cares if efficiency isn't great? The other part is pumps. Plumbing in general, I guess, but mostly pumps. And I'm way less confident on this. LH2 is stored at way lower temperature than hydrocarbon fuels. You'll also need to pump WAY more of it by volume to get the same mass flow. In contrast, hydrocarbon pumps have their own challenges, especially carbon buildup if you're using a turbopump. Building a system that can handle both seems like a technical challenge. But it's probably just going to be a heavier engine and higher price tag. Maybe that's ok? Also, for a lighter rocket with electric pumps, this might not be an issue at all. You just need it to handle lower temperatures and maybe live with a lot less thrust, which, again, for orbital operations isn't crucial. Finally, the tank's been mentioned, but I do want to point out that a tank for LH2 is way heavier than for methane, because it does need to withstand more pressure and cryogenic temperatures. Is that worth the savings you get on fuel you don't need to bring along? Maybe! This seems to fit an extremely specific mission profile, though. If you don't plan to burn a lot of fuel once in space, it's cheaper to just bring a bit extra for all your maneuvers than to build heavier tanks and engines to handle both types. If you plan to do a lot of orbital maneuvering, it might make more sense to just to deliver a stage to Earth orbit that's already built for hydrogen on whatever rocket you'd like to use and just go from there. But there could be mission profiles that need just an option of versatility, and somebody's willing to pay to have it. I can't think of anything, but it's not that far out there to be completely implausible.