OHara

KSP's stock aerodynamics figures forces on wing-parts depending on their angle of incidence to the airflow, and applies the forces at the locations of the wing parts, and that is accurate enough to reproduce spiral instability, its solution with dihedral, and Dutch roll (if you have too much roll stability). The picture at right shows an airplane that weakly recovers from a spiral. Too much dihedral can give it Dutch roll. I suspect you will see Dutch roll in a flying wing, and will need significant (static) vertical fins to make it pleasant to fly. Beware that the reaction wheels in KSP are very strong and built into nearly all cockpits, so you need either SAS off or reaction wheels disabled in order to see the aerodynamic stability. What stock KSP is missing, is interaction between wings --- so your elevons on a flying wing will act as if they are in the undisturbed airflow, not in the down-wash from the main wing.

I am convinced the changes were unintentional, because the are so inconsistent and make little physical sense. The Big-S delta-wing, from the example at the top of this thread, had a drag coefficient for flow from below of Cd = 0.96 in versions 1.2--1.7, which makes sense for a nearly flat plate, but Cd = 0.02 in version 1.80 so when we try to belly-flop it cuts through the air as well as a needle. The Terrier (v2) was modeled as 0.8-meters long in version 1.7, but 21.0 meters long in KSP 1.8.0 Even though it is a clear error, and easy for players to fix by pulling over the correct file from previous versions, Squad might be nervous about promising to have a solution soon. KSP has a system to automatically estimate, from the model of each part, for each direction of airflow, the facing area, degree of pointiness for Cd, and protrusion of the shape for shock heating. Squad could put the correct values in the configuration files for each Squad part, but will want to repair the automated system for mods. Part modders do not want to figure areas and drag coefficients. Rather harmless errors started to creep in to the automatic drag-estimator with the _v2 parts around version 1.5, as seen in the PartDatabase.cfg. Then in 1.7.0 the basic nose-cone was given Cd = 0.04 for flow from the left, but a reasonable Cd = 0.54 for flow from the right. So there might be a subtle bug in the shape-estimator.

It is worth trying them. KSP automatically added entries for the new parts, to the 'PartDatabase.cfg' that I copied from 1.7.3. One might expect the new parts to have errors in drag, but the ones I've checked seem fine.

In recent versions of KSP you can choose from the first main menu 'Settings' -> 'Graphics' -> 'Part Highlighter Brightness Factor' It is hard to know whether an old thread is still relevant, when you have a question, but it seems this one is not. You can, if you want, flag your own post to ask a moderator to split it off, so other people searching for the question find the modern solution.

That is not quite true. I had the mistaken impression that nuFAR divided parts into voxels, and used some computationally expensive technique to figure the airflow around the craft (maybe something like the vortex lattice method, I thought) making the CPU do the hard work. Looking into the code, I see that @ferram4 did the hard work of coding the engineering methods from the middle of the last century to figure aerodynamic forces from various measures of the aircraft shape. Body drag, lift from wings, interactions between wings, are all handled explicitly. It seems that each simple computation-heavy method misses some important aspects for some regimes of flight. What FAR shows us is that, with intricate code, simulating realistic aerodynamic forces, real-time in a game, is feasible. Star Theory might consider whether FAR's general approach for body drag will be simpler and easier to maintain than the rather complicated drag-cube method of KSP1, which is difficult to maintain (as KSP 1.8.0 shows). If you ever find you've figured everything out with rockets, airplanes in KSP are surprisingly fun, given that it was meant to be a rockets game. == Although some people say "what should we keep? Nothing!", I think we want to keep several things KSP1 that gets right: + Fins make a rocket fly straighter + Pointy things have less drag + Wing dihedral gives an airplane roll stability etc.

That video of Cupcake's Vulture inspired me to try flying it under FAR and stock KSP (version 1.3.1). The most obvious difference by far is stock KSP's greater the lift and drag coefficients at low speeds, making the air feel much more dense (point 9 above). Stock KSP uses a lift coefficient 5× that in FAR, making aerodynamic forces 5× stronger at any given speed. Stated in other ways, the Vulture can pull a 5-G maneuver at √5 times lower speed, or make turns 5× tighter, in stock compared to FAR. The next obvious difference follows from the same difference in physics: controls feel more effective at low-speed in stock, less effective at high speed -- where in FAR coarse action on the controls at high speed can rip the wings off. The Vulture has landing gear that retract into the nacelles, leaving nothing exposed. With FAR, when we try to extend them, FAR tells KSP that they are enclosed, so KSP says "cannot deploy while stowed". KSPs configuration files have become complex over the years, but they do let us change things pretty easily. It is easy to substitute more realistic lift and drag forces as a function of airspeed, and/or make the stall behavior less mild, if we ever want :

