wumpus

If you haven't put it together yet, maneuver nodes have this exact error (although typically you don't use maneuver nodes while suffering gravity losses).

Even Orion was believed to only cause low levels of damage to the Earth, and it flew by exploding nuclear weapons. In practice, the calculations were dreadfully flawed (the radioactive material would be collected by the magnetosphere and returned to Earth) for most launch sites, but you could still get the "low radiation result" by lifting off of Antartica.

Where is the surprise in all this? Congress is uninterested in going to the Moon. They *are* interested in funneling money to SLS. If NASA wants any funding to go to the Moon, they have to use SLS. There's probably some grumbling from Congress not already on the SLS bandwagon wanting some reason for funding the thing (and maintaining NASA's budget at all), so NASA is scrambling to find a mission for it. I don't think SLS is eating the rest of NASA's budget. I'd say that the rest of it is disappearing and NASA is scrambling to protect what they can keep (SLS). The piper has to play what the guys paying the bills want to hear. Is lunar orbit even a good place for such a base? It might make sense if you need to get somebody on/off the surface (radiation, solar flare, whatnot) but it seems kind of unlikely. I'd expect that a Lagrange point makes much more sense (don't try explaining it to a Congressman).

Vaguely space related link below: http://zitscomics.com/comics/march-25-2018/

I'm sure half the specification of the DSG (now LOP-G) is to be more than ~30tons per launch to make sure that the Falcon-Heavy can't be used. I've seen claims that it would be 60 tons and that an SLS block B could throw it all the way to LTI, but that depends on SLS block A either launching or being canceled followed by block B launching. Proton is listed as a possible launch vehicle, and I doubt that it can send anything to LTI that Falcon Heavy can't (FH's main limitation is that it is unlikely be able to lift anything that F9 (expendable) can't lift to orbit thanks to structural issues - no idea if block 5 changes that). I'm sure that Congress will carefully stick their fingers in their ears and chant "not listening" to any suggestion to spend money anywhere but SLS. Space requires funding, and only SLS gets funding. Therefore DSG/LOP-G requires SLS.

I really have to wonder about that graph. The infallible wiki (presumably better than a tweet if little else) lists DOS-3 and DOS-6 as 19.4 and 19.8 tons respectively. I may have botched a post on another site thinking that Tiangong-1 was in the same class (all the Salyuts were roughly that size). Officially, they've lost contact with the satellite. I wouldn't be surprised if their docking procedure requires control of each side (my KSP procedure certainly prefers it), and they aren't sure about the lost side. Launching a rocket just to bring it down in Point Nemo is expensive, but I suspect the danger of losing face if they can't dock was the critical factor in the decision (especially if the guy responsible for docking had to sign off).

RCS thrusters. Steam works the same as pressurized gas, with the added bonus of cooling off and losing energy. The final output was 108m/s (after gravity losses). A kerbal jetback has 400m/s, but 0m/s after gravity losses (on Kerbin). Using SRBs would likely have been deadly, and you really don't want to pull negative gees the way I'd expect from a "headfirst" landing. A balloon is a far more sane way to get extreme altitude (remember, to get above 20,000 feet, a ~$100 ticket from Southwest is all you need).

Is this ideal for correcting inclination? My understanding is that GSO satellites burn *past* GTO, then change inclination, and finally circularize into GSO. I'd consider doing a 400 m/s burn (while lining up a munshot), fixing inclination at perikee, and then setting up a maneuver node to Mun (actually I nearly always fix it in LKO orbit. I'm lazy that way, but if I knew that I was low on delta-v there are options). Doing it this way is also more efficient with low powered engines (low TWR that take require a burn that takes a larger angle away from Pe).

For those keeping score, that's 108m/s delta-v. I don't know what the Isp of steam is, but it is bad. Very bad. The interesting bit about this whole debacle is that a relatively short rail is needed for stability. I'm guessing the rail used was ~15-20m and was enough to get the fins effective. No idea what the acceleration was, but I wouldn't expect much. The extreme TWR needed in model rocketry appears to be largely thanks to the traditional 1m launch rod.

