K^2

Again, you are learning something from a game that has not even resemblance to reality at this point. Never mind gun range, if you are within visual range of an enemy fighter, you are both doing it horribly wrong. The first person to pick up the enemy on the radar lets the missiles loose, then turns around and runs. Because no matter how superior your stealth is, nobody's going to miss the launch, and once they see it, they can bring you up on active and get a lock to fire off a response before they turn tail and run. This is how modern BVR combat works and why speed is so important. Your survival depends on you outrunning the range on incoming missiles. This is the only game in town for modern air superiority, unless you massively outclass the enemy. In later case, you just shoot everything from beyond detection range, and your piloting skills just need to be good enough not to total the plane on landing. You have several people with actual flight experience and background in either making the planes, maintaining them, or in my case, writing sims for them, that are telling you that this just isn't the case. The fact that the sim has complexity does not mean that it's the same kind of complexity as on a real aircraft. Just because they did a good job replicating start-up procedure does not mean the plane actually responds to any of the inputs in a way consistent with physics. As I've told you, MSFS and X-Plane straight up do not simulate fighter aerodynamics out of the box, and I have not personally seen a single modded aircraft that fixes that. So is this thing. Do you know how much aerodynamic simulation it does? Zero. FAA has very lax definitions for what constitutes a training tool, because all it's meant to do is teach you how to read instruments.

First time I got into a cockpit of a WWII era plane and was asked to taxi, my response was, "How???" Even with conventional, raised cockpit, the nose-up attitude on the ground means you can't see in front of you. Solution? You weave a bit of a snaking pattern when you need to see forward, looking either left of or right of engine in turn. Naturally, it's not the sort of thing I would want to do while landing, but it works on the taxiway.

It's not forward speed, but transverse. In other words, even if you don't go fast, building prop for range of RPMs is hard. Right now, a near-constant RPM prop is cheap enough to be worth the fuel savings.

Maybe if you're in AF. If you're a general aviation pilot, you know that any fighter jet is called a lawn dart, but especially the F-16. Yes. And for F-16 best rate of climb angle is 90° with enough thrust left over to be "free falling" straight up settling on modest transonic speeds. Meanwhile, F-15 and F/A-18 do actually need a bit of lift to get them off the ground, but so little that it can actually be entirely body lift, with Israeli F-15 infamously landing without a wing. The way these aircraft stay in the air has more in common with physics of skipping rocks than aerodynamics of an airliner, let alone a general aviation aircraft. Most crucially, they aren't stable, with flight computer actually responsible for turning pilot's inputs into movement of control surfaces that result in the sort of movement of the aircraft that makes intuitive sense. When you pull on the stick in a modern fighter, it doesn't translate into movement of elevators. It translates into movements of every single control surface throughout the aircraft. This is almost never simulated in flight sims. Instead, they fake a conventional aerodynamics model that resembles the flight dynamics of a fighter, but which is, in fact, stable. The virtual control surfaces that simulation uses usually have nothing to do with locations of real control surfaces on a jet. Building an actual aerodynamic model of a fighter jet would require writing a dedicated flight computer for every fighter, and that's almost never done. Stock X-Plane and Microsoft Flight Simulator X jets most certainly do not do that, as I have messed with modding these. There might be some modded aircraft out there that attempt to reproduce correct flight model and flight computer behavior, but since all of the originals are military secrets, it can only be an approximation. Which is why bringing fighter piloting experience from a generic flight sim, not one built for military training, is just a tier above citing an action movie. They do replicate a lot of the flight characteristics, and some better ones even do a decent job in replicating the feel of flying such a plane. But they have almost nothing to do with physics of an actual fighter jet, because that's just not the sort of thing these games are built to simulate. It's also why I keep telling you to load up the C172. One of the nicer things about that plane is that it has a very simple aerodynamic model. Outside of wind shear, the hardest thing to simulate on it is p-factors, and that's not very hard. I cannot overstate the difference that a real cockpit makes with all the movement, vibration, that feeling of seat pushing into you as your wing load increases, and how you can feel every shift of the wind on a small plane. But all of that aside, even older flight simulators tend to do a good job of simulating how a C172 actually responds to input and how it behaves in the air. So it's a good test case. You can learn almost everything you need to know about flying that plane from a sim. Though, it might not be clear why some good practices are good practices until you get into a real cockpit and try to land a real plane. Oh, and don't get me started on tail draggers. No sim will EVER prepare you for experience of landing a tail dragger.

