Realism in KSP - Various Ideas with Pros/ Cons

[Red Iron Crown]

"The lack of a proper atmospheric re-entry model has enabled the latest KSP challenge  speedruns to the edge of space."

Pfft. Burning off a few canards on the way up is half the fun of a speed run. I may not get both up and down in two minutes, but I could certainly do runway-to-circular-orbit in that time.

That quote struck me as a bit odd, too. Speed runs would still be possible with better aero, though the times would increase.

[NathanKell]

I like that un-deadly reentry is characterized as exploit.

[Renegrade]

Man, I loved FE2 and FFE, although I've only ever played them in DOSBox. Did play this as a kid on a Mac SE though.

I think there's some fan ports to OpenGL, by the way. Anyhow, it's fairly impressive, procedurally generating the entire galaxy (with planets and stars and orbits and everything), having dozens of ships, upgrades, a trading engine, ISRU, contracts, and personnel management on a floppy disk and in full real 3D. I think the only drawback was that ship motion used a simple iterative force mechanic, rather than Keplerian/orbital mechanics.

I like that Orbiter though - puts a different twist on 'Go play Orbiter!' heh. I seem to vaguely recall a C64 flight simulator that looked kinda like that..

[Jouni]

Eh? I play a lot of stock FAR, and I mean a lot, and I generally find I use two stage rockets, with some three stagers put in for larger payloads. 3200-3500dv requires about half of the theoretical maximum that a 370 isp stage can provide (~7500), which is pretty much on the same scale as 4500. We're talking like 45% and 55% here..

That's a wrong way to estimate it. A Skipper with an orange tank can lift something like 11-12 tonnes to orbit with FAR. Without FAR, the payload capacity is limited to 4.5-5 tonnes. In other words, the difference is huge.

[Renegrade]

That's a wrong way to estimate it. A Skipper with an orange tank can lift something like 11-12 tonnes to orbit with FAR. Without FAR, the payload capacity is limited to 4.5-5 tonnes. In other words, the difference is huge.

I'd call that a small difference - only about 5 tons. You could strap a pair of large SRBs on the stock version and it's carrying the same mass into orbit.

The mass ratio overstates the difference, just as the percentage understates it. In Stock and FAR, you can do SSTO rockets with light payloads. In Stock and FAR, staging is required for any serious payload. Fundamentally the same.

Compare a sea level Eve launch vs. a Mun launch, then we're talking about a 'huge' difference. Suddenly the Skipper+Jumbo64 is putting over a hundred tons into orbit in a single stage on the Mun, versus making it less than halfway on Eve with literally 0 payload. Huge difference.

Enabling a FAR-like experience in stock won't suddenly completely ruin the game, just change it a bit. Regex's solution came pretty close to fixing up the difference, but I'm not sure how Squad would feel about rescaling the entire system, considering how long it takes to biome a single planet or make Gilly's 'low space' region and warp tables a bit less ridiculous.

[NathanKell]

Eh?

It's all about the mass ratio, that's how the rocket equation works.

You can SSTO with *any* size payload; the mass ratio you need for 0.2 tons is the same as the one you need for 200 tons (modulo the fact that with FAR drag goes by the 2/3 root of mass, roughly, so you will need a *lower* mass ratio for 200t than you did for 200kg).

[m4v]

Enabling a FAR-like experience in stock won't suddenly completely ruin the game, just change it a bit. Regex's solution came pretty close to fixing up the difference, but I'm not sure how Squad would feel about rescaling the entire system, considering how long it takes to biome a single planet or make Gilly's 'low space' region and warp tables a bit less ridiculous.

Squad wouldn't scale the system, they will just either nerf the rockets or keep the extreme air drag.

[CoFFian]

For "realism" I need at least this:

[CoFFian]

Wow, how can I make it smaller?

Edited September 11, 2014 by CoFFian

[Guest]

For "realism" I need at least this: http://goo.gl/cGRdav

You can have that with the Home Grown Rockets pack.

[Renegrade]

Eh?

It's all about the mass ratio, that's how the rocket equation works.

You can SSTO with *any* size payload; the mass ratio you need for 0.2 tons is the same as the one you need for 200 tons (modulo the fact that with FAR drag goes by the 2/3 root of mass, roughly, so you will need a *lower* mass ratio for 200t than you did for 200kg).

