Leganeski

Often, you might want to take advantage of an extraterrestrial atmosphere by flying a plane or using parachutes to slow down a craft. This can be more or less effective depending on the conditions there: a parachute that lowers a capsule down to Earth safely will crash at high speed into Mars, while a propeller plane that fails during testing on Kerbin might actually work just fine in Eve's thicker atmosphere. In this sense, Eve is better for atmospheric flight, while Mars is worse. But by how much? I've seen this concept quantified before in specific instances, but not in the general case, and as far as I know, it has not been given a name. I propose a new metric to measure it: the flight effectiveness index. (If this name is already taken, or if the concept actually does already have a name I don't know about, I'd love to hear about it so that I can correct this post.) Unfortunately, air is complicated, and many simplifying assumptions are often made. One unfortunately common one is the lack of distinction between atmospheric density (how much mass the air in a given volume has) and atmospheric pressure (roughly proportional to how much energy the air in a given volume has). While clearly related, these concepts can end up being very different because of the fact that air molecules move at different speeds. KSP does maintain the distinction between pressure and density internally, but fails to convey it in situations where it is relevant, such as when parachutes open. They open at a minimum pressure, when perhaps a minimum density would be more consistent with the actual performance of the parachute. It's not just a problem in KSP: pressure and density are both measures for "how much air there is", so the distinction between them is not intuitive and can easily lead to confusion. Even xkcd, a webcomic now known for its very good scientific accuracy, at one point got pressure and density mixed up. (source: https://xkcd.com/620/) The 9% figure would be correct except for the fact that Titan's atmosphere is not 50% denser than Earth's; it has 50% more pressure (and consequently over four times the density because the air is so cold). The relationship between density and pressure can be derived from the ideal gas law. (The ideal gas law isn't perfect, but it's close enough under normal conditions.) PV = nRT, where P is the pressure, V is the volume, n is the number of moles of air, R is a constant, and T is the temperature. Wait, this equation doesn't have density in it! We need to relate the density to other things that are in the equation. The density ρ, by definition, is the mass m divided by the volume V. The total mass m is the molar mass μ times the number of moles n. Putting this all together, we find: PV = nRT P = (n / V) RT P = (m / (μV)) RT P = (ρ / μ) RT Pμ / RT = ρ R is a constant, so the density is proportional to the pressure times the molar mass divided by the temperature. The rest of the comic is basically accurate: the amount of mass held up by a given wing or parachute (at a given velocity) is proportional to the density divided by the surface gravity. (Explanation in the spoiler box for why this works.) This gives us our final definition for the flight effectiveness index: FEI = (Pμ) / (Tg), where P is the pressure (in kPa), μ is the mean molar mass (in amu = g/mol), T is the temperature (in K), and g is the local surface gravity (in m/s2). Importantly, this is dependent only on the local conditions, not on any characteristics of the vessel. (For maximum accuracy, the local surface gravity should include the effect of the body's rotation; that is, it should be reduced for rapidly spinning bodies. However, this does not make much of a difference unless the body is rotating quite quickly.) In KSP, the pressure, temperature, and local gravity can easily be obtained in the above units from the barometer, thermometer, and gravioli detector respectively. The molar mass is not obtainable in-game, but it is globally constant across each body. For stock atmospheres, it can be found on the body's KSP wiki page. For most modded atmospheres, it can be found in the body's .cfg file as atmosphereMolarMass (in kg/mol, which must be multiplied by 1000 to obtain it in g/mol). While this definition is based on SI units, it would be nice if there was an easy-to-remember "Earth/Kerbin standard" value. (Earth and Kerbin have basically identical conditions.) Fortunately, there is! Plugging in standard thermodynamic conditions, we find: P = 101.325 kPa (1 atm) T = 298.15 K (SATP standard) μ = 28.9644 amu (US standard for Earth; Kerbin global constant) g = 9.80665 m/s2 (1 g) FEI = (101.325 * 28.9644) / (298.15 * 9.80665) ≈ 1.00375, which is basically 1 (to within the actual variation on Earth of any of pressure, temperature, or even gravity). Of course, actual conditions on Earth and Kerbin vary considerably. In the thinner atmosphere at high altitude (0.8 atm, for example), the FEI falls to 0.8, meaning that a plane can only hold 0.8 times as much mass. In the cold polar weather (temperature: roughly 240 K), the FEI rises to 1.25. The flight effectiveness index can now be calculated on other celestial bodies. Let's take Eve as an example of a popular destination for planes. On the equator at sea level at noon, the conditions are: P = 506.625 kPa T = 423.7 K μ = 43 amu g = 16.67 m/s2 FEI = (506.625 * 43) / (423.7 / 16.67) ≈ 3.08. This means that a parachute can hold up 3.08 times as much mass as would be safe on Kerbin, and a propeller plane can carry 3.08 times the mass (including the mass of the plane, so you get a lot more than 3.08 times as much payload). While this definition is designed to be as easy as possible to calculate accurately, it still requires some work. Alternatively, I've included tables of typical FEI values on atmospheric planets and moons from a variety of systems. The FEI varies across the surface of any body, mainly due to variations in altitude (i.e. mountains, which you probably already knew to look out for) and temperature (which doesn't change all that much unless the body is a tidally locked planet). The given values are at the datum level at a latitude of 17 degrees, with a temperature averaged across all daily and seasonal variation. Stock system: Real Solar System: Outer Planets Mod: Galileo's Planet Pack: Grannus Expansion Pack: JNSQ: Whirligig World: Strange New Worlds: Edge of Eternity:

