OHara

Nothing exactly like in the VAB but 1) you can "Aim camera" from the right--click menu so that the camera is centered on that part; select again to toggle back to centering the view on the CoM 2) you can pan the camera aiming with hold-middle-mouse-button and drag, then a double-middle-click resets the aiming to the CoM or the part chosen as above (see KSPedia under mouse controls). I guess the first one will be more useful for what you want --- and hope someone else knows an even easier way.

That is a complicated question because KSP lets you choose where the game goes. On Windows, by default you probably have KSP at c:/KSP_WIN64. If you have a slow internet connection, you get the patcher, like KSPx64-Patch-1.9.0-To-1.9.1.exe, let your browser put that .exe-file it wherever the default location is, run that .exe-file, which will then ask you where your KSP is installed (probably c:\KSP_WIN64). If you have a fast internet connection, it is easiest to get KSPInstallerx64-1.9.1.exe, run it, and accept the default directory. When I download a new version I make a new directory c:/KSP191, install the new KSP there, copy my settings .cfg from the old version to the new one, and maybe delete the old directory after I'm sure I like the new version.

I'll link here from the suggestions thread

Is the image at right, with a fairing turned upside down, what you are suggesting? Or do you mean a fairing open on both sides (somewhat like the part called 'Structural Tube') ? It is tricky to put the decoupler on the correct 'interstage node' of the fairing. There is also a bug that makes this kind of fairing hold on to the detached stage until we quicksave/quickload (or switch to another craft and back) -- or we can avoid the bug by making the root part something in the booster section. KSPs rules for drag do count the fairing as open if it is open at one end; and people do trick KSP into thinking the fairing is closed for purposes of drag, but open for purposes of the engine thrust, but I don't think that has any effect on your suggestion.

Just confirming that there is one case were root part matters, as @Lt_Duckweed said. It has been a bug since the beginning of the aerodynamics from 1.05 (tracker link, maybe related). If the root part is a fairing or cargo bay, after quickload or switching craft, the game treats that fairing or bay as open.

Not for air breathing engines, by convention. Not all the air is burned, and the proportion of unburned air that contributes as useful ejected propellant varies a lot. Isp is specified per mass (or weight) of stored fuel only, excluding the components from the atmosphere. You notice the Isp values are very large for high-bypass jet engines. I thought [edit: wrongly] that the Thermometer part ignored its own part-temperature, sensing instead ambient temperature (as if the sensing element was cleverly mounted like we mount static pressure sensors on aircraft)

I thought AFR was air-to-fuel ratio, so would appear as a simple ×AFR factor here, without the /(AFR+1). I see the cfg files have small numbers like area = 0.006 for the intake area, and that both you and the player who wrote the wiki figured this must be scaled by 100 to get a reasonable 0.6m² area. If I use this convention for area, and use the alt-F12 aero-GUI to find the density, I consistently figure the intake should provide 125% the airflow that the right-click menu says. Maybe that factor of 100 is supposed to be 80 ? For me, the discrepancy is a constant factor regardless of air density (see the image at right, for example). Maybe KSP does not figure density exactly the way you inferred from the wiki? It is possible that KSP adjusted the atmosphere-curves and nobody updated the wiki.

For me, in Flight screen and Map screen, the ring shader still acts as its code specifies : flat brightness depending on how much of the illuminated side we see of the constituent particles, plus low-angle scattering (specified as Mie scattering as if from sub-micron dust) that makes the sun look a bit diffuse when seen through the rings. In the Tracking Station, both effects act as if the sunlight were coming from a different direction than from the sun. This problem is new since Kopernicus with KSP version 1.7.3, and suggests that something changed with how KSP reports the position of the illumination in the various scenes. It's great to have this mod alive, @prestja. Kopernicus has grown lots of features. Hopefully the community can provide good pull requests to keep at least the core function working smoothly.

