OHara

It would follow, except for the bug (or sloppiness, or maybe needed simplification) that KSP does physics in the rotating frame of the planet, for everything inside the 'low orbit' altitude. So Foucault pendulums don't work on Kerbin (even if put far enough from the equator that they should). It bothered me that the left wing shows − lift while the right wing +, but presumably KSP uses just one model of the symmetric-shaped wings for each of left- and right-side wings in mirror symmetry, so the left wing might have its up/down coordinate inverted, but physically acts (roughly) symmetrically to the right wing. The magnitudes of the lift usually match to better than the 0.3% in the initial post; bad luck there. You can use alt-E to trim out the roll.

People would be very wise (as KSP players probably are) to read this and everything else in the Making History Discussion sub-forum before buying the expansion ... or decide like I did that they can spare US$15 and that supporting KSP under its new owner is a good thing to do. MH was disappointing, but I hope Take Two can see from player feedback which parts worked, and support better releases of KSP in the future. I'm going to the bug-tracker to enter one particular item of feedback now.

I made a bug report on the (self-service sign-up) bug tracker. Thanks for pointing out that the plates are useful if you ignore the warnings.

That bug, for me at least, is fixed in version 1.4.3 and the corresponding Making History. The perspective through the windows changes when I double-click, roughly consistent with what one would see by getting out of the seat. The small round windows on the Russian-style capsules, however, need a different perspective, as if we put our face against the glass, to give a useful field of view.

By 'multiple strategic branches' I understand you to mean multiple choices in what order to unlock the parts in a career. Splitting into many branches early, like the Historical Progression Tech Tree, gives more choices of which branch to advance at any point in a career. It happens that the author there used the word 'linear' to describe his tree, which does not at first sound like what you want, but the many parallel branches give a high-dimensional space of choice to the player. It is also easier to find the technology you want next in its grid organization. You might want to split your branches all the way down to the starting node, so that you have 12 parallel paths branch out immediately after the starting node, grouped by technology rather than intended application, with the early-node research costs reduced as there are fewer parts in each node. Then we can choose, for example, to develop aerodynamic recovery of upper rocket-stages using wings, without air-breathing engines or landing gear, or liquid fuel tanks (or even cockpits if I had chosen to build this with capsules).

Usually, KER will give a clue of the misunderstanding, by associating a large delta-V to stage S0 or whichever stage is running after the capsule is separated. That is, KER indicates that after dumping the dead weight of the capsule, the main rocket and its fuel tank can go pretty far. The screenshot in the top post, though, does not show the heat-shield-jettison in staging. With no capsule-separation staged, KER for KSP v1.3.1 calculates correctly for me as if the capsule stays attached for all engine burns. Based on the paint schemes, the top post is from KSP v1.4.x, so maybe the experimental KER for v1.4.x (recently adopted by new modder) has a new bug.

I built something really similar with the parts I could see. It got into orbit nicest if I flew about 10° above the horizon, picking up speed to 1200m/s below 10km, which might be faster than you have tried. All the suggestions above are good, but I saw no really big problems with your craft as I saw it .... but I saw only two rapiers, so... So some clipping is going on, and KSP estimates drag as if there were no clipping (which is nice for some aspects of KSP as a game, so that clipping is a purely cosmetic choice) so depending on what is clipped your plane might have the effect of exposed flat plates. This aspect of drag in KSP is not obvious at first, so if you remain frustrated you might put the craft on a share somewhere post a link to it. ..and you would be correct in flying with the cargo bays closed, so that their contents don't create drag. The cargo bays themselves can under some high-speed conditions show less drag when open than when closed (and some QA guys just can't let it go) but not enough counter the benefit of avoiding drag of their contents.

Kerbals in seats inside fairings or cargo bays are still exposed. That bug is still open.