Yes, you adjust your elevators to set your air speed for VY or VX as desired with balls to the wall. Because elevator is used to control your air speed, and at full throttle, your climb rate depends on your air speed. And there's a reason F16 is called a lawn dart. Again, try landing a 172 in simulator using only a throttle. Set the trim for 60 knots and don't touch elevator controls at all. In fact, just unbind them. Might take you a few tries, but you'll be a better pilot with what you learned.

- "To change lanes, simply turn the steering wheel gently. The car will start to drift to adjacent lane without altering its speed." - "I just tried this. I jammed the steering wheel all the way and the car span out of control and crashed." That's not how you drive a car and it's not how you fly a plane. You're still getting that backwards. Airspeed depends on your AoA, and AoA depends on elevator settings. Yes, weight and balance will determine which elevator setting corresponds to what AoA. Again, you can't change steady state airspeed of an aircraft without changing AoA by changing your control surface positions. If you go faster, lift exceeds weight, and you accelerate up. You can't endlessly accelerate up, so you will reach a new equilibrium at some climb rate. And your equilibrium AoA doesn't depend on your climb rate or air speed, because it's just a balance of torques. If you are no longer climbing and your AoA is the same, then your air speed settled back on its original value. What other options are there? I can't help the fact that this contradicts your expectations. That never stops physics from working, I checked. And the rest is just confirmation bias, I'm afraid. Jamming inputs to the limits, watching plane do something erratic, and then divine some sort of pattern that matches your expectation is not the right way to check yourself. Trim an airplane for level flight at 70% throttle. Smoothly cut throttle to 60%. Wait for plane to settle. How much did the air speed change? How much did AoA change? What's your new glide angle? Next exercise. Put a plane in slow level flight on approach to a runway. It should maintain altitude and heading on trim alone. 1,000 feet AGL at 60 knots for a 172 should be good for this. Now try to land the plane without touching the throttle until you are wheels down. Repeat, but this time, land without touching elevator controls or elevator trim. Was that easier or harder?

You are getting yourself confused somewhere. When you throttle down, in steady state, AoA stays constant, air speed stays constant, and you descend. Your pitch angle changes, because your relative wind now has vertical component, so the same AoA means a more nose-down attitude. Likewise, if you throttle up, the nose goes up and you start climbing, but again, AoA and air speed stay pretty much constant. And the reason is that airplanes are intentionally built this way. The CoP of the main wing is behind CoG, which means that with no other forces, the only direction a plane would be going is a vertical dive. But the horizontal stabilizer on the tail is built for negative lift and is way behind the CoG. The net CoP is balanced on CoG in level flight. Now, if you apply external force to force a plane to pitch up, AoA on both the wing and stabilizer increases, which increases lift on the wing and decreases negative lift on the tail. This shifts CoP back and causes the plane to pitch forward. Likewise, trying to force the plane to pitch down results in CoP shifting forward and plane pitching up. Assuming all other factors impact your wing and stabilizer the same way, AoA is fixed in steady state and depends only on position of elevators. And because "neutral" position of elevators depends on your trim settings, when you trim your aircraft, what you're really trimming for is specific AoA. And as pointed out, if AoA is fixed, so is the air speed. Once airplane settles down to your adjustments, all forces and torques are balanced. (That's definition of steady state.) That means Lift + Weight + Drag + Thrust = 0. And unless you're doing something really drastic, Lift and Weight are roughly opposed and Drag and Thrust are roughly opposed. With this in mind, what @mikegarrison wrote should make more sense. If you keep your trim settings and throttle down, the AoA can't change, because your elevators didn't move. The lift hasn't changed, or you'd be accelerating down. And so the only thing a plane can do is continue at the same air speed, descending gradually, trading gravitational potential energy to substitute for reduced power from the engine. Now, all of this works to first order. Yes, real planes are more complex. L/D is not constant. It's a factor of absolutely every variable mentioned and a few that weren't. The wing and stabilizer do not respond the same way to air speed changes, because they aren't the same shape and there is air stream interference. If your climb/descent rate are significant, then your lift and weight vectors are not colinear. All of that means that in a realistic scenario, if you adjust one thing, you have to adjust all the others. It's not as bad as flying a helicopter, but you still have to coordinate your inputs. Nonetheless, if you want to descend, you reduce throttle and then correct everything else. If you want to slow down you pitch up, correct everything else, then trim if you're happy with the new speed. The intention is still tied to a specific input, with other inputs being corrective. Mentally, think of it as a difference between making small adjustments to the steering wheel in a car when you're hit by sudden gust of side wind vs making deliberate turn. You're turning the steering wheel in both cases, but intention and how you process it are very different. Disclamer: I don't have significant air time on anything larger than a C172. So this might not strictly apply to airliners, but I haven't heard anything that implies it shouldn't.

