Flotillas: A Primer in 3 Chapters PLUS APPENDIX FOR 0.25

[Geschosskopf]

CHAPTER 1: THE BASICS

This guide will consist of a number of chapters in separate posts. I'm doing it this way to avoid a single huge WOT and also to break it up into functional chunks.

NOTE: In 0.25, MJ got a new function: Advanced Transfer to Another Planet, or (ATTAP). This makes the handling the launches and departure burns of the flotilla ships MUCH MUCH easier than originally presented below, although the underlying thinking for flotilla design remains the same. So, you still need to read the original chapters but don't pay so much attention to the details of doing the launches and departure burns. Then read the new appendix for 0.25 and ATTAP, which is the 2nd post on Page 4 of this thread.

INTRODUCTION

A flotilla is a group of ships all leaving the same place on the same day for the same destination. While you can send flotillas to Mun and Minmus, the short travel times and the fact you don't have to wait on a launch window make this unnecessary and overly complex; better there to send 1 ship, let it arrive, then send the next. Thus, this guide only discusses interplanetary flotillas, the need for which is created by launch windows (actually, departure or transfer windows) only happening every so often. As such, this guide is intended for players who are already familiar with sending single ships on interplanetary missions and want to up their game.

So why send a flotilla instead of a single ship? Well, it depends on mission complexity. The more things you want to do, the bigger a single ship becomes, which makes it harder to launch/assemble and control, the more fuel it burns for the same delta-V, and you start running into part-count issues. Also, eventually you'll have to start compromising on mission capabilities or even drop some things you originally wanted to do. Plus, you also run the risk of a single failure scuppering the entire project, and will then have to wait a long time for rescue. With a flotilla, OTOH, you can put each mission task on a separate ship and thus optimize it for that particular job. Each ship will thus be smaller with all the advantages that entails, and a failure only impacts that part of the overall mission. Plus, you can build in redundancy and self-rescue capabilities.

That said, there are drawbacks to flotillas. First, you have to launch a lot of stuff and make many dockings. Then you have to do the transfer burns for all the ships on the same day, one after the other. This can take a substantial amount of your real time, especially if you have long burn times and lots of ships, so you might have to reserve most of a day off for it. And you have more ships in flight, which might be an issue for you depending on your hardware. But that's really the extent of the disadvantages and they're worth it for the enhanced mission performance and survivability you get for it.

