Jump to content

Realism in KSP - Various Ideas with Pros/ Cons


I_Killed_Jeb

Recommended Posts

Aerodynamics

Something better is needed, no question about it. The "mass/drag" model is...counterintuitive. I found that out fast the first few days of playing when i couldn't understand why my larger plane with more thrust couldnt do as well as my first little testplane.

Universe Scale

This is maybe the only point i don't feel is a big showstopper, could be related to the max-timewarp effect, i don't want to have to wait longer. But for every problem there is a solution. Basically, i don't feel either way about it, do as you please.

Isp

Well, i'm not a fan of something beeing misrepresented. What we have now is simply not ISP. Now, we can say "we don't care", but the argument of "it would be too hard" is just that, an argument for the sake of argument. For that matter, who is the one to judge what is too hard for others? We have engine overheating!!! How often could i not go full thrust because the rocket would just overheat? If thats not too hard...

Just do it right instead of finding arguments to do it wrong.

Life Support

Absolutely needed. Why? Because its the MAIN difference between a short trip into orbit and to the moon and a multiyear mission to the outer planets. When ppl say "not needed, too hard", then how about fuel for the rocket? Its exactly the same stuff, just for Kerbals. If fuel is not too hard, then consumables for Kerbals arn't either. Lets face it, it adds to the challenge, and once you reach orbit/moon, KSP can need a challenge. Its called "game progression".

Re-entry Danger

Well, as i always said, i still don't get why this is not implemented, Squad even took the time to FX it and put values on the parts. If we accept that its a challenge to GO to space, then we will surely accept its a challenge to RETURN from space? Why shouldn't it be, isn't that what KSP is all about, mastering the challenge?

What could be "too hard" here? Its all a question of tutorials and giving ppl feedback when something explodes.

my 2 cents

the always used argument "its too hard" is a logical fallacy. nothing is too hard if you give feedback as to why you failed so you can do better. you are not to judge what is too hard for ppl, even more so when we are talking about "basic understanding" of the representation of spaceflight in a game. We are not talking equations here, we are talking "oh...it did go booooomm...the game tells me i overdid xyz". Thats something a child will understand, because all humans work like that, trial/error. Don't always underestimate your fellow humans.

Link to comment
Share on other sites

Umm...those are nearly all fast rolls and relatively low AoA pitching. I can manage all that in FAR with unstrutted eggshell SP+ wings. Change to stock wings with the CoL in the middle instead of the tip and add some struts and I can pull substantially sharper stuff than that without wing snapping.

Sure, you can break the wings off doing not-too-extreme manouevres, but only if you fly badly. The thing that rips wings in FAR isn't high AoA, it's trying to go from 0° AoA to 30° AoA in a fraction of a second. Only specialist aerobatic planes can handle anything close to that in the real world, and a hypersonic spaceplane is pretty much the opposite of an aerobatic specialist.

It's dragster vs sportscar; Skylon is designed to go very straight, very fast. It's not supposed to do combat manoeuvres. The design priorities of a dogfighter vs a top-speed specialist are sharply opposed.

FAR allows full-throttle vertical-climbing takeoffs; you just have to either get the nose up as soon as you leave the ground (before you've got too much horizontal speed), or pull the nose up over the course of a few seconds. It's go-fast-then-slam-it-into-a-handbrake-turn that causes aerodynamic failures. Planes like curves, they don't like angles.

Just after flicking into a 180° roll, immediately post takeoff:

http://i1378.photobucket.com/albums/ah120/craigmotbey/Kerbal/Kerbodyne%20Showroom/screenshot7_zps316eb448.jpg

10G pulling out of a dive at 500m, maximum elevator deflection:

http://i1378.photobucket.com/albums/ah120/craigmotbey/Kerbal/Kerbodyne%20Showroom/screenshot12_zps74a79d8a.jpg

6G inverted banking roll, >45° AoA:

http://i1378.photobucket.com/albums/ah120/craigmotbey/Kerbal/Kerbodyne%20Showroom/screenshot19_zps9b85b6af.jpg

Negative 8G at full throttle, mid-Immelman:

http://i1378.photobucket.com/albums/ah120/craigmotbey/Kerbal/Kerbodyne%20Showroom/screenshot8_zpsd2da2cfa.jpg

That plane only has two struts per wing; I deliberately left it fragile because I intended it as a trainer. If I was building an aerobatics specialist and went crazy on the strutting, it could tolerate much rougher treatment than that.

I did eventually snap the wings off that, but in order to do it I put it into a full-power dive from 20,000m and then deliberately slammed it sideways just off the deck. It still took a couple of attempts to make it die.

I do agree that it's a bit easier to break wings on large planes than it should be, at least from a game-for-fun POV, but that's more to do with KSP than Ferram. If they'd give us decent sized wing pieces (either larger, or tweakable, or procedural, or weldable) so that we didn't have to build jigsaw wings and strutting became unnecessary, that'd be a good thing.

Pretty much every flyer struts their wings anyway; why not make the strutting reinforcement a given? It'd improve the aesthetics, ease the engineering learning process and reduce part counts. I don't see any downside.

Obviously, not all aircraft are designed for acrobatics. And Skylon, with its short wing, it's probably only going to be good for climbing, but that's an extreme. And clearly you can't make sharp acrobatics at match 3. OTOH, you can easily check how well the 787 can perform, and that's not a plane made for acrobatics.

Have you spoken (or written in a forum) about FAR with actual pilots? Or are you a pilot? I was testing it with a small plane I use for Kerbal rescue missions, I don't even know what I changed, but I was going at 700 km/h on the runway and still not taking off. Anything that has wings and an aerodinamic shape will take off at those speeds. It doesn't matter if it has flaps (it has), where is the landing gear or anything else. The wings make it take off.

Agreed about either larger or weldable wings. KSP physics and damage might be fun, but it's not realistic, specially with aircraft - they shouldn't act like ensembled legos but as pieces welded together. But structural failures in aircraft, specially absent turbulences, are very, very uncommon. Which is why I think something of the simulation you've built has to be wrong somewhere.

Comparing actual aircraft, that are designed to work together, vs lego aircraft makes little sense. It's amazing KSP planes work at all. Engines are not just slapped onto a jet, 10 jet models might all have the same engine (say a CFM56), but the thrust in each might vary by over 50%. Yes, some are early vs later versions in the same family, but it's not just improvements, it's what the original aircraft was designed for. Modern planes with the "same" engine often have very slightly different version---tweaked for each airframe, and they do not produce the same thrust. In KSP, there is the one basic jet, one turbofan, etc. One is slapped in something not much bigger than a BD-5, the other is the size of the space shuttle. Instead of customizing the engine (as they would in RL as needed), you have only the throttle control (or thrust limiting) in KSP.

Regarding disintegration, it can be a toggle option.

Also, isn't it established that the current atmosphere is a place holder? If so it's going to change regardless, so the only question is more vs less realistic.

Well, a certain amount of abstraction is required. Making a spaceplane in the SPH isn't like creating a mod for MS Flight Simulator, nor should be.
First of all, I strongly believe that when considering game changes argument that it breaks current designs should never have any weight. Even if you are so fond of your designs you should have accepted the notion it is a beta and that anything you may or may not have built could be ruined at any time. We can rebuild it, we have the technology (:)) Building and rebuilding is a major part of what the game is actually about anyway.

