OhioBob

Yes, I experimented with the lockRotation parameter. It didn't solve the problem. Although it locked the ascending node of the rings in place once the game was started, it didn't stop the line of nodes from shifting from one run to the next. As I recall, with lockRotation = false the ring axis would precess with the planet's rotation; and with lockRotation = true the ascending node remained fixed and was not tied to the planet's rotation. However, I could find no way to permanently lock the ascending node to a particular celestial longitude. As I explained, on one run the rings would have an ascending node of X. I'd then exit the game, edit the moonlet's ascending node to match the rings, restart the game, and now the rings would have an ascending node of Y. The lockRotation parameter appeared to have no affect on this random shifting of the ascending node. It appeared that it just wouldn't allow me to make the ascending nodes of the rings and moonlet the same. I could get the moonlet within a few degrees of the ring plane, but anytime I tried to make them exactly coplanar, the line of nodes of the rings would change on the next run. Adding to the frustration, I could make the rings and moonlet coplanar if I edited the moonlet's ascending node using KittopiaTech; however, the problem would rear its ugly head when I edited the moonlet's config to make that change permanent. Hey, I just got an idea. The moonlet orbits in a gap in the rings, however that gap isn't real - it's just a blank spot in the middle of one solid image. What if we actually split it into two separate rings with a real gap between them? Maybe then we could place the moonlet in this gap without it affecting the rings. I'll have to experiment with this to see if I can make it work.

@Sigma88, have you had a chance to look into my ring inclination problem? I'm sure you're busy and I don't want to pressure you, but I haven't seen anything since your initial reply. As a reminder, below is the post where I described the problem.

You'll probably just have to play around with it to get the colors and brightest that you want. Below are Ciro's current settings. The numbers you'll want to play around with are those in the Light{} node. Those settings affect how the sun looks from a distance and the color of light that it casts. The settings under the Material{} node affect the sun's appearance when up close to it. I recommend that you not change sunAU and luminosity because I think that will likely mess up the power generation of solar panels. @ScaledVersion { Light { sunlightColor = 1, 0.92, 0.85, 1 sunlightIntensity = 0.45 sunlightShadowStrength = 0.75 scaledSunlightColor = 1, 0.92, 0.85, 1 scaledSunlightIntensity = 0.45 IVASunColor = 1, 0.92, 0.85, 1 IVASunIntensity = 0.34 sunLensFlareColor = 1, 0.92, 0.85, 1 ambientLightColor = 0.06,0.06,0.06,1 sunAU = 13984359719 luminosity = 1360 } Material { rimColor = 1,1,1,1 emitColor0 = 1,0.97,0.83,1 emitColor1 = 1,0.887,0.72,1 sunspotColor = 0.54,0.35,0.13,1 } }

Could it be as simple as changing Tellumo's template from Kerbin to, say, Laythe?

I don't use Trajectories but I did do some experimenting with it several versions ago. It worked but was not highly accurate. It appeared that Trajectories pulled in the data from Realistic Atmospheres to make its predictions, but I was consistently landing short of the first predicted location. The amount of error varied significantly depending on the body and the entry conditions, but in some cases I was several hundred kilometers off target. Also, when aerocapturing/breaking I always ended up with a lower apoapsis than the initial prediction. I doubt that using Realistic Atmospheres and Trajectories together will break anything or cause it to go nuts, so I suggest you go ahead and give it a try. If the resulting predictions are not accurate enough for your satisfaction, then you'll just have to uninstall one mod or the other. Maybe things have gotten better than when I last tested it.

Ciro is the sun. @Galileo has tried renaming the sun so that it appears as Ciro in the game, but there is some issue that has prevented that from being implemented. I don't recall exactly what the problem is but I'm sure Galileo can tell you. Hopefully he'll be able to rename it in a future release.

To use Realistic Atmospheres with KSP 1.2 requires that you update to Kopernicus (Release 2). Provided Kopernicus is updated, Realistic Atmospheres will work in its current version (1.2.2).

From my experience, the game will play just fine even if the orbits interfere. In fact, I once by accident had two planets occupying the same space at the exact same time. The planets' orbits are on rails, so the bodies don't gravitationally effect one another. This allows scenarios to exist in the game that couldn't possibly exist in real life. If GPP and OPM where both installed, the game might work OK (don't know for sure because I've never tried it), but you would have two overlapping planetary systems with orbits that couldn't realistically coexist.

