Realism Overhaul

[NathanKell]

For the mods based on this, see the Realism Overhaul thread and the Real Solar System thread in Addon Releases

====

This is to combine separate discussions in the KIDS thread, the StretchyTanks thread, the usual chatter in Modular Fuels, etc.

So, between KIDS, MFS, DRE, FAR, RT, we're getting closer. What needs to be done?

First, masses. If we accept 64% scaling, which seems reasonable so as to not overload PhysX, and which most modders who add real-life parts ascribe to, then we also need to scale masses of payload if we're using KIDS, as otherwise our rockets will be utterly ungainly and way-worse-performing than real life.

So, let's tackle masses first. There are three things to consider. First, fuel tank dry mass; second, engine TWR (i.e. mass for given thrust) and third, payload mass.

To resume the discussion from StretchyTanks thread, here's what I have so far:

I was responding to Starwaster, who found that for the actual tank (not the whole stage structure, the tank) for RP-1 on the S-IC, dry mass was approx 11 tons and there was approx 622 tons of RP-1 in it. That yields a ratio of 0.017 or so. (Note that in stock KSP, tank mass ratio is 0.1111)

I then did some basic guesstimates when considering that KSP tanks are not actually tanks, they're stages with tanks inside.

So, let's talk about the Titan I (the kerolox version) and its first stage.

I figure as one of the first missiles, and not a tank-is-skin job like the Atlas (that to this day has one of the best dry:wet ratios ever), it's a good minimum baseline. In addition, it's nice because it has not much in the way of thrust plates or heavy interstages or guidance, and it's easy to see on a cutaway that the fuel tanks take up most of the internal volume of the stage.

I come up with:

		Diam	Height	Mass	Fmass	Ehgt	Emass	Enum	Vol	Dry Mass Mass/KSPVol	Mratio (dry:dry+fuel)
Titan I-1	3.05	16	4	72.2	3.13	0.84	2	86.7	2.32	0.000133757	0.030446194
Fake TI-1	1.95	10.24	1.13	22.16	2.00	0.28	2	21.7	0.57	0.000132367	0.024607888

The fake Titan I uses the 64% rescales (real:KSP), and a rescale of 1/3 on engine mass (close to .64^3). Its dry mass is slightly lower to account for a 0.4t decoupler.

Note that the volume ratio is about 1/4.7 stock (stock is 0.000625, or 1/1600), and the mass ratio is about 1/4.5 stock (stock is 0.11111, or 1/9).

If the tanks were just tanks, as Starwaster calculates, rather than 2 tanks + outer skin + misc structural mass, then it does seem reasonable the ratios would be off by a factor of 10, not ~5.

So that should cover tanks. Thoughts?

Now, engines.

Engines in KSP have TWRs in the range of 5 (the LV-1) to 10 (LV-909, Poodle) to 14-17 (LV-Ts, Skipper) to 20 (48-7S) to 25 (Mainsail).

Now it just so happens that a flat multiplier of 6x works pretty well here, yielding TWRs of 30 (about right for a tiny vacuum engine) to 60 (upper stage) to 102 (lower stage) to 150 (Merlin 1D, best TWR ever).

Conversely, that means dividing engine mass by 6.

Finally, payload. Now it transpires that pods, at least, in KSP, are quite close to the mass they "should be", as are the probes we build (they're maybe heavier, actually). So we can just do .64^3 (it's the cube rule: mass is cube of volume), which is darn close to 1/3.

We also need (which I am working on) non-probe-core satellites that can transmit science but not be controlled, and which would be very light indeed.

So let's start with payloads massing 1/3 of what they presently do, which means you should be able to launch an Apollo stack on a 64% size Saturn V, with FAR and KIDS set at .33, .33.

Edited December 22, 2014 by NathanKell
update link

[NoMrBond]

What about changing the fuel mixture, if the assumption is that the Liquid Fuel and Oxidizer is use are RP-1 and LOX respectively then the mix ratio should be 1:2.58 a not 0.9:1.1. Perhaps an unneeded complication?

[ferram4]

One correction I'd like to make: the 48-7S got a thrust bump and now has a TWR of ~30, making it a superior lifting engine to the Mainsail.

I think an interesting thing to look at for comparisons is to calculate the structure ratio and payload ratio for each booster and see how it compares to real life.

e = m_structure / (m_structure + m_fuel); structure ratio

m_structure = m_drytanks + m_decouplers + m_engines + ... + m_all_other_not_fuel

p = m_payload / (m_structure + m_fuel); payload ratio

