Snark

Sure thing! Just to be really explicit, though, in case anyone's reading this post and missed my disclaimer above: Everything I say here, it's based on my general knowledge of the software industry, having worked as a professional software engineer in companies large and small for over 20 years. I don't work for Squad, and I have zero visibility into their management practices, their decision making process, the relationship their management has with the developers who are working there, or anything else. I'm a Squad outsider, same as you, and I don't have any more access to such information than you do. So, please don't read too much into what I'm about to say: it's not about Squad specifically, it's about the industry in general. An excellent question, with a simple answer: It depends. ...Okay, perhaps a bit more detail would be helpful there. Software engineering, like all engineering, is subject to finite development resources, and one has to make a judgment call about which of the following to prioritize: What we produce When we produce it At what quality do we produce it The old engineering joke goes: "You can have it cheap, high-quality, and on time. Pick any two." Everything's a trade-off. If you wanna ship more features, you either have to spend more time to get it out the door, or cut corners on quality. If you want to hit a deadline, you either have to cut features, or be willing to ship crap. If you want to ship a gold-star, armor-plated, high-quality product, you either have to cut features, or take a long time to produce. (Or you can pump more money and people into production, in an attempt to boost all three.) There's no single right decision. It completely depends on the requirements of the situation. My experience over the last couple of decades has been that for the most part (with some notable exceptions), this feature/time/quality triangle tends to get collapsed into a simple linear feature/time scale, with quality mostly out of the equation. Why? Details in spoiler section, because I can already tell this post is gonna be long. So, assuming that as a company you've made the usually-what-everyone-does decision to ship "really good, but not perfect" software with a reasonable investment in QA, this means you're down to a question of what versus when. It means that, broadly speaking, you have two ways to ship: Feature-driven: "We know what features we want to ship. We're going to work on it until those features are ready, and will take as much time as it takes in order to do so. This means we can't predict exactly when we'll ship." Schedule-driven: "We know when we want to ship; there's a date we need to meet, for some external or internal reasons. We will do whatever we have to in order to meet that date. This means we may have to cut features." It's not strictly an either/or; there's a spectrum. For example, you may be primarily schedule-driven, but you have some absolute-must-have features that you literally can't ship without, so you have to accept the risk that you may have to slip the schedule. (You want to avoid that if possible, because it gives you a black eye and erodes your credibility if you do it a lot, but sometimes it's unavoidable.) Generally, it's external factors that force a company's hand and determine whether a given release will be feature-driven or schedule-driven. For example, suppose you're a game company working on a major new release, and a big gaming convention like E3 is coming up nine months from now, and your business model and marketing and such is critically dependent on having a big "wow" release at the convention, and if you miss it you'll go out of business because you don't have enough venture capital to last another year until the next one. In that case... you gotta make that date. So you'll do whatever it takes to hit that date, which may entail working some long hours... but it also may entail scaling back the planned feature list and cutting features until you've whittled it down to something that you can get done by the deadline, but still has enough stuff in it to be sellable. On the other hand, you might have a case where you already have a product that's out there, working well, selling well. You're working on a new version that you'll be releasing to address some issues. On the one hand, there's no explicit deadline breathing down your neck-- it's not like "this has to be ready by 3:12PM on Thursday, six weeks from now, or we'll go out of business." On the other hand, you have to address these issues, otherwise what's the point of releasing? So in that case, you just work on those features until they're ready, then you ship, whenever that happens to be. Both cases happen. My experience is that the large majority of releases are schedule-driven, especially in larger companies where there are other big, heavy wheels with lots of inertia that also have to be set in motion for a release (e.g. marketing campaigns, scheduled analyst calls, tech support centers set up, supply-chain issues for hardware, documentation production, all kinds of other stuff). But feature-driven releases happen, too. Again, it depends on the company, its level of competence, and the business model it's chosen for itself. Many words in spoiler section below. I'll tell you three stories about three different hypothetical types of company, with three very different answers to the question you ask above. I'll call them Type A, Type B, and Type C, just for convenience. The executive summary: Ideally, this supposed conflict isn't actually a conflict, because the management and developers work closely with each other in an environment of mutual respect and support, since they're all playing for the same team. However, it's also possible to have a "use 'em up and spit 'em out" business model, where management treats developers as a consumable resource, and routinely just burns them out and then hires replacements. That's repugnant to me, of course, since I'm a developer and am therefore biased in the matter, but depending on circumstances it can be a successful business model for the company. One thing to note-- if you're outside the company (e.g. as a customer, looking on)-- it can be difficult or impossible to tell which of the above-described models it is, unless the company is so large and well-known and has so many ex-employees that conditions in the company are an open secret. But if the company is a small one, then it can be impossible for an outsider to tell. "Don't know" means "don't know". So, again, please take everything I say above as a general commentary on the state of the industry, and don't take anything I say as even the remotest speculation as to what category Squad might be in. No, it's critically important information that everyone up and down the chain-- from uppermost management down to the rank-and-file engineers-- needs to have front-and-center in their minds at all times. "What do I have to do, and how much time do I have to do it in." It's really important, because if things start looking tight, then some difficult and irreversible decisions have to be made, such as finding features that can be cut. But, again, the above applies to schedule-driven releases. There are feature-driven releases where they slip the schedule to meet the needs of the features, rather than vice-versa. My guess is that when Squad's working on KSP updates for the PC, they're primarily feature-driven rather than schedule-driven, thus all the player uncertainty and their reticence about announcing dates. I would also guess that where the console releases are concerned, they would tend to be more schedule-driven, since that involves cumbersome supply-chain stuff that has to be coordinated, and approval process, and all that stuff. I base these guesses on my general knowledge of how things work in the industry, and also on what I've observed from Squad's public announcements and actions. I suspect they're reasonably good guesses, but that's all they are, just guesses, and I could be wrong, since (like you) I don't have any insider knowledge of how they make their shipping decisions.

Guess. Go on, you'll never guess.

It is not just just discouraged, it's also explicitly against the forum rules (see 2.3.e). Note that Squad has always been reticent about release dates-- and quite properly so. It can be quite hard to predict how long it will take for software to be "ready", until you get really close to the end. Squad generally never announces release dates for any future version. In the past, generally the way one knows that a release is imminent is when they announce that the new version has been released to "Experimentals". Typically the full release comes within 2-3 weeks or so of going to experimentals. But that's also not set in stone-- the experimentals could drag on a lot longer, if a lot of issues get turned up that need addressing. (And speaking as a software engineer with a couple of decades of experience in the industry, I gotta say that I think they've made the right call, there. It's impossible to predict when it'll be ready. So if you're the company, and you make a prediction, you're going to be wrong, which means either you'll have to renege on it and say "Nope folks, we changed our minds"-- which will disappoint and outrage everyone-- or else you have to say "Well, it's not ready, but we'll just ship it anyway because we've hit the date"-- which will lead to a buggy and/or incomplete product, and lots of really unhappy users. So as galling as the current state of ignorance may feel... it's actually better this way. It's better not to know, than to think you know and find out that you're wrong.) Generally the way you find out when Squad will be releasing an update is when they say "Hi everyone, we just released it!" Note that I'm not a Squad employee and therefore don't have any more visibility into what they're going to do than you do-- I'm just describing what they've always done in the past. That's no guarantee that they'll do it this time around, just "this is what they've always done, so in the absence of evidence to the contrary, it's probably the most likely assumption this time too."

There's no code or config whatsoever in DefaultActionGroups for interoperability with ActionGroupsExtended, or vice versa. The two mods don't know about each other, at all. DefaultActionGroups works purely with the stock action groups, i.e. putting part actions into the groups automatically. I don't know anything about how ActionGroupsExtended is implemented, but what you just said there makes sense to me. One thing to bear in mind about action groups in KSP is that they're not actually moddable, and it's impossible for a mod to extend them. It is physically impossible to add action groups to KSP with a mod. (The technical reason, for the curious, is that they're implemented as a C# enum, which is a hard-coded list of constants that's graven in stone and can't be modified.) So. There are the special "named" groups like Lights, Gear, etc., and there are the Custom01 through Custom10, and that's it. That's all you get. "But Snark," I hear you say, "the whole point of AGX is that it adds all these action groups! How can it do that if it's impossible?" Simple: it's not actually adding action groups. (I believe that to be the case. I don't know anything about its implementation, I'm just deducing this from first principles.) I assume what it's doing is adding code and UI to act like action groups, but technically they're not action groups in the same sense that the stock ones are. If cleverly enough implemented, I imagine that it could be made so that the difference would be fairly transparent to the user. However, it would not be transparent to other mods-- they wouldn't be able to "see" those extra action groups unless they were given some sort of interop code to work specifically with AGX. With that in mind, then... it wouldn't surprise me if AGX were implemented to go ahead and use the stock action groups for those first several ones-- I know that's what I would do if I were implementing it. So... if that's the case, then I would imagine that DefaultActionGroups and ActionGroupsExtended would work together as follows: For the stock action groups, they'd work just fine together For the extra "action groups" that AGX adds, DAG can't see them and won't work with them at all. That's just a guess, though. I haven't actually run AGX myself, so I don't know for sure-- the only way to know would be for you to try it and find out.

Huh. Well, that's weird. No idea what's going on, there. No, it's just doing a plain-vanilla tweaking via ModuleManager, just like everybody does. If you look in GameData/OPM/, there's a file called OPM_CommNet.cfg, which contains config like this: @PART[*]:HAS[@MODULE[ModuleDataTransmitter]] { @MODULE[ModuleDataTransmitter] { @antennaPower *= 4 } } @CUSTOMBARNKIT { @TRACKING { @DSNRange = 2000000000, 50000000000, 2000000000000 } } See that "@antennaPower *= 4" ? That's where it's multiplying the range of every antenna by 4. Now look at JX2Antenna, in the "Patches" subfolder; there's a file called jx2_OPM.cfg. You can see it here. As you can see, it does "@antennaPower /= 4", i.e. divide all the powers by 4, to cancel out the multiply-by-4 that OPM does. You should be seeing 500k, i.e. the stock value. I have no clue what could be causing your problem. I tested this before I published JX2Antenna, and it worked as expected. Also, FWIW, it's been downloaded a few thousand times, and you're the first person to ever mention this problem-- if it were simply broken, I expect someone would have mentioned something by now. For example, by a happy coincidence, just recently in the post above yours, @Gorby1 was commenting precisely that he was happy that this fix was being done to OPM with JX2Antenna. So I assume it's working properly for him. Gorby1, can you confirm? Perhaps you and @NeuroticGamer can compare notes as to what's going on? Anyway, NG, all I can think of from your description is that somehow, your OPM installation isn't applying the range extension, I know not why. Are you running some old, pre-CommNet version of OPM, or something? What happens if you run OPM without JX2Antenna? Do you see Communotron as having a range of 500k, or 2M? You should see 2M. If you're not, there's something wrong with your OPM.

Hi @UranianBlue, and welcome to the forums! Thanks for sharing your ship. Just so you know: when you paste a huge block of text like that, it causes problems for people reading the forums. Not only does it make it inconvenient and awkward to read, but it can cause serious browser problems for anyone who happens to be reading the forum on a mobile device. When you need to paste something fairly big into a post, it's much better to use a "spoiler section" to hide it, so that you don't overwhelm people. (That's the little "eye" icon on the toolbar above your post when you're editing.) I've taken the liberty of editing your post to move your ship into a spoiler section for you. However... even with a spoiler section, it's still generally best not to paste huge files into the forum. There are better ways to do that. For example, if you want to share a .craft file so that other people can fly it, you can host it on some other site (like dropbox or whatever), and provide a link. In fact, there's a site called KerbalX that's specifically designed for just that purpose! So, for example, you can post your ship there, then copy the link for it and paste the link here. Much nicer for everyone. Yes, you can... everybody can. It's just a little fiddly, is all. The important thing is, don't try to "attach" them. It won't work. Instead, just do this: Post your image to some public image-hosting site, such as imgur.com. (Doesn't have to be imgur, that just happens to be the most popular one. It's really quick and easy, and you don't have to have an account in order to post an image on imgur.) When you're looking at your image in your browser (i.e. when you're looking at the image on imgur), right-click on it and choose "Copy image location". Now come into your forum post and just paste the URL. Presto! It will automagically convert itself into an in-line image.

