Tallinu

I'm sorry if it sounded that way. There's only one "complaint" and it's the very first paragraph, and it's in regards to what I assume is a normal behavior for the plugin, where it disables gimbals and re-enables them depending on throttle state. The issue has to do with that feature's implementation: Because the plugin controls the gimbal locks via the same toggle the player would use, you lose the ability to manually control gimbal locks (at least via the usual toggle). Since this appears to be "working as designed" behavior and there don't appear to be any errors to report, I did not consider it a bug or expect the log to be of any use. And the rest of what I wrote was simply an attempt to provide as much information as I could about the nature of the behavior I was "complaining" about and to describe my attempts to work around it. I don't remember whether the "show actuation toggles" option I used to do that is available in a stock game, which is why I mentioned TE. Oh, and the comment about a gimbal limit slider is just irrelevant wishful thinking, as in "wouldn't it be nice if the game had..." (Sorry for getting sidetracked and confusing the issue.) As for the Bobcat, that's a stock part from the Making History expansion, not a mod, so I just assumed you'd be familiar with the name (sorry again). It's apparently implemented with two separate gimbal modules -- I guess they couldn't give it roll control authority (as a single central engine) with just one module. I mentioned what I'd learned about it in my experiments because I thought the fact that the plugin only locks/unlocks one of those gimbals might be something you'd consider a bug. I don't know if any other engines actually have multiple gimbal modules, so maybe it's just an edge case that hasn't come up before. Either way, since one of them does get automatically locked/unlocked, the plugin clearly is "working," it just doesn't take into account the possibility that a part might have more than one gimbal module. The issue should be reproducible by launching any craft using an engine with a gimbal and attempting to manually lock any of its gimbals while the engine is running. The gimbal setting in the menu immediately changes back to unlocked and the engine continues moving in response to yaw/pitch control input. In the case of the Bobcat, providing yaw/pitch/roll control input while the throttle is off and looking at the engine and the part right-click menu, you should see that one nozzle still moves and the second gimbal hasn't been auto-locked (and can be manually toggled, whereas the first gimbal option will instantly switch back if clicked on, as previously stated). I ended up removing the plugin because I really needed to be able to lock some gimbals on a mission I had in flight (and couldn't use the workaround of disabling the actuation toggles due to being in flight already). But if you can't reproduce this, let me know and I'll reinstall it and create a log (would you want one where I'd launched a craft and moved the engine around? Just at the main menu? Or what? I haven't seen any error messages regardless of what I tried).

It seems like this plugin makes it impossible to lock the gimbals of certain engines the normal easy way, whether during flight or in the VAB. If you try to lock a gimbal while your engines are active, it instantly resets back to "free," and of course if you try to toggle it while engines are shut down they just go right back to "locked." Surprisingly, tweaking the gimbal range down to zero in the VAB (with Tweakable Everything) doesn't seem to have any effect either. (That seems to just be broken in general, but it most likely doesn't have anything to do with this plugin.) The only thing that does work is to use "show actuation toggles" and turn them all off. This may also be a Tweakable Everything feature though, I'm not sure. Sadly there is no "gimbal limit" slider available in flight that could be used to easily adjust them on the fly in the same way that engine thrust can be scaled for more precise burns... While investigating this I also discovered that this plugin only affects one of the Bobcat's nozzles, and the other still moves. This seems to be because there are two separate gimbal lock options on its menu (and a different, "0-100" gimbal limit adjustment -- which only affects one nozzle?!) and in the action group editor there's an entire extra set of gimbal-related options, one for each nozzle. Using these I was able to get both its nozzles to stop moving by toggling all six actuation toggles in flight, but that can't be done for both nozzles in the VAB.

Ah, thanks! I think the wording of "non-resettable" must be what confused me -- as in, "But why can't I reset it? How is that a good thing?" I guess it really meant "non-resetting" as in "it doesn't get reset when you switch away from them." And the hotkey in #3 is just a way of setting more than one of them to do that en-masse.

Sorry if I'm being dense, but what does this mean?

I am indeed playing Career, although I would expect the recovery of science and/or Kerbals (where applicable) to function in the other modes.

