Starman4308

There's also the matter of having multiple lines of evidence. With something that far outside our current physical models, "this experimental design has a flaw" is more likely than "models which have stood up to everything else are wrong".

1) Cold fusion is basically "one botched experiment showed it", followed by endless wishful thinking, conspiracy theories, and precisely zero actual credible evidence. 2) Our theoretical understanding of physics says "this isn't even remotely plausible". You need staggering amounts of energy to get past the Coulombic barrier* between nuclei, and that requires some combination of extreme temperature (giving nuclei lots of kinetic energy) and extreme pressure (giving nuclei lots of potential energy). Cold fusion doesn't have the former by definition, and the latter requires pressures that make "formation of metallic hydrogen" look tame. 3) The process for manipulating metallic hydrogen to begin fusion is "exactly the same as for regular hydrogen": you add a lot of heat and pressure to it.

Very, very impressive. One thing I'm wondering about, though, is whether the benchmarking may have been affected by the sheer simplicity of the rocket design. Most designs flex a bit, and that plays havoc with the rigid-body physics of KSP. However, your design had excellent symmetry, with each segment having exactly the same mass and exactly the same thrust: any flexing at joints was quite minor and didn't need much time to solve.

The primary limitation to multipurpose industrial robots isn't the form factor. It's the programming, and to a lesser extent, some types of sensor like smell and fine touch. Humanoid robots without the programming for multiple tasks is just a waste of money... and once you have the money to write the software for a new task, you may as well build a bespoke robot (not to mention fewer things can go wrong with single purpose equipment). A humanoid or other general purpose form factor (e.g. spiderbot) really needs strong AI to kick off.

Mostly YouTube or other web surfing on a second monitor. RO means large dV requirements, and it's cheaper to skimp out on probe thrusters, so 4-20 minute burns are not atypical.

What I've heard about Take Two: An boilerplate EULA whose more plausibly threatening terms were never enforced. They briefly shut down a mod for GTA that did break EULA and permit breaking DRM. None of us know for certain what went down, but given the kneejerk reactions many have to anything Take Two does and the sensationalism that surrounds it, I'm inclined to give them the benefit of the doubt. I'd give Star Theory the benefit of the doubt as well, but Star Theory is no longer in existence. I can't not-boycott a company that folded. Overall, I'm glad for this thread, because I did have a very negative reaction based on that Bloomberg article, and some of the comments here made me remember "oh yeah, media coverage is frequently sensationalist and there may be much more to the story".

Short version: insufficient data. Long version: I've found most of the flak leveled at Take Two laughable, with this being the first real concern. What reassures me somewhat is that job offers were extended to nearly the entire team. This likely was not a cost cutting measure: you don't offer incompetents a job or needlessly disrupt an effective team. It's entirely possible that one too many insults was passed at the negotiation table and Private Division went for the nuclear option. Never discount ego: businesses are made of people, and people occasionally do irrational things. A bit of time will help clarify things: if this was a one off event, or if Private Division will make a habit of hostile takeovers.

For this to work: there is a hard constraint that exhaust velocity must at least match your velocity relative to atmosphere. It's actually a bit of a thorn in the side of any sci fi writer who wants spaceships refueling by dipping into the atmosphere of a gas giant: for that to provide net propellant, you need something like a fusion torch as your engine.

My understanding is that floating origin/Krakensbane solved the most problematic issues. While there's minor inaccuracies caused by 32-bit floating point, it's definitely playable. Most RSS issues are caused by a patchwork of multiple mods, rarely still maintained by their original authors, on top of the kludgy mess that KSP itself is. As to the thread topic: I'd maybe prefer some scale up, but a smaller system does ease the learning curve. RSS, scaled or not, also conflicts with the core interstellar aspects of KSP 2; it's intended to feature additional solar systems. With RSS, many are the lightyears to "nearby" exoplanetary systems.

Weeks at best, quite possibly months to complete a realistic ion engine maneuver at 4x timewarp.

Unrealistic does not mean unplayable. In this case, the Dawn engine would be unplayable without either unrealistic stats or on-rails thrust calculations Persistent Thrust style.

First, that's a hair cheaty. Second, unless you're trying to use vacuum engines, 100 m/s is likely a huge overestimate. It gives you an almost negligible amount of velocity and gravitational potential energy. You do have less back pressure from atmo, bringing Isp closer to vacuum levels, but you're not going to get enough to justify switching to vacuum engines without either mods or craft file editing.