A common fear for 1st-time flotilla users is that multiple ships will arrive simultaneously and they won't be able to do what's needed (like aerocapture) for 1 ship before having to do that for the next. While this might be a problem at Mun or Minmus (which is why you don't send flotillas there), it's not a problem anywhere else. In general, you'll be burning the ships at least 15 minutes apart and each burn will have a little error in it. Over the course of an interplanetary trip, these slight differences will translate into plenty of time between ship arrivals. Eve is the worst case with arrivals only a few hours apart but that's plenty. While you might not be able to finalize the orbit of 1 ship before dealing with the next, you can at least get them aerocaptured and their Pe's out of the atmosphere before the next arrival. Elsewhere, there'll be days or weeks between arrivals.

So, that's what flotillas are and a nutshell comparison with doing the same mission with a single ship. If you're still interested, read on.

I. IMPORTANT GENERAL CONCEPTS

I.1 Modularity

To fully reap the benefits of having a flotilla, you want to build for modularity. That is, you have payload modules for specific tasks and tug modules to move them around. All these modules should have large docking ports at least for where they'll be connected while under thrust, to avoid wobbles. It's best to have big docking ports on both ends so you can stack multiple modules as needed, or mix and match to create expedient ships or stations with various capabilities you hadn't thought of before you left. Modularity begets flexibility.

If some modules require small docking ports, make sure several other modules also have at least radially mounted small docking ports. But in general, try to avoid small docking ports unless absolutely necessary like for small landers and spaceplanes.

I.2 Probe Cores All Around

Every single module needs a probe core and the power to keep it running. This is so you can send crewless modules around on their various tasks at the destination, whether they had crew originally or not. In fact, you'll probably need this anyway for launching and docking all the modules because few, if any, will have Kerbals aboard. In general, you'll put all the Kerbals in 1 or 2 ships at most and their mission equipment in however many other probe ships that will all rendezvous at the destination.

Also, if you're into MechJeb, every module should have that, too.

I.3 No Ship Left Behind

One of the main risks to flying flotillas is forgetting about 1 or more ships in the early part of the trip when they're all doing the same things in quick succession. You have to make sure they all do their departure burns, all leave Kerbin's SOI, all do their mid-course tweaks, and eventually all arrive. The solution to this problem is Kerbal Alarm Clock, which brings us to the next section.

EDIT: I.4 Quick-Save Frequently

By this point in your KSP career, you should be hitting F5 just before you do something major and just afterwards if it goes OK, and pretty much every time you have nothing better to do. There are scads of points in dealing with flotillas that you should quicksave after. Every time you put something in its parking orbit, every time you complete a departure burn, etc. I shouldn't need to elaborate.

II. ESSENTIAL TOOLS

II.1 Kerbal Alarm Clock

This mod is an absolute necessity for doing flotillas. It's the only real way to keep track of everything you need to do. If you don't have it, get it, because it's quite useful even if you don't do flotillas. When you have it, set it up as follows:

• Display 20-50 alarms before scrolling
  
• Use KSP time
  
• Use the "Model" for determining transfer windows
  
• Automatically create SOI-chance alarms 5 minutes prior
  

II.2 Kerbal Engineer Redux

This is primarily useful for determining if your landers have sufficient TWR to take off from different planets. It's also good for determining if you've got enough delta-V although MechJeb is a bit more trustworthy on that.

II.3 RCS Build Aid

You'll be doing a LOT of docking so you'll need to design your modules so they translate cleanly without unwanted rotation. This mod is THE thing for that.

II.4 MechJeb

Yes, this is essential. Even if you normally don't use it for single ships, you need it for flotillas. And seriously, if you're at the point in your KSP career that you're doing interplanetary flotillas anyway, you no longer have to prove your machismo by doing everything by hand. When you have maybe 20 ships to launch, then 10 dockings and 10 (usually long) transfer burns to do in batches, you'll be very thankful you have MJ, even if you normally think it's a cheat. Install it on every module. Use it as desired or needed. But at least have it so you know how much delta-V a given module has left in case you need to extemporize a rescue.

That's it for the basic groundwork. Next up, actually getting started on your 1st flotilla.

TO BE CONTINUED

Edited November 8, 2014 by Geschosskopf
added importance of quicksaving

[Rhyunix]

An interesting guide

[Geschosskopf]

CHAPTER 2: ASSEMBLING THE FLOTILLA

III. SET MISSION GOALS

You need a plan so developing one is the 1st step. First, you set the big-picture, strategic objectives. To justify having a flotilla, you need a fairly large and/or complex set of objectives; otherwise you could probably do it with a single ship. Generally, if the set of mission goals involves going to multiple moons and/or inclinations in the destination area, and/or multiple very different tasks, and/or involves returning some ships and leaving others behind, it's a good case for doing a flotilla. For example, a set of mission goals that would justify a flotilla could be to send an expedition that will

1. map both Duna and Ike with SCANsat,
   
2. scan both for Kethane,
   
3. gather and return all possible science from the Duna/Ike system,
   
4. leave behind a permanent station in Duna orbit, and
   
5. set up a Kethane operation based on Ike to supply the flotilla during the mission and be ready for future expeditions.
   

Once you've got your mission goals, you can start envisioning how you'll accomplish them, which lets you start designing the ships you need. The above list will be our example for the rest of this guide.

IV. DESIGNING SHIPS

The general process is to look at your list of mission goals and separate them out into jobs for individual mission payloads, then build both these payloads and a way to move them around. While doing this, you also consider which tasks can be combined in a single payload and which have to be done individually, which determines how many ships you need and their general characteristics. General guidelines for making these decisions obviously include whether something will stay there or come home or will need to operate simultaneously in different places. But another one is high operating inclination. Generally, you want to keep your main pieces close to the equatorial plane, so things like mapping probes that live in polar orbits, even at the same planet, should be separate from permanent stations that will serve as ports for this expedition and any future one.

So, let's consider our example Duna expedition starting with the mapping jobs. Ike is close enough to Duna and has low enough gravity that a single probe can do both. But while SCANsat mapping requires a polar orbit, there's no real need to do Kethane from more than about a 35^ inclination at either place because you're very unlikely ever to use Kethane at higher latitudes due to the wastage of fuel required for significant plane changes to get back into equatorial orbit where you need the product. This suggests 2 probes, as follows:

• A SCANsat probe to do both Duna and Ike. Assuming it will capture into polar orbit at Duna, it needs enough delta-V to get down into a near-equatorial orbit, transfer to Ike, and get back into a polar orbit there.
  
• A Kethane probe to do both Duna and Ike. It will do a similar flight but only go to 35^ inclination instead of polar so doesn't need as much delta-V.
  

Next, we need to gather Science! For this we need a Duna-capable lander with all the science parts we want to carry. This lander will also work on Ike and its science parts will be used as well to get data from high and low orbits at both places. The Duna orbit data can be obtained as the lander enters the Duna system. The lander will then need to make 2 sorties down to Duna, one for surface and one for "flying over" data. It will also need to make 4 trips to Ike, for high orbit, low orbit, surface, and "just above" data.

This lander will be our main fuel-consumer during the mission and will thus define the size of the Kethane operation we need. We also need a Mobile Lab to rearm the goos and bays between lander sorties, and this could also serve to store all the data, which makes more role-playing sense than storing it all in a capsule (we'll have dozens of stored experiments at the end). So the Mobile Lab will also be the core of our return vehicle. This gives us 2 more ships:

• Duna-capable lander that can also get from low Duna orbit to the surface of Ike and back on a single tank. The round trip to Ike is about 2000m/s, less than what a chute-less lander should have to be safe for a round trip to Duna, so no worries there.
  
• A return vehicle built around a Mobile Lab and whatever else we want to attach to it. The Mobile Lab at least must be capable of landing safely on Kerbin.
  

Now we need to consider the permanent Duna station. This only really needs to be 1 or more big fuel tanks for the Kethane system to fill up and these can be the same tanks used to move the station out there. But we want living quarters for the crew and, for role-play, a 2nd Mobile Lab that will do imaginary science from orbit. The return vehicle and the lander will dock to this station during operations at Duna so the station needs multiple docking ports. Mobile Labs need a crew of 2 to function, we want to return 2 Kerbals with the data, so that means 4 Kerbals total. And because the lander and return vehicle will dock with the station at Duna, all the Kerbals can ride out in the station in a single Hitchhiker. This suggests the following:

• A permanent station consisting of a Mobile Lab, a Hitchhiker, a fuel tank, and a number of docking ports.
  

This leaves the Kethane system, which can be quite complex if you want high efficiency. But the Duna-Ike system doesn't require high efficiency so we'll just put everything on 1 vehicle. This means drilling and refining both on Ike and delivering finished LFO and mono to the station. The main question thus is how much fuel we need to move at once. Counting fuel used in taking off from Ike, rendezvousing with the station, and returning to Ike, such a system will deliver a little less than 1/2 the fuel it starts with to the customer. The lander will need a major refueling after every sortie that lands so you need to deliver at least that much each trip, more if you want to cut down on the number of tanker runs and if you have space to store the extra at the station. And of course the return vehicle will need some fuel to get home if it didn't bring enough with it to start with. So decide on how big a rig/refinery/tanker ship you want and build it, keeping in mind that you have to get it off the ground and to Ike. So, now we have:

• A Kethane ship consisting of 1 small Kethane tank, 2 small drills, 1 small refinery, power to run them, and lots of LFO tankage for finished product.
  

This gives us a total of 6 mission payloads, meaning the flotilla will consist of 6 separate ships.

1. A SCANsat probe for Duna and Ike,
   
2. A Kethane probe for Duna and Ike,
   
3. A lander for Duna and Ike,
   
4. A return vehicle including a Mobile Lab that can land on Kerbin, in which 2 Kerbals will come home,
   
5. A permanent station with a Mobile Lab, Hitchhiker, and some number of tanks, in which the expedition crew of 4 will go out, and
   
6. A Kethane-processing fuel tanker
   

All these payloads need to get out to Duna and 1 needs to come back. 4 will need to dock together but the 2 probes never need to interact with anything so don't need docking ports. Simple rockets with sufficient delta-V will work for them. But the other ships will need at least transfer tugs. Depending on how heavy you make things, you can built the transfer engines on a permanent attachments, disposable stages, or separate tug modules docked on in orbit. It's generally handy to go with docked transfer tugs because this increases flexibility. And being able to remove the tugs to a separate orbit helps keep part count under control when you dock the station, return ship, and lander together.

NOTE: It's VERY important to build ships with reasonably short transfer burn times. First, remember you have a whole flotilla to burn and the longer each one takes, the more of your time it will take. Also, the longer the burns, the less accurate they are and the more they interfere with the burns of other ships. Thus, in general, try to build for transfer burns of about 5-6 minutes, which takes a TWR of about 0.75. Don't go over 10 minutes or you'll hate yourself. If you can do less than 5 minutes, by all means do so. If some of your ships are small, light probes, try to give them conventional transfer stages instead of nukes, so their burns will be 1 minute or less.

V. LAUNCHING THE FLOTILLA

Launching means getting everything off the ground into parking orbits and docking whatever needs it. This is NOT done at the so-called "launch window". "Launch window" is a misnomer; it's really a "transfer window".

V.1 Timing the Launch

The actual launching and docking process is time-consuming, both in gametime and realtime, so needs to be done some time before the transfer window comes around. There will be the inevitable failures requiring redesigns, which will consume even more time. It takes a couple of game days to get a typical flotilla all up and docked, so I recommend starting the process a least 1 game week prior to the transfer window.

However, as soon as you get everything up and parked, you'll start having second thoughts, realize you've forgotten some vital part on a ship, discover 2 modules won't dock, or think of a better way to do the mission. This means de-orbiting and replacing 1 or more ships, which also consumes gametime and realtime. Therefore, getting started a month of gametime before the transfer window is probably better, especially if you need to do a lot of designing and testing of ships, tugs, and lifters beforehand.

NOTE: When docking payloads and tugs, do the rendezvous with whichever module is lighter because this will burn the least quantity of fuel for the same delta-V. But once the modules are close enough, always control the payload during the actual docking. This preserves the payload's ship name for the completed assembly, which is the name you'll be looking for when searching the map and alarm lists for the ship you're interested in.

Anyway, when you decide to send a flotilla somewhere, you need to set an alarm with Kerbal Alarm Clock to tell you when to start the launch process. Just create a transfer window alarm and give it however many days or months lead-time you feel comfortable with. Get all your ship design and testing done before this, so when the alarm goes off, you can start launching and docking immediately.

V.2 Executing the Launch

Launching puts things in parking orbits and the purpose of parking orbits is to prepare for the transfer burns. Executing the transfer burns is inevitably a bit chaotic but you can reduce the chaos by carefully executed launches. IOW, don't just throw your ships into the same orbit one after the other. This adds to the chaos of departure.

As will be discussed in the next chapter, when doing the departure burns, you'll need to be able to quickly find and select individual ships off the map. So what you want to do is space your ships' parking orbits out both horizontally (in the same orbit) and vertically (at different altitudes). Horizontally, try to keep spacing in the same orbit no closer than about 1/4 of an orbit, 1/3 is a bit better, so 3-4 ships max per orbit. Vertically, put ships into orbits spaced about 25km apart, which is enough to clearly distinguish their paths on the map. So say 100km, 125km, and 150km, which is enough for a flotilla of 9-12 ships.

Don't worry about interlacing the spacing of ships in different orbits because that isn't necessary and won't keep anyway in the time between launch and departure. But before firing the engines of any launch, look at the map. You just want to put the ship into whichever orbit has an open space at the time. You might have to wait on the pad 10 minutes or so until and opening comes around, and then launch to that orbit's altitude.

And don't forget the note mentioned above on how to dock payloads and tugs. You want the finished assembly to end up in the proper place so that's the place you launch whichever module will hold still while the other rendezvous with it.

Anyway, that gets your flotilla from drawing board to parking orbit. All that's left is whatever last-minute adjustments you want to make and then send it on its way. That will be the subject of the next chapter.

TO BE CONTINUED

Edited February 18, 2014 by Geschosskopf

[Geschosskopf]

An interesting guide

Thanks but it's just getting started

[Geschosskopf]

CHAPTER 3: GETTING THE FLOTILLA UNDERWAY

VI. THE DEPARTURE BURNS

Designing, building, testing, launching, and docking all the mission modules is rather boring and takes a lot of your time, with nothing to show for it except a crowd of ships in LKO. Then you wait and second-guess yourself until the day of the transfer window, when it's too late to make any more changes and you have to do the departure burns. This is also time-consuming and all you have in the end is a bunch of ships in interplanetary space, but it's at least hectic enough to stay exciting. And it's also the last great chore in the whole flotilla process. From here on, the workload decreases dramatically and you start appreciating the investments you've made up to this point.

VI.1 Departure Preparation

At some point between launching and the day of departure, you need to create a maneuver node alarm in Kerbal Alarm Clock for each ship in the flotilla. It's a good idea to create the alarm for a ship as the last step in its launch process once its in parking orbit, so you don't forget it later and leave it behind when the others leave. Note that these alarms are simply a checklist to make sure you burn all the ships in the flotilla. You will not actually use any nodes created now except maybe the earliest one, and the other ships will not actually leave at the times you set. But the pop-up boxes for these alarms will be your checklist, which you check off as you burn that ship, and they all ensure you begin the departure process on the day of the transfer window.

Because you launched at least a week before the transfer window, the nodes you'll be creating for these alarms will be many orbits in the future. To make sure they get set for the correct time, use MechJeb to create the nodes. The process goes like this:

1. Set the ship's target planet
   
2. Open MJ's Maneuver Planner, scroll to the "Transfer to Another Planet" function, and click "Create Node". DO NOT EXECUTE THIS NODE. This creates a node at the proper time at the proper ejection angle for the trip.
   
3. Open Kerbal Alarm Clock and hit "Add Alarm". This defaults to coming up as a maneuver node alarm. Make sure the alarm will be attached to the active ship and give it about 30 minutes of lead time. Save the alarm.
   
4. Repeat process until all ships in the flotilla have such alarms, making sure all have the same amount of lead time. Read the alarms off the KAC list to make sure every ship has one.
   

At this point, there's nothing to do but fast-forward until the earliest alarm in the flotilla goes off. But before you do, make sure you yourself are ready. Each burn has to be done in realtime so getting the whole flotilla underway will require the sum of their burn times plus time in between to do various other tasks. This requires a fairly substantial amount of realtime, so don't start burning until you have enough contiguous free time to get it all done.

VI.2 Doing the 1st Burn

So, you have the free time required and are ready to go. Now just fast-forward until the earliest node alarm for the flotilla goes off. Now you have about 20-25 minutes of realtime to set this ship up to do its burn. This ship and all others will require you to do a pre-burn checklist so I'll cover that here, but remember you have to do these same steps for each ship.

1. When the alarm goes off, click "Jump to Ship and Restore Maneuver Node".
   
2. Check the "Delete on Close" button for this ship's alarm and close the alarm, removing it from the KAC list. This means you're committed to burning this ship now. If for some reason you don't actually burn it now, you'll have to create a new alarm for it so you don't forget it later.
   
3. Set "Control From Here" to an appropriate part. This is necessary because it might have been different during previous docking. Also, if the ship has Kerbals aboard, control will default to their part, which might not be a good thing if it's facing backwards or sideways.
   
4. Make sure only the engines that will be used in the burn are active and shut all others off. Often necessary after docking.
   
5. Make sure all fuel tanks to be used in the burn are turned on, if you'd turned any off previously.
   
6. Gently tap the SHIFT key once to run the engines at the lowest possible thrust for about 5 seconds, then hit X to cut them off. Each time you switch between ships, KSP forgets how much thrust its engines have so can't calculate burn times for nodes, which means you don't know when to start the burn. Doing this little "blip" of the engines makes KSP remember how your engines work so it can calculate burn times.
   
7. Go to the map view and set your destination planet as target. Each time you switch between ships, KSP forgets what your target was. KAC claims to remember your target if you set the option that way, but I haven't had this work for me.
   
8. Open MJ's Maneuver Planner, scroll to "Transfer to Another Planet", and click on "Remove All Nodes". This node was created at least a week ago and you did the "throttle blip" a minute ago, so is no longer accurate.
   
9. Create a new transfer node however you want, manually or with MJ.
   
10. Execute this node either manually or with MJ. Believe me, after the 1st couple, you'll want MJ to do them.
    

Somewhere during the above process, 1 or more node alarms for the other ships in the flotilla will certainly go off. Ignore them but DO NOT CLOSE THEM. Just drag their pop-ups off to the side of the screen and keep doing what you're doing with the active ship. The crowd of alarm pop-ups will be your accountability checklist to make sure you burn all ships in the flotilla.

Anyway, 1 burn down, however many more to go.

VI.3 Doing the Other Burns

OK, so the 1st ship is on its way. Now you have to switch to another ship and do it. Ignore the order in which their node alarms went off. What you want is the ship in the best position to do its burn. So go to the map view and focus on Kerbin. The path of the ship you just burned will show you where the transfer node needs to be relative to Kerbin, so look for a ship that's at least 1/4 to 1/3 of an orbit away from getting to that point. This is why you need to space your ships out in their parking orbits during the launch phase; it makes finding the next ship to burn much easier. Anyway, decide which ship icon is in the best place to burn next, mouse over it to learn its name, then jump to it using KAC. If that ship's alarm has already popped up, jump to it using that. If not, jump to it by clicking on its name on the list of upcoming alarms. Jumping between ships with KAC usually works better than doing it with KSP's built-in mechanism.

Once you're at the next ship, the 1st thing you'll see is all the popped-up alarms in the center of the screen again. So drag them out of the way again. Then go through the same pre-burn procedure listed above for the 1st ship. Close and delete this ship's alarm, set control from here, blip the throttle, delete and recreate the node, etc. Then do its burn, ignoring and dragging away any more alarms that pop up in the meantime. And once this ship's burn is done, repeat this whole procedure for the next and the next, until they're all done.

Now, do a couple of checks to make sure you've burned all the ships. All the node alarms should be dead and gone. Each ship should now have a new alarm set for leaving Kerbin's SOI in a few hours so make sure they've all got one. Finally, focus the map back on Kerbin and make sure nothing you want to take with you is still in orbit. Once you're sure everything's on the road, pat yourself on the back and celebrate with an adult beverage of your choice. You've successfully launched your 1st flotilla.

NOTE: It sometimes happens that Mun is in the way when it comes time to do the burns. Usually this isn't a disaster-the ships are going by way too fast for this to screw up their trajectories unless they pass VERY close or run into it. HOWEVER, even a distant fly-by is a problem because you have KAC set up for automatic SOI change alarms, which interfere with other burns. So before lighting off the 1st burn, make sure Mun's not going to be a problem. If it is, just fast forward a little until you can get by it without an encounter. A few hours more or less on the transfer window doesn't make enough difference to worry about.

VII. LEAVING KERBIN'S SOI

You've done all the burns and the members of the flotilla are all on escape trajectories away from Kerbin. Even for insane flotillas of over 20 ships, the 1st ship should still be in the vicinity of Minmus' orbit by the time you burn the last one. Thus, you have some hours of gametime to wait before any leave Kerbin's SOI. And you'll know when this happens because you set up Kerbal Alarm Clock to create SOI-change alarms automatically with 5 minutes lead time. So there's really nothing to do at this point but admire your work, take some "last look at home" screenshots, and fast-forward until the 1st SOI alarm goes off. When that happens, jump to that ship and delete its alarm.

Now, you're at the 1st ship about to leave Kerbin's SOI. Go to the map view, zoom in until the ship's blue line fills about 1/2 the screen, and put your cursor over the far end so you can see the time until it happens. Then go to 50x warp, keeping the cursor on the end of the line as it moves toward the ship so you can read the time all the way in. When it gets to about 1 minute, slow down to 10x warp and keep it there until the SOI change happens and the blue line gets drawn out towards the target planet. You'll probably have to zoom the map out some to see this happen. Once this happens, go high warp again until the next alarm goes off. Then jump to that ship and repeat the above process. Then repeat for all remaining ships in the flotilla.

You shouldn't have to worry about other alarms popping up while changing SOI for a different ship. By the time they all get out near the edge of Kerbin's SOI, there will be way more than 5 minutes between ships. But if this does happen, just ignore the alarm and remember that it includes a 5-minute cushion so can't happen until the ship you're flying now has already done it's change. Then jump to the open alarm without warping. Nothing to it.

NOTE: This method of doing SOI changes at 10x warp is one you should use in all situations, whether you're doing a flotilla or not.

VIII. FINAL NOTES

Unless you're going to Eve, this is probably the end of the hassle unique to flotillas. From this point on, it's very unlikely you'll be dealing with more than 1 of the flotilla's ships at a time until they all meet up at the destination. They'll be doing their mid-course tweaks at different times and will probably arrive days, weeks, or even a month or 2 apart at the destination. And even at Eve, they'll at least be hours apart and you only need a few minutes for the critical maneuvers for any one ship. If you can get a flotilla off the ground and on the road, you can handle its arrival at Eve.

So from this point on, it's all profit. It's just a very cool thing to have lots of separate ships all at once at the destination. It's so useful and it gives you a feeling of having founded a space empire instead of just being a transient presence. So go ye forth and fill space with swarms of ships until your CPU begs for mercy.

I hope you all enjoyed this guide and found it useful. Feedback and differing opinions welcome.

[DerekL1963]

You forgot one all important, must not be forgotten, point - F5 is your friend. (Almost as important is "keep notes - preferably on a pad next to the keyboard so you don't have to swap windows".) "Never get involved in a land war in Asia" is a distant third.

[Geschosskopf]

You forgot one all important, must not be forgotten, point - F5 is your friend. (Almost as important is "keep notes - preferably on a pad next to the keyboard so you don't have to swap windows".) "Never get involved in a land war in Asia" is a distant third.

And "never go up against a Sicilian with death is on the line!"

But seriously, D'OH! I can't believe I forgot that. I'll have to go edit that in.

[DerekL1963]

OK, studying the guide further... I'm not at all clear why you think Eve is such an issue. It's Jool that's the bear for me. Even with ships arriving days apart, it's quite possible to have three or four ships strung out between the boundary of Jool's SOI and your circularization burns. (If you aerobrake, it's even more complicated.)

[Geschosskopf]

OK, studying the guide further... I'm not at all clear why you think Eve is such an issue. It's Jool that's the bear for me. Even with ships arriving days apart, it's quite possible to have three or four ships strung out between the boundary of Jool's SOI and your circularization burns. (If you aerobrake, it's even more complicated.)

