thegreatgonz

Members
  • Content Count

    63
  • Joined

  • Last visited

Community Reputation

0 Neutral

About thegreatgonz

  • Rank
    Rocketry Enthusiast
  1. Hmm. Maybe there are two separate problems at work here? I've had trouble after splitting a ship as you describe (although part of that is a bug where inactive ships in physics range use the active ship's target instead of their own), but I definitely haven't had more than one ship in physics range when I've had the asteroid problem.
  2. The flight computer has this unfortunate tendency to put the ship into an out-of-control spin under some circumstances. The problem seems to always be associated with changes in the structure of the vessel (e.g. docking, undocking, using the Claw), but it's not a temporary glitch after the change; it persists even if I change the focus, or save and reload. It's driving me bananas at the moment because it's making unmanned asteroid redirect missions all but impossible: the bug kicks in very reliably when capturing an asteroid, and as a result I can't get the asteroid to hold attitude long enough for a burn. I might actually be annoyed enough to try to fix this. Before I sink too much time into it, though, is it a known issue? Any guesses where the problem might lie?
  3. UKS has parts like that (although not the ones pictured), but lately they're discouraged because large bases built that way tend to get eaten by the Kraken.
  4. It looks like you've chosen a burn in a region where the two porkchop plots basically agree. The trouble comes where they disagree by large amounts (like, thousands of dV)-- try something near the bottom left corner, or anywhere below the top-left/bottom-right diagonal. Note that if you try to actually perform a burn in that region, I think you'll find that the plotted trajectory comes out looking really screwy, but I think that's an unrelated stock bug where it doesn't render near-parabolic trajectories very well. In any event, the path your craft actually follows is more sensible (in fact you can trace the correct trajectory with your mouse pointer by looking for where it highlights the "bubble" to add a new maneuver node). The closest-intercept markers look correct, although I haven't run a full mission to verify that, and they're far apart from each other.
  5. I'm getting some fairly sketchy results from this plugin. Here's an example: try plotting a transfer from Kerbin@80km to Duna with no insertion burn, with a time window of year 1 day 150-225, and a time of flight of 65-100 days. If your results match mine, you'll see delta-vs that never gets above 4000, whereas if you plot the same parameters in AlexMoon's launch window planner, the delta-vs get close to 10,000. Even the basic pattern of the porkchop plot is different: in the mod, the "stripes" go from top right to bottom left (shorter travel time requires less delta-v), but in AlexMoon's planner they go from top left to bottom right (shorter travel time requires more delta-v). If I actually execute a burn using parameters from the mod in this region, the orbit I get doesn't take me anywhere close to Duna. The orbit does get me pretty close to infinity, though: it seems to be almost exactly parabolic, right on the threshold between elliptical and hyperbolic (this also plays havoc with the way KSP renders it, but that's a separate issue). This happens pretty consistently with all the solutions I've tried, and that seems awfully coincidental. My guess is that the mod's solver is for some reason unable to produce a hyperbolic trajectory, so when it gets a travel time/departure date combo that requires one, it just gets as close as it can with an elliptical trajectory.
  6. On a related note, I don't understand how you determined which was the "best choice". Lowest launch mass? Lowest cost?
  7. You could make the hard mode even harder: only show biomes that you've performed an experiment in (Or unlocked in the resource system? Or observed with ScanSat?). Basically, only show the biomes that the user knows about for other reasons. This tentatively sounds reasonable to me. It could even be convenient: a lot of the time, I want to know what I can do in the places I can already get to, and having Eeloo in the list is just a distraction.
  8. I believe Kermen's point is that when a satellite is transiting the sun, you have to literally stare directly into the sun to receive the signal on Kerbin. Even if that doesn't outright fry your radio antenna, it seems pretty implausible that you could dig the signal out of that background.
  9. The workaround I've been applying is to only place the stakes right before finalizing the build, and then remove them right after. On Minmus, that's usually more than enough time to grab them before they fall over. It might not work as well on bodies with stronger gravity, though.
  10. KER also reports weird horizontal velocities. I was told over in that thread that it's a bug in recent versions of stock KSP. ...and just as I was writing this, the new KER release dropped, with a fix for this. Whatever they're doing, kOS could in theory do the same thing.
  11. Hi, resurrecting this old post because I'm experiencing exactly this issue (attached stakes falling over and exploding), despite running KIS 1.2.0. Are you sure it's fixed?
  12. 1. There's no way to access KER from kOS, as far as I know. 2. In older versions of kOS, you could compute atmospheric efficiency easily: there was a function to get terminal velocity, and atmospheric efficiency is just the ratio of your velocity to terminal velocity. That function has been removed from kOS, but that's because... 3. With the new aerodynamics model in KSP 1.0, terminal velocity is much harder to compute. I don't think KER is actually doing that; my hunch is it's just using the old model even though it no longer applies. 4. I've heard that 100% atmospheric efficiency is no longer a good rule of thumb for setting your launch velocity anyway.