Frederf

Can you explain how the new SAS does its math? "It holds a heading" "It's not an autopilot" how do you reconcile that contradiction? If it holds an attitude it's an attitude autopilot. What PID values does it use? How does it derive them? When are new attitude target values captured? What control surfaces does it use and when?

This is exactly what it is not. SAS is math that translates input numbers into output numbers to physical controls. It no more steers your craft than does a pocket calculator.

This is such a confusing issue. First, raise your hand if you know what the letters S.A.S. stand for. It's stability augmentation system. What does it mean to augment stability? Usually such systems are effectively dampers designed to suppress unwanted oscillations and not autopilots. Historically KSP SAS & ASAS were exactly autopilots which instantly starts everyone off on the wrong foot in terms of expectations. We've departed traditional vernacular at right angles already months ago. Previous versions were a motley collection of controls, control channels, and controllers. "SAS" parts were controllers only available to the control channel used by the "T" SAS controller. The manual controller actuated all available controls except the SAS torque which was reserved for hands off input. The ASAS simply expanded the set of controls that the SAS controller had available to it beyond pod torque and the exclusive SAS wheel parts. To top off the confusion you could have multiple controllers in operation simultaneously with manual control channels operating one set of controls and the automatic SAS channel(s) operating a partially overlapping set. What a mess! In any case all automatic inputs were effectively PID controlled. Things wobbled with any sort of automatic input because 1. the PID coefficients were terrible and 2. they were static. --- What does the new system do? Surely it is a PID contoller as well. My fear is that despite making "better coefficients" the PID factors are still static and thus unsuitable beyond some range of use cases. My hope would be that the PID coefficients would be autotuned if not outright fully configurable manually. Are the PID numbers autotuned or not? --- Ultimately the typical user will want both stability enhancement for maneuvers and autopilot functionality for non-maneuvers. Before we had A, it seems now we have B. Living without both available is going to be unsatisfactory.

Mainly for part count or drag/mass reasons. You also might want different locations as your CoM changes. rotpower or reaction wheels or whatever are still quite overpowered compared to their real counterparts so unless you need to dock you often don't need RCS at all. If all you need is translation then a simple 4 (even 3 or for the masochist 2 or 1) array of linear RCS ports is sufficient. Some landers probably benefit from full axis RCS arrays during critical phases of flight.

Maybe the node art is in error. Is the vector line angled too?

Ah, the classic misconception. You never leave the SOI with a greater/less speed than you entered it when the speed is measured relative to the body of interest which is the measurement that matters when considering capture.

It's been a great read so far and very impressive. My contribution is outmatched in the realm of numerical analysis but I think I have something of value. My thoughts turn to more practical matters like error analysis. Mission planning to the proverbial deltaV penny is foolish. I would be interested in sensitivities for +- time or speed for transfers in terms of corrections or even end game non-optimal captures. Knowing that +-10 seconds results in 200 dV would be invaluable for planning. Also often fuel minimization isn't the priority. Sometimes one has X dV and is interested in minimum time. This was touched on earlier. Lastly check values would be nice to verify that the maneuver is going well and what errors and how serious they are can be realized. One thought about timing parking orbit burns. Perhaps a 2-burn method is practical to synchronize Pe with impulse point. For example if one executes 20.524652 orbits between now and burn perhaps TOT could suggest the minimal parking orbit alteration to achieve exactly 20 or 21 orbits. Thus later when one wants to escape it just happens to be at the best point in the orbit.

Perhaps a return trip has a duration? Assuming 60km/hr or something? It's a good question. It's difficult to believe KSP would require extraordinary skill on the user to return too exactly to KSC.

Gravity capture around Kerbin by transgressing the Mun's SOI is possible. Gravity capture around the Mun is not. It's tempting to think it is possible in reference frames where the Mun is in motion but consider the Mun's reference frame. The space craft heads toward the Mun hyperbolically and escapes because gravity is a conservative force. The laws of physics reach the same conclusion no matter which reference frame is chosen. Of course if you introduce other types of forces or gravity from a complex system then all bets are off. The mechanics of capture have to include more than a 1-body gravity source for capture.