I'm on KSP 1.7.3 with SR 1.9.1.3 and RecoveryController 0.0.3.8 and I have a couple of questions. 1: I don't know if this is actually a feature that Stage Recovery is supposed to have or if I'm remembering wrong. I thought that in the past I had been able to drop an upper stage or payload from orbit back onto a suborbital trajectory and have the mod recover it for me while I do other things (assuming it met the parachute, heat shield, and/or propulsive landing criteria of course), but recent attempts haven't even resulted in a "stage destroyed" message, as if the mod just isn't handling the event. It works fine for stages jettisoned as I launch a new vehicle, but it seems like once something has achieved orbit it stops paying attention (or at least doesn't generate the expected messages). 2: It was also tricky to figure out just how many parachute modules I needed to attach via docking ports to successfully bring down an older "space bus" craft for recovery (which was replaced by a larger model with better crew capacity and more delta-V). When attaching the parachute-laden probes to the old design in the editor, SR treated each of them as separate stages (even though no staging was enabled on the docking ports), and stubbornly kept telling me that the main craft was 0% recoverable. I had to replace the docking ports with structural connections and/or move the parachutes onto the main craft in order to figure out how many were actually needed. At first I thought that the parachutes all being on these docked probes might be responsible for SR not recovering the craft after I dropped it out of orbit, but then I realized that it still should have generated a "stage destroyed" message if that was the case, so it's probably just a separate usability issue. It's easy to find out if something like a docked escape pod ("MOOSE" etc) has enough parachutes to land safely by simply detaching it from everything else, after all, and I just keep coming back to that after trying to think up any use case that would require the current treatment of docking ports. I understand that it might not be easy to do anything about, but it would be a "very nice to have" feature/tweak/whatever if there was a way to make it treat unstaged docking ports in the editor as being one stage instead of separate stages and base its diagnostic report on the combined unit. Thanks for keeping this mod going, and all the others you maintain -- I use quite a few of them!

Alright, sounds like either there's a bug in MM or it's an intentional change and the documentation hasn't been updated to reflect it...

... But... if a mod is installed... then why would its "modname" not exist in step 2? Regardless of whether or not the mod uses FOR[MyModName] in all of its patches. Assuming it's installed properly, of course. From the very link you posted: The first and third bullet points. It has examples right after that. Although the DLL is called "Scale.dll" instead, "TweakScale" is the name of the folder out of GameData, so that should absolutely exist. Granted, the advice he gives about making sure of that by using FOR at least once is sensible, and making all of them use FOR for consistency (and to allow BEFORE to work) would also make a lot of sense. But AFTER, at least, should still be working right now, at least for TweakScale, even if its patches don't currently include a single FOR.

Ahh, I had suspected saved craft files might be susceptible too, that's why I checked the ones I'd made recently! I can see what you mean about the problem spreading between users. However, it sounds to me like there's an easy preventative measure. Any time you download a craft (from KerbalX or anywhere else), open it in the editor, and then simply save it, without touching anything. (After having the TweakScale update installed, of course!) That should trigger TweakScale's module duplication fix, and ensure that the craft file you have on disk is now a "safe" copy, whether or not it was "tainted," right? Which is why you said people needed to switch to all their ships (via tracking station, etc) to get them to be loaded up and then resaved in the persistence file. However, this is only necessary for craft which contain parts suffering from duplicated modules, right? Because those are the only craft which could be affected by TweakScale resaving them in a way that prevents future corruption when the module cache ends up fixed (has its "sanity" restored). So, it's not that every craft must be activated and resaved (in flight or in editor), it's simply that all craft which contained duplicate modules on some part must be. So in my case, my saved craft and persistence file contents shouldn't need to be resaved. (I'll still run through the important ships and stations in flight just to be sure, and I'm resaving all of my recent craft files even though they're mostly stock parts that were unaffected! Can't hurt to be safe, especially for the craft I was posting in case others liked them.) Ahh, now I understand what's causing those type and default scale entries to get doubled up. Thanks for pointing these out, @Tonka Crash! And for the explanation of the ordering: Wouldn't this be true only if the mod was trying to use :BEFORE[TweakScale]? If TweakScale's included patches run at step 4, and :AFTER patches in the last part of step 5 for each mod, doesn't that mean :AFTER[TweakScale] still runs after TweakScale's patches? Either way, it sounds like adding the % signs at least, and possibly using :FOR, would be good preventative measures to take. It might avoid some cases of a mod's included patches (being overly simple and/or not understanding exactly how to use the proper directives) conflicting with TweakScale's, since if they don't have any ordering directive they'd be applied first, and TweakScale's patch (being written with this possibility in mind) wouldn't introduce any problems (which wouldn't have been introduced in any case by patches from the mod itself). Does that seem reasonable?

Okay, I believe what you're telling me is that if any of my active craft (the ones saved in the persistence file and any quick saves) contained parts which suffer from this module duplication issue, "fixing" the duplication before installing the newest release of TweakScale would have caused the affected parts to experience issues like zero mass and other nastiness, regardless of whether or not their scale had been changed (simply the presence of the broken duplicate module is enough). Is that an accurate summary? Assuming that is true: Since I have not used any of these parts (the parts in which I found module duplication in the cache file) in any of the craft I've launched so far, none of my existing craft should experience any problems, regardless of what I do (because none of the parts they contain have duplicate modules saved). But now that I have installed the new version of TweakScale, it will prevent the duplicated module in those parts from eventually corrupting any craft I might launch that use those parts, because it renames the extra module to something else which won't overwrite the correct settings in the first instance of the module. Therefore, with the new version installed, I should be able to safely use any parts which are affected by that duplication, without having to try to manually fix hundreds of lines in the cache file every time I install or remove or update an mod (which happens frequently enough that it isn't really feasible). Correct?

How do you know for sure if you are affected by the problem? That doesn't seem very clear to me. None of the craft files I have saved recently seem to have any duplicated TweakScale modules, but when I hunted through my ModuleManager.ConfigCache file I found some parts where this was the case, matching what you showed on the GitHub issue even down to the duplicated type and defaultScale settings in the first module. The affected parts don't seem to include any that I have actually used in my craft so far. And as I said, I didn't find any evidence of this issue in my saved .craft files. Does that mean I don't have to worry, and once I install this TweakScale update, there won't be any problems if these corrupted extra modules do get added to things in the future? I actually don't use TweakScale very often, funnily enough. I'm usually able to do everything I want without changing part scales. The only thing I can really remember doing most recently is increasing the size of the micro landing legs one time when I needed longer legs for a lander but only had those legs unlocked, and that craft was recovered a long time ago.

The Klaw is the (official!) nickname for the Advanced Grabbing Unit, in the Actuators (160) research node. It's capable of latching onto other vessels/parts without needing a docking port on the target (and can latch onto asteroids in order to stay attached while mining or moving them). (Ninja'd!)

You can actually change which direction they point their helmets by switching camera modes using the V key (pretty sure that's the default). In "Orbit" mode, "up" is north as bewing said. But in "Free" mode, "up" is away from the planet, and pressing space will orient EVA Kerbals that way instead. If your target is significantly above or below you in one camera mode, or you're having trouble getting a grip on a ladder because of the target craft's orientation, switching camera mode may make it significantly easier to maneuver to or around your target.

Right. I just didn't understand that when you said "this is a special case" you were referring back to this constellation setup again, rather than orbit segment time scaling in more general terms, which is where my mind was leaning (as in that last paragraph) as I'm learning how these things work. I always understood intuitively why the TA of 90 was needed in this case, even when I was originally describing it wrong, lol! It needed to be symmetric, with the AN/DN equidistant from both Pe and Ap. Anywhere else would not put the nodes in the right place, the orbital plane would be tilted around the wrong axis, and sufficient error would prevent 100% coverage.

Actually, the biggest issue I'm addressing by having all four satellites be deployed by a single carrier vehicle (second to interplanetary encounter/capture) is to get the correct relative timing between the four satellites. Each must reach apoapsis at a different time, staggered by 1/4 of their period and in proper sequence. Deploying them from a lower circular orbit that makes 1/4 less than a whole number of full orbits in that amount of time allows each satellite to arrive at the target apoapsis from its deployment burn with the correct timing, raise its periapsis and tweak its period to be as accurate as possible, and from then on remain synchronized with the others, even as they all later perform their inclination changes -- the orbits are fairly high even at that point, so the delta-V cost of doing inclination last was acceptable. A small lightweight relay satellite can easily have 2000 to 3000 delta-V with just a few oscar tanks and a spark engine, though relays meant to reach Kerbin from the outer planets would by nature require larger, heavier antennas (or arrays of them) and therefore more fuel and thrust -- although a better way to go about it, especially around Jool, would likely be to have a pair of large, powerful relays as the main link back toward Kerbin, while small satellites with RA-2 antennas like the ones I've been experimenting with provide local coverage of each moon, bouncing signals around to reach the larger relays as needed. Really? Let's see, the SMA given in his thread is 3,625,000m and according to the wiki, Laythe's SOI is 3,723,645.8m and its radius 500,000m. So that's 5/6 of Kerbin's radius. Scaling 4,350,000 by that factor does indeed give 3,625,000. Despite the fact that Laythe's SOI is vastly smaller than Kerbin's, that result is still lower, but the orbit isn't circular, so... Okay, I think I finally found what I need to do to figure out the Ap and Pe (to center of mass) from eccentricity and semi-major axis. Google was all like "Here's how you calculate the things you already know!" Eventually found https://jtauber.github.io/orbits/017.html and managed to piece it together from various pages there... Focal distance c = a * e 3625000*0.28=1015000 It looks like Pe = a - c/2 3625000 - 1015000 / 2 = 3625000 - 507500 = 3117500 And then I think Ap = 2a-Pe 2 * 3625000 - 3117500 = 7250000 - 3117500 = 4132500 Dang, it's less than 10% outside the SOI! And for the most interesting and science-rich of Jool's moons, too... Well, that one will just have to make do with three equatorial satellites. Anything landing on the poles will probably be able to see the strong primary relays north or south of Jool. A set of three of those, equidistant in a polar orbit, should ensure that one or more are always visible. Indeed, I was just thinking that as I read the previous paragraph. (Also: I get that reference! High-five! ) Good, I had a feeling it was something like that. And now I'm confused. I'm not sure what the difference is, compared to what you said earlier in that paragraph. How does "being Pe" or "being AN/DN" change anything, compared to going from, for instance, 30 degrees to 45 degrees TA on two orbits with the same eccentricity but different periods?

Wow, you've really gone above and beyond here! Did you get your Ap and Pe references swapped in the above line? Or is there some reason to use the Ap sight angle for Pe and vice versa? And considering that I actually used a SMA greater than 4,350,000m around Kerbin anyway (5,506,299m), in order to get easy to work with periods (12h), and plan to do the same around other bodies, there should be an even larger safety margin. What I had in mind was, TargetBodySMA = KerbinSMA * TargetBodyRadius / KerbinRadius which I'm pretty sure gives the result I'm looking for, linearly larger or smaller in proportion to the change in radius. If that does the job the way I believe it should, then I don't have to mess around with math that I can't do in my head. It's great to have alternate verification though! Dangit! Google never dug up Zyx's post for me. And you had even posted there, too, at the time. "Indeed, you're looking at the prospect of four launches, at least for Kerbin." Well, I'm getting all the satellites there with one launch, but making that plan work is what I needed help with in the first place. XD Mainly I'm doing it that way because I wanted something that would work for moons and other planets, and getting a single vessel carrying multiple satellites to intercept a planet will be far easier than trying to manage multiple vessels, and means that the satellites themselves only need to carry enough delta-V for moving into the correct orbits once they detach from the carrier. And it looks like he already did the work of figuring out the SMA for all the planets and moons! I'll probably check a few with that ratio method to see if they match, and if they do, I can just use his values as minimums and try to find nice periods above them. It seems the only one that he had an issue with was Duna because of Ike, and for some reason he went lower instead of higher. I'll have to have a look at Duna's SOI and see if the constellation could be set up in higher orbits instead, to avoid creating gaps in its surface coverage. And that video and patent document are also interesting. I suspected there was probably a range of values that would work for things like eccentricity and inclination, and one of those illustrations confirms that, though it seems like 0.28 and 33 are pretty close to optimal there. Again, thank you for all your help, you've done far more than I asked! Edit: I just had a thought that might save me a lot of trickier calculations if it's correct. Assume that the eccentricity of the orbit remains the same, and only the period is altered (causing the SMA and both the periapsis and apoapsis heights to increase). For example, going from a 12 hour period to an 18 hour period. Am I correct in thinking that the time taken for a satellite to travel from periapsis to latus rectum (TA=+-90) scales linearly with the period? As in, 18/12=1.5 so t=7000*1.5? In my notes from working out the right equation to do what you showed me, I have: t=(2tan^-1(3/4)-(0.28*sin(2tan^-1(3/4))))*43200/(2pi) It looks to me like the location of that 43200 value for period makes it a simple linear scaling factor for the result.

https://steamcommunity.com/sharedfiles/filedetails/?id=1654472000 I just got done setting up for the first of these maneuvers, and it looks great! Not exactly crossing the other satellite's orbit line but I doubt that's possible without performing the inclination change for the first two satellites before the other two (the ones opposite them) are even launched... https://steamcommunity.com/sharedfiles/filedetails/?id=1654490026 Aaaand done! Periods correct down to a thousandth of a second thanks to thrust limiting down to 0.5% and slow-mo physics warp. Pretty much perfect. Yeah, reading about it did fill in a bit more historical detail for me, which was interesting. The whole epicycles thing, heh... And to think that today we have people "all around the globe" (lol) who supposedly believe the Earth is flat again. Right. I figured that one out. Yeah, I had to figure out adding in and removing the planet's radius already. It's nice that they gave Kerbin such neat round numbers, heh. The reason I was trying to figure these calculations out to begin with was that I couldn't find a way to do it (accurately) using Engineer or MechJeb, but hey, maybe I've actually learned something! I doubt I'll remember the details of the equations a week from now, and there's no way I could write any of them out from memory, but the relationships between the anomalies and what everything does and means is all pretty clear. You've been a tremendous help with this! I don't suppose you have any thoughts on the additional issue I noted near the end of the OP, about figuring out what semi-major axis would be required around other planets? My best guess on that right now is to compare the radii of the planets and just scale up/down proportionally from the 4,350,000 that was used in the original details for Kerbin (in the thread I referenced), on the assumption that the geometry will end up the same. I'll still need to figure out what the period would be in the rescaled orbit and figure out if it can be done within the SOI of some of the smaller moons, or if the reduction in mass (and hence gravitation) causes even that (presumably) closest possible orbit to be outside the SOI of, say, Minmus the same way a synchronous orbit would. Although I have the advantage of not worrying about the planet or moon's rotation speed, only its radius, which is going to be smaller along with the gravity, so maybe it'll work out nicely...

I figured that would be the case. Just to make sure I'm not missing anything important, my understanding is that TA = 0 at periapsis, is that right? I need to figure out how to get characters like ε typed in without copying and pasting from something else. And how to remember what to call them (other than "curly E" or "curly W" LOL). I've seen these equations everywhere, but always in the context of solving for position, and just couldn't sort out what I needed to do to get the answer I wanted. Looks like I was overthinking things, and except for the first one they were already in the required form with no "numerical analysis methods" (whatever that means) needed! Awesome! Thank you so much for the walkthrough of this process. And the answer -- when I try it myself I can use that to check my work. This should be able to get me the time before periapsis as well, right? Symmetry and all. If my satellite is at apoapsis (just after getting the 12h period matched), just subtracting 7000.63 from the UT at which periapsis will be reached should give me the position on the closer side, without having to wait and go past PE. And I should be able to use this around other bodies as well, right? It doesn't appear to directly require any constants regarding gravity and such, just the parameters of the orbit and the period. Taken together, those effectively incorporate that kind of information already, I believe? So what I need to do now is go back to make sure all of these are solved in the form I need, more or less the way you did but keeping the input of True Anomaly as a variable, then chain it all together with another variable for period, and I should have an equation where I plug in those two values and it spits out a time-since-periapsis as a result. I could then convert that into a bit of code to do the job quickly. Maybe even figure out how to write a KSP mod to do it. (If I decide to get really ambitious I could probably work up a pull request for MechJeb to let it automatically place maneuver nodes at specific points in the orbit...) As it turns out, I was very much mistaken when I claimed that the position I wanted was along the semi-minor axis. In hindsight, that should have been pretty obvious, since the minor axis goes through the center of the ellipse, NOT either of its foci. I'm glad I mentioned the true anomaly, since that's the actual position I need in order to change the inclination correctly. The apoapsis and periapsis need to be the points most distant from the equatorial plane, with the orbit not tilted one way or the other around the major axis, to match the example configuration as closely as possible.

Credit for trying to help, but yes, I am familiar with orbital maneuvers and standard relay satellite deployment patterns. And I am, in fact, making use of a particular variation of a resonant orbit (or maybe it's something more properly known by some other name), a kind of result which that calculator isn't designed to provide, to get all four satellites launched on their different trajectories at precise times. I'm afraid I put "advanced" in the subject line for a reason. I'm working on this because I want to do something way cooler and more effective with fewer satellites. The kind of help I need is not "how do I shot relay satellite?" It's "how do I math Kepler to solve for X given Y" or "how do I avoid having to math Kepler and get this accomplished to the desired precision by some other means." I don't want to be just eyeballing the position of my maneuver node based on where the lines appear to cross, I want to do it right, or find a way to make the game or the mods do it right for me (that doesn't take launching extra equipment). I've been trying to figure out how to get from point A to point B mathematically speaking, where A is the assortment of orbital parameters I have and B is the one piece of information I think I need to solve for. But, at least so far, I'm just too unfamiliar with the relevant equations to know which I need and in what order and form, compounded by my programming-trained brain always finding it harder to work with variables that don't have names which are intelligible words that remind me what the variable is and does just by reading it. About the only one I even know how to say is theta, because it was used so often back in trig class, lol!

This is also a great perspective, overall, but I think it needs a couple of minor caveats. Time to Apoapsis (I'll abbreviate as TTA) isn't necessarily going to stabilize and stop increasing "until nearly in orbit" if you run your engines at full power at all times the way you suggest. In my experience it never stops going up, slowly at first but more rapidly later in the ascent, unless I'm actually taking too sharp a turn and not going to space today after all. If you're taking a high enough turn to make sure you don't burn up or lose excessive amounts of speed to drag, once you start to get into the upper atmosphere TTA can rise quite rapidly, thanks to the increase in TWR as your stages expend fuel. This can happen even if you start with low TWR (around 1.2), as in your engines are just barely strong enough to take off. Taking a sharper turn isn't necessarily a surefire answer to that, especially if your TWR drops quite dramatically when you stage. It depends on your rocket design and what fraction of your trip to orbit is performed by each stage. In fact, the closer you come to getting all the way into orbit on your first stage (doing so creates a SSTO rocket with any remaining stages as payload), the more you have to throttle back as you get closer to aiming at the horizon in order to avoid pushing your apoapsis up to your target too soon. Another issue: Being a little too high compared to the most efficient possible gravity turn for your craft is basically safe. Being a little too low can be deadly. Keeping TTA stable toward the higher end of the range gives you more time to correct if it starts dropping (for example, after staging), by aiming slightly above your prograde vector. Doing that is not necessarily the most terrible thing ever in terms of efficiency, as long as you don't have to veer too far off prograde. For example, I've read that real-life rockets often circularize post-apoapsis, which would require just such an orientation.

The most efficient kind of ascent path is typically what's known as a gravity turn. This involves gaining a certain amount of straight-upward velocity, and then tilting the rocket a certain number of degrees in the desired direction (usually east, and often north or south for polar orbits), waiting for the prograde marker to descend to match the rocket's new "forward" direction, and from that point on following the prograde marker in a smooth curve that minimizes drag. If you have a level 1+ pilot or a good enough probe core, you can turn on SAS and simply set it to the "follow prograde" mode. And as mentioned by many others everywhere, there is no single, optimal ascent for every rocket. Finding the best gravity turn path for your unique rocket takes trial and error, even when a plugin is doing it (the Gravity Turn launch autopilot is an excellent assistant and/or learning aid if you want to watch how it tries different paths and see what the results are, just be sure that you have the option to 'revert to launch' before using it). With experience, you'll get more of a feel for what's likely to work well for a given rocket. It depends mainly on two factors: TWR (Thrust to Weight Ratio) and staging. Drag can also be an issue if it's very high (large fairings or a great deal of parts sticking out without a fairing, for instance). TWR determines how fast your rocket accelerates. If it's not above 1.0, you can't even get off the ground. I prefer to keep the starting TWR in the 1.2 to 1.5 range, and though going higher is an option it could also mean that you have built too much rocket for your payload and might be able to save some money by using a weaker engine. TWR will increase over time as each stage expends fuel, reducing its mass and thus its weight while the amount of thrust (typically) remains constant, resulting in a greater acceleration being felt, peaking right before the fuel runs out. Staging affects your ascent by typically causing your TWR to change suddenly, usually decreasing quite a bit as your spent first stage's powerful engines and rising TWR are traded for a more efficient but weaker upper stage engine. If your second stage (or third, etc) doesn't have enough TWR you could potentially find yourself falling right back into the atmosphere if your prograde is too low to the horizon and you haven't gained enough horizontal speed yet, especially if the engine is simply too underpowered for the amount of payload it's trying to push. I'd recommend keeping this above 1.0, but keep in mind that sometimes you need to make sure it's showing you the vacuum stats (rather than atmospheric / sea-level) in order to see the right TWR and delta-V figures, as some vacuum-optimized engines (like the Poodle and Terrier) have abysmal sea-level thrust and efficiency (ISP). How does all this affect your ascent path? If your starting TWR is high, especially if your second stage's is as well, you typically want to make more of a turn away from vertical, and start sooner. If your TWR is low, you want to start later and turn less. Expressing when to start the turn is also often done in terms of your rocket's current speed, such as "start turn at 100m/s" rather than by giving a time or altitude. They're all interrelated along with TWR anyway, and since a high-thrust rocket will gain speed faster than one with lower thrust, using starting speed figures can make it easier to make comparisons and take what you've learned with one rocket and apply it to another. Finally, it's typically best to throttle back when your time to apoapsis reaches about 50 seconds (in the stock game you have to go to the map view and point at the apoapsis marker to see this, you can right click it to make it stay visible without having to track it with your mouse). Try to maintain that time at 50 seconds so that more of your rocket's thrust is applied later in the ascent when the rocket is aiming closer to the horizon. The benefits of this are twofold: You waste less thrust on going up, and you delay causing your apoapsis to reach your intended orbital altitude. The sooner that happens, the larger a circularization burn you'll need to finish gaining horizontal velocity. For "getting into orbit" purposes, a larger circularization burn is bad. That's because having to apply more of your horizontal thrust at apoapsis, compared to at a lower altitude, reduces the efficiency of that thrust, costing you more fuel, according to the Oberth Effect. (Basically, you spend more delta-V for the same effect when you do it at a higher altitude.) It's a bit counter-intuitive, so to put it another way: Applying less thrust during the middle stages of the ascent (when you're aiming more upward) allows you to apply more total horizontal thrust prior to reaching your desired apoapsis height, which saves you from having to apply significantly more thrust at the end of your ascent where that thrust is less effective. The net effect is that you spend less fuel to reach orbit if you throttle back as needed to avoid pushing your time to apoapsis over about 50 seconds until as late as possible in your ascent (often into the 25-50% range, although TWR affects it too).

Hello! I'm not sure if this is really the right place for this advanced topic, and if anyone has a better idea for where to put this I'll happily post there or get it moved if possible. I'm working on a mission plan to place four relay satellites in a tetrahedral configuration which will provide 100% uninterrupted coverage of a planet's surface, using Kerbin as my starting point for now (since I still need to figure out how to calculate the minimum semi-major axis required to provide such coverage around other planets and moons). This requires four eccentric (0.28), inclined (33 deg) orbits with the same orbital period and, for Kerbin, a SMA of 4,350,000 km or greater. I'm using 5,506,299 km because that results in an easy to deal with period of 12 hours. I'll include the exact orbital parameters needed farther down, which I have shamelessly lifted from a very old (2013) thread which I will also link. Here are a few screenshots to give you a quick idea of what it looks like. Four-satellite tetrahedral configuration for 100% comms coverage on Imgur, or open the following: I've figured out how to accomplish *almost* every step of the process! Plotting the inclination changes to be performed at the correct time/location is the only thing eluding me. It's not a simple matter of doing something at the current ascending/descending node since they all have to start out in equatorial orbits, and I couldn't just target another vessel and use the relative AN/DNs unless I launch two additional satellites and carefully position them in 90 degree polar orbits which are perpendicular to each other and have their Longitude of Ascending Node carefully tweaked to be positioned exactly along the semi-minor axis of the pair of satellites which need to change inclinations relative to that plane. But launching six satellites instead of four defeats the entire purpose of this plan, and if I knew how to figure out where the AN/DN of these polar satellites needed to be, I think I would already have what I needed to figure out when the inclination changes should be performed without requiring some external reference. All I really need is a way to find out the number of seconds since periapsis (or AP, whatever) which will put the satellite in line with its orbit's semi-minor axis (not major, the one at a right angle to it), the latus rectum, which is to say, when the satellite is at +/-90 degrees True Anomaly. (For an elliptical orbit like this, 90 degrees is not simply 1/4 of the orbital period, like it is for a circular orbit.) Kerbal Engineer can show me what my vessel's current True Anomaly is, but it doesn't provide a way of finding out what the UT will be at that point in the orbit or how much time remains before it, so that doesn't help me plot a maneuver node in advance so that it occurs exactly at 90 degrees, which is necessary to allow the burn to be started at the right time. For reference, here's where I'm at in terms of the mission plan. The four satellites each need to reach their target apoapsis in sequence, 1/4 of their final orbital period apart. The period I'm using is 12 hours, so each satellite need to decouple and burn to raise its apoapsis at 3 hour intervals. Additionally, since the Argument of Periapsis for each satellite is rotated 90 degrees (drawing lines from their APs to Kerbin will form an X or + when viewed from far above a pole), the launch vehicle needs to complete 1/4 of an orbit more or less every 3 hours (180 minutes). A circular orbit with a period of 48 minutes will result in making 3 complete orbits in 144 minutes and another 3/4 of an orbit in the remaining 36 minutes. So, first the launch vehicle gets into an equatorial orbit at an altitude of 305,314 meters, which gives an orbital period around Kerbin of 48 minutes. Just before every 3 hour mark the launch vehicle decouples a satellite, I take control of it and create a very precise maneuver node, first using MechJeb's maneuver planner to "raise apoapsis" after an arbitrary fixed time of several minutes and then tweaking the values using PreciseNode until the accuracy is down to the 10 meter range (just because I can), and then I set the UT of the node to a specific time. For the first satellite I just pick some convenient round number far enough in the future to allow time to get ready. I record this value, and then for the other satellites I simply add on the correct number of additional seconds (3 * 60 * 60 = 10800) to ensure that each node is executed with the correct timing. The time taken for these satellites to reach apoapsis from the deployment orbit is around 3 hours 40 minutes, so the first will need to perform a burn shortly after the second is deployed, and so on. The AP burn brings the PE up to approximately 3364.5 km, and I adjust as needed to ensure that the orbital period is as close to the intended 12 hours as possible given the limits of precision in the values displayed by Engineer and MechJeb. Getting MechJeb's Synodic Period (with another of these deployed satellites as a target) to display a value of over 1000 years, for example, is not difficult and offers more than sufficient precision. After all four satellites have performed these burns, the final step will be to change their inclinations so that they provide constant polar coverage as well as equatorial. And that's what I'm not sure how to do accurately, as described. Here is a save file for a 1.6.1 sandbox game that shows the desired final configuration (it's really nifty to watch in the tracking station as the comm network lines maintain this rolling, stretching irregular tetrahedron, always completely surrounding the planet as the satellites sweep through their elliptical orbits). The state I need to get there from is simply the same thing but with all satellites having an inclination of zero. You'll find two quicksaves in there, one showing each configuration. https://drive.google.com/open?id=1Y71svhDTCd6uBXDtN0mRpcN0l1dGn3z2 Additionally, I'd be grateful if anyone could provide suggestions regarding how to determine what the minimum SMA is for establishing 100% coverage with such a constellation around other planets or moons. Even having a simplified calculation that overestimates somewhat would be perfectly useful. Finally, here are the exact orbital parameters and the thread I referenced for them (the real source, Draim's article, is sadly behind a paywall):

Even the basic fly-by-wire system in AA is amazing, it's like SAS on steroids. The craft goes exactly where I tell it to and stays rock-steady in other respects. I finally got the kinks worked out of the OBS I installed (mainly an irritating hiss in my microphone input line) and got the mission recorded last night, along with a bit of description and commentary. I didn't expect the resulting video to be basically an hour long, although part of that is that KSP ran noticeably slower while recording, but it's done and the latest minor revision of the craft landed intact once again, despite a mishap at the end which nearly led to a crash for the utterly silly (silly, I say!) reason that my velocity readout never switched back to Surface mode automatically, so I thought I was going far faster than I actually was and kept trying to slow down unnecessarily! Here's a link to the video: Which apparently the forum automatically embeds! Alrighty then. It's unfortunate that you can't simply count passenger cabins, particularly those which are required to allow the vessel to contain the number of Kerbals occupying it during the ascent or descent phase, as payload mass -- it uses more delta-V to keep such dead-weight attached for the return trip than it would to drop it off in orbit, after all! And detaching components that make up more than a third of the main body of the vehicle isn't exactly something you can do with a spaceplane, and have it remain stable... or even intact. But I believe this qualifies for utilitarian credit despite that ruling, thanks to the relay satellite "payload" (which weighs less than 10% of what those passenger cabins weigh, LOL ). And it turns out that little thing could actually prove quite useful, since despite its size the satellite actually has enough delta-V to transfer itself to either moon and take up a decent high orbit, and the RA-2 antenna can provide 100% signal strength even from Minmus to a level 1 tracking station. There are links in the description of the video to KerbalX pages with both craft files, for the basic version and the one with the relay payload. I actually rebalanced the RCS thruster positions on the latter in order to compensate for the slightly heavier fairing base left behind after dropping off the satellite. It probably wouldn't make a significant difference, but it's there if anyone cares about the difference.

@Shadriss I didn't see such a question or answer when I glanced through the last few pages or the first page, and there's only so much time you can spend looking for things that may not exist. Also, since it doesn't look like anyone responded to that part: "KSP.log" is the one you'd want, found right in the main folder where the executable is. @wile1411 Thanks for linking those! That spreadsheet makes it so much easier to figure out how far you can reach with various setups -- I had no idea that you could get more signal strength than the level 3 DSN with four stock RA-100 relays! A set of relay satellites spread out in a solar orbit could extend your reach quite a bit...

I have a question about a couple of the rules. Rule 3 suggests you don't have to use a completely stock KSP install. More specifically, would I be correct to assume that if you're flying a stock craft in a save with mods installed (I have a station I want to dock with that has mod parts, for example), but none of the installed mods change stock parts or affect how it flies (like FAR does for example), then the mission can qualify? I could switch to my clean install and spend the time to sandbox up a demo station to run the mission there, but I'd rather just use my existing career game. And am I right to assume that even Atmosphere Autopilot's fly-by-wire mode, which is basically what SAS wishes it could be when it grows up, is not allowed for the stock challenge? Or is that actually okay to use? Also, just to clarify, while rule 1.B says "Crew transfers are permitted," does bringing passengers or tourists to a space station counts as payload delivery for the "Utilitarial Commendation?" The mass of those comfy cabins is basically payload after all! (I could probably squeeze in a fairing with a tiny relay satellite on the tail though...) Here's what I'm planning to use, by the way (Edit: updated the screenshot to show current version, click for a few more. Also, craft file).