Realism in KSP - Various Ideas with Pros/ Cons

[juanml82]

This comes up a lot, but I really don't get it. Double the scale, double the maximum timewarp: impact on wait-around time = 0.

Is there some limitation I'm missing that would make this not possible?

I think it's mostly due physics warp: aerobreak - time to leave atmosphere, 5 minutes - warp to 4x, 1,25 minutes watching your ship engulfed in flames. Increase the scale: time to leave atmosphere, 10 minutes - 2,5 minutes doing the same. Something similar, but not as extreme, happens during take off while waiting for the circularization burn. Or RVs in LKO where time warp is more limited.

All this can be solved with a working faster physics warp, leaving only the use of rovers to reach points of interest as a drawback. But, then again, we're talking about using rovers to move around anyway...

Also, on the topic of realism, something that's not often touched: ion engines. They should be able to be used while on rails, as real ion engines (which are fired for weeks or months). I guess an on board nuclear reactor should be added for missions beyond Dres. And, by making ion engines realistic and allowing a behavior different than short burns at a maneuver node, it increases the gameplay options.

[Tw1]

The applicable and appropriate axial tilts are a good and so far orphaned realism element, can we add those to the first post w/ Pros/Cons? It would add a level of complexity to the current "go straight up for a while, then hold the D key for a while" launch recipe. The con of course is people would need to learn that planets have tilts.

I agree with this idea. This was posted a while ago, and seems like it could be a good set up:

I don't mind the idea of making the planets slightly larger, but I see some flaws:

If everything is re-sized to compensate for reduced delta V needs resulting from aerodynamics improvements, it won't just effect the planets with atmospheres- planets without them will end up being harder to land on/launch from. This may not be ideal. Perhaps they could just adjust the ones with atmosphere.

The main benefits that would come from larger planets, IMHO, is the visual effect, and the fact that there's not as much space between orbits. Kerbin would take up so much more volume compared to your orbital path. Basically, the difference between these two diagrams.

However, this would make rendezvous harder.

The other downside to realistically sized planets which is often overlooked, is it would make ground exploration much harder- Things like Wooks's circumnavigation would be nearly impossible. KSP currently doesn't give you much to do while on a planet, and I'm hoping they will improve this in future, so larger planets may not be that great an idea.

I wouldn't mind some simple life support- how long people can last in space is critical in real life space missions- it seems odd to overlook this completely. Flying around for all eternity is a probe's job really. As long as it's not to harsh- then again, if you save up enough funds, it's not too hard to push about huge loads.

It will show the real difference between a short trip to the Mun, and the years long voyage to Jool.

Edited September 9, 2014 by Tw1

[Levelord]

The air pressure calculation is orthogonal to correct thrust scaling implementation. If thrust scaling were changed, it would be as correct as possible in this aero model and would remain correct in a putative new aero model.

Honestly, I do not understand why this small change is so objectionable. It increases realism with next to no penalty, and seems to be a simple change to implement (according to the programmer types anyway, not my skill set).

Edit for your edit:

No it doesn't, it uses the scale height model. The only sharp cutoff is at the atmosphere's edge.

If that is the case then I don't understand why people incorrectly do a 'gravity turn' at 10km up instead of an actual gravity turn that follows a ballistic trajectory. Those sharp turns are not even supposed to be possible. The aero model is messed up regardless of scale height and it's clear that it's not adequate enough on its own, and I can't see why you would prioritize a change you see as insignificant in front of other glaring problems like aerodynamics.

[worir4]

Snip

Man awesome drawing! I thought it was the real thing!

Instead of scaling up the planets why don't they just scale down the Kerbals and parts!!!!

[Guest]

However, this would make rendezvous harder.

Rendezvous is no more or less difficult under RSS proper (Sol system) than stock; the tools provided in KSP work exactly the same.

The other downside to realistically sized planets which is often overlooked, is it would make ground exploration much harder- Things like Wooks's circumnavigation would be nearly impossible. KSP currently doesn't give you much to do while on a planet, and I'm hoping they will improve this in future, so larger planets may not be that great an idea.

