Leganeski

In general I think it’s 0.01 atm, which on Kerbin is at an altitude of about 23 km.

There is one relatively complicated technique that will actually reduce your velocity relative to Kerbin: the gravity assist. Two gravity assists at Kerbin, followed by one at Eve, can slow down your speed from 4000 m/s to 3100 m/s. However, if you just want to return a few kerbals to Kerbin, @Cpt Kerbalkrunch's suggestion of using a heat shield is much easier and more effective.

Version 0.2.0 is released! Now includes several new options; see the OP or the update changelog for more details.

That's probably it. Kerbin's rotation is defined not by its sidereal rotational period of 5h 59m 9s but its solar rotational period of 6 hours. Increasing the Sun's mass so much speeds up Kerbin's orbit significantly, shortening the orbital period to 1h 4m 7s. Kerbin needs to spin even faster than that so that the Sun still goes around every 6 hours as viewed from the surface, so its new sidereal rotational period should be 54m 25.2s. This is confirmed by the observed value. Setting solarRotationPeriod = False would make the 6 hour value be Kerbin's sidereal rotational period rather than its solar rotational period, resulting in a spin rate very slightly slower than its stock rotation. In that particular situation where the Sun's gravity is 9999999 g, Kerbin's fast rotation is the least of your worries: its SOI doesn't even go all the way to the surface, let alone out to Minmus.

Welcome to the forums, @Crafteurkiki! Edge of Eternity depends on a lot of moving parts, such as Kopernicus, Kopernicus Expansion, and Module Manager. In order to help you, we first need to know what exactly is causing the problem, which requires more information than "Kopernicus failed to load the custom planetary system". A screenshot or list of all the mods in your GameData folder is a good starting point, but much better are log files, particularly KSP.log.

I can't think of a better way to put it! Moar boosters, moar explosions, and moar adventure, all starting today.

The folder WhirligigWorld/Resources/CRP appears to have configs for every atmosphere except Egad, and they look consistent with the numbers you just stated.

Wow, that was fast! I didn't know how intentional these "bugs" were, so I chose the safe side of assuming they were stylistic decisions, but it appears I was wrong. Although PJ2ARC is now mostly obsoleted by the latest changes to GitHub, I'll keep this thread up for anyone who wants Giant Jones, as well as other actual stylistic changes I might have later which wouldn't work as updates to PJ2. (I'm thinking of maybe thin atmospheres for Tobalk and Millie, which would definitely change the gameplay.) That's totally understandable; I'm not super happy with it either. I don't see any good way to change the density of an atmospheric body without messing up something else, so not changing anything in PJ2 is probably the right decision. That makes sense. I ignored both porosity and the extra volume above the datum level, thinking that they would roughly cancel each other out, but I guess I hadn't realized just how much fluff ring moonlets have.

Update: the changes described below have now been implemented, although not yet released, in the PJ2 Github repository (latest update here). PJ2ARC now has several new options, including redone altitude curves for Viszra, Jejunum, Cricoid, and Zeppeli, a thin atmosphere for Tobalk, and a few other minor fixes. Original post: After a considerable number of exploration missions to all the planetary systems, I have discovered that each one is fantastic, and contains many interesting things to discover. In total, the Ilio-Pyri system has far more high-quality content than any other planet mod I have seen out there. As a collaboration between 15 authors, there are some inevitable differences between the styles of different contributors, resulting in features that don't really detract from gameplay but leave me wishing for just a little more internal consistency. Rangon's mass is much lower than would be expected from its radius and composition as described in the Tracking Station. Beddul's pressure-altitude curve at moderate altitudes is substantially shallower than its temperature would indicate. Neither of these things are bad, but they feel somewhat out of place when part of a stellar system that is otherwise very realistic (or at least "kerbalistic"). In order to solve this, I made Planet Jam 2 Alternate Realism Configuration, a collection of Module Manager patches which do my best to straighten out some of the inconsistencies while preserving the original intentions of the affected celestial bodies as much as possible. (For example, I don't see any way the surface conditions on a planet as large as Tobalk could have ever ended up the way they did there, but I'm not going to give Tobalk more air because that would make it far less challenging to land on.) PJ2ARC consists entirely of these changes, and not any of the source material used to make the bodies in the first place. (This is partly for flexibility and partly for legal reasons: the PJ2 download does not have any kind of license in it, so I don't technically have the legal right to distribute a derivative work.) As such, PJ2ARC needs to be added on top of a full PJ2 installation. The following is a list of all the individual patches, with (somewhat spoilery) explanations in the spoiler boxes. Each patch is optional and can be disabled in the settings file if you don't like it. Ollo-Hadfield density fix: increases the masses of Hadfield and the full Ollo system by a factor of 10. (Does not apply to bodies whose masses have already been increased.) Minor moon density fix: increases the masses of Phe, Ber, Phomos, and Rangon, and decreases the mass of Blitzø. Ocean density fix: increases the density of Jejunum's ocean to 3.1 g/cm3. Oynag system atmosphere fix: increases the average atmosphere molar mass of Viszra, Jejunum, Cricoid, and Zeppeli to about 28 g/mol. Questions, comments, and concerns should be directed to the PJ2ARC thread or the GitHub issue tracker.