Flotillas arrive at Eve with the tightest spread in time, usually only 1 to 4 hours apart. Thus, you get the same sort of thing as at Jool with multiple ships in the "approach pattern" between SOI entry and aerobraking. In both cases, you have the same worry: can I get Ship A in a safe orbit before I need to switch to Ship B? The reason this is a worry is because while you're flying Ship A, Ship B is getting closer to the air or to the last point you can adjust its Pe before the air.

At both planets, the critical interval where you really have to fly a ship to make sure it ends up in the right place lasts about the same amount of time. The difference between the planets, though, is that at Eve, this critical time interval is a significant portion of the difference between ship arrival times. This is definitely not the case at Jool. A ship just entering its SOI is at least a week away from Pe, often more, so there's no worry at all that you'll be flying Ship A while Ship B lithobrakes or gets slingshotted Kod knows where.

So for an Eve flotilla, it's often the case that you have to aerocapture Ship A into a highly elliptical, big Ap orbit just to buy time because you know it'll take it a day or more to make the circuit, by which time all the other ships will have arrived. Immediately it's clear of the air, you jump to ship B and aerocapture it however seems most efficacious at the time. Then Ship C. Then you might have a chance to go back to Ship A and tweak its Pe a bit so next time it comes around, it'll end up where you want it. Then here comes Ship D, after which you jump to Ship B and tweak its Pe, and so on. Sometimes, you might have to tweak a Pe completely out of the air and park that ship just to take it out of the equation for the time being, then bring it back in a few orbits later once things have settled down.

