Frederf

A small note, under AOTF AG EDIT the Communitron 88-88 has four action group options "Toggle" "Toggle Antenna" "Activate Antenna" and "Deactivate Antenna" Only one of these four actually works and that is "toggle." The others don't respond when queued.

Indeed which is why I said just add a bit of text in the "continue to hold F9" area so you'd know. If we want a real save/load system that would be its own thing and really it should already be in the game. That's really what scenarios are already.

I'm talking about the proposed Action Group Sequence. You press AG1 and it fires off all actions associated with AG1-1. When you press AG1 again it fires off all actions in AG1-2 and so on AG1-3, AG1-4, etc. Action groups would be strings of what is currently known as action groups. They'd be action group groups perhaps. You're talking about adding programmatic items (ifs ands nots waits) to individual classic (current) AGs which is cool but different. Actions on the Fly is a mod that allows reconfiguring action groups in flight so it's possible if not default behavior.

I've heard that MJ's "all stas" button reports TWR_atmo correctly with the MFS constant-fuel-rate change.

The one problem with this is what happens to sealed items if you have a craft A+B and dock it so it's A+B+C then undock it so it's B+C. The A+B sealing has to be broken since the new craft is smaller. The same with parts destroyed.

This would effectively turn the 10-element action group set into a 2-dimensional 10xN matrix where each action becomes an action list. Each element would be 1 to N long depending on how many layers are added. AG3 could be 1-long, AG7 could be 21-long. I really like this idea because it means that the classic staging tree can become a list in the "Stage" action group. It can still have a graphical representation and auto-population like current but you could add new, previously impossible, functions to the stage list like toggling pod torque, extending antennas, which could be later toggled the other way. The "Abort" AG being a small list is a prime example where one key pressed a few times does all the abort stages. It does ask the question how should the lists progress: cycle, one-way, two-way? Configurable?

I've re-named the quicksave file as an autosave and vice versa and both work. The distinction seems arbitrary as does the limitation in number. A dialog that allowed choice and that retrieved timestamp data seems as easy as can be given that anything can have complications in programming.

I wasn't thinking through all the way but you're right. I can input any action groups on any delays already. Combined with AOTF mod I've got it all.

You have a good point. Maybe the "Hold F9..." text could say "Hold F9. Last quicksave 3h 23m ago..." instead. If you want to check it just tap F9 to read.

One feature that I wish RT2 had was the ability to schedule raising and lowering of antennae. With two I can do it: antenna A is active, B is inactive, set A to lower in 60 seconds, and B to raise in 6060 seconds. For 6000 seconds the craft is not connected but it automatically raises with a delay allowing the connection to resume. This saves lots of power on long flights to hibernate the connection. The problem is that bringing several large antennas is impractical just to schedule the lowering and raising at the same time. You can't do that for a single since only the currently-available action is schedule able. If action groups could be added to RT2's repertoire that would workaround the issue.

A small speed change retrograde applied at every Pe between 23km and 69km (function of height of course) would be a very cheap way of having decaying orbits. No parachutes, no landings, no slippery craft, no draggy craft, just -N m/s where N is a function of altitude. Parts that barely skim the atmo at 67km will take ages to hit the 23km wall and ones at 24km will likely disappear on the first Pe. It isn't very often that an unattended craft passes Pe. Unattended ascending craft would be immune since it's only evaluated at Pe. It's simple and efficient and handles 80% of what's desired compared to full physics for all craft in the atmo band.

I've avoided using quickload because I couldn't remember if I saved 60 seconds ago or 60 days ago. There is much cursing when the last 10 flights are erased because the last quick save was farther back than you thought.

It would be nice if a scene is loaded which has craft in flight where some parts are missing that KSP would provide the option to delete the craft or not. If not the craft would remain but a substitute generic craft object (say a cube) would be displayed in its stead if it happened to be encountered in flight. The reasoning is that the craft is valuable in its current situation often and it's simply a matter of starting KSP again with the necessary remedy to complete its consist of parts. Currently KSP auto-deleting craft means that without suitable backup files the user's progress is lost even if providing those parts on subsequent KSP starts is easy.