Planet Jam 2: the Ilio-Pyri System is a fantastic planet mod, full of variety, possibilities, and of course many, many interesting planets. As a collaboration between 15 authors, there are some inevitable differences between the styles of different contributors, resulting in features that don't really detract from gameplay but leave me wishing for just a little more internal consistency. Tobalk somehow lost all of its atmosphere to Turtlestar while the very similar Sinacin retained a substantial amount of nitrogen. Hidalgo's atmosphere is somehow much taller than Viszra's denser, warmer atmosphere held down by less gravity. Neither of these things are bad, but they are somewhat out of place in a system that is otherwise very internally consistent. In order to solve this, I made Planet Jam 2 Alternate Realism Configuration, a collection of Module Manager patches which do my best to straighten out some of the inconsistencies while preserving the original intentions of the affected celestial bodies as much as possible. (For example, I don't see any way Tobalk could have avoided retaining enough nitrogen to form bodies of liquid, but I'm not going to give it lakes because that would make it feel very different.) PJ2ARC consists entirely of these changes, and not any of the PJ2 source material used to make the bodies in the first place. As such, PJ2ARC needs to be added on top of an existing PJ2 installation. Download (License: MIT No Attribution) The following patches are enabled automatically and have already been implemented in unreleased PJ2 versions. Ollo-Hadfield density fix: increases the masses of Hadfield and the full Ollo system by a factor of 10. Minor moon density fix: increases the masses of Phe, Ber, Phomos, and Rangon, and decreases the mass of Blitzø. Beddul-Dopale atmospheres: lowers the atmospheres of Beddul and Dopale to 73 68 and 63 km respectively. Ocean density fix: increases the density of Jejunum's ocean to 3.1 g/cm3. Oynag system atmospheres: increases the average atmosphere molar mass of Viszra, Jejunum, Cricoid, and Zeppeli to about 28 g/mol. The following patches are new in 0.2.0. They are enabled by default, but can be disabled in the settings file. Viszra density increase Increases Viszra's surface gravity to 0.2139 g. This is not necessary on its own but makes the new atmosphere work much better, as it lowers Viszra's calculated atmosphere height from 196 km to 151 km and raises its SOI altitude from 201 km to 288 km. Oynag system atmospheres Expands the atmospheres of Viszra, Jejunum, Cricoid, and Zeppeli outwards to realistic scale heights. Viszra's atmosphere now ends at 151 km, Jejunum's at 86 km, Cricoid's at 147 km, and Zeppeli's at 91 km. Scatterer integration Raises the Scatterer visual scale heights to match the new Oynag system atmospheres. Does nothing if the Oynag patch is disabled. Ilmar oxygen Adds oxygen to Ilmar's atmosphere to match its description in the Tracking Station. Jones temperature Raises Jones's atmospheric temperature to 100 K to match the value in the Tracking Station. Tobalk atmosphere Adds a thin hydrogen-nitrogen-helium atmosphere to Tobalk. (I assume that it was originally hydrogen-dominated but lost almost all of its hydrogen and most of its helium to Turtlestar.) 25 km total height, which is below the highest terrain and so will not affect stable orbits. 3 atm at the datum level. This is actually quite dense, but Tobalk's high gravity means that the atmosphere thins out extremely quickly and is practically negligible above 10 km, where most of the terrain is. At orbital velocities, however, it can be significant in the unlikely event that you don't run into a mountain. Scatterer integration is included with a gray-white color. Like the actual atmosphere, the view doesn't change much except at the bottom of craters.