You're right. It's an inverse cube. Moon wins. I was extrapolating from actual movements of water levels in deep ocean and, you're going to laugh at this, but I forgot that the Earth spins. When I was extracting relative strengths, I modeled it as Sun going around the Earth in 24h, and Moon going around the Earth in 27 days. When, of course, relative to Earth, Moon goes around in under 25 hours, so the two periods almost match, with envelope modulated by the beat frequency.

Yes, graphics in a game engine usually runs on its own thread. What do you mean, that's not what you've meant? I agree that KSP2 will have to push graphics a lot further than KSP, but I'm not sure ray tracing will help a whole lot, and I'm usually the guy who pushes for broader RT use. It just... Doesn't help you render a planet, unless you throw a LOT of RT power at it. Talking about all the things Ray Tracing can do and how much of it you can support on next-gen is a complicated topic. Especially, because specs aren't public yet, so even things I know I can't discuss. But in broad terms, the hardware isn't quite there yet to just straight up ray-trace the entire scene and completely abandon conventional rendering. You need very complex BVH and a lot of rays to achieve that, and even 2080Ti just can't in realistic scenarios. Instead, what you normally do is render scene as normal, and then use RT to improve lighting or reflections. Again, speaking very broadly, you can improve reflections, global illumination, and shadows. This can be absolutely phenomenal for creating atmosphere in some games, but KSP2 doesn't have scenes where it pays off. Lets break it down a bit. I would broadly break down the components of the scenes into 3 categories. Planets that you're on the surface of or in low flight over, including terrain, sky, and weather rendering as applicable; planets that you're in proximity of, such as when you're in orbit; and your actual craft. You can have all 3. If you're flying over Lathe, you obviously have your craft, the terrain of Lathe bellow you, the sky above, and possibly, Jool occupying a solid chunk of it. All of these have to be handled differently. Lets start with planets you are orbiting. Can you improve these with RT? Maybe, but it doesn't seem cost-effective. The only fancy things that can be going on are things like crater shadows and atmospheric scattering. You can try to get that with RT, but you'll need a ton of rays to get good resolution out of it without noise. It's way, way easier to just write custom shaders for these things. You can get absolutely amazing looking planets with conventional shaders if people writing them understand light theory and scattering processes. If you don't, they won't write a good ray tracer, either, so all around, you're better off with conventional shaders. The planets you're in flight over are more interesting. Here, shadows really can be improved, especially, once you take global illumination into account. You can get better time of day and weather visuals for sure. But RT is still an expensive way to get these. And while it can pay off in very complex scenes, like if you're in a town or a canyon, where there are a lot of shadows from all kinds of vertical objects, you don't get much of that in KSP. The scenes we do get are pretty natural, and you can get very good look out of them by using prebaked lights. Can you get better quality with RT? On a powerful PC, yeah. On console hardware? I'm honestly not sure. But what you'll get won't be worth the effort. So conventional lighting still wins. That leaves the craft. This is the only part of the scene that might actually benefit from RT if it's done right. Baking light probes for your craft doesn't really work because there is staging, moving parts, and occasionally things explode. So getting good global illumination with rays is a lot easier. The craft can also have reflective bits, and SpaceX has demonstrated with a Tesla Roadster in orbit, planets reflecting off shiny bits make for great visuals. This would be a lot of work to get it right, though. Unity's support for ray tracing is still in preview, and you need people who really know what they're doing on this. Realistically, you'll need to hire a dedicated graphics engineer with RT experience just to work on this to get it in time for release. All the racing games devs obviously think it's worth it. But is it for KSP2? I don't know. And it doesn't look like Intercept currently has developer resources to throw around.

