Geschosskopf

I can't say that "we know" the NSWR works. There's quite a bit of disagreement on that score. I'm inclined to be dubious, myself. I don't trust Zubrin--he's got too much of the airs of a wild-eyed zealot for my taste. But let's say everybody agrees on the numbers and the numbers indicate it would actually work. That's just the beginning of the problem. Designing the tanks so the fuel doesn't just go critical for no reason seems even less likely than agreement on the underlying numbers. And even if that is possible, it will be hugely expensive just to develop the necessary manufacturing plant, must less build the actual system. And even if you get past that, you still have the very real issue that a fuel leak will likely cause the ship to explode. http://www.projectrho.com/public_html/rocket/enginelist2.php#nswr

My condolences. I raise a glass to its departed spirit. May it be happy in the next world. Good luck with the recovery!

Thanks Back at yas!

Good job! I'm glad nothing major has malfunctioned yet

That's an impressive beast and I salute you for doing a Jool 5 with it Good luck with the rest of the tour!

Well, the feasibility of a single-launch, all-in-1 unit depends, I would think, on what resources are available, what form(s) they're in naturally, at what quantity per shovelful, and at what depth. The more you have to separate and refine the desired atoms and molecules out of their matrix and natural compounds, the more gear you need for those functions and the slower the overall process. The scarcer and deeper the good stuff is, the more spoil you'll have and the bigger the diggers you'll need. Also, the more likely it is that you'll have to haul the spoil to a distant location (where the concentration of good stuff is nearly zero) so as not to pile spoil on acreage you'll later want to strip-mine. Methinks there's ample scope here for Murphy's Law to require us to go big or go home, Especially considering the scale of plant required for even modest industrial-scale resource exploitation here on Earth, where building the required infrastructure is much easier. As to commercial viability, that depends on the commercial need. Many types of satellite are in large-scale demand so have created a market for launchers, competition within which has created excess capacity being filled by cubesat stowaways which aren't, in themselves, commercially viable but they can leverage a market tailored to launch bigger, profitable things going further away. The commercial viability of an ISRU base on the Moon depends on the demand for fuel. If the only customers are government exploration missions, then the demand is low and that's that. However, if the Moon really is carpeted in helium-3, or if it's commercially worthwhile to mine NEOs and those miners need fuel, then it's another story. And in this latter case, then I'd expect to see HUGE ISRU plants on the Moon, with all sorts of tradesmen building and operating them.

Thanks. Back at you both. According to the forum about the forum, post reactions are having technical difficulties so are temporarily disabled. They hope to have this fixed in the near future.

My concern is the scale of the ISRU facility required to produce the industrial quantities of fuel needed for the fleet of interplanetary tugs, asteroid-bound ships, Moon biome-hoppers, and all the other other ships lining up to use it. The rover in the video you just linked is functionally the same as the one you built a few episodes back, just a prospector. It's exactly the same as putting the ore Surface Scanner on a small rover in stock KSP. It can't actually DO anything with the resources, it merely determines what's in the ground and the best places to dig for them. Actual exploitation of the resources requires following up with the necessary industrial plant. It's with this latter plant that I foresee issues. Basically, to make fuel in the required volume in the available time between all the many customers, the plant has to be pretty big in total. And the total plant will have to comprise numerous components each performing one of the MANY industrial processes along the way from raw lunar dirt to refined (and possibly cryogenic) rocket fuel. Each of these components must therefore also be pretty big. So at a minimum, you're looking at 1 heavy lifter launch per component, maybe several per component (especially for the storage tanks). So you'll end up with a large collection of skid-load machinery pallets, all of which have to be interconnected for the plant as a whole to function. Docking base components together in KSP is hard enough and that doesn't even consider the evil lunar dust being blasted into the connecting ports of 1 module by the landing of the next. So I figure you'll need a bunch of pipe-fitters and electricians to hook all these modules into a functional whole. And also mechanics to maintain the fleet of strip-mining excavators and dumptrucks. After all, you'll have a LOT of spoil scooped up with the good stuff. The good stuff has to be moved to the immobile ISRU plant and the useless dust and gravel hauled off to the spoil pile some distance away. This industrial-scale lunar ISRU plant is a whole nuther thing compared to the idea of using ISRU on Mars to pre-make fuel for the return trip prior to the actual lander even leaving Earth. In that case, you have only 1 customer ever and several years to produce the fuel. The biggest thing you need for that application is the storage tanks, which are going to be about the same size as those in the lander so no big deal., But for a multi-customer, relatively short timespan ISRU station like the idea for the Moon, you need a LOT more stuff in all respects. Either that, or you greatly reduce the number of customers and/or the frequency of customer visits Which decreases the usefulness of the lunar ISRU base.

