Eric S

Why would you have the same amount of thrust? My large rockets tend to have similar TWR and payload percentages compared to my smaller ones (once they're large enough to use mainsails that is). The only time I've got a lower TWR is if the payload is fragile. No, that's your goal, not mine. Mine is to minimize the cost of the operation. Since we don't have maintenance costs, the cost of a kethane mining operation amortized over it's lifetime does nothing but go down as you get more use out of it. True, but I don't think the difference is that great. You gain 3% on liquid fuel conversion, and the large converter weighs 4 tons, which is a drop in the bucket on a large kethane processing rig. An all-in-one kethane processing vehicle saves you a docking operation, though I'll admit that's more an issue of convenience/time than fuel. If you're lifting a payload with an interplanetary transfer stage that either goes somewhere other than Eve/Duna or returns, and I'm lifting a payload without an interplanetary transfer stage, my launches will be smaller, so sooner or later, I'll not only catch up with you, but pass you. The large ship is a one time cost, which just like a general kethane mining operation, the amortized cost approaches zero per mission as you use it for more missions. As for career mode, as others have pointed out, we already know that mods can work in career mode, and just the stock game won't work if they limit the tech tree to one part per node, as the number of nodes that they've discussed are fewer than the number of parts in just the stock game. All that said, I'm not saying you're wrong, but more that you're evaluating this from a different point of view. I'm pretty sure that we both agree on the following: If you're not using kethane, none of this makes sense. If you need to refuel, you'll do at some point along your trip where you're going to stop anyway, at which point LKO is much more likely than Minmus. If you're doing this for a single mission and that mission doesn't involve taking a kethane processing rig with you, it's just adding a lot of parts and work. You need to use something like this over multiple missions (or in the case of a mobile refinery, multiple places within a single mission) for it to be of benefit. And to get back to the point of the OPs question, while it can be a fuel-lifted-from-kerbin saving maneuver, you'd doing it more because Minmus is where you get your kethane than because of the savings of the one specific maneuver.

OK, first of all, it's not worth arguing over doing this without Kethane, and I don't think anyone has said it's a good idea if you're not mining kethane. As for doing it with kethane, you're overlooking a lot here. First, you're measuring everything in delta-v, which makes sense to an extent for a single craft mission. You're talking multiple launches, probably different size craft, etc, at which point just summing the delta-v is inaccurate to the point of being virtually meaningless. If I lift a 300 ton mining operation in a single lift, the total fuel expended would probably be about the same as if I broke it up into three or four missions, but the summed delta-v is going to be radically different. Second, you're assuming that your idea of an efficient kethane operation is the same as mine. To be honest, I do my refining on the surface. At the quantities that I mine/refine kethane, the mass of the converter and the solar panels or generator is inconsequential. The fact that you get more mass out of the kethane than you put into it is a minor issue at most, certainly less of an issue than having to launch so many missions to do it your way. Third, you're assuming that fuel is fuel is fuel. Which for the most part is true now, but when career mode gets a budget, then the fuel you get from Minmus for the cost of infrastructure is going to be far more efficient than the fuel you have to pay for, and then pay for a craft to lift, when you amortize that infrastructure over several missions. For those of us who already play like the budget matters, it's a win now. Here's how I do it. Step one: Launch a self-sufficient automated drive section with kethane processing built in. Most of the craft on the launch pad is the processing unit, the craft itself is going to handle it's own circularization and transfer burn. Step two: Take that craft to Minmus and process fuel. Step three: Launch the payload on a craft that's just big enough to get the payload to Minmus. Step four: Pick up the payload with the drive section. Step five: Use the drive section to take the payload wherever it needs to go. Step six: The payload section does it's business. Step seven: Use the drive section to take the payload back to Kerbin. Step eight: Do just enough of an aerobrake to capture, drop the payload so that it continues to aerobrake and then reenters, and take the drive section back to rendezvous with Minmus. Step nine: Refuel at minmus. Step ten: Plan a new mission and repeat steps three through nine until you start feeling that this makes the game TOO easy. I used the same drive section for 1) a kerbal'ed eve landing/ascent mission. 2) a kerbal'ed Laythe landing/ascent mission. 3) a grand tour, landing everywhere but eve and laythe. 4) another eve landing/ascent mission when I wanted to try it a different way. If you're only doing a single mission that doesn't involve kethane processing, then yes, the amount of work necessary for the infrastructure isn't going to make up for anything. And if delta-v is your currency, you're right. I can't imagine a situation where that's really the case though. Just changing the mass of the payload changes the delta-v you get out of the same amount of fuel. Redesigning the craft moving fuel from one stage to another can alter the delta-v of the overall craft even if the fuel stays the same.