There are several misconceptions in your post. 1) Just because a AAA publisher is backing the title doesn't mean they give AAA resources to the game. It's being made by a small team on a tiny fraction of the budget Take Two allocates to their AAA titles. 2) A better game engine will not help. Nobody in game design is possessed of a rigid-body physics engine meaningfully better than the one in Unity, and that is the bottleneck. 3) Unless I miss my guess, the KSP 2 team is doing something far smarter than trying to parallelize the monstrous problem that is rigid-body physics. They're probably going to do some sort of static or dynamic parts welding, treating groups of parts as a single part where the rigid-body physics engine is concerned. That scales up magnificently without requiring them to write a high-performance rigid-body physics engine from scratch. 4) Writing a better rigid-body physics engine won't help much, because the problem is inherently difficult to parallelize due to the self-consistent nature of trying to solve a large set of rigid-body constraints.

I think there was at least one point where KAC stored settings in GameData, and there's some mod in my current RP-1 install that occasionally triggers an MM cache rebuild.

For moddability, portability, and ease of sharing save files, flat text continues to be a good choice. Something that would add a bit of complexity would be to essentially bake MM into KSP 2, such that you can have "source" flat-text files in GameData with a cache that can be rapidly loaded if it hasn't changed. Hopefully, modders this time around remember to store settings and other mutable data outside GameData. For save files, they may consider bundling a save file converter which would let the player extract binary save files into flat text and back again This would have the effect of making life a bit more difficult for people who frequently manually edit or view save games, but is at least a compromise between speed and viewability/moddability.

With RP-1, this becomes a much more substantial question due to tooling costs. Due to that, I tend to go for a low-thrust sustainer core that can just barely get off the pad, then slap on boosters as needed for heavier payloads. This results in OLV families with 0-8 boosters, occasionally including 1-booster designs, and sometimes with alternate booster selections. For example, if I need just a little extra thrust, I may slap on 2-4 Castor 1 SRBs, whereas more demanding payloads may call for a pair of LRBs.

A good bet would be to park the return vessel at a Lagrange point, Eyes Turned Skyward style. It's a little bit more dV-intensive, and means a longer trip back to the return vehicle, but you can get to a Lagrange point from any point on the surface for roughly the same cost, letting you pick landing sites at will. I would rule out the high mountains unless a specialized lander is developed, as beyond the roughness of the terrain, you also need to deal with how thin the Martian atmosphere is up there. Seismic activity is likely a non-issue. Mars isn't 100% seismically dead, but it's not exactly prone to massive quakes. Radiation protection is likely a matter of mission duration. Short-duration, you can get away with minimal shielding. Long-duration, and you're probably going to want to set up your base underground... which incidentally solves some dust-related problems. Power: for a short-term mission, you can probably do solar panels + batteries (or regenerative fuel cells). Long-term, you can do either solar cells + wind turbines w/ storage, or go for a buried fission reactor. The latter also has the advantage of providing all the heat you could ever need. Heating: insulate the floor, and with how thin the Martian atmosphere is, you're probably not going to need much heating. This will be less of a concern if a fission reactor is used for power. A lot of choices depend on mission scope (30 day flags-and-footprints or multi-year base) and whether the local terrain is amenable to underground bases. I believe there's at least lunar proposals to use lava tubes to put the base in, though I don't know offhand if there are similar features on Mars one could exploit. Digging out your own cave is all fine and dandy until you try to figure out just how much Marsmoving equipment you're going to need for the job.

I'm given to understand it's generally been the expectation that pilots be allowed to parachute down safely, even if it's over their own territory where they will undoubtedly be back in action the next day. It's been a while since I read about it, so I'm fuzzy on it, but I'm given to understand at least one WW 2 ace pilot was vilified for shooting pilots under their parachutes if they were over their own territory (though he did refrain from shooting pilots down over his territory under the assumption they would be captured). It does not hurt matters that there are frequently more pilots than aircraft available: the loss of just the aircraft is still a substantial blow to the enemy's capacity to wage war in the air. Now, as to whether this is morally consistent with how soldiers of other services are treated, I'm less certain, but so long as both sides agree to fight by the same rules, that's OK by me. These escape systems are probably bending the rules, and I could see countries saying "nope, you're not going to do this with us", but these systems would basically amount to a roughly ~100 mile extension of "we still won't shoot you under your parachute if you're over your own territory."