Aerodynamics

Personally, I was so disappointed when I found out how KSP handles drag with adding up drag of all parts etc. It was the first thing I disliked about the game but I'm willing to let it go for now because I strongly believe that this falls under HarvesteRs placeholders that will be improved upon. So we wait for "scope complete".

Universe Scale

Don't see much of a gain by going bigger just because and I agree with original "scale down to be more fun" approach. For balancing, OK, but this is working out nicely for most people (or so I assume).

Isp

I think I understand why it was done in the first place (constant thrust is easier to understand) but I don't think it would have been a big deal if it was introduced the right way first time around. This might have gone too hard in the simplification direction. Personally, I think it should be fixed (hence, I consider it broken).

Life Support

I'm not sure what to think about this one, it is a large obstacle to long duration missions and I don't appreciate that. If it can be worked trough with some kind of food generation/recycling parts then I'm all for it. It would be similar to how you add solar panels to probes so you don't have to drag tons of battery stacks (I'm looking at you, FlowerChild!)

But I think it would be absurd and going too far on the realism side of things to simulate bone loss and radiation. I mean, there are some people talking about Kerbals and cancer in same sentence! Come on, people, seriously? How many books and TV shows about space exploration actually talk about space cancer? Not many that I've read, and it is because it is not fun. And I have Arthur C. Clark and Isac Asimov on my side :)

Re-entry Danger

Everything in game so far is hinting this will be included and I'm OK with it. I can understand it could be too hard for people, specially in the start and I fully expect it will be optional feature.

The thing with breaking current designs is that it prevents carrying on a savegame from a version to another. Of course, it could be simply solved by a setting that allows, let's say, KSP version 0.3 to run a 0.29 savegame without all the new features that will break the ships already in flight. Meaning you don't have to throw your save game away.

About radiation, yep, that would be me. But we're talking about realism here, and realistic life support goes well beyond food. Otherwise we end up sort of discussing some posters favorite gameplay mods and/or ways to make KSP even nerdier, and calling that "realism"

Link to comment
Share on other sites

Aerodynamics

-Pros

  • Intuitive rocket design will be good rocket design, unlike in a current implementation, where players are punished for building rockets that look like these from real world
  • Nose cones will be beneficial, not punishing
  • Shielded docking port will be beneficial in some designs, not inferior in every way to the unshielded one
  • Building planes (inc. spaceplanes) will be easier and more intuitive (I'm yet to build successful airplane in stock aerodynamics, while I did it just fine in FAR)
  • Game will hopefully start teaching people good things. For example that the best way to get in space is not by using stacks of turbojet engines and one small rocket on top of that

-Cons

  • Current veterans will have to un-learn their old habits
  • Some of the whackjobs won't work any more
  • It'll require more work than it looks on a first glance from the devs. Not only they'll have to code in proper simulation, but we'll also need to have fairings in a stock game (including proper customizable inter-stage fairings) and all of the missing parts related to aerodynamics and structure.

Re-entry Danger

I moved it right under aerodynamics as for me - these two are linked. Proper aerodynamics = proper reentry dangers.

This one is a change that makes least of a difference to the new players.

-Pros

  • Every new player expects reentry to be dangerous. Every new player tries to build a rockets that take that into account. Every new player is somewhat disappointed to find out that it's not the case.
  • Players won't be punished for building realistic descend modules.

-Cons

  • Current veterans will have to un-learn their old habits
  • Some of the current reusable rockets will be useless with a proper reentry damage.
  • Slight increase in difficulty - it should be migrated by user interface displaying warnings when flight path leads to potentially deadly atmospheric reentry (and highlight it when you are on a perfect reentry angle/speed combination)

Universe Scale

Mind you - I don't want game to up-scale into a fully realistic sizes. Just something that wouldn't lead to insane densities.

-Pros

  • More realistic ascend paths - no more forced turns at 10km, instead players will use proper gravity turns and see pretty much the same thing they can in transmissions from the real rocket launches
  • "Going up" won't be nearly as huge part of a challenge as it is now - people will learn a proper thing about the space flight
  • Kerbin (and, well, all the other planets) won't be a neutron star any more with it's insane density
  • It'll trigger Kraken's bane near Mun and Minimus so we won't be experiencing bugs out there that we do now
  • Atmosphere will behave in more natural way allowing for more accurate and easier aerodynamics simulation
  • Which will also allow a proper "translation" of real-world rockets and engines to the KSP reality
  • Game will finally be able to use close-to-real-world values for rocket engines which also adds to the educational value
  • Combined with aerodynamics fix it'll give more-or-less the same DeltaV requirements to ascend into orbit as it is now

-Cons

  • Ascend might take slightly longer (depends on a scale)
  • Flight between the planets and moons might take longer, though it's not really a problem as people run time compression on this one regardless
  • It might require some additional work rebalancing the game (though this change should be combined with fixes to the aerodynamics, therefore overall delta-v requirement to ascent into orbit would remain similar)

Isp

-Pros

  • You get the underlying maths right fixing an obvious issue with the code
  • Isp will be Isp not just from name itself
  • Added educational value to the game - aka. "KSP won't be teaching you wrong things"
  • No need to make any additional changes to the game balance, as game doesn't display any numbers to the player anyway, so for a new customers it won't make any difference on a negative side.
  • You'll be able to use some of the real-world maths in KSP that you cannot now due to the incorrect implementation

-Cons

  • Current veterans will have to un-learn their old habits, especially if they got every rocket calculated down to 1 m/s

Life Support

Before we get into details - it should be balanced in a way where doing a short orbital flights, or a trips to minimus and back shouldn't require any other supplies besides these in a Mk1 pod. Thinks like radiation should be IMHO out of question.

-Pros

  • Added depth to the game, shows some of the real-world challenges involved in a space flight
  • Space stations and bases would finally make some sense
  • Planets with natural resources - like oxygen on Laythe or ice on Eeloo would be more desireable adding another consideration (an advantage) to planning the missions
  • You could build farms / villages, etc. - just look at the popularity of farmville!
  • It'd create additional differentiation between unmanned and manned missions, giving players a reason to send unmanned missions - it'd really make a huge difference comparing to what we have now: a game that tries very much to convince everyone that if we can send Curiosity to Mars we could just as well send men out there tomorrow.
  • It'll add a whole new level of depth and planning to the interplanetary missions rewarding players for thinking ahead and giving them a reason to send unmanned missions ahead of manned (to get an idea on how long it'll take to get there, perhaps also creating resource depots or planet-side bases).

-Cons

  • Current veterans will have to un-learn their old habits
  • It might be a similar thing to the solar panels and people forgetting to unfold them - only this time we'll have people forgetting to take food
  • It'll be most likely the most item-intense addition to the game from all of these related to the realism.
  • It will require adding window with an information about the spacecraft - how long will resources last? What's the current balance of consumption vs production? When we'll run out of food? - still though IMHO it's simpler and more user-friendly than displaying it as an additional types of fuel (even if in essense these are just a types of fuel, and few mods already implement it like that).

ADDITIONAL

Delta-V readouts

  • Super-helpful for a new players who like to have their missions planned
  • Decreases guesswork in a game (Having your Kerbal stranded on a Mun mission is annoying, but doesn't even come close to the frustration of getting that in the interplanetary flight)
  • Adds to the educational value (people will not only learn what the delta-V is but also how amazingly helpful it can be!)
  • Game will give people an option to have everything lined up perfectly instead of forcing everyone into guesswork and try-fail-try again mechanic even if they hate it (part of the reason why MechJeb and Kerbal Engineer are so popular that some people consider them mandatory to enjoy the game)

Rescale the tech tree

  • Make it impossible to research the whole tech tree on a Kerbin itself
  • Split technologies in a logical way (so that we'd have more nodes to research)
  • Move nuclear engines somewhere near the end of a tree (if not the the last spot, the final tech, as none of them have been used to propel spacecraft yet)
  • Put unmanned cores earlier in a tree
  • Make the whole tree at least somewhat similar to the real-world progress (though I think everyone agree that they still want to have manned pod available from the start)

Additional launch sites

  • Either researchable or unlockable by landing in the site
  • Put them at the different latitudes, so that people would be able to learn what are the challenges involved

Rebalance jet engines

  • Make them work in at least somewhat realistic manner, so that we would have...
  • No more rockets propelled by jets!
  • Add ramjet/scramjet equivalent - engine that doesn't work below certain speed threshold

Change nuclear engines

  • Make them use only a liquid fuel. There is absolutely no need for oxidizer in nuclear engines.
  • Add consequences to crashing them
    • At a very least - huge drop in reputation (make it dependant on a biome? Eg. crash on badlands wouldn't make any difference at all?)
    • In a best case - permanent pollution of the area in a certain radius of the crash side (instant death for any Kerbal trying to enter it), huge penalty in reputation, reputation cost for each LV-N launched (so players wouldn't be able to use them without positive reputation)

And something to make life easier, though only remotely related to the realism (again - difficulty is directly proportional to how you explain the game to user) :

Improve maneuver nodes

  • Change color when a deadly reentry path&speed combination occurs
  • Add something to inform people if they'll be touching atmosphere or not instead of forcing them to use the KSP wiki for that
  • Precision......
  • Add option to reset the game speed back to 1x when 1 minute away from the node (gash, missing the node from jumpy time acceleration can be sooo frustrating)
  • Ascend/Descend nodes should appear on your orbit around current planet if you have another planet selected as a target

Improve the docking interface

  • Add a docking camera, perhaps inspired by one in Soyuz - black&white with clear cross-hair and clear readings next to it.
  • Change the docking GUI. Right now it makes docking more difficult, not easier. Data output should be clearly visible while docking, it cannot be clustered in a tiny spot of bottom-left corner of a screen. Don't be afraid to show numbers - they make stuff easier, not more difficult, if you know how to present them to the user in an accessible manner.

Edited by Sky_walker
Link to comment
Share on other sites

Aerodynamics

-Pros

  • Takes the spamminess out of designs thus reducing part counts
  • More of a challenge to get to orbit

-Cons

  • You cannot modify wing shapes to suit desired aerodynamic performance requirements
  • Many old designs will become obsolete

Universe Scale

-Pros

  • More planning involved
  • Assets such as stations and bases get more use and thus, have more value

-Cons

  • More parts, if not scaled, means a slower game
  • Exploration component is diminished as the planet surface area will be too big

Isp

-Pros

  • Rocket design might actually become interesting

-Cons

  • Confusing to the point of restricting young age players
  • Hard to display this information concisely in the interface

Life Support

-Pros

  • More logistics and planning in gameplay

-Cons

  • Kerbals can die more easily making the game harder for new players

Re-entry Danger

-Pros

  • Orbit planning becomes more important

-Cons

  • Many old designs will become obsolete
  • Aero-braking as an option may disappear from mission planning

Edit: If we get more realism in KSP then we have to have more info available in stock gameplay. Otherwise alot of these suggestions will badly hurt gameplay.

Edited by O-Doc
Link to comment
Share on other sites

Aerodynamics

-Pros

  • Intuitive rocket design will be good rocket design, unlike in a current implementation, where players are punished for building rockets that look like these from real world
  • Nose cones will be beneficial, not punishing
  • Shielded docking port will be beneficial in some designs, not inferior in every way to the unshielded one
  • Building planes (inc.spaceplanes) will be easier and more intuitive (I'm yet to build successful airplane in stock aerodynamics, while I did it just fine in FAR)
  • Game will hopefully start teaching people good things. For example that the best way to get in space is not by using stacks of turbojet engines and one small rocket on top of that

-Cons

  • Current veterans will have to un-learn their old habits
  • Some of the whackjobs won't work any more
  • It'll require more work than it looks on a first glance from the devs. Not only they'll have to code in proper simulation, but we'll also need to have fairings in a stock game (including proper customizable inter-stage fairings) and all of the missing parts related to aerodynamics and structure.

Re-entry Danger

I moved it right under aerodynamics as for me - these two are linked. Proper aerodynamics = proper reentry dangers.

This one is a change that makes least of a difference to the new players.

-Pros

  • Every new player expects reentry to be dangerous. Every new player tries to build a rockets that take that into account. Every new player is somewhat disappointed to find out that it's not the case.
  • Players won't be punished for building realistic descend modules.

-Cons

  • Current veterans will have to un-learn their old habits
  • Some of the current reusable rockets will be useless with a proper reentry damage.
  • Slight increase in difficulty - it should be migrated by user interface displaying warnings when flight path leads to potentially deadly atmospheric reentry (and highlight it when you are on a perfect reentry angle/speed combination)

Universe Scale

Mind you - I don't want game to up-scale into a fully realistic sizes. Just something that wouldn't lead to insane densities.

-Pros

  • More realistic ascend paths - no more forced turns at 10km, instead players will use proper gravity turns and see pretty much the same thing they can in transmissions from the real rocket launches
  • "Going up" won't be nearly as huge part of a challenge as it is up - people will learn a proper thing about the space flight
  • Kerbin (and, well, all the other planets) won't be a neutron star any more with it's insane density
  • It'll trigger Kraken's bane near Mun and Minimus so we won't be experiencing bugs out there that we do now
  • Atmosphere will behave in more natural way allowing for more accurate and easier aerodynamics simulation
  • Which will also allow a proper "translation" of real-world rockets and engines to the KSP reality
  • Game will finally be able to use close-to-real-world values for rocket engines which also adds to the educational value

-Cons

  • Ascend might take slightly longer (depends on a scale)
  • Flight between the planets and moons might take longer, though it's not really a problem as people run time compression on this one regardless
  • It might require some additional work rebalancing the game (though this change should be combined with fixes to the aerodynamics, therefore overall delta-v requirement to ascent into orbit would remain similar)

Isp

-Pros

  • You get the underlying maths right fixing an obvious issue with the code
  • Isp will be Isp not just from name itself
  • Added educational value to the game - aka. "KSP won't be teaching you wrong things"
  • No need to make any additional changes to the game balance, as game doesn't display any numbers to the player anyway, so for a new customers it won't make any difference on a negative side.
  • You'll be able to use some of the real-world maths in KSP that you cannot now due to the incorrect implementation

-Cons

  • Current veterans will have to un-learn their old habits, especially if they got every rocket calculated down to 1 m/s

Life Support

Before we get into details - it should be balanced in a way where doing a short orbital flights, or a trips to minimus and back shouldn't require any other supplies besides these in a Mk1 pod. Thinks like radiation should be IMHO out of question.

-Pros

  • Added depth to the game, shows some of the real-world challenges involved in a space flight
  • Space stations and bases would finally make some sense
  • Planets with natural resources - like oxygen on Laythe or ice on Eeloo would be more desireable adding another consideration (an advantage) to planning the missions
  • You could build farms / villages, etc. - just look at the popularity of farmville!
  • It'd create additional differentiation between unmanned and manned missions, giving players a reason to send unmanned missions - it'd really make a huge difference comparing to what we have now: a game that tries very much to convince everyone that if we can send Curiosity to Mars we could just as well send men out there tomorrow.
  • It'll add a whole new level of depth and planning to the interplanetary missions rewarding players for thinking ahead and giving them a reason to send unmanned missions ahead of manned (to get an idea on how long it'll take to get there, perhaps also creating resource depots or planet-side bases).

-Cons

  • Current veterans will have to un-learn their old habits
  • It might be a similar thing to the solar panels and people forgetting to unfold them - only this time we'll have people forgetting to take food
  • It'll be most likely the most item-intense addition to the game from all of these related to the realism.
  • It will require adding window with an information about the spacecraft - how long will resources last? What's the current balance of consumption vs production? When we'll run out of food? - still though IMHO it's simpler and more user-friendly than displaying it as an additional types of fuel (even if in essense these are just a types of fuel, and few mods already implement it like that).

I was going to write here something constructive, but this ^ says everything I would want to say and even more.

Link to comment
Share on other sites

Do you have some insights about the point of view of Squad on all this? I mean, just like there are wiki pages with references on what we should and should not expect (weapons...), I guess Squad has already given some kind of explanation to the most obvious lacks.

From all cited elements, the most obvious is aerodynamics model. Everyone can see that there is something wrong when you lift a bulky platform the same way as you lift a thin rocket. That should be here from the very beginning, and I wish I could know why the hell they did not at least implement a basic aerodynamics model (or integrate NEAR).

Link to comment
Share on other sites

Obviously, not all aircraft are designed for acrobatics. And Skylon, with its short wing, it's probably only going to be good for climbing, but that's an extreme. And clearly you can't make sharp acrobatics at match 3. OTOH, you can easily check how well the 787 can perform, and that's not a plane made for acrobatics.

Have you spoken (or written in a forum) about FAR with actual pilots? Or are you a pilot? I was testing it with a small plane I use for Kerbal rescue missions, I don't even know what I changed, but I was going at 700 km/h on the runway and still not taking off. Anything that has wings and an aerodinamic shape will take off at those speeds. It doesn't matter if it has flaps (it has), where is the landing gear or anything else. The wings make it take off.

Not really, no. The angle of attack generates lift. Airfoil shapes are about reducing drag, not generating lift; a bare plank will lift off with sufficient speed and angle, and the best airfoil won't generate any lift at all if it isn't angled up. If you're still grounded at 700km/h, I'd suspect that your wings are working to generate downforce rather than lift. Get the design right and you'll lift off with no control inputs as soon as you break stall speed; get it wrong, and you've got a rocket sled rather than a plane.

I know a few pilots, and I have a long-standing interest in WWII aviation, but I'm a neuroscientist rather than an aeronautical engineer. I do believe that Ferram knows what he's doing, though.

Have you had a poke through https://github.com/ferram4/Ferram-Aerospace-Research/wiki/An-Example-SSTO-Design-Process ? The bit under the second image about takeoff speeds may be of interest.

Speaking of large planes performing as they shouldn't, check out Alex Henshaw's book Sigh For a Merlin. He was quite fond of doing barrel rolls in Lancaster bombers. :D

Agreed about either larger or weldable wings. KSP physics and damage might be fun, but it's not realistic, specially with aircraft - they shouldn't act like ensembled legos but as pieces welded together. But structural failures in aircraft, specially absent turbulences, are very, very uncommon. Which is why I think something of the simulation you've built has to be wrong somewhere.

The main reason for that is because professional pilots are trained very carefully to avoid doing the sorts of things that might cause structural failure, and the sorts of aircraft used by less-trained pilots are built so that they can't do the sorts of manoeuvres that would cause them to fail. Plenty of desperate pilots broke their Spitfires and Messerschmitts during WWII.

Edited by Wanderfound
Link to comment
Share on other sites

For those people saying that Squad should just copy FAR or NEAR into stock; they can't without open sourcing KSP as a whole;

Both FAR and NEAR are GPL v3 licensed (the cancerous open source license), so unless ferram (the owner of the code and only person able to change the license it is released under) provides Squad with a different license they will have to implement new aerodynamics from scratch.

That is what choosing the wrong license can do.

Link to comment
Share on other sites

I just want to point out that some of those change would fit nicely with the difficulty switch we should get in 0.25. Allow me to digress a bit on coding those (estimation of complexity are my opinion but I think I have a good general grasp of KSP code by now)...

A switch to choose between the actual or a realistic ISP/thrust is a couple of lines in 3 modules (2 engines, RCS) as far as I know.

Universe Scale is more complex but is a scale factor applied to different part of the code (I would argue that having the solar system set up in a config node would make things even better, but it's even more work).

Life Support is middle ground, you have to handle what happens when the ship is out of focus and such.

The aero / Re-entry part require more complex code, but reworking the 'Part' code so the aerodynamics is fully handled by a module instead of the part itself would make it easier to change the used model by squad and modders.

I feel that using a difficulty system for some of the proposed realism change would be a great middle ground. It would allow the player who want to keep their save or not bother with the increased complexity to keep playing as they do, and still allow those who want a more realistic approach to have it.

Edited by sarbian
Link to comment
Share on other sites

Regarding the Isp scaling in atmosphere, Isp in KSP is an accurate representation of specific impulse, it's just how the rocket behaves in atmosphere that is different from how real rockets work. The math used is correct if you imagine all engines use an automatic thrust limiter that limits engine thrust to the value at Kerbin sea level. I would prefer that it scaled thrust rather than fuel flow as real rockets do (why limit the thrust if it doesn't damage the rocket?), but it's not accurate to say that Isp in KSP is not a good analog of real-life Isp.

***

Shifting gears a bit, though I am a proponent of greater realism in KSP, there are some unrealistic simulation elements that I think shouldn't be made more realistic:

- Patched conics: N-body gravitation would be a more accurate representation of the real world and would allow playing with LaGrange points, but the patched conics model is a reasonable approximation (good enough to get us to the Moon IRL), is computationally less expensive, and permits stable parking orbits.

- Throttleable, restartable rocket engines: It is difficult to make a rocket engine throttleable in real life, so it is only rarely done. However, having a working throttle makes rockets easier to control and easier to make fine adjustments to the orbit with, so it's a good tradeoff. Same with restartable engines, they tend to be the exception rather than the rule IRL, especially for lifter engines, but they make handling rockets easier in game.

- Simplified fuels: In KSP there is a single fuel/oxidizer combination used for all liquid fueled engines; in real life there is a variety of fuels and oxidizers used with varying properties of density, specific impulse, storability, etc. While having more fuel options would increase realism, IMO it would just be adding realism for realism's sake while confronting new players with a bewildering set of options. (Though the LV-N should be able to run on LF, LFO, or monoprop, IMO)

- Unsaturable reaction wheels: IRL reaction wheels can only supply so much torque in a given direction before they reach their saturation point and can spin no faster. KSP reaction wheels are not saturable so they can do some unrealistic things, like hold a lander upright on one offset landing leg or power a spinning helicopter-style craft. However, managing and canceling torque saturation would add another layer of ship management for little gameplay benefit, IMO.

Link to comment
Share on other sites

Regarding the Isp scaling in atmosphere, Isp in KSP is an accurate representation of specific impulse, it's just how the rocket behaves in atmosphere that is different from how real rockets work. The math used is correct if you imagine all engines use an automatic thrust limiter that limits engine thrust to the value at Kerbin sea level. I would prefer that it scaled thrust rather than fuel flow as real rockets do (why limit the thrust if it doesn't damage the rocket?), but it's not accurate to say that Isp in KSP is not a good analog of real-life Isp.

Show me one rocket that does it.

Then we can agree that "it's not accurate to say that Isp in KSP is not a good analog of real-life Isp". As far as I'm concerned - it is inaccurate and it is teaching people a wrong thing about Isp.

Change the thing to "efficiency" or something alike and noone will care. But if they use therm "Isp" - they should make it work like Isp works.

Link to comment
Share on other sites

Show me one rocket that does it.

Then we can agree that "it's not accurate to say that Isp in KSP is not a good analog of real-life Isp". As far as I'm concerned - it is inaccurate and it is teaching people a wrong thing about Isp.

Change the thing to "efficiency" or something alike and noone will care. But if they use therm "Isp" - they should make it work like Isp works.

The term Isp is being used correctly, is my point. It is specific impulse, the amount of force created per unit reaction mass. The math used in KSP calculates the reaction mass required to generate a given thrust correctly using Isp.

That there are no real life rockets that throttle their engines that way is true, but Isp is being used as specific impulse correctly in KSP (i.e. the amount of reaction mass to generate the thrust of the engine is correct). It is whether thrust or reaction mass flow rate changes with atmospheric pressure that is the issue, not whether Isp is being defined correctly.

Link to comment
Share on other sites

Thanks :)

I added "ADDITIONAL" additional section right after you posted quote of my post.

Wow if Devs implement all those ideas it would push KSP into 0.9 version for me.

For those people saying that Squad should just copy FAR or NEAR into stock; they can't without open sourcing KSP as a whole;

Both FAR and NEAR are GPL v3 licensed (the cancerous open source license), so unless ferram (the owner of the code and only person able to change the license it is released under) provides Squad with a different license they will have to implement new aerodynamics from scratch.

That is what choosing the wrong license can do.

GPL v3 is not cancerous Sir! It only protects your work from thieves.

Like you said author can always change license or add double license option, so I see zero problems with GPL.

Link to comment
Share on other sites

GPL v3 is not cancerous Sir! It only protects your work from thieves.

Like you said author can always change license or add double license option, so I see zero problems with GPL.

still doesn't change the fact that Squad can't use either without ferram's explicit permission

Link to comment
Share on other sites

Wow if Devs implement all those ideas it would push KSP into 0.9 version for me.

GPL v3 is not cancerous Sir! It only protects your work from thieves.

Like you said author can always change license or add double license option, so I see zero problems with GPL.

still doesn't change the fact that Squad can't use either without ferram's explicit permission

However they are free to use the same calculation, even reverse engineer the code as long as they don't obviously copy code.

Most games has a legal statement saying the game publisher owns all mods, this is done from two reasons, one is to avoid 3rd part commercial DLC, second is to avoid that someone create a mod then sue them as they use the same obvious feature in the next game.

Link to comment
Share on other sites

Regarding the Isp scaling in atmosphere, Isp in KSP is an accurate representation of specific impulse, it's just how the rocket behaves in atmosphere that is different from how real rockets work. The math used is correct if you imagine all engines use an automatic thrust limiter that limits engine thrust to the value at Kerbin sea level. I would prefer that it scaled thrust rather than fuel flow as real rockets do (why limit the thrust if it doesn't damage the rocket?), but it's not accurate to say that Isp in KSP is not a good analog of real-life Isp.

***

Shifting gears a bit, though I am a proponent of greater realism in KSP, there are some unrealistic simulation elements that I think shouldn't be made more realistic:

- Patched conics: N-body gravitation would be a more accurate representation of the real world and would allow playing with LaGrange points, but the patched conics model is a reasonable approximation (good enough to get us to the Moon IRL), is computationally less expensive, and permits stable parking orbits.

- Throttleable, restartable rocket engines: It is difficult to make a rocket engine throttleable in real life, so it is only rarely done. However, having a working throttle makes rockets easier to control and easier to make fine adjustments to the orbit with, so it's a good tradeoff. Same with restartable engines, they tend to be the exception rather than the rule IRL, especially for lifter engines, but they make handling rockets easier in game.

- Simplified fuels: In KSP there is a single fuel/oxidizer combination used for all liquid fueled engines; in real life there is a variety of fuels and oxidizers used with varying properties of density, specific impulse, storability, etc. While having more fuel options would increase realism, IMO it would just be adding realism for realism's sake while confronting new players with a bewildering set of options. (Though the LV-N should be able to run on LF, LFO, or monoprop, IMO)

- Unsaturable reaction wheels: IRL reaction wheels can only supply so much torque in a given direction before they reach their saturation point and can spin no faster. KSP reaction wheels are not saturable so they can do some unrealistic things, like hold a lander upright on one offset landing leg or power a spinning helicopter-style craft. However, managing and canceling torque saturation would add another layer of ship management for little gameplay benefit, IMO.

here I agree.

N-body is hard to calculate during high time warp, worse if you have lots of missions.

Engines, real world solution is to have lots of different engine types, same with fuel, again agree with the LV-N but it should not be able to run on oxidizer.

Reaction wheels, same here, they are also overpowered for better gameplay.

Link to comment
Share on other sites

However they are free to use the same calculation, even reverse engineer the code as long as they don't obviously copy code.

Most games has a legal statement saying the game publisher owns all mods, this is done from two reasons, one is to avoid 3rd part commercial DLC, second is to avoid that someone create a mod then sue them as they use the same obvious feature in the next game.

except neither the KSP EULA or ToS mention user-created addons/mods

Link to comment
Share on other sites

m4v: When have I ever said it was the only truth? Did I not specifically point out in the last thread that experiences will differ? All I tried to do with my post was point out, contrary to what you appeared to be arguing, that stock aero is not necessarily easier, or easy. Not that it's not easier for some people (say, you), but that it's not necessarily easier, or easy period.

People implicitly say so when they claim that is more intuitive and use it as an argument for change the aero model, otherwise why would be the point of arguing for a change that will affect everyone if it only makes things easier for some? Also I tried to explain why I think stock would be easier for most people, add an engine, some wings, check the alignment of the CoM and CoT and you're set, it will fly even if it looks like a brick. Meanwhile the other camp explanation is because.

The argument that a realistic model being more intuitive is bogus, people generally have an idea about how a plane looks and how they fly, but they know jack about what makes a plane flyable, ie how to design one. What TWR should you use? where should the CoL be? when too much wings is too much?. A realistic model doesn't make building planes intuitive, is just the same than stock with the difference that it railroads you into building stuff that looks aerodynamic.

Show me one rocket that does it.

Then we can agree that "it's not accurate to say that Isp in KSP is not a good analog of real-life Isp". As far as I'm concerned - it is inaccurate and it is teaching people a wrong thing about Isp.

Change the thing to "efficiency" or something alike and noone will care. But if they use therm "Isp" - they should make it work like Isp works.

Real life rockets neither can be restarted as often as KSP rockets can, then is KSP teaching wrong things about rockets? You have to draw the line somewhere, it will never teach the absolute truth. And it is more educational to have "Isp" rather than "efficiency", that way people know that when an enginer says the word Isp, roughly speaking he's talking about the rocket's efficiency, even though the exact concept of Isp isn't understood.

Edited by m4v
Link to comment
Share on other sites

ISP:

This makes little (almost no) difference as long as you just piece together rockets and see how far they go, so there's a whole class of players that won't be affected either way. The big pro would be that you don't learn false truths.

CON: Variable fuel consumption looks like something you could safely ignore while getting into the game. Variable thrust, however... well, everybody knows that thrust is vital in rocketry. Don't know about you, but as a newb I would have wanted to know everything that relates to thrust before I even placed my first rocket on the pad. Having variable thrust (and poking that into the player's face) would place KSP in the category of games where you need to figure things out before you even get started -- and difficult things at that: Math! PHYSICS! You're aware that there's a host of people who, on the sight o any formula, shake like a wet dog and turn away in disgust? And we're not talking about a sorry few. "I always sucked at math" is nothing anyone seems to be ashamed of.

It might look more scary than it really is, but I'm underwriting the philosophy that the game shouldn't look scary. If that requires one to take certain liberties, so be it.

Atmosphere:

KSP seems to have a big audience that enjoys impossible contraptions. Full-on realism would probably spoil the fun for them. But does it need to be as silly as it is? When I noticed that everything falls at the same speed no matter it's weight and volume, I was mildly put off.

generally

We are not the target audience. In terms of sales, the "just for lulz" types probably outnumber us five-to-one, at least.

Link to comment
Share on other sites

Well, a certain amount of abstraction is required. Making a spaceplane in the SPH isn't like creating a mod for MS Flight Simulator, nor should be.

I don't disagree, but saying that a certain takeoff protocol---military power used for military aircraft on takeoff rolls (usually fully loaded, or indeed "overloaded" with ordnance, etc)---should be true in a game where the engine that is on an F-16 might be stuck, unaltered, on a Cessna 152 makes little sense. In KSP, short of the game looking at maybe total mass and downrating the engine, the throttle is the per use control of the thrust. If you trebled the thrust of every RL jet out there right now, they'd have to change their TO procedure.

As a new player myself, I can say all the statements that stock is punishes expectations of reality are true. All my first rockets had nosecones, if I had not read the forums and see other designs, I'd have continued to assume that they were required. I'd have abandoned guys in space in lander cans for later capsule rescue before I would have reentered with them (the GAME tells me that they cannot survive reentry, after all).

Having just played a couple days modded, the only mod that I consider more difficult is life support. Yes, theoretically I can die on reentry now, but it has yet to happen to me, but then again my designs had the capsule separate anyway, because I thought it had to. LS is actually a difficulty modifier, OTOH, though only a little (I am using Snacks as I like the idea of abstracting LS to "man-days in space per unit LS." Snacks is so forgiving it has yet to be an issue in any mission, though I had one close call when my first Munar mission modded had Jeb in an eccentric Kerbin orbit and run out of fuel. Before I could rescue him, he had a Mun interaction that there it into a really crazy orbit that was hard to match, and I worried for his life… then a 2d Mun interaction put his perikerb at 15km, and luckily it was shallow enough that he could survive reentry.

I should add that rescuing Jeb became my critical mission, and it was pretty fun.

Edited by tater
Link to comment
Share on other sites

Having just played a couple days modded, the only mod that I consider more difficult is life support. Yes, theoretically I can die on reentry now, but it has yet to happen to me, but then again my designs had the capsule separate anyway, because I thought it had to. LS is actually a difficulty modifier, OTOH, though only a little (I am using Snacks as I like the idea of abstracting LS to "man-days in space per unit LS." Snacks is so forgiving it has yet to be an issue in any mission, though I had one close call when my first Munar mission modded had Jeb in an eccentric Kerbin orbit and run out of fuel. Before I could rescue him, he had a Mun interaction that there it into a really crazy orbit that was hard to match, and I worried for his life… then a 2d Mun interaction put his perikerb at 15km, and luckily it was shallow enough that he could survive reentry.

TAC-LS is also unrealistically forgiving, BTW. Stick a couple of small radial-mount parts on the side of your capsule and you can keep your Kerbals alive for years. The only real killer in TAC-LS is running out of electricity; that'll kill 'em within hours.

I don't think anyone has come up with a remotely challenging LS mod yet.

I should add that rescuing Jeb became my critical mission, and it was pretty fun.

With you on that. Emergency situations and desperate rescues are some of the best bits of KSP. We shouldn't be trying to discourage them. Half of the reason I have EVE installed is because I love popping out of the cloud bank on reentry only to discover that I'm face-to-face with a mountain. Tons o'fun.

Link to comment
Share on other sites

TAC-LS is also unrealistically forgiving, BTW. Stick a couple of small radial-mount parts on the side of your capsule and you can keep your Kerbals alive for years. The only real killer in TAC-LS is running out of electricity; that'll kill 'em within hours.

I don't think anyone has come up with a remotely challenging LS mod yet.

I think the challenge of life support only reveals itself in interplanetary travel. Mess up a transfer to Jool and need another orbit to fix it? Hope you brought a couple years' worth of extra snacks. It also encourages higher-energy non-optimal transfers, which can make the interplanetary gameplay a different balancing act than we have now.

When travelling around the Kerbin system it's basically a non-issue, travel times are so short that mistakes hardly matter.

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...