Some of the adapters and nose cones look to be hollow, so players put batteries and small tanks in there, but KSP considers the small parts to be surface-attached to the outside of a part in the stack, so exposes them to the full airflow. The method of figuring what parts are enclosed in cargo bays is detailed enough to protect parts inside the hollows of the protecting parts, while leaving parts on their outer surface exposed to the airflow. We can apply it to whichever parts we choose with a module-manager patch: With this patch, parts on the end of a fuel tank can be shielded by a nose-cone. Parts attached to the wall of a nose cone, or hollow structural fuselage, can be rotated around their attachment point so as to be attached to the inside of the wall, or offset so their visual center is inside the fuselage, and they are shielded from drag. The shielded parts will show "cannot deploy while stowed" if they are parachutes or antennae or landing gear. (The visual center of retractable gear, and thus their stowed-ness, depends on whether they are extended when the physics loads, which makes it harder to test their function on a craft, so it is good that landing gear now have the 'Deploy Shielded' override.) Clipping parts into fuel tanks, and other non-hollow parts, remains purely cosmetic; drag remains. I suggest making this the default behavior.

I started to make a Module Manager patch, so that hollow-looking nosecones and adapters would act like always-closed cargo bays. I'll ask on the Add-Ons thread how to make it more general, after I remind myself what my questions were.

You are leaving much earlier than the transfer window, to an outer planet, so Kerbin has not yet caught up to Duna as much as it would be at the transfer window. To catch up to Duna, the transfer path has to swing closer to the sun than the Hohmann-transfer shape you would see at the window. The exit from Kerbin is not parallel to Kerbin's apth but dives toward the sun; the approach to Duna is parallel, though, since you picked the arrival time that minimized that burn. Sometimes the closest-approach markers give nonsense (bottom image). You know there is a closer approach further along the orbits, so If you add another maneuver node, with zero burn, further along in your orbit, you can force KSP to find the real approach.

The opposite approach would probably be more rewarding. Reach Minmus at its northernmost or southernmost points in its orbit, 90° from either nodal point. Then Minmus is moving in its equatorial plane relative to Kerbin, the craft is moving slowly relative to Kerbin, let the craft reach its apoapsis and wait for Minmus to come by. The biggest velocity involved is Minmus's 270m/s orbital velocity, which is the desired plane.

Well, Minmus is descending through the nodal point at its orbital velocity times sin 6°, about 30m/s, so to enter its SOI while staying above its equator you need to be moving down also at 30m/s. Transferring to Minmus' orbit, 24'000km from Kerbin, results in a rather slow velocity there, about 3000m/s × 700km /24000km = 85m/s since we have the same angular momentum as we did moving 3000m/s at 700km above Kerbin. So we need about 20° inclination in the orbit that leaves Kerbin so that 85m/s × sin 20° = 30m/s The transfer burn doesn't give much freedom to adjust the arrival orbit, so I adjusted the inclination before the transfer burn to tune the angle at which I arrived at Minmus. Leaving the final orbit quite loose around Minmus makes aiming easier, but I couldn't get lower than 2.4° before getting frustrated. I found the mods Precise Manuever and Better Burn-Time to be quite helpful here.

Yes, I saw this and started writing the table intending to make a simple bug-report saying "please un-reverse them". Then I realized why KerikBalm, and others, say the swapped stats are not much better, and that comparison to real engines is complicated.. The AJ10-137 certainly looks like a vacuum-optimized engine, as if trying to optimize Isp in vacuum. This real engine does the best it can with the long-storable, self-igniting, low-energy-density, hypergolic fuel it had to use. The J-2 gets its better stats mostly by burning cryogenically-stored liquid hydrogen. KSP treats all fuels the same, and give engines performance closer to that with hypergolic fuels. The engine masses do seem to be reversed, roughly. Also J-2 analog needs more thrust, as you mentioned earlier regarding how they are used in an Apollo Saturn-V replica. We still need to put something on the bug-tracker. Maybe a link to this thread is the best. https://bugs.kerbalspaceprogram.com/issues/19076 "some new-engines specs are out-liers in KSP"