This is an excellent point and why a lot of people argue against fully realistic planet sizes in stock. Upping the scale by 1.5x (planets and their SMAs) to accommodate better aerodynamics isn't that drastic, however, and only increases delta-V to the Mun by about 200m/s at most (while still not provided the full 4.5km/s needed to get to orbit). Which makes the rest of the system a bit less accessible, but once you know your way around another 1000m/s to get to Eeloo will make it that much more satisfying, IMO. Plus, since launches still won't need 4.5km/s to orbit, you can loft even more up there.

But you do make a good point. Also, 3.2km/s to orbit is realistic on Kerbin so it might as well stand.

[Red Iron Crown]

I can't see why you would prioritize a change you see as insignificant in front of other glaring problems like aerodynamics.

Uh, I don't? I think thrust scaling is a quick and easy fix with almost no downsides, but I agree that better aero would have a much bigger impact on the game (among other changes). It is such a simple change that I don't see why it shouldn't be done.

[Franklin]

Unless there's something substantial gameplay wise added to life support, I'm adamantly against it. If someone implements kerbal comfort and happiness levels, a reason to actually take kerbals somewhere other than the arbitrary science experiments they can do, meaningful decision on how the life support is done, then I'm definitely for it!

This is more or less my opinion on the matter as well, and I have a hard time believing Squad doesn't plan to expand upon the depth of Kerbal value. They're already working in experience logs with progressive punishments for killing experienced astronauts, and so far crew maintenance has been one of the last major elements that hasn't been added.

Right now Kerbals are entirely expendable. And while that's fun and fits with the aesthetic (I actually kind of like the cartoony disrespect for life), I think there should be some upkeep to your astronauts from a Space Agency Game angle. The fact that you can leave a man on the moon forever makes them feel less alive and more just like little rovers.

So with that I imagine if Squad ever does get around to life support, they'd be hard-pressed to involve more than just another bolt-on part with fuel-like values. I'm sure they'd go the whole way with it and make life support actually meaningful, or at least dress it up so it feels more organic than current mods.

Plus, as has been discussed with some players not liking a 'timer' on their missions, pretty much all life support mods as it is have snack-generating parts. As regex has already broached, once you're deep enough into the tech tree life becomes self-sustaining, and it just becomes one more element of a mission to consider. Like solar panels, and lights. So while the element makes for good progressional factors, by time players reach the 'sandbox' it becomes more or less drag-less.

Edited September 9, 2014 by Franklin

[Franklin]

The applicable and appropriate axial tilts are a good and so far orphaned realism element, can we add those to the first post w/ Pros/Cons? It would add a level of complexity to the current "go straight up for a while, then hold the D key for a while" launch recipe. The con of course is people would need to learn that planets have tilts.

I agree with this idea. This was posted a while ago, and seems like it could be a good set up:

http://image.noelshack.com/fichiers/2014/22/1401545942-amazing-paint-skills.png

Yeah I think that would be a great compromise.

[SkyRex94]

So heres my opinion on the topics mentioned:

ISP:

I'd say yes lets adjust the system for behavior of the engines in the atmosphere, but thats not a big deal, because basically its just making the system 'realistic' but wouldn't change the gameplay much. Engines are better in a Vaccuum and not so good in an Atmosphere. Some more significant some less. And thats whats counts basically and thats already implemented in the way it is now. So i'd say yeah go for it if you've nothing else left to do, so maybe as an update after 1.0

Life Support:

It may be more realistic, but i'd say NO don't do it stock. If you want it you can get a mod. But it would destroy the Kerbalness of the missions. In reality every bit of a mission is planned before, in KSP sometimes you improvise, like you see ' oh so much deltaV left!? lets land on another body too!' and that wouldn't be possible anymore if you haven't planned it before with the life support system. So this time gameplay wins over realism IMO and if you want it there are mods for it.

Aero:

Yes change the Aero, it would make flying easier and you'd have to watch for the shape of the things you build. I'd go for something like NEAR Aerodynamic system. BUT simultanously to improve stock Aero they'd have to implement Stock Fairings so you're still able to bring weird shapes into Orbit.

Reentry Heat:

I'd say Yes as with Aero, BUT implement it in a way new players don't explode without knowing why that happened. So maybe a new GUI Gauge similar to the G-Force-Meter showing the Temperature of the hottest Part with a red zone where the temp-limit of that part is, so it'll be obvious why something broke.