I'll second KER. It actually gives more detailed information than MechJeb does, without the temptation to use the autopilot. On the other hand, MechJeb does provide most of the information, so if you want an autopilot (or a fly by wire system, for that matter), it will provide the important information.

I think a bigger issue is that if any of the computers are running slower than real time due to physics calculations, they should all slow down, at which point what NTP is providing isn't relevant except as a baseline, so you might as well focus on what will be relevant.

Very much this. Planetary transfer windows are significantly wider than the time it takes for a single orbit in LKO. Never feel like you have to transfer THIS ORBIT. If you don't get it set up in time, start setting one up for the next orbit. Seriously, Even Moho windows are several days long if you're willing to adjust your travel time. For a Duna transfer, you can launch 5 days early or late for a cost of about 40 m/s delta-v. I usually spend that much just fine tuning my transfer once I'm out of Kerbin's SoI. http://alexmoon.github.io/ksp/ gives a nice visualization of the increased delta-v it takes to launch early or late. Well worth playing around with even if you don't use it to plan your transfer, just to give you a feel for how early/late launches affect the budget.

Surprisingly enough, the Oberth effect is more important than the orbital speed you could use. An orbit with apoapsis at Minmus height and periapsis at 80-100km is close to planetary transfer velocity at periapsis. Right on the first point, wrong on the second, depending on your purpose. Ships departing from Minmus, either by direct departure or by dropping the periapsis to LKO, spend less delta-v on achieving orbital transfer velocity from the point of refueling than refueling in LKO. Still not worth doing if you don't have a kethane based refueling operation at Minmus, but it bumps up the surplus delta-v in case something goes wrong.

Strictly a matter of how the indicators are displayed/what they mean, the flight characteristics don't change.

Does a mix of standup and funny music, probably more of the latter, but I've recently become aware of Tim Minchin. The kind of comic that pops wheelies as he goes over that "gone too far" line, but worth a listen.

Designing elegantly minimalist craft. Feature Creep thinks he's my friend, he's always hanging with me, getting me into trouble, etc. My first mission to Jool started as a single unmanned craft that would drop six probe craft, one for each moon and one for Jool itself. It ended with a 300+ ton mothership with a crew of 12, kethane refining abilities, two landers, greenhouses for life support, etc. Yeah, sometimes Feature Creep is nice to hang with, but not all the time.

The devs mentioned that Friday on their livestream, that they wanted people to focus on the problems, not what they saw as the easiest solution, because while a 64 bit client would ease memory problems for those players that had more than 4GB of ram and a 64-bit OS, it wouldn't help anyone that didn't have both, but memory optimizations within the game or engine would benefit everyone.

If you're having fun, you're probably doing it right. I do missions with and without MechJeb, depending on what factors I consider important for that mission. Sometimes I'm doing a challenge, either from the forums or from reddit, in which case I stick to the allowed mods if any, as otherwise, there's no real way to compare results for the mission. Other times, I'm wanting to test a ship design, at which point the piloting skill isn't what I want to measure, so it isn't particularly relevant, and letting mechjeb babysit the craft means I can do something else. I'm well beyond the point where keeping the ship aimed at the maneuver node marker is interesting or challenging in most cases.

As you can tell from the various answers, the question has to be more specific in order to get an actual answer, as it can be applied to many things. When most people talk about wanting a 64 bit version of KSP, they're referring to the instruction set, in this case the AMD64 instruction set which AMD created and Intel licensed. While there are possible efficiency improvements, the most noticeable change between AMD64 and the previous standard of x86 is that the former can address more than 4GB of RAM fairly easily. On the other hand, 32 bit vs 64 bit can also refer to the size of data, where a 64 bit integer has much greater range, and a 64 bit floating point value has much more precision.