Or, indeed, Explanation #3: The game developers don't care, because it was designed & balanced for gameplay reasons to provide a fun, interesting environment to explore that's challenging without being boring or over-difficult. ...which I suspect is the real reason. (And, frankly, just speaking for myself, I think that's the right priority and they made the right call.) ^ This. "Because it's a game and is supposed to be fun" explains an awful lot of things in KSP.

Actually, no, you don't. Imgur doesn't require an account, at all, if one simply wants to post pictures there. Yes, they allow having accounts, which allows doing extra things like "keep track of how many people have liked your posted image" and stuff like that. But if all you want to do is host an image there so you can embed it here in the KSP forums, you don't need an account at all. You can post to imgur anonymously, without needing to "sign in". Just go there, click the "new post" button, drag-drop your image, right-click to "copy image location", paste that into your KSP forum post. Bam, done. Two mouse clicks, a drag-drop, and a paste. That's it. Nope. They stick around forever. I have pictures that I posted years ago that are still sitting there, and I've never once created an account.

And the reason they have to eat their food in little bite-size pieces and can't swallow big things? Because their esophagus runs through the middle of their brain. And the reason their blood is blue? Because their hemoglobin equivalent has a copper atom in the middle, instead of iron. And <lots of other cool stuff>. Yeah, octopi are neat. Actually, @worir4, that has happened to people in real life, and it's a lot less fun than you might think: Sacks' book where he discusses this, The Man Who Mistook His Wife For A Hat, makes for fascinating reading. Anyway, back on topic: ...My personal vote for weirdest critter, though, has gotta be Dicrocoelium dendriticum. It has the weirdest, most wonderful life cycle I've ever heard of-- I mean, if I read a science fiction book in which an author made this critter up, I'd be shaking my head and saying "yeah, right, that's believable." It's a parasite that lives in the liver of ruminants such as sheep. Gets excreted in the animal's droppings. There it gets ingested by a snail. Snail leaves the parasite's cysts behind in its slime trail. Ants follow the snail, using the slime trail as a source of moisture. Here's the really cool (and, to me, jaw-droppingly amazing) part: Inside the ant, the parasite takes control of its brain to make it behave in a very specific way. It makes the ant leave the swarm, find a tall blade of grass, climb up to the tip, and then just hang on there. Having thus put itself in precisely the location where it's most likely to get inadvertently eaten by a sheep... it gets eaten by a sheep. And thus the cycle begins again. I swear, I'm not making this up. So yeah, that's my vote for weirdest. Oh, I'm a big fan of tardigrades, thus the avatar. But as far as I'm concerned, they're the coolest. This topic, however, is about the weirdest. And to me, Dicrocoelium is even weirder than water bears.

