• Content count

  • Joined

  • Last visited

Community Reputation

851 Excellent

About Laie

  • Rank
    Capsule Communicator
  1. All I can say.... check F3 after the explosion, to see what blows up first. Might give you some insight. There's been issues with parts being considered to be wider than the heatshield even though looking at the vessel one wouldn't guess. If that's your problem, you need a wider shield.
  2. How to make KSP more accurate?

    @linuxgurugamerslight misunderstanding here, edited my post for clarity. Not 100% sure if it's true, though, or if the first stage would fall just a little short.
  3. How to make KSP more accurate?

    There's plenty of good answers already, but here's my two cents. an (IMO minor) issue is the simplified aerodynamics. FAR (Ferram Aerospace Reserach) does quite a bit better, but as long as you only do rockets and return in capsules you won't notice the difference. The core issue of most oddities is that the planets in KSP are so small while still having real-life-like gravity. The only true solution is upscaling the planets. Just two of the problems: Orbital velocities are slow, yet atmospheric entry has to be hot and dangerous according to player expectations. KSP Rockets are inefficient, mostly by parts being way more massive than they are IRL (the real Saturn V / Apollo would make Kerbin orbit on the first stage, and has enough dV for a Jool-5). throttling and restarting rocket motors is non-trivial IRL (may want to try Real Fuels for that) simplified orbital mechanics are a pretty minor quibble in my book. If you want to have fun with lagrange points and low-power transfers, Principia is there for you.
  4. solar panels as radiators

    Short answer: In your case, no. Long answer: There's two kinds of heat in KSP: ordinary heat from friction and sunlight and engines running hot, and "core heat" which happens entirely inside parts and is basically totally decoupled from the normal heat system. For ordinary heat, solar panels radiate well. They have insulated sockets which limits their use as heatsinks, but they can shed quite a few watts nonetheless. However, only dedicated radiator parts can pull core heat out of a drill or converter. So for your particuar use case, you're out of luck.
  5. To the best of my knowledge, staging only ever happens once to any part. If you want to toggle it repeatedly, you need action groups (or the context menu).
  6. How a build a 22,000 m/s dV spaceship?

    @Streetwind: periapsis-kicking is only good for the first 1km/s, from then on you have to pull through in one go. When going to Jool, that's another 1100m/s or so you have to provide in a single burn. Believe me, I didn't pull that 0.15g figure out of my nose, nor any other orifice: at that acceleration, said burn lasts over 12 minutes, and no matter how smart you set it up, you'll spend an extra 100m/s compared to doing it on a still leisurely 0.3g. Just check your dV meter before and after the burn to get at the actual dV expenditure.
  7. How a build a 22,000 m/s dV spaceship?

    Sorry, cannot resist the urge to nitpick... It is totally possible to be too miserly with the engines. When leaving Kerbin, I'd recommend a TWR of no less than 0.15 (preferably 0.2) -- below that, the losses from a long-duration burn will be greater than the straightforward dV loss from adding more engine mass. In a solar orbit, you can probably afford much less; actually, you can afford to stage most engines and continue on miniscule thrust once you've accumulated a few hundred m/s of excess escape velocity and are far enough from Kerbin to be flying away on a virtually straight line. The 0.15g rule is really only about Kerbin departure, for most of this particular mission you can make do with less. So yeah, I'm nitpicking.
  8. How do you do a gravity turn?

    I've had great results with a rather simple approach that would turn the rocket so that srfprograde would reach X pitch by the time I had an airspeed of Y (IIRC 80° @ 100m/s, but I'm not too sure). Then follow srfprograde until the first stage burned out, and only *then* would I start to seriously consider where I was and if any adjustments were necessary. The X degree by Y airspeed scheme turned out to be surprisingly versatile: over a wide range of initial TWRs, it would place me on a reasonable trajectory the later parts of the script could work with, *without* requiring massive control inputs at any time of the flight. It looked a lot more planned than it really was. ETA: Even better, because I did too. Above approach worked very well for Atlas, Titan, and all types of Saturn. Also Proton and R-7.
  9. The best way to reduce launch cost is to reduce payload mass. Oh, that's what you're going after... on that premise, winged jets it is. Rockets just cannot compete, period. Of course, actual launch cost is pretty high -- you're rolling out a lot of expensive hardware and any failure is really gonna hurt. It's the recovery that makes it work in the end. Exactly. Nah, if you have any control at all (a few airbrakes will do), landing on the runway isn't all that difficult. What poisons recoverable rockets is that they effectively have to be SSTO (because recovering earlier stages is difficult at best, and comes at a steep discount even if you can make it work). However, one thing to keep in mind... With stock settings, one can totally afford throw-away rockets. Not accounting for recovery in any way is a great way to reduce (actual) launch cost and also takes care of several failure modes. Recovery takes as much time as a launch if not more, and compared to the cash flow the actual mission generates, the payoff for recovering the LV tends to be meager.
  10. Maneuver node off by 200 m/s?

    That is indeed a good question. I *think* this comes very close to the mark. I believe it compares the track you are on with the track you want to be on (the dotted line in map view) and somehow computes a vector that takes you from one to the other. Said "tracks" can also be expressed as a vector+timestamp+orbital_mechanics, so I guess it comes down to comparing vectors. But, as I said, that's only guesswork. I've done some experiments where I started the burn sooner or later, or tried to not strictly follow the mark on the navball ("if I don't point as far in during the first half of the burn, maybe I don't need to point as far out later on") but none of these have lead anywhere: Merely comparing dV is a bit one-dimensional, and beyond that I don't know how to quantify if one outcome is better or worse than another. On a practical side, I did get good results with splitting burns, that is, lining up two or three maneuvers end-to-end with only short breaks between. Planning this is a PITA (and it breaks down if burn times overlap, so you really want to be conservative), but the upside is that you get the encounter you've been aiming for, at very nearly the dV expense as it said on the nodes.
  11. Maneuver node off by 200 m/s?

    That's just an artefact of the maneuver-node smartness. Nodes try to correct for all kinds of errors. Point left for a little while and you will notice how the marker shifts right; it tries to point in the direction you need to go (now! instantly!) to put you on the desired speed&vector. I do *not* know how it really works and what it takes into account; I do know that it works well until it no longer does; taken beyond it's limits it starts to make matters worse. Going halfway around Kerbin on a single maneuver node is bound to lead to strange results.
  12. Maneuver node off by 200 m/s?

    @Brainlord Mesomorph: simply put, this is (part of) the price you pay for a low TWR and the resulting long-duration burns. Watch where the maneuver node marker is on the navball during the burn. Most of the time it's not lined up with the prograde marker. If you started four minutes early, it was probably 20° off (inwards to Kerbin) ; later during the maneuver, I guess that it might have been pointing outwards by a similar-if-not-larger amount. A smaller, but still significant, amount is lost because you're not doing a short impulse that's basically at right angles to gravity, but keep pushing while Kerbin's gravity is already tugging at your coattails, trying to hold you back. In other words, old-fashioned gravity losses.
  13. Gravity Assist Magic

    If you plan on visiting all these places anyway, and will refuel at every stop, I suppose that dV is not a suitable metric for efficiency. I'd say you want to line up your stops so that you can get to your next destination without worries, with frequency of launch windows being a secondary but worthwhile consideration. Eve-Duna-Jool should work just fine. Or, if you want to touch all possible bases, perhaps Dres-Eeloo-Duna-Jool-Eve (with one Eve gravity assist before you capture on the next round).
  14. Gravity Assist Magic

    It's been said twice already, but wth... From Minmus, drop to a low PE near Kerbin, then do the transfer burn there. You want to use another craft in LKO to plan a bog-standard transfer, just so you know where your PE has to be. That way, you spend about 400m/s to get from Minmus surface to Kerbin PE, and another ~1200m for the transfer burn to Jool. With more than 1km/s left in the tank, a straight Vall landing might be doable without any gravity assistery at all... barely... certainly if you pass Tylo and collect 500m/s. If your craft can refuel on Laythe, going there first might be easiest. Not sure if 3km/s is enough to handle Moho even by way of Gilly, though. Anything else should be doable, though.