OHara

KAC does automatically set an alarm for each maneuver. It has layers upon layers of features and options. Color-coding maneuvers that are closely-spaced in time, or (nearly) overdue, does seem helpful, without adding any complication to the user interface. 15 minutes seems reasonable. In general, reading Snark's thread linked above, and the one about the mod he wrote, might be interesting for you (if you haven't already); Snark answers a lot of questions here, so probably has a good idea of what user-interface in this game has worked well (or not) for most people. I wondered if you could fit the 3 sort-select buttons above the tracked objects list, just to the right of "Tracked objects:" While a newly-tracked object does appear at the bottom of the list, even if filtered by MNV, it disappears if we select other sort-option buttons. Exiting/re-entering the tracking station restores this newly-tracked object to the list (as if the list from which you sort is created upon entry to the tracking station).

The craft in Fourfa's kerbal-x link worked as expected for me in 1.1.3: contents have drag when doors are open, no drag when doors are closed, repeatably after repeated open/close I used the alt-F12 option to show drag in option menus, and roughly confirmed with steady-state airspeed. The small fuel tanks are very slightly longer than the cargo bay, so in the SPH it is very easy to connect the rear fuel tanks to the small ones inside the cargo bay, when aiming for the back node of the cargo bay. When I do that, the contents of the cargo bay have drag, and the bay itself has more drag from its unconnected tail. The things known to have unwanted drag inside closed cargo bays in 1.1.3 are wheels, landing legs, EVA kerbals, and kerbals in chairs.

That was a wobbly early-career SSTO using Whiplash and LV-Ns, in which I had the rolling problem you described and did the best I could to resolve it with aerodynamics. When the roll did wander off, I tried to make the plane 'Dutch roll' rather than spiral, so the roll didn't build up too quickly. That ship had no fuel lines; you probably had at least 1750 m/s of liquid fuel in the central tanks when you reached orbit! Your version-3 flies straight as an arrow. I experimented a bit to try to find what it was that helped. I tried moving the root part (using change root' in the SPH) and that made no difference. Mounting the wings to the tank in front of the cargo by made the problem worse. On the version with wings mounted to the cargo bay, opening/closing the cargo bay made no difference. Everything I have seen is consistent with wobbling joints being the cause of the wandering roll. Having fewer joints between the heavy engine and the wings makes the plane fly symmetrically.

I replaced Kerbal Alarm Clock with this much simpler mod, and it is working quite well. Vessel renaming (which you can do in the tracking station) has caused no problems so far. This is a minimal implementation of exactly what was requested in the thread linked below. It does not pause the game when maneuvers come close: it provides only the schedule, not the alarm clock. Later discussion in that thread asked for other selected events like closest-approaches to be considered in the sort, whereas ManeuverQueue sorts only maneuver times, but placing a zero-dv manuever node seems a fine way to select those other events.

Persistent roll, always in the same direction, seems to be cause by wings flexing asymmetrically, even if the design is nominally symmetric. Placing wings directly off the root central part has helped this for me (you seem to have done that already) and struts helped when I had heavy engines on the sides. After the persistent roll is reduced, though, there is still some residual error that makes the plane wander. Dihedral angle in the wings should bring the plane back to level. A v-tail converts roll into a yaw error, while leveling the plane, but worked well for me.

3-point takeoff. Place wheels carefully to be sure the are parallel. Bewing reduces friction on the front wheel, which reduces wheelbarrowing in nosewheel aircraft. (I just trim pitch up on the takeoff roll to get the weight off the nosewheel) Adjusting wheel parameters seems unlikely to help your tail-wheel aircraft, unless you are hitting one or the other suspension limit. There might be something else useful to you in this long thread: I had the benefit of starting with version 1.1.0, and starting aircraft with 1.1.2, so never used the old landing gear. You can try my lightest and heaviest tail-draggers that use the lightest landing gear if you like.

You can when you are about 90° from your Laythe encounter, during your half-orbit around Jool. You cannot significantly change the direction from which you enter Laythe's SoI, but you can adjust the position of your periapse with Laythe to be anywhere in a circle roughly perpendicular to your entry direction. In your picture, you show that your entry direction is very roughly perpendicular to your target orbit, so for this unlucky case you can't help much. The best would be to mid-course correct so your periapsis is hidden behind Laythe in the close-up view of Lathe that you show, so your periapsis is where you cross your target's orbit. Describing the same geometry another way, looking at Laythe from the point-of-view of your path entering its SoI, your target orbit is an ellipse; you can adjust your SoI entry location so your path crosses that apparent ellipse at the one of its two vertices (tightest-curvature points) that has your target moving generally away from you. That gets your angular momentum about Laythe aligned as well as it can be with your target's. For a circular target orbit like you have, that puts your periapsis with Laythe at your AN relative to your target, so you can capture-burn to leave a high apoapsis (near the DN) and correct inclination while moving slow-ish at the DN. Looks like the inclination will still be 60° but I don't see how to do better give where you are approaching from.