Universe Scale:

Thats a difficult one. With higher timewarp the time would be the same on rails, but the atmos would take longer which is tedious. And if they implement a better Surface exploring System (look at my Science System Overhaul Thread) and you'll have actual things to do on the Surface, the areas and biomes could get waaaay too big for Gameplay fun. The only pro i see for Real Scale is the better low orbit view over atmo planets, so right now it would only be a pro for 4 planets and its a minor pro. So again IMO Gameplay wins over Realism this time.

[tater]

I'd say because we see the same arguments against every change. Isp seemed when I first heard of the error as a no-brainer. Honestly, when I saw that this error was int eh game, I assumed the even those against any change towards "realism" (even if it made gameplay easier, not harder) would be on board for fixing something so trivial to fix.

I think it's kind of surprising that anyone is against fixing it at all, in the whole list is seems like a given. Get the math right, negligible impact except making some high;y optimal designs in saves less highly optimal (and once any atmosphere alteration is don, those will all be broken, anyway).

I'd wager we could make up something and claim it was wrong, and show the easy fix, and that it would only change current designs by 1%, but then the math would be right, and the same people would be against it just because "realism."

Regarding ion engines, that's an "on the rails" issue, I believe. Seems like it shares the same issues as n-body (a 3-body problem where one mass is set to zero reduces to Kepler). Seems like a constant tangential thrust might be straightforward to patch in to the "rails" system, the trouble would be that KSP allows for arbitrary thrust directions.

Life Support:

It may be more realistic, but i'd say NO don't do it stock. If you want it you can get a mod. But it would destroy the Kerbalness of the missions. In reality every bit of a mission is planned before, in KSP sometimes you improvise, like you see ' oh so much deltaV left!? lets land on another body too!' and that wouldn't be possible anymore if you haven't planned it before with the life support system. So this time gameplay wins over realism IMO and if you want it there are mods for it.

I don't understand any "NO" to stock for something that would clearly be a toggle. You'd really be against it as a difficulty setting, since we know for a fact there are going to be difficulty levels coming? Wouldn't a standardized base for LS make more sense than multiple, similar mods? People then flick a switch and play with it on or off (or a slider, even). Future mods can then use the base code, and depart only where they wish (making it easier to have mods play nice with other mods).

The same is true for any "realism" that anyone is against in stock. Deadly reentry? Add it, then toggle in difficulty. Aero model? Ditto. More ways to play "out of the box," and room for people who start on "easy" to move up in challenge if they life. I see no possible downside.

Edited September 9, 2014 by tater

[Levelord]

Uh, I don't? I think thrust scaling is a quick and easy fix with almost no downsides, but I agree that better aero would have a much bigger impact on the game (among other changes). It is such a simple change that I don't see why it shouldn't be done.

It probably can be done, but the apparent 'advantage' it gives is really, really small. So small that I would regard it as a cosmetic change. My main beef is that some people assuming it's an easy fix, which is questionable at best and that if Isp scaling was one of SQUADs goals they would have implemented it a long time ago during their lunch breaks if it were so easy. So I'm under the impression that it's not as easy to implement as some people may have led you to believe and may involve more complex coding than is probably worth.

I'm on the boat that if all things are equally difficult to code, thrust scaling really should be way down on the priority list until we have a good aerodynamics model, re-entry physics, a basic life support and other things fleshed out.

[Tw1]

Rendezvous is no more or less difficult under RSS proper (Sol system) than stock; the tools provided in KSP work exactly the same.

This is true, but when playing stock size, I tend to set things when I'm rendezvousing so I just have to do a simple hohmann transfer, without the time-taking wait in a higher/lower orbit until you're close to the target. Seems a lot less practical in RSS, you have to move things a fair bit further out before this is possible. Not a major problem, but could make it harder for new people.

Plus, as has been discussed with some players not liking a 'timer' on their missions, pretty much all life support mods as it is have snack-generating parts. As regex has already broached, once you're deep enough into the tech tree life becomes self-sustaining, and it just becomes one more element of a mission to consider.

True, but that's the one of the real differences between a manned and robotic mission- unless you bring enough stuff, you can only be out there for a certain time. This could be a motivator to set up stations, bases, motherships, and other infrastructure beyond a bare bones science lander. Or maybe a system where you can collect some of the necessary resources for long term survival in situ let's not go there.