m_payload = m_everything_remaining_in_rocket_after_booster_is_decoupled

For a realistic rocket design, these numbers should end up being the same in real life and KSP and would provide a good sanity check for the calculations.

Edited October 21, 2013 by ferram4
Tweaked m_payload description to be more correct

[NathanKell]

NoMrBond, yup, see MFS thread. That part's all working. Kerolox (in the S-IC) is a 2.2:1 ox:fuel mass ratio, which seems about average for kerolox stages, so that's what I went with. Given the differing densities and that KSP engines take volume ratios and not mass ratios, that equates to approx 61/39 ratio of oxidizer to fuel, volume.

2.6 is closer to the modern ratio I think?

ferram: yeah, it should have gotten a nerf, not a boost...

And the spot-check routine sounds right, too--thanks for the breakdown.

[Starwaster]

One thing I'd like to note is that I focused on the internal tank aspect primarily because with Modular Fuels we can make adjustments to the two separately. basemass would be structural components and specified TANK{} mass the internal.

It's that specific area that seems like it's more massive than real life fuel tanks. LiquidFuel and a lot of other tank types in the TANK_DEFINITION[Default] have a mass per unit volume of 0.0005. So I'm going to experiment with cutting that down to 1/10th (Edit: Oops not a tenth that's probably too much. I still have to work that out...). I think in general people have avoided trying that sort of thing out of concern that it would make things 'too easy' and that it would unbalance the game, but we'll see where it goes.

Basemass (i.e. structural tank component) I haven't even looked at. Maybe scaling down the internal tanks will be enough, I don't know. Thoughts?

Edited October 21, 2013 by Starwaster

[NathanKell]

Right, sorry, I guess I wasn't clear about that when I copied the convo over?

From http://spacecraft.ssl.umd.edu/academics/483F09/483F09L13.mass_est/483F09L13.MER.pdf I find:

Where V = volume (in m^3) of fuel

LH2 tanks: 9.09kg * V

All other tanks: 12.16kg * V

However, the data for LOX seems to fit the linear regression less well.

Further, there's additional mass for cryo insulation: LH2 is 2.88kg * tank surface area; LOX is 1.123kg * tank surface area.

We can estimate that the tanks are capsules, of approx the same radius as sidelength (works for most normal stages). Volume is 7/3 * pi * r^3, whereas area is 6 * pi * r^2. So we can say that insulation should not be proportional to volume, but to the 2/3 root of volume.

I can add precise calculation of that to MFS, of course...

(You might want to read the whole pdf; it's quite helpful for us. Also details estimates on fairing mass.)

EDIT: Since we're talking about the whole stage, we can use the fairing estimate. Stage height we can guess as two capsule tanks. We will consider only the walls of the tank, since presumably the engine and the nose fairing or decoupler will account for the two ends. So 2 * pi * r * h.

All that * 4.95, then raised to the 1.15 power.

Edited October 21, 2013 by NathanKell

[Starwaster]

Right now I'm just trying to wrap my head around the density reduction that I'm only just now discovering. I couldn't figure out why my calculated figures for fuel were so far off from what I was expecting in the KSP editor. Finally tracked it down to the MFS resource file and see we're redefining what the tank volume unit represents. So basically volume (and therefore resource density) are cut by approximately 20%?

[NathanKell]

Oh, you mean the original volume unit = 1/160th m^3 thing, whereas I'm using 1/200?

I went with 1/200 because the only tanks we have to go with are not actually tanks, they're tanks + outer structure. So it makes sense there's wastage. (Coincidentally and usefully, it means that you get the same energy density going from LF/OX at stock density to RP-1/LOX with 1 unit volume = 1/200 m^3).

So tanks that have only 1 subtank, and that are shaped in a tanklike manner (toriod, Stratus, Cylindrified stratus) could have 1/160th their volume in m^3 as KSP volume, but the cylindrical tanks where it's assumed there's two internal capsule-shaped tanks? 1/200.

Edited October 21, 2013 by NathanKell

[Starwaster]

Oh, you mean the original volume unit = 1/160th m^3 thing, whereas I'm using 1/200?

I went with 1/200 because the only tanks we have to go with are not actually tanks, they're tanks + outer structure. So it makes sense there's wastage. (Coincidentally and usefully, it means that you get the same energy density going from LF/OX at stock density to RP-1/LOX with 1 unit volume = 1/200 m^3).

So tanks that have only 1 subtank, and that are shaped in a tanklike manner (toriod, Stratus, Cylindrified stratus) could have 1/160th their volume in m^3 as KSP volume, but the cylindrical tanks where it's assumed there's two internal capsule-shaped tanks? 1/200.

I don't see a mechanism in place by which any of the tanks are treated differently from each other. (with regards to volume)

LH2 / LOX engines and nuclear engines are hit pretty hard by this. I didn't see it before because I still had my own config file lurking in there which was overriding some of the resources. Taking it out, stock rockets and KW rockets have a harder time getting to orbit than before.

And as I said, the LVN takes big hit when it's already got a bad rep in this mod. I just checked out an old nuclear test design I have and it's getting about 0.85% of its former Delta-V.

Seems like doing something about the tank mass is definitely imperative now.

[NathanKell]

Correct, there isn't one. I was saying 1/160 would be _justified_ in that case, whereas in general use 1/200 is the proper value. If people really are using non-cylindrical tanks with only one fuel in them (not RCS or Xenon, btw, that's handled separately), then I could do some sort of special handling. But I figure 1/200 works well enough.

