Vector

Been done before, got 434 m/s, others got much faster using separatrons: http://forum.kerbalspaceprogram.com/threads/49863-Fastest-Unicycle-Hell-on-Wheel?p=652498&viewfull=1#post652498

100% agree and to me this is one of the weaknesses of the science system that I hope gets fixed in a future version. To address the OP question, you want a mission that is "efficient" ... in terms of what? Ship mass? Labor? Number of launches? A rover may be efficient in terms of number of vehicles, but it's going to take a hell of a long time to drive everywhere so it would be inefficient for your time spent. Launching a carrier that separates into a fleet of probes may be efficient in ship mass or number of launches, but not efficient in mouse clicks for all the transmitting...

I was wondering the same thing. Transmit speed doesn't matter when you can queue as many transmissions as necessary. There is always plenty of time to send. Pretty sure this will have to be re-balanced in the future. There is some wording regarding range, maybe this will play a factor later.

Seriously? The math for rails is not that hard or compute-intensive. (But then, neither is the math for SOI transitions...) Timewarp cannot be used in an n-body environment? Can never work on rails? You're just making stuff up. Whether it's a good idea in that it changes gameplay in a positive way, now that's a different question. I would say station keeping would be not at all fun.

One, this is not the N-body problem, because the planets and moons are not experiencing deflections from each other, and spaceships are not having gravitational attraction to each other. The interactions grow only linearly with the number of spacecraft, not quadratically as with the N-body problem, and even the full N-body problem is not difficult for small N. Two, the compute time for these calculations is not the reason they are excluded from the game, so "optimizing" them gets you nowhere. This has already been discussed in other threads. Here's one: http://forum.kerbalspaceprogram.com/threads/49121-On-Newtonian-trajectories-vs-patched-conics

In settings.cfg, change to CONIC_PATCH_DRAW_MODE = 0

Nicely done. I can see it definitely pays to have two command pods. I can also see now how much I missed out on crew reports. I had not managed my transmissions -- I just hit the transmit button and assumed they would go out eventually, which was both incorrect and also a bad strategy because I had to suffer with minimal power the whole time, which is especially a problem when trying to land. Your approach worked much better.

+1 for this suggestion. As a workaround, I sometimes use the 'rename' feature to declare my current ship to be a space station. I like the idea of additional tabs in the filter panel because I can see circumstances where you may want a 'clean' view that shows no ships at all.

I agree this should be built into the game. I've had problems with Krakens and glitches killing hours and hours of work. Definitely NOT FUN. (And fun is the reason we're here, right?) I wrote this script which takes the manual labor out of backing up the save files, and it's an external program, not a mod, so it won't affect the game's stability (or lack thereof). http://forum.kerbalspaceprogram.com/threads/56437-Unlimited-quicksaves-with-screenshots-using-AHK

I agree that the transition period creates real problems and should be configurable. Nowadays I always do "<<>" (left, left, right) in quick succession to skip the transition. It is a decent workaround, but it is frustrating for new players. When I first started playing KSP it was extremely irritating to try to walk the line between overshooting and slowing down too early and having to wait for a while. Like doing a suicide burn on every time warp. And for no reason other than a bad user interface.

This is along the same lines as Multiple Sequential Savegames for KSP using AutoHotKey (AHK), but with a couple differences: One, it is not limited in the number of saves. Each save goes to a new folder that is named after the date/time. Two, it also saves the most recent screen shot to the same folder. If you take screen shots just prior to saving, this makes it much easier to see what is going on at the intermediate saves. Without this sort of functionality I was always reluctant to use the quicksave feature because I never knew if I might want to return to the previous quicksave. Now, with no limitation, I can save before or after any major or minor event. As often as I want, I can screenshot (F1), quicksave (F5), and then run this script (currently bound to Ctrl-F5). This script requires AutoHotKey (www.autohotkey.com) to run, which limits it to Windows. Without further ado: ^F5:: ; modify these to your particular install and savegame outfolder := "C:\Users\Vector\Desktop\KSP\snapshots\" screenshots := "C:\Users\Vector\Desktop\KSP\KSP_0.22\Screenshots\*.png" gamefolder := "C:\Users\Vector\Desktop\KSP\KSP_0.22\saves\Tech0 Grand Tour\" ; Find most recent screenshot latest := 0 Loop %screenshots% { FileGetTime, filetime if (filetime > latest) { latest := filetime lastfullfile := A_LoopFileFullPath lastfile := A_LoopFileName } } ; Create output folder folder := outfolder . A_Now . "\" FileCreateDir, %folder% ; Save three files to out folder FileCopy, %lastfullfile%, %folder% FileCopy, %gamefolder%quicksave.sfs, %folder% FileCopy, %gamefolder%persistent.sfs, %folder% MsgBox, Saved