Try toggling the brakes on and off. If that doesn't work, try (re)setting control-from-here to whatever commands the rover. (And tell us which worked for you.)

Also try right-click and 'control-from-here' on the probe core that is oriented the same way as the active rocket engine, or shut down that engine and use the one oriented with your capsule instead.

I like the gradual unlocking of parts, because restricted choice forces creative solutions. The fact that we need to do something (collect science) with our limited tech before getting the next level makes a fun challenge. The need to remember to activate experiments is a bit un-fun, and there are suggestions to automate that. The silliness of carrying goo to biomes, and its disconnectedness to the technology that it unlocks, doesn't bother me too much, but it does lose my interest and makes it harder for me to remember the rules for collecting science. It looks like experienced players can set up the game to unlock the tech-tree with money and time, using tree toppler and setting part-unlock costs in the new-game options, but I haven't tried that yet. My best suggestion, which I've tried myself, to keep what we like about earning our way through the tech tree, is similar to an old suggestion 'actual R&D'. I kept track of how many science points, reputation stars, and 1000s of funds, I gained using parts on nodes I had recently unlocked, and when this totaled the science points required for the next node, I considered the predecessor node to be sufficiently established technology, and opened the next tech-node by mod-F12. (Book-keeping by hand was too tedious, and I was making up the rules as I went along, so I drifted to unlocking nodes when I felt I had gotten all I wanted out of the earlier tech.)

There was what seems to be a good design to solve this, in a mod for 0.23. It gave a way to transfer the SAS-controlled steering to the trim settings, so there is continuity when we release SAS. I don't see any current mod implementing it.

