• Content count

  • Joined

  • Last visited

Community Reputation

968 Excellent


About DerekL1963

  • Rank
    Rocket Scientist

Recent Profile Visitors

1810 profile views
  1. To not use aerobraking...
  2. Building a space station in the sandbox just because. I devised a simple and elegant way to move the RCS on my delivery tug close to the loaded/average COM.
  3. No, we aren't really taking about the same thing. You're discussing 3D printing as an alternative for existing conventional processes. I very specifically stated that it's not just an alternative. Though I linked to a prototype as an example of something that can't be done with existing processes, I have specifically otherwise avoided using the word prototype because 3D printing is rapidly moving out of producing prototypes in the lab and into the world of manufacturing.
  4. 3D printing and CNC are used not to eliminate welding, but to reduce the amount of welding. The F1 engine required an enormous amount of touch labor to assemble components from individual weldments that we'd machine as single piece today. (No CNC or six-axis machines back then.) No, 3D printing is not an alternative to machine for things that can be machined. The point of 3D printing is create things that cannot be created with more conventional methods or which it would be prohibitively expensive to create with more conventional methods. Such as this prototype engine manufactured at Lawrence Livermore.
  5. For the lander/return vehicle in the VAB or for the whole vehicle at liftoff?
  6. When I played using Remotech, here's how I did it: 1. Choose one bird as the "reference" bird, and get it into the "perfect" orbit and note it's orbital period. 2. Move a second bird into the "perfect" orbit, and then move it into the proper position relative to the reference bird. If it needs to move East, drop the Pe and let it drift, then circularize. If it needed to move West, raise the Ap. When you're at the proper relative position, match periods (or preferably match periods by matching the semi-major axis). The key here is to watch the difference in orbital periods between the reference bird and the bird being moved into position. The larger the difference, the faster the relative motion, the harder it is to brake precisely into position. So, if it needs to drift a long way you can start with a large relative difference in orbital period and then slowly lower the relative difference as you get closer. (Tweaking your thrust down is a massive help as you're making the final adjustments. Correct that, it's not a massive help, it's the only way) It took me a huge amount of practice to nail the procedure, but in the end I could nail position +/- 1 degrees and period to +/- .01 seconds. I'd typically use tweaked RCS for the final persnickety adjustments. 3. Repeat with the third bird. Using a mod such as MJ or KER that gives you a readout of the relevant data (Ap, Pe, period, semi-major axis, angular position relative to target) is a massive help. If you do use such a mod, matching orbits by matching semi-major axis is much easier than trying to match period by matching Ap and Pe. Just out of curiosity why did you use those massive RA-100's when all you need are HG-5's?
  7. I've already pointed that out, twice. ("Except at the smallest scale (where the weight of the drive dominates) the NERV will always be lighter".) I didn't say it couldn't compete, not even once. I pointed out (twice) that (except at the smallest scale) a vehicle powered by Poodle's will be heavier than one powered by NERV. Congratulations! You've "proved" what I already admitted to and pointed out two times now - at small scales a NERV comes off far worse. No offense, but do you even understand what this discussion is about? Please scroll back up and read the OP's post. This discussion is all about gargantuan vessels - vessels in a weight range where NERV's have a vast advantage.
  8. Yes necessarily. Except at the smallest size (where the weight of the engine dominates), if you want the same d/v as a NERV a conventionally powered vehicle end up heavier. That's a mathematical and unavoidable consequence of the drastically lower ISP of those engines. (Or to put it another way, your quoted comparison of the weight of the engines is dramatically and grossly incorrect and misleading because you leave out the weight of the fuel.) Here's a simple comparison: A NERV (vacuum ISP of 800) producing 5k d/v: A Poodle (vacuum ISP of 350) producing 5k d/v: A Rhino (vacuum ISP of 340) producing 5k d/v: (Even though the Rhino's ISP is only slightly lower than Poodle's, it requires much more fuel because it weighs five times as much.) The math doesn't lie. The math never lies. Except at the very smallest scale, where the weight of the engine dominates, a NERV will always have a dramatically higher d/v for the same weight due to it's dramatically higher ISP. Always.
  9. Chang-Diaz didn't do anything to me. What 'did' something to me was endless posts (such as yours) the pronounce the VASIMR to be a viable solution even though (as you now admit) it's still very early in development. As it stands, VASMIR is a power hungry beast - and requires either solar panels of outlandish size, or a very heavy reactor and either way results in a tug with an impractically small payload capacity. (The latter especially when compared with it's cost.) For VASMIR to be practical requires serious breakthroughs in it's efficiency or in the efficiency of it's power supply - or magic pixie dust. (As a point of reference, the current model requires 200KW - the ISS's arrays produce 120KW.) I'm not judging the drive, I'm judging the ungrounded assumption in your first post that it's already developed to the point where one can make reasonable assumptions of it's availability and capacity and thus presume (pronounce really) that it will be useful. I'm not against the drive - I'm against counting eggs that not only haven't been hatched, their great-great grandparents haven't even met yet. A VASIMR engine requires large amounts continuous power for extended periods - something no battery now or in the near or medium term can produce.
  10. Works for me too...
  11. Quoted because I simply must point out how absurd and true this is.
  12. That's why you go high rather than splitting down low - you minimize that inefficiency by minimizing the swept angle. (My rule of thumb is "orbital period <= 1/8 burn time". I've never had to make a larger than normal mid course correction burn using this method. (As compared to the burns made down low with a higher t/w engine.) Except at the smallest sizes, a high TWR engine also considerably increases the weight of your vehicle, significantly reducing the total TWR of the vehicle. I've never seen the problem here. With MJ automating the burn, I just go do other things during long burns. I either swap to my browser and cruise the web, or sit on the couch and watch anime, or go into the kitchen and start dinner... once I even went to the grocery store.
  13. I want to make sure we're talking about the same thing. My objection is not to bundling MOLE and BARIS (that is, I'm not objecting to them being included in the same download), nor to installing BARIS. (I might want to run it at some point, I played the heck out of the original back in the day.) I'm objecting to being unable to completely opt out of what is described as optional functionality. If I've disabled BARIS in a given save, then it shouldn't display an icon in the stock toolbar. Whups, I found the white square error last night just before going to bed and decided to investigate this morning... My fault, I shouldn't have done that while still on my first cup of coffee. Thanks for catching that. My apologies.
  14. That's exactly where it is. No, thank you, I have BARIS disabled because I don't want it in my game. If it's not in my game, it should not be taking up screen space. It's bad enough that I have to update it so I don't get an error message when I'm loading the game. (Because I don't have the option to not install it in the first place.)
  15. Still working on my science mode campaign prep work... With dMagic's science mod installed and science return set to 50%, I've established to my satisfaction that 50% is too low. (I'm trying to avoid getting too much science.) The key problem is that I have a set of rules that determine how often I can launch (sort of a poor man's roll-your-own KCT), and unless I fill all my slots with unmanned science missions I end up with long 'dry spells' with no manned missions while waiting on more science. And of course, filling up all the slots with unmanned missions to get science for manned means no manned in the first place... The solution comes in two parts: - raise the science return (probably to 75%). - revamp my launch cadence rules, allowing the number of launches per year to rise over time. (Reflecting increased infrastructure as the program matures.) As an aside, I came up with the idea of launch cadence rules to basically force time to go by. Otherwise, if I launched as soon as I landed, I often found myself landing on the Mun by the end of the first calendar week... And since launch slots are limited, I have to consider my priorities and goals when one comes available. (Which is something I enjoy - the planning and scheduling.) I'm also tempted to write a MM patch making *all* antennas into relays...