[1.2] Real Solar System v12.0 Dec 8

[ferram4]

@Captain_Party: You missed a launch site config. I don't know how many people would be interested in it, but there it is.

@Mulbin: Correct, one of my missions is going to be LADEE. Not USA-165, but that would be a cool one to do. The other one goes much further back, but is still launched on a pile of solids.

@DeathSoul097: I decided to go with Eotena; it's a pretty unique name. The main purpose of the design was to deliver a fully fueled Saturn V to orbit for fun and profit. I... overbuilt.

I'm tempted to use it to launch an interplanetary mission to Mars using nothing but solids. The problem is that the current design needs to be rebuilt to reduce part count. I'm going to look into welding together a bunch of the engines on the main core, since there are 19 RS68A 4x clusters down there; I think I can merge the center 7 into a single block (since it isn't needed for roll) and the remaining 12 can be put into 4 groups of 3. On the second stage I also want to merge each of the 3 trios of M-1s into a single engine to reduce part count further. Then I need to look at the boosters and see if I can use a single sep motor for each rather than the two that a currently use. I might look into merging the ground-lit solids together to try cutting it down to 12 solids lit at launch to 6, with corresponding reductions in the part count for decouples, nosecones and sep motors. I'll get rid of the tiny hydrolox fuel tanks that I keep in the nosecone of each of those for some minor fuel crossfeed so that I can scrap the fuel lines. Then I think I'll need to work out a much larger RCS block for the upper stage so that it has the ability to orient itself during a coast phase, since currently there are a stupid number of RCS blocks on it.

I'm actually not planning any missions with that currently. It's just too unwieldy to fly due to the part count, since at launch I'm running at 30% full speed. It's impossible to judge how the ascent is going.

Edited February 25, 2014 by ferram4

[Starwaster]

I... overbuilt.

Blasphemy!

[AndreyATGB]

Ferram casually building rockets to send a fully fueled Saturn V to orbit.

[usulrasolas]

And here I am trying to balance my rcs on a lander... the shame.

Ferram casually building rockets to send a fully fueled Saturn V to orbit.

[NathanKell]

Captain_Party, if you're taking requests: RAF Boscombe Down, and a launch site on Sri Lanka's east coast.

Ferram: Scout, or LJ, or LJ2, would be my guess for LV. Unclear which. Thus maybe San Marco?

[ferram4]

Scout is correct! Actually, I'm planning to do Explorer 9, I'm just unsure about setting up a balloon.

Early SRMs are TWR monsters; I swear, I have to waste dV by heading more vertically than I would like with the Algol stage in order to keep the vehicle from melting during ascent.

Edit: Actually, right now I'm playing around with a Pegasus XL because I'm distracted by shiny things. It too melts on ascent.

Edited February 25, 2014 by ferram4

[Deathsoul097]

@DeathSoul097: I decided to go with Eotena; it's a pretty unique name. The main purpose of the design was to deliver a fully fueled Saturn V to orbit for fun and profit. I... overbuilt.

Lol, You don't say! That thing can almost carry two fully fuelled Saturn Vs to orbit. Also, thanks for choosing my suggestion.

(If you want an explanation, I came up with it because I have been watching an anime recently called Attack on Titan/Shingeki no Kyojin. In some of the Translations for the sub however, it gets turned into The Eotena Onslaught, which does and doesn't make sense at the same time. I DO NOT recommend anyone watch it if they are even a tiny bit squeamish, there is some pretty gruesome stuff in it. If you look it up, be warned.)

Edited February 25, 2014 by Deathsoul097

[NathanKell]

I've always had a fondness for Scout.. With the new utilization slider you should be in a much better position to remake it than I was! Also, now you can use HoneyFox's thrust curve plugin so the solids can have spot-on burn times and curves.

Also, I seem to get *massive* drag losses--on the order of 1700m/s!--when using that type of craft. Dang low gravity losses though!

[Captain_Party]

Right, lined up for the next release, I have Koggala Airport on the southern coast of Sri Lanka, and RAF Boscombe Down. Any other requests?

[brooklyn666]

Has anyone tried using AbeS' launch window calculator? I'm getting some really wonky transfers, and dates that don't match up.

[AndreyATGB]

Has anyone tried using AbeS' launch window calculator? I'm getting some really wonky transfers, and dates that don't match up.

The angles it gives don't match the ones I calculated, they're off by 3-5 degrees for the most part. I haven't tried it but I doubt they are both correct but I know mine work at least.

[brooklyn666]

The angles it gives don't match the ones I calculated, they're off by 3-5 degrees for the most part. I haven't tried it but I doubt they are both correct but I know mine work at least.

It's not just the angles, I haven't calculated anything myself yet, because I wanted to test out the new calculator, but my windows are either way early or way late.

[AndreyATGB]

I've refined my config for RSS 6 and PF today. Changes (that I remember):

-All bodies' inclination are relative to their parent's equator

-Radii fixed for Phobos and Deimos

-Double checked and fixed all SMA's, orbital and rotational periods

-Integrated the color and height maps for all planets and moons, these are from metaphor's pack but use RSS 6 instead of Universe Replacer.

-Changed multiple fade altitudes, most notably Kerbin fades in at 110km. Basically no timewarp lag in LEO.

-Fixed Titan atmospheric pressure (4.5 -> 1.45atm)

Download here, requires clouds and PF. TextureReplacer is for skybox only.

Nathan, you forgot to explain what deformity is. I'd like to know what the stuff in the following do:

PQSMod_VertexHeightMap

-heightMapDeformity

-heightMapOffset

PQSMod_VertexSimplexHeight

-deformity

-persistance

-frequency

PQSMod_VoronoiCraters (procedural craters?)

[ferram4]

For anyone still interested in my previously posted Eotena launcher:

Removing the fuel crossfeed from the booster nosecones, reducing SRB sep motors to 1 per SRB rather than two (with necessary changes to the size and angle of the sep motors to avoid a collision), reducing the sep motors on the main core from 3 to 2 larger ones, reducing the number of deorbit motors on the second stage in the same fashion, as well as the removal of a bunch of upper stage control stuff has resulted in part count of the booster system alone being reduced from 209 to 177. Combining the 12 ground-lit solids into 6 solids reduced part count to 153 and increased clearance during separation, but caused issues on the pad during load and looked less awesome, so I'm not going to do that unless it seems absolutely necessary. Note: the part count includes the launch clamps, which number at 6 on the central core and one per each booster, for a total of 24.

In attempting to weld the Novapunch-based 4x RS-68A clusters I discovered that ModuleJettison only flags one fairing mesh as something to not display, so welding those meshes together was no longer an option. Instead I opted to weld a large group of the AIES Aerospace-based individual RS-68A's, and I was successfully able to weld the central 28 engines (representing 7 parts) into a single part cluster; the remaining 48 engines (representing 12 parts) will be welded into either 3 or 4 parts of 16 or 12 engines, depending on how concerned I am about having efficient roll control vs. reducing part count. Then I will look into merging the M-1s on the upper stage.

As a side not I've decided that the payload fairing is going to be based on a merging of my Saturn-Nova textures and blackheart's extra payload fairing textures, in particular the Long March texture, which will need it's ring repainted that particular shape of red that NASA used.

More relevant to all of you guys, in the process of messing with this (and using it as an extreme test case for KJR) I was able to hack together a workaround the launch clamp jump on load; I simply delete its original connection to the ground and replace it with a new one, which happens to get around the issue (woo!). So that will be in KJR v2.1 when that comes out, I just need to make sure nothing wonky happens as a result of doing that.

I'm also working on a config for Vandenberg AFB as well, with the pad at SLC 6; that should be up soon.

Edit: Here it is. Setting it up was surprisingly easy, with almost no problems involving the terrain at all; perhaps the map decal should be a little larger to get more of the point, but the way it's currently set up the terrain doesn't do anything stupid, so I'm happy with it.

                //Vandenberg AFB, SLC 6
                PQSCity
                {
                    KEYname = KSC
                    //repositionRadial = 158200.0, -220.0, -570000.0
                    latitude = 34.5813
                    longitude = -120.6266
                    repositionRadiusOffset = 165 //42.7000007629395
                    repositionToSphereSurface = false
                    lodvisibleRangeMult = 6

                }
                PQSMod_MapDecalTangent
                {
                    //radius = 79637.5
                    radius = 5000 // KSP: 7500
                    heightMapDeformity = 80 // was 75
                    absoluteOffset = 112
                    absolute = true
                    latitude = 34.5813
                    longitude = -120.6266
                }

Edited February 26, 2014 by ferram4

[AbeS]

It's not just the angles, I haven't calculated anything myself yet, because I wanted to test out the new calculator, but my windows are either way early or way late.

I haven't really had a chance to test it myself, just changed everything to be exactly like the RSS configs. I think I will make a little test now.

EDIT: BTW you need to remember it always assumes you are starting your transfer from a 0 deg inclination orbit. maybe that's what causes the inaccuracy.

EDIT2: It really is way off, at least my tests for a Kerbin-Duna transfer, not sure why though :/

Edited February 26, 2014 by AbeS

[brooklyn666]

I haven't really had a chance to test it myself, just changed everything to be exactly like the RSS configs. I think I will make a little test now.

EDIT: BTW you need to remember it always assumes you are starting your transfer from a 0 deg inclination orbit. maybe that's what causes the inaccuracy.

EDIT2: It really is way off, at least my tests for a Kerbin-Duna transfer, not sure why though :/

Inclination is not the problem, I plan my launch azimuth to match the target body. The problem is the planets not beeing where the calculator thinks they are. So far I've tested for Duna, Jool, and Eve, and they all are massively off. I looked through the orbital elements and I can't see anything wrong.

I am curious about the Epoch being used by the cfg though, because it's not Julian, and there's no other system where the number given works as 1950.

Nathan, how did you figure out the Epoch?

Edited February 26, 2014 by brooklyn666

[AbeS]

I think it is the epoch too, I tested with the moons of Jool and all the numbers where accurate except for the dates. For the moons Nathan didn't mess with the stock mean anomaly at epoch so maybe that's why.

I think it has to do with that number:

Epoch = 1577907488.17727995 // KSP now starts in 1950.

which I didn't use

Edited February 26, 2014 by AbeS

[NathanKell]

AndreyATGB: awesome! Checking out.

Mind if I merge the non-PF portion into RSS itself?

(Also: I think it makes more sense to have moons of planets other than earth have their inclinations relative to the ecliptic, as when you're doing Mars/Jupiter/etc transfers from Earth the ecliptic is your reference, and other than Mars you're not going to be landing so tilt [and fake tilt via equator-relative inclination] matters less.)

So sorry about forgetting to explain that stuff! Here you go (in next post)

Ferram: Slick 6 is finally getting used?

Re: epoch. The epoch is J2000 minus 50 solar years (note that the way the epoch parameter works is actually "subtract epoch from UT to get current time" so times before 2000 get positive epochs).

Epoch should be set for all CBs.

[NathanKell]

First, you need some background on PQSMods. The way PQS works is, when it's about to build a vertex for the quad (quads are the basic building blocks of the PQS, a subdividable chunk of terrain), it first creates a vertex at planetary_radius from the center of the planet. Then it calls each PQSMod to see how that vertex is changed, in the order specified (each PQSMod has an int order field; lowest called first).

PQSMods, well, they modify how the PQS is built/updated/etc. Here, we're interested in PQSMods that modify how vertices are built.

VertexHeightmap has a low order and goes early. Given the vertex's original position it will look up the corresponding texel in the heightmap. The vertex's new elevation will be original_elevation + heightMapOffset + heightMapDeformity * white_level_of_texel. That becomes the new elevation of the vertex and is passed on to the next PQSMod in order.

VertexSimplexHeight passes the vertex elevation to a multilevel simplex noise function. output elevation = input + deformity * simplex_evaluation. For frequency and persistence see http://libnoise.sourceforge.net/glossary/

The VoronoiCraters mods do the procedural craters on the moon, yes. deformity works like always, frequency works like for perlin or simplex noise. Don't change it much or you'll be losing hundreds of megabytes of RAM (a doubled frequency here cost ~700MB!)

[AbeS]

So how do I use the epoch in the code of the launch window planner? Do I need to change the Mean Anomaly at Epoch of the bodies or what? I don't know how to change the epoch in the code, can't find it anywhere

[brooklyn666]

Re: epoch. The epoch is J2000 minus 50 solar years (note that the way the epoch parameter works is actually "subtract epoch from UT to get current time" so times before 2000 get positive epochs).

Epoch should be set for all CBs.

The Epoch 1577907488.17727995 that's in the config is 50.0019 years in seconds. So what your saying is that the way the game reads the epoch is basically "The epoch is x seconds until J2000"? But J2000 isn't defined anywhere that I can see.

[NathanKell]

AbeS: I haven't looked into the code of the planner yet, sorry.

brooklyn666: it's defined in the actual orbital stats. An orbital epoch just means "the time at which these orbital parameters are correct." So what I've done is said that "these orbital stats are true 1577907488 seconds from now." The orbital stats are those for the bodies at the J2000 epoch, which the epoch line at the top of the cfg says is 1577907488 seconds from game start.

[Hodo]

Is the d/V requirements the same as on Earth, with the RSS+Kerbin resize? The mod that doesn't change the planets just rescales them.

On Earth it is something like 9.4km/s or abouts.

[AndreyATGB]

Should be the same, it's the same thing as normal RSS but with planets in different positions.

To Nathan, I understand why it's using the ecliptic, the change is just preference I suppose but I might put it back since it's really odd now. You can use the files for whatever you want of course but since I don't understand what all the stuff you explained does just yet, you should check them first. For example the height map of mars doesn't seem to do anything, the terrain looks perfectly flat once the color map fades out, I guess the best way to figure it out is a ton of game restarts and changing values until I get it combined with reading about it. Thanks for explaining!

[Starwaster]

Should be the same, it's the same thing as normal RSS but with planets in different positions.

To Nathan, I understand why it's using the ecliptic, the change is just preference I suppose but I might put it back since it's really odd now. You can use the files for whatever you want of course but since I don't understand what all the stuff you explained does just yet, you should check them first. For example the height map of mars doesn't seem to do anything, the terrain looks perfectly flat once the color map fades out, I guess the best way to figure it out is a ton of game restarts and changing values until I get it combined with reading about it. Thanks for explaining!

there's two meshes, one far away and one up close. When you start getting close up it fades one out and the other in.