Oh, there are so many factors in local tides that go way beyond gravity. The day-night cycle is a lot faster than lunar cycle, obviously, and water has a lot of inertia, which means the two cycles will not have the same effect even if they were at the same strength. If you're living by the bay, the tides aren't due to water in the bay being pulled by gravity, but hydrodynamic flow of water in the sea/ocean around it, which is driven, among other things, by gravity. But how shallow the water is, how wide the inlet, etc, makes way more of a difference. In general, it's still synced to the tidal rhythm, albeit, with a bit of a lag, unless you're directly on ocean shore. And your highest tide is still going to be around the full or new moon, when Sun and Moon work in tandem rather than in opposition. That said, this also has negligible impact on rotation of the Earth. The water that's sloshing around bays and shorelines is just not enough mass to make an impact. And the tides in the open ocean are a lot simpler. There is still a factor of water mass, but topography no longer plays any role. And the Sun has significantly greater impact there than the Moon. Not by as giant of a factor as Sun/Moon mass ratio, of course, due to the distance difference, as you indicated, but noticeably. It's probably sufficient to point out that Moon is pulled on by Sun's gravity more than by Earth's, and Moon's pull on Earth is going to be smaller by the mass ratio of these two bodies. (Edit: Corrected by mikegarrison - tidal effect of the Moon is, in fact stronger. See link in quoted post.) Finally, the tides caused by Sun on Earth have absolutely nothing to do with Earth migrating from the Sun due to tidal effects. You should be looking at tides that Earth-Moon system is causing on the Sun. And that's a whole another story, because the Sun's movement itself is rather complex. It's not even at the center of the Solar System at the moment. So you have to talk about how all of the planets interact with the Sun together to see what sort of tidal effects this results in, and then propagate that back to individual planets to see how much they get pushed around.

True, but Jupiters' migration would have had to have been more extreme than what can be explained with tidal effects alone. So both friction, read, collisions with smaller things orbiting the Sun, and 3rd body interactions, likely with Saturn and the ice giants, were involved if all of this is correct.

No. Certainly not with anything organic. Carbon is even used to strip oxygen from metals - e.g. see how copper is smelted from malachite. There might be some fuels out there that you can oxidize with carbon dioxide, but they aren't anything that's going to be practical. And having either reduced carbon or carbon monoxide as part of your exhaust isn't going to be great either.

Yeah, outside of what's needed to survive the launch, they don't have any physical protection. Some warheads are designed to maneuver in atmosphere on re-entry, though.

Ah, yes, the Kzinti Lesson.

Not sure that's necessary. A near light-speed beam is not going to diverge a whole lot. You can either think of it as relativistic effect or as magnetic field generated by the plasma current. Either way, with enough energy, there just isn't enough time in proper frame for plasma to dissipate. I don't know if there is any advantage whatsoever over just lobbing a projectile, but making plasma beam weapons is actually way more plausible than you'd normally think.