Not entirely a fan of infinite snack generation, makes it a little easy, unless it's very big and heavy. And maybe doesn't run of nothing.

Plus, if you can bring enough spare fuel for an extra landing, why not some extra life support as well? Build your space empire, and swing around the solar system as you please!

Edited September 9, 2014 by Tw1

[Franklin]

Life Support:

It may be more realistic, but i'd say NO don't do it stock. If you want it you can get a mod. But it would destroy the Kerbalness of the missions. In reality every bit of a mission is planned before, in KSP sometimes you improvise, like you see ' oh so much deltaV left!? lets land on another body too!' and that wouldn't be possible anymore if you haven't planned it before with the life support system. So this time gameplay wins over realism IMO and if you want it there are mods for it.

One might argue that life-support would be seen as another type of fuel, rather than a hard timer. Something like, "Oh we got there quick, we have so many snacks left! Lets land on another body, too!"

And has been mentioned before, all current life-support mods come with snack-generating parts, so really a timer isn't even really a concern, it's just another mission element, like solar/battery management.

But I agree, it's an element that may be best suited to be toggle-able in the difficulty menu.

True, but that's the one of the real differences between a manned and robotic mission- unless you bring enough stuff, you can only be out there for a certain time. This could be a motivator to set up stations, bases, motherships, and other infrastructure beyond a bare bones science lander. Or maybe a system where you can collect some of the necessary resources for long term survival in situ let's not go there.

Yeah, I agree with you, but that's a matter of difficulty scale rather than element inclusion entirely. While I'm completely behind life-sustaining elements, I do believe their challenge should be tailorable.

Edited September 9, 2014 by Franklin

[Guest]

This is true, but when playing stock size, I tend to set things when I'm rendezvousing so I just have to do a simple hohmann transfer, without the time-taking wait in a higher/lower orbit until you're close to the target. Seems a lot less practical in RSS, you have to move things a fair bit further out before this is possible. Not a major problem, but could make it harder for new people.

With a larger solar system you really just have to adjust your thinking and when you launch if you want to launch to rendezvous. I try to launch ahead of the target by a bit, into a higher arc than its orbit in order to "fall" back down into rendezvous, where I match speeds. This can be done easily in a larger solar system, just like doing a Hohmann transfer, which is pretty much how I always do a rendezvous when in orbit because I don't really grok the multiple orbit "inch closer" method and I'm terribly impatient.

[Renegrade]

It probably can be done, but the apparent 'advantage' it gives is really, really small. So small that I would regard it as a cosmetic change. My main beef is that some people assuming it's an easy fix, which is questionable at best and that if Isp scaling was one of SQUADs goals they would have implemented it a long time ago during their lunch breaks if it were so easy. So I'm under the impression that it's not as easy to implement as some people may have led you to believe and may involve more complex coding than is probably worth.

Except it's literally three lines of code. Take a look at any thrust correcting mod, ignore the necessary modding API junk, initialization etc, and you're more or less left with three lines.

If it's trivial for a mod to do, it's even more trivial when you aren't stuck behind the modding API. Especially since they don't have to worry about being incompatible with RealFuels, KIDS, BTSM, Arcturus Thrust Corrector, etc etc.

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.

Aero, re-entry, and life support all require much more massive, sweeping changes. I bet I could bang this change out within an hour, and I don't even know Mono and would be coming at the KSP source completely cold.

It shouldn't take more than five to ten minutes for a Squad programmer.. that would be maybe twice the time necessary to change g0 from 9.82 to 9.81 (s.engineModule.G is g0, presumably), or about 0.015% of the time necessary to do basic life support.

[Levelord]

Except it's literally three lines of code. Take a look at any thrust correcting mod, ignore the necessary modding API junk, initialization etc, and you're more or less left with three lines.

If it's trivial for a mod to do, it's even more trivial when you aren't stuck behind the modding API. Especially since they don't have to worry about being incompatible with RealFuels, KIDS, BTSM, Arcturus Thrust Corrector, etc etc.

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.