Many of the coefficients of drag in 'PartDatabase.cfg' , and a few of the part dimensions, seem to be clearly wrong in 1.8.0. If we delete that file, KSP regenerates it, but again with the wrong values. Those of us with a previous working installation can copy over the old 'PartDatabase.cfg', delete the line containing "version = ..." and that solves the 1.8.0 problems with aerodynamics and heat.

If you are using only RSS and SMURFF, you should have the complete set of parts from stock KSP (with some adjustments to their performance by SMURFF). I suspect you have some leftover configuration files, maybe from trying Realism Overhaul or something. Your GameData folder should have the subdirectories and files below. Any additional files, should only be mods that you know you want. Kopernicus/ : replaces the planets as KSP starts up ModularFlightIntegrator/ : used by Kopernicus RealSolarSystem/ : the configuration files to tell Kopernicus where the RSS planets are RSS-Textures/ : the images to tell KSP what the planets look like ModuleManager.x.x.x.dll : used by most mods, to cooperate regarding configuration files ModuleManager.* : some cache files made by ModuleManager, after it has run once SMURFF/ : a module-manager script to adjust dry masses of tanks and thrusts of engines Squad/ : the data-files that set up the stock game as created by Squad Playing the game, in sandbox, using RSS and SMURFF is somewhat harder than stock KSP. If you want that, I can imagine it might be hard in a fun way, for you.

That would be consistent with what Star Theory has said about a 'custom solution' for their binary planets. By "keeping the universe a bunch of one-body systems" I suppose you mean that all celestial bodies are 'on-rails' Keplerian orbits. The two planets in a binary system could also move 'on-rails' following their Kepler orbits around their barycenter. Then within a 'custom solution' SOI centered on that barycenter and enclosing both planets, craft are pulled by gravity from the two individual celestial bodies. KerikBalm and others discussed this possibility (among many other possibilities) on the first few pages of this thread. The restricted three-body problem requires numerical integration to find the path of a craft in SOIs with two celestial bodies, which could fit with the numerical integration Start Theory would need to handle craft under thrust during significant time-acceleration (and maybe also craft under thrust when not focused). The restricted three-body problem is also complex enough to simulate Lagrange points --- all five points for binary systems where one body is heavier enough to create five --- for people who want that. Systems that are not interesting enough to warrant the 'custom solution' can get a separate SOI around celestial body, so we can have the stable on-rails orbits when N-body physics would be a mere annoyance.

Jumping landing gear was a common problem in KSP version 1.3.1, and Whale_2 made a mod to work around it The problem is much reduced since version 1.4. Some people say the mod above still helps, but I cannot confirm that; you can read the thread and see if you want to try it Another workarounds are to turn off 'Spring/Damper:auto' setting on the landing gear that have it, after first enabling 'Advanced Tweakables' in the in-flight 'Settings' menu that you get with the 'Esc' key, and then reduce the 'spring strength'. A more direct workaround is to retract landing gear and rest craft directly on the ground.

KSP1 supports the behavior of a variable burn-rate as an SRB burns through its fuel, so if that detail carries over in the re-implementation for KSP2, that increases the chances of getting what you want. Even now, it is possible that someone has made a KSP1 mod that lets you select variant SRB profiles, and some players write config files to customize the stock SRBs to their liking: https://forum.kerbalspaceprogram.com/index.php?/topic/142626-srb-thrust-curves/ https://forum.kerbalspaceprogram.com/index.php?/topic/138654-how-to-do-thrust-curves-in-stock-ksp/

I agree that many of us will need the function of Module Manager. The hope expressed above (I think that is a reasonable hope.) is that Star Theory do build that function into the base game.

