Jacke

@linuxgurugamer has adopted this mod for KSP 1.8+.

@Popestar, as others have said, this is tough stuff to understand. There is little in your life's experiences that can be adapted to Astronautics. Everything you will have to learn using a lot of the 1st Principles of Physics as they apply to the Solar System, be it in KSP or in real life. This is tough, but with care and taking your time to skim lightly and come back often to this tricky topic, can be mastered. The key is to take this on in little bites that you can accumulate. Try to imagine you're in Map Mode and picture the orbits involved, zooming in to see the parking orbits, zooming out to see the orbits around Kerbol. Imagine in a general overview the thrust of the burns and how they will affect velocities with respect to the bodies around Kerbol and Kerbol itself. Although I've referenced a source filled with formula, don't bother with those formulae and the actual numbers. Getting the mental images at various scales and the ideas in mind is the key to understanding. The rough size and direction of the numbers involved is good enough. The formulae and detailed numbers are layered onto that understanding later if necessary. Read the text and get the feel for the nature of things in Interplanetary Transfer. Because Interplanetary Transfer is usually done parking orbit to parking orbit, it comes down to 2 timings, Time #1 and Time #2. Each of these Times is also associated with an Angle to help determine it. Below I'll express this as travelling from Kerbin to Duna to shorten wording. It can be adapted to any pair of a current body orbiting Kerbol and a target body orbiting Kerbol. Or any current and target bodies orbiting any central massive object. The big difference is the changes in determining Times #1 and #2 between going out (say from Kerbin to Duna) and going in (say from Kerbin to Eve). On the chart @Snark referenced (copied below), the Planetary phase angle is determined on the left pane and gives Time #1, while the Ejection Angle is determined on the right pane and gives Time #2. Given the two bodies as current and target, these two Angles can be predetermined (and have been by others), which then can be used to determine the two Times. Time #1: When in the orbit of Kerbin the delta-V cost to Duna is near minimum. Anything well away from this time is a direct hyperbolic trajectory and needs a LOT more delta-V. The relative positions of Kerbin and Duna in their orbits around Kerbol determines the Planetary phase angle. This is used to determine Time #1. How much delta-V over the minimum the spacecraft has available determines how big the Launch window is around this Time #1. This produces a transfer orbit from Kerbin to Duna. This is usually a half of an elliptical orbit, called a Hohmann transfer orbit. The speed of Kerbin orbiting Kerbol is how fast the spacecraft is moving with respect to Kerbol. To get into the transfer orbit, with respect to Kerbol, the spacecraft needs to either speed up to go out (say from Kerbin to Duna) or slow down to go in (says from Kerbin to Eve), in both cases matching the speed in the transfer orbit at the start near the current body orbiting Kerbol. Besides that speed change in #1.4, the spacecraft needs to escape from Kerbin. This then leads to.... Time #2: Near Time #1 within the Launch Window, when in the parking orbit around Kerbin to start the Ejection burn to get into the right hyperbolic escape orbit leaving Kerbin with the needed Hyperbolic excess velocity (the remaining relative velocity of the spacecraft after it has effectively escaped Kerbin) either Prograde for out (say from Kerbin to Duna) or Retrograde for in (say from Kerbin to Eve) that matches the speed change in #1.4. The whole burn delta-V will be larger because the spacecraft needs to escape from Kerbin as well. While the spacecraft is under thrust, this is called the Power track and is an accelerated trajectory. How much angle around the current body this power track does, along with the angle the hyperbolic escape orbit does before leaving the SOI of Kerbin, gives the Ejection angle. This is used to determine Time #2. The hyperbolic excess velocity is either Prograde with respect to Kerbin's velocity around Kerbol and thus added to the spacecraft's velocity with respect to Kerbol to go out (say from Kerbin to Duna); or Retrograde with respect to Kerbin's velocity around Kerbol to go in (say from Kerbin to Eve). Given a standard Prograde parking orbit, when going out (say from Kerbin to Duna), the burn will be around the dark side of Kerbin. Similarly, when going in (say from Kerbin to Eve), the burn will be around the lighted side of Kerbin. Again, on the chart @Snark referenced, the Planetary phase angle is determined on the left pane and gives Time #1, while the Ejection Angle is determined on the right pane and gives Time #2. Further information can be gleaned from the master document I learned from many decades ago. This one slim volume, already decades old when I read it, has compressed information in spades about all parts of Astronautics, from getting into orbit to going from the Earth to Mars. I had to seriously up my game to understand many parts of it, including learning a new Calculus tool, Lagrangian mechanics, to plot the path of the Power Track. That level of study isn't needed here. I'd suggest just skimming over the calculations just to get a better feel for all the other details. The Mars Project (1953) by Wernher von Braun Archive.org has it online now. https://archive.org/details/TheMarsProject-WernherVonBraun1953/mode/2up Here's where it begins on Interplanetary Transfer and covers Time #1 and the Planetary phase angle. https://archive.org/details/TheMarsProject-WernherVonBraun1953/page/n61/mode/2up Here's where it starts talking about the Time #2, the start of the ejection burn and the Ejection angle. https://archive.org/details/TheMarsProject-WernherVonBraun1953/page/n67/mode/2up This took me a lot of effort to understand. But I got there. Now I get to apply that knowledge to KSP. Once you start to get an idea about Interplanetary Transfer, @HebaruSan's Planning Node is a new fantastic tool to plot Interplanetary Trajectories. Its two parts are exactly equivalent to determining my Times #1 and #2 above. Because it's working in the game, the determination also automatically handles the level of details like the current and target bodies being in elliptical orbits which are tilted with respect to one another. While it's possible to manually plot, or use the tools in good mods like MechJeb, this sort of exacting tool will be a KSP gamechanger.