Aero, re-entry, and life support all require much more massive, sweeping changes. I bet I could bang this change out within an hour, and I don't even know Mono and would be coming at the KSP source completely cold.

It shouldn't take more than five to ten minutes for a Squad programmer.. that would be maybe twice the time necessary to change g0 from 9.82 to 9.81 (s.engineModule.G is g0, presumably), or about 0.015% of the time necessary to do basic life support.

This still doesn't answer my question of why SQUAD has refused to implement this. Is there any particular reason why they decided to leave this out? Also how does the three lines compensate for the different types of engines like the aerospike for example?

They are "efficient at all altitudes" http://www.nasa.gov/centers/marshall/news/background/facts/aerospike.html although that probably warrants a line specifically to deal with it. Not too much work, but still... Assuming all you said is true, why is it not in the game then?

[tater]

If an actual Squad person posted here saying "This is a feature, here's why…" we'd know it was not an error. Clearly g being wrong is unintentional, right? So they are capable of an oversight, like any other set of human beings.

[Levelord]

If an actual Squad person posted here saying "This is a feature, here's why…" we'd know it was not an error. Clearly g being wrong is unintentional, right? So they are capable of an oversight, like any other set of human beings.

Except that this has been around for 2 years. You're telling me they were capable of listening to suggestions for implementing docking, re-entry effects, ship persistence, and ion engine rebalances since 0.13 but somehow consistently miss the memo on thrust variance? Threads on it have been around for ages and I assume that they didn't want to implement it because it was either too difficult to add, not important enough or rejected for gameplay reasons.

[Franklin]

If an actual Squad person posted here saying "This is a feature, here's why…" we'd know it was not an error. Clearly g being wrong is unintentional, right? So they are capable of an oversight, like any other set of human beings.

That's actually where we left off in the other realism thread when the presumed bug was re-classified as a feature request by someone who isn't even part of the Squad team. Which brought Ted down from the mothership, etc.

I know Squad's terribly busy, but this forum really needs a direct (I mean, sits next to the devs direct) point of contact between the community and them. Someone who can reference requests like this thread and "why things are as they are" notes back and forth between the mothership and us squabbling amongst ourselves.

I know that's supposed to be what the forum's for (and to a different extent, the bug tracker), so I'm not dumping on the mods or community managers so don't take it that way, but communication feels more like throwing pennies down a well and listening for the bottom.

Like, the mods here keep the peace, but who here brings all these topics of discussion and questions up to Squad?

I'm just curious keep in mind, don't read this post with any tone of hostility.

[SkyRex94]

True, but that's the one of the real differences between a manned and robotic mission- unless you bring enough stuff, you can only be out there for a certain time.

That can also be changed by a Science system Overhaul with some Experiments needed to be manned and some Experiments needed to be activated/deployed by a Kerbal. That way you'd have things were you 'need' to bring a Kerbal and that would make a difference between Probe and Manned.

I have an Idea, what about a compromise, let me explain:

Lets implement a Life Support System but not in a way of a Ressource. Lets pretend every command module would've implemented Life support things in there directly.

Like some plancton-cleaner converting CO2 back to O2 and producing new snacks with the Carbon and other extracted things and Recycler converting Urine to Water. Lets pretend such a thing is implemented in every Pod.

So now you'd have some sort of Timer how long you can stay on EVA , so no Command Seat missions anymore. And every Pod would consume an amount of Electricity per Second. So Life support would be a 'balancing out energy supply' problem rather than a 'we need 10t more snacks on the ship' problem. And if it runs we would still save the Kerbalish way of doing missions. If a Pod runs out of Energy for Life support another timer would start how long this Pod can provide support while unpowered, so with the assumed left snacks until their empty and until the Kerbals will die due to CO2. A bigger Pod can provide a bigger Time unpowered with the Hitchiker and the Lab being the best.

Another useful thing in such a scenario would be a generator producing electricity from fuel and oxidizer as your last hope in the night, but such a generator was already announced to come so no problem there. A Manned mission would need much more electric charge per second than a probe mission, which is the same way in real but not in KSP right now.

It would implement Life support in a believable way while keeping it a balancing and not a more fuel problem.

what doya think?

Edited September 9, 2014 by SkyRex94

[Renegrade]