Also, recall that as of MFSC, engines have realistic Isp, so non-hydrolox engines will be lucky to hit 350 vac, and nukes (eventually) will have their real 850-950s Isp. I've done tests and hydrolox beats the pants off kerolox for upper stages where TWR matters less (heck, it even wins at equal TWR for lower stages!), and nukes are even better, even with their low TWR.

[asmi]

The Russians fire-tested MethaLOx engine with Isp of 380 sec.

As for the main topic - maybe it would actually be easier to find a way to redefine celestials' properties to match RL, than doing all of this?

[NathanKell]

Nope, because float errors. Orbits are bad enough as it is, even after ScaledSpace.

If KSP switches to 64-bit and gets double-precision floats for free, and if we get a way to change all those attributes without breaking other things...then yeah, I'd prefer to do that too.

But this at least we _can_ do, right now.

[asmi]

Nope, because float errors. Orbits are bad enough as it is, even after ScaledSpace.

If KSP switches to 64-bit and gets double-precision floats for free, and if we get a way to change all those attributes without breaking other things...then yeah, I'd prefer to do that too.

But this at least we _can_ do, right now.

Orbits are using doubles right now. There is no difference between 64bit and 32bit as far as doubles go - they are just as "free" in 32 bit app as they are in 64 bit because they are supported by underlying hardware which doesn't care if current mode is 32bit or 64bit.

And please note that I didn't ask you why do you think we can't do that - I've asked if somebody had actually tried to do that. As an engineer, I don't buy theory unless it's proven (or disproven) by experiment.

As example, for long time it was belived that it's impossible to read and moreso change resources for inactive vessels. But it took me one good Saturday to prove this belief wrong by finding a way to do just that. Here is a screenshot: http://imgur.com/q8wyAiN Please note that it's made from Tracking Station, when vessels aren't even loaded yet (vessel.loaded says false), and yet it still is possible to read and write resources for these vessels. The same is for Space Center screen - believe or not, but game time doesn't actually stop when you go into one of these two screens, and my life support mod still works in these scenes (by consuming/generating resources). Oh, and all of that without any nasty hacks like reflection, private members and so forth - everything is done using public interface only.

With that, can you please tell me if you, or someone you know of, have actually tried to do that? Or everyone gave up without even trying?

P.S. I'm sorry if that sounds a bit harsh, but I deeply believe that engineers are supposed to solve problems, including those problems which were never solved by anybody else before them, and even those which are thought/believed to be unsolvable...

Edited October 22, 2013 by asmi

[asmi]

LOL, it turned out to be much easier than I expected (please note orbit and orbital velocity):

P.S. Looks like my dream of turning KSP into Orbiter while retaining all KSP features might not be as far after all...

Edited October 22, 2013 by asmi

[NathanKell]

Apologies! My reply was flip and I got just what I deserved. :]

I had read (and based on how the numbers fluctuate, thought I saw confirmation) that orbits were floats. So I muffed it, then.

(Are you sure about off-rails as well? The references I had was to PhysX using floats internally, though velocity when queried is returned as a double)

I have not tried rescaling planets, no. And since it is indeed technically possible to add new planets, presumably with different orbital and physical parameters, I see no reason to believe it is impossible per se, although I am not sure whether KSC would relocate properly. It's the latter--the breaking other things--I'm more worried about. But you've got me fair and square. I haven't tried it.

And as I said, I'd love it if it happened, but for now I was going for the low-hanging fruit. :\

EDIT:

This was the Best Ninja Ever. Kudos to you, asmi. That's right awesome.