Shallowest angle that prevents atmospheric exit is the hardest on the shield equipment. Depending on the craft and FAR/no-FAR your aero performance will differ. With FAR and simple craft I need to keep below about 42km Pe to deorbit in one pass from LKO and about 36km Pe if I have escape energy. My experience is that the shielding resource is plenty so go gentle-flat. Steeper angles are easier on the shield (thermal) but harder on the rest of the craft in terms of load factor (Gs).

There might be a second order approximation which is short of a full numerical solution but for TWR > 0.05 or so the first order is plenty good.

It could be balanced so that the scan time meant you would only scan the cell below the craft on the first pass so it'd be indistinguishable from current. Only on subsequent passes would the scanner see previous filled cells and have time to side look. For RSS-compatibility perhaps scanning should be a range based on math depending on the body radius current SOI? Kerbin, Earth-sized-Kerbin, Mun, would all have different min/max altitudes as the geometry scales.

It's best illustrated by starting in a circular orbit around the Mun (it's important that it's circular) and making a maneuver node to exit Mun's SOI with some prograde amount. Keeping the prograde value constant, as you drag the node around the orbit you'll see what effect your exit direction has on the resulting orbit around Kerbin. The most efficient will produce the most eccentric (or most westward if you really overpowered it) skinny resultant orbit around Kerbin.

Is it worth considering a scanning system that is able to scan in a range of solid angle? Perhaps it's still cell-by-cell, once every N seconds, but can gimble to reach areas in sight not necessarily directly below the craft.

In such a case it's probably best to remove the previous maneuver node and generate the next with the remainder of the maneuver until complete. The maneuver nodes require a definite epoc/orbit count and can't really span multiple orbits as designed. Also long-duration burns split 50/50% before and after the impulse point is only a first order approximation. The optimized split might be 37/63% for example. It ultimately depends on the maneuver. It's a different solution for constant attitude as variable attitude as well.

Lowest inclination yes. Least energy requirement, no. And that assumes impulse maneuvering. Cushioning your fall toward the equator over a long burn can ultimately reduce your inclination to zero if you reach orbital speed just as your cushioning stops, but that takes much more dV.

I was deploying Kerbin probes from an airplane via parachute like those low altitude military drops and noticed the auto-cut bug. Would have shared it if I thought it was a bug/had such a quick resolution. Thanks for the MM snippet to FAR-ize all parachute modules.

As I'm trying to add successfive 20m/s boosts to an escaping probe it dawns on me that I'd love if KAC would allow me to select the alarm actions completely independently of each other: Message, warp 1x, pause. Right now it's a radio button but if they were checkboxes I could have 1x warp without message, pause without message, etc. I use KAC as a "warp to x" often and I don't need to click "delete on close" and have a message. It's just been a few seconds since I created it and I don't need a reminder.

For direct ascent from a latitude to the least energy orbit you want to have an inclination to match your latitude. If you launch from 53*N then you would launch on a heading of 90+53 southeast assuming the body isn't rotating. For arriving at the Mun inclined I've found a free return trajectory (a whopping 20m/s extra) from a slightly (how much?) inclined LKO will result in a capture up to polar on the Mun. The vertical (out of plane) speed when you hit the Mun's SOI minus the fact that the gravity brake slows your lateral angular momentum bends your orbit up quite steeply.

Circle is zero, ellipse is sqrt(1 - (a/b)^2) for a long dimension, b short dimension. 1 for parabola, sqrt(1 + (a/b)^2 ) for hyperbola. EDIT: The a/b number for orbiting is going to be R+Ap/R+Pe where R is the body radius. The twos cancel.

I really like the redo of the flight data section with units and sensible decimal places. If you want you can add the ° symbol in the attitude, AoA, and sideslip section to complete the motif.