Back at; ya Probably not. There's really not a lot more to do there except climb a mountain to get Science! from the other 2 biomes. Basically, I'm tired of messing around in the Rhode system so will likely be warping ahead a fair amount, to get SE-1 on its way and maybe HE-1 to arrive, so I can explore Hydrus. It looks quite interesting from the pics I've seen of it. And after that, a window for Fury is coming and I really want to try a return mission from there. Fury's like a cross between Eve and Moho only with rings .

Nice mission, Moho is a challenge by the method you used here is the one I think is best myself. Bummer about leaving the Science! behind. Now you'll have to do a rescue mission for it

Wow, that was fast. "Speed of plot" indeed So, you sent the Science! home but not the Kerbals? Sounds like something I'd do

Interesting vids. I'd like but that button's not working right now. It's a shame you didn't hit F3 on the Jool mission to see the official cause of death. Have fun with Moho.

All very interesting. The big question I now have, after your very informative posts above, is how are they going to get the necessary infrastructure for a fuel base to the Moon? There's a lot of bulky equipment needed regardless of which type of fuel is there. All the mining/drilling stuff, refining stuff, processing stuff, and of course sufficient storage tanks, all beyond whatever power plant it needs. And there's going to be a lot of work for welders, pipe-fitters, electricians, crane operators, etc., in putting it all together. Is there any sort of outline for that?

EPISODE 10: The Show Must Go On (music by Queen) The vaporization of Guslie had thrown a pall over AE-1. It also put a kink in the plans to explore more of Ash as there wasn't a sciencemate now to spare for the rover trip. All the others were busy in the lab. But given that AE-1 ARSEFACE was pretty inadequate anyway, this really didn't make much difference. So, while the sciencemates did research stuff, there wasn't much else to do but check on the deployed Science! once in a while. Meanwhile, back on Rhode, the Boffins were hammering together the Circus' 2nd interplanetary mission, the 1st Scaythe Expedition, due to leave in a month or so. This will be another uncrewed scouting mission., Scaythe is the next planet out from Rhode, an airless body a bit bigger than Rhode, making it a challenge to land on. Thus, the Boffins naturally want to try that. Scaythe has a single moon, Scindo, a small, airless rock that looks like a jawbreaker, mostly white but with streaks and patches of many bright colors. Spectrography from Rhode has been inconclusive as to its make-up. Scientists are divided over whether it really is mostly sugar or simply mineral pigments, so requested the Boffins send probes to settle the issue. SE-1 will consist of 4 ships, shown below. On the left is SE-1 PUSTULE (Probe Using Scaythe To Ultimately Land, Expendable), a combo orbital/lander probe. The orbital section will function as a short-range relay to support the lander. Next is the SE-1 SCAN-Ore Probe, intended to map and assay both Scaythe and Scindo. Hence, it needs nukes to give it the necessary dV to move between them. Next is the SE-1 Scaythe Polar Relays Mk 2 with a stack of 2 small relay probes, each with the medium-sized dish. Finally, on the right, is SE-1 SCHLEMIEL (Scindo Collector of High and Low Experiments Making itself, Eventually, a Lander). This is the same idea as SE-1 PUSTULE, an orbital/lander Science! probe with the orbiter serving as a relay for the lander. In the fullness of time, the sciencemates in AE-1 SCAB worked themselves out of a job so there was nothing for it but to get everybody back into AE-1 CRAP and go home. AE-1 CRAP had a very low TWR on largish Ash and, due to a tall mountain inconveniently close downrange to the east, had to begin with a long, slow vertical ascent. This gave the crew a good view of the lava lake that had eaten Guslie, ending the mission on a bummer. There had been some doubt at Mission Control as to whether AE-1 CRAP could actually make it home but the Boffins responsible were confident. In fact, it had enough dV to circularize without aerobraking, and then had just enough left to deorbit. AE-1 CRAP was the 1st ship where the return stage had a TAC Self-Destruct charge aboard. Previously, such stages had just been allowed to burn and/or crash. But this usually happened out of everyone's sight so Mission Control had started a new policy to blow these stages up after the deorbit burn. The resulting gratuitous explosion did much to cheer the not-so-jolly crew (plus this post hadn't yet had a gratuitous explosion). Landings on Rhode are a bit tricky as there are mountains everywhere but careful aim brought AE-1 CRAP down safely in a narrow valley running more or less parallel with the inclined descent path. The load of Science! returned by AE-1 was not as large as hoped (mostly due to bugs with the deployed Science! causing Mission Control to destroy it) and by now all new tech was rather expensive, so the Boffins got few new toys. Something they did get, however, were the biggest relay antennae. These were considered vital now that the Circus' 1st wave of interplanetary ships were getting further from home and signal strength was getting disturbingly low. So, the Boffins immediately slapped together probes using 2 of the Wild Blue antennae, stacked 2 of these on a rocket, and sent them into polar orbit at Rhode. Then they took the same rocket, added a bigger transfer stage in the middle, and sent it up to join SE-1 in parking orbit, as the SE-1 Scaythe Polar Relays MK IV. This made the original SE-1 Scaythe Polar Relays Mk 2 surplus to requirements. There was some thought of sending it out anyway but it didn't seem worth the trouble so, much to everybody's delight, Mission Control decided to deorbit it. Not much happening right now. Your humble narrator apologizes. Tune in next time for more of the slow spiral into damnation.