You only run into this sort of thing at Jool if you're determined to aerobrake directly into an encounter with whichever moon you're going to, or to at least park in an elliptical orbit out that far in hopes you'll eventually get an encounter without having to burn again. Due to the long intervals between arrivals, this is the only way to end up with a bunch of ships all orbiting Jool and needing attention more or less at the same time. If you're willing to do more burning, however, you can avoid this at Jool entirely.

[DerekL1963]

Ah, OK. As it works out, Eve is one of the few places I haven't sent at least a pair of vehicles to so that wasn't obvious.

Another thing I noted; VI.2/9 Sometimes MJ will calculate a node in the next window rather than a few minutes away in the current one. If this happens click "Remove All Nodes", time warp forward four or five minutes, then try again. You may have to do this several times.

[wasmic]

I see that I should build some bigger flotillas. My current record is four launches to Jool at the same transfer window, but they didn't do anything with each other after launch. My record for most interplanetary ships at the same time, though, is probably over 0 - all heading to some planet (or Dres). Nice guide, there's a few of the tips here that I could have used earlier

[Captain Sierra]

I see that I should build some bigger flotillas. My current record is four launches to Jool at the same transfer window, but they didn't do anything with each other after launch. My record for most interplanetary ships at the same time, though, is probably over 0 - all heading to some planet (or Dres). Nice guide, there's a few of the tips here that I could have used earlier