Edited October 22, 2013 by NathanKell

[asmi]

THIS is THE stuff (note parameters):

KSP feels kinda funny (craft is ejected with quite a velocity from the launchpad), but maybe these issues could be solved afterall?

[NathanKell]

That looks amazing, and well worth playing with. The main issue with dV scaling, after all, apart from planes, is time to orbit/thrust.

What CelestialBody params are you playing with? I can guess most, but the question for me is after the rescale how to get a 100km atmo.

....and good gracious, you must be going fast on the surface! 6h period for a planet that big!

EDIT: Gotta say, never eaten tastier crow. :}

Edited October 22, 2013 by NathanKell

[AbeS]

"I am not sure whether KSC would relocate properly"

But didn't he just made the planet more massive? why would KSC need relocating?

Applying the orbital period formula Kerbin's radius is still 600km in that picture, and the mass is like 13 times bigger, I think.

Then again, I know nothing about modding and stuff like that

EDIT: Nevermind, I was wrong xD

[asmi]

And the last treat for today (it's 11:40pm over here, note orbital velocity):

What CelestialBody params are you playing with? I can guess most, but the question for me is after the rescale how to get a 100km atmo.

Believe or not, only one - it was GeeASL (set it to 13.8 in SpaceCenterAddon::Start() (that is my class marked with [KSPAddon(KSPAddon.Startup.SpaceCentre, false)]) for the first screenshot, and Radius (set to 6371000 in the same place) for the rest of them. Visuals are still "old", but solving THAT is IMHO well worth investing time into. Looks like you guys might need to turn your balancing gears to the opposite direction - with that kind of environment, even mainsails won't do much good . I gotta commend Squad devs as they (possibly unintentionally) made it so easy to play with.

And I've gotta thank you for setting me up for the challenge - I've been wanting to try it out ever since I've started playing KSP, but never went as far as to actually sit down and try it

So, once I finish the work on my current ECLSS mod, I'm all set to take up the challenge of making it all work. Join up and maybe we'll turn KSP into what we want it to be for us!

That's enough for today. asmi out.

P.S. Remember that theorists in US in 60s had concluded that staged-combustion KeroLOx engines can not be built, but the Russian engineers didn't care about theory, and instead actually tried and developed the most advanced KeroLOx engines on the planet to date.

Edited October 22, 2013 by asmi

[NathanKell]

Join up? Heck, I'm already playing with CelestialBody, figuring out if I can get the orbital parameters to work. Thanks so much for pointing the way and, most importantly, kicking me out of "nahimpossible"!

The best part is the balancing gears don't need any turning--this thread is already about balancing for reality and then dividing Isp by 3 (which scales _very_ closely for both Earth->orbit, and Earth->other planets/moons, to KSP values.). So we can just do without KIDS and all the work of this thread so far needn't be changed.

[TheCanadianVendingMachine]

Sorry, but when I see a large block of text on the screen, I cannot understand. So, is this making KSP more "real". As in, 1:1 planets?

[AbeS]

It is currently brainstorming, but that's kind of the goal!

[ferram4]

I am terrified and intrigued. The only other thing that needs to be done for the planet scaling is to have the atmosphere's scale height increased to 7.5km from the current 5km and have it end ~100km - 120km up. How does the terrain look after this mess?

Also, a rotational period of 23hr, 56min and 4.1s, so that you have a proper sidereal day.

I guess KIDS will get two uses: making things harder for people who don't want realistic-sized planets (and any issues with those) and those who need an easing-in type of plugin for getting used to realistic-sized planets.

[Razorcane]

If you want me to give my input on realism overhaul, I suggest a redo of the physics. It is horrible and inaccurate, and it encompasses everything we know about physics up until the late 15th, possibly early 16th century, apart from general relativity, which was always apparent anyway, but wasn't given any sort of coherent name until the 1900s. Of course I'm not sure this can be done with a mod, but I would hope that the devs realize this mistake and will correct it.

[NathanKell]

ferram, that's exactly what I'm working on now, spurred by asmi. All those parameters look easily changeable (though I'm unclear on the interaction between rotational period and angular velocity, i.e. which informs the other). And presumably we can borrow hyperedit's orbit-changing code to change the orbits of planets.

I'm thinking moving Minmus to Duna, so there's a Phobos and Deimos both? Dunno what to do about Dres though. Given what was said when Kragrathea was talking about it, she ran into memory problems adding more planets because the quadtrees are such hogs. I wonder if we could instance them? I'd rather have six moons that all look like the same rocky ball (but different sizes) than only one, any day.