NEVER believe the dV map. ALWAYS add some some percentage of extra fuel, from 10-50% depending on how lucky you're feeling and how much you follow @bewing's excellent advice. But I myself don't trust Mun at all. Its terrain in most places is far from level and everywhere is covered with ship-killing scatters and ROCs. So, when I'm just trying to land in a certain biome for Science!, I always use the very expensive stop-and-drop method. I get in about a 12km orbit, kill my horizontal velocity completely so I stop over that biome, then ride on down controlling vertical velocity. When the terrain becomes more visible, I slow down nearly to a stop and make sure I'm coming down on a safe spot, adjusting horizontally as needed. I make my munar transfer stage big enough to do most of the landing, then ditch it once I'm about 1000m above the ground and lined up on a good spot. Thus, my lander usually has only a tad bit more fuel than needed to get home and I get a nice explosion from the "crasher stage" in the final moments of descent. Sometimes, parts of the crasher stage survive and I EVA Kerbals to go examine the wreckage. OTOH, if I'm building a base and require landing a bunch of modules in the same (previously selected) place, I use MJ. Every real spacecraft ever launched as been controlled by its guidance system either completely or nearly so, so I see nothing wrong with this Gilly is different. At that cursed place, velocities are so low that stop-and-drop doesn't cost you noticeably more than any other method. And it's very important to land on as flat a place as you can find, due to the low gravity. I also recommend having some up-pointing RCS thrusters to speed the damnably long descents. It's either that or point towards the ground and run the main engine. A lander totally powered by monopropellant is one of the simplest ways to build for Gilly.