I have to agree with Smidge. I have seen this behavior too. This is a bug as far as I'm concerned. Justifying based on seeing what will happen one orbit later is nonsense because you can always place multiple maneuver nodes to see far in the future, even two or three or more orbits later. For rendezvous near planets or moons this bug mostly doesn't matter because you usually don't need late corrections, but in deep space it makes certain intercepts difficult because it might be impossible to make an adjustment of 0.01 m/s 100 days in advance. You need instead to make a change of say 5 m/s at 10 days in advance.

Two launch unlock complete! Initially I was just going to launch a carrier that separated into a whole bunch of probes that would send science back by radio. But I thought this would be rather anti-climactic since the science just shows up as science points without a detailed accounting. So I decided instead to try to physically return enough science to Kerbin to unlock the rest of the tech tree. This is a bigger challenge, and more interesting. First, as others had pointed out, I could get more science at the tail end of my first mission by aerobraking into a polar orbit and getting EVAs over all the Kerbin biomes. I went ahead and loaded an intermediate save and did this, which got me up to a total of 3698 points for mission 1. This turned out to be unnecessary but at the time I thought I would need every last bit. With this science, I unlocked all the techs shown here, with 50 science points left over: Then for the second mission, I made a small tug/ferry with a large fuel tank mother ship, and attached 12 science assemblies, each of which has one materials science bay, two goo, two gravioli (one for surface and one for near space), one seismic, and one thermometer. Then one by one, I docked with a science assembly, carried it down to the surface of the Mun, did the science, carried it back up to the mother ship, and then picked another one, carried it down to a different biome, and back up, untill all 12 were exposed to different biomes. Unfortunately Jeb is not very good at counting, and there are 15 biomes, not 12. But 12 turned out to be sufficient. In addition, I put a bunch of gravioli sensors on the mother ship, with the idea that I could get high altitude gravioli measurements on all the Mun biomes too. There are 24 gravioli sensors on the mother ship, with the intent of getting some of Kerbin's biomes too. Here's a close up showing science pods and the ferry: Then it's just a matter of dock, land, science, rendezvous, dock, undock times twelve! This is a laborious process but eventually I got it done, then went to higher Mun orbit (60+km) and got high altitude gravioli measurements. And on returning to Kerbin, I flew over enough biomes to use up the rest of the gravioli sensors. It would have been more graceful to splash down in water, but the crash landing didn't appear to have destroyed any science, so I didn't bother trying again for a better landing. Grand total for second mission: 7984 science! Plus the 50 I had left over from the first mission gave me a total of 8034 to spend on science. This was plenty to finish out the tech tree, with 944 points left over.

I believe from Bop to Tylo will cost roughly 260 m/s delta-V, and from Tylo intercept you can use gravity assist to correct inclination and go just about anywhere you want. I don't think there is anything to be gained by trying to gravity-assist off of Pol. You don't need to bother correcting inclination prior to the Tylo intercept, because you can intercept "above" or "below" Tylo and fix your inclination basically for free. Likewise from Pol to Bop is pretty much going to be just engine and not much else you can do in terms of gravity-assist to make the trip from Pol to Bop any cheaper. And unlike Tylo, you can't use gravity assist off Pol or Bop to fix inclination difference (theoretically you could, but it would take an insane number of repeated Bop encounters). If you only need a fly-by and don't care to stop at Bop (or Pol for that matter) then it's not hard to get a cheap intercept without insertion. But orbit or landing is indeed very costly. I included some additional screen shots from my visit below. I don't have delta-V measurements but I have fuel at each point. Before leaving Pol for Bop, I had 730 fuel. Getting an intercept at Bop, I had 691 remaining. After killing relative velocity in preparation for landing, I had 569. After landing, 499 After taking off and getting Tylo intercept, 395. Edit: on second thought, regarding Pol-to-Bop transfer, it would be theoretically possible to go Pol-Tylo-Bop and it's conceivable the savings in using Tylo for inclination change might more than offset the extra fuel to reach Tylo. I'm not sure how the numbers would work out -- it might still be impossible to do any better than direct burn from Pol to Bop.

I think EVA on Bop, even if difficult, would be better. Landing the whole craft took many attempts because there are very few flat spots, and even with a flat spot to land, the lack of reaction wheels makes it exceedingly hard to keep from tipping over. I redistributed almost all the fuel to the 'legs' and even then it was very tricky. I blew a lot of fuel hovering for the absolute most gentle landing possible, because anything over about 1 m/s leads to bouncing and tipping. I wouldn't expect a lot of gravity losses because you can get to orbital velocity quite fast, but you do have to include fuel for Rendezvous. With the ship in polar orbit like I had, I didn't think it was a good idea, b/c Bop would rotate under the orbit and lead to higher cost to rendezvous.