My current record is about to be 8 inbound for Duna. Base, Station, and various shuttles and ERV craft for a massive kethane operation.

sidenote

I don't get why people find it so hard to get over 50% returns with kethane mining. I can get 50% returns on Duna for kod's sake! Even more on the Mun. If I build it properly, the tankers can get 60% yield off the kualli gas fields (yes, I name my kethane deposits, it makes things sound cooler).

/sidenote

Another thing, I have some minor disagreements about the necessary mod list.

RCS Build Aid - not required

I've done enough docking that I can place RCS pretty well. You can tweak fuel out to see dry CoM and you can always include enough SAS torque (a single reaction wheel unit usually does the job) to compensate for slight offcenters.

MechJeb - highly recommended

For the automation of burns and transfer planning, you'll want it, but you can technically do it without it. Just be ready to want to claw your eyeballs out.

That's it. Engineer, while also not required, is highly recommended as the alternative is hyperedit "simulation" testing.

[problemecium]

This is the kind of tutorial I dream of making ^^

In fact, you sounded a lot like me in the first part with your emphasis on modularity and ability to recover from issues. I design all my large ships as a conglomeration of self-sufficient modules, and until now I thought I was the only one obsessive enough to be doing that.

Edited March 2, 2014 by parameciumkid
Turns out refreshing the page turns line breaks into "<br>" tags.