In the classic Niven and Pournelle book The Mote in God's Eye, the jumpdrive-capable human empire encounters its first intelligent aliens in the form of a sublight beamed-power ship. This ship solved the deceleration problem by being a huge solar sail. It was sent on its way with a massive battery of lasers then planned to stop by using its sail to brake during a close pass by the destination star. The main problem the aliens had with this scheme was political. They didn't have a single world government and their civilization was never stable due to internal pressures. So they'd nuked themselves back to the Stone Age MANY times in their very long history. One such episode happened while this ship was en route, with its launching lasers being used in their nth world war. That's the main problem I see for humans and beamed power, too. All spacedrives worthy of the name are also WMDs, due to being able to direct the vast amount of energy required in the desired direction. I see beamed power as more vulnerable to misuse than most other schemes where the power is aboard the ship. For example, an Orion ship is a high-capacity nuclear bomber in orbit but it can be built and fueled far enough away to pose little real threat. Even if it does some start dropping nukes on Earth, there's time to intercept them. With beamed power, OTOH, all you need is a few mirrors in orbit and brief flicking of the beam to them, and you can vaporize anything you want without significantly slowing the ship.

I haven't looked at this mission in several months. Now I see Bennu is so covered with boulders they've had trouble finding any places to "land" at all, and have had to rewrite the landing program to come down between all the boulders. I'm glad they think they can make it work despite all the boulders. It's too bad they can't just turn down their scatter setting

Yeah, I imagine we'll get new, mondo relay antennae and the nuclear reactors needed to power them (which we'll need anyway for things like VASIMR engines). And the bandwidth will likely be very low at extreme distances. IIRC, it took more than a year for New Horizons to transmit all the data it got from its brief encounter with Pluto. I don't understand why folks think it's "cheating" to have MJ fly your ship. Every real spacecraft ever made has been flown either entirely or almost entirely by their guidance systems, even when crewed..

Umm.... No. Signal delay creates the need for AUTONOMY, which is a totally different thing from automation. Automation was invented in the Neolithic (irrigating fields with a waterwheel instead of peasants with buckets, for example) if not even earlier. Automation is a dumb device doing a pre-set, hardwired routine. It makes no decisions, it makes no in-process adjustments. It just does the same thing over and over regardless of inputs. Autonomy does what automation cannot. It works via algorithms instead of fixed mechanical (or hard-coded) linkages. These algorithms accept a range of input values and crunch the numbers to arrive at the same desired result by different routes. They can even monitor their own progress and adjust themselves in-process to help end up with the desired result. The preplanned maneuvers in RT are holdover from ancient times when the base game did not allow a ship to have more than 1 node at a time, and also did not remember a ship's nodes when you switched focus to another ship or KSC. Nowadays, you can make long chains of nodes for the same ship and the game saves them all so they're still there (maybe years/decades later) when you return focus to that ship. Given that even the shortest interplanetary trip is far longer than the signal delay, you have no problem at all manually plotting all the nodes you need far in advance and setting them to autoburn. The end result is EXACTLY the same as, if not better than (due to more precise execution of the burns), doing all these burns manually in realtime. There's no rush to create the nodes so there no need to compensate for the signal delay. IOW, this whole thing is a scam, making you think signal delay has any meaning at all for such simple things as individual maneuvering burns, when it really doesn't. But, as you say, doing anything more complex than a single maneuver node can handle requires not automation but autonomy. Landing is just one example. Launch, rendezvous, and docking are others. For all of these, you have a choice. #1 is that you can accept what the game gives you in allowing realtime, direct control of probes regardless of their distance from home, which basically means that you as the player are the probe's autonomous, self-correcting control algorithm. In this case, signal delay could equally well be zero or infinity for all the difference it makes to gameplay because the probe is flying itself without need of input from home. #2 is to disable direct, realtime control of probes beyond LKO and then write flight control algorithms to do the same job you'd do yourself if you were controlling the probe in realtime. In which case, signal delay could ALSO range from zero to infinity without it making the slightest difference on the probe, which is, again, flying itself without input from home. From this you can see that the ONLY way signal delay has any impact AT ALL on gameplay is if it prevents the direct, realtime control of probes like we have without signal delay If it does that, then it condemns all players to doing nothing with probes but flyby, impact, or simple orbital missions. Everything else requires either a pilot (and thus having to bring him home) or the underlying ludicrous assumption that your space program somehow missed out on the Silicon Revolution which itself, in real life, was largely a spin-off of, and synergistic with, the space program. Which makes no sense unless you're setting your space program in the 1950s. C'mon, man. The whole concept of signal delay for probe control is totally bogus outside the 1950s. It's an insult to your Neolithic umpteenth great-granddaddy who invented the waterwheel, not to mention any society capable of landing a booster on a barge at sea. That was my impression, too.