Releasing cross-gen should be fairly straight forward with the next generation. Microsoft actually has a Smart Delivery program that lets you publish your game for XBox One and Series X as a single SKU. It's basically counted as a single game on your XBox account, and it will download appropriate version for the correct system. We're yet to see if Sony has anything similar planned. There is going to be far less change in hardware between generations this time around. We still get substantial performance upgrades, but the core architecture stays the same. The shift from Cell/Xenon to Jaguar during last generation meant backwards compatibility was hard to achieve and even ports had to be rebuilt to fit new consoles. This isn't the case this time around. All four consoles in both generations from both Sony and Microsoft are built on AMD x64 technology. So the amount of work necessary to make games cross-generation is comparatively small. This is made further true in KSP2 case, because it is built on top of Unity engine. Almost all of the platform specifics are going to be handled by Unity. Odds are, the PS4/XB1 version of KSP2 will just build for PS5/SX if you simply select that build target in Unity when exporting the game. Naturally, to take full advantage of new capabilities, some additions will need to be made. Primarily in UI, social/match-making features for multiplayer, and graphics. At a minimum, you'll probably want higher resolution textures for next gen. But the team might want to also adjust things like LoD settings, vegetation and rock densities on planets, and other little improvements to the look of the game. This kind of work isn't exactly free, but it can be handled by a small group of devs, as it doesn't actually involve remaking content.

Yes, railgun will still fire. Water isn't THAT conductive, even sea water, and path of least resistance will still be through the projectile. Efficiency might drop both due to resistance and to some of the current flowing via other paths. It might also fry control systems or the capacitor itself, as it's likely to draw more current than normal shot. And just like toaster in the bathtub, it's not inherently deadly. There still needs to be a reason for current to travel through your body. It doesn't take a lot of current through human heart to stop it, and there is going to be quite a bit flowing through water, but the electromotive forces are going to rapidly decay away from the rail, and you still need to create a potential across the heart, which would take some unfortunate positioning of things. I wouldn't feel confident firing a railgun under water just for the hell of it, but if it's a life-or-death situation, I'd probably take the risk.

It should be pretty easy to park a rocket in an eliptical orbit with periapsis just above the atmosphere. Then pick a much bigger circular orbit to try and match. You have two good options for a transfer burn. From periapsis or from apoapsis. Both can get you to the target circular orbit with two transfer nodes (one at your original orbit, and the other at target to circularize). And it should be very easy for you to compare the amount of fuel required to complete either of these two maneuvers.