[problemecium]

I can tell you meant 10, but it was too funny anyway when I read it and thought "well gee, I for one would be ashamed if my record weren't over zero..."

...I just double posted. Oppz. I didn't mean to! I just had one thing to say and then something else to say... xP

[Geschosskopf]

sidenote

I don't get why people find it so hard to get over 50% returns with kethane mining. I can get 50% returns on Duna for kod's sake! Even more on the Mun. If I build it properly, the tankers can get 60% yield off the kualli gas fields (yes, I name my kethane deposits, it makes things sound cooler)./sidenote

Let's assume you're using the kethane to refuel ships that will never touch the ground themselves. In such a case, efficiency comes from 1) moving kethane itself, not finished product, and 2) moving only the kethane itself, not the drills, refineries, and their powerplants. Thus, maximum efficiency comes from having at least 3 separate units: a drilling rig that stays on the ground, a refining station that stays in orbit, and a kethane tanker lander that goes back and forth between them. And of course before that you need a probe to find the kethane, although it can go out by itself in an earlier window. But having 3 separate units means you have to do a flotilla, which most folks are afraid to do. Thus, they lower their efficiencies by having all-in-1 kethane plants, and/or by moving finished product instead of kethane.

In my example Duna flotilla above, I took the least-efficient option: moving finished product along with the refinery, drills, and power. On the Duna-Ike run, this has about 40% efficiency. But that's enough for the purpose of refueling a lander and the return ship. It shouldn't have to make more than a couple of trips. If that's all you need, then why bother setting up a high-efficiency operation? You've already got 6 ships in the flotilla as it is; efficiency would add at least 2 more. Besides, this example mission to Duna was just to grab the science and go home, leaving the core of a station for future expansion. The assumption is you'll be going back next time with colonies in mind, and can set up a better kethane thing then.