So, it used to be, pre-1.2, that it worked exactly the way you were expecting: first drain the center tank, then the outriggers, because of the way the fuel flow rules were set up. Now, in 1.2, by default, it's the other way around. Why? Because now tanks have this new-with-1.2 thing called "flow priority", and the highest-priority tanks are drained first, and by default, the earlier stages are given a higher priority than later stages. Since your radial tanks are attached by decouplers, they're being interpreted as "earlier stage", which means they get a higher priority and are drained first. However, it doesn't have to be that way-- if you really want it to be the other way around (i.e. drain the center first), you can make it do that. Turn on "Advanced Tweakables" in the game options. Then, whenever you have the right-click menu open for a fuel tank (either in the editor, or in flight), it'll actually show you the fuel flow priority (it's a number)... and you can edit it by clicking little + and - buttons. So you could make the center drain first by raising its priority higher than the outer tank's, if that's the behavior you want.

And not just artificial-- some have theorized that it's actually just a simulated moon in a computer game! Crazy talk, I know. Like this?

My theory of what they're working on is "Don't know means don't know, eventually we'll find out." Not bad, I suppose, though it's hardly my area of expertise. You've got the wrong etymological source of my username. (Like just about everyone, all the time... sigh.)

My guess is that it's because of this. Look at your parts, starting from the front end and working backwards, and their heat tolerance: Shock cone intake, 2400 K Fuel tank, 2000 K Command pod, 1100 K ...notice anything about these numbers? Note that I've quoted the max internal temperature tolerance, not skin temperature. The command pod actually has a fairly high skin tolerance of 2000 K, which I assume is why it has a reasonable ability to tolerate atmospheric reentry from space: it doesn't have to endure that heat a really long time, so it doesn't have time to accumulate an overall heat load. But if you're flying all the way around the planet, you're subjecting the craft to really high temperatures for a really long time. I assume that what's happening is that it's starting to heat up from the nose cone, since that's in front. It gets really really hot... and stays really really hot... which means it starts conducting heat to the fuel tank, which then starts getting hot itself, which then starts heating up the pod behind it. My guess would be that at all times, the intake is hotter than the fuel tank, which is hotter than the pod... but the pod has by far the lowest temperature tolerance of the three, so it goes kaboom first. And the reason you make it halfway around the planet is that it takes that long for enough heat to get built up and conducted back to the pod. ...which is why I'd guess that this would be exactly the way to fix the problem. Though heat shields don't enable fuel cross-feed, so that might cause problems draining fuel from the forward tank to feed the engine (unless you've got "fuel transfer obeys crossfeed rules" turned off and manually transfer fuel back from time to time).

