Rune

Members
  • Content Count

    3,954
  • Joined

  • Last visited

Everything posted by Rune

  1. Well, the size of the wheel is mostly defined by the length of the sections... You could use a big payload bay instead (or several Mk3 sections), and it would grow directly proportional to the length of your segments. As to docking alignment, a single Jr port would do, I think, to lock an alignment. As long as it is off-center of the Sr. it will force a perfectly aligned double-dock. I also thought about that sort of solution, but I haven't implemented it yet myself. In related news, I have successfully assembled my awesomest interplanetary stack yet, IMO. More than 4km/s in there without nukes, courtesy of using the lander as the propulsion section. Incidentally, said lander is a Vega, meaning it can land anywhere but Eve... and it also has the ability to land a small emergency refinery, too, or one of the ore tanks. In other words, in an emergency the lander can work as both a miner and tanker, making this a potential Grand Tourer on its own. Other interesting stats of the assembly: -About ten or eleven separate ~50mT launches. In the future it will be ten or less, but I was faffing around with how to package that ring efficiently. All done with reusable chemical SSTOs. -318 parts in total, divided among 31 independent pieces docked to each other, some no more than eight part ring sections, or five part fuel tanks. Also a few commsats to establish a local network linked back to kerbin. -All pieces were delivered inside a Mk3 payload bay, except the lander, which SSTOed itself. No space littering was conducted during the making of this pic. -More dockings than I care to remember, most of them with <0.1º tolerance. Lots of double-docks in the tankage section, the Klaw Pod sure earned its keep! -About 300mT IMLKO. dV without staging any tanks is ~4.2km/s, ~1.2 before refining any ore, TWR at the first burn is 0.3. I am mighty pleased with myself for pulling this off so smoothly. Rune. And SnapDock was glitchy, so most of the dockings are thanks to @NavyFish.
  2. Engineering at any level is hard. We still do it, when we have the will to. If it's doable, it's doable. By definition. Another question is whether it will get done, or should. I never claimed it was. But if ISS has sustained a permanent crew for decades, I'd say we have the capability to do it, if we put our mind to it. It obviously won't get done if we never try. I'm sorry, are you saying that the mathematical models that validated, for example, Curiosity's skycrane, wouldn't handle a manned lander doing a much larger portion of the descent under engine power? You cannot hide under supersonic retropropulsion anymore, now that SpaceX routinely demonstrates it, after developing it on the back of a freaking cargo delivery program. So what exactly is so impossible about designing, testing, and using a martian lander, that you can't do it within the multi-billion budget such a program would command? I never said it was the most practical. I said it's a more than decent baseline, showing that between us and mars there are only the dragons that we want to imagine, and a bunch of rocket launches. Now, is there the political will to do it? Of course not. The official line can be summed up as excuses to avoid saying 'we ain't paying what it would cost'. Rune. And obviously the plan can be improved. My first post in this thread was pretty much all about that.
  3. That's engineering. We haven't built ECLSS that last longer than six months without resupply, because we haven't tried to do it. Grab the component of the ISS, overbuild, test to destruction lots of times, then pack enough spares, and a few extra. And do it by triplicate if it's vital. Landing, well, we have actually landed stuff. Large mass? We hadn't landed large masses on Earth until the Shutle flew. And after a few tests and such, land it did. We have also taken off form other bodies. Turns out gravity and rockets work the same way everywhere. All of that is part of 'building the thing'. We didn't have ECLSS at all until we started building manned spacecraft. And we didn't have long duration ECLSS until we started building space stations. Of course, I'm not saying it wouldn't take a crapload of money to build it all. Of course it will, and how much is a very open question. But this mission plan in particular is, technologically, well within reach. Just like it was when originally written, 13 years ago. Rune. After a certain point, the only way to eliminate the last uncertainties is to actually start doing the thing.
  4. Launch vehicle limitations. They are lofting 80mT transfer stages, so you cluster them until you have enough, then drop them as they empty. If you could do it symmetrically, you would drop them one by one to save the most weight. Yes, this design has more stages than it needs to, and more engines than it needs to. But it can be launched with an Energia, and a single humongous TMI stage can't. Rune. Using Energia as the assumed HLV shows the age of the paper, BTW.
  5. Who else? NASA, which these days does the same kind of manned mission ESA does? Rune. This is a paper study. I can make a paper study, if I feel like it.
  6. I found this on Atomic Rockets today, and yes, it also caught my eye. It's basically a wonderful yardstick. It's the Mars mission we could do yesterday, with no fancy tech and R&D involved. Frankly, we need something like this if we are to compare apples to apples. When was the last such study done, the sixties? Since then, all of them have assumed some sort of technology that we don't yet have in an attempt to be novel or something. But only after having something like this is when you can then get smart about things, and compare them to a very reasonable baseline. Want to check the impact of using aerobraking to shave dV of the Martian injection? Now you can see exactly how much that saves. Want to see if we need nuclear rockets? Change the stages to nuclear ones, run the numbers, and compare the advantage in IMLEO to the development cost of your nukes. Figure out the launch rates needed to support things. Looking at it from that perspective, it kinda reinforces my belief that storables+fancy mission planning tricks would be the cheapest, fastest way to do a mission to Mars. Basically, this plan is a 'battlestar gallactica', with all the things launched in a single ship, and it also uses no aerodynamic breaking to reduce delta-V. In that sense, it is basically a brute-force approach, and thus somewhere around 1,300mT IMLEO, if I can read, and if you'll forgive some rounding so I can do the numbers in my head. Which is actually not even that bad, that means tens of heavy lift vehicles, not hundreds... an SLS would lift it in less than 20 flights. Ok, maybe a bit bad. Or is it just a great place to start the conversation? Suppose that you broke the mission into several transfer windows, and did a... Mars Orbit Rendezvous model, let's call it, for historicity's sake. Then you can send a surface habitat and the lander ahead of crew, and you halve the size of your manned ship. That is a big thing. You can also check things out remotely before sending crew, and test the Earth departure stages and such. Those 'test' stacks incidentally, can be smaller for the unmanned cargo flights, because those ain't returning (Transfer Hab+Return capsule+Return stage is around 150mT, and the lander is around 50). That small architectural change would, alone, break those 1,300mT IMLEO into 300-1000mT chunks launched every two years (the manned window having a significantly higher launch requirement). Another minor trick that would slash IMLO would be aerobraking (not aerocapture, that needs beefy heatshields). That could take away one of the martian injection stages altogether, at the cost of a few months orbiting Mars before the main ship reaches the low martian orbit that the lander can reach form the surface. And even then the crew could land earlier if the lander stayed on a high elliptical orbit waiting for them, and did a slightly faster entry. Bit ballsy, landing before your return ship gets into position to pick you up if crap happens. But you could use that time to do orbital science. That slight dV gain (the couple km/s or so that can be aerobraked after inserting into high martian orbit), in such a staged low Isp architecture, would have a snowball effect that would cut IMLEO drastically, since it cuts the payload to TMI to about half. So, you know, now we are looking at ~650mT IMLEO, divided among two or three windows (~6years), most of which will be dumb, cheap fuel and mass-produced simple chemical stages. The yearly payload launched to LEO start to gets within the budgets of real-world space agencies pretty quick! Rune. But hey, no fancy tech to sell to politicians.
  7. Hum. Great minds think alike? Mk3 shuttlebutts work great to hide the seams. Rune. Interesting dockings to make stuff line up when building rings, right?
  8. I was shooting for 40mT on orbit, and just tried a crazy MTOW test with all the intention of reverting it when it didn't work. I guess 55mT works, too. Look at the mission timer. Rune. The Vector and derivatives sure are OP.
  9. Thanks! I think that would work, yeah. As you can see in the picture, a Base-In-A-Box can also be split into two packs that fit a single long payload bay (like the Orca's, or the Centaur's), and I will be providing it in just that way in the payload section (I call them 'basic pack' and 'expansion pack', what you see in the Centaur's bay would be the 'expansion pack'). Now, getting it safely onto the surface without KAS to rig some short of crane will probably be much more trickier than it seems (you could test on kerbin), because the thing is quite wider than the payload bay, and it has a ways to fall. And of course, it would use humongous amounts of fuel each refuel, with at least one on LKO and one on LTO. Theoretically it could refuel itself, ~20mT at a time, but... there are faster ways, so I'll leave that as an exercise for the reader. Those are all good suggestions. I have fiddled a lot with rovers in the VAB, but I hardly ever use them on my save! Maybe that should change... In any case, and in the meantime, you can actually turn any of my modular bases into a rover of sorts by putting construction rovers under each module and retracting all gears. I have the intention of sending three of the little guys to Moho on the next window for that very purpose! (But a busy Jool window comes first) Turns out my peak of eternal light wasn't so eternal after all, and I want to check the nearby Mohole for some photo ops. Rune. And the Orca 'roves' so well...
  10. Actually you need some short of adaptor, since you can only surface-attach things you could normally surface-attach in the VAB. But put a Cubic Octagonal Strut , or a BZ-52 Radial Attachment Point, and you are set. Docking ports of other sizes can be directly attached to the rock. Rune. Beware the 1.3.1 bug with asteroids changing seed, tough!
  11. Cool stuff! Asteroid bases are a ton of fun. Two things I found that help make it funnier: -KER's thrust angle and thrust torque indicator. Priceless. You can counteract thrust imbalance in several ways (elastic tractor designs, high engine gimbal, low engine thrust and high counter-torque, differential throttling...) but the crucial thing is that you have to know how much you need to counter it, and when you have fiddled enough. I myself only use nukes to move rocks around (high efficiency), and those don't have gimbal, so I use the Klaw's lock/unlock as a crude gimbal, until I manage to bring the induced torque into the realm of something my reaction wheels/RCS can handle, then autostrut to keep things like that. Anything below 10kNm can be handled with a few reaction wheels, see the upper-right window of this pic to see that in this instance, I was handling 7.94kNm moving this 1,740mT rock. Yes, I was doing 20min burns to get 150m/s... you don't need much to nudge something into the right orbit, if you do it at the right time. -KIS/KAS to build the actual asteroid base. You may not use it for anything else, but directly slapping docking ports on the surface leads to awesome things. And if you take it further and you use attachment points for other non-surface attachable stuff, the sky is the limit: Rune. It is nice if the rock is big enough to make the rest of the stuff aesthetically insignificant.
  12. Well, I really wouldn't recommend Mk2. The drag is horrendous. I know I've recently released the Vega, which actually uses a bunch of those, but in that case the drag is a big part of what actually makes the rocket stable pointy side first, and the whole design is mostly for looks first, with efficiency being a distant second. BTW, a quick pic because even tough it was added to the OP, I don't think I have actually posted it here: Anyhow, the thing uses five engines to put almost the same payload in orbit that the old LackLuster did, and that one also had Mk2-1 adaptors (but only four instead of six), so that kind of proves just how much of a hit each of those things is. On a somewhat, but mostly unrelated note, I think I am going to change my standard tank dimensions. Specifically, I have fallen more and more in love with my half-of-a-previously-standard-length ore tanks, and what you can do with them. Anyhow, I decided to see what I could do with a similarly sized LFO tank, so I started experimenting putting subassemblies together on the VAB to see what I got: KER has a fit when it tries to work out the dV of such a contraption, especially since most of the reaction mass is kept as ore (very volumetrically efficient, and the ore tanks have the best tankage ratio in the game). But, working my trusty KSP excel, I get more than 4km/s out of such a configuration. Yup. Using 340s Isp aerospikes as the engine. That is a lot of fuel in that thing (218mT out of 302 total, in fact). And the hexagonal pattern is pretty pleasing to look at, too, not to mention it has a lot of double-docks to give it rigidity. And it all came out of a humble five part tank subassembly, that the Vega can put inside its payload bay to be refueled on the surface of wherever. Even tough that is a lot of docking ports and extra parts, well, each of them is only five, most destinations won't require the full 14 tanks to get the interesting hexagonal pattern, or I will use nukes to halve the required reaction mass... and what the hell, the whole thing is under 300 parts, I guess I can handle the tankage section being 70 (14x5). So yeah, in other words, let it be known that 'payload section' in the OP is soon to get some movement, after all if I show all these things is because I intend on you guys getting your hands on them. I actually plan on it becoming just as important, as the VAB or SPH sections. After all, these days I end up thinking way more about payloads than launchers! I am also quite interested on feedback on that idea. What payloads would you guys like to get? Would you like them in subassembly form (as they are now), as a completed file for you to pick apart, or something different altogether? Rune. Who's up for some Lego in space?
  13. Hum. You like to tease, don't you? I can't make out what you used for a payload bay, so I guess I'll just have to wait to see the cool graphics when you release it. The only really functional cargo bay's I've been able to make use of are Mk3s, and even then loading/unloading rockets is quite tricky. Rune. ...without KIS/KAS, that is.
  14. Yup, pretty sharp right there. It started with the Vega, and we will go up in luminosity a bit yet... There is a Sirius on the works. Actually, under that fairing, it's a single S3-14400 tank (3.75m), surrounded by 18x FL-T800s holding the spikes (1.25m each), so the shroud is 'only' a tad fatter than 6.25m in diameter. Though if you consider the annular wing, yeah, it's more like 9.1m diameter in the engineer's report. Lots of volume to store lots of fuel! It is a surprisingly simple build under the hood, actually. I even placed the FL-T800 with 6x symmetry three times, spaced 20º, so that I could turn the engines on/off in thirds... which means I didn't even need Editor Extensions to build it! (I still used it of course, to make sure everything was lined up and such... I just didn't need it) I wish you luck, then, because I really want to see want you can come up with. You usually make pretty cool-looking stuff! What direction are you leaning right now to shape it, fairing body like this one? Mk3 fuselages, maybe? Or plain cylindrical rocket tanks because of the decent mass fraction? Just curious, because over time I have tired all of them, but I'm sure there is some great idea out there that I'm still to learn about. Rune. So glad to have my old thread active again!
  15. Update! Added the Centaur, a 20 mT VTVL cargo SSTO. What a mouthful of acronyms! Post below: CENTAUR The first of a new breed: Practical cargo chemical SSTOs, with a payload bay and a generous maximum payload. Why would I bother, if I have a ton of airbreathing SSTOs that can do the same thing, for less fuel and cost? Well, airbreathers are not really that much slower than rockets in getting to orbit, but they are slower. And some people just don't like them. Plus, legendary designs like the DC-X and Bono's monsters have always intrigued me. If only our earth was a tiny bit less massive, or our chemical engines a bit better, we could have one of these. Wouldn't that be cool? And isn't that a good enough reason to build such a thing in KSP? Besides, it is actually useful. And what is a 'generous maximum payload', I hear you ask? Well, in this case, 20mT to 100kms circular, which is nothing to sneer at. Basically, as long as you aren't carrying mostly fuel, you will max out the payload volume long before you max out the payload weight (for handy calculations, the maximum takeoff weight is indicated on the description). Handling is superb, with the powerful RCS system and the almost-empty mass in orbit being relatively low. And once it's time to get back, you won't take any longer than to reenter any capsule: point your butt to the wind, and let the gods of newtonian mechanics carry you down, you will barely see a few temperature gauges turn brownish. Happy launches! Rune. New naming convention for VSSTOs, too. Why do you think that is?
  16. I'm getting good at this. That, right there, was intended. Proof of frantic last-minute terminal guidance: Rune. Ballistic flights are easy, once you get the hang of flying backwards... and Trajectories. That too.
  17. Holy mother of edits. I'm done. I'm finally done! Everything is updated and compliant with 1.3.1, and I even whipped up a couple of fancy pics (I'm not ashamed to say I stole the idea from @Raptor9) and organized things and everything. Check it out! Rune. Now, to put moar things inside!
  18. This thing is shaping up nicely, I think. What do you guys think? 20mT to orbit, seen here during shakeout test, AKA assembling another package for the next Jool window. Rune. For those that say that SSTOs take too long to get to orbit, you can now go ballistic.
  19. That is really helpful, thanks! I still have all the old seeds in various savegames, so I imagine if I can get that to work, it will pretty much solve all my issues. Rune. Good thing I make backups of the backups.
  20. More info I guess, because I found this only after posting myown issue under modded installs: I am short of glad I was not crazy, and this is a thing that happens. Going by @Squelch's comment, and after more tinkering, apparently it's only seeds with >8 characters that get converted to scientific notation... which ends up with a 8 digit number converted into an seven-digit number, with a rounding error ensuring they are not the same. I've tried manually converting the old seed to scientific notation... but since it has eight characters (I assume it's because of that), the game just assigns a new completely different seven-digit one without scientific notation. Rune. Was that really neccessary, and the old seed completely irreproducible? Because it has seriously bummed my day, I have like ten of these asteroid bases in my save.
  21. I am posting this here, because I do run a modded install. But I seriously doubt it is a question of mods! Anyhow, a description of the issue: Asteroids keep changing seed, basically, like the title says. After being perfectly stable for a long time, and having placed a ton of stuff on them with KAS, suddenly the other day I went to one of them rocks, and found that the asteroid had swallowed the ships docked to it. Fortunately, the game now does backups, so I could backtrace the issue to before it happened, and replicate it, taking pictures this time. I think the important bit is the last error, the rest is just a very old save with a lot of mods removed (I think, but would gladly be informed otherwise): With a bit of savegame editing I found that the thing that was happening was that the asteroid kept changing seed when I made a new save, but it would load old or new savegames with the old seeds with no issues. So yeah, I could short of undo the damage. But it would keep changing the seed if I saved after loading that vessel. Well, I left that one alone, changed the seed back manually without it loaded, and proceeded to load another asteroid station, just in case. And then this happened: That is not cool. That base in particular is one of my oldest ones. It has survived four game versions, and still has 600mT of unextracted ore inside. The thing has not exploded, incidentally. It is just an empty globe of stuff (You can see I even wrote stuff with solar panels on the surface) attached to a rock that suddenly is much, much smaller. I actually use it a lot, and building such a thing is complicated. Again, it keeps switching seeds whenever I save with it loaded, but is very happy to load with the old seed from an old backup save, and won't change it unless I save with it loaded (but persistance.sfs autosaves whenever you switch vessels, so loading it means the seed changes immediately). No idea why, it doesn't throw out an error until I load the new save with the wonky seed either! The new seed is something very similar to the old one, but '-2.251617E+07' instead of '-22516169', for example, if that helps in any way. Could somebody help here? I don't want to fiddle around with KAS for one hour only for it to happen again immediately afterwards! And I strongly suspect KAS is not to blame here, because the first time it happened, it was with a ship towing a new rock, docked to it with a Klaw and without stuff surface-attached to it yet. Oh, and a modlist of sorts, for completeness' sake: Rune. I don't even know who to ask about this, frankly, but thanks for reading if you got this far!
  22. I like that Armadillo! I've designed similar stuff myself, fairings are the best thing since sliced bread once you get the hang of them. I would even use something similar in my save, if I didn't like Mk3 adaptor tanks so much, and didn't use kerbin SSTOs as general-use landers already. Kind of like that Armadillo can do 'all the things' the others can? 'If you can make it there...', and all that. Rune. And I have a hunch we will get to change their textures next update! Disclaimer: This is very much not a confirmed thing, that I know of. It might not happen, or need a mod to happen.
  23. Considering how dark nighttime on kerbin is (at least on map mode), it's still nice to have a marker to aim for. Rune. KSC is always on the nightside when you go for it.
  24. Put a marker on it. The classic way has always been launching a kerbal and planting a flag somewhere, but nowadays we can use waypoints placed using the map screen. Rune. It's the small things that make a difference, sometimes.
  25. For old times' sake, and 'cause Mk2 fuselages are crappy: 4,3km/s on LKO, which is actually excessive for the intended purpose (7 crew trained to lvl3 by doing a Minmus landing, pop out of Kerbin's SOI, then return via Munar flyby). But hey, maybe you want to squeeze a Munar landing in there while you are at it. I might make a ~15mT long range cargo bird, removing the foremost liquid fuselage sections to put a larger payload bay, and optionally train in larger batches. Rune. Simple, but it actually looks rather nice.