Eric S

Not surprising, my first instinct was that it was a flaw in the patched conics prediction. Basically, the reason it shouldn't work (and won't, except in cases where the simulation isn't as accurate as the math underlying the simulation), is because of the basics of orbital mechanics. Baring some outside force, you will arrive at the same altitude as you started at, and with an upward velocity equal to the downward velocity you started at.

Depends on what I'm doing. For challenges, of course I play without MechJeb. Basic career mode I tend to either play without, or use it mostly as a fly-by-wire system (SmartASS, maneuver node editing, and sometimes maneuver node execution, but doing my own maneuver node creation). When I start playing with life support or other time sensitive mods, I start using something, be it MJ or KAC or such to tell me when the transfer windows are. Without time sensitive mods, I don't mind throwing my craft into orbit and then estimating how long till the transfer window by dropping a test maneuver node and checking to see if I'm arriving at the destination before/after the target gets there, and by how much.

I'm not sure about saving in the VAB/SPH, but there is a text message letting you know it saved when you hit F5 (or an autosave checkpoint, for that matter). However, the text message doesn't show up centered in the window like some of the other status messages do, so you have to know where to look. It's on the right side about a quarter of the way up from the bottom, if I remember correctly.

As some have pointed out, a straight up launch is less efficient, but Minmus has so little gravity that it doesn't really matter. Even on the Mun, the straight up launch only costs about 100 m/s more than the mostly-horizontal launch, assuming a munar TWR in the 5-6 range. Just keep in mind that as you take off from larger bodies (or similar bodies but with a lower TWR), you'll tend to have a lower TWR and the difference will become greater.

From my reading on the subject, it looks like multithreaded physics won't be a big win unless you've got multiple craft within the physics window, so I'd recommend the G3258 unless you do a lot of multi-craft bases and similar operations. Note: docked craft will probably count as a single craft for purposes of this.

I'm looking forward to hearing about this as well, even if it's bad news just so that I can set reasonable expectations. Too much is changing to assume that the microbenchmarks we've seen will be an accurate representation. For those that haven't been following, here's what I think will be the most significant factors in performance improvements: 1) PhysX optimizations: microbenchmarks indicate that for connected rigid bodies, the version of PhysX that U5 uses peaks at about 50% faster than the version that U4 uses. 2) Multithreaded physics simulation: I expect this to not affect single craft and only provide a benefit when there are multiple craft inside the physics bubble. Creating a general purpose physics model that can use multiple threads on a single set of connected rigid bodies isn't something that's been done yet to the best of my knowledge. 3) The new UI code: The consolidation of the existing three types of UI code, each with their own overhead, down into a single set of UI code should have a positive effect, though I'm not sure how noticeable it will be. Squad has commented that one of the types of UI code that's getting replaced was particularly bad in this regard, so it might actually be noticeable all on its own.

I didn't make it clear, but that's really what I focus on as well. There are very few things I've actually removed completely from my diet. Fish and chips being one of the few things that I removed that I'll miss. 2500 calories for a single meal just isn't worth it. I tend to describe it as making myself aware of the decisions I'm making and trying to make the better choice more often, but not to the exclusion of all the bad choices. I gained the weight slowly and my HbA1c isn't too serious yet, so I didn't need to make drastic choices to start losing weight. I won't know how my HbAIc is changing until I get retested in a few months, but both my doctor and I expect to see some positive changes there as well. Moderation in everything, as the saying goes. I can't think of a single thing that the body needs to function well that it can't get too much of, and that includes water. And no, I'm not talking drowning, there is such a thing as water poisoning. Same for salt. Some salt in your diet is necessary, but it's easy to get too much of it, especially if you're sensitive to it. At least some people have a harder time losing weight if they cut fat out of their diet completely instead of limiting it to a small amount. Seems the human body doesn't want to give up what fat it's got if it's not getting any new fat. As I said before, I don't think that there is any one diet that's optimal for everyone, especially when you take into account what diets different people can stick to. My favorite hamburger is something like 900 calories and the fries that come with it are even worse, but as long as I know that I'll make room for that every few months, I'm fine. If I say that I'm giving up that hamburger for good, I'll feel like I'm depriving myself and the diet won't last two weeks, even though I probably wouldn't have eaten that burger during that same two week period even without being on a diet. I haven't stopped eating candy, but I eat it a lot less often and in smaller quantities when I do. Chips and cookies fall into the same category. I haven't even given up fried chicken, but I limit the frequency and portion size when I do eat it. So yes, focusing on moderation can work for some people, even those that don't have the best self-discipline.