Hm, that's odd. As far as I can tell from your screenshot, that fuel duct should allow fuel to flow just fine. Can you explain exactly what you mean by "doesn't work"? Are you saying that when you launch the ship, the nuke engine completely runs out of fuel and won't run and is deprived of fuel, while there's still fuel remaining in that central tank A? Or are you saying something else? What exactly happens that you don't like, here? (What I'd expect to happen by default, given the screenshot, is that the NERVs would use up all the B fuel first, then all the A fuel when B goes empty. Is that not what happens?)

Gotta say I'm not a big fan of the idea myself, for a few reasons. Problem #1: Suspension of disbelief. I have trouble swallowing it, since I don't think that any real spaceship ever does anything like this, at all. They're designed to enter at a certain orientation and maintain that orientation, and that's what they do. They're designed so that when they're in that orientation, they're fine, which means that no such system is necessary. Problem #2: Not really necessary. KSP already has a mechanism for this: design the ship to be able to handle reentry. Skilled players can get really fancy with it. Newbie players can just do the simple thing, which is what every single IRL spaceship except the space shuttle does: stick a heat shield on the front, and design the ship so that it's aerodynamically stable with the heat shield facing forward. Problem solved. Problem #3: Difficult to even make it work. A ship in reentry tends to be very strongly controlled by aerodynamic stability. Chances are good that even if you had such a system, it won't actually have the physical ability to turn the ship in a way that does any good, because there's simply not enough control authority available. Yes, it's possible for a skilled player to design a ship that has the ability to steer and orient itself even during reentry... but if they have that much skill, they also have enough skill that they don't need this thing anyway. Problem #4: I have trouble seeing how it would actually be all that helpful. KSP does a pretty good job of warning "this thing is overheating!" well in advance of it going kaboom. If you just watch the ship, and see something overheating, and steer that thing away from the blowtorch... how is that hard? Maybe this might be an interesting idea for a mod or something, but it really seems like a stretch to me to have it in stock-- especially given the finite development resources at Squad. Personally, I think their time would be better spent elsewhere.