The mod FAR did show that simulating airflow around [analyzing the shape of] the whole craft is feasible, and I would like to see that in KSP2, but that is not the current plan : Maybe we can argue that a rockets game should get proper aerodynamics treatment, but if that argument fails, there are some complications in the current KSP aerodynamics that would be better left out, making a simpler and easier-to-understand KSP2. In my opinon... 0) I think having drag on each part is fine. The need to balance attachments to our rockets against their drag is good for the game. KSP1 automatically figures drag of other parts from their models (specifically their colliders) and this is where things go wrong: new parts have models or custom drag data that does not meet the expectations of the KSP1 system. (FAR had a bug in this class that was exposed by the ReStock mod, so it happens to the best of us.) If KSP2 documents, at least internally, the way the aero system interprets the model and configuration of parts, that should help. 1) Removing drag of covered faces is the lowest-order approximation of whole-body aerodynamics, so in absence of other offers I'll take it. [Edit: after further thought and reading others' comments, I very much hope for a better offer, that uses the shape of the assembled craft to figure aero forces.] 2) I like offset-independence, not having to worry about exactly where I place my surface-attach parts on a spaceplane, although when I first started I did try to tuck RCS thrusters in low-flow areas, not knowing that it made no difference in KSP's model. [Edit: after further thought, since most people expect that offsetting parts to make a smoothed craft would reduce drag, better if KSP 2 follows that expectation.] 3) KSP1 has enough realism to demonstrate how the rotation of airfoils affects stability; it shows the effect of wing dihedral, for example. I like that. One can cheat the current system, by rotating nose-cones backwards, for example, but I don't think that loophole alone is enough to warrant a more complex system. 4) Players expect that tucking things inside hollow-looking parts will remove drag, and protect from heat. I recommend applying the protection of cargo bays to all hollow-looking parts, maybe with a note in their descriptions to confirm which are hollow. 5) The rule that such protected things are forbidden from interacting with the outside world, seems an un-necessary complication, in hindsight. Drop "cannot deploy while stowed" 6) I think a more realistic stall behaviour would be fun, and make aircraft more interesting, while not affecting high-powered spaceplanes and fighter replicas very much. KSP1 can do that with 'lifting_surfaces_curves::lifting_surface::lift,drag' and it won't affect rockets because their angle of attach remains low. [Edit: FAR has differently unusual stall behaviour that some players would change, if it were configurable] 7) Skin drag is small enough that it can depend only on the side area of the part, without a coefficient depending on the shape of the part --- certainly it should not use the same drag coefficient Cd as the face would have if facing the airflow. 8) The configuration value 'drag_tip' should apply to faces according cos² (dot-product squared) of their face relative to the airflow. I do not think Mk2 spaceplanes were made draggy on purpose, or intended to force us to put an angle of incidence on our wings, nor that rockets were intended to suffer drag so severely when we deviate from prograde. 9) Having the coefficient of lift increase with low speeds was a clever idea to enable players to make light aircraft and spaceplanes with the same set of parts. Sometimes people will say the air 'feels thick' when landing but mostly this enabling trick seems not to bother players.

Yes, I see the same problem with a 'bicoupler' engine mount instead of the parts from Making History. Someone else has reported this as a bug here, https://bugs.kerbalspaceprogram.com/issues/20740, but your example is easier to understand, so I attached it to that bug. I don't know of any workarounds, either, but the mods that compute delta-V (Basic Delta-V, Kerbal Engineering Redux) get this right.

StarTheory plan for KSP2 to have aerodynamics very similar to that in KSP1 That system uses several rules---some of which may have helped to make a good game---and not all of them will carry over into a fresh implementation. 0) Each part feels aerodynamic forces as if it was moving through the air alone... Struts have zero drag, but all other parts have aerodynamic forces applied. 1) Except, KSP1 reduces the forces on each face that is node-attached to another part, to the extent that the attached part covers that face. The need to explicitly define the 'covering area' for tube-like parts has tripped up many mods, including Making History. 2) Offsetting a part does not change the size of the aerodynamic forces on the part (but the point where those forces are applied to the whole craft does move with the part). Clipping, offsetting parts inside other parts, is purely aesthetic 3) Rotating a part does change the aerodynamic forces. We can set angles of incidence on wings, and on SRB-fins, to give the desired effect We can rotate nose-cones 180° and avoid the leading-face drag in favor of the much lower trailing-face drag 4) Except, any part inside a closed container feels zero aerodynamic forces, (and only parts in the 'Payload' section in the VAB count as containers). The definition of 'inside' is reasonably sophisticated and is rechecked when the container opens or closes There have always been one or two bugs where the checking goes wrong 5) Parachutes, thrusters, antennae, and landing gear do not function from inside a closed container ("cannot deploy while stowed"). We have an override ('deploy shielded') for landing gear 6) The forces on wings as a function of angle-of-attack give a very soft stall, that behavior being defined by custom curves in physics.cfg. 7) Skin drag, from faces of a part parallel to the airflow, use the same shape factor Cd as they would have when facing the airflow. This gives Mk2 cargo bays slightly lower drag when open, at high speed. 8) As the side-face of a (non-wing) part is tilted into the airflow, the force proportional to tilt angle is all counted as drag, where we expect drag proportional to sine-squared of the tilt angle from standard aerodynamics. An Mk2 spaceplane in KSP1 at 3° angle of attack feels sin3° = 5.2% (where one would expect only sin²3° = 0.3%) of the of bellyflop drag of its bottom surface. 9) The lift on wings as a function of Mach number, is higher at low speed, lower lift at high speed, compared to expectations from standard aerodynamics. A space-plane can easily have enough low-speed lift to glide near touchdown-speed the entire length of the runway. Links to threads for reference in spoiler: Now seems like a good time to discuss which of these have been good or bad for the game, in our experience with KSP1.