Agreed. I didn't go into that because I really don't have much advice there, my exercise plan experienced RUD due to unrelated medical issues. :-) Basically, this is the one area were I most agree with the diet buzz about eating minimally processed foods. Basically, processing or overcooking food tends to make the carbohydrates in the food more readily available to your body, causing the glycemic index of the food to spike. Minimally cooked pasta has a low glycemic index, overcook it and the GI triples, if I remember correctly.

I can usually get them stable for years, but even then I want better. You can use Hyperedit or save file edits to park the satellites perfectly, but if you do that, you need to be careful never to make them your active ship, as the pass from on rails to physics and back to rails will throw the orbit off due to FP rounding errors. I find the best way to fine tune the satellite's orbit is to use a very weak engine (single LV-1 ANT or Ion engine), thrust limited as low as you can get it and then burned on minimum thrust. Oh, and you want the satellite to be very stable, no flexing, as the flexing will throw off the orbit.

Well, since the original question has been answered, I'll just offer moral support, having gone through the same thing about two months ago. In addition to paying attention to the glycemic index of foods, weight loss helps. I won't push any particular diet because I'm a firm believer that there is no one diet that's right for everyone. I'd recommend looking into nutritional info and a few different diets to find one that works for you, as a diet with perfect benefits that you can't stick to isn't going to help in the long run as much as any diet that helps that you can stick to, because sadly, this is the rest of your life that you're talking about. You need to find what works for you. In my case, it was about finding ways to cut back on calories without feeling like I was depriving myself or eating foods that I didn't want to "just because." What worked for me was spending a week tracking what I eat, including weighing things so that I knew just how much I was eating, then looking up the basic nutritional and glycemic information for what I ate. At the end of the week I started categorized foods into a few categories ranging from "this is good and I like it, let's eat more of it" to "I like it but it's bad for me, I need to eat it less often" to "OK, that food is really bad for me and I don't like it enough to make up for that, it's gone." Another big thing I noticed when I started paying more attention is that I tended to eat more than necessary. Why stop when the food still tastes good, right? This tended to be a bigger problem on foods that I really liked, but I found that most of the enjoyment I got from a favorite meal came early on, so that shifting from "eat till it doesn't taste good" to "eat till I'm not hungry" really didn't leave me feeling like I was depriving myself much. I didn't get things right immediately. I had a few meals that were low enough in protein that the first time I lined up one low protein meal with a low-to-medium protein meal in the same day, I didn't get enough protein and was feeling off during the late evening. Still, I'm losing a pound or two a week most weeks while maintaining decent energy levels and not missing my favorite foods much, which means it will take a long time to get my weight back down where it should be, but after all, it took a good 30 years to gain it.

Of the subreddits I read on a daily basis, /r/kerbalspaceprogram is the only one that's gone private. It's being unofficially discussed in one other reddit that I read. I don't know the admin in question nor the reason for the ban, so I don't consider myself qualified to take a side. I know that some of the people that took offense over the fact that reddit hadn't said why they banned said user. Frankly, given that most employers in right to work states won't discuss why they fired someone with anyone but the fired person, that person's "chain of command," and the HR personnel that process the firing, I don't find this kind of process that abnormal. Ah, here we go, a reddit topic that lays out the reasoning of the protest: https://www.reddit.com/r/OutOfTheLoop/comments/3bxduw/why_was_riama_along_with_a_number_of_other_large/?sort=new

Things like that make me glad that squad is outsourcing the PS4 port rather than the PC port. I hope that the PS4 port is wonderful and all, but since the last console I owned was the 2600, it's really more a matter wanting it to be good for other people than for my own needs.

Correct. In fact, one of the devs, Maxmaps if I remember correctly, said that the reason they started shipping the Win x64 client right after a modder showed that it could be done wasn't because that modder had shown that it could work, it was because the initial community that sprung up around that modders work seemed more accepting of a less stable product than squad assumed that they'd be.

In fact, when I mentioned that I have rarely seen people asking KSP to be ported to consoles, it's possible that every request I've seen has been on Reddit. I'd expect them to be more common there since Reddit has a wider user base, not being restricted to KSP players. This forum is populated almost entirely by people playing an existing version of KSP, which means desktop users.

I think of it as insurance against the longshot of a hard to detect rogue planet deflecting the trajectory of the probe by enough to make backtracking the trajectory impossible without knowing about said rogue planet. Yes, that's a very long shot, but it would stink to high heaven to go through all the work just to have that happen.