Spinning objects can be complicated. Spears aren't a good example, because they're generally not spin-stabilized, and even if they were thrown with a spin around the longitudinal axis, it wouldn't be much. I suspect that the spear's stabilization is some combination of simple inertia (i.e. a long skinny thing has a big moment of inertia relative to its mass, so doesn't suddenly start spinning easily) and perhaps some aerodynamic stability (i.e. a somewhat heavy spearhead at one end, which wants to be in the front of the object as it goes through the air). I suspect that footballs also aren't a super great example-- I don't know what the ratio of maximum to minimum moment of inertia is, but I'd guess it's not that far removed from a sphere. The long pointy ends of a football are relatively narrow-- I'd guess that the moment of a football wouldn't deviate all that much from that of a soccer ball of equivalent mass. One example of a somewhat long, skinny object that is spin-stabilized around its longitudinal axis is a rifle bullet. However... it's not that long and skinny (like a spear or a rocket), and also, I think they tend to be pretty carefully machined, which I would imagine would hold them steady long enough to do the job. (I'm just hand-waving here, though-- I am not any kind of expert on firearms, I'm just speculating by applying general physics knowledge.) I suspect that part of the problem of trying to spin-stabilize a very long, skinny object is that its skinniness causes it to have a very small moment of inertia, relative to its mass. This means that unless you make it spin really fast, it simply doesn't have much angular momentum. If it doesn't have much angular momentum, it doesn't take much torque to point that angular momentum in a different direction. And given that it's long and skinny, that means any lateral forces applied at the ends have a big lever arm, meaning lots of torque to work with. So you've got a system that, on the one hand, easily generates big torques trying to move it off-axis; and, on the other hand, doesn't need much torque to make it go off-axis. And in the specific case of a rocket: unless it's only going straight up, then its path needs to curve as it ascends, and a spin-stabilized rocket is going to have problems with that-- if it has enough spin & angular momentum to provide useful stabilization, that's going to make it resist staying prograde as the trajectory curves... and any torques that try to force it prograde (e.g. via fins on the back) are going to cause precession, like a wobbling top, which would be a Bad Thing. Put that all together, and I suspect we're getting at most of the reason why rockets tend to be aero-stabilized rather than spin-stabilized.

The usual answer to this problem is: Heat shields, plus a good transfer window. If you use a tool like http://ksp.olex.biz, you can see that arriving in Kerbin LKO from Moho will put your Pe velocity at only ~1700 m/s above circular LKO speed, in other words, you'd be hitting atmosphere at around 4000 m/s. That's eminently easy to handle via aerobraking... as long as you have a heat shield. If you're coming in a lot faster than 4000 m/s, it means your transfer window wasn't great; the solution is to use a better window for the trip. If you don't like spending ablator, you can use the inflatable heat shield, which has no ablator and can be re-used. Or just leave it inflated all the time. ...the above design happens to use some modded parts, but you get the idea. Discussion here:

Well, feel free to post that over in the Suggestions forum...

Actually, this is the exactly diametrically wrong thing for aerodynamic stability. You want the CoM to be as high as you can make it. You want the CoM to be right up there at the front of the rocket. When a rocket flips during an ascent, the problem is that the CoM is too low-- specifically, it's below the center of dynamic pressure. To be stable, the CoM has to be above the center of dynamic pressure. There are two ways to accomplish this (not mutually exclusive): Raise the CoM. Lower the center of dynamic pressure. (This is what "put fins at the back" does.) Thus, the standard mantra for aerodynamic stability: Heavy, pointy bits at the front Light, draggy bits at the back Definitely would like to see a screenshot, though-- that should quickly clear everything up and we can give you specific suggestions to fix the problem.

This topic has been extensively pruned (removed or redacted many posts) in order to clean up: various off-topic comments personal attacks bickering about personal attacks arguing about arguing deliberate attempts to provoke rage responses to attempts to provoke rage, from people who should know better C'mon, KSP forums, you're better than this. Since it's clear at this point that this thread can't stay on track without going off the rails and exploding into massive fireballs at regular intervals, 'fraid we gotta lock this one, folks. I'll close with a few bits of Moderator Finger-Wagging, and then some friendly advice. First, the finger-wagging: Don't troll. Please review the forum guidelines, specifically rule 2.3.b. Troll-posting, or making posts that are intended to provoke an emotional reaction, is against the rules. If you see a troll, report it. Since trolling is against the rules, it's absolutely the right thing to do to report it-- that's what the report function is for. We're the moderators, we'll deal with it. Don't publicly accuse a troll. Deciding that someone's a troll (or breaking any other rule) isn't your job, it's the moderators'. Taking on moderator's jobs for yourself can be construed as "backseat moderation" and may, itself, be a rules violation (see rule 3.2). Don't publicly announce that you've reported someone. More backseat moderation, folks. And finally, the friendly advice: If you think someone is a troll... do not feed them. If someone actually is a troll, their whole mission in life is to get a reaction out of you. They're specifically looking for sore spots and hot buttons that they can press. When you give in, and show them that they've gotten your goat, they win. You reward their behavior, and they double down on it and persist. C'mon, folks, this isn't your first rodeo. I know that you know better. I assume you've gotten caught up in the heat of the moment, and hey, we've all been there. But any time you're responding to someone on the forum and you find yourself brimming over with rage... perhaps just stop and think for a moment, take a few deep breaths, maybe step away from the keyboard and consider. It's never a good idea to post angry, troll or no troll. But it's an especially bad idea to post angry when that's exactly what someone is trying to get you to do. By far the best response to someone whom you think is a troll is to do just three simple things: Ignore them Report them Move on. Thank you for your understanding.

This is fairly easy, if you know the secret handshake. You can do multiple tank transfers concurrently. Let's say you have one big orange tank full of fuel, and N smaller, identical-to-each-other tanks that are symmetrically arranged and which you need to have identical amounts of fuel in, so that you'll have an even mass distribution. You can select as many tanks as you want (right click the first one to select, then hold down ALT while right-clicking additional tanks to select them). Once you have selected the big orange tank and all the little ones, just click the "out" button on the big orange tank. Presto: propellant starts concurrently flowing into all the little tanks, symmetrically. Unfortunately, this is hard, though it seems silly that that's the case. The stock game doesn't give you any tools to do this; you just have to eyeball it. Unless you come up with some hacky design trick, like including some small empty tank on your mining vessel that you can use as a "measuring spoon". Fill up the little tank completely (thus guaranteeing even LF + O), then empty that tank into your target tanks. Repeat. ^ Same problem as the "equal fuel + oxidizer" issue. Just have to eyeball it, there's no precise way to do this in stock unless you're using a "measuring spoon". Annoying, yes. So, to summarize: Equal amounts in multiple tanks: yes Equal LF versus O: no Precise amount transferred: no

Hello, You didn't say exactly what version you meant. Just to be clear: If anyone wants one of the free versions of KSP (i.e. really really old), you can download them right here: But anything after that, isn't free and can't legally be shared. Doing so would constitute software piracy-- please don't do it, or even discuss doing it. That's a strict forum rule (see 2.2.a). Thank you for your understanding.

Welcome to the forums! Moving to Mission Reports, since 1. this is about KSP, not actual science & spaceflight, and 2. this sounds like a request to discuss KSP flights, which is generally what Mission Reports is for.

Okay, folks, here's the second time the moderator team has had to step in to tidy things up. Snipped out a completely pointless off-topic exchange in which this thread, which is supposed to be about Mars colonization, got derailed into pointless bickering over the supposed meaning of a non-English word that itself has nothing whatsoever to do with space, Mars, or anything else. Last time, I gave a gentle reminder that the topic here is Mars colonization. It's pretty much still the same folks here, so I know you don't need another reminder (right?), but... the topic here is Mars colonization. Do you think it's a good idea? If so, why? Do you think it's a bad idea? If so, why? That's the topic. Please try to keep things in perspective, and let's be civil, please. Thank you for your understanding.

@gowthamn: Other than the suggestions already made, another option to reduce eclipse issues is to put your comms network not equatorial. Doesn't necessarily mean they have to be in polar orbits; just inclining the orbits by 20 or 30 degrees will reduce eclipses quite a bit, given that you're orbiting 2000 km up. If you're putting them in perfectly equatorial orbits, then they're guaranteed to be eclipsed by the Mun on every orbit, and by Kerbin on every Mun orbit. Just an option among many, FWIW. The simplest option is to just "don't timewarp through an eclipse", and/or "put enough battery power so they can last through an eclipse" (it doesn't take much).