Starhawk

Oh fine then. @Angelo Kerman

Went to Jool and landed on Vall. Beautiful! Happy landings!

This. Absolutely so much this. Happy landings!

Overlapping bug reports merged.

Overlapping threads, one from KSP2 Discussion, have been merged.

Moved from Bug Reports.

This thread has served its purpose and has now been locked.

Moved from KSP2 Discussion.

Overlapping bug reports merged yet again.

It's complicated. Moho is a special case. It is very deep in Kerbol's gravity well and all maneuvers deeper in a gravity well are more costly in terms of dV. It is in a very eccentric orbit around Kerbol. This means that there as a significant difference in your relative velocity if you encounter it at its periapsis versus at its apoapsis. It is in a very inclined orbit wrt Kerbin. This, combined with being deep in the gravity well, means a plane change maneuver to encounter it is very costly in dV. The upshot of all this is that transfer windows between Kerbin and Moho are definitely NOT equal. A simple Hohmann transfer is not really the most efficient transfer to Moho most of the time. It also means that simple tools such as the image shown or the tool linked in your post are not very effective in finding a good transfer. To get a better idea of the variety of transfer windows take a look at this. This is the output of the Alex Moon Launch Window Planner with the origin as Kerbin and the destination as Moho and the dates as Year 1 Day 1 (Year 0 Day 1 in KSP2). The porkchop plot is zoomed out several times to show a longer time range which allows us to see several successive transfer windows. Note that they are not very regular and that they vary significantly in the amount of dV they require. They also vary rather a lot in the duration of the trip (vertical axis). It has been said before that KSP1 has three big bosses. Eve, Tylo, and Moho. Eve is the hardest to return from the surface of. Tylo is the hardest to land on. And Moho is the hardest to get to. The orbital insertion dV required when you actually get to Moho is insane. Happy landings!

Overlapping bug reports merged.

Hello @DerTueb and welcome to the forum! The moderation team has added the translation for the post above. Please use English when posting outside the Interational Section of the forum. Thank you for your understanding, Forum Moderation Team

Moved from Bug Reports.

Another bug report has been merged into this one.

Hello @TechDragon. Your post has been edited to remove the text files pasted in. Please do not post long text files such as this in the forum. They interfere with browsing (especially for users who are on mobile devices) even if they are placed inside spoilers. Please upload such files to an online storage service and link to them here. Thank you for your understanding, Forum Moderation Team

And that is exactly the bug. The fact that it's so confusing is what makes it a particularly nasty bug in my view. Happy landings!

I looked at the video. It clearly shows that your trajectory is leaving Duna in the exact opposite direction from that needed to head back to Kerbin. Here's a screen grab I took from your vid. In this image Duna is moving in its orbit from left to right. If you want to go back to Kerbin your trajectory must be going to the left. Not to the right as shown. Your node is exactly on the wrong side of your Duna orbit. Happy landings!

Yes. The bug is that the wrong trajectory is shown for your path outside the SOI until you leave the SOI. After exiting the SOI the correct trajectory is shown. Perhaps I can still convince you. The direction of one's orbit around Duna does not make any difference (other than where you place the node). If you are looking down on Duna's north pole and Duna's direction of travel around Kerbol is 'up' on your screen, then your predicted trajectory away from Duna orbit should be 'down' on your screen. This is when viewing the map within Duna's SOI. I must say that I think it does. This is a particularly nasty bug since it will completely mislead the player about the result of doing an engine burn. Fixing this is critical to allowing new players to understand orbital mechanics. Anyway, the upshot of all of this is that if you make your burn in the correct direction it will give you the expected result. It just doesn't look like that in map view until you exit the planet SOI. Happy landings!

My experience with this bug indicates clearly that the bug is that the wrong trajectory is shown until you exit the SOI of the distant planet. I first experienced it on my first return from Duna. My standard procedure for this is to use an online tool to find the transfer window. Warp to that date and set up a node. I set up the node to leave Duna in the direction I know the ship needs to go to get a Hohmann back to Kerbin. I adjust the position of the node on my Duna orbit (rather fiddly) so that my trajectory is leaving the SOI in exactly the opposite direction that Duna is travelling in its orbit. This involves a bit of zooming out and zooming back in. As I said, fiddly. But it works. So imagine my surprise when I zoom out much farther to see just how close I'm going to come to Kerbin and I see the trajectory taking me out much farther from Kerbol. That is exactly the opposite of what I expected. I could see this was a bug. It seemed far more likely to me that the trajectory shown after leaving Duna's SOI was displayed wrong rather than actually being calculated wrong. This turned out to be the case. If you know which direction to burn and ignore what the map tells you will happen after leaving the SOI of the planet you're leaving it will all be good. If you believe what map mode shows, it could be that you will not return from space today. The map display appears to add my velocity on leaving Duna's SOI to the orbital velocity of Duna rather than subtracting it. Perhaps a minus sign slipped? Happy landings!

Multiple overlapping bug reports merged.

Have you tried turning off Auto Friction Control in the parts manager and moving the Friction Level slider way over? Happy landings!

KSP Version: 0.1.1.0 21573 OS: Windows 10 21H2 CPU: AMD Ryzen 5 3600 GPU: Nvidia GeForce GTX1660 Ti Expected Behaviour: Orbit around airless celestial body should remain unchanged when no force is applied. Observed Behaviour: When craft is below a specific altitude and time warp is set to 1x, the periapsis will steadily decrease while the apoapsis steadily increases. Changing time warp to any value other than 1x arrests the behaviour. Behaviour reappears when time warp is returned to 1x. At the Mun the altitude threshold is about 23 km. At Minmus the altitude threshold is about 27 km. Steps to Replicate: Put a craft in Mun orbit with the periapsis below 23 km. When (sea level) altitude drops below 23 km the orbit begins to change. This behaviour stops when the altitude of the craft rises above 23 km. Fixes/Workarounds: Keep Mun orbit above 23 km (Minmus above 27 km) or use time warp values other than 1x. Mods: None. Tested at the Mun and Minmus. This bug was present in 0.1.0.0 as well.

Multiple overlapping bug reports merged.

Patch one rendezvous complete.

The announcement post for the patch will have a link to the patch notes. Happy landings!