Signal delay and automation are totally separate things. One has no effect on the other. For instance, in KSP1, you can install either MJ or RT, you don't need both at once. If you think signal delay is a good idea in KSP, then you've either never actually used it OR you're a proficient kOS coder and enjoy writing probe-flying scripts at least as much as you enjoy building and flying rockets. But If you're the later, we wouldn't be having this conversation because you'd surely recognize that 1) not everybody is good at writing kOS scripts, 2) not everybody enjoys writing code enough to want to do that instead of flying rockets, and thus 3) that signal delay is a VERY BAD thing to force on majority of players, who aren't good or willing coders. This is because the ONLY gameplay impact of signal delay is to force you to write a bunch of code to do some fairly complex math. Seriously, within the Kerbol system, signal delay has no meaningful effect on Science! transmission. Whatever the speed of light, the delay between transmitting and receiving the points is so small as to be inconsequential, even with OPM installed. ALL that signal delay does is turn probe cores into model airplane RC sets, nothing but a receiver and some servos. No autonomy at all, no brains. Like WW2-vintage optically guided weapons. If the probe is too far from Kerbin to be flown hands-on by somebody with a joystick at KSC, then players have to write programs so the probe can fly itself, because the only way to implement signal delay is to make direct hands-on control (like you have without signal delay) be so far behind events as to be useless. True, this is how it works in real life. Teams of folks highly skilled in several separate Dark Arts spend years writing complex programs for distant space probes or even boosters that never even reach orbit. But putting this into the game means an individual player has to master all these Dark Arts alone. That is, knowing the proper orbital mechanics equations to use for the job, knowing enough about programming in general to convert these equations into self-correcting flight control algorithms, and knowing enough about the specific language in use to do so in that language. And then have the time to do this and repeatedly debug the software, just to get the rocket to function as desired. All of which is in addition to just building the rocket itself. Of course, some folks groove on this, which is why kOS exists and why RT has the option to include signal delay. But for the few folks who both can and WANT to do this, the signal delay option isn't even necessary to have because they'd write the same programs with or without it, just because that's what they enjoy doing. For everybody else, this is sheer torture getting in the way of their fun, which is just flying rockets. Fortunately, the unmodded game provides an easy solution. You can control probes in real time no matter their distance because you, the human, are pretending to be the AI of a highly autonomous robot. Thus, you can ASSUME there's however much signal delay you want and it doesn't matter, because your probes are modern, autonomous vehicles capable of flying themselves (because the highly skilled, multi-talented team behind the scenes at KSC built them that way), as opposed to ancient, dumb, WW2-vintage tech you should be embarrassed to send even to LKO. Then you don't have to write all the code to do this, and don't need to feel ashamed by this. So really, when you boil it all down, having signal delay does nothing good for anybody. Those who like writing control algorithms will do so whether there's actually delay or not, while those who don't enjoy coding (or lack sufficient training even to attempt it) will be forced into it anyway if signal delay exists. And as mentioned, it has no impact on Science! at least within the Kerbol system. The exact same arguments against signal delay also applies to probe control at interstellar distances. It just shouldn't be stock and there's really no need even to make it a mod. The difference with interstellar is the impact on Science! But as I outlined in a post above, putting a significant delay on Science! transmission pretty much kills the idea of building a cohesive space empire or even making an interstellar trip within a reasonable amount of gametime. Thus, it's best not to have it at all. This leaves players free to enjoy the game however they want.

Well, KSP1 has (almost) always had a light sprinkling of totally unexplained alien artifcts: crashed UFOs, the Vall-Henge, the Face, all the Monoliths, etc. This is fine with most folks because players can either ignore them completely or spin their own lore off them. I play the game both ways depending on mood so would be disappointed if the new KSP2 planets did NOT contain a similar light sprinkle of anomalous pop culture references. I want folks to spin new tales off them and the rest to be able to continue to ignore them without making vast tracts of real estate unplayable to them. But the key thing is, they must all remain totally unexplained. Built-in lore is bad for everybody. It prevents folks who enjoy visiting the anomalies from telling their own stories about them, and it forces a story on those who'd rather not have one at all. As to actually meeting aliens, anything mobile, let alone tool-using, would require at least rudimentary AI. I just don't see that happening. But I really do hope for alien plants to liven up the scenery. Besides, they'd give something more for the rover arms to sniff, and perhaps new experiments leading to domestication of edible strains for colonists.