Sure; I was speculating based on just the actual Kerbin system. At the very least, though, the lack of seasonal variation means that there's a lot less incentive to correct the length of the year from 426 to 426.09 days, which is perhaps an in-universe explanation for why the calendar doesn't use leap years. (The real Mayan Haabʼ calendar, which was used fairly close to the equator where there is less seasonal variation than average, was exactly 365 days long.)

I made a delta-v table for the full system. It's in the form of a table as opposed to a map for two reasons: primarily so that I can include transfers between bodies other than Armstrong, but also because I am no good at graphic design. If anyone wants to make a map from the numbers, go right ahead! Currently, only the Pyri system is included because I haven't left Pyri yet and don't want to spoil Ilio's planets. I'll probably expand the table to the rest of the Ilio system eventually, but not until after I reach all the planets, and that might take a while. Update: the table is now complete!

That's really weird. The fact that it happens in the stock system means that it's not a planet pack causing the issue. (In particular, it's not PJ2, so this might not be the best thread for it.) Kopernicus alone doesn't do that either, so either Kopernicus was installed incorrectly or it's some other mod causing the problem. The only relevant mod I can think of is Realistic Atmospheres (which is incompatible with any system replacer like PJ2).

While we might like calendars to be based on nice astronomical concepts such as the orbital periods of the Earth or the Moon, this is not how it works in practice. Calendars are based on observable effects: for example, Earth's year is defined not by its orbital period but by the period of the seasonal cycle (which is about 20 minutes shorter), and the month was originally defined not by the Moon's orbital period but by its phases (which are about two days longer). On Kerbin, there is no seasonal variation at all, so Kerbin's location in its orbit doesn't produce any easily noticeable effects unless you're actually paying attention to the constellations. This means its orbital period wouldn't have the same importance that Earth's year does. Instead, it seems more likely that the calendar would be based more directly on Mun. (Remember that Mun has about four times the angular diameter of the Moon, so it's way more noticeable in the sky.) There is a Munar eclipse every 6.534 days, but half of them occur at night, so from a given location, visible eclipses usually occur about every 13 days. The time of day of the eclipse advances by 25 minutes each time until it reaches sunset. Then, the alternating daytime and nighttime eclipses would swap, and the time of day of the visible eclipse would return to sunrise. This happens every 95.4 days, after seven or eight visible eclipses. Every five of these "eclipse cycles" (477.00044 days), the eclipse would occur at almost exactly the same time of day, off by less than ten seconds. Anyone with a watch who could see the sky getting dark due to a Munar eclipse would probably notice this, so a calendar based on this unit of time seems likely. (The phases of Mun cycle at the same rate as eclipses, so any such calendar would also include them as a bonus.) My proposal would be as follows: A "year" is 477 days. The error between this and 73 Munar eclipses is so small that it would add up to less than an hour over the course of a human lifetime, so it's unlikely that further precision would be needed. The year is broken into five "cycles", each of 95 or 96 days. Separately, a "week" lasts 13 days, but the last week of every other cycle is followed by an extra day not part of the week. I'm not sure "week" is exactly the right word since 13 is not that close to 7, but I can't think of a better alternative other than obscure terms like "fortnight". How would this work? As an example, let's look at this calendar from the perspective of an observer on the surface of the ocean at 0° N 0° E, where Kerbol rises at 03:00 and sets at 00:00. The first eclipse is on Day 5 at 04:23, which is during the day. The next visible eclipse is one "week" later, on Day 18 at 04:48. Eclipses continue on the fifth day of every week until Day 57, where the eclipse continues past the end of the day. The next eclipse is on Day 64 at 03:14, which is now just after sunrise on the twelfth day of the week. More eclipses continue on the twelfth day of each week until Day 142 at 05:42. On the 57th day of every cycle, the day of the week with the visible eclipse swaps. (At other longitudes, it's other days of the cycle, not the 57th.) During the first cycle (Day 57), it was from the fifth to the twelfth day of the week, whereas during the second cycle (Day 153), it moves from the twelfth to the sixth day of the week. The next visible eclipse is on Day 161 at 03:19. Wait, the sixth day of the week, not the fifth? It remains off for now, but then at the end of the second cycle, after the week ends on Day 195, an extra day is added between weeks, and the next week doesn't start until Day 197. The eclipse after that, on Day 201, is consequently pushed back to the fifth day of the week. In this way, every visible eclipse occurs on the fifth, sixth, or twelfth day of the week. (Well, they do if you start the week on Day 1 like I did. The days of the week could easily be renumbered to move them around.) After a "year", on Day 482, an eclipse occurs at 04:23, the same time of day as the very first one. Since we're not used to thinking in terms of eclipses and time of day like this, the whole system feels unintuitive, but it lines up nicely with easily observable astronomical events, and I would say it's not any more complicated than the Gregorian calendar.

This could be caused by any number of things, but the most common reasons are incompatible mods and mods that have been installed incorrectly. Without knowing anything about your KSP installation, it's impossible to say more. In order to try to diagnose the problem, we would need more information, such as log files and a list of the mods you have installed.

Is Ollo supposed to be less massive than Armstrong? It surface gravity of less than 0.2 g seems really low for a giant planet.

Ballutes are good at slowing you down from 5000 m/s to 1500 m/s or so, but you need conventional parachutes to make it the rest of the way. I have personally found some success with the large parachutes from Lithobrake Exploration Technologies: a Mk1 pod with a LET-SP-1X24 parachute hits the water at around 18 m/s, which is slow enough to survive. (Well, I survived the one time I have tried it so far, and that might just have been due to a lucky Scatterer wave.) Ground landings are even trickier. You could try using disposable landing legs that absorb some of the energy of the impact, but I found it more convenient to jump out, grab all the science, and then use the personal parachute to safely glide the rest of the way down. It's not easy to get below 50 m/s with a personal parachute in the thin atmosphere, but it's definitely possible with careful steering as long as you're not at a particularly high elevation.

Welcome to the KSP forums, @Pla1ddragon! The scanner is in fact looking for an orbit above 25 km and below 19 km, which indeed does not exist. This is a known bug with the stock ore scanner: it can't scan any body with a radius of 5 km or smaller. A few small asteroids have ore everywhere to make up for this, including Raft and Gershmurzelen.

Because the orbital velocities involved are so fast, you want to make sure that you intercept the asteroid at apoapsis, especially because that means you get to use Armstrong's Oberth effect for more of the transfer. This can often be really difficult to do with a direct transfer, so treating it like a docking maneuver definitely helps in that regard. For example, by intercepting Rider at apoapsis, you should be able to make it there from low Armstrong orbit with just 3300 m/s. Rider is a bit far out, but its orbital eccentricity is really useful because it allows you to sort of "store" the increased apoapsis you get from a large burn at Armstrong and use it towards the post-refuel ejection to Haut-Oklo or Zhandar. If you go to a circular-orbit asteroid like Morhomlo, you'll be spending more fuel raising your Pyri periapsis, which doesn't really help much.

Endless loading screens aren't usually caused by insufficient hardware, and in your case, 36 GB of RAM is way more than enough to run this mod. It's more often some mod somehow being installed incorrectly. The rest of us don't know anything about what your KSP installation looks like, so we would need more information to help you. Even a complete list of all the mods in your GameData folder would be a good start.

Yeah, I definitely found this to be a problem as well. I ended up using an empty Mk1 command pod for its reaction wheel, but that's very inefficient and doesn't seem like the intended solution. I don't think Parallax is supported yet.

I found ???? on the [redacted] side of [redacted]! It turns out that [redacted] was actually describing [redacted] the whole time. (Spoiler: in-game screenshot of part of ????) This pack appears to have some interesting secrets. The one I found was I believe made by @Exo's Lab. Nice job!

That doesn't sound like a bug; if anything, it's MechJeb's fault if it doesn't allow you to scroll through the list of bodies the way the selector for the stock Δv readout does (or compact the list by planetary system like the way KER's readout does).

No, it's unrelated.

This is a good idea in the long term, but the problem is that it still takes like 5000 m/s to get to Zhandar from Armstrong orbit. I guess I'll have to start setting up some infrastructure in the asteroid belt. It's not a full Δv map, but I do have some initial values for how expensive it is to eject to other planetary systems directly from a 40 km Armstrong orbit. (minor spoilers)

Congratulations on the release! I can't wait to start exploring the system!

Wait, this is great! I was running into issues getting PlanetInfoPlus to work with Whirligig World: every time I focused view on Imterril, the game would crash. I thought it was due to Imterril not having a heightmap file, but since Imterril's entire solid surface is at -10000 meters, it was probably the same issue as with Kcalbeloh. This means the problem should be fixed now!

The Panther in wet mode has an Isp of 4000 s. The exact fuel consumption depends on how long you use the plane for, but I'll take a wild guess and say you might need an average TWR of 0.4 for an hour. In that case, your plane would to be about 30% fuel by mass. That's a lot, but in practice, you wouldn't be using wet mode the whole time, which would raise the efficiency a lot, and a fighter jet might not need to be constantly executing maneuvers for an hour straight. If I made a fighter jet, I'd probably stick with dry mode the whole time (Isp: 9000 s), and run it for like twenty minutes before landing back down. Then the plane would only need to be 5% fuel. (Note that the number of engines doesn't matter other than letting you fly the plane at a higher TWR if you want.)

This sounds like an infinitesimal. As you mention, infinitesimals can be useful as a way to think about calculus, and both Newton and Leibniz used them in their original formulations of calculus. (Around the 1860s or so, mathematicians figured out how to do calculus without infinitesimals by using limits instead.) The thing is that infinitesimals are not standard real numbers, and therefore do not have decimal representations at all. (If 0.999... were less than 1, then its square root would be even closer to but still not quite 1, and how would you represent that?)

The planet pack Edge of Eternity also has a completely black skybox (using TextureReplacer similarly to @pmborg's solution). The subfolder /GameData/EdgeOfEternity/Other Features/Skybox has the relevant part.

This is the only problem that I could see. Because the center of lift is so far back, it's constantly trying to tilt the plane downwards. On the ground, this means that the front wheel is supporting most of the weight of the plane, and one wheel isn't enough to maintain stability. In the air, your control surfaces are fighting as hard as they can to counteract the downwards tilt, and are just barely succeeding. When you use them to do something else like turning, they can no longer provide enough pitch torque, and the plane pitches downwards and crashes. Still, the fact that you managed to actually achieve level flight after only 10 hours is very impressive! It took me a lot longer than that.

Yes; that is what I was describing. A Kerbin year is 3.43 times shorter than an Earth year, so using light-Kerbin-years would place the systems at 1/3.43 times the real-scale distance, rather than the full 1/10 or 1/11 found within the Kerbol system.

Why not? There's a perfectly rigorous way to do so, which is what is used in infinite decimal expansions. Why? Infinite decimal expansions represent the limit of converging sequences of finite decimal expansions, but different sequences can converge to the same value. The number 1 already has many different representations, such as 1/1, 3 - 2, and 50. There's no reason why there can't be another one. In particular: are there any nonzero infinitesimals? In the hyperreal numbers, there certainly are, but when we're talking about numbers without further context, we mean a real number, not a hyperreal. In particular, decimal expansions such as 0.999... always represent real numbers. One very important step in constructing the real numbers is taking all the things that would have been infinitesimals and setting them equal to zero. In the hyperrational construction, the infinitesimal hyperreals are explicitly unified with zero. In the Cauchy construction, all the sequences approaching zero are set equal to zero.