I tried to follow the arguments that the stats are switched, but I do not see it. Generally, KSP engines are lower-TWR versions of the real engines that they look like: TWR, sealevel; Isp, sealevel 86, 60; 316s, 220s real RS-56-OSA 1.0tonne 14, 11; 320s, 250s KSP Swivel 1.5tonne 66, 54; 452s, 366s real RS-25 3.5tonne 25, 24; 315s, 295s KSP Vector 4.0tonne 2.6, 1.2; 850s, 380s real NERVA-2 2.5tonne 2.0, 0.5; 800s, 185s KSP Nerv 3.0tonne 33, n/a; 312s, n/a real AJ10-137 (Apollo SPS) 0.3tonne 15, 2.5; 412s, 70s KSP 1.4.2 Wolfhound 2.5tonne 70, 30; 420s, 200s real J-2 1.5tonne 31, 25; 330s, 265s KSP 1.4.2 Skiff 1.0tonne The Wolfhound has strangely high Isp; the Skiff has strangely high TWR (for a KSP engine). KerikBalm's suggestion above makes them fit the KSP pattern better, while keeping the Wolfhound strongly vacuum-optimized as its big bell suggests.

Cupcake (the guy who makes lots of small craft with Kerbals in fairings) reported this as a bug, https://bugs.kerbalspaceprogram.com/issues/18105, still waiting for confirmation so whoever has a simple craft demonstrating it could be the confirmer. The bug tracker uses a login, but of the style where each person signs himself up.

You probably saw above: send that Kerbal on at trip outside Kerbin's sphere of influence, on orbit of the Mun and landing on Minmus, and then return home, so he has 3 stars on his next flight. If you want to do the Vostok mission, though, you want to use EVA parachutes on your first flight. When you start a new career-mode game you can choose "Difficulty Options" -> "Advanced" -> "Enable Kerbal Experience" OFF; then all Kerbals will start at level 5, and have EVA parachutes on their first flight. In my installation of KSP ver 1.4.1, Kerbals with 1 star or more from old saves get EVA chutes; newly-hired Kerbals in version 1.4.1 do not get EVA chutes until they have 3 stars.

That is what the change-log says: * EVA Chute - Kerbals of Level 3 and above have a personal steerable chute And, that is how it works in my install of KSP version 1.4.1

The video shows a vertically launched MK2 craft reaching apoapsis of 137km in 1.3.1, but only 38km in 1.4.1. I tried the linked craft in 1.4.1, and reached an apoapsis of 159km, so whatever the problem is, does not affect my install.

Possibly your MK3 adapter is connected to the contents of the cargo bay, rather than the cargo bay itself? Yes, and it also says a lot of other stuff that makes it take longer to see your point. Nice rainbows, though. I see that the A.Cd values around 6m² are unusually high; I see 0.5m² on a similar fuselage that I built just now. Your MK3 adapter also has a high A.Cd, so maybe KSP does not think the adapter is connected cargo bay, in KSP's simplistic way of figuring which surfaces are exposed for purposes of figuring drag. Stuff inside cargo bays is still shielded from drag, so don't be bummed about that. Hopefully, you can re-check connections and everything will get better.

There have been suggestions to make a momentary button on each stage in the VAB staging display, to show the dry-craft mass and center-of-mass when the button is pressed (reducing the frustration of forgetting to refill our tanks when we check the dry craft manually). I can imagine that button populating your formula with the dry mass when pressed, and the wet mass when released. That spares the player the most error-prone and tedious part. Here, wet mass for a stage would be the mass after burning any fuel that engines activated in earlier stages can access, and after decoupling any parts that earlier stages decouple. Dry mass would be after burning all fuel reachable by any engine activated by the current stage. Simpler, and maybe general enough, would be to compute delta-V whenever the other quantities are committed, but compute wet mass when delta-V is entered.