Imagine the gravity well of the Mun is a curved dish and your space craft a marble. If you introduce the marble along the edge it will roll to the bottom and come out the other side unless something slows it. It'll even come out with the identical speed as it was introduced (with respect to the Mun). It is theoretically possible with N-body gravitation because the dish isn't symmetrical and might change over time but not in KSP's 1-body gravitation.

It's probably the association with the time period but I imagine 1960s tract homes with sundress housewives and white shirt/black tie company men.

I apologize. However integrating a specific version of a shared library which is under development into your package does carry a risk of error and I thought you should be aware.

Not all keep the dll in the root but even so there's a problem of version. The mod can be older than others. The order I apply mods using JSGME can determine which .dll I end up. A mod with dll included installed after can lower/change the version and break a mod or undo a fix that worked before. When files overwrite each other like that JSGME unnecessarily considers them co-dependent which makes it a complete pain to use JSGME as intended. It's madness. Redistribute with does not mean distribute packaged within. It's just permission not suggested practice.

1. Imagine if every mod author did that. N copies of the .dll loaded with up to N different versions of it depending on which snapshot in time the modder grabbed. 2. The author of the .dll directly says not to.

Stop including ModuleManager.dll with your releases please!

It stops crossfeed of flowable resources across that docking port only. Global resources are unaffected. RCS thruster toggle you can add as an action grouping. RCS fuel you need to click the green play arrow to the red slashed circle every time as it isn't an action groupable feature. Often my RCS fuel is hidden deep in my craft so I can't get to it at launch. However I can transfer prior to separation. Any CoM imbalance that undesired RCS fuel usage produces is unavoidable.

I see. I'm reluctant to make analogies that aren't physical examples of what's being described. Telling someone "it's just like a fish pedaling a bicycle" when it's not is putting a stubborn roadblock in the road to future understanding no matter how convenient or feel-good it happens to be now. Understanding comes not from memorizing an outcome but seeing the process and being able to verify it. A memory device that cheats to give the right answer is only that, not understanding.

Indeed. Perhaps even a hangar so you could have the parts not rendered but the craft stored in perfect detail.

Currently what I do is drag all such parts to stage 0. To complete this idea all that the stock game would need is to stop staging at some point before the final stage. Then I think why have only one? Why have linear staging at all. Drag all your abort stage parts into Stage "A" which won't happen in the normal linear sequence. Branching stage trees. Conditional staging actions! IN-FLIGHT USER-SELECTABLE STAGING PROFILES!!!! ...then I had to lay down for a while.

Why it would matter is because it serves as a counter to the notion that KE is divided between the rocket and its expended propellant which would suggest that at some point you'd reach a maximum distribution in favor of the rocket at a finite speed. I was trying to dissuade this thought because it leads to incorrect conclusions. The concept of 1000 to 1001 m/s being a bigger energy increase than 10 to 11 m/s is perfectly simple to follow but to many people it's unsatisfactory. They want to have an emotional understanding of their physical world which a mathematical explanation, however clear, doesn't provide. The search for the everyday example is to satisfy those people. Relativity, as in Eisenstein relativity as opposed to the typical if-I-go-left-you-seem-to-go-right Galilean variety, isn't required at all. For the propellant to have relativistic mass it would have to have a relativistic exhaust velocity (aka relative to the rocket) not just a normal exhaust velocity happening at relativistic speeds as measured from elsewhere. Also one must remember that if the exhaust is relativistically heavy, so is the rocket. The two effects cancel. Not so much easier but more productive energetically. "Top speed" is a terrestrial phenomenon involving things like friction and drag. It takes a rocket longer to go from 0 to 2000 m/s than from 1000 to 2000 m/s too. A car has no greater ease going from 50 to 51 mph than it does from 10 to 11 ignoring the myriad of car-specific factors such as drag, friction, torque curves, gear ratios, etc. The quantity that is easier to tack on at higher speeds is energy. Assuming a vehicle can accelerate a given unit of speed it will provide more additional kinetic energy starting from a higher speed. Simple? Yes. Correct? Yes. Initiative explanation that everyone can relate to from everyday life? No. It comes back to one of those "see the equations work out!" arguments that fall flat with the layperson. "Wow, what a pitch! That fastball had 230 Joules on it!" Correct isn't always understandable. This is a really tough challenge because people do not see the world energetically. We think in force, distance, time, temperature but not linear energy. Our eyes see light bulb irradiance logarithmically! People are shocked at why car crashes at 50 mph aren't twice as violent than 25 mph. I think pendula are a good avenue because they translate KE a measurement that we have little concept of linearly to height which we understand well. T = U = mg*h is a nice measuring stick. The trouble is finding a mechanism that adds a fixed deltaV so one can observe how its effect is different when applied at different speeds.