I've done a quick check and there appears to be no stock game changes since KSP 1.6.1 that would affect the biomes and science values. So 20190306a is good for play today in a wide range of KSP versions.

Yes it will. The rate of input from cosmic rays and creation from particle collisions needs to be higher than the rate of destruction by collision with protons. As the density of anti-protons increases, the rate of collisions will rise and eventually there'll be a steady state. The present of the magnetic fields and the charge particles spiralling along them will tend to increase the effective mean free path for all particles. This is all still a good quality vacuum and no real threat to any craft that can take the radiation, but could be detected.

The end of "WandaVision" episode 3 brought up this song from my deep dark past.

I can support this theoretically. If a vessel or debris on rails changes SOI, it will then adopt its new pathway in that SOI. If it's an encounter with a body where it enters the SOI, has a flyby, then leaves the SOI, this will be a angle change of excess velocity exactly like a real-world gravity assist flyby.

Wow, @HebaruSan. Just, wow. I've never gone interplanetary in KSP. More from my careers being restarted along with so much to do within the Kerbin SOI. I certainly understood it well, from my study years ago of von Braun's _The Mars Project_. But this is a major advancement. All the explicit things in interplanetary transfer made implicit in a series of simple steps. Bravo! I've just started getting back into KSP and have yet to settle on a version to run. Likely will be one of 1.9.1, 1.10.1, 1.11.0, or 1.11.1. To the best of your immediate knowledge, do you think there will there be an issue running Planning Node on either 1.9.1 or 1.10.1 if I use them? Thanks!

@Hyomoto! You're back! Good to see you dude. I've been away from KSP since August and not done a lot since the start of 2020. Just started getting back in yesterday, so I'm just learning about all the changes still. Sorry I can't assist with the hatch obstruction issue. Can't remember for sure or find by searching a general issue. I wonder if @linuxgurugamer knows about any issue related to hatches that I can't remember. Otherwise I'd suggest trying to rebuilt it in the version you're using from scratch, at least to test the hatch with less plane around it.

It reminds me of the Blue Streak. https://en.wikipedia.org/wiki/Blue_Streak_(missile)

"LGG personal log: 2020 Oct 4 Sunday: As so many people were complaining, spent the day updating topic titles. Didn't feel so good at the end of the day. Only figured out an hour ago I definitely updated some titles twice or more. Things are bad. Considering a career (another one?) in politics. Also worried the corners of the room are becoming non-Euclidean."

If it purports to be a sweeping basal physics theory, if it doesn't have a quantum mechanics-general theory of relativity unifying component that describes how space comes about with a simplistic 3-dimensional nature (ie. Loop Quantum Gravity or others), then it's likely excrementse. Lack of co-authors and references as @mikegarrison points out is another warning sign.

Floor 5387: After consulting logs, you realise 9 days ago the floor signs got screwed up, not to mention most losing 2000 floors. You count out the number of floors and discover this one's is right. You think.

That's one way to do it. If you can't hold the craft at that AoA, then it needs more pitch authority from RCS or control surfaces that can take the heat. Alternately, there's other re-entry profiles that may work. In this case, to prevent overheating, the key is maintaining altitude until the craft is slower. Use lift to keep the craft at altitude. To refine this, you need to test multiple re-entry profiles. Different initial periapsis altitudes, different attitudes, etc.

Good points. You can turn down science rewards to 10% and face a real challenge advancing through the default tech tree. In fact, that might go too far, requiring interplanetary missions to unlock some technologies that should be able to be developed independent of how far and how well things have been explored interplanetarily. KSP and KSP 2 both need a system where techs get unlocked by researching, developing, and testing and using new concepts and parts. The rewards from exploring out in space should feed back into the career, I'm just not quite sure how best to do that.

If the pilot isn't wondering whether to fly or eat the craft, it ain't Minmus-themed enough.

Those are solar periods. Sidereal periods would be more appropriate.

If changing the tech tree, I'd change it so that uncrewed missions from Start were possible. Move the Stayputnik to Start and retech the other probe pods to match. Move the command pods out. Move the External Command Seat to Start to allow some initial "special" crewed missions.

Hmmm, it's more complex a problem. In the statement of the problem, the periapsis is fixed and the apoapsis is variable. Which means the eccentricity is variable.