Here's a problem that I hope somebody can help with. This problem is in KSP version 1.1.3 using Kopernicus 1.1.3-1. I'm assisting on the development of a mod and we've run into trouble with a planetary ring and moonlet. We have a ring system that is inclined about 30 degrees to the planet's equator and we want to have a moonlet embedded in a gap in the rings. The problem we're having is that we can't seem to be able to lock down the orientation of the rings. The line of nodes seem to randomly change and I haven't been able to identify any particular cause or pattern. For example, I'll load up the game and use KittopiaTech to determine what the ascending node of the moonlet must be to match the plane of the rings. I'll exit, edit the moonlet's cfg, restart the game, and the planes are nowhere near each other. Using the direction of the sun for reference, it appears that the moonlet's orbit is correct, but the line of nodes of the ring plane has shifted from what it was previously. I can never get the rings and moonlet coplanar. Does anybody know how to fix this problem? Is there an "ascendingNode" parameter or something similar for rings that will lock down their orientation?

This mod is dependent on Kopernicus, so until a 1.2 compatible version of Kopernicus is available, Realistic Atmospheres is on hold. It's my understanding that the creator of Kopernicus is really busy at the moment with real life obligations, so we may have to wait a little bit. Please be patient.

Eve Optimized Engines, version 1.1.0 The newest release of Eve Optimized Engines is compatible with KSP version 1.2. Because of changes made to the Swivel and Reliant stock engines, the stats of the Abel and Adam engines have been revised accordingly.

A 1.875m heat shield on a 1.25m payload should give you a ballistic coefficient that is plenty low enough. A periapsis of 30 km might be too high but you can certainly give it a try. Using the Mk1-2 command pod, I got a good entry and landing using a periapsis of 20 km. I then increased it to 25 km and got an aerocapture. I didn't go any higher. If you are trying for a direct entry and landing on a single pass, then I think 30 km is too high (but if I'm wrong it wouldn't be the first time).

Any part, including the heat shield, will explode when it hits 100% of its maximum temperature. For a heat shield I believe the max temperature is 3300 K. When you reach 3300 K it doesn't matter how much ablator you have left, it's going to blow regardless. Also, running out of ablator doesn't automatically mean you're going to blow up. Burning away ablator is just a way to keep the temperature down. When the ablator runs out, the temperature of the heat shield will spike up, but if it's still below the max temperature you'll be OK. I successfully performed a high speed entry and landing at Tellumo using a Mk1-2 command pod with 2.5m heat shield and 800 ablator. My entry speed was 6.1 km/s and the initial periapsis altitude was 20 km. I got up to 92% of max temperature, pulled 7.5 g peak acceleration, and consumed 65% of my ablator. With your higher entry speed of 6.4 km/s I can see where you could've gotten up to 100% of max temperature. Try it again using a higher periapsis. Having a higher periapsis generally means that you'll burn more ablator but you'll reach a lower peak temperature. It doesn't matter how much ablator you have if you reach the max temperature, so the first critical step it to stay below 3300 K. If you can do that, then you have a chance. If you can keep your initial peak temperature below 3300 K but then run out of ablator and blow up, then you likely have no chance to survive no matter what you do. Another critical factor in surviving entry is the ballistic coefficient of your vessel. Basically this tells you how efficient your vessel is at slowing down. A low mass vessel with a big heat shield will have a low ballistic coefficient and will be more efficient at using drag to slow down. Conversely, a heavy vessel with a small heat shield will have a high ballistic coefficient and will be less efficient at using drag to slow down. At Tellumo you want to try to use as low a ballistic coefficient as possible so that you slow down as quickly as possible. Computing ballistic coefficient is not something you can readily do because it requires knowing the drag coefficient. However, you can get a quick idea by just looking at mass per square meter of heat shield. My entry vehicle had a total mass of 5885 kg (at entry) and a 2.5 m heat shield, so that works out to 1199 kg/m2. If your vehicle is much higher than that, then that's likely a big part of your problem. You may need to redesign your vessel to provide a lower ballistic coefficient. (edit) It should go without saying that for a launch vehicle you want a high ballistic coefficient. This allows it to cut through the air with low drag losses (just the opposite of what you want for an entry vehicle). This is why launch vehicle are long and narrow and entry vehicles are squat. In the first case you want to concentrate the mass behind a small frontal area, and in the second case you want to spread the mass out over a large area.

I love this but I just thought of something. Although Gael is given a longitude of ascending node and argument of perisapsis in its config, since it has zero eccentricity and zero inclination, it technically has neither. I recommend that you delete argument of periapsis from the data box.

When you're watching Lili from the surface, how long does it take to cross the sky. I would expect that it zips along at a fairly good pace.

That looks great. I assume you're using the configs with the zero inclination? Hopefully I can figure out how to make it work with the inclined rings, but if not, there are still some scenic views available.

@Galileo, if you decide to add Lili, please let me know. I'll need to updated the tables of properties again.

