ibanix

No. I was surprised at that, I expected at least one vomit-inside-helmet moment. However, I will add that there ARE some serious blood/wound moments in the movie, if that is an issue.

Nice, I've been looking for something like this.

It turns out that you can not use the time given as an exact time. The angle of ejection will be wrong. If I take the time given, plug that in, and then adjust to the correct angle of ejection by moving the node, I can get to interception. But the time will be off by up to 1/2 of your initial orbit time.

So I tried this on a different install of KSP, and still got the same answers which when plugged into the game, do not result in an intercept. Is anyone else having this problem?

The planner appears to be giving me data that does not work correctly. See this screenshot: (Ignore the bug with Precise Node reporting the year as '1' instead of '3'; the UTC is correct. I've reported the Precise Node bug.)

I seem to have found a bug. 1) Set your time format to Earth normal 2) Make a node 3) Note time as '1 year xxx days' 4) Change time format to Kerbin format 5) Check node 6) Find that time is '1 year yyyy days'. Time SHOULD be '3 years yyyy' days for this UTC (21060000). Saving and reloading did not fix this issue. - - - Updated - - - This problem also persisted over a reinstall...

http://alexmoon.github.io/ is giving me very strange solutions, and not for Mun->Minmus either. I'm trying to do a Kerbin->Dres transfer, and for my particular starting/ending orbits I get: Kerbin (140.5km starting orbit) Dres (13138km ending orbit) UT: 21056544 Prograde ÃŽâ€v 1,517.8 m/s Normal ÃŽâ€v 208.4 m/s -- This does not get you ANYWHERE near Dres. - - - Updated - - - Yeah, something is either really messed up with the http://alexmoon.github.io/ or with my game. The Kerbal Alarm Clock is giving me transfer window dates that are so far off from optimal according to the calculator that it's scary.

http://ksp.olex.biz/ does not but http://alexmoon.github.io/ does! Hm, I didn't realize that. Thanks. Also thanks for the detailed answer.

Anyone know what the best transfer orbit from is from Minmus to the Mun (or the reverse)? Thanks.

To save yourself a huge amount of time when doing final approach docking, I strongly recommend the Docking Port Alignment Indicator mod. Short version for using: 1) Rotate the craft until the large orange cross-hair is dead center to the targeting brackets 2) Use the IJKL RCS keys to push the prograde/retrograde marker toward the direction of the yellow lines 3) Slowly move the prograde/retrograde marker back toward dead center as the yellow line approach the center 4) Zero out the yellow lines on dead center 5) Use H or N RCS keys to approach and dock

There is a nice mod that allows you to select root with one click: SelectRoot

Thanks for the info about Part Commander, that looks super helpful.

When working with complex stations in orbit, where multiple craft are docked together, I often find myself highly annoyed trying to view a particular part of the station. The camera control does not seem to let me pick a base section to work from and move the camera around on. For example, I like to send a lander to Minmus to collect science, then dock it with a lab in orbit and offload the science. Trying to select the instruments on the lander craft after docking is a major PITA, because I can't rotate relative to the lander. Any solutions to this problem?

Technical question for Peppie23: What type of pathing algorithm does RT use to find a link back to KSC, when more than one path is available? On that note, have you considered adding an option for 'link saturation' where a dish can only handle so much upstream/downstream traffic at once?

KER Settings -> Orbital -> Time To Manoeuvre Burn Fire up at 100% when this reaches 0 s.

The version on CKAN still reports max KSP version as 1.0.99. Any chance that can get fixed?

That's not much help, I already knew that =)

That appears to be about the SoI transition, not the issues with 'regular' orbits.

That can't be true, because we have the 'on rails' mode where these things don't happen.

I get flickering when using the 4-way lights. They also seem way too bright. Any ideas what I might be doing wrong?

This is a really, really annoying issue for anyone trying to make SatCom systems with RemoteTech. Is there any way around this issue, even at the loss of other accuracy? Can the orbit simulation calculations be turned OFF in some cases? Once I get a craft into a stable orbit with no SoI change and no atmospheric effects, I don't want to have the orbit being recalculated unless a dV change happens.

I continue to have the same problem I've had with all satcom setups: Trying to get synchronized orbits. The game likes to have orbit times start to 'wander' - I've watched orbit times of 6h 0m 0s slowly change to 5h 59m 59s ... and keep going down. Without any control or dV change. Trying to get exact circular orbits is also a pain - even a difference of a km or so, over time, will cause satellites to end up out of alignment. Any suggestions on these problems?

I noticed it going to zero during one pass through the shadow of Mun. When it play it at low speed, the same thing does happen, but not the same outcome.

I have a bug / highly annoying 'feature'. I have a craft with a Life Support MiniPak on it, and two of the orange-shirt crew onboard. It's a standard setup, so I forgot they didn't 'need' the supplies. Halfway through the mission, with over 50% supplies left, one of the two will 'raid the snacks' and they 'fall out' and both crew members die. Edit: This appears to happen if on high time acceleration.

Nice idea. I like it.