If you right-click on a propeller blade during flight, it will show the blade's angle of attack along with other statistics such as how much lift that blade is producing. This works without any mods, although I don't remember whether it requires enabling some setting like advanced tweakables. I've observed this as well. It appears to be caused by the propeller blades passing the speed of sound, rather than the atmosphere being too dense, because it remains a problem even at high altitudes. In a cold atmosphere like Tekto where the speed of sound is low (~200 m/s), this can be a significant concern. In hotter atmospheres where where the speed of sound is faster, like Eve (~300 m/s) or especially Imterril (~550 m/s), the 460 rpm limit is a much more relevant issue. The average molar mass and adiabatic index (but not pressure) also affect the speed of sound, so even cold hydrogen-helium atmospheres generally don't have this problem.

I'm not an expert on large propeller planes, but that doesn't look like enough propeller blade area for such a heavy plane. I would bring the CoL even closer to the CoM so that it doesn't pitch down as much, and add more control surface area in the pitch direction if that would help the plane steer better. Propeller blades quickly lose thrust as the airspeed of the blade rises above Mach 1. This means that to reach higher speeds, the blade orientation should be brought closer to forward-backward by changing the deploy angle, rather than increasing the RPM. It looks like you might already be doing this, though, which makes me think that the propellers need to be more powerful.

Saving the ship blueprint from the VAB doesn't require any mods: the craft files can be found in /Ships/VAB or /saves/[save name]/Ships/VAB. However, recreating the blueprint from a ship already in flight is an unusual thing to need to do, and could be tricky to implement, so I don't think there are any mods that do that. I certainly don't know of any. I do think that this feature would be nice to have, though, so asking about it in Add-On Discussions might prompt someone to make a mod for it! ("Blueprint" is not the official name for the craft designs found in the VAB; I just made it up today to clarify what I was talking about.)

Sorry, I misunderstood the question. .craft files are for saving ships as a collection of parts that you could put together in the VAB. These are saved in the Ships folder. ShipSaveSplicer saves ships that have already been launched, as a craft in a particular location on or above a celestial body. These represent actual instances of ships, not ship blueprints, and so would not show up in the VAB. When you load a ship from a ShipSaveSplicer generated file, it should appear in the physical location that it was previously. Launched ships and ship blueprints are stored in somewhat different formats, so I doubt converting one to the other would be as simple as renaming the file to .craft.

Ships are normally saved as .craft files, so that means everything appears to be working correctly so far.

If you need to do something while in "space just above the sun", then that means below an altitude of 1,000,000 km.

You're right that that's probably the safer option. When the current and projected orbits do overlap, though, it appears that clicking on them will bring up that position on the current orbit rather than the projected one. (You can tell even before clicking because the position indicator that follows your mouse along the orbit line is blue instead of orange.) However, I don't know whether this is always the case, and I wouldn't be surprised if the choice of which one gets selected was dependent on some weird condition.

Tannor, Lito, and Totoöa are all icy, so they might not have had the same volcanism processes that rocky planets do. The oceans of Kerbmun and Gannovar, and to a lesser extent Valyr, Imterril, and Lowel, have locked up most of the CO2 from those atmospheres. I'm not really sure why Oshan has so little; maybe it used to have a liquid ocean? Egad, though, is definitely supposed to have a lot of CO2. Egad in particular is missing a configuration file for the Community Resource Pack, which could be why it doesn't. Ollym does have a proper CRP config with a section giving it 93% CO2, so harvesting CO2 there should work in theory. I don't know how bad its thin atmosphere is for Kerbalism harvesters, but it can't be much worse than the similarly thin atmosphere on Mars.

A 2.7m-diameter vessel will fit inside a Mk3 cargo bay with plenty of room to spare.

