OHara

I found a satisfactory eve shuttle design, using the advice here and on another thread (where I posted the shuttle) : There have been more single-stages to orbit from Eve's high point in the past months: @astrobond has posted a tiny 60-tonne single-Kerbal horizontal-takeoff single-stage orbiter @recursive_mouse has posted a very dense 520-tonne single-Kerbal horizontal-takeoff orbiter using 6 Vectors and 2 LV-Ns thrusting while shielded from drag in a single MK2 cargo bay.

Soon after this thread started (not yet having found this thread) I started a similar thread, and got some good advice. I am happiest myself with a two-stage design (craft file) using horizontal takeoff and landing for the sake of control, especially for the landings. Fueled mass is 175 tonnes and TWR starts at 1.1 at Eve's high-point. I can hold an AoA around 3° and gradually transition to vertical. I take off heading west, then rotate just past vertical to exit the atmosphere, so that the first-stage re-enters not too far east of the high-point, within gliding distance for landing, without needing to save any fuel for boost-back. The second stage then needs to provide essentially all the orbital speed to circularize, but it can do so with 2--4 G acceleration before the first stage gets too deep in the atmosphere, so I can switch back to land the first stage, without any stage-recovery mods. The orbital stage took its canard with it, so the booster stage is left with wings further back, closer to its unfueled CoM. When it is time for the orbital stage to return to the surface, it has wing-strakes forming a feathered tail and deployable control surfaces for drag, all of which were shielded in the cargo ramp during ascent. For re-docking, both craft point slightly uphill, the orbiter rolls into the cargo ramp, and then the lifter gulps it down, like a pelican swallowing a fish. The module-manager patch to enable angle-snap on docking ports is very helpful to make the joined craft fly straight. After docking, the cargo ramp can close around the orbiter, shielding its tail feathers and engine from drag during the next ascent, but leaving its nose and canard active (and causing drag, which is only fair). I am happy to imagine this is some custom fairing that the Kerbals can fit while they are preparing the craft for flight. Not that I'm finally happy with the shuttle in 'the simulator' (hyperedit) I can time-warp to the transfer window and send the full expedition.

.. by default after assembly in the VAB, and the nav-ball and controls are oriented so that pulling up rotates the nose toward the Crew Hatch. Now that you mention it, the crew hatch is on the pulling-up side for all command pods (except the MK1 cockpit, but the canopy makes its orientation obvious). Most pods have the crew facing forward and their heads to the crew hatch. The two standard lander cans consistently lean the pilot forward, away from the crew hatch to look out the window. Then pulling up or the 's' key turn the craft in the direction of the pilot looking up. The new KV1 'Onion' also follows this convention; the hatch is not so obvious, but the VZOR orientation window between the pilots feet is easy to find (and the ejection seat hatch is naturally on the opposite side). From that point of view, the KV2 and KV3 are oriented just fine, only the Kerbals are seated sideways relative to the control stick, and presumably they do not eject out of the crew hatch. The Munar Excursinon Module has the pilots, looking out the windows, with their backs to their control sticks. So we just need to ignore the orientations of the Kerbals, and the windows on the M.E.M. The Kerbals are not flying the craft; the crew hatches are.

The shock of the stresses suddenly appearing on a quick-load causes wings to flex nearly twice as much as they would in steady flight. 1) alt-F12 cheat menu to select 'unbreakable joints', then F9 reload, then un-select 'unbreakable joints' 2) take the load off the wings momentarily for the quicksaves in the future -- pull up briefly then pitch down in a brief zero-G maneuver for the quicksave -- so you can F9 load without the need for 'unbreakable joints'

That is an unfortunate effect of a combination of features of KSP (each of which is nice on its own) when SAS is active on a complex craft. When you use the IVA view for a pod, the control-from-here point is changed to that pod (so the control inputs are aligned to that pod). The SAS tries to slow the rotation of control-from-here pod. The control torques are applied at the reaction wheels. Joints between parts flex. Large craft have wobbling resonances, where the control-from-here pod might be yawing right while the part of the craft housing the reaction wheel is rotating left. So by trying to slow a rotation to the right by commanding a turn left, the SAS is making the reaction wheel (already turning left) turn left even faster, and thus pumping up the wobble. You can solve the wobble by removing any link in that causal chain. I like turning SAS off.

SAS, when locked to prograde, does give you the rotation rate matched to your orbital period, as you want. The problem is that KSP's "on-rails" time-warp (the one you get by pressing '.' without the [alt] key) turns off the SAS (as MechBFP said) and suddenly stops the rotation of the ship. You are not the only person to want different behavior; someone made a mod Persistent Rotation to teach KSP to obey physics better and keep ships rotating during 'on-rails' time warp.

Tidal forces are just enough to get a long stick-shaped satellite to rotate as fast as the orbital period, within about half an orbit. It then takes a very long time for the swinging to damp down to one of the two stable orientations, pointing radially out or radially in, but the initial swinging starts fast enough that tidal forces are obvious. KSP applies the same gravity to all parts of any single craft, no different for the parts slightly closer or further to the planet, so it usually doesn't demonstrate tidal forces. If you let fuel tanks float loose in cargo bays, however, KSP separately applies local gravity to those tanks. A craft like this will be swung around by tidal forces. If you let it run with physics-on time-warp, it will start to tidally lock enough that one end is always pointing above the horizon. I cheated one into orbit, and decoupled the caged fuel tanks, just starting to cook dinner, and now it is swinging around, pointing just above the western horizon on the day side, pointing just above the eastern horizon on the night side of the orbit. On average, it is rotating as fast as it orbits, nav-ball always showing more sky than ground.

Even though physics is independent of motion through space (you cannot feel your velocity relative to any aether, only relative to other objects) experiments can measure absolute rotation. If you throw a ball forward from your satellite, it will not follow the curve of your orbit, but rather go straight relative to what were once called 'the fixed stars'. The path is at first surprising to anyone in a satellite that is keeping one face toward he parent body, and the apparent force causing the ball to deviate from orbit is called the 'Coriolis force'. (They call the Coriolis force a 'fictitious force' because it is a force that seems to be acting on moving object, to explain their motion when seen from a rotating point-of-view.) During your next orbital period, the ball loops around behind you in your orbit. Satellites often do show one face always to the parent body ('tidally locked') but physical experiments on such a satellite can notice this absolute rotation -- usually experiments involving moving momentum like the ring of a spinning gyroscope. People demonstrate the rotation of the Earth with the Foucault pendulum, which tries to swing in a plane stationary relative to the 'fixed stars', as closely as it can given the changing direction of gravity. Freely gimbaled gyroscopes on a spacecraft do hold orientation with respect to their starting orientation in space-time. In the language of 4D space-time, you cannot feel your orientation; neither absolute orientation in the space coordinates, nor your absolute velocity which is orientation in a space-time plane. You can feel your change in orientation; either rotation in space using gyroscopes, or acceleration which is rotation of your reference frame in a space-time plane. KSP has one big flaw in that it suddenly stops rotation during time-warp; at first we guessed you wanted the mod 'Persistent Rotation' that repairs that. It has a tiny flaw in that its gyroscopes hold orientation in a frame rotating with the planet rather than the fixed stars, if you are close to the planet.

At 1 solar radius from the surface, you see the flux you would expect to see when on the surface. Raxo's experiments are posted here Probably they wanted to allow us to do such things, but got confused between altitude above surface and radius from center, so I entered a bug report for this.

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.