I tried to think of the Oberth effect like this a while ago and it just wasn't intuitive. The obvious question comes up what happens when your rocket is going faster than the exhaust? By the explanation that energy is divided between the rocket and its exhaust it would stand to reason that the maximum amount of energy to the rocket is achieved when the minimal amount is left in the exhaust. This is when the exhaust is stationary. Such is not the case as the Oberth effect is uninterrupted at any increase of speed, well beyond the exhaust velocity. I believe the problem with this is focusing on a scalar quantity, energy. Transferring the whole thought process over to a vector quantity, momentum, bears more fruit. Relying on an external concept of stationary will mislead you. Instead, consider the center of mass of the rocket-fuel system. The momentum and position of the system are fixed and can be set to zero safely. The only effect observed by burning the rocket is on the energy of the system by separating the components of the system. This doesn't explain the Oberth effect however. The Oberth effect is noting that the separation acceleration from speed N to N+1 increases the energy of the system more when N is larger. Gravity, orbits, etc. are all distractions. Oberth effect is an extremely basic consequence of physics and applies to a single object accelerating in free space in a straight line. It doesn't even have to be a rocket with reaction mass. It all comes down to how a fixed change in momentum (or speed for a constant-mass object) results in a variable change in kinetic energy depending on the momentum or speed to which the change was applied. I'm not sure this is applicable. To apply the energy of the swinger must be changed by applying an impulse at high speed to increase KE better than at low. Legs and pushing aren't so well behaved because your ability to make an impulse is impaired by how long you are in contact with the thing to shove off of, the angles, etc.

I struggle to find a common household way to describe that kinetic energy rises as the square of speed. Very little in our daily lives operates on a "fixed delta-v" basis like rockets do. Because friction is so prevalent often high speed is the worst time to increase speed since the friction increases at a rate exceeding the square. Low speeds minimize many kinds of friction but downplay the exponential relationship between speed and energy. Pendulums like a hammock or playground swing are good simple models for the interplay of motion and potential motion like what happens in spacecraft orbits.

You've pointed the outer sats' dishes at the inner sats... but have you pointed the inner sats' dishes at the outer sats?

Perhaps that's a bad example then. Can you take the Kerbin-Duna and Duna-Ike figures and though any simple math express Kerbin-Ike as a result of that?

I'm confident that the transfer dV is practically identical for another planet and it's moon. It's like the gasoline used driving to another country and being concerned about which house you arrive at. The capture dV... I made that up. I tried to think through it logically and I made a guess. I think if you encountered the planet body and did a sling through its gravity to aim you for its moon you would travel a path very similar to the piecewise path the dV map indicates except you could cancel the planet capture and planet-moon dV's against each other. What I don't understand is why the capture dV for Eve is less than the Eve-Gilly transfer dV.