Are you sure? I just tried this to check, clicking "add maneuver" when I had a 0 m/s maneuver node a bunch of orbits in the future. The new node got placed on my current orbit, and adjusting it moved the location of the existing node, confirming that they work properly even if the future node is added first. (It's not relevant to this question, but the test also showed that changing the nearby node can push the future node across SOI changes, which seems weird to do but I guess makes sense considering how maneuver nodes work.)

Great question! I don't know what this technique is called either; I can only assume that it's not used in real missions because it's so slow. What I do in that situation is create a new 0 m/s maneuver, and click the "next orbit" button a bunch of times until there is a reasonably close pass sometime in the future. It doesn't need to be an encounter, just a near miss, and the proximity matters less and less the farther into the future it is. (The maneuver node is just to specify a location in time; the KSP engine has no reason to calculate a near miss 27 orbits from now unless it's right after a maneuver.) After that, I create a new maneuver node on my current orbit, and adjust it by small amounts in the prograde-retrograde direction. As you've already realized, the small change in orbital period is magnified over many orbits, leading to a large change in how close the intercept is. But because of the second maneuver node in the future, KSP actually calculates how exactly that burn will affect the intercept, so it's pretty easy to get it to hit the target.

I don't see why not. As long as the mothership still has enough fuel to reach Moho, the boost module doesn't need that much delta-v to get from Gilly to the outer system (2750 m/s for a direct transfer, or 320 m/s for a Gilly-Eve-Kerbin-Eve-Kerbin-Kerbin-Jool route).

Moho and Gilly both have significantly eccentric orbits, making a straight Hohmann transfer impossible. The best route I know of involves dropping down to Eve and putting your periapsis at the right longitude so that when you eject from there to Moho, the transfer meets Moho at periapsis. It requires an awkward ejection from Gilly, but saves a lot of fuel at Moho. Gilly to Eve: 180 - 680 m/s depending on Gilly's location Eve to Moho: 640 - 730 m/s Capture / ejection at Moho: 1020 - 1060 m/s Landing / takeoff at Moho: 850 - 870 m/s This adds up to a total cost of 2700 - 3350 m/s in each direction. That isn't enough to require a specialized ion vehicle, especially not if you have ISRU, but Moho's moderate gravity (0.275 g) can be challenging for motherships to land on. The route I took to Moho in my grand tour mission actually went Minmus-Moho-Mun so that I could use the full gravity assist potential of Eve in both directions. (Technically, it was Moho from stock-scale JNSQ, but it has a very similar size and orbit as stock Moho, and that entire section of the mission would have worked almost identically in the stock system.) I packed 8800 m/s of delta-v because I didn't want to worry, but I only ended up using 4360 m/s to get from Minmus to Moho, and that was with a terrible Moho encounter. With a better placed Eve assist, it could have taken less than 3200 m/s, and the theoretical minimum for that route (in the stock system) is about 2320 m/s. In summary, getting the mothership to Moho and back is totally doable, but will likely require some careful orbital maneuvering.

Your propeller blades are arranged asymmetrically: they are deployed in the same direction, but the motors are spinning in opposite directions, so one set of blades is producing backwards thrust. Try setting the variant of the propeller blades on the one of the engines to "counterclockwise". (I don't remember which one it should be; try both separately and see which one makes the plane go forwards.)

Science multipliers can be found in the Kopernicus configuration files in the download. For example, the science multipliers for Heimdall are in GameData/PJ2/KopernicusFiles/2_PyriSystem/IlioC_e/2-Heimdall.cfg, in the section Body/Properties/ScienceValues. (The folder name IlioC_e represents the systematic designation of Bifröst, Heimdall's planet.) If the multipliers are not given there, I believe they are the same as those of the templated stock body (found at Body/Template/name). The biome-specific multipliers are found along with the biomes in the Body/Properties/Biomes section, in the form "value = (multiplier)". Note that these files are relatively safe to explore without the risk of spoilers: although they do include physical and atmospheric properties (which could be spoilers for cloud-covered planets like Sinacin and Beddul), they don't include bodies like [REDACTED] or any science definitions.