This sounds like a problem they had with the updater (see https://bugs.kerbalspaceprogram.com/issues/22734) The solution seems to be to get you the correct localization file for the base game. You can download the full zip version of KSP173, or maybe comment on that bug to let @ManeTI know there was a problem 1.7.0-to-1.7.3, because he thinks he's fixed the updater and is asking there for confirmation.

When you are controlling a craft with action-group sets, you should see a new button in flight-mode, above the delta-V button, that lets you switch sets. The keyboard commands (in default Windows keybindings) are F6 and F7 to switch forward and back through the sets.

It could mean (and I think it does mean) that metallic hydrogen---with its extremely high energy-density if you believe that Harvard paper---motivates Kerbals to develop magnetic nozzles so they can use its full potential exhaust-velocity without vaporizing their rocket nozzles. Then the magnetic nozzles and plasma confinement are ready to use with nuclear engines. At least we are on record saying that we hope that we can pick which parts in the tech-tree that we actually use on rockets (as we can choose in KSP1). Yes, at least I understood that to be his suggestion. I could argue with the response; I think KSP could preserve the core game-play without the SOI approximation. But, I see how keeping the current SOI system is by far the safer choice for KSP2 from the developers point of view. Maybe the infrastructure for Rask-Rusk and the constant-acceleration under warp will enable a simpler restricted N-body mod. Although, the 'custom solution' for Rask/Rusk could be something simpler like the Sigma Binary mod, with the smaller body fully in the SOI of the larger, as if the smaller were a moon of the larger, and then the larger body orbiting the common barycenter, that barycenter having no SOI and existing only as a parent for the larger of Rask/Rusk for purposes of orbital parameters. Probably, the idea of the cesium is that it is easily ionized, so there will be plenty of Cs+ ions created in the hot the reaction chamber. Then these charged ions can be steered by magnetic fields to make a nozzle. The molecular hydrogen is not going to ionize much, even at 7000K. Somebody here who knows plasma physics might be able to explain how the Cs sheepdogs can herd those H2 sheep. I imagine this nozzle cannot hold much pressure of H2, so this might be a low-thrust engine. There is another area where KSP1 underestimates technology. The empty fuel tanks have several times more dry mass than one would expect, given their fuel capacity. This, and the strangely heavy engines, balance out the 1/10 solar system so the game is not too easy. Maybe the orbital construction facility could somehow avoid the need for such heavy fuel tanks, so that craft built there could have higher full/empty mass-ratio and thus greater dV, depending less on optimistic assumptions about near-future technology.

In the forum thread about SVE, you will probably find the common mistakes people have in setting things up. Maybe start looking at the end and then go backwards, until you find the most recent similar problem and solution. Also re-check the installation instructions first page.

You understand correctly. SAS does not control the axis groups. (Players have made a suggestion to change this https://bugs.kerbalspaceprogram.com/issues/22946)

KSP has a rule preventing us from deploying parachutes through a closed fairing. Usually, the hole at the bottom of your fairing after the rest of the rocket has detached would make it no longer 'closed' but a recent bug (https://bugs.kerbalspaceprogram.com/issues/21915) makes KSP fail to notice that kind of opening. If that bug is the cause of your problem, you can try the workarounds: + Quicksave / Quickload, then deploy the parachute, or + Deploy the fairing explicitly before the parachute, or + Choose another part, beneath the decoupler that opens the hole, as the 'root part' of the rocket. (None of these workarounds looks really convenient for your rocket.) If you want to change that rule in your game, and generally be able to deploy parachutes through fairings, you can edit the configuration files, or use a ModuleManager patch, something like @PART[*]:HAS[@MODULE[ModuleParachute]] { @MODULE[ModuleParachute] { %shieldedCanDeploy = true }}

There is more mention of new engines, and orbital mechanics in Rask-Rusk, in Scott Manley's interview of Nate Simpson here: https://www.youtube.com/watch?v=n-xM_e5x6oc Metallic hydrogen as rocket fuel does make the condensed-matter physicist in me cringe, so I'll just call it 'kerbolide' and get over it. There is an atmospheric engine that dilutes the 'kerbolide' with water to reduce the chamber temperature; and a vacuum engine that injects cesium, presumably for its low ionization energy so it makes a plasma, and a magnetic-field nozzle. I don't imagine anyone will force us to use them. Rask and Rusk get "a custom solution" for orbital mechanics. That would be some solution to the 'restricted three-body problem', where the craft are light enough that we can neglect their effect on motion of the planets. I think the only solutions involve numerical integration. This seems a small step from the restricted N-body problem of numerically integrating the trajectories of all craft, under the gravity of all the planets, leaving the planets themselves (unrealistically) on rails. Then we would get the interesting gameplay part of the Principia mod, the complex motion of the craft, without the instability of the Jool system. I see the concerns about station-keeping of satellites, but when I look at examples, the orbital drift is usually negligible, and if I am close to a moon then finding a resonant orbit seems like it could be interesting (as it was around Duna in the Snarkiverse mod). Constant acceleration of craft, during time warp and when we are flying other craft, sounds very nice. That, and Kerbals' tolerance for long journeys in space without food, should enable interplanetary travel with believable fusion propulsion. Accelerating at 1m/s² for 400 Kerbin days gets you to 3% c, so if the interstellar distances are scaled down to 10%, the trip is only few times as long as a trip to Eeloo in KSP1. I hope my suspension of disbelief can follow roughly the same pattern as it did in KSP1, with immortal Kerbals flying under mostly-real physics on a compact planet where 2-g acceleration gets us to orbit in 3 minutes, and with many engineering details abstracted away.

It sounds very much like a relatively recent bug, https://bugs.kerbalspaceprogram.com/issues/21915 If that is the problem causing you trouble, then the workarounds are: + After deploying the heat shield, right-click on the fairing and select 'Deploy' so that the fairing separates into pieces, or + Quicksave and quickload, F5/F9, or + If you are still working in the VAB, change the 'root part' to something below the heat-shield

I like being able to understand how other people make their craft, and recognizing the lego parts helps with that. Mostly, I like the removal of un-necessary choice -- the precise length and taper of a fuel tank, for example. What do you think of procedural parts where the sliders select between discrete values ? (Other people might call these 'variant' parts.) I could pick a fuel-tank and then stretch the diameter to 0.625 1.25 or 2.5 meters depending on what I need, rather than remember that 'Rokomax' is the name for 2.5-meter tanks so I can find it in the alphabetical list. Then I can configure it to be liquid-fuel-only, and let the paint-job-indication follow my choice, rather than needing to know and find that paint-job detail. Then I can select its length to select between the 100, 200, 400, or 800kg capacity. I could pick a wing panel and double its size until I have 40m², rather than know which size is wing-connector type-D. Then we can have our lego parts without so much searching though to box of lego to find the correct one.

KSP already allows the kind of axial tilt that gives you seasons. The entrance of the Mohole, for example, is in darkness over the Moho winter. But, all the planets' rotation axes are parallel; all the equators are aligned to the galactic plane in the skybox, which was helpful for orientation when I was a new player. With the constraint to have all the rotation axes parallel, the axial tilt of planets can only vary due to their orbits around the Sun being tilted, their inclinations, so none tilts more than a few degrees. The Real Solar System mod tilts the solar system, so that all planets have axial tilt near 23°. Venus is given a negative rotation rate to effect its near-180° axial tilt. I would hope that in KSP2 the nav-ball and default camera orientation, when inside a planet's SOI, orients to the poles of that body, so that polar orbit looks vertical on the nav-ball and camera. I also hope that axial tilt is used sparingly in KSP2. I think you might be remembering this one, with the nice picture by guigui30000. There are some good thoughts there about how to keep the initial game-play simple: the first launch site on Kerbin's equator, Mun's orbit in Kerbins' equatorial plane, etc.