You're not wrong about current gen of console CPUs. But KSP is also the kind of game where it matters the least. There are basically two things the CPU is in charge of. Feeding the GPU with draw calls and running the game. The former can be pretty complex in general, depending on how busy your scene is, but even on the planets, there just isn't enough going on to give even the base model PS4/XB1 any difficulties. The fact that it's Unity is a significant overhead, as specialized engine could have taken better advantage of nuances of the game to make rendering even cheaper, but even with Unity, there just isn't enough complexity to make it a hard problem. So we are left with the rest of the game. AI is only expensive if you have complex path finding or strategic gameplay. We can discard it right away. Even if KSP2 has some sort of AI ships, Total War it is not. You can do all necessary nav computations on a TI-83. The real sinks of performance are usually animation and scripting. The later almost exclusively due to poor implementation, but nonetheless, it is a fact we generally have to live with in game dev. Writing a scripting system that will keep your designers happy, prevent them from doing horrible things to your game, and at the same time runs at a reasonable pace requires an horde of developers. Because we have budgets and you just can't make designers write better scripts (we tried), sacrifices in performance in the name of simple, maintainable code base is how it goes. Fortunately, KSP is not the sort of game where you have five thousand behavior scripts running on every single component. All of the critical systems are hard-coded in C# and what little scripting you need for missions is cheap. Animation - I don't think I need to even talk about this. I'm sure the anim graph for that one kerbal you have running around the surface is actually quite impressive. But you're still animating just one character at a time. Even scaling up to a few in multiplayer is not breaking any CPU budgets. On to the exciting bit. Physics! Normally, in most games, this is barely a speck. The reason is, you can't write a physics engine if you don't know what you're doing. You can write a script parser following a YouTube tutorial. You can write an A* path finder following the Wikipedia article. You can even write a crap renderer by following one of these "Make a Game" books. You aren't writing a physics engine if you don't have a few years in Classical Mechanics, Differential Equations, Numerical Methods, and a lot of CS courses (or equivalents!) to tie it all together into practical understanding of simulation. So you know which part of absolutely every game engine I've ever worked with is polished to an absolute perfection? No, actually, the math and vector libraries, but physics takes a close second. The simulation itself isn't always great, because some games have taken an oversimplified approach, but if you have a good quality simulation, it's usually one of the most performant parts of the engine as well. You just can't screw it up without screwing up the simulation itself and having absolutely everything explode instantly. Unity is built on top of nVidia's PhysX engine. I have many complaints about that one, but performance isn't one of them. That thing has a multi-body solver that is well optimized and it's paired with a very robust collision detection. KSP has a bit more going on in terms of physics than most games, but it's still a pretty straight forward proposition. The absolute worst case is a ship ascending through atmosphere. You are on high part count, there are a whole bunch of active weld points acting as constraints on a multi-body solver, majority of the parts are generating aerodynamic forces, there are more potential intersections than ever to keep collision detection busy, and you might have physics warp enabled on top of it just to make things extra bad. You can throw enough parts at a simulation to make it a workout for any system. But the crux of it is that this won't get any worse in KSP2 compared to KSP. This is just something that the game has to deal with. And if KSP runs fine on a current gen console, there isn't really anything you can add to this in KSP2 that would require the next gen CPU power. Oh, sure, there will be a lot of advantages of running on next gen. You can throw in way more parts and still have a good framerate. A complex rocket on a large planetary base in KSP2 might give current gen of consoles a heart attack, while running perfectly fine on PS5 and SX. But this is something that PC gamers already have to deal with. If you want to build a giant monstrosity in KSP and have a smooth framerate, you better have a beefy PC to run it on. It's not really a reason not to allow PS4/XB1 players to even try. There will be a whole bunch of other things. The GPU on next gen can handle a lot more, and that means it will require a lot more of the CPU attention. Multiplayer servers could have much higher player caps if the host is running it on a next gen console or beefy PC. There will be good reasons to play KSP2 on either a next gen console or a modern PC, I have no doubt. But none of it makes the base game fundamentally unplayable on PS4 or XB1. Or on essentially the same PC hardware that KSP currently runs on. There could be any number of additional considerations going on in the background. I'm not going to pretend to have all the pieces of the puzzle. And overall, KSP2 can end up being way more CPU intensive than KSP, requiring a lot of people to upgrade. But saying it's unwise to try and get any next gen game to run on PS4 and XB1 is uniformed. KSP2 is a perfect example of a game where simultaneous release on current and next gen makes perfect sense as an attainable goal. It will sell way more units this way, and if you throw in a free next-gen upgrade on consoles, you might even be able to make deals with Microsoft and Sony to subsidize you somewhat, because it will help push next-gen sales down the line.

Yes. A 24h real-time build delay, which you can't speed up with warp for an unexplained reason, but you can rush with Kerbal Diamonds. What are Kerbal Diamonds? Glad you asked. They are a new resource you can use to speed up construction of rockets and buildings, buy research levels, and customize your Kerbals! You get 100 Kerbal Diamonds just for signing up, and after that, they are available with convenient purchase options for $2.99, $7.99, $14.99, and $49.99 for the best value! Just joking, of course. (I hope. ) But in all seriousness, if construction time is tied to the simulation time, the only thing it really changes is you have to leave yourself margin on transfer windows. You can always warp forward to when your ship is ready to go. So I don't really mind either way.

Mars is low enough gravity and thin enough atmo for rail launch. It's effectively free to ship cargo from Mars once you have an industrial base there.