Alt-QEWASD are the set of keys to increment trim. By "for whatever modes" do you mean that you'd like a way in-flight to selectively apply trim to certain parts? Myself, I'm not dexterous enough with a mouse to select a control-surface in flight. (Maybe I have unusual habits as an airplane and sailplane pilot, changing trim very often in flight.) If you mean you'd like keys/sliders to trim individual parts in vehicle assembly (balancing the craft) we have the rotate-part tools, using either shift-QWEASD or the mouse, to adjust the center-orientations for control surfaces and thrust. There are suggested ways to improve the rotation tools in general. Assuming the elevator is rotated in assembly so that neutral elevator gives best rate-of-climb, before takeoff I need to trim nose-up so it doesn't wheelbarrow, in flight I trim-out the tendency to roll right (even Val's designs do this a little) but I don't need the reaction wheels to help with any of this, and am always surprised when the space-plane rotates faster and faster when out of the atmosphere. I should have linked to a recent explanation from @Snark about how unexpected trim can confuse people. I'm suggesting that having reaction wheels ignore trim by default will make everybody happier.

I love trim for aerodynamic control surfaces, and for gimballing thrust on NASA-shuttle-like craft, but trim can be troublesome when used accidentally. (Trim being what we get with Alt-A,S,D,Q,W,E, Alt-X to turn it off) I suggest that trim should apply only to the 2 steering controls that are physically connected to the torques we typically 'trim out'. Aerodynamic control surfaces: apply trim, as it balances other aerodynamic forces, and lets us set for a desired AoA Swiveling thrust: apply trim, as it compensates for the misalignment of the nominal thrust vector with the CoM. Reaction wheels: ignore trim, any application of which seems to be done as well or better with SAS (true?) Reaction Control System (the little jets): ignore trim, as this is never desired to be applied continuously (true?) Rover-wheel Motors: apply trim, as people already use that Rover-wheel Steering: apply trim, only because it seems to do no harm For a space-plane with both control surfaces and reaction wheels, the control surfaces would be positioned according to the position of the control-input indicators, but the reaction wheels would torque only according to the difference between control-input (red) and trimmed position (green). Am I forgetting anything? I admit that I have used reaction-wheel trim to wrangle asteroids, but that exploits the unrealistic infinite angular-momentum capacity of KSP wheels, so I would not mind if that were less easy; trimming the thrust gimbals to the CoM, though, seems to be in the spirit of the game. Trimming for takeoff solves the fishtailing problem for me, and of course has all the other usual uses for flight, so I'd like to let more people use trim without worrying about forgetting to turn it off. This might be considered together with an earlier suggestion for a better UI and SAS-interactions for trim (from which I stole the image above). I saw discussion about a mod implementing some of this but I cannot find a live mod.

How much rotation and how fast? I had a satellite in a 7km--56km elliptical orbit, so I let it run over lunch, and saw only 0.1°/s per after a half-orbit (which is less than I would have expected just from tidal forces -- I'll have to make a tidal-force demonstrating satellite sometime). Ap and Pe do wander around, up to 300m, which is consistent with the dev-note descriptions of the effects of roundoff. I don't know where KSP might switch to surface-referenced coordinates on Minmus, but the time-warp limits are at 12km and 24km. (Note that the original post mentioned that trim was checked, and zero)

Good point. I was referring to the 9 parallel paths that branch almost immediately from the starting point. Dividing parts onto more paths should reduce, on average, the number of parts between any starting point and any desired part. Increasing the players power of choice was one of the mod author's stated goals, and I think he did so on average. I see now that on the stock tree (which I generally appreciate) you can reach nuclear engines, for example, skipping the probe rockets, researching large fuel tanks instead.

By having more branches, there are on average fewer un-interesting nodes between the player and what he want. Alternatively, there are more different configurations of tech that could be reached for a given investment, because there are more combinations of how far to go down each branch, than with a tree having fewer branches.

If I understand, you like the challenge of earning your way through the tech tree, but want to pick a different path than you took before. So at first I would think the tech tree linked in the first post would be a pretty good solution. The flatter tree would have fewer parts that are not relevant to your plan between you and the parts you want. Maybe it would remove too much challenge, though. Another way to interpret what you say, is that the vicious cycle, the parts you want requiring you to collect 'science' that in turn requires other parts that needs more science, forces us into a path of maximizing the science we can collect with given tech, and there are only a few optimum paths. This also troubled me, as the optimum path seemed to involve lots of 'biome-hopping', so I cheated my way through science points on my first career (after satisfying myself that I had done enough contracts/rescues/exploration with a given tech level). However, now I am noticing that I can get science points in the hundreds from unmanned interplanetary probes. Goo and thermometers and Science Jrs do work on unmanned probes.

I chose to start playing in career mode because there were too many choices of parts in sandbox. I have appreciated the way the stock tech-tree limits my attention. I trusted that the sometimes-strange grouping of parts would let me build what the developers found new players need to build, and have not been too frustrated. For my second career-mode game, the link at the top to pap1723's very logical tech-tree looks appealing. After playing with it a bit, I think it gives more overwhelming choice than I would have wanted on my first play-through. KSP seems to me exceptionally well-designed for configurability and expandability, with the tech-tree being defined in one configuration file, so it is easy to imagine the stock game with an introductory tech-tree for the first play-through and another for experienced players. I do enjoy trying to find creative solutions with limited parts, and think that is generally the appeal of career mode. I guess that the top post's quote of Stephen Sondheim, "I need that shoe to have a child", refers to the game of collecting science points. There, I found the rules too silly to learn (measure temperature with a wheel touching each KSP building) and chose not to participate. When I am satisfied with my achievements with a given technology, I defy the witch and alt-F12-cheat the next node. If the implication is that we would earn each node in pap1723's tech tree by doing specifically related activities, testing ladders to get better ladders, for example, then I don't think researching specific parts makes a space-program game more enjoyable. Any successful use of a ladder by the space program, to earn money, fame, or science, gives feedback and incentive to the manufacturers of ladders to design a better ladder. And, successful uses of limited parts is the fun part of the challenge.

Usually, Kerbin is outside of Eve's orbital plane (and thus Eve's equatorial plane which is the same in KSP) so your starting point is outside the target plane. So you will have some time traveling into that plane before you can turn to match it. In order to arrive at your destination, and also be moving in your desired direction, you need some mid-course correction. Opinions on what is most elegant will differ, but I think you might like to leave Kerbin on a path that will pass over Eve's north pole, just far enough above that an AN mark appears a bit before the close-approach, and turn at the AN into Eve's plane (along the lines of what f.m.m suggested).

I (like everyone else, it seems) like the top-post's suggestion to have being present on the ground count as much as flag planting. According to the community wiki, http://wiki.kerbalspaceprogram.com/wiki/Experience, the difference between landing on a body and planting a flag is very small: 0.2 times some multiplier on the order of 5, compared with 16 needed to get to level 3. So I would be tempted to skip it, but worry I would end up one XP short. I don't see any way to make landing the same value as flag-planting, or otherwise remove the bonus from planting a flag, in any configuration files. The best I can think of is to edit the save file occasionally and substitute s/ExitVessel,/PlantFlag,/

In the low gravity of Minmus, pushing and rolling and dragging all work fine That is the place to experiment and make mistakes, because there is so much you can get away with.

The type of maths needed are just the fractional powers in Kepler's third law cited above -- for figuring angles in the one orbit that is circular after a whole number of circuits of the other orbit, because angles in the circular orbit advance uniformly in time. The periods of the orbits T1 and T2 follow T2 / T1 = [(Ap2 + Pe2) / (Ap1 + Pe1)] ^ (3/2) You wanted to catch up 10° in one cycle of a modified orbit, so you want to adjust T2 = T1 + (10°/360°)T1 T2/T1 = 370°/360°; (370/360)^(2/3) = 1.018; Ap2 + Pe2 = 1.018×(Ap1 + Pe1) So if Ap1=Ap2 = 700km (100km above sea level) we want Pe2 + 700km = 1.018×(700km + 700km) => Pe2 = 726km (126km above sealevel)

The interesting bit that makes issue #1 not so easy, is that for general 3D bodies, torque along one direction causes rotation about a different axis. Some axes of the body have higher moments of inertia than others, so a torque between these principal axes cause a rotation about an axis closer to the easier one. (The concept is the 'tensor of inertia' but I can't find a link with a helpful illustration) The physics classroom demonstration showing why this is more interesting than you might think, is to take a book and tape it shut. You can toss it like a pizza so it rotates like an airplane in a flat spin. You can toss it so it rotates along its longest axis of near-symmetry, probably up and down the printed pages. But if you try to toss it along its mid-length axis of symmetry, it refuses to cooperate and tumbles in some messy way. I'm not sure if that's the main cause of SAS's roundabout path, but so far it looks plausible.

Fine control mode reduces the thrust of each RCS block by a different amount, in a way that reduces the unwanted torque quite a lot, for a given amount of linear acceleration. For long skinny rockets with RCS blocks spread along its long axis, fine-control mode works great. For short squat rockets it doesn't get the ratios close enough to correct to be really helpful, but doesn't hurt.

Every time I play KSP now I notice more about intersections. I'll just say what I notice and trust taniwha to ignore anything that's only distraction. In some (possibly trivial) cases the closest approach tells us how to get closer: mid-course corrections. Point in the direction from cyan marker indicating the vessel to that for the target, and burn a dV of closest-approach-distance / time-until-closest-approach. That is the minimum-dV burn from first-order perturbation-theory, so it is inaccurate to the extent that changing the vessel path changes the gravitational field that the vessel flies through, so it is useful when there is less than about 1/4 orbit around anything between me and my goal. I meant literally rotating the vessel orbit in 3D space, with no change in its shape, leaving one focus on the sun (or whatever body we are orbiting) as one would do with a burn perpendicular to the orbital plane. Then there are no more than two intersections and the solution is easy (thanks to the nice people who developed algorithms for arcsine and such). I agree that projecting orbits onto the same plane after rotation can move the foci as you say, open up the possibility of four intersections, and I see no analytic solution for those intersections. Those ranges, I guess, are in the two-dimensional space comprising pairs of positions, one along each of the two orbits. Some but not all the closest approaches (*s in my figure) will be in those ranges. I plotted the curves where each orbit's tangent is perpendicular to the separation of points on the two orbits (the other condition you mentioned) and see 9 places where both tangnts are perpendicular to the separation, three of which are local closest approaches. I was thinking that the SoI search would be a 1-D search of positions as a function of time. It is possible that the code tried to avoid computing a lot of orbital positions at given times (inverting the Kepler equation) in favor of finding the positions first, and then working out the times (the easier forward Kepler equation). I guess you have BSP sorting through the pairs of positions on the two orbits to find the subset that are within the SoI radius of each other. I don't see how that can be extended to find all (up to four) local minima, but I'm pretty sure that out of those (up to four) minima we want to see the ones that correspond to potential (after doing things like normal burns) actual intersections.