OHara

That is interesting. The lego-style drag model was described, among other things, here (overhauls for 1.0). When neighbors are node-attached, each joining face its 'area' reduced by the 'area' of its mating part, for purposes of drag. So a 1.3m² circular face of a fuel tank is completely shielded by the 1.4m² area of a reaction wheel, while the leftover 0.1m² area of the reaction wheel is left exposed. The area of the entire silhouette of the part as seen from the staking direction counts as 'area'. I haven't looked into it, but suspect the fairings are treated as if the procedural fairing was node-attached to the plate. The 5-meter fairing has surface area 20.12m² on its largest face, 2.21m² on the others, according to my copy of PartDatabase.cfg, and this makes sense if it describes a 0.4-meter-thick base plate with 5.06-meter diameter (5.06m)² pi/4 = 20.12m². So maybe the slightly-over-5-meter fairing is enough to occlude the slightly-over-5-meter baseplate of that fairing. The pointy fairing has a low coefficient of drag Cd, (the drag force is area×Cd×density×v²/2) and the flat plate has the largest possible Cd =1 so hiding every last bit of fairing plate with the procedural part would be a net win. The alt-F12 menu lets you turn on "Display Aero data in Action Menus" which isn't very self-explanatory or documented, but might be useful to you.

I have been meaning to start a thread with the information I have collected on drag, which has changed a bit since Claw's introduction (thread link) and causing a lot of trouble due to mis-configurations in the newer parts. Making an example for this case is an easy first step

That is a new (since version 1.6.0) problem with the engines that got new models with open trusses mounting them to the tanks. When in line in a stack, with the shroud in place, the automatic generation of an aerodynamic model notices the open path through the truss, and reckons they block an effective area less than that of a solid cylinder. KSP thinks the wind can rush through the inside of the fairing and hit the separator behind hard. There's a thread here with links to a bug report with patches if you want to change this (to what I recommend Squad should do) with Module Manager (thread link -- I missed the Poodle but the same thing happens and I included it in the bug report.) For sharing your spaceplane, it seem the old Poodle model should work fine. It has no holes to fool KSPs aero model. They are still in the game as separate parts, just hidden in the default parts view in the VAB.

Usually, large drag comes from a mismatch between the sizes of parts along a stack. In KSP if one part has larger area, its mating surface surface gets drag proportional to the 'uncovered' area. What size of tank are your mounting the engine to? One variant of the Wolfhound matches the areas of a 2.5-m tank; the other variant matches a 1.25-m tank even though its bell is larger because the forward-facing bell has a low drag coefficient. The new Poodle, with twin bells and a truss mount, either leaves extra draggy area on a 2.5-m tank, or overhangs a 1.25-m tank. The old Poodle matches the 2.5-m tank (and you can find it in the VAB/SPH by selecting the 'Enable advanced mode' ||> button, then 'Filter by Module' then 'Engines'). The drag of the new models is confusing (thread link). I think the best thing to ask Squad to do here is make each engine act (for drag purposes) like a size-adapter, from a disk the size of its mount, to its bells

You can find the old textures in the VAB/SPH by slecting the 'Enable advanced mode' ||> button in the upper-left corner of the screen, then one of the categories other than the usual 'function' f(x). For example 'Filter by Module' then 'Engines'

That is a little different to the trouble the OP had. They had a persistent differences between their install and their friend's install. You do have the Terrier on your Eve craft, and that was the bug causing the OP difficulty. The new variant-model Terrier makes a more drag in a rocket stack than the old (thread link). Of the new variants, the 'shroud' variant is least bad if you have a game-generated PartDatabase.cfg, the 'bare' variant is least bad if you have PartDatabase.cfg from the KSP store zip file. Maybe you replaced the old Terrier with the new between your two trials? Otherwise, if you start a thread with a kerbalx link to the craft file, we can compare experiments.

This turned out to be not a mod problem after all, but a configuration problem with freshly-installed KSP. (Maybe not worth moving again, though, as google can help others find the solution here.) The solution was found via the reddit thread and is now reported on Squad's bug-tracker : Delete the PartDatabase.cfg and have KSP forced to generate it when it is started.