I'm very far from being even competent on exogeology, but it seems like Mars has way better odds of having abundance of metals near the surface due to volcanism and tectonics in its past. Best chance for metals other than iron oxide and a handful of others on lunar surface is meteorite impacts. If we can get everything we need on the Moon in abundance, great, but it seems doubtful from the first glance. Just looking at general mineralogical composition, there's no carbon on the Moon. Even if you find a way to refine iron from the oxides found on the surface, no way to make such basic material as steel. Copper also looks like a problem, so aluminum alloys are also a problem. Mars has far richer geology and seems like it would give great opportunities for mining. Mars is also conveniently located. It's a little far, true, but there are known cycler orbits that would make it very convenient both to send equipment from LEO or lunar gateway to Mars and to send goods from Mars to Earth. Shipping down here on Earth can take months, we still get things manufactured where it's cheap, not where it's convenient. 7-8 month shipping time from Mars seems entirely reasonable. The next convenient mining location is the asteroid belt. The problem there is that while it's pretty good for raw resources, it's not fantastic for actual industry. A lot of the things we make require an entire pallet of raw resources. The simplest of titanium alloys require a source of titanium, aluminum, and tin. Good luck finding all of that on the same asteroid. And failing that, moving things about the belt is actually awkward. Depending on how quickly you want things moved, sending things to Earth might be cheaper than moving things from one part of the belt to another. On Mars, while I don't expect all of the necessities to be found conveniently in one location, you can have a literal railroad moving raw resources about. That planet's practically made for being turned into a giant factory. The only significant problems are the dust that you'll have to deal with and lack of rivers and lakes for easy cooling solutions. But this feels less like a barrier, and more like reason to build infrastructure differently.

I think it might, actually. With tech we either have or are reasonably certain about, combat isn't going to be an up close dog fight. It's going to be ships lobbing missiles at each other from very, very far away. In which case, building a ship around a massive railgun seems like a way to go. I just can't think of anything that trumps that. A rocket seems like it's only going to be useful on terminal run. Firing engines early on is just another way for your opponent to have early warning. Yeeting a small missile at high acceleration from a railgun gives you best chances of surprising enemy fleet, and the missile can use small rocket engine to make final course corrections with insufficient warning for enemy to do anything about it. Then you just go for a kinetic kill, and that's all she wrote. Given that time between firing the missile and it punching holes in the other guys' hulls is going to be measured in hours if not days, the fact that it might take a few minutes to aim the main gun by rotating the entire ship seems insignificant.

It's less of "Why not Mars?" and more of, "Why Mars specifically?" Yeah, I'm sure we can turn Earth into enough of a toxic dump that Mars would be acceptable as an alternative. "Same toxic soil and unbreathable atmosphere, but with way fewer neighbors? I'm in!" The problem with that is by the time we can start turning Mars into something self-sustaining, we'll have better options. Mars provides minerals and ice. So do a lot of asteroids out there. Mars provides a little more than 1/3 Earht's gravity. Is that enough for long term habitation without severe health issues? I don't know. I do know that a centrifugal station in orbit doesn't cost that much more than Mars habitat, and will give me a standard gravity making sure I stay healthy. Everything about Mars that feels like an advantage at the first glance is actually just more problems. Gravity? Just makes coming and going harder. Atmosphere? Barely there, but enough to result in dust storms. Radiation protection? Moving a bit further from the Sun, into the asteroid belt, is actually more effective, given the lack of magnetosphere on Mars. In a lot of ways the Moon is a better place for permanent habitation, and that's not in my top 3. Short term, Mars can turn into a fantastic industrial base. If we crank up environmental protection laws on Earth to 11, it might be cheaper to do metallurgy and maybe even a lot of fabrication on Mars. But I wouldn't expect anyone to actually be living on the planet for that. To extract intermediate products from the surface and to bring in equipment, there will have to be a robust rail-launch system on the planet. So it's going to be way better to have workers have permanent habitation on Mars' orbit, probably collocated with all of the shipping, and have workers come to the surface to work. It's likely to be fly-in, fly-out setup, rather than commute, but it's still going to be closer to our presence on ISS than a real permanent habitation.

The first step in making steel is making pig iron. That is followed by all kinds of purification steps to make high quality steel. How you make pig iron has little effect on quality of steel you're making - any quality of pig iron will require purification and burning off excess carbon. So I wouldn't worry about quality of steel degrading due to coal becoming more expensive. And yeah, you can substitute coal with pretty much any carbon. Charcoal has been historically used, and while there were a lot of benefits of switching from charcoal to coke, most of these can be rectified with modern industrial processes. So bio-sourced carbon is definitely on the table. Air capture would be very expensive, but if carbon tax is implemented, we might have a market for carbon captured from industrial waste. Turning CO2 into carbon you can use in metallurgy is a bit of a process, but it's definitely an option. All that said, I suspect we'll be sticking with fossil fuels for blast furnaces for quite a while still.