Well, don't take me too seriously, because as you say I am just brainstorming ways to preserve what other people describe as part of their fun. Here I was imagining a player who wants nothing given to him that could otherwise be earned or discovered in-game. Measuring sea-level thrust is (objectively, I dare say) more fun than the early-career "test engine by staging" tasks. We can get starting and ending masses from the 'i' button on the Map View, and note the mission elapsed time between staging and when the craft just begins to lift off. I was a bit excited to go back to the VAB and see how far off the measurements were. fuel flow = (19040kg - 15580kg)/62s = 56kg/s thrust = 15580kg × 9.81m/s² = 153kN specific impulse = 153kN / 56kg/s = 2730m/s conventional Isp = 15580kg / 56kg/s = 278s Measuring the vacuum values, however, was awkward because I had to get the tested engine above the atmosphere. Full thrust would give too short a burn time to measure to precisely, so I set the thrust limiter to 10%, and tried to ignore the engine stats in that pop-up window. fuel flow = (3120kg - 2390kg) / 35s = 5.4kg/s at 10% throttle thrust = (3120kg + 2930kg)/2 × 200m/s /35s = 17.3kN at 10% throttle specific impulse = 17.3kN / 5.4kg/s = 3200 m/s conventional Isp = 3200m/s / g = 326s So we can measure engine stats in-game within a few percent accuracy, and there is no need to have them displayed in the VAB. People who don't want to see the numbers, though, seem to have no problem simply ignoring them.

One would not compute either, but rather find the answers experimentally. Players who enjoy the game by taking risks would build up KSP-intuition about the various engines can do. Players who build spread sheets would test each engine in turn, measuring thrust by testing engines with weights on the pad, and vacuum thrust with timed burns and maneuver nodes in orbit, and measuring fuel-flow with the in-game clock. Right now, the game abstracts away the experimental testing of parts, making the parts available with numerical specifications for thrust and Isp, but no in-game tools to use those numerical specifications. Presenting numbers in-game that cannot naturally be used in-game is what seemed confusing to me, in the sense that I cannot see what mode of play the presented information is meant to encourage. Computing delta-V from in-game information needs a calculator plus significant recording with pencil, or two abacuses (wet and dry masses) plus slide rule, or a spreadsheet. My implicit assumption, I suppose, is that computing is not the fun part for anyone, but that experimenting is the fun part for most people.

That brings up the counter-point of the thread, making sure players can easily and naturally avoid game-features that spoil their fun. I happen to think several features of KSP defeat the purpose of the game, in the sense of short-cutting the fun part. {auto-struts, instant-scanning for ore, crew that work for free, science from biomes at each KSC building} Most are easy to ignore, but I needed the mod ScanSat to replace the stock exploration, and had to get used to the bought-slaves model for crew. For the sake of new players, I would recommend a delta-V toggle-button be shown in the Engineers' Report. Then the first time a player has the concept of how many m/s he wants at a particular stage of a mission, the calculation is there for him to enable. I am guessing here that the players whose fun would be ruined by a numerical display of dV, would not go into the Engineer's Report looking for such numbers. Having the toggle default to off keeps the initial staging presentation simpler. Logically, the thrust and Isp for each engine would be hidden unless delta-V is displayed, simplifying those displays as well.

That is the right answer. Earlier I suggested using the higher thrust, between vacuum or sea-level atmospheric, so that air-breathers show non-zero. But, KER solves this problem better by having air-breathers always use its 'atmospheric' option. DMagic's Basic Delta-V, of course, has the best simple user interface for the options, including an easy way to turn off the display. Stock KSP shows, in the VAB hover-text for each engine, two values for thrust, vacuum and sea-level on Kerbin. The mods give us a way to get thrust on any celestial body, at any altitude, by evaluating the in-game atmospheric curves. Figuring the thrust in the atmosphere is helpful, for figuring thrust-to-weight on Eve's mountains, for which the only in-game alternative is to experiment with sacrificial landers.