My whole point was more along the lines of 'omg 8:1 is so much better than 5:1' when in fact it isn't. It's more like 'bleh ln(8)and ln(5) are basically the same number.' (y'know, how like 9.82 and 9.806 are exactly equal). Plus you can't really strap together huge bundles of jumbo64s and skippers and expect the game to handle it gracefully.

Regarding aero - did you just suggest that we could much use Squad's aero^(3/2) and forget all this FAR business? Bad Nathan, bad!

Squad wouldn't scale the system, they will just either nerf the rockets or keep the extreme air drag.

Yeah, that's very likely what they would do. Given a choice between the two, I'd prefer the former though. I'm playing a stock-plus-info-only playthrough at this time, and the sticky stock air is evil.

[SkyRender]

Here's my own somewhat-simplified take on things:

Aerodynamics

-Pros

* It's actually a lot easier to get to orbit in a proper aerodynamics model, assuming you have an aerodynamic build

-Cons

* Unless procedural fairings are also added, most rockets will never be flyable

* Aerobraking becomes much, much trickier

Solution: A modification of FAR-like aerodynamics, without the aerodynamic failures (the primary cause of around 90% of FAR-related accidents).

Universe Scale

-Pros

* A bigger space to explore

-Cons

* A massive drain on resources

* The engine can't really handle it

* Would require significant rebalancing

Solution: Really, it's fine the way it is.

Isp

-Pros

* With a scaled universe, it acts as a balancing tool

-Cons

* Without it, it just makes things much easier

Solution: As above, just don't add it.

Life Support

-Pros

* More challenging missions and design requirements

-Cons

* Not even remotely new-player-friendly

Solution: Don't implement it, or have it be an optional "hardmode" feature.

Re-entry Danger

-Pros

* More challenging missions and design requirements

-Cons

* Not even remotely new-player-friendly

Solution: Don't implement it, or have it be an optional "hardmode" feature.

Of all of the original suggested realism mods, only the first stands out as an issue that needs to be addressed any time soon. Adapting to whatever takes the place of the current aerodynamics model is going to be one of the hardest things many players do.

[Jouni]

I'd call that a small difference - only about 5 tons. You could strap a pair of large SRBs on the stock version and it's carrying the same mass into orbit.

The difference is not 5 tonnes. The difference is that you need almost 2.5 times bigger rocket to launch the same payload single-staged with stock aerodynamics. While single-stage lifters are borderline useful in the stock game, especially if you consider costs, they have higher payload fractions in FAR than any asparagus lifter has with stock aerodynamics.

To lift the same payload with stock aerodynamics, you need to use two of the biggest SRBs as the first stage. In FAR, that rocket can lift maybe 24-25 tonnes, or about twice as much. While it's still much more efficient than in the stock game, the payoff from staging is less than in stock (roughly 2x vs. 2.5x), because the delta-v requirements are so low.

[Corw]

The rescale is more about maintaining dV requirements to orbit if better aero reduces them as in FAR/NEAR. Cutting 1000m/s from ascent requirements makes staged rockets almost worthless. If the surface gravity is to remain at 1g and the 4500m/s to orbit is desired, radius must increase.

That is why I said, quote "moderate increase in size for balancing reasons and such", but going full blown Earth size just for the heck of it doesn't look like a good call from my point of view.

[NWDogg]

With a new aero system, the problem isn't just how much payload you can get to orbit. It is also a serious career mode imbalance. For example, the very first ship every single player makes, to complete the '5,000 m altitude' contract, is a MK-1 pod with the RT-10 SRB. It's going to pretty silly when they reach over 450 Km (!!!) with that thing on their very first launch without even trying.

We probably can't have a new aero system without changing something. The scenarios like above will only get more absurd as time goes on. Change career mode, nerf engines, use ISP scaling like KIDS, or scale the system...those are the best (only?) options as I understand it.

Here's a question though: Is there any way, theoretically, to get realistic drag without using the air density of the Earth? Let's say Squad implements realistic aero, but instead of just using Earth-based numbers like FAR/NEAR, they come up with an atmosphere that is more dense, and so doesn't have the extreme dV-to-orbit losses of FAR---is that possible? Would it even make any difference to the 'souposphere' we have now? Would it throw off the other planets' atmospheres, balance-wise?

[Renegrade]

To lift the same payload with stock aerodynamics, you need to use two of the biggest SRBs as the first stage. In FAR, that rocket can lift maybe 24-25 tonnes, or about twice as much. While it's still much more efficient than in the stock game, the payoff from staging is less than in stock (roughly 2x vs. 2.5x), because the delta-v requirements are so low.

So we're looking at a 20% reduction in staging effectiveness? That doesn't sound so bad to me. It's not going to absolutely ruin the game or anything. That is the crux of the reduced delta-v issue, is it not?

With a new aero system, the problem isn't just how much payload you can get to orbit. It is also a serious career mode imbalance. For example, the very first ship every single player makes, to complete the '5,000 m altitude' contract, is a MK-1 pod with the RT-10 SRB. It's going to pretty silly when they reach over 450 Km (!!!) with that thing on their very first launch without even trying.

A few points here:

- The contracts currently implemented are placeholders

- Because of the above, they are also a joke (0.25 is supposed to address this).

- The altitude ones are just there as handholding contracts for newbies, or OCD people. OCD is going to cost a bit of Funds now.

- The RT-10 craft can reach about 45-48k in stock with a standard setting of 1.75twr (about 32% thrust limiter)

- You can build an orbital craft out of the starting parts in stock using the T30 and FL-T400 tanks. Without exploity explosive decoupling. (1x parachute, 1x t30, 4xT400). This craft can transmit multiple times thanks to alternator, whereas the RT-10 can transmit one-and-a-half times.

- You can build a sub-orbital craft out of the above parts with only 2xT400.

- You can trade in rep for unlimited money in 0.24. 0.25 will undoubtedly have even more of this.

We probably can't have a new aero system without changing something. The scenarios like above will only get more absurd as time goes on. Change career mode, nerf engines, use ISP scaling like KIDS, or scale the system...those are the best (only?) options as I understand it.

You can also change the mass fraction of tanks (ex. the tanks in KW are 10:1 instead of 8:1 in stock -- NASA tanks being 8.2:1 apparently; these could be reduced to 6:1 or something). Note that engines need a good non-trivial balance pass at some point as a number of them have bizarre specific impulses and TWRs.

Here's a question though: Is there any way, theoretically, to get realistic drag without using the air density of the Earth? Let's say Squad implements realistic aero, but instead of just using Earth-based numbers like FAR/NEAR, they come up with an atmosphere that is more dense, and so doesn't have the extreme dV-to-orbit losses of FAR---is that possible? Would it even make any difference to the 'souposphere' we have now? Would it throw off the other planets' atmospheres, balance-wise?

You can increase the effective area of a craft with a multiplier or the sea-level pressure, but you'd have to go absolutely bonkers to bring it back to 4500. I tried out Ferram's 10x area multiplier, but that just seemed to provoke bugs and really encourage aerodynamic building. I'd say the losses there were only about half of stock aero.

The problem here is that stock aero assumes that the effective cross-sectional area of your craft is directly proportional to the mass, so no matter how intelligently you build it, no matter how big or small it is, it will have this massive drag. That's why generally craft find themselves slowing to ~100m/sec just before impact on descent.

With real aero, if you make a slender rocket, the effective cross-sectional area will not increase as it gets taller, only if it gets wider (and even massively abusive asparagus pancakes are actually more aerodynamic under this system than the mass=area=drag stock system, as they usually have engines underneath tanks, saving them some frontal area...).

Overall, the force of the drag is the drag coefficient (this varies per the shape and orientation of an object) times the dynamic pressure (mostly velocity squared, but including static air pressure and such), times it's area. In stock, the drag coefficient (c_d) is almost always 0.2, and the reference area is proportional to mass (mass times .. 0.008?). Not cool. This has the side effect that a stock rocket made entirely out of 0.2 (c_d parts (some parts are not 0.2 (c_d, like cupolas, nosecones or parachutes), it will fall in the atmosphere at any which angle, regardless of it's shape, as there's no net torque anywhere as all the parts are decelerating at the same rate.

I'm sure Ferram or Nathan could explain the aero ends of things a lot better. My jargon in that area isn't very strong. Yet.

Note that a thrust corrector wouldn't have that big of an impact on your efficiency to orbit, you'd just have to be slightly more careful around vacuum-rated engines on the launchpad in terms of TWR. It's main benefit would be to increase the authenticity of the KSP experience and simplify manual calculation of fuel flow rates (plus save a few CPU cycles over the stock .. thing..). While this might sound like a minor gain (and it is), the cost is even less than minor..six lines. KIDS can provide both thrust correction and engine ISP nerfing in one bundle.

[Jouni]

So we're looking at a 20% reduction in staging effectiveness? That doesn't sound so bad to me. It's not going to absolutely ruin the game or anything. That is the crux of the reduced delta-v issue, is it not?

No. With FAR, a single-stage lifter can be 2.5x smaller and a two-stage lifter 2x smaller than with stock aerodynamics. The payload fraction of the single-stage lifter is around 23% (11% in stock), while the two-stage lifter also lifts 23% (13% in stock) due to the inefficiency of SRBs.

[Renegrade]

No. With FAR, a single-stage lifter can be 2.5x smaller and a two-stage lifter 2x smaller than with stock aerodynamics. The payload fraction of the single-stage lifter is around 23% (11% in stock), while the two-stage lifter also lifts 23% (13% in stock) due to the inefficiency of SRBs.

Yes, those figures sound about right. The question is though: will that really ruin the game?

I mean, if I were Elon Musk, and I had a 5t-to-orbit rocket, and Jeb's Junkyard was founded and produced a 11t-to-orbit rocket that cost exactly the same as my model, I'd be very alarmed. Like emergency-board-of-directors-meeting-and-sell-all-of-my-shares alarmed. But if it turned out Jeb was using some simple, unpatented technique that could easily be added to my designs, I'd just smirk and quickly retrofit everything.

I still wouldn't be selling rides to Moon for a TTC token.

[Franklin]

Aerodynamics

-Pros

* It's actually a lot easier to get to orbit in a proper aerodynamics model, assuming you have an aerodynamic build

Solution: A modification of FAR-like aerodynamics, without the aerodynamic failures...

Isp

-Cons

* Without it, it just makes things much easier

Solution: As above, just don't add it.

Life Support

-Cons

* Not even remotely new-player-friendly

Solution: Don't implement it, or have it be an optional "hardmode" feature.

Re-entry Danger

-Cons

* Not even remotely new-player-friendly

Solution: Don't implement it, or have it be an optional "hardmode" feature.

Not trying to get cutting, but I don't know why having the game more challenging, to any degree, is a con. This summation is literally harder = bad, easier = good.

Do the vast majority of people actually see increased complexity or additional nuance as a problem? Isn't that the antithesis of exploration and creativity, which is what KSP is about? I mean it's a rocket and space sim game, not checkers, and outside of making things more difficult for the sake of difficulty, which nobody so far has desired, is it actually preferable for us to steer the game easier over all else? Why has easy become synonymous with good?

It boggles my mind that people who gravitate to rocket design and space exploration in the same hand would reject having to learn something new.

Again though, nothing targeted at you specifically, I just hate the more easy = more fun, less easy = less fun fallacy.

Edited September 11, 2014 by Franklin

[m4v]

Yes, those figures sound about right. The question is though: will that really ruin the game?

Is subjective, just like people can't play without FAR people can't play with that dumbed down approach to rockets.

[NecroBones]

Here's the relevant section from Arcturus Thrust Corrector:

		public void FixedUpdate() {
			float staticPressure = (float)FlightGlobals.ActiveVessel.staticPressure;

			foreach (EngineSettings s in engines) {
				// Our actual Isp at this altitude
				float realIsp = s.engineModule.atmosphereCurve.Evaluate ((float)staticPressure);

				// Maximum thrust, 100% throttle at this altitude
				float realMaxThrust = s.maxMdot * realIsp * s.engineModule.G;

				// Adjust the engine's nominal max thrust to be what it really oughta be.
				s.engineModule.maxThrust = realMaxThrust;
			}
		}

The lines preceded by comments are the meat of the update code. s.maxMdot is basically just a slope.

Sorry for replying a couple of days late.

This is a very compelling argument. Generally speaking, even if a change sounds simple, I try to never assume that it will actually be simple, because you just never know how they've organized their code. A simple thing like ISP variance could be hardcoded in dozens of places in the code (an ugly way to do coding, for sure). Or, maybe the physics implementation for some reason doesn't like thrust variances independent of the throttle setting, or who knows what else.

But this code snippet does show a simple mathematical fix.

Personally I was just happy to discover that they modeled atmospheric losses to begin with. Hopefully this will be corrected, since as others have pointed out, it would be more realistic, while having minimal impact on the gameplay, other than to just be a little more careful to get enough TWR on the pad. My suspicion is that it's been a low enough priority that the devs just never get around to it.

[m4v]

My suspicion is that it's been a low enough priority that the devs just never get around to it.

http://forum.kerbalspaceprogram.com/threads/93292-Realism-in-KSP-Various-Ideas-with-Pros-Cons?p=1405613&viewfull=1#post1405613

[NecroBones]

Sorry for the double-post. I'm coming in a little late.

Now I've got a direct quote that HarvesteR was kind enough to rattle off regarding ISP. This is all that will be said on the matter:

"We are aware that the Isp maths are incorrect for the engines, but that is an issue of low priority at the moment, because gameplay-wise, it would change very little to have that corrected. As for the argument about this being 'too small to not be corrected', that is a kind of inside-out notion. Every issue takes up development time and effort, and we're constantly having to prioritize. If you ask us why we wouldn't fix an issue that small, ask instead why an issue so small would be prioritized over more important ones in order to be fixed."

As I suspected.

However, something that happens a lot in game (or any project) development, is that lots of little tiny bugs and possible improvements will pile up, because they never individually become a high enough priority. Small flaws can stick around forever, and eventually become infuriating.

So I would highly recommend, that perhaps once every few weeks (or once a month or whatever), having a "small bug fixing" day, where you just work on all the little things (or re-categorize them upon discovering they're not so small). I guess the alternative is to save them all for the end, and doing a massive clean-up pass before 1.0. But that's a long time to let a lot of small things linger.

EDIT:

http://forum.kerbalspaceprogram.com/threads/93292-Realism-in-KSP-Various-Ideas-with-Pros-Cons?p=1405613&viewfull=1#post1405613

Ninja'd. Yes, I'm still catching up in the thread.

[NecroBones]

Nice! I never got to play the original Spacewar, although there were a lot of direct clones on home computers (including a CGA version for IBM-PC). I did get to play a version of Lunar Lander at the Ontario Science Center though hehe.

The original PDP version can be played in a web-browser now: http://www.masswerk.at/spacewar/index.html

Though I grew up with the PC version... in monochrome CGA on a 4 MHZ PC. http://www.old-games.com/download/2862/space-war

[Renegrade]

The original PDP version can be played in a web-browser now: http://www.masswerk.at/spacewar/index.html

Awesome find there Reminds me of the Vectrex edition...somewhat. Those were quite rare, so I didn't have much playtime on 'em hehe.

Though I grew up with the PC version... in monochrome CGA on a 4 MHZ PC. http://www.old-games.com/download/2862/space-war

Yeah, I had a copy of that back in the 386 era - I used other platforms prior to then (and still largely other platforms into the Pentium era). It was rather fun. There were several other ports, clones, etc around that time that polished up the graphics a bit that were also quite fun, although I can't recall the names of any of 'em at this point.

So I would highly recommend, that perhaps once every few weeks (or once a month or whatever), having a "small bug fixing" day, where you just work on all the little things (or re-categorize them upon discovering they're not so small). I guess the alternative is to save them all for the end, and doing a massive clean-up pass before 1.0. But that's a long time to let a lot of small things linger.

That's similar to the technique I used to use as a professional programmer, only it was more like a session at the end of a shift, any day where there wasn't some massive interference from the suits. Turns out that translates into 'weekly' or 'monthly' in a lot of companies. Or 'unpaid overtime' (not that it's typically paid anyways)

These problems do tend to build up, and eventually cause secondary issues. It's generally easier to do changes early in a project, too, rather than later on once the faulty code matures into a "feature" and other parts of the project start to rely on it.