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?

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.

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?

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.

Has anyone else had a problem where the dV reported on mouseover, and displayed by the marker on the legend when you click, is sometimes wildly inconsistent with dV indicated by the color of the porkchop plot, and by the "total dV" field when you click? For instance, I'm looking now at a plot where the mouseover text said 4760, but the "total dV" when I click is 2795 (the latter is the one that makes sense). Also, a feature request: sometimes I want to optimize my departure for soonest arrival time rather than shortest travel time; would it be possible to have a setting to make the porkchop plot show absolute time rather than travel time on the vertical scale?

I don't remember, sorry. I definitely had KAS, but I may have been using a pre-KIS version; not sure.

I've noticed that too; I think it's a recent change. I used to use KER's horizontal velocity indicator to execute landings. I'd aim at the horizon parallel to the surface retrograde marker, burn until my horizontal velocity was close to zero, and then do a suicide burn. This doesn't work anymore, though, because I can't get the horizontal velocity down to zero.

This isn't how it's working for me. I have a vessel that's reporting "crew lost" only an hour or so after being decoupled from its supplies storage. Is this a bug? Edit: And yet oddly enough, I was still able to EVA the crew, which I thought was disabled when the crew was lost, and re-boarding the ship seemed to reset the timer.

FWIW, I'm finding accuracy seems to vary a lot with the ship. I seem to be getting much better results with my 2.5m ships than I did with my 1m ships.

Is it supposed to be possible to see resources in the zoom window? I can't seem to do it. Edit: Never mind. Just found the "Zoom Requires Narrow Band Scanner" setting.

+1. This is a dealbreaker-- it means that an outage on somebody else's website can stop me from playing KSP.