Yes. I think many of us did, when first starting to play KSP. I could not find this in Squad's 'feedback' tracker, so I added it: Suggestion: make planets and moons visible on approach New KSP players are likely to have seen Jupiter, Mars and Venus being quite brighter than the background stars, and to have known what they were seeing. It would be reasonable then, to look for the target body in flight-view, as one approaches it. It would also be rather fun to spot it from far away on approach. The surface of the target, however, at standard rendered brightness, is hard to see when only a couple pixels across. We depend on our dark-adapted eyes to spot Mars from Earth. We also depend on dark-adapted eyes to see the stars in real life, but the KSP skybox is visible at standard rendered brightness. The visible skybox is nice to help players keep their orientation, but those visible stars set the expectation to also see the target planet, for players who know how Mars stands out from the stars. For example, the mod 'distant object enhancement' has a DarkenSky operation to dim the skybox and adds a Flare to planets and craft.

With the first video up so far, it looks like a difference in drag, that begins when you cross the speed of sound. If you can upload your craft to kerbalx.com or dropbox and post a link here, I'm sure we will figure it out. There is one easy mistake -- connecting the tank below a cargo bay to some contents of the cargo bay rather than the cargo bay itself -- that happens to be treated rather unkindly by KSP's simplified model for aerodynamics, and gives this symptom.

The Engine-Plate collider is a disk-shaped mesh enclosing the plate, no collider for the shroud meant to go around the engines. You can use Collide-o-Scope to see them in-game. But, parts of the same craft are not supposed to collide with each other at all. I have seen a remotely similar problem with the SM-25 service module (bug report). Parts connected to parts that are connected to the SM-25 can, under unusual circumstances, erroneously 'collide' with the SM-25, often being ejected violently.

You will need to search the bug-tracker for 'cargo drag' and see if anything matches. They restored its visibility, whether you registered yourself to make reports or not. Some possibilities are #13366 (similar problem on reloading, if the cargo bay is the root part) and maybe #16993 (drag from parts that span cargo bays). Often the bug report tells you an easy way to avoid the problem.

Well too late for a close to lowest fuel opposition mission. If you are still before the transfer window, you could plot a course that gets you to Duna during Kerbin-Duna opposition, and see if the required craft seems interesting to you. The Hohmann transfer has you about midway between planets during opposition, so you'll need to go very roughly twice as fast to get there in roughly half the time --- and then capture in high orbit so you can time your escape from Duna to aim properly to get back.

We talked about that a while ago here:

Two possibilities spring to mind. 1) if you touch nose-wheel first, that pitches you up, and then the wings catch more air and bounce you up. Real aircraft do this and it can be very embarrassing. You have to slow down enough that you are pitched up enough that the main wheels touch before the nose wheel, but probably you knew that. 2) if you touch main-wheels first, and then the airplane pitches down, and then the nose-gear compresses fully, there is a bug (20682, some workarounds mentioned at the link) where the strut kicks back unrealistically hard.

1. Variant parts reverting to the old version is new to me. I hope you have version 1.6.1 because the .1 fixed some (different) problems with the part database; you can download 1.6.1 from KSP store or wherever you bought the game, as it replaced 1.6.0 around 10 January. Maybe someone else will recognize this. Maybe it will help if you spell it out: which part exactly and which variant ? 2. All of these problems with the delta-V readout are familiar to me. The implementation is not very good yet. At least the display is either correct or obviously wrong. It is a reasonable to continue to use the mod Kerbal Engineer Redux or the mod Basic Delta V until the main game repairs the bugs.