What new content are you thinking should be coming that isn't part of career mode? Neither the home page nor the FAQ discuss the game features at all. The About page mentions existing features, and except for "And a whole lot more!" only mentions career mode stuff as planned features. The "planned features" page of the wiki is the only one of your three references that discusses any planned features other than career mode, and I've always taken that page with a grain of salt given the "Please note that these features are not a commitment, and the dev team is not under any obligation to implement them all." message at the start. Even then, there's not that many things on that page that could really be called content. Mining absolutely. Enhanced IVAs, sure. Improved aerodynamics, probably but we're already starting to stretch the idea of content. More planets? definitely, but that's bottlenecked behind the observatory, which is probably bottlenecked behind the research tree that they're currently building. Are you saying that you're expecting career mode to come faster? That's a bit more reasonable, from the outside at least. I don't know how much of the career mode is based on the infrastructure they're building now, how complex that infrastructure might be, etc. I already know both of these. I can't name a single thing I could have spent the current price of $23 on that would have even come close to providing the entertainment value that KSP has already given me. If a meteor struck Squad HQ and 0.21 was the last version of KSP we ever saw, I wouldn't feel ripped off, just disappointed that I didn't get even better versions. As for capitalism, your expectations and desires don't really enter into that. You paid for the game, and when it's done, you'll get it. No delivery date was specified, and the specification of what would be delivered didn't deal much in concrete or measurable qualities of the game to be delivered. Yeah, that's a cold and harsh way to put it, but capitalism can definitely be cold and harsh. tldr: The things you mention aren't supporting your point of view as well as you think they are.

What part did you use for your inflatable modules? If it doesn't change it's drag coefficient, then the overall drag isn't going to change unless you've got FAR installed.

That shouldn't come as too big of a surprise. Because of the scaling of the solar system, reentry velocities tend to be quite a bit slower. For example, LKO orbital velocity is less than a third of LEO orbital velocity.

Very much this. I've been playing since 0.18.0, follow as much dev info as I can find, and almost every time, the availability of the download was the first official announcement. I seem to remember once a tweet broke the news 30 minutes before the new version was downloadable, but that's about it. I remember a lot of people who were certain that the ... can't remember what they call it, a full weekend of stuff on Twitch, some of it from the devs, some of it from popular streamers... at any rate, several people were certain that the new release would come out in conjunction with the last event of that weekend, because that's how it had happened the last time they did a weekend like that. They were wrong. More recently, several people were certain that the newest release would come out just prior to KSP going on sale for Steam's big summer sale because it wasn't save compatible with the previous version, and that wouldn't be a nice thing to do to people that just purchased the game. Again, they were wrong. I don't know when the actual decision is made, but anyone that knows for sure probably isn't allowed to say. I haven't seen any evidence that Squad knows sooner than a day or so out when they'll be releasing. I'm sure they have expected dates for updates to land, but from what I've seen, the time between them saying "It's ready" and "Send it out" is very short for this industry.

Continuing to ascend to orbit after cartwheeling the entire launch craft. And laughing all the way.

I'm pretty sure that it's the former, as the devs have stated that mods that aren't updated to hook into the research system will not appear in career mode, but will still appear in sandbox mode. They've also said that research will be about unlocking existing parts. You'll start a career mode save with very few parts, and then as you spend research points, you'll unlock more parts. So I don't think they're talking about improving existing parts or adding a ton of new parts through research in 0.22

Other than lack of multiple physics threads, I'm not sure the MP issue can be blamed on unity (as in I don't know, not that I know that unity itself isn't an issue), but yes, from what I've read while following various MP mod attempts, much of the difficulty is on how KSP was programmed. It's along the same issues as making a single-threaded program multi-threaded. In a single-threaded program, it's fairly common to do things that assume that the running code is the only thread and therefore requires no locking or semaphores to ensure that things don't get changed in the middle of a function without that function's knowledge. Changing code written to run as a single-threaded program to multi-threaded isn't trivial in the case of non-trivial programs unless you're doing a half-assed multi-threaded implementation with global locking, because assumptions that are valid in a single-threaded program are no longer valid in a multi-threaded program. The same thing is true between single player games and multiplayer games, assumptions can break. As for any limitations placed by unity, the devs have already ruled out changing engines beyond updating to newer versions of Unity. We switched to a much more recent version of Unity back in 0.18.3/4, and the devs are currently evaluating the latest Unity update.