At other places, you can't afford such inefficiency even at the get-go. For instance, Jool. The main focus of any Jool expedition will of course be Laythe, but it's stupid to refuel space-bound ships from the surface there, leaving Vall as the only practical source. But it's a significant trip between Vall and Laythe, so you really need an efficient set-up. That's where you put every function in a separate unit. In fact, you'd need at least 5: a drilling rig on Vall, a kethane tanker lander, a refining/transshipment station at Vall, a kethane shuttle between Vall and Laythe, and a 2nd refinery at Laythe. You can probably get about 60% efficiency delivered to Laythe that way. But this operation will require a decent flotilla itself, on top of the flotilla of stations, colonies, and spaceplanes going to Laythe. The main question, therefore, is whether you combine them into a single flotilla of a dozen or more ships, or do them separately.

Another thing, I have some minor disagreements about the necessary mod list.

RCS Build Aid - not required

I've done enough docking that I can place RCS pretty well. You can tweak fuel out to see dry CoM and you can always include enough SAS torque (a single reaction wheel unit usually does the job) to compensate for slight offcenters.

Well, that's your loss, and RCS Build Aid is intrinsically better than tweaking tanks empty anyway. If you don't want to use it, don't. But IMHO it's a requirement to do many things right, which is the whole point of doing them at all. It should be a stock feature.