I have seen it asked, though it's rare. If you check on what's been announced so far, Harvester says that the Unity 5 port was actually sped up by this decision because the company that they're outsourcing the PS4 port to has more Unity 5 experience than Squad does, and was willing to help out in the initial work. Really, we're going to see Unity 5 and probably 64 bit Win support before the PS4 port is released. There's also a chance that an asteroid will kill us all before any of that happens. Simply saying "a chance" without even a guess at the probability kind of feels like fear mongering. Since squad themselves are sticking with the desktop platforms and outsourcing the PS4 port, I really don't think you could call this a "focus on other platform"s. I do agree that the PC version of KSP could be harmed if they switched to primarily developing a PS4 version and then porting that to the desktop platforms, but that's not what's happening here unless Squad is lying out of their rear orifice. I just don't see that happening prior to KSP 2 or some other update that is almost a complete rewrite. Personally, I've got no firm concerns about this announcement. It's possible that they may actually lose money on this, it's possible that the PS4 port may not be as playable as the PC version, and it's possible that they could flip around the prioritization, but really, none of these are likely enough to affect the current players of KSP. I'll keep my eyes open to see if anything like that is coming down the pike, but it's way too early to start fretting over it. The closest thing to a concern was the fact that the announcement replaced the dev notes instead of being the big item on the dev notes. I can see where the announcement is very big from their point of view, but as a player that has no interest in playing consoles, it doesn't affect me in any way other than the probably-unlikely events discussed here.

No worries. To be honest, the only reason it matters to me is that I don't want anyone taking incorrect statements as gospel. Which of course means that we need to determine which ones are incorrect. Can you be a little more specific on your experiments? I'm just trying to figure out where the discrepancy is between your experiments and this experiment and the description on how the orbital energy worked that I posted, which agrees with Jouni's results. I think I'm right, and if I'm wrong, I'd like to know before I spread the wrong ideas any further.

Leaving an atmosphere is going to add a factor favoring the straight up approach. I've seen people test this and come up with the orbit being slightly more efficient. I suspect that the real difference may be minor enough that it can get lost in minor variations of other factors. Also, I'd expect this trick to be more viable going to Minmus than to the Mun due to it's lower orbital velocity. But that's not what the post was discussing. It's not wasted delta-v, as I pointed out in the second paragraph after what you quoted. It's increasing the orbital energy in the most cost-effective manner. You're hung up on the fact that you don't want to go to orbit, but that doesn't mean you aren't still bound by orbital mechanics. If you're not being supported by something else, you're in an orbit, even if you're moving straight up. Show me where my math is wrong, because it's saying that for purposes of escaping an SoI, the actual heading of the velocity rarely matters, the speed is far more important. That's not saying that I think that going straight up from the Mun is going to be horribly inefficient, it's just going to be less efficient. The Mun's gravity isn't strong enough to make doing things in a less efficient manner that noticeable and also means that your TWR is going to be higher. Doing this from some place without an atmosphere but with a higher gravity, say Tylo, will cost you noticeably more. Also, I'd like to apologize if I'm coming off as snippy or like a dog that won't let go of a bone. It's not my intention, orbital mechanics are not the most intuitive thing so not understanding stuff like this is reasonable, I'm just in enough physical pain at the moment that my already less than impressive social skills are a bit frayed. EDIT: On the subject of the original post: I think that a large part of the reason a munar rendezvous isn't as effective as a lunar rendezvous mostly comes down to two factors. First, the fact that the landing, takeoff, and return burn take a lot less delta-v on the Mun than on the Moon. Second, the lower TWR of KSP engines means that there's a lot less to be gained by frequent staging, because you're carrying more inactive engine mass. I once did an Apollo-style Mun mission and had to create custom fuel tanks because the smallest 2.5m fuel tank had much more fuel than I needed for the landing, taking off, and return burn all by itself. One other possible reason is that the LEM was designed from top to bottom to be as light as possible, I read somewhere that there were parts of the craft where stepping on the craft while it was under full earth gravity would have put your foot through the panel. The Mk 2 lander can, on the other hand, weighs almost as much as the Mk 1-2 lander can on a per-kerbal basis.