It's a solved problem for elliptical orbits using the function between mean anomaly (time based from periapsis) and eccentric anomaly (angle based from periapsis). https://en.wikipedia.org/wiki/Mean_anomaly At the end of the article just before the references, there's a infinite equation to calculate the eccentric anomaly from the mean anomaly that can be used to figure out the position. From that, should be able to calculate the required orbital parameters.

@Raptor22, I think you should be more cautious and consider the advice here. @linuxgurugamer is a long established programmer and KSP mod author. He supports over 200 KSP mods because he is that good and organized in his method for handling mods and taking them through KSP version updates. He is one of a few people who make and maintain the mods that many people, including me, think are essential for taking KSP from a good to a fantastic game. And like them he does this all voluntarily in his free time for no concrete benefit. I may not have been coding as much as LGG, but I have coded as long as he had. I've also expanded to supporting hardware, systems, and networks and I've had to troubleshoot many an issue, including finding the root cause of software installation issues. I've also manually modded KSP for years. Recently, as LGG suggests, I've mostly switched to using CKAN as it helps me spend less time tinkering and more time playing. First, as LGG indicates and as there are no other complains when the Spacedock stats show this mod is in common use, your issue is likely an install issue. To fix this, you should clean out this mod and its dependencies from your GameData tree and download and reinstall all of them carefully. Second, the way you say you download a copy of the mod source is not the first option you should be using. That tree will only be complete for a given patch on its particular branch. This could easily be a testing version that may have issues that the mod author is still working out. Also, this mod on GitHub has 16 branches. Which one is current isn't obvious and could easily change. Only those working on the software should be looking at that. Normally, I'd use CKAN, but I checked manual install. I went to Spacedock for this mod from the link in the original post, clicked on Download, and got a zip with the GameData tree for this mod in it. That what I used for years (with the software JSGME to add and remove mods) and it looks good. Do this for the dependent mods (ModuleManager, ClickThroughBlocker, ToolbarController) as well as ZeroMiniAVC (which is also needed now due to changes in KSP). Clean out your GameData tree of the files and subdirectories those mods include. Then reinstall them. Then try testing it. If that doesn't work, get a snapshot of your GameData tree as well as the logs from that run and post a link here.

My sympathy on this tragedy. What I think should be done is making sure all trees are living and well-rooted. And adults need to be aware of risks and their degree. Falling trees are more of a hazard than many might think. Jared Diamond mentioned this in an article. https://www.nytimes.com/2013/01/29/science/jared-diamonds-guide-to-reducing-lifes-risks.html The risk on a single encounter is low. But the shear number of encounters means the risk is significant. I have a friend who applied this lesson and was saved from a falling tree.

@RobertaME, very good dynamically analysis. I currently run KSP on Windows 10, which I've managed to tame to the point it's not that much of a issue. I also want to see KSP 2 on other OS. I don't have any problem with the female Kerbals.

Not true at all. It's known that it will never be realistically available. Metallic hydrogen is similar to monatomic hydrogen: both are wildly unstable under any usable temperature and pressure. Metallic hydrogen only exists under massive pressures. Monatomic hydrogen only exists in near vacuum. Putting either in KSP 2 as an effective fuel is damn stupid.

No problem. Well, as a Steam user, when I see games go up exclusively on the Epic store--which I'm unlikely to use--I feel a loss, even if the exclusive is temporary. Then I look at it again and remember that the closest I've come to wanting an Epic exclusive game is Rebel Galaxy Outlaw. And I've not spent the time to come close to finishing the original Rebel Galaxy. "Bribe", like a lot of strong words, gets misused, as you've mentioned often from a lot of emotion. But at least in North America and Europe, there's few outright bribes. But there's a lot of over-sharp actions, with a lot of these put into contracts. And contracts often have terms that limit what we as consumers get as benefits. And in the end, if the exchange of funds happens, there's always a bit of getting the power to call the tune. Well, as a network administrator, I kind of feel security in a lot of the platforms doesn't get properly or sufficiently addressed. (Especially as the user needs to be aware and cautious.) To a degree, Apple's closed garden is a bit more secure. But it's not impossible to get equivalent security in other means. And using it as a club to ensure a captive paying audience is a bit of an abuse. And all of the meta-services that enable what we do--for a cut--are to a degree anti-competetive. I feel it has to go beyond just anti-trust to actions that limit interest rates. As the interest rate limits are avoided in various ways, it will be a far-from-perfect solution. I don't think a decision in these suites will significant change the landscape. But I could be wrong. But I think they'll need legislation to make a proper level playing field. And I think it may come from Europe, where they do realise that appropriate regulation can often be a better solution. Whatever happens, it's going to take a while.

There's also the contracts (including the automatic World's Firsts) that when a player achieves the goals in space, they receive the rewards. Especially using Contract Configurator, these rewards can be virtually anything. Exactly! Using rockets as well as R&D to develop new versions is how rockets improve. There's also just finding out what things are like out there. Every probe to every planet, every orbital observatory, every crewed mission has improved our knowledge of space and the bodies out there.