Zhetaan

Members
  • Content count

    290
  • Joined

  • Last visited

Community Reputation

326 Excellent

About Zhetaan

  • Rank
    Curious George

Recent Profile Visitors

1812 profile views
  1. Flyby Finder only deals with planets that orbit the sun; it won't help here. Try the KSP Trajectory Optimization Tool, instead. I can't guarantee that it will work any better (I haven't used it yet) but it's a start.
  2. Kopernicus handles solar panels, not Galactic Neighborhood. The most recent release is supposed to fix the problem (the popularity of Galileo's Planet Pack rather forced the issue--relevant post here), so if you have that and it is installed correctly, the next question to ask is: what other mods are you running? Kerbalism is a known incompatibility. There may be others.
  3. Once upon a time, TaranisElsu was planning to add a waste-to-food converter, but it never happened. That being said, there are mod expansions (Mod mods? Metamods? Modception?) that convert waste into food. On the other hand, you're not likely to find many that perform the conversion at 100% efficiency. There are some that reduce the resupply needs to 10% or less, so you could conceivably send a mission that won't need to be resupplied more than once every few centuries, but the consensus was essentially that adding a life support mod and then adding converters so that you never had to pay attention to the life support mod was rather pointless: the only difference between running TAC with 100% conversion and running no life support at all is that the TAC install runs slower because it keeps calculating the resupply timers for Kerbals who will never run out of food. On the gripping hand, there's nothing preventing you from taking one of these mods and editing the configuration file yourself. They may be out of date, but they're just parts, not plugins, and honestly, a few edits to the configuration file may be necessary to get them to work anyway. This is the munseeker Greenhouse. (Last updated for 1.1.3) This is the SETI Greenhouse. (SpaceDock link) (Last updated for 1.2.2) This is BioMass. (Last updated for 1.0.2) This is Kerbal Planetary Base Systems. (This was updated for 1.3, but I do not know whether any of the greenhouse parts work in orbit).
  4. @Tux1: You're not following the intended campaign, true, but the rocket you designed is working exactly as it should. I will not revisit the reasons why you generally should not use Seperatrons as boosters; simply accept based on your own experience that they are inadequate to the task. The point of these two missions in the campaign is to show both the basics of how to fly and the advantage of staged rocket designs. You're meant to keep a full fuel load for each but if you wish, you may turn down the thrust limiter to keep the thrust-to-weight ratio at about 2. For your first rocket with just the Stayputnik and the RT-10, the mass is 3.61 tonnes. The weight on Kerbin's surface is therefore 3.61 * 9.81 (this is the acceleration due to gravity at the surface) = 35.414 kilonewtons, or kN. The thrust of the RT-10 at sea level is 197.90 kN, so the full thrust-to-weight is 197.90 / 35.414, or approximately 5.59. To start with a thrust-to-weight ratio at around 2--and do keep in mind that this will change with altitude (gravitational acceleration decreases as you go higher), with air pressure (thrust increases as air gets thinner), and with the rocket's mass (weight decreases as you throw propellant out the back)--turn down the thrust limiter to about 36%. For the second rocket, the idea is that you take your first rocket (or something close to it) and add a decoupler and second RT-10. Since you'll be higher up when you light it, you may want to consider turning down the thrust limiter on the second stage (the original part of the rocket) even further, to about 30%, but for the first stage, the second RT-10 and decoupler add another 3.61 tonnes. Forgetting the battery and parachute for now, the weight is 70.828 kN, but the thrust is the same, so the new thrust-to-weight ratio is 2.79. To turn it down to 2, set the thrust limiter to 72% on the lower booster. The reasons for turning down the thrust are several. First, you have fewer drag problems in the lower atmosphere, whether they come from heating or from the air tearing off pieces of your rocket. Second, the rocket is easier to control if the high relative wind speed is not forcing it into a particular orientation--efficient rockets need to turn. Third, it is inefficient to burn so much fuel so low in the atmosphere; all rockets perform better in vacuum than they do at sea level, so while it is important to get out of the lowest part of the atmosphere quickly, there is also a diminishing return where you burn the fuel that you would otherwise save to make it happen faster than necessary. What you will see for having done this is that turning down the thrust limiter makes your rocket go higher on the same load of fuel (to a point). For the second mission, the idea is that your first stage will not go so high as your earlier rocket (because it's heavier), but because you have a second stage, you'll go far higher than you would any other way. If you want to test this more thoroughly, you can do so with a rocket that uses two RT-10 boosters side-by-side and another that has them staged in sequence. I will leave the problem of designing a balanced twin-booster rocket to you. P.S. I will say that inasmuch as this campaign is meant to re-enact historical space flight, you've done especially well: your second rocket is your very own Four-Inch Flight! P.P.S. Don't try to save money with solid rocket boosters. They're already the cheapest rockets in the game.
  5. I have guesses, but no concrete figures. I was planning on working something up this weekend, actually; you're the second person I've seen recently who wanted to put together a mission like this.
  6. I hate to be the one to rain on the parade, but if you try to set up these bases, you will lose them. Unfortunately for you, there is a minimum altitude below which KSP automatically deletes low-flying craft under the assumption that they would crash anyway--even though this assumption is sometimes incorrect. This has a lot to do with the fact that in the code, every planet surface is a thin shell and orbital speeds are fast enough that a craft can glitch through that shell between physics ticks. To illustrate, let's assume that you have a very slow computer that can only calculate one frame per second. In order to approximate continuous motion, what KSP does is figure out where your vessel will be each second and 'jumps' it to that location instantaneously. If you're moving at .1 metres per second, then every frame has it jump .1 metres. If you're moving at orbital velocity of several hundred metres per second, then each second, the vessel jumps several hundred metres. In this illustration, the simulation would be slow enough for you to see it; if there is a rock or a different vessel or the surface of the planet in the way, there is no collision, because in the code, the vessel never contacts anything: it instantaneously jumps from one point on the orbit to the next and never checks to see whether there was anything in the way. Those who try to have a demolition derby in space also encounter this problem: head-on collisions in KSP tend to glitch through. In KSP, the physics simulation operates much faster than that, but often, the speeds involved are also much faster. This is a problem because it can conceivably allow a vessel to glitch right through the surface of a planet and come out again without ever actually crashing. To counter this, the game assumes that anything below a preset altitude (which varies by body) will or has crashed, and because of the nature of the physics simulation, that altitude has to be higher than a vessel travelling at orbital speed can traverse in a single tick. Obviously, there are exceptions. This only applies to vessels that are both in flight and on-rails. In other words, your already-landed bases are safe. Also, if you are off-rails (meaning you are either controlling the vessel or controlling one within the physics range of 2.5-ish km) then the simulation uses much finer calculations and you won't have to worry about it. Also, auto-deleting your lander while you try to land it would be in bad form, so the game specifically avoids auto-deletion of a controlled vessel. (Additionally, if you're controlling it and you do crash, you get to see explosions. Auto-deletion just removes the icon from the map view; it's very boring.) What this means is that the GIF linked above was not only a matter of fine orbital manoeuvring, but in fact required an additional effort of great technical complexity to surmount the limitations of the game as a simulator. What happened there is that the rover with the loaded Kerbal was parked on the Minmus flats ahead of time, and then the satellite's orbit was adjusted. When the satellite came in for its low-orbit pass, the player had to wait until it was within physics range of the rover, quickly switch to the rover, and launch the Kerbal, all in record time. Note that when the GIF begins, the camera view is side-on, just as it usually is when you first switch to a vessel. If the player had truly begun with the rover, then the satellite would have been auto-deleted. Without raising the periapsis, the satellite will still be auto-deleted unless the player makes a point of returning to control it through the low-altitude portion of every single orbit.
  7. I used Flyby Finder, by @PLAD. It takes a bit of guesswork to figure out a set of initial conditions that will yield results, but it works.
  8. Simply entering and leaving Duna's orbit makes a gravity assist; you get gravitational influence on your flight path every time you pass by any celestial body that is not the destination of the flight. Whether that influence counts as an assist depends on whether you consider it assistance. Maybe it's really gravitational hinderance (I'm looking at you, Ike). Since you ask about boosting to a prograde orbit, I wonder whether you mean something along the lines of a free-return trajectory such as many of the Apollo missions used. If that is the case, then no; the gravitational relationship is not the same, so the concept does not apply. Free-return (with the retrograde flyby) is only possible when the vessel goes from a primary to a body orbiting that primary and then returns to the primary. Duna does not orbit Kerbin, so this is not possible. If you are already in a retrograde orbit around Duna, then you can return from that orbit without needing to switch directions; just reverse the rules about when to leave. The object is to return-burn so that your exit vector overlays Duna's retrograde orbital vector, and you can do that no matter whether you orbit prograde or retrograde to Duna itself. You'll only be burning at local night rather than local day. If you were asking about honest-to-goodness gravity assists, the problems with gravity assists at Duna are that Duna is relatively low-mass, so there isn't much assistance it can give you, and that it has an atmosphere, which puts a hard limit on how much of the possible assistance you can actually use. That's not to say that it can't help you; I'm only warning you not to expect dramatic results such as you can get from Eve and Jool. There is a Kerbin-Duna-Kerbin flight path that begins at Kerbin on day 239, costs 1303 delta-V, encounters Duna on day 372, flies by at an altitude of 65.7 km over Duna's surface, and returns to Kerbin on day 1087. The total flight lasts for 848 days and costs 2611 m/s. I include that because I do not know the final flyby altitude and do not wish to obligate you to an aerocapture that it may turn out you can't actually do. I found some earlier and shorter flights, but the only cheaper ones I found fly by Duna at much higher altitudes.
  9. @omelaw: With 2200 m/s in the lander, then assuming you can get the mothership into close orbit of Vall, you can land and return from there. I'd advise against hopping around, though. You can visit Pol and Bop without trouble. With the right gravity assist, you won't need aerocapture, and that's a good thing; for the amount of fuel it saves, you may not leave yourself enough delta-V to go that far down the gravity well and climb back out again if you want to land on three of the moons as well.
  10. I was assuming that since firearms are only props in The Sims, it was actually the very first time that Nick ever fired one: he just isn't a good shot.
  11. Pre-v1.0 grand tour flights were once the pinnacle of achievement in KSP. I suppose they still are, but they are easier now. If you find doing a no-ISRU grand tour too easy, then you can try to simulate a pre-v0.23.5 grand tour and do it without 3.75-metre parts. Once upon a time, we had to do Jool-5 missions with nothing larger than orange tanks. Multiple-body gravity assists are also a challenge and worth the time you spend studying how to do them.
  12. Parachutes work on Duna; they just don't work well. They are usually worth the mass to take them, but they often don't slow you down enough on their own to prevent crash damage. For this reason, you ought to take both parachutes and descent-stage rockets to ensure a trouble-free landing. If you really want to land your rover on parachutes alone, make it as light as possible and remember that because there's so little air on Duna, you will need a lot more parachute than you're used to providing for Kerbin landings.
  13. Are you planning on going to Duna and then continuing to Jool as a sort of little grand tour, or will it be two separate missions?
  14. @canisin: You can add a CLS module to the reaction wheel or turn CLS off when you're at that station, I suppose. I know that CLS has an off button mainly intended to let you evacuate old stations if you decide to install CLS in the middle of a save, but nothing prevents you from using it at any other time. Given that this appears to be CLS doing exactly what it was designed to do, it all depends on the point at which you think you go from setting the parameters of your play style to cheating at solitaire. For what it's worth, if you're going to play this game, then you're going to have to roll with the punches. The fact that you effectively punched yourself in this case just means you should have a good laugh and move on, whether you decide to bring the large construction crew, de-orbit the module and send a replacement, or do what @bonyetty suggests and suddenly remember that you meant to install it that way--OH&S is important, after all. You wouldn't want wild goo just floating about in the crew compartment.
  15. @HebaruSan: True, but if that happens, the solution is to back up a step and refine it again. The point is to break up the transfer into manageable pieces; however, just as everything else in KSP is an approximation, so too is breaking up the transfer planning. There is no single action you can do that affects only one variable, so the only way to break the problem into manageable pieces with the tools at hand in stock is to work out a way to limit the effects of those changes on all but one of the variables and then make corrections to the approximation. It's Newton's method, in space.