Except that you are using it, and as was said, gravity losses. I also suspect that thrusting straight up doesn't benefit as much from the Oberth effect. Think of the gravity losses this way. Say you have a craft with a 2.0 TWR. This means that when you burn straight up, you lose half your thrust fighting gravity. On the other hand, if you burn at 60 degrees below vertical (30 above the horizon), you wind up with a vertical TWR of 1.0 and a horizontal TWR of 1.732. Gravity cancels out the vertical TWR, leaving you accelerating horizontally 73% faster than you were accelerating vertically. Then, as you gain horizontal velocity, the amount of vertical TWR you lose to gravity becomes even less because you're coming closer to being in orbit. Now, that first factor is scaled by the Pythagorean triangle type math, so the higher your TWR, the less important it becomes. At a TWR of 3, you're only accelerating horizontally 1.414 times faster than you would if you burned straight up. However, diminishing returns kick in and the horizontal acceleration is still higher until you have an infinite TWR. As for the first part (you are using it), that has to do with orbital mechanics. The specific energy of an orbit never changes, though unless you're in a circular orbit you're constantly trading between potential energy and kinetic energy. Basically, if your orbit's specific energy is higher than the potential energy at SoI altitude plus the kinetic energy of an orbit at that altitude, your orbit will leave the SoI (barring hitting atmosphere or terrain, or a delta-v burn) and your speed as you reach the SoI is determined strictly by how much more orbital energy you have than potential enery at that height (speed after crossing the SoI depends on the actual vector plus the body's vector relative to the parent body). If what matters is the orbital energy, then the heading of your velocity doesn't actually matter for purposes of exiting the SoI. That second part ignores the direction you're leaving, but that can be adjusted easily enough by proper selection of when you do your transfer burn. There is a corner case where an orbit with more energy than the potential energy at SoI altitude but less than that potential energy plus the kinetic energy of an orbit at that altitude may or may not exit the SoI, but that's usually not particularly significant unless your intention is to barely leave the SoI. If you're leaving with enough velocity to transfer somewhere, you tend to need enough extra energy that this is a non-issue, and if you're barely leaving the SoI then doing a transfer burn to go somewhere else, you're spending more delta-v than is necessary to get there. So, the most efficient way to leave the Mun and return to Kerbin isn't to burn straight up unless you've got an infinite TWR. On the other hand, while you do want horizontal velocity, it is probably more efficient to burn to SoI exit rather than doing an actual circularization burn, though to be honest, the difference between burning to orbit and burning directly to transfer are probably relatively minor. TLDR: gravity losses are real so you accelerate faster if you don't burn directly against gravity, and horizontal velocity is just as good as vertical velocity for leaving an SoI at any significant velocity.

Unity 5 should be in the next major upgrade, so 1.1, with no ETA on that update. There probably won't be a 1.0.4 unless something's wrong with 1.0.3. If I'm understanding what they've said correctly, work on 1.1 has been going on in parallel to 1.0.3.

The reason the devs have given in the past for that decision is that real scaling would significantly increase the time that it takes both to launch from and land on celestial bodies, increasing the "grind" factor of those two activities.

While I'll agree that that video card is quite likely the bottleneck, window's tendency to move a single thread between CPU cores, even when that thread is running at 100% utilization, makes that a bit harder to determine. A 100% utilization thread can look like a 25% load on each of four cores.

Threading physics simulation of connected rigidbodies isn't a trivial problem. In fact, I haven't seen anyone solve it in a general enough solution that it could be included in a physics simulation as the primary solver. So in this case, it's the software theory itself that isn't keeping up. As NoMrBond points out, we don't have a really good idea of how much of a performance gain we'll get out of 3.3. The closest I've seen to KSP-like uses involved a microbenchmark that indicated that 3.3 runs about 50% faster than 2.8.4 in that microbenchmark (testing connected rigid bodies). In my experience, real world uses seldom see as much benefit as microbenchmarks do, so while it won't shock me if we see a 50% improvement in the single-craft case, I'm not expecting it. And yes, there are other microbenchmarks where 3.3 beats 2.8.4 by a larger margin (orders of magnitude in one case), but I'd argue that those don't represent KSP's PhysX usage as well.

Also be aware that you're not throwing away as much as you think. The amount of science reported when you run an experiment indicates how much you will get assuming that you turned in the results right now, before you turn in a different but otherwise identical experiment. The total science you can get from a given experiment at a particular biome and altitude is capped, usually in the range of 100% to 130% of the science you'd get from a single return. What this means is that if you return two goo experiments from the same location, worth 100 science each, while the first one would get you 100 science, the second would get you considerably less, not even the 30 science that would get you to the cap. Unless it's changed from the last time I looked, you'd get 100*30/130 or slightly more than 23 points. The third one would get you 100*7/130, or about 5.4 science. Because of this, I don't worry about hitting the science cap and I don't intentionally do multiple identical experiments on the same mission.

Exactly. On a similar note, it was once estimated that there would never be more than one million automobiles in the US. The reasoning was sound at the time. It was based on the fact that a car was complex enough that operating one (including maintenance) was a full time job and they estimated that there would never be more than a million people that would want the job of chauffeur. That said, rockets are going to have to become greatly simpler and cheaper before this kind of expansion would take off. Then again, if we don't do the work to make it more accessible, the expansion will never happen.