Boswell has two possibilities: Alien cultures detected (via some instantaneous means that defies relativity and that whole "speed of casuality" assumption) an atomic blast on Earth, rushed to where the nukes are (again, faster than the speed of light), and promptly crashed on what just happened to be the same day a nuke was lost. And they haven't left evidence since. Or it was a "deeper cover story". More likely made up by the locals to tell the new transfers "what really happened" and grew out of control. You can imagine the size of the operation when the Air Force loses a nuclear bomb. Occam's razor is pretty clear. Even if you are willing to assume that the "broken arrow" (lost nuclear weapon) was the cover story for an alien crash, the rest of the issues are huge. I'd also recommend googling "sleep paralysis". This type of thing leads to all sorts of hysteria, I've even seen reports on CNN of "sexual assault during an airline flight" that was textbook sleep paralysis.

At some point there was a "compile Java to native" option in gcc (called gcj) but it didn't support all the libraries and produced slower code than modern JITs. Presumably it isn't a problem anymore. Speeding up python is likewise a matter of using pypy (JIT python) instead of python (most standard libraries are supported, now including numpy, but you might have to recompile anything done for "standard" python. By 1999 it was accepted that programmer time was more important than cycle time (computers would catch up). Computers might not be getting much faster nowadays, but they are already fast enough to rarely bother with C++ code (it doesn't sound like you are going to be writing a widely used graphics engine or similar). I've only done enough C++ to wrap a library for python, and came to the conclusion that while the language might be based on C, the whole idea was as far from C as possible. In the K&R book, the authors state that "C is a small language and is best served by a small book". C++ is basically the kitchen sink thrown in, and then the plumber threw in the rest of the piping. After a lot of struggle and googling, I finally understood that the way I was creating objects (the way the "learn C++ in FIXNUM days" showed) put the object on the stack and not the heap. This meant that while the pointer to the object was good, all the data was almost certainly (but not always, can't be that easy to debug) overwritten. I suddenly realized all the tiny little details you need to know to learn C++ made it very specialized tool and that I should stick to smaller languages unless I really wanted to specialize in software (I'm a hardware guy). If speed is really your thing, I'd suggest CUDA or OpenCL. This is for really parallel, really weird memory models, really fast code. All coded on GPUs. It still looks like the ground floor is still open.

While I love the robotics aspect, it would nearly have to be a Zachtronics game instead of a Squad game to really work (or possibly back in the depths of time and Muse software). Even if Squad could pull it off, I can't imagine Take2 signing off on that, you are looking at a microniche (programming games) as a DLC of a niche (rocket science games). It would certainly follow the "make a game about doing something hard" and presumably "strip the hardness down to a manageable level" that is KSP. Unfortunately I'm sure the independence that allowed Squad to allow Harvester to make his crazy game died when Squad sold the game to Take2. They will demand cliched and obvious DLC. Expect a multiplayer announcement with likely eternal delays, cancellations, and general unhappiness.

A great reason to learn python, although it isn't without its warts (that first bug that's due to everything in python being a reference can be painful). But in general it should be easier to debug than Java (Perl is said to be write-only. If you have to fix a bug you find later, better to rewrite the code than to debug it). Python is taking over the numerical calculation world, but I'm not sure it is all that popular (for employers) anywhere else (and I'm clueless about what Polish employers want). That said, it should be roughly as suitable for any task you need (python 2.x finally overthrew BASIC [don't learn BASIC, it will damage your brain for later] as the best string-manipulation language (at least for pure ASCII strings), I'm not sure if python 3 (which uses unicode natively) is *quite* as slick). One thing that I've found python lacking in is GUI programming integration: I'd look into IronPython and the .NET/mono environment. It might work better).

This can often be used by rocket scientists to adjust the thrust needed. Typically the internal channel is molded in various shapes to allow changes in thrust over time. Dry mass of a solid rocket can be significant. Not only do you have the payload, but a solid rocket can be described as a "pipe bomb with one end open": you need a strong container to keep the pressure of the escaping gasses inside the rocket and leaving the correct spot. (and shape).

