Jump to content

[1.2] Real Solar System v12.0 Dec 8


NathanKell

Recommended Posts

PSA: I submitted a pull request to NathanKell's RealSolarSystem repository with body-centric orbital elements with respect to Earth's equator at B1950.0 (1949-12-31 22:09:18.216 Temps Atomique International) as provided by the Jet Propulsion Laboratory's HORIZONS system.

I set the start of the game to 1950-01-01 00:00:00.0000 Temps Atomique International.

The net result is that the Earth's obliquity with respect to the ecliptic is correct and the Moon correctly lies roughly in the ecliptic (the axial tilt of the other planets is still weird, but there's nothing that can be done about that).

Moreover, the positions and velocities of all bodies are exact at the beginning of the game (they drift afterwards because as KSP does not have N-body gravitation, orbits do not precess).

Note that the ecliptic is no longer horizontal in the map view, the Earth's equator is instead.

If you want to try this out before NathanKell merges it and releases a new version, you can find the cfg here.

Link to comment
Share on other sites

PSA: I submitted a pull request to NathanKell's RealSolarSystem repository with body-centric orbital elements with respect to Earth's equator at B1950.0 (1949-12-31 22:09:18.216 Temps Atomique International) as provided by the Jet Propulsion Laboratory's HORIZONS system.

I set the start of the game to 1950-01-01 00:00:00.0000 Temps Atomique International.

The net result is that the Earth's obliquity with respect to the ecliptic is correct and the Moon correctly lies roughly in the ecliptic (the axial tilt of the other planets is still weird, but there's nothing that can be done about that).

Moreover, the positions and velocities of all bodies are exact at the beginning of the game (they drift afterwards because as KSP does not have N-body gravitation, orbits do not precess).

Note that the ecliptic is no longer horizontal in the map view, the Earth's equator is instead.

If you want to try this out before NathanKell merges it and releases a new version, you can find the cfg here.

Cool. I haven't tried it yet, do those pressure curves actually work? I had the impression the game didn't model the atmosphere when its pressure was lower than 10^-6 times the surface pressure.