I did a bit of research, and it'd be hard to pull off. The concept is more than a bit hampered by the general awfulness of trying to get buoyancy in a mostly-hydrogen atmosphere. I don't have the time to iterate over the entire parameter space, but I have a suspicion that you might want to go below the 1-bar level just so atmospheric density increases. I assumed a 1000 ton reactor producing 100 MW of thermal energy, with the hot gas inside the balloon maintained at a nice cozy 298.15K (room temperature). I ballparked the Jupiter atmosphere as pure H2 at 200K/1 bar. To maintain 1000 tonnes of buoyancy, you'd need a spherical balloon 200m in radius. I then assumed as insulation it would have 2.5mm of fiberglass (which would itself mass ~2200 tons), and I got a heat loss of 893 MW, about 9x what is being produced. Submarine reactors with fiberglass insulation probably aren't the way to go. Hyperion claims they can build a 15-20T reactor producing 70 MW of thermal energy, which is a roughly 35-45x improvement in power to mass. An array of these would get you past the break-even if the balloon itself can be made lighter. Advanced foam materials are better insulators than fiberglass, though structural integrity is also a concern.

Really, I think the low temperature at the 1 bar mark is a plus. You're going to need a hot-gas balloon anyways. With a low baseline temperature outside the balloon, you don't need the balloon to be as hot to get good buoyancy. This also serves as a low temperature heatsink for fission reactors, or a nigh-endless source of hydrogen if you assume the presence of a fusion reactor. Solar panels aren't very effective out there, and wind turbines would require you to be attached to a solid surface; fusion/fission is the best idea I can conceive of anyways. I could easily envision having a fission reactor at the bottom, cooled by hydrogen gas cycled through the balloon. Convection currents inside the balloon should really help. And hey, there's one more advantage to balloons on gas giants vs. Earth/Kerbin: no pesky O2 to ignite after a lightning strike!

As always with this sort of system: one constant tradeoff is that added mass means less range/speed/maneuverability, so heavy abort systems mean you're more likely to get shot down in the first place. Another factor is "how easy is this to operate for a possibly wounded and likely disoriented pilot?" There's also the (small) possibility of being mistaken for a still operational aircraft and being shot down again... this time with a lot less aircraft between you and enemy fire. And now that I think about it, while an enemy pilot might not intend to shoot you down, a heatseeker that can't tell the difference between the Sun and an enemy aircraft may not be able to tell the difference between one of these concepts and a jet exhaust... How worthwhile this is depends strongly on what sort of treatment a captured pilot can expect. Overall, I would expect these sorts of systems to lead to more overall deaths*, but that may be worthwhile against a foe with particularly poor treatment of prisoners. *Predicated on the assumption that parachutes are pretty good at getting you down to the ground alive, many of these concepts require the final stage to be a parachute anyways (thus not even eliminating parachute-related risks), higher likelihood of being shot down in the first place, and possible (accidental or intentional) double-shootdown. Many of these autogyros look a lot more like an aircraft than a guy in a parachute, after all.

The impact should be minimal unless the dev team is composed entirely of 80-year-old smoking diabetics with heart disease. Productivity will take a short-term hit due to lack of face-to-face meetings and some people are simply unproductive working from home, but I would anticipate less than a week of overall development lost.

There are two problems, both of which are fundamentally because Gilly is way too small for practical slingshot maneuvers. 1) Unless you can borrow NASA's supercomputers, you're going to waste more dV setting up Gilly encouters than anything GIlly actually gains you. 2) Even if you could set up the slingshots with superb precision, it would take a very long time, as each slingshot provides only a very small boost. It'd also be impossible to use Gilly for the final gravity assists. You'd need to use Gilly to kick yourself into a Kerbol-centric orbit, and then use at least a few Eve encounters to boost up to a Kerbin-crossing orbit. Eve is a practical slingshot target, but slingshots work poorly when relative velocities are low (as would be the case from a "just barely ejected from Eve" orbit), so you'd need several slingshots just to build up some Eve-relative velocity. Now, if he had a bit more dV to spare, I might suggest kicking himself into a Kerbol-centric orbit and using Eve slingshots to go to Kerbin, but with the dV he has and the absence of any practical gravity assist target within Eve SOI, he's basically stuck without a rescue mission.

Clearly the answer is a series of Gilly gravity assists. A more serious answer: send a rescue mission. While I'd have to double-check with actual math, I suspect you're not going to get enough dV to pull off something like EEK, where you eject from Eve, encounter it N orbits later (it helps to make an N:N+1 resonance), and use that slingshot to send you to Kerbin.

There's a difference between EA and release, but in the minds of the consumer, far less than there should be. Real EA processes fall well short of the idealized picture of EA, as developers are forced into an early cycle of addressing user feedback promptly, which can lead to things like bandaged-over code instead of taking the time to fix the root issues. The sort of title that really benefits from EA are those with a particularly novel concept (e.g. the first KSP) and those which outright lack the funding to make it through development and need a cash injection regardless of what it does to development. In the case of KSP 2, the primary positives of EA are meaningless (the devs have money and a clear idea of what they're doing), leaving just the downsides of EA (being prematurely forced into regular feedback loops and sifting through the noise of community feedback to find precious little signal).