thegreatgonz

@Anth It sounds like there's a different bug here, then: in situations like the one in the screenshot, the game stops modeling the vessel's trajectory at a certain point (in this case the second close approach to Ike), but continues drawing a trajectory past that point (the blue line from the Ike encounter back to the vessel's current position). That's really surprising and confusing, and makes it very hard to plan: if I want to figure out when I should stop trusting the displayed trajectory, apparently I need to be aware of events (such as the first close approach to Ike) that aren't visible in the UI and don't affect the vessel's actual trajectory.

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 Home 64-bit (10.0, Build 19045) | CPU: Intel(R) Core(TM) i7-9700K CPU @ 3.60GHz | GPU: NVIDIA GeForce RTX 2080 Ti | RAM: 16384MB In the attached screenshot, the planned trajectory (orange) passes deeply through Ike's SOI, but the actual trajectory (blue) stays in Duna's SOI (I've also attached a save to reproduce the problem). However, the only planned maneuver has 0 delta-v, so the two should be identical. After advancing time far enough, the actual trajectory suddenly updates to show the Ike encounter. Included Attachments: quicksave_9.json .ipsImage { width: 900px !important; }

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 Home 64-bit (10.0, Build 19045) | CPU: Intel(R) Core(TM) i7-9700K CPU @ 3.60GHz | GPU: NVIDIA GeForce RTX 2080 Ti | RAM: 16384MB The VAB staging UI in the attached screenshot shows the NERV stage as having a burn time of 23m:56s, and the in-flight staging UI shows the same, but in fact it burns for 3h:23m:56s. When burning, the remaining burn time counts down to 0, and then loops around to 59m:59s, three times. The same problem occurs with ion engines, where it's nearly unavoidable because even the smallest Xenon tank will keep an ion engine running for more than an hour. Included Attachments:

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.

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?

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.

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.

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.

On a related note, I don't understand how you determined which was the "best choice". Lowest launch mass? Lowest cost?

But keep in mind that the link's orbits for Minmus are bogus...

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.

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.

Any guesses when this is going to get some love?

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.

What's OSE?