This still doesn't answer my question of why SQUAD has refused to implement this. Is there any particular reason why they decided to leave this out?

Based on my perusal of really old versions of KSP, I think they have a rude hack in place (the Isps of the old engines used to be like '5' and '6' or something heh), and it's basically bug senority-ified itself into a 'feature'.

That's my guess, anyhow. Apparently there was once a dev statement that they intended to fix it one day (from the Arcturus Thrust Corrector thread), but nothing has ever come from it.

(NB: I peeked at the BTSM version of that, and it's very similar, although presumably more up to date as it's 0.22+)

Also how does the three lines compensate for the different types of engines like the aerospike for example?

Quite easily actually. Since the aerospike has very close Isps (388 and 390 if memory serves), it's sea level thrust will be basically 175 * (388/390), or 174.1, whereas say a 48-7S will be 30 * (300/350), or 25.

(Note that it scales smoothly between SL_isp/vac_isp thrust and full thrust as the atmosphere fades away)

They are "efficient at all altitudes" http://www.nasa.gov/centers/marshall/news/background/facts/aerospike.html although that probably warrants a line specifically to deal with it. Not too much work, but still... Assuming all you said is true, why is it not in the game then?

Counter question: Why is g0 9.82?

#define M_PI 4 /* Because Reasons! */

I can't think of any single justified reason why it's like this. The lack of Aero, LS, and DRE do make sense from various angles (Aero would involve a lot of extra data added to parts and rebalancing, life support requires changes to On-Rails ships that may be performance impacting or non-trivial, and DRE involves looking over all heating variables and also adding heat shields etc), but a thrust corrector is trivial.

Unless.. Squad is afraid that people will riot in a panic and burn everything down if their 48-7S engines become 15% less powerful on the launchpad.

[Levelord]

It's puzzling because if it was in the game all along only to be overridden by a bug, wouldn't they have added thrust values for sea level and vacuum in the context menu in the VAB before then?

Counter question: Why is g0 9.82?

Most likely because of the scales used for Kerbin and the planets. Which also explains why the 'water' is so dense that steel girders and asteroids float. As far as I know the Aero overhaul and DRE were at least known development goals, so we know that they are working on those.

Edited September 9, 2014 by Levelord

[tater]

Why is more fuel a "problem?" It's a problem in the sense that is it a puzzle to solve for a given mission, the same way it's a "problem" that you cannot reenter your munar lander at kerbin, so you need a capsule.

A simple LS would be very much like Snacks I think. Treat all consumables as a single unit. You need some much food/water/air/scrubbing per kerbal, per day/hour/whatever. You'd also require power at some minimal level. Each habitable module contains LS as part of the design. The consumption rate can be a difficulty slider, or a few options (normal at 1 per day, say, easy at zero per day, hard at 2 per day or something).

Really, things need to be tied together. The astronauts need to matter. Not just "reputation," but what they can do. Since the player actually does everything, this is a little hard. This is why I'm actually fine with some automation represented by the kerbals doing stuff on their own when ordered to somehow, with slop added in based on their native stupidity, morale, health, and experience. Look at using a maneuver node. You do the actual piloting, which is planning the burn. Then you have to execute it within whatever slop you can on the navball (assuming you are not using some mod to do this with 100% accuracy). You can elect to do it yourself, or you could let jeb do it. He would start the burn +-the ideal start time based upon his skill. He would point the ship +-his skill. He would stop the burn +- his skill. Remember, this would be a choice by the player no to just do it themselves. Health and morale? related to current LS for the former, and amount of space vs current mission duration might alter morale. A reason to build larger stations. This could affect science gathered as well.

There are all kinds of interesting career gamely options that are lacking.

[SelectHalfling0]

I would like to see a "difficulty meter" that you can alter when creating a save (or in the F12 menu). You want life support? Check the box. How long can they last? Scroll the slider. Same with Re-Entry and Aerodynamics. Universe and ISP on the other hand should be left to Squad to decide. Truthfully, even if they don't come out with anything of the sort for any of these, there is a great modding kommunity out there, and they have everything that is listed here.

[Harry Rhodan]

This could affect science gathered as well.

I really like this idea. You can go all the way to Duna and don't have to worry about your guys dying from starvation. But theres only so much science they can gather with an empty stomach.