I don't think this is actually workable gameplay mechanic, and it would definitely poke more holes in KSP physics First of all, the devs would have to decide once and for all what the speed of light in KSP really is, the same as here or some considerably lower number inferred from other aspects of KSP physics. They have to do this to know how long to delay transmissions from interstellar ships. And therein lies the rub. To justify this sort of system, the speed of light must be presumed to be so high that all comms within the Kerbol system have effectively zero delay. But the faster light goes, the greater the in-game interstellar distances have to be to create any meaningful delay between transmitting and receiving Science! A "meaningful" delay is something longer than hours or even a few days, which a player can just warp past without disrupting his other plans. It has to be months at least, perhaps even years or decades. But this all means that sub-light interstellar ships would take on the order of centuries to get anywhere, which is bad for the gameplay mechanic of exploring other star systems. But OTOH, if you still want to have delay while keeping interstellar travel times down to a few decades at most, then the speed of light in KSP has to be significantly slower than here, scaled to the toy-size KSP solar system. Which logically means there'd have to be signal delay within the Kerbol system, so you'd need kOS just to send a probe orbiter to Duna. Either that or you have to make light's fundamental properties very different from here. Like it maybe it's really fast (so no signal delay within the Kerbol system) but it does in fact use lumineferous aether, which is produced by stars and mostly stops at the heliopause, so the speed of light between stars is much lower than between planets. Because, after all, you'd still need to have instantaneous comms within the other star systems. But OTGH, if light slows down between stars, then interstellar ships could be end up being faster than light while travelling between stars, despite being much slower than light within solar systems. Which means it would be faster to return Science than to transmit it. That's a whole lot more hand-waving than I want to put up with just to incorporate a feature of very dubious gameplay value I agree 100% that it would be better all around to not have lag. Lag just doesn't fit in with the overall concept of "building a civilization". For even interplanetary, let alone interstellar, colonies to function together as a cohesive whole, you have to have fast communications. Otherwise, you're not creating a civilization, you're creating a bunch of independent city-states, like the ancient Greeks and Phoenicians did, or a bunch of independent nations (once they become sufficiently self-sufficient) like the Age of Empires ultimately did.

As with all so-called "realism" features, when added to KSP, they're half-measures that annoy the folks who never wanted them and don't satisfy those who clamored for them. A pox on them all. Let us have no more "realism" features because they're all bad for everybody's enjoyment. Good. I bring sacred 100% perique tobacco for the peace pipe. It'll put hair on your teeth

You can have signal delay in KSP1 with certain mods (ex. RemoteTech). If you haven't tried this already, do so. Then you'll see why signal delay is a bad idea as a stock feature. If you don't have time for that, here's the short version. Without signal delay, the assumption is that probes are highly autonomous. When you fly a distant probe in realtime, you're playing the role of its AI, just as you play the role of pilots with crewed ships. So, signal delay has to assume probes are too stupid to fly themselves or you'd still be able to do that in the game. And the lag also means you can't fly the probe from KSC, either, EVEN IF YOU HAVE A GOOD CONNECTION. Thus, the only way to control distant probes is to install the kOS mod and write your own autonomous AI routines for the probe. So, if you're not proficient at writing kOS scripts, you basically can't use probes. As for interstellar lag in KSP2, there are only 2 solutions as I see it. Either 1) completely ignore it, or 2) make communications totally impossible between stars. The latter would basically put each interstellar outpost in its own universe, so it would have its own separate stocks of money, Science! points, and rep, and basically run as a separate game from the Kerbol system.

Quite a trip How long did it take? I thought the ScienceDeckTM was pretty cool. Too bad you melted it.