I was just checking out the water content. It looks like that at 288 K and 100% relative humidity, the air can hold about 1% water. So realistically, I'd probably show it at 0.5%. As far as the other planets go, I didn't really figure an exact composition, but I did have some idea of what I was going for. In the case of Tellumo, I was guessing about 75% nitrogen, 16% oxygen, 5% carbon dioxide, and about 4% other (methane, water, neon, ammonia, etc.). My rationale for 16% oxygen was to have less than Gael but enough to support combustion. But what I just now realized, the 16% for combustion is at 1 atm pressure. At 10 atm pressure, the percentage could be much different. The 5% CO2 was because I figured a large planet like Tellumo might have a lot of volcanism (i.e. hot interior). The other percentages are just what was needed to make the mean molecular weight come out to 29 g/mol. To generate an atmospheric model, all I really need is the molecular weight, not the exact composition. Therefore I didn't think about composition much more than to have some rationalization for the molecular weight I was using.

I'm not suggesting a lower oxygen content. The only reason I mentioned it is because you had it at 15%, which is a bit on the low side. I seem to recall reading that to support the combustion of many fuels, a minimum of about 16% is needed. I think we should keep it pretty close to Earth's 21%.

Right digits, wrong order. 78% N2 and 21% O2. The remaining 1% is mostly argon. (edit) That's the composition of dry air.

@JadeOfMaar, that looks awesome. I see one error though, Gael's semimajor axis is 13,984,360 km. I also figured the molecular weight of Gael's atmosphere to be exactly that of Earth, presuming the same composition. It's possible Gael could have a lower oxygen content than Earth, but then it would need more of a heavier gas like carbon dioxide to make up for it. Also one itsy bitsy grammatical nit pick. It should be "A goldilocks planet that surprisingly..." Generally, "which" is used following a comma, and "that" is used when there is no pause.

Below are the new files: http://www.braeunig.us/KSP/TellumoLili.zip Warning, be careful with the Tellumo file. This is not the .cfg you sent out earlier today. It is the .cfg I sent you on Thursday with the new Tellumo atmosphere, but with the Ring node copied to it. As I said, I couldn't get your file to work. The only change I made to the ring is to set angle = 0. The Lili .cfg has several changes to it. First, I deleted a bunch of stuff that's not needed, like mass and gravParameter. All we need is radius and geeASL, from which the game computes everything else. I think it is best to not specifiy the other stuff to avoid possible inconsistencies. I also greatly reduced geeASL to give a more realistic density (accounting for the fact that density 10x what it would be in real life). The value you used gave Lili an impossible density. We normally also don't need to specify sphereOfInfluence and hillSphere (the game will calculate those), but in this case Lili is so small and so close to Tellumo that its computed SOI is smaller than its own radius (I guess that's what happens when you're inside the Roche limit). I therefore overrode the computed values and gave Lili a SOI of 17000 m. This allows orbits of Lili if we're within 10 km of it. I also made Lili tidally locked. Furthermore, I gave it a very slight inclination of 0.5 degrees so that is passes just above and below the ring plane to produce some nice views of the rings. Not much of an inclination is needed to produce some nice views, but you're free to add more inclination (or take it out) if you want. I also revised things like time warp limits and science values to match the same formulas I used for the other celestial bodies. I could not observe the problem you talked about regarding Lili turning spherical. I changed all the fade start and end values back to the norms. I then did a close flyby of Lili and continued to observed it until it traveled around the far side of the planet and disappeared behind the limb. It looks fine to me the whole time. I also didn't see anything unusual in the map view. One more thing, I noticed that Lili is actually wider than the gap in the rings though which it passes. It might look better if you could widen the ring gap.

I'm assisting on the development of a mod and we've run into trouble with a planetary ring and moonlet. We have a ring system that is inclined about 30 degrees to the planet's equator and we want to have a moonlet embedded in a gap in the rings. The problem we're having is that we can't seem to be able to lock down the orientation of the rings. The line of nodes seem to randomly change and I haven't been able to identify any particular cause or pattern. For example, I'll load up the game and use KittopiaTech to determine what the ascending node of the moonlet must be to match the plane of the rings. I'll exit, edit the moonlet's cfg, restart the game, and the planes are nowhere near each other. Using the direction of the sun for reference, it appears that the moonlet's orbit is correct, but the line of nodes of the ring plane has shifted from what it was previously. I can never get the rings and moonlet coplanar. Does anybody know how to fix this problem? Is there an "ascendingNode" parameter or something similar for rings that will lock down their orientation?

I didn't even get to that. I was totally focused on just trying to solve the other problem. I'll take a look at it. I'll take the inclination out of both the rings and the moonlet and send you the updated files. You can then take a look at it and decide whether or not you want to use it. I looked into that. Sanus' rings have no inclination, so the problem I'm having would not be a issue there. Ovok is inclined 1.5 degrees, so it does pass a little above and below the ring plane.

If I can get some help and figure out how to make Lili work with the inclined rings, then we can add it back. But until that happens, yeah, take it out (assuming you like the inclined rings better than Lili).