You might want to use atmospheric density instead of pressure so that the aerodynamics work right (KSP and FAR use atmospheric density in their drag calculations, and they have it set as a constant multiple of pressure, which only works for Earth's atmospheric composition). For example, Venus's atmospheric pressure at "sea level" is 90 times Earth's, but its atmospheric density is only 55 times Earth's (because of a different atmospheric composition). So multiplying all the Venus values by 55/90 will result in a more realistically behaved atmosphere.

Also, another thing to consider is that the 0 altitude marker in KSP is usually the lowest point on a planet, while in reality the 0 altitude marker is at "sea level", which is not the lowest point. For example on Mars, the atmospheric pressure is 0.007 times Earth's at the "sea level", but the lowest point on Mars is at -7 km altitude, and has an atmospheric pressure of 0.011 times Earth's (atmospheric density 0.023 times Earth's). So you might want to move Mars's atmospheric values down so that the 0 altitude marker in KSP is the same as the -7 km altitude marker in reality.

Link to comment
Share on other sites

Is there a version that only resizes Kerbin? I play with a lot of mods that enable off-world resource utilization and construction so I'd love a version that just makes Kerbin Earth-sized as an extra incentive and a way to test giant heavy lifters.

Alternatively, could I simply just cut out all of the other planets and change the SMA of Kerbin? If so, what's the Period parameter mean?

Edited by TomatoSoup
Link to comment
Share on other sites

You might want to use atmospheric density instead of pressure so that the aerodynamics work right (KSP and FAR use atmospheric density in their drag calculations, and they have it set as a constant multiple of pressure, which only works for Earth's atmospheric composition). For example, Venus's atmospheric pressure at "sea level" is 90 times Earth's, but its atmospheric density is only 55 times Earth's (because of a different atmospheric composition). So multiplying all the Venus values by 55/90 will result in a more realistically behaved atmosphere.

This is incorrect, at least for FAR. FAR correctly calculates the air density based on atmospheric pressure, atmospheric temperature and atmospheric composition (specified in the FAR config file). The only things that still use the weird density = pressure * constant in FAR are the few things that haven't had their aerodynamic properties changed. Making that change will actually make aerodynamics behave less realistically as a consequence.

Link to comment
Share on other sites

Cool. I haven't tried it yet, do those pressure curves actually work? I had the impression the game didn't model the atmosphere when its pressure was lower than 10^-6 times the surface pressure.

You might want to use atmospheric density instead of pressure so that the aerodynamics work right (KSP and FAR use atmospheric density in their drag calculations, and they have it set as a constant multiple of pressure, which only works for Earth's atmospheric composition). For example, Venus's atmospheric pressure at "sea level" is 90 times Earth's, but its atmospheric density is only 55 times Earth's (because of a different atmospheric composition). So multiplying all the Venus values by 55/90 will result in a more realistically behaved atmosphere.

Also, another thing to consider is that the 0 altitude marker in KSP is usually the lowest point on a planet, while in reality the 0 altitude marker is at "sea level", which is not the lowest point. For example on Mars, the atmospheric pressure is 0.007 times Earth's at the "sea level", but the lowest point on Mars is at -7 km altitude, and has an atmospheric pressure of 0.011 times Earth's (atmospheric density 0.023 times Earth's). So you might want to move Mars's atmospheric values down so that the 0 altitude marker in KSP is the same as the -7 km altitude marker in reality.

The very next RSS update will accept pressureCurve data if useLegacyAtmosphere = False is set.

A set of atmospheric curves for Earth, Venus and Mars are included. Arbitrary cutoffs were made at 180km to allow time warping. (I've tested more realistic earth pressure curve data and while interesting to play with, doesn't let you do more than physics time warps)

Edit: Actually... atmospheric height is 192 for Mars / Duna. Pressure data for Mars was generated according to NASA's Martian atmospheric model. Venusian data was generated from generic atmospheric modeling in the absence of solid reliable data.

Edited by Starwaster
Link to comment
Share on other sites

Okay, this is another "why are my launch profiles not working?" post, but I have to do it.

I'm trying to get a rocket into orbit in RSS. Stats are as follows:

Stage 0: 3x SRBs with 120s burn and approx. 1850 kN of thrust, weight about 100 tons each.

Stage 1: 1500 kN thrust (vac) with approx. 110 t of hydrolox fuel, dry mass about 10 tons.

Stage 2: 90 kN thrust, with 20 t of hydrolox fuel, dry mass 2.25 tons.

Payload: mass 15 tons.

The second stage is within the range of size and TWR seen in real rockets of the same payload, e.g. Ariane 5, Atlas V, H-IIA/H-IIB, and the rocket has 10.5 km/s of dV, so it should be able to reach orbit. However, in all my launches so far, the second stage falls back into the atmosphere and burns up before it can reach orbital speed. Apogee is typical between 180 and 240 km.

I have tried both launching manually, beginning pitchover immediately after launch and keeping the vehicle pointed toward the surface prograde marker, and using the Mechjeb ascent profile tool with turn shape between 50 and 75%, starting at 0.5 km and ending at 120-180 km. Using a similar launch profile with a different rocket with a high-thrust upper stage (TWR starting at 0.9), I was able to get into orbit, albeit not terribly efficiently.

Does anyone have experience with launchers with low-TWR upper stages? If so, what sort of launch profile do you use?

Link to comment
Share on other sites

Okay, this is another "why are my launch profiles not working?" post, but I have to do it.

I'm trying to get a rocket into orbit in RSS. Stats are as follows:

Stage 0: 3x SRBs with 120s burn and approx. 1850 kN of thrust, weight about 100 tons each.

Stage 1: 1500 kN thrust (vac) with approx. 110 t of hydrolox fuel, dry mass about 10 tons.

Stage 2: 90 kN thrust, with 20 t of hydrolox fuel, dry mass 2.25 tons.

Payload: mass 15 tons.

The second stage is within the range of size and TWR seen in real rockets of the same payload, e.g. Ariane 5, Atlas V, H-IIA/H-IIB, and the rocket has 10.5 km/s of dV, so it should be able to reach orbit. However, in all my launches so far, the second stage falls back into the atmosphere and burns up before it can reach orbital speed. Apogee is typical between 180 and 240 km.

I have tried both launching manually, beginning pitchover immediately after launch and keeping the vehicle pointed toward the surface prograde marker, and using the Mechjeb ascent profile tool with turn shape between 50 and 75%, starting at 0.5 km and ending at 120-180 km. Using a similar launch profile with a different rocket with a high-thrust upper stage (TWR starting at 0.9), I was able to get into orbit, albeit not terribly efficiently.

Does anyone have experience with launchers with low-TWR upper stages? If so, what sort of launch profile do you use?

Use the first stage to raise the Ap to about 350km or even a bit higher, after the first stage is burn-out and decoupled, point your rocket towards horizon or only a small pitch-up from horizon (like 5~10 degrees), use the larger Time-To-Ap given by the high Ap you have achieved to accelerate horizontally and once the horizontal velocity get higher, the centrifugal effect will become stronger and you will need less pitch-up angle to compensate the gravity pull to maintain zero vertical velocity later.

Link to comment
Share on other sites

OMG! look what "honeyfox" did.... light speed ninja medal awarded!

Posted by honeyfox > "have been fixing some bugs and do more tests, and working with several modeling guys.

And here's something to show

screenshot108.png

Yes, i'm playing KSP with NathanKell's wonderful RSS and this platform is located at Lat 0, Lon 154W, same location as the "Ocean Odyssey" in RL."

give he man a cookie!

Edited by Guest
Link to comment
Share on other sites

eggrobin: merged! Thanks so much for this! :)

TomatoSoup: Period is the number of seconds it takes the body to complete an orbit.

Legendary Emu: please use words. Don't know what I'm supposed to be seeing.

metaphor: Starwaster and Ferram covered it, but re: ASL, Starwaster and I are trying to figure that one out. If ASL can ever return a negative number, then we can just add key = <0 blah elements to the curve. Otherwise we probably will have to go with rejiggering what counts as sea level in KSP.

Armchair Rocket Scientist: Double the thrust on your final stage; that's a worse TWR than even single-engine Centaur has (and SEC is optimized for GTO insertion, not LEO!) Also do what HoneyFox suggests, obviously, but even then you'd need probably more than a single RL-10 (at 99kN!) to push a 38t stack. 180kN should be fine though (although you'll have to burn some radial+, probably).

Just to put some numbers behind HoneyFox's point, you should have your apogee, on SRB burnout, more or less exactly as many seconds in the future as the total burn time of your remaining stages (well, not quite exactly, but close--maybe 30s less?). If your remaining stages have a combined burn time of 15 minutes and your apogee is in 3 minutes...obvious problem. Worry less about height of apogee and more about time to apogee.

Link to comment
Share on other sites

Use the first stage to raise the Ap to about 350km or even a bit higher, after the first stage is burn-out and decoupled, point your rocket towards horizon or only a small pitch-up from horizon (like 5~10 degrees), use the larger Time-To-Ap given by the high Ap you have achieved to accelerate horizontally and once the horizontal velocity get higher, the centrifugal effect will become stronger and you will need less pitch-up angle to compensate the gravity pull to maintain zero vertical velocity later.

All right! Using the approximate payload to Kerbostationary Transfer Orbit, this method worked beautifully with a 330 km apoapsis. Now to try it with the LKO payload!

Link to comment
Share on other sites

Use the first stage to raise the Ap to about 350km or even a bit higher, after the first stage is burn-out and decoupled, point your rocket towards horizon or only a small pitch-up from horizon (like 5~10 degrees), use the larger Time-To-Ap given by the high Ap you have achieved to accelerate horizontally and once the horizontal velocity get higher, the centrifugal effect will become stronger and you will need less pitch-up angle to compensate the gravity pull to maintain zero vertical velocity later.

All right! Using the approximate payload to Kerbostationary Transfer Orbit, this method worked beautifully with a 330 km apoapsis. Now to try it with the LKO payload!

EDIT: Nope, still doesn't reach orbit. It seems that the second stage does need more power.

However, looking at the upper stages of the Ariane 5 (the cryogenic one only has 65 kN of thrust, but looking at videos of launches it reaches 1st stage burnout with only 1 km/s to go before reaching orbit), and H-IIB (137 kN, and launches the rather heavy HTV), it seems like they have less propellant in their upper stages.

Reducing the upper stage's fuel capacity by 25% while extending the first stage from 20 m to 25 m and setting the SRBs to the correct tech level (woops) seems to greatly increase GTO capacity. Theoretically, it now has enough dV to put 20 t into LKO, but I doubt it has the thrust. Still, if it can manage the 15t I originally planned, it will have a launch mass/payload mass ratio of 34:1, which is still pretty good.

Testing later...

Link to comment
Share on other sites

All right! Using the approximate payload to Kerbostationary Transfer Orbit, this method worked beautifully with a 330 km apoapsis. Now to try it with the LKO payload!

EDIT: Nope, still doesn't reach orbit. It seems that the second stage does need more power.

However, looking at the upper stages of the Ariane 5 (the cryogenic one only has 65 kN of thrust, but looking at videos of launches it reaches 1st stage burnout with only 1 km/s to go before reaching orbit), and H-IIB (137 kN, and launches the rather heavy HTV), it seems like they have less propellant in their upper stages.

Reducing the upper stage's fuel capacity by 25% while extending the first stage from 20 m to 25 m and setting the SRBs to the correct tech level (woops) seems to greatly increase GTO capacity. Theoretically, it now has enough dV to put 20 t into LKO, but I doubt it has the thrust. Still, if it can manage the 15t I originally planned, it will have a launch mass/payload mass ratio of 34:1, which is still pretty good.

Testing later...

If the first stage burn-out when the orbit velocity is already near 7000m/s, the gravity pull is actually only 1-(7000/7900)^2 of 1 Gee (suppose the velocity required to reach orbit is 7900m/s, but if your orbit is higher, this value will be lower), which is only 0.21G vertical acceleration you need the upper stage to compensate. Thus even with only 65kN thrust for a total stack of around 20t, the TWR is still around 0.32 which is higher than 0.21... so that you roughly need to pitch up for 40 degrees at that moment.

Note that the above calculation is based on the condition that you have already reached the Ap point when the first stage burn-out, otherwise, you have some more "free" time to accelerate without the need to pitch up that much.

Edited by HoneyFox
Link to comment
Share on other sites

metaphor: Starwaster and Ferram covered it, but re: ASL, Starwaster and I are trying to figure that one out. If ASL can ever return a negative number, then we can just add key = <0 blah elements to the curve. Otherwise we probably will have to go with rejiggering what counts as sea level in KSP.

On that note I'm back from my illness (yay. That was just SO much fun :()

So I'm getting ready to re-examine the issue with martian altitudes but the more I'm looking at the problem I'm skeptical that a negative SL altitude is possible. Obviously planets with oceans would by necessity be an exception but what I think KSP is doing is setting an arbitary SL for planets with no oceans where SL zero is at the planet's radius before any heightmap modifications or PQS modifications. Planets with oceans would have SL zero set to wherever the ocean surface is. Doing it any other way really doesn't make sense and unless Squad really screwed up coding terrain generation (obviously a possibility as they're only human and we humans DO screw up) then I don't see them doing it in a way that would allow negative altitudes.

Edit: And let me also add that while I've been ill I've had all sorts of Kerbal Space Program induced fever dreams along with 'Attack on Titan' dreams and 'The Walking Dead' dreams. And I don't even do psychodelics.... (Also.... If you cough three times in the mirror: Carol appears.)

Edited by Starwaster
Link to comment
Share on other sites

Vertices can be displaced down as well as up. Or else sea floors wouldn't work. So, same same if no ocean PQS above them. The question is just whether the method that returns altitude ASL is clamped.

Great you're feeling better!

Link to comment
Share on other sites

All right! Using the approximate payload to Kerbostationary Transfer Orbit, this method worked beautifully with a 330 km apoapsis. Now to try it with the LKO payload!

EDIT: Nope, still doesn't reach orbit. It seems that the second stage does need more power.

However, looking at the upper stages of the Ariane 5 (the cryogenic one only has 65 kN of thrust, but looking at videos of launches it reaches 1st stage burnout with only 1 km/s to go before reaching orbit), and H-IIB (137 kN, and launches the rather heavy HTV), it seems like they have less propellant in their upper stages.

Reducing the upper stage's fuel capacity by 25% while extending the first stage from 20 m to 25 m and setting the SRBs to the correct tech level (woops) seems to greatly increase GTO capacity. Theoretically, it now has enough dV to put 20 t into LKO, but I doubt it has the thrust. Still, if it can manage the 15t I originally planned, it will have a launch mass/payload mass ratio of 34:1, which is still pretty good.

Testing later...

Success! 15 tons into a 400 km orbit! (with 1.8 km/s left in the second stage)

Final design: P6iZwUD.png

Link to comment
Share on other sites

So I finally got around to making my own rss config. I always wanted a config that converted the stock kerbin system to a realistic system that can exist in our universe. I started out making my own config that kept the stock kerbol system flavor, but with realistic density values of each planet. I noticed my numbers were matching jsimmons's numbers that I just decided to use his values for the mass and radius. However, I simulated the physics on all the planets for about 700 years using universe sandbox so they would settle down into stable, realistic orbits. To keep the orbits tight to the star like in the stock game, I modified kerbol to be about 57% the radius of our sun and changed its mass so it is bright enough to allow kerbol to keep its same orbital period as in the stock game and stay at a comfy 20C (actually kerbin ended up settling into an orbit where it it should be at 19.6C... close enough :D). So, if kerbol was a real star is should shine only at 15% of the brightness of the sun and have about 57% of the radius of our sun.

The moons of the planetary systems have changed a bit as well. Minmus is no longer inclined because the gravity from the mun pulls it into a orbit of low inclination over time. I didn't make that many manual changes for the jool system, but I did push out tylo and vall a little bit. If I didn't vall would crash into laythe every time. This minor modification forced vall into a neat orbit that would change in eccentricity over time due to the gravitational influence of laythe and tylo. When vall got dangerously close to laythe, tylo would eventually pull it back and once vall got dangerously close to tylo, laythe would pull it back. Vall follows this pattern ad infinitum, but since ksp doesnt simulate gravity that way I just put the moons where it is in the middle of this cycle. Bop also crosses under pol's orbit and says hi to pol every so often, which can make for a very easy transfer between the moons. If principia gets to a mature state, moon hopping in the jool system may become interesting with its n-body physics (the moons should stay in a stable orbits, though).

I also modified the scale heights and atmosphere cutoffs a bit to be at the same atmospheric pressure that the Kármán line for earth is defined at (1/2200000 atm). Again this was another spot from where me and jsimmons came to the same numbers with so I kept them mostly the same. However I messed around with eve a bit. Wanted to contain iodine in its atmosphere, so I came up with an atmosphere that is composed of 80% Iodine, 10% Hydrogen, 80% Iodine, 9% CO2, and 1% mystery gases. No idea if such a combination can exist (maybe that 1% mystery gas is what makes all the difference) but it works nicely with the numbers I wanted to achieve. Eve being composed of mostly iodine makes it interesting as the oceans may be iodine liquid since the pressure at the surface at eve is so great. Or maybe eve's oceans are made up of litium instead. If this is the case, Lithium iodide will exist in great quantities on eve, allowing the kerbals to easily make batteries for machines that will filter out the CO2 from the atmosphere into oxygen, which allows them to stay on the planet for indefinite periods of time. So leaving your kerbals stranded on eve isn't as bad anymore!

I didn't change jool's atmosphere, though. I figured since you cant land on jool, the height of the atmosphere doesn't matter that much. I also dont know of a gas that would make such a green color and has a melting point that is at about -150C. Chlorine gas is green, but at the temperatures jool should be at, chlorine will be solid. However, some crazy electrical action may be going on at jool which may be causing some gas to glow green, giving jool its color. Or maybe the tidal forces of the moons causes jool to warm up (I used that as an excuse to keep laythe at a temperature of about 8C, to allow for its water oceans).

Anyway here is my config file for rss:

http://pastebin.com/p0Qq6qVH

Also for you guys who have universe sandbox this is the system I used to get the orbital values for (if you don't use the most accurate setting, weird stuff will happen like gilly being shot off into its own orbit and jool's moons doing wtfever they want to do):

https://dl.dropboxusercontent.com/u/17644930/kerbol%20system.ubox

Link to comment
Share on other sites

Jool is green because the souls of the departed (Kerbals) eventually find their way there where they are condensed and filtered and osmosiate throughout all the Joolian layers giving it its nice rich green texture. In actuality, Jool is a rather dull and boring mauve color so we're better off green.

PS: Nice work.

Link to comment
Share on other sites

This is incorrect, at least for FAR. FAR correctly calculates the air density based on atmospheric pressure, atmospheric temperature and atmospheric composition (specified in the FAR config file). The only things that still use the weird density = pressure * constant in FAR are the few things that haven't had their aerodynamic properties changed. Making that change will actually make aerodynamics behave less realistically as a consequence.

That's interesting. Are the default FAR atmospheric compositions for the different planets based on the real planets, or on the KSP stock planets? Like is Laythe's atmospheric composition the same as Earth's or Titan's? And are you using the temperature given by the in-game thermometer or something else? I guess I'll have to change the atmospheres based on FAR data then. I was using atmospheric density = (pressure * molar mass) / (R * temperature).

Link to comment
Share on other sites

They're based on KSP stock planets, though those are informed by real life. Kerbin has Earth-like properties, Eve and Duna both share a similar composition (90% CO2 and mostly N2, plus some trace Ar) based Mars mostly, but also looking at Venus. Jool uses Jupiter's with as much He cut in as I could (10%) because it made the density so low compared to the pressure. Laythe has an oxygenated atmosphere, but it's mixed with CO2, SO2 and some other nasty things to simulate a sort of volcanic environment with life somewhere on it to keep O2 in the atmosphere. I thought that would be more fun.

All the numbers are exposed in the config file, you just need to keep track of which body is which, since it goes by number.

Link to comment
Share on other sites

I'm also curious right now about RSS / RO / everything else that goes with these compatibility with .23.5. The whole asteroid thing really seems interesting, but I want all my realism to stay unbroken while trying to use it...

Link to comment
Share on other sites

@frozenbacon: Please tell me this is compatible with v6?

I just downloaded and installed the latest version from github so my config works well with that.

Also I noticed you can link bump maps in the config file. Does this mean you can make better looking terrain with a higher res map?

Link to comment
Share on other sites

I just downloaded and installed the latest version from github so my config works well with that.

Also I noticed you can link bump maps in the config file. Does this mean you can make better looking terrain with a higher res map?

I've personally only played with PQS settings, but if it is possible to improve the resolution of the terrain map, that would go a long way towards improving the look of the terrain without having to make it overly exaggerated in the vertical.

Link to comment
Share on other sites

What causes the terrain vibration / jitter issue? I've noticed that even in stock, Mechjeb reports some millimeters per second ground speed while landed and nothing seems to stay exactly where you put it for very long, instead slowly moving along the surface.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...