My own grand tour: 3629 from first Tech-level 0 flight. Took FOREVER, but I managed to get a high and low flyby of all bodies except Mun and Minmus. Also landed and got samples and surface EVA from Gilly, Pol, and Bop. The craft was not particularly spectacular, only 20 cans of fuel once in LKO. With this start, I think two launches is very feasible. The plan was to do Mun and Minmus last, but I barely had enough fuel to get back after all the other visits, so I went straight home. Here's the science summary: I took a ton of pics, here's a sampling of screen shots from the tour: Sometimes to take advantage of gravity assists, I made multiple visits rather than getting high and low and all moons on every visit. Eve was first but Gilly was last. Low Duna was on a separate pass from Ike and High Duna, etc. The sequence was: 1. Near Kerbin (Highlands) 2. High Kerbin 3. High Sun 4. High Eve 5. Near Eve 6. High Ike 7. Near Ike 8. High Duna (was hoping to thread the needle and get high and low Ike and Duna in one pass, but I messed up) 9. High Moho 10. Near Moho 11. Near Duna 12. High Jool 13. Near Jool (aerobrake seems not to allow air sample) 14. High Pol 15. Near Pol 16. Landed on Pol (extreme EVA) 17. High Bop 18. Near Bop 19. Landed entire craft on Bop -- I think this turned out to be a mistake and wasted a bunch of fuel in the process 20. High Tylo 21. High Vall 22. Near Vall 23. High Laythe 24. Near Laythe 25. Near Tylo 26. High Dres 27. Near Dres 28. High Eeloo 29. Near Eeloo (didn't take a ton of fuel but took a very long time to go to Eeloo) 30. High Gilly 31. Near Gilly 32. Surface Gilly (extreme EVA) I didn't get any coverage of Mun biomes or Kerbin biomes except for one. I would have liked to have gotten EVAs above all Kerbin and Mun biomes and also gotten High, Low, and samples from Minmus. I would have also liked to have gotten low sun if it were feasible, but I didn't see a good gravity-assist opportunity, and flying directly is very costly. I also believe the transmitter didn't get all the crew reports back home, because 1) I was constantly out of electricity, and 2) the transmitter seems to flake out when starved of electricity for a long time. Saving and reloading seems to help but I didn't reload any saves just to fix the transmitter.

"Near Eeloo" is below 60k

Also just found "near Vall" is about 90km (not 80), somewhere between 88 and 92. ...And Dres is 25km

137.3 is not low enough to sample the upper atmosphere of Jool. I don't know what the height is, but I could not sample the atmosphere during an aerobraking maneuver that was at approx 130km, it was telling me "near Jool" instead. Needs verification. Also, I confirmed Morden96's measurement, 25km is low enough to be near Bop.

The problem as I see it is that SRBs have a different drag coefficient. With a lot of SRBs at the back, drag tends to tip you in the direction of your velocity, like fletching on an arrow. This is only a problem if you have a long, low-TWR burn in the early phase of flight. In that case the tendency to tip in the direction of your velocity amplifies itself. If you have higher TWR in eary flight you won't have this problem. You may have to sacrifice some dV, but dV at low TWR is mostly wasted anyway.

Not really a serious entry, as for me it doesn't go with the spirit of the challenge, but here is a single craft that separates before leaving the pad... just to see if I could.

Just because your ships are hard to get into orbit doesn't mean they all are. This one looks very much like Ekku's but a bit bigger (shameless copy for my experimentation) and a non-expert pilot (me) can get it into orbit every time, except when I forget to explode the stages at the right time. I've found that when you stack engines radially, they are not always parallel even though it would seem they ought to be. If you mount radially only at "right angles" (i.e. 2x, or 4x symmetry or in the same direction) it seems to improve the chances that the radially mounted parts will be parallel. I would agree Ekku's claims are a bit light when it comes to proof, but gravity assists do not require luck, just patience. I enjoy low-dV gravity assist bouncing and on a dry run test I got high and low encounters at all Jool's moons except Bop and got an Eve intercept on the way back, all with a Tech-0 ship with only 9 cans of fuel, and I still had a bunch left over, so it's definitely doable, not even that hard once you get the hang of it. A few days ago I posted the save file for an unrelated reason here.

Incredible! It's an interesting technique, burning at using Jool apoapsis to get intercepts. I will have to try that.

I would agree you shouldn't be able to do science for "free", but I'm wondering, what exactly constitutes a launch? I myself am considering some creative potential missions and I think it would be helpful to clarify how launches are counted.

Insufficient yellow paint on the pipes.