[Tangle]

Certainly good for explaining! At some point, I'm going to send a mission to Duna, complete with fake food supplies, and a prepackage flotilla will certainly be part of it.

[Geschosskopf]

Certainly good for explaining! At some point, I'm going to send a mission to Duna, complete with fake food supplies, and a prepackage flotilla will certainly be part of it.

Good luck with it. Once you do a flotilla, you'll never do a single monster ship again

[Specialist290]

Let's assume you're using the kethane to refuel ships that will never touch the ground themselves. In such a case, efficiency comes from 1) moving kethane itself, not finished product, and 2) moving only the kethane itself, not the drills, refineries, and their powerplants. Thus, maximum efficiency comes from having at least 3 separate units: a drilling rig that stays on the ground, a refining station that stays in orbit, and a kethane tanker lander that goes back and forth between them.

I understand it's more efficient to keep both the drilling station and the refinery at "fixed" points, but is there a reason you keep the refinery component in orbit with the fuel depot rather than on the surface with the drill, and have the fuel shuttle transport raw kethane rather than processed fuel? I've heard some advocating the other approach before for their own kethane facilities, and I'm wondering how these two approaches compare.

[Geschosskopf]

I understand it's more efficient to keep both the drilling station and the refinery at "fixed" points, but is there a reason you keep the refinery component in orbit with the fuel depot rather than on the surface with the drill, and have the fuel shuttle transport raw kethane rather than processed fuel? I've heard some advocating the other approach before for their own kethane facilities, and I'm wondering how these two approaches compare.

Kethane defies common sense in that it weighs less than the amount of LF/O/MP you can make out of it, by a fairly significant amount. You gain mass by refining kethane. Also, the refining process has built-in inefficiency in terms of units, so X units of kethane converts into Y < X units of whatever finished product, and Y weighs more than X. Thus, if you refine on the surface, you already have less product than you had kethane in terms of units. And it's heavier so you burn more fuel getting it orbit than the same units of kethane would cost you.

[Specialist290]

Makes sense. Never did that much digging into the properties of kethane when I was still using the mod more regularly, and I guess I never caught on to the fact that the fuel was actually heavier than the kethane itself.

[Jouni]

In the Jool system, mining kethane at Pol is certainly a viable option. While getting back to Laythe often requires improvisation due to Tylo and Vall, I get something like 70% efficiency with a single ship.

[Amaroq]

A couple of notes on Kerbal Alarm Clock -- it has a setting you can do without a maneuver node, just specifying by "time", I tend to do that for my flotillas.

Also, there's no need to put your launch alarms "on top of" each other as you describe. For example, my next Jool transfer window opens in +222 days, and lasts something like 8 days, so I've got my first alarm set on +222d, and all the subsequent craft alarms on +226d, so that I get a single popup when the window opens, and have all the other craft in list-form in KAC.

[Geschosskopf]

A couple of notes on Kerbal Alarm Clock.....

Yup. You can do all sorts of things with KAC. I just find it easier to make a maneuver node and create a maneuver alarm in KAC for it because I like the KAC list to use all its different symbols to remind me of what I was supposed to be doing then. I typically have a lot of stuff going on, like several flotillas en route simultaneously to different places plus stuff already in place. As a result, it might be days or weeks of real time between times I'll be messing with any individual ship or flotilla, in which time I'll have totally forgotten what it was up to .

[Amaroq]

Fair enough!

All I meant was, your hypothetical reader may not need a popup every 15 minutes, there are less-visual-clutter approaches to the same problem.

I've just gone down a path more along the lines of "writing good notes to myself in the KAC 'notes' field for an alarm". I've even started using that just for notes about things, with no ship really required (though of course, hooked to one via KAC), such as "Jool Transfer Window in 7 days" -- "Verify that you've got everything in place and launch any manned craft you intended to send.."

[rottielover]

Extremely well written. Thank you good sir for taking the time to post this.

One thing of note, is the wonderful discussion points regarding Kethane in the prior responses, IC could be worth noting in the original document. I would however caution the reader that kethane's config could change at some point in the future or the reader can modify the weight of the resource as they see fit. So the hauling refining could go either way. As it stands today, it's "more worth it" to haul the Kethane to orbit and refine it there.

Now another thing I thought of is that the updated KAS mod with its less explodie fix works some wonders for these flotillas. Think "underway replenishment" using (lighter) KAS pip connectors rather than docking ports. Save weight = save fuel. But it's not for everyone.

Anyway wonderful guide good work.