If I understand, you used the air-intake rates reported in the right-click menu on the air-intake parts, and found those reported intakes to be lower than (true_airspeed + v0_intake) × ρ × area. Everything you write makes sense (although I don't see where on the wiki you are referring to with U being not in kg/s) and I don't know of anything that KSP does that you left out. Realistically, we would expect a little less intake than that formula gives, as the bow wave of the craft pushes some air away before it is compressed into the air intake, but I don't think KSP simulates in that much detail. There is an option alt-F12 :: Physics :: Aero :: aero-GUI that shows you what numbers KSP is using for the craft in flight. Maybe that display will show where KSP is computing differently than you ? Maybe the local density ?

Welcome to the forum, @hellix08 I find that I need 4 of those large steerable fins (of which you have 2) very far back on the rocket, overhanging the main engine, to make your craft pleasant to fly. When I drop your boosters, I am still in the atmosphere, so I put those 4 fins fins on the main stack. I put them at 45° so they fit between boosters and launch clamps. It is the flat front surface of the Science Junior that is giving you a lot of drag in the front. Swapping the battery and probe core helps a tiny bit, because the larger probe core covers a bit more of the Science Junior. Putting things in a bay or fairing would help a lot, but big four fins in the back gets the job done. With those steerable fins you can fly a smooth turn using alt-D to bias the controls to the right (assuming of course that you leave SAS off) and then alt-X to re-center before you get into space. For the roll, I found that a couple EAS-4 struts from the nosecones to the main stack stopped the flexing and the roll. You might prefer those struts at the bottom of the boosters, and to move the separators up, so the separators push the noses of the boosters away upon release.

Just for reference, there is as you may know a mod that implements Alex Moon's calculations in the game, Transfer Window Planner (thread link) When I started playing KSP, I looked for the way to set maneuvers on craft in the Tracking Station, was surprised that there was no such ability. (Actually I was surprised that this ability was not in Mission Control.) If some variant of the Tracking Station did let us 1) set maneuver nodes, not just on craft but ... 2) also on dummy craft that we could place into orbit with some 'set orbit' dialog, and 3) advance the 'on-rails' orbits arbitrarily into the future without changing the game-clock, and 4) copy maneuver-nodes from the dummy craft onto our actual craft, then we could do our transfer-window planning using the in-game maneuver nodes.

That was an error with the upgrader, reported here (link) and since fixed. If you download the current version of the 1.9.0 -> 1.9.1 patcher from the KSP store, it should work. If you already have a patcher newer than 1 March 2020, and it doesn't work, you might need to download the full 1.9.1 That was for the KSP store; ask again if you use Valve's Steam system, and somebody who knows that system might know the solution.

Maybe so, but Kopernicus' success indicates that not too much had to be re-written in order to use configuration files for planets. Kopernicus' seems to do its main work at startup, replacing KSP's default solar system with whatever the configuration files specify, and then Kopernicus mostly stays out of the way. (Kopernicus now has many features, and some of them are active during gameplay, like its UI and maybe collisions for scattered rocks, but it lets KSP run planetary physics on the customized planets.) This gives some reason to think that Squad might find it feasible to incorporate some features of Kopernicus.

It sounds like a bug reported here (link) in which case a brief timewarp *before* you take off seems to prevent KSP from getting confused into thinking you are 'landed' while moving.

I think no. It has been suggested to Squad on the bug-tracker (here) where often players post their workarounds, but it seems that no-one has found a way. (Well, I suppose you could go into the file Squad/Experience/traits.cfg and change the EVAChuteSkill to level-6 and restart the game, so they never have chutes until you restore traits.cfg, but that would be overkill.)

You are correct to be surprised at the strength of gravity making a difference. The 'gravity' factor is due to convention about how rocket engines are specified, and is the gravity at the surface of Earth. In Physics, impulse would be in [Newtons×seconds] and specific impulse would be the impulse per mass of the propellant, in [Newtons×seconds/kg = m/s]. In rocket engineering, traditionally we divide by the weight of the propellant instead of the mass, which depends on the force of gravity where the rocket designers live. Under that tradition, we get a specific impulse in units of seconds, and have to multiply back in the value of 'gravity' at the location of the designers in order to use the number in a physics equation. KSP uses the traditional convention; then people can compare Isp in these units to real-world engines that they know.

Everlasting. I am one of the people who don't like career mode, but of course didn't know that until I tried it, so I've played one career game spanning the five years since version 1.0. Career mode starts very difficult for new players, then gradually gets easier. (One might prefer a game to start easy, while one is learning the mechanics, then get harder.) So when I was new I liberally used a Sandbox to design craft and learn how the game worked. The stock planetary scanning made no sense to me, so I adopted ScanSat very early as my only mod. I enabled new features from new KSP versions, like G-forces on Kerbals, and the radio network, as they became available. Now that save has plenty of money and a complete tech-tree, so I have effectively a sandbox, but a sandbox with a lot of character.

Yeah, that 'materials bay' that some contracts require frustrates every new player. Those contracts are really asking for the SC9001 Science Junior. The Science Junior just barely fits behind the heat shield, so that if you point exactly retrograde, in the 'Surface' frame of reference, the Science Jr. is protected. The Hitchhiker Storage Container is similarly difficult to re-enter. A related thing that was not obvious to me when I was a noob, was that any Kerbal can 'Collect Data' from the Science Jr., and take the data into the capsule, so we do not need to bring back the Science Jr. itself. Yet another thing that was not obvious to me, is that ablator does very little good. When we run out of ablator, the heat shield gets a little hotter, but it just radiates heat faster and comes to a steady state at a higher temperature. The heat shields must have some incredible insulation because their internals stay cool and sometimes conduct heat away from the rest of the craft. If you get curious, you can use the debug menu (alt-F12 on PC) under Physics::Thermal::Display_in_action_menus and see what KSP is thinking about heat. The signs of heat flux are + for flows that make the part hotter, − for flows that are removing heat.

It is awkward for everyone new to the forum to figure out how to put pictures somewhere like imgur and then past the link https://i.imgur.com/tDfB5nd.jpg (in the form with the .jpg ending) here. I'll post an example. That lander can extends beyond the heat shield that I guess you would have used, so the lander can gets some of the compression heating. KSP roughly realistically simulates which parts feel the shock heating, and how much. If you made a nice transfer from Eve, you would hit the atmosphere at 3600m/s, so if you can maneuver so your Pe is about 45km, and have no more mass than the can and heatshield, you can aero-capture on the first pass, then after one elliptical orbit you can aero-brake to land on the next pass. As everyone else said, just skimming the atmosphere at 55km to aero-capturing to orbit and then doing a rescue might be less frustrating and more fun. Squad made Kerbals immortal beings who need no food and sit happily in space for long periods of time, so we have the flexibility to rescue them later.

My thinking here is that 'x' is proportional to the angle of attack θ for small angles, as is sin θ. Wings can have a very flat drag bucket in Cd versus θ, or a parabolic θ² shape like the NACA airfoil you showed. KSP's physics.cfg has curves that look parabolic for small angles, and KSP uses sin θ as the independent variable here. I would expect other parts to also have drag that goes roughly as x² or θ² or sin²θ for small deviations from the cardinal directions. For large angles, a simple sin²θ is reasonable, is written very simply in terms of componenets, and transitions naturally into the drag for the other cardinal directions. The v-shaped drag curves we see for fuselage parts seems to be a mistake in KSP, which makes mk2 fuselages very draggy unless we fly them strictly prograde. I suppose you will need to replicate this mistake to write your optimizer -- unless the optimal ascents always have zero angle of attack.

No, you would expect the lift-induced drag to depend on wingspan, L-I-D = Lift² /Q /π /span² where Q is the dynamic pressure, but KSP does not consider the shapes of wings. It looks like KSP uses the total area of the wing parts as a quantity that scales as length². In a single wing area = chord × span, so if η = span/chord is the aspect ratio of that wing, then span² = η × area, so they could do L-I-D = Lift² /Q /π /η /area for some estimated η, and then they can figure this type of drag for each individual wing component. Experimentally, KSP does make this type of drag depend on Lift² and Q and total wing-area in this way. Looking at L-I-D in the aero gui, KSP acts as if η is a function of the mach number, going from about 5 at low speed down to about 1 at mach-1. I can't find any aspect-ratio-versus-mach curves in the configuration files, though. The induced drag is only noticeable at low speed, parasitic drag dominates when you fly faster, so I just say KSP uses an aspect ratio about 5 to estimate L-I-D whenever I might notice it.

KSP simulates body lift. There are additional lift vectors, in light blue, visible from the body of a rocket when you enable alt-F12->physics->aero->aeroGui. There is also a section 'name = bodyLift' in Physics.cfg. I never experimented to find exactly which parts have body lift applied, nor what surface-area is used. KSP does estimate the induced drag. You can see its value as 'L-I-D' (lift-induced drag) in the 'aero-Gui'. This appears to be proportional to the square of the total lift of the craft, so represents the energy lost to the wake of the whole craft. The amount of energy lost, and thus drag, depends on the wingspan of the craft, which KSP does not compute for any other reason. I remember concluding that KSP uses some approximation that is close to the theory for craft with wings with aspect ratio around 5. Surely Boots has induced drag in his Kerbal-Wind-Tunnel mod, so he must have computed it or found the API function that returns the KSP's computation.

The Physics.cfg has 'LIFTING_SURFACE_CURVES' that give lift for the airfoils that use ModuleLiftingSurface. The lift as a function of angle-of-attack is given by a table of 'key's and KSP interpolates between them with piece-wise cubic polynomials. The only relevant parameter for each part is the area of the wing, with the (inappropriate) name 'deflectionLiftCoeff' in each configuration file. There is an introductory post about the aerodynamics model here I posted my reverse-engineering about how drag of parts combine, to give KSP's approximation to drag of the whole craft, here KSP does this, but why did you expect a sine and not cos²(2°) and sin²(2°) ? I am wondering where KSP got that formula. The force on a face goes as the sine of the angle, yes, but there is another factor of the sine of the angle to take the component of that force in the direction that we call 'drag'. The drag goes as sine-squared of the angle giving a nice smooth curve (in real life, though not in KSP).

KSP is set up as a game to experiment by trial and error. And, the detailed math is awkward. But there are approximations you can do with secondary-school physics, if you want. If you are willing to accept (from some physics course) that the projectile height follows h = v×t − 0.5×g×t² as a function of time t after being thrown up at velocity v and then pulled down by gravity with acceleration g, then you can complete the square h = −0.5×g×(t − v/g)² + 0.5×v²/g and see that the peak height is 0.5×v²/g. So to reach h=200km you might expect to need an initial velocity v = sqrt(2×h×g) = sqrt(2 × 200'000m × 9.8m/s²) = 1980m/s. KSP since version 1.6 will estimate the delta-V of a rocket, so you might add fuel until it says 1980m/s, or maybe round 2000m/s, and see if that gets you close. There are several bad assumptions behind that approximation, but If you want to calculate, I would start with that approximation, and then maybe estimate corrections for the effects outlined in the post that @Streetwind linked to above.

Decline the contract to establish a base on Eve. The rocket-powered shuttles can barely make orbit from 7200m, so if there is no ore in either biomes 'peaks' or 'Olympus' those shuttles will not work. During the propeller-powered flight, could you not fly west and then turn east just before the rocket-powered portion? That might leave you within gliding distance of the base. Astrobond's SSTOs are simple constructions with no tricky adjustments, as are Kergarin's until the Breaking-Ground propellers that go in service bays -- as if to simulate an internal turbine with doors on the intake and thrust ports. My 2-stage craft clips through the cargo bay, shielding from drag just those parts lying inside the bay, which I rationalize as an accurate simulation of a form-fitting fairing. I know you know that clipping itself doesn't affect KSP's physics simulation (except of course as it should affect rotational momentum). The clipped craft at left has the same drag as the basic craft in the center, but the trickery at right has fooled KSP into thinking that all the parts are on the trailing end of the stack, with no parts feeling the force of leading-side airflow. So StratzenBlitz's artistic clipping has no effect on performance. Putting engines inside fairings/service bays that are open on the end gives you drag-free thrust (recursive_mouse raised this to an art-form here) and EverAlpaca does mention when he resorts to this trick. Probably we should always point out in challenges or on kerbalx (or in a you-tube if you do it that way) how we take advantage of KSP's physics engine, and what it did for us, so that new players don't worry that aesthetic clipping might be considered cheating, and don't stumble into exploits unless they want to.