Eric S

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.

I'm normally a proponent of not keeping user data files (persistence and craft saves, for example) in the program directory, but even I see that it wouldn't fit well with KSP, especially how KSP is often played.

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.

Do you know you're 5' 7" because someone measured you, or can you eyeball it that close? Eyeballing tends to be off by percentages, not by units, so it's as likely that your eyeball guess will be off by about an inch as theirs will be off by two and a half centimeters. The same goes for just about any measurement that isn't based on something in the environment where the estimate is being made, be it distance, speed, mass, etc. And as someone who's feet are right at the upper range of what most shoe stores carry but still a hair shy of a foot long, I can tell you that it's kind of off on its approximation unless the US shoe industry is ignoring about half a bell curve worth of customers.

I'd suggest starting a thread describing your problem. Post pictures of the rocket, describe your ascent profile and at what point it flips (especially in relation to staging and your pitch maneuver, both are critical times). I follow those kinds of threads and occasionally chip in, and if the OP is actually interested in learning the new system, they inevitably do. It usually doesn't happen without a little back and forth, as frequently the first suggestions posted don't actually fix the entire problem. I'd also recommend reading this thread if you haven't, though admittedly it doesn't go into details on TWR or a proper ascent profile. That said, I can see how the new aero system is less friendly to the new players. Then again, unless we revert to the older aero, the flipping issue will never go away. It might become less pronounced, but you really don't have many options to get rid of it without losing many, if not most, of the improvements of the new aero system.

I'm in agreement that we really need more stuff to do on existing planets than we need more planets to go to, though I'm not opposed outright to the idea of spending developer time on more planets. That said, I think Squad should definitely make sure that they've closed every detectable memory leak before spending any development time on other planets. Prioritizing any other asset management improvements/fixes that they have planned would probably also be a good thing. Adding more planets in a situation where you're already memory constrained and/or leaking memory would be bad prioritization. Don't get me wrong, I'm not saying that they have to add dynamic asset loading or other things like that. I actually thought they came close to, if not achieved this in 1.0, but they've backslid by the time of 1.0.2, and I'm not sure that the heat gauges are the only issue.

I'm not sure if people are answering the question you're trying to ask here. If you're thinking that a retrograde orbit of Kerbin would be a more efficient orbit to reach the Mun because of the direction you'd be approaching the Mun, this is not the case. With a retrograde orbit, your velocity would be added to the Mun's velocity to determine the relative velocity, instead of being subtracted from it, meaning that your insertion burn in Munar orbit would have to expend more delta-v to circularize.

I'd recommend this tutorial for some tips on understanding the forces that go into rocket flipping. Beyond that, I'd say: Do an actual pitch maneuver and then gravity turn rather than the old 10km up then pitch 45 degrees. The amount of the pitch maneuver needed will depend on the TWR of the craft and when you do it. Higher TWR or higher altitudes mean having to be more aggressive with the pitch maneuver. Complete your pitch maneuver before going near Mach 1. Because of how aerodynamics work, the flipping tendancy is at its worst near Mach 1, and I find trying to punch through Mach 1 before doing the pitch maneuver leaves me having to make a very aggressive pitch maneuver. Try to be pointing straight prograde during staging events. Not only does this help boosters not get shoved into your central core, but staging tends to be a critical point in rocket flipping because you're usually discarding something with low mass but a lot of surface area, meaning your CoM won't move much, but your center of pressure does. When in doubt, post asking for advice. Include screenshots of the craft in question, a basic description of your ascent profile, and at what point the flipping happens. Probably the only thing more frustrating than trying to help someone deal with a flipping rocket when your own attempts at launching that rocket fly with no problems because you're not recreating the situation accurately enough is being the person with the flipping rocket.

That's generally been rocket advice, to the best of my knowledge. Spaceplane ascents might use that rule after switching from air breathing to rocket propulsion in 1.0, but I haven't played around with enough spaceplanes in 1.0 to know if that has become the case. Prior to 1.0, my rocket engine phase was usually short enough that it didn't really didn't matter as my apoapsis was far more than a minute ahead of me.

More specifically, the drag of that thing is going to be so high that the presence or lack of nosecones is going to get lost in the noise. Even just struts have a very pronounced effect on drag.

I'll agree with both rcp27 and Master Tao, it looks like you're trying to fly the old ascent profile, and that doesn't work well with most rockets. I'd go with four fins on the center stack, 45 degrees off of the cardinal directions. That should be enough to keep it on track with a more gradual pitch maneuver. I'd also look at moving as much of the radial mounted parts into a service bay as possible, as I've noticed that too much radially mounted stuff at the top of the rocket really amplifies any tendency of a rocket to flip, since radially mounted stuff isn't occluded. If you can send Bob instead of Bill and have unlocked EVA, you can move the goo containers and science junior below the heat shield and extract/reset them with Bob, meaning that you don't need as many goo containers and you don't need them to survive reentry. I'm not sure if non-scientists can remove the results from experiments in 1.0.

That sounds nothing like my experience either, so I'd like screenshots, notes of what mods you've got installed, etc.

Development is still going on, the devs have been talking about 1.1 and mentioned that they think they have "years" left to go before stopping development. As for the memory leak, it has been mentioned as being fixed in 1.0.3, though they haven't released that version yet. There are three ways to work around the memory leak, one of which leaves the temperature meters still functional.