I'd assume that any design using a rutherford cycle would happen after much improvement over a currently 1-1 rocket. The idea of taking a brand new engine (designed for single use with kerolox) and assuming it can be used for crew rated use with arbitrary fuels seems extreme. Maybe working on "Elon time" you would have enough time to build such a thing (although I think it works the other way, if you pencil in something that makes the schedule laughably impossible (like Rocket Labs provides a crew-rated engine tomorrow) you will be expected to pretend harder that the schedule is real). If you want redundant systems (in the *last* stage, have you played KSP at all?), I'm almost positive pressure fed systems scale down easier. First, we should break our design into three parts. First is the crew module. Second is the ascent engine and fuel/oxidizer tanks. Third is the descent engine and tanks. Obviously, if we can dock the engine stack to the crew module and if it can survive arbitrary amounts of time in radiation and vacuum we reuse is obvious. Unfortunately, that (the non-engine bits of the LM) was only 12% of the mass of the Apollo LM. It may be tempting to combine the descent and ascent modules. Unfortunately, had the Apollo program tried that, they would have certainly had to carry more mass (of fuel) to the LM than the entire mass of the disposable LM. It may be possible to combine the ascent and descent engines and simply stage the descent fuel tank, but I suspect that the cost and mass is largely contained in the tanks. A Rutherford engine might have wildly lighter fuel tanks, but don't be at all surprised if you leave at least one "decent battery" on the Moon. Reducing dry weight does wonders to increasing delta-v, and it is quite likely that bringing new batteries means bringing less total weight. Nevermind the whole issue that Rutherford engines should be considered experimental for even cargo vessels. I don't think they have demonstrated (or even announced) any throttling capability. The overall problem is a lot like going to Earth orbit. There is a strong desire for SSTO (or in this case "single stage to the surface and back to orbit", and it "only" needs 3460m/s). But the huge difference is that every gram of mass has an enormous cost, unlike launching from sea level with a zero "tax" on mass. This makes staging and ignoring reuse much more likely than than without the "lunar orbit tax" (and it isn't clear that you can make a LM crew cabin reusable for less than a 12% mass budget). There are great reasons to recover your first stage booster. From then on, recovery gets harder and the returns smaller. Going into another gravity well changes the numbers again, and may make reuse not worth it at all.

Considering the cost of each lunar flight, the cost of the lander is in the noise. There is no reason to make it reusable and little reason to bring it back (do you really want a heat shield on it? You pretty much at least need to aerobrake, even if you are going to dock it on the ISS between flights). Also how reusable will that engine be after using nitric acid (probably less bad than LOX, unless you are talking about the stuff similar to "red fuming nitric acid" from Ignition!, then all bets are off). The rutherford engine is still extremely complex and untested, building reliable pressure-fed hypergolics aren't. I'd even expect it to be trivial to build one with Kerbal-style drop tanks, at least assuming that you dropped the tanks between burns (close one valve, eject, open another). This should go a long way to fixing the efficiencies of pressure fed engines (or just use two like Apollo did. Everything I heard implied that the ascent engine was the most likely component to fail in Apollo. The forces acting on it from launch (and pogo) to landing weren't completely known, and it had to be so extremely light... Lots of nightmares at NASA about astronauts banging away on the ascent motor while air ran out).

I'd assume that the main internal roadmap walked out the door with Harvester around 1.1 (although "Making History" was announced more or less in 2013). I'd expect that his vision of KSP is more or less complete and not to expect anything as major as multiplayer added. The only reason I might expect multiplayer is a push from Take2 insisting that "all games must have multiplayer" (even if they banned at least one mod that provided such). If Squad is working under such restrictions (because they have to, not because it is feasible), don't expect good results.

Didn't keep the MIT students from chanting "the Ringworld is unstable" about 20-30 years ago at whatever con happened after somebody did the calculations. As far as building something like that in KSP, I don't think KSP would like something extended through the physics bubble. I also don't think that any procedural part would save from the issue of "things violating the physics bubble" and "too many parts". *Something* involved would summon the Kraken: you are abusing Unity too badly.

If this is happening during [non-physics] warping, any acceleration (phantom or not) should be ignored. If it *is* happening during warping, it is likely an unrelated bug. I suppose it is possible for clipping to influence the physics engine, but altering a warp course is rather strange.

What is firing the harpoon? It is in a polar orbit so firing from the ISS is out of the question. Are you suggesting mounting it to a Soyuz [Dragon, or similar]? Some non-existent space robot will be needed to fire the harpoon. The harpoon is also listed as extremely specific to hitting Envisat, with subsequent harpoons designed for each individual bit of space junk. I also have to ask what is on the other side? A parachute? A giant umbrella (because the air won't open the chute)? I'd guess it simply adds the ~100m/s via solid rocket to deorbit the thing. I'd recommend your space robot using ions to change orbits and attaching solid boosters (to dribble out 100m/s over 10 minutes) for deorbiting (you don't want your ion craft in the atmosphere, although if the bird is too high, you might lower the Pe via ions and do the last bit with SRBs). I can see that large (relatively dense) objects in LEO might take some time to come down (Skylab took what, 10 years?). Objects in polar orbits (like Envisat) are a huge danger thanks to relative velocities at orbital speeds (although I'd hate to think what relative speeds two objects in Baikonur inclination can hit). Finally, how much delta-v do you need? LEO-Earth (in one orbit) looks like ~100m/s. GSO-Graveyard is said to take 10m/s (according to the infallible wiki), but I really don't expect two GSO satellites to ever hit. Elliptical orbits should get fun, although presumably dropping the Pe into the atmosphere should be less expensive than dropping from circular into the atmosphere, and if it is high enough it shouldn't matter). Getting your space robot to intercept such a beast might be more fun.

I'd think the bigger issue is trying to wave around a 50-70m barrel. The only use I can imagine is for sniping the rear lines of WWI trenches from an equally rear line. Such a monster would quickly be taken out by artillery. Even with a 5-7m barrel, I'd strongly suspect that all the limitations would be in the sniper and the bullet, and that at that distance shear chance will overwhelm any bullet velocity (even if you had a two-stage gun. And I can't imagine the second stage not pulling the barrel at all). The Paris Gun was 34m. I'm not sure it could hit a target smaller than Paris (although it did from 130km away).

I've missed most of the greatness of the twinboar out of love for SRBs. Typically when you have enough kickers you don't need a twinboar, although I'm changing my build concepts to include it. So kickers are probably my favorite, thanks to terrier and LV-N splitting the vacuum "vote". The biggest problem with the LV-N are the stock tanks. You are stuck with either the 1.25m tank or plane tanks. But you still want one in orbit once it is unlocked (to ferry anything to Mun, Minmus, or a special orbit) and it is the goto engine for interplanetary travel. The terrier is just amazing. Unlock it as soon as possible. I really wish the demo had it, although I guess the challenge of getting to the Mun without it stretches out the demo's usefulness and feeds the need for "real" KSP.

It would be a lot easier argue for launching rockets as entertainment. Just look at the money US cities and states lavish on professional sports stadia, "bread and circuses" has been a means of swaying the people for 2000 years. The big problem with "NASA isn't Disney" is that Disney provides far more entertainment to more people than NASA ever will (same for the highly subsidized NFL). It may have twice the budget, but it returns an unbelievable 25% return on those dollars spent. Don't even think about using the argument "for science": look at the congressional "science committees" and count how many of them ran against science. "For science" falls not on deaf ears but hostile ones. SLS at least has the argument as a jobs program (in all the right locations, and has the promise of keeping old jobs instead of promising new ones [politically more useful]), so it gets funded. Keeping the rest of the programs intact will likely require a different argument or a different congress (and I can't think of a single [electable] candidate running on "science", let alone "space"). Using SLS is a crime against all taxpayers who may someday have to pay the debts congress is incurring, almost nobody will swing votes over this. Canceling SLS is a crime against all those employed specifically for SLS and they (and their friends and families) will know exactly who voted to make them unemployed. Sorry, that's how humans work (the needs of the few outweigh the needs of the many). This is part of the cost of transferring control of NASA to Congress.

The killer for multiplayer is that player control of time acceleration is problematic at best. Perhaps something where vessels/zones are automatically run at maximum acceleration for their areas (mechjeb might be needed for burns and especially docking). Note that removing acceleration for your own physics bubble could cause problems, let alone for your docking target. I wouldn't want to be responsible for getting multiplayer to work acceptably.

I suspect "leadership" only applies in the sense of "don't step in the leadership". Government appointed positions tend to act as pigeon management: fly in, make a lot of noise, fly out. The real problem is lack of someone with the ear of Congress to protect the budget. We may be looking at a NASA that does nothing but spend money on SLS.