Because KSP wasn't designed with MP in mind, and a lot of the design decisions at the code level would have to change. One of these decisions is the design that the craft that the player is currently controlling is the center of the universe, and you can't have multiple centers of the universe. How many of those games involve speeds of 2 km a second where variation of less than a single meter can make or break a mission? How many of those games involve enough computation that they can't realistically all be done on the server computer? For that matter, how many of those games would cope with a computer that can't run the current simulation in real time? These are just a few of the issues that make KSP almost the perfect storm for a game that is hard to make multiplayer, even without the design decisions that make it harder. I hope not, I don't see any way for KSP to function as an MMO. The kind of sync that we're talking about should be possible on a LAN, but I don't see it happening as soon as you try to cross the internet. As for LAN multiplayer, I'm not saying that it can't be done. I'm saying that if it weren't difficult, one of the multiple programmers that have tried to implement MP KSP would have succeeded. It's not like the only people to have taken up the challenge were teaching themselves programming while trying to achieve this. To do it right will take either the devs focusing on rewriting the parts of the game that make MP difficult to implement (which means that they're not working on other stuff), or a lot of work by the modding community, and it's far from certain that it can be done that way.

As I understand it, they don't want to add any more planets and moons until they've sorted out the mechanism for discovering and exploring new celestial bodies, so you don't get full info on them as soon as they're in the game. You'll probably know the orbit of the planets, but anything past that may require science in some form.

To be honest, I think the only way timewarp would work well as a game mechanic in multiplayer KSP is when a few friends get together to do a specific mission together. "Hey, lets do a multiship colonization mission to Duna!" would work because once everyone gets their ships into orbit, you can say "OK, everyone do your transfer burn on your next orbit, then we'll timewarp till we reach the first place for course corrections.", "Hey, let's all pick a planet and send a lander there!" wouldn't, and the idea of a persistent world gaming environment where several people do unrelated stuff in the same world would be right out. While I suspect that this is more viable than having one computer do all the calculations, assuming non-trivial ships, it brings issues of it's own. If one of the computers has to run in slower than real time due to part count, then both of them have to slow down by the same amount and at the same time. Synchronization is just touchy. For example, if you're trying to dock two craft in LKO, they may not be moving very fast relative to each other, but they can be moving over 2 km/sec relative to their SoI, so even just 0.01 a second of jitter in the sync means craft bouncing around 20m, which would make docking kind of hard. Sending craft-relative info may work better in that case, but not in others. Don't get me wrong, I wouldn't mind seeing multiplayer in KSP, and I do follow things like this, I just don't see it as easy as some people think it should be.

It takes some trial and error to get the periapsis in the right place, but it's not as hard as you make it sound. Your orbit around Minmus is fast enough that you have a good bit of flexibility, waiting an extra orbit changes where the periapsis would be just over a degree, which is well within the margin of error if you're trying to eyeball the ejection angle, and not too far off even if you're using protractor or the like. The big exception is Moho, which has a very narrow transfer window. I've done this more than once, and while there are losses due to having a less than perfect periapsis and inclination, I have yet to have a planetary transfer that doesn't come in at least 300 delta-v below what it would take for a transfer from LKO, even after course corrections, assuming I get everything close to right. If I blow the periapsis timing, I can easily spend twice what I "saved" with midcourse corrections, which is why I always suggest quicksaving before attempting this.

It's not, though. You're basically saying that timewarp is the single most important part of multiplayer, everything else is just aesthetics, and that if you can manage that, everything else will be easier. In my opinion, there's enough challenge accurately synchronizing data between multiple players that the level of timewarp becomes just one more piece of data that needs to be synchronized. If you can't synchronize ship positions/velocities well enough to allow for the level of interaction you want, then timewarp is moot. If you can synchronize the data, then you're just deciding how to decide on the level of timewarp, which is a UI problem, not likely to be less manageable than the synchronization issues. This isn't to say that timewarp may ultimately prove to be "the" deal breaker to multiplayer, but that result isn't likely to be the case, and if it is, it will be because of UI issues, not technical ones.

I think it's more that we're not measuring the same thing. This is in fact the case. Worse than a wash, actually, if you spend delta-v to circularize at Minmus. However, here's where we got to the part where we're not measuring the same thing. The OP is talking about running a kethane-based refueling operation on Minmus, so I don't think he's interested in total delta-v expenditures, but rather the maximum delta-v expenditure between the pre-refueling phase and post-refueling phase. In that case, there's less delta-v expended departing Minmus with a low-kerbin periapsis where you do the rest of your transfer burn. This usually beats departing directly from LKO by at least 400 delta-v, if you're not counting the delta-v to get to the refueling station against that maneuver, which means that as long as your post-refueling-phase delta-v budget is higher than your pre-refueling-phase delta-v budget, you will be able to get by with a planetary transfer stage that has that much less delta-v (or the same stage, but with a higher safety margin). I think that for most planetary transfers, the delta-v savings are closer to 600 delta-v, but it's been long enough since I've done this that I'm not certain I'm remembering it accurately. The last time I did this was back in 0.18.2. If you're looking at the total delta-v expenditure, then yes, this is more costly than refueling at LKO or departing directly from there, depending on whether you needed to use your transfer stage to circularize. If you hadn't spent the delta-v to capture into a Minmus orbit then leave it, then the delta-v expenditure would look like a regular two-kick departure, so whatever delta-v you used on those two Minmus-related maneuvers would be an extra cost.