Your original thinking, @Laie, made sense to me. You want an LKO staging base for the usual reasons. You asteroid has more energy than it will in LKO -- specifically the extra energy-per-kg is 0.5(3200m/s)² - 0.5(2400m/s)². Each chunk of dV that you can manage lowers the specific energy by dV×Vorbital for the orbital speed Vorbital at the place you make it. Conservation of energy requires a particular sum of dV×Vorbital over all your (pieces of) burns to get where you want. So, if you lengthen your burns, continuing them through the arc where you orbital speed is at least half its value at PE, you loose some efficiency but it the extra cost in dV, and burn time, is less than a doubling. When I did this, I burned through 120° of arc each low orbit. 'Gate orbits' is a strange name (given by just their original proposer but not really explained) to the altitude that divides two cases of circular orbits. For a given interplanetary destination, is it better to (1) lower PE and burn from there, or (2) leave directly? Circular orbits above the gate-orbit altitude benefit from the step or lowering PE. There seems to be no reason to actually enter an orbit at the gate-orbit altitude. It is not a 'gate' in the sense of a doorway; it is a dividing line. Edit: Now I see. If you want a refueling center in circular orbit, for a given interplanetary destination, and you care mostly about minimizing dV needed after refueling, and you don't want to bother with the step of dropping PE, then the gate-orbit is a little better than other altitudes.

I honestly think that "trial-and-error with a lot of quicksaves" is a big part of how "some players accomplish the task with apparent ease". I think you know the bottom of capsules, with or without heat-shields, give significant lift, so you can use the magic reaction wheels to hold an orientation to steer your path. A very shallow approach, periapsis above 35km altitude, maybe even a few skips before final re-entry, gives you more opportunity to change your path Just one or two aero control surfaces can do a lot to let you control drag on the way down.

No. Traditionally we just post the resolution of the problem, whatever it is, as you did. I can imagine someone else will make the same mistake, search for "rcs not working," and be happy to read a reminder about hibernation.

Wind seems to have potential. It affects rockets only a little, but makes landing aircraft interesting, and we would quickly launch sailboats. KSP generally does not let random events affect game-play (KerbNet being the exception) presumably because the game is largely about rewarding good planning. Winds that change randomly might not fit for this reason, unless they are moderate enough and change regularly enough, so we can design to cope with wind, or wait it out. Maybe the meteors could be harmless if ignored, and have some benefit if you are actually looking for them -- like asteroids. KSP has the kind of axial tilt that creates seasons, rotation tilted relative to orbit. The hole at the pole of Moho is dark half the year. It's just that all the planets' and moons' rotation axes all need to be parallel to each other, so the variation in axial tilt between planets is all due to the variation in their inclinations.

I'm not sure I follow Bill's logic here with the part-count, but can understand wanting to use an SSTO. I assume that by SSTO to the Mun you mean a space-plane. (You could mean a rocket that gets to orbit in its first stage, literally a SingleStageToOrbit, then uses upper stages to go to the Mun.) Nuclear engines are probably smart, but you can use Terriers if you like, and still have 2500m/s deltaV in orbit.

This certainly looks like the file with translations (for English, in your case) was corrupted: GameData/Squad/Localizations/dictionary.cfg Most of your text comes through in English, and the text that fails tends to be entries toward the end of that file. You should be sure to try what the OP originally said they tried first: re-install or verify installation of the KSP files.

That is the resolution suggested in the bug-report 20683 (which is still awaiting confirmation by some other user) but I didn't see a way to implement it as a Module Manager patch. I'll steal your idea and if it works as expected put it on the tracker as an improved workaround. Edit: Having drag configurations that depend only on whether the shroud is present works great for the engines in the base game. But, several Making-History engines have different mount- and shroud-sizes depending on the variant. (The Cheetah can have either a 1.25-meter or 1.875-meter shroud.) I'll leave the more complicated Module-Manager patch on the bug-tracker because that hack resolves the problem in Foxster's thread as well.

Please post a craft file. Shrouds don't help in my craft.

You can still find the old Terrier using the 'Advanced Search' and/or see other workarounds in this thread

Too late, but 84 159.3 km is the 'closest approach' on a segment of orbit after you encounter the planet, and then escape its sphere of influence. 84 159.3 km is the radius of the sphere of influence of Kerbin. This is one situation where the right-click persistent display of a number is not helpful, because you need to watch if a different symbol appears for a periapsis, and then start making its number get smaller. (I remember an option "always show closest approach markers" that if turned off might make the 'closest approach' go away when the closest approach happens after an encounter and you presumably don't care about closest approach anymore.) Now that you have the periapsis distance displayed, you can watch it while you adjust the maneuver, and probably you will see the maneuver adjustments that you expected to work before (while watching 84 159.3km not change) actually do work.