Eric S

Yes, and if you activate them through the right click menu, you can later stage them to run the test, so the engine itself can be used to get the engine into the situation it needs to be tested in. Or at least you could last time I needed to do that.

Yes. In fact, the above discussion about the parachute issue I was having lead me to figure out the basics about this, since the MM config above makes the Mk16 parachute as overpowered as the default Mk26 parachute is. Basically, copy the part directory that you want to have unmodified from the Squad directory into a different directory and then edit the cfg file within that directory to change the name and title parameters. You have to change the name, otherwise KSP will only keep one of the two parts, and you should change the title parameter so that it's easier to tell which is which in the VAB or when you're mousing over the part in flight. If you want more details, feel free to ask, I'm just skimping on the details because I'm still waking up and not thinking well yet.

I will confess that on my "when I'm not so busy with work" todo list, you'll find, somewhere after "learn KSP modding," an entry for "something to trigger Gravity Turn a given amount of time before in phase/plane with craft's target." Making something seperate that hooks into GT makes sense to me, since you're right, it really isn't in scope for GT. Then again, when creeping featuritis sets in, I start thinking of winding up rewriting all of GT as part of a larger project I'm considering. I have way more plans than time.

On my last career save, I had no problems with MechJeb's "land at target." This time? I've had it try to land me consistently almost half a world away, even when I use "pick a spot on the map" rather than entering lat/lon. Hmmm... I should try it again, to see if it puts the red target crosshairs in the right place or the wrong place.

I'll agree with RSS/RO, and throw in Principia. N-Body physics would require many changes. The necessary UI changes are what would concern me the most. I'm on the fence with the science fiction stuff. I could see a place for it, but not with the current balance where it's too easy to cap out the tech tree without ever visiting another planet.

That was going to be my solution, but I like yours better (Module Manager was a bit more primitive last time I got into it up to the elbows). I'll probably use this, fixing the mk16 only until I retire all my craft that are depending on the current broken stats, at which time I'll either apply both, or switch to RealChutes.

Yes, though I'm not certain that it's just MechJeb, I think I've seen the same behavior from SAS, just not as frequently.

It comes down to two things. First, the most delta-v you can get from any flyby is twice the relative velocity. And it retains the sign, so if you're moving faster than the Mun is orbiting, you won't get anywhere near that amount of delta v because the optimal change in delta-v would slow you down. Because of orbital math, what a flyby is really doing is changing the direction of your relative velocity with respect to the body you're flying past. The maximum change this can yield is if the new direction is directly opposite your current direction. The second thing that limits this is the gravity of the body in question. The more gravity it has, the more capable it is of offering significant deflection, and the faster you're moving relative to the body, the more gravity it takes to deflect the craft's path. The Mun is a bit on the light side in this respect, making it difficult to reach the limits set by the first limiting concern.

I've got one minor issue with Ven's Stock Revamp that isn't just my own weird aesthetics. The Mk16 and Mk26 parachute are rather odd if you don't install RealChute. Basically, the Mk16 is too weak and the Mk26 is way too strong. In a stock game, a Mk16 will land a Mk1 Command Pod at 5.1 to 5.5 m/s. With just VSR and ModuleManager installed, the same parachute/pod combination lands at a harrowing 9.7-10.5 m/s. On the other hand, the Mk26, a freaking DROGUE chute that's lighter than the Mk16, will land the same payload at a "I hope you didn't activate this early without adjusting the 2.5Km deployment altitude" 3.5-4.3 m/s. If you install RealChute, this all sorts itself out, with the Mk16 landing slightly faster than stock at 5.7 m/s and the Mk26 a capsule-destroying 75 m/s (approximately, it was still slowing down when it impacted). I took a look at the .cfg files and didn't see anything obviously wrong, and I won't have the time to dig into it more thoroughly until I finish my current playthrough, as I've got missions in progress that have adapted to this situation, and fixing it mid mission would be fatal.

I'm a firm believer in KAC, I regularly have missions that look like regex's screenshot, sometimes two simultaneously. Combining payloads just isn't practical beyond a certain point, though I'll gladly push it to that point. In fact, every recent tourist mission to the Mun or Minmus in my current save has dropped off supplies/fertilizer to my Minmus base and the location I've picked out for my first Mun base. Even my strictly-probe Duna mission was too much for one launch. Of course, it was a lot more than a lander or two. Eight comms satellites, six probe landers for Duna, two probe landers for Ike, a land-and-return probe for each, two mapping satellites (I didn't have all the techs unlocked when I launched the first one, so they could have been combined), and one high atmosphere sample skimmer for Duna.

Scott Manley did a video on this, the Mun isn't particularly useful for most interplanetary destinations with a traditional gravity slingshot because you need more than you gain from the Mun to get there, and burning after you leave the Mun looses too much efficiency due to the Oberth effect. If you just want to hit the solar SoI though, it's great. If I hit the Mun or Minmus on an interplanetary mission, I do it as sh1pman describes. Hmmm.... there's something I should try, a gravity slingshot off the Mun that rather than throwing me up, throws me down. If you can hit LKO with more velocity than you had when you finished your transfer burn, that could be a win. Of course, getting the timing for an interplanetary transfer right under those conditions would be a nightmare :-)

I might too. The first thing that went through my mind was "What's Klingon for 'Oops!'?" Does it translate out to "I meant to do that."?

That one, true. In fact, I've had problems every time I've tried to use that one, even from LKO, though that may be a mod issue. I was just correcting the generic "direct antennas can't reach other planets" statement. "This direct antenna" would have been accurate.

This isn't true. For every relay antenna other than the shortest ranged one, there's a direct antenna with the same rating and significantly less mass. The RA-100, the longest range relay antenna, with a 100G rating, is matched by the Communotron 88-88, a direct antenna having less than 8% of the RA-100's mass. Only the smallest relay antenna is deployable, so I tend to put the larger ones in fairings.

The difference in SMA between a 100km altitude periapsis (gravity turn) and a center of Kerbin periapsis (vertical ascent) is 5.8% in the case of a Mun-altitude apoapsis, so if the gravity turn yields an 11% greater SMA, it is more efficient. Also note that the farther the gravity turn pitches over, the more efficient it becomes, as long as you're not drastically increasing losses from aerodynamic drag. Even ignoring centrifugal force, 45 degrees isn't the most efficient angle, I just gave those numbers because it was easier to visualize (and I got it wrong anyway). At 30 degrees above the horizon, you cancel out 1g of gravity and get 1.73g (2g * cos(30 degrees)) of horizontal acceleration. Of course, if you try to launch that far over right away, you get into the case of drastically increasing your aerodynamic drag. Also note that the higher the apoapsis, the smaller the difference in the SMA the LKO periapsis makes, so leaving the SoI doesn't change this. There are probably people that overstate the difference. I've seen people claim a 40% advantage overall, but I'd actually be surprised if the difference is that great for craft with a reasonable TWR. But it is is there.

Because KSP is large address aware (to the best of my knowledge), which bumps it up to 3GB if your OS is set up to allow for that. I know that before 1.1, I'd usually be running in the 2.5-3GB memory utilization range after a while on a modded install. Now, I know older versions of windows need to be told to boot in a mode that allows for large address aware applications, but I get the impression that that defaulted to on for Windows 7 and later.

Good question, it is wrong.... OK, I think I got it. 1.73 would be the square root of 3. 1.43 squared plus 1 would be 3, so I counted the 1, not the 0.43 for the vertical component. Apologies, I haven't been sleeping well for the last two weeks and this is hardly my worst sleep-deprivation induced goof. I should probably go back to actually drawing this stuff rather than just doing it in my head until I get back to my usual sleep cycle. Much smaller benefit, but still quite a bit larger than the extra orbital energy required for the higher periapsis. Unless I botched that math as well, that is. I've done the math when fully awake in other threads, and the conclusion was the same, just off on the amount.

Pythagoras still matters, just not the way you think. We can all see that the specific orbital energy between two orbits with a Mun-level apoapsis, with one a center-of-Kerbin periapsis and the other a low-Kerbin-orbit periapsis, favors the former but is minimal. The point of the non-vertical ascent is that it's adding to its orbital energy in a more efficient manner. It should also be pointed out that the extra energy of the latter orbit isn't entirely wasted as it means that you're closer to matching the Mun's orbital velocity when you get there. 2g worth of vertical thrust yields 1g worth of acceleration (two steps forward, one step back). 2g worth of prograde thrust 45 degrees off of the horizon yields 1.73g worth of acceleration (1.43 steps forward, one step back, and 1.43 steps to the side). Now, as you increase the TWR, this effect diminishes, but it doesn't go away until you're talking an infinite TWR. Even at a TWR of 10.0, the vertical ascent is still losing about 10% more acceleration to gravity. This doesn't mean that the entire first case launch will be 73% more efficient because even a gravity turn spends some time going close enough to vertical that it doesn't really benefit from this during that time. In addition, as the craft burns fuel, it's TWR goes up, so even a low-TWR craft should have a higher TWR by the time it has pitched over enough for this to make a significant difference. On the other hand, as the craft starts reaching orbital velocity, the craft will wind up losing even less acceleration. But really, given that the specific orbital energy between the two target orbits only differs by about 3%, it doesn't take much to overcome that. Yes, you can say that you'll just design a craft with a higher TWR, but then you're using a more expensive craft to launch the mission, which is a better method of determining efficiency than pure delta-v. But all of this is the theoretical math that got dismissed by the OP, so really, we need to fix the test case and rerun the tests. As others have mentioned, we need a defined payload to be delivered but treated as inert or at least mostly inert. If there's a probe core there I don't mind the idea of it controlling the craft, but if it has fuel and/or an engine, neither should be used or altered.

Not a spaceplane expert, but at least part of the problem is that any aerodynamic surfaces ahead of CoM of the craft reduce the stability of the craft, requiring more command authority if the craft is not pointed directly prograde. Now, the closer to prograde you are, the weaker this is, so if you can do a true gravity turn (aiming prograde for everything except the pitch maneuver), then you'll probably be much more likely to be able to launch this craft without the huge tail fins. If you find yourself having to push the nose over closer to the horizon, then you might be able to manage this by doing a more aggressive pitch maneuver or doing it at a lower speed/altitude. Lowering your TWR is another alternative that might help. This gives gravity more time to pull the heading of the craft over.

Not necessarily the worst, but one that has always annoyed me every time I see it is brute forcing a password/launchcode/etc. They fill in digits one at a time. I get why they feel the need, that gives us a countdown for suspense, but it still hurts the brain.

I've been following the developer comments on this, and I have to agree with this. The last statement I remember is that it was being made part of the "Engineer" class, but that got it tangled up in an overhaul of all the astronaut classes, which didn't make the 1.0 or 1.1 cuts. So for the on topic part of this post, I have to respond with "it's that it's not ready yet, not that they don't want to give it to us." On the off topic part, I'm going to point out that the coding that is currently holding this up isn't even the delta-v calculations. It sounded like that part was actually coded, they just couldn't release it without the classes overhaul. As for pandaman's suggestion, the problem with edge cases is that they probably aren't planned for, so the code most likely wouldn't be able to put up a warning that the answer was questionable. A list of all possible edge cases just wouldn't be practical.

Das mentioned a new onscreen button that toggled this, so it really doesn't sound like an IVA replacement. As for the amount of work, it's funny how many times an interesting project can come out of taking a needed break from a main project or that apparently unrelated changes can lead to interesting new features. More than once during development, I've written someone a note saying "You know, since we're already making changes X and Y, adding Z would be trivial, does that sound like something you want?" and received the answer "Yeah!"

This is in fact the case, the rigid body simulation code in 3.3 is about 30% faster than 2.8.X. Not a huge factor, but it's something. And yes, I have to agree with the fact that there will always be a limit and people will be pushing that limit, it's just how things work.

Not saying it's why it can't be done, just clarifying the reasoning, but n-body and atmospheric effects aren't non-deterministic as KSP would implement them either. It's that atmospheric effects are hard to integrate and n-body physics would change a lot of assumptions built into the code of KSP. Personally, I don't think this would be particularly hard to implement, I just don't see much of a payoff for the work it would take.

Probably not what happened, Claw himself said that Squad shouldn't fix things the way he did. Much more likely that since he's hitting high priority bugs that they had the same bugs on their high priority list.