Trogdor!

To add to this, I've managed to transfer fuel to a ship, undock them, and then have the fuel magically transport between the undocked ships when trying to move fuel again.

Thanks to this guide I did my first ever landing on the VAB helipad! In that vein I drag optimized the Karmilla, and added science parts. The downside is that it isn't as pretty, but it *does* top out at mach 1.8 with a humble wheesly. After the drag was sorted out, it wasn't very hard to create a dockable SSTO version.

Update: So after extensive testing, I think I've found a pretty decent part order for the least amount of drag on mk1 parts. I uploaded the original test drone to kerbalx here, and have a new craft with much reduced mk1 part drag here. I've found that you should build up to the largest, leading with the parts that create the least amount of drag, then tapering down. Because the engine nacelle is larger than both the probe core and the cargo bay, it shields both of them really well, but you have to build up to the probe core with a faringless heat shield mounted in front of an empty cargo fairing. Incidentally, the SAS module has less rear facing drag than the cargo bay, so it acts as a step down. I'm not sure if this is the most optimal order for mk1 parts, but it's fairly optimized. I also could have inserted an inline cockpit between the probe core and the nacelle for even less rear facing drag, but this craft maxes out at 1,751m/s already. You could try the 'mount an intake behind the engine trick' for even less drag, but you won't actually go any faster thanks to the engine flaming out. It's not the probe core or the reaction wheel, it's apparently how mk1 parts are calculated. Some mk1 parts are larger than others, and apparently order is very important. You can take away the probe and the SAS wheel and the cargo bay will still generate significant drag at high speed, because of a tiny 0.078 m2 forward facing lip that has a Cd,0 of 0.91. I've found that if you shield it with something larger, like an inline cockpit or an empty faring, you will eliminate all of it.

While I appreciate the information, it doesn't only happen on the cargo bay. I rebuilt another from scratch without ever adding a cargo bay or heat shield and ran it again. As you can see, this time the RGU is behind the NCS, and it's drag value is 2.24kN, while the NCS is 0.31kN, the wings are 0.74kN and the stabilizer seems to be in the RGU's shadow with 0.13kN. The RGU is also a toasty 1927K. I'm set up to launch vertically, so the reaction wheel is a leftover from Wheesley testing. Kind of hard to stay balanced on the tip of it for long enough to get going without it. I guess I'll have to track down all the 'mk1.01' parts and test which order to put them all in. Perhaps it's possible to start with a cargo bay packing nosecones and taper down from there? Thanks to Ohara's most excellent notes on drag, I've compiled a spreadsheet on all the mk1 parts. It seems size is the determining factor. Apparently there is no sort of automatic 'taper' when two parts are mated. If anything is left over, the remainder is counted as a completely flat surface. I suppose this is just a leftover from way back when the mk1 parts were created where the size wasn't actually that critical to the design of the model. Also, just looking at the numbers, the heat shield with a faring is 1.44m2 and without it is 1.27m2 . Which leads to the awkward realization that the *shielded* heat shield is therefore more exposed to the atmosphere and subject to ablation due to friction on the fairing. Kinda counterintuitive. I suppose these quirks aren't really that important in a game about space, but I started down this rabbit hole because I wanted to find the smallest atmospheric probes that I could use on Laythe. As an aside, it's totally possible to go supersonic with a tiny juno drone who's only control surfaces are reaction wheels. Too bad you can't tuck any science instruments on it because they all count as exposed, no matter where you put them.

I wasn't really sure how to attach the craft to the post, so I just used steam. It's a pretty simple ship and can be recreated completely with 14 or so parts. The wings are structural wing type Ds tilted at 5° and the horizontal and vertical stabilizers are elevon 4s, with COL balanced slightly below and behind the COM. I checked numerous times on the cargo bay attachment and am pretty sure that's not the case, but regardless, the effect still happens without any cargo bay at all. Most notably the 'shrouded' heat shield acting as if it were exposed to atmosphere and the reaction wheels overheating and eventually exploding if attached directly behind the NCS. Is there any sort of guide for the correct order for these 'mk1.01' parts? I had some success rearranging things by putting the engine nacelle in front of the cargo bay, but it also gets really hot. That tiny lip is presumably responsible for twice as much drag as the wings, which seems... odd. Perhaps we need to send Bill out there to perform some rocket surgery with an angle grinder or a very large lathe.

Zero mods KSP 1.7 on win 8.1. While trying to make the most streamlined flyers possible, I've found that certain mk1 parts seem to generate excessive drag. This Picture shows what I'm talking about. the 1.25m cargo bay is responsible for almost *half* the drag of the entire vessel, even though it's attached in line to the rest of the ship. As near as I can tell, this is because of the tiny lip shown here highlighted in purple. The NCS adapter is showing 0.34Kn of drag and the cargo bay directly attached behind it is showing 4.79Kn This effect is also noticeable when other parts are swapped into the same spot such as the advanced inline stabilizer, RC 001S Remote guidance unit, and 1.25m heat shield. Are these slightly larger than MK1 parts supposed to be generating this much drag and therefore heat? Or are they supposed to be streamlined? If a heat shield is placed before the cargo bay, stabililzer and probe core, those parts generate much less drag, but the heat shield actually wears away even while shrouded due to drag and heat being generated.. While the pictures show effect happening at ~21Km and 1700m/s, it can also be generated at 100m and 700m/s with a wheesley turbofan. Craft file is here

Alas, if my google fu had been better, I could have found those already reported bugs. They look very much like those that have already been reported. I will try to mess around with the second one a little more, because mine was a bit different in that I did have a claw and I did use RCS, but the vessel that spontaneously deconstructed was the root part of the one that I undocked with, was under no more acceleration than that of the decoupling force, and the the non-physics 5x warp is what caused it to rip apart. The ship that I undocked was left intact, and it didn't matter which vessel I was flying, only the former ripped apart. A restart did fix the issue. In hindsight however, I do believe I used a 4x physics warp with a reusable lower stage during the same play session. That vessel did not have rcs capability or a claw. I will see if I can find a reliable way to trigger it.

So in my travels I have encountered 2 different bugs. The first one occurs when you launch a ship with a launch stability enhancer that is placed in such a way as to be off the launch pad at launch. When you do this, every x number of seconds, the LSE will spawn beside your ship and you will fly away from it very fast. However, if manage to keep your ship arrow straight, you will make it to orbit safely (the LSE likes to crash into your ship when it spawns, which makes the parts that contact it explode). After that, the interesting stuff starts to happen. If you switch to the LSE 'debris' that spawns, you will notice that it's orbital speed does not change, but it will be under constant .5g acceleration! Kerbin will slowly recede from you and you will eventually leave kerbins SOI. (good luck trying to timewarp, change vessels, or return to the space center. You can't! "you are under acceleration") Today, I was hit by this (http://forum.kerbalspaceprogram.com/threads/103282-Exploding-and-bending-ships-while-time-warping) bug, and wouldn't you know it, my RC-L01 Remote Guidance Unit ripped itself out of my space station, and it's orbital speed stayed the same, while it was under constant .5g acceleration! My theory is that somehow these parts are becoming detached from the physics of the game and remain stationary while kerbin moves away from them. Thoughts?

So your point is, what? Never make suggestions? Never file bug reports? I'm not saying it sucks, I'm saying it could be improved upon from a gameplay perspective, and make a better and more rewarding game. That's why I responded in a thread titled 'impressions'. Frankly I'm much happier seeing them direct most of the current work to unity migration than anything else, but I thought I'd give my thoughts on a newly introduced game mechanic and it's relation to good game design, because that might be something that a game developer is interested in.

I am very late to this party, but as a person who's both dumped 600 hours into this game and has yet to install a single mod (I like to play the game the devs intended), I did have some confusion on how mining, scanning, and resources worked. I understand roverdude's reasoning and explanation, and they make a certain amount of sense. Usually in this game I try and experiment with things as intuitively as possible, and the whole scanning process is a bit less intuitive than I'd have liked. I had assumed, starting out, that I'd have to figure out some kind of scanning orbit, and eventually I'd get a whole map of the planet. Once I realized polar scanning was instant I was a bit disappointed because there was less reward for the effort expended than I expected, but it made a certain kind of sense, because really, all you're doing is finding out what the general concentration is in a biome. What you are not doing with the high level orbital scanner is getting any sort of spatially accurate information. The overlay you get from this is essentially a starter kit at this point. If I'd had my druthers, I'd wish the requirement would be for the probe to complete one polar orbit, or at least an animation, but whatevs. Not a terribly big deal. After I figured all that out, my next intuitive assumption was that since there was no sort of accurate map with the orbital scanner, that job would then fall to the narrow band scanner. Now that you got some extremely generalized information, you'd narrow things down a bit, and your orbital overlay would turn more into a map, which would require you to get into a proper scanning orbit and do some very simplistic, but at least some sort of analogue to reality legwork. Here is where my biggest confusion and immersion break came from. Why is there no usable, discoverable, viewable detailed map? Without it, finding the perfect mining spot is very frustrating. After some searching at this point, I found out that in order to get some detail to the little gui window, you had to land and take samples. This makes proper intuitive sense once you realize what the surface scanner's job is. Getting more and more accurate information should take more and more work. What still bugs the crap out of me though, is after you do all this work to drill down to the most accurate information you can get, you have no way to save your work. Which rewards all your effort with a slap in the face. This is worse than nothing. Your effort/reward ratio at this point is negative. Your GUI window is all you really have, and you just constantly throw that data away. No space program worth their salt would ever just trash useful data. It's not like storing data is hard. Just ask nasa. The progression I would personally like to see with resource scanning goes something like this Step 1. Get into a polar orbit, run the scanner for exactly 1 orbit. (this gives you an extremely basic idea of what's out there because you're zoomed all the way out) (small reward for decent effort, but that's fine because it's the first step on the journey.) Step 2. Get a surface scanner on the ground to get biome information (this gives you a much better idea of where stuff is, but you still got work to do, because your zoom level is way too close,) Step 3. Get a narrow band scanner in a close realistic scanning orbit, and get a slowly revealing map. (Once you have the general and the specific, then you have the happy medium complete picture. This also gives you the bonus of your polar satellite not being a single use craft with very small reward for all the effort it takes to get it there, and it teaches us plebs about actual satellite scanning mechanics in the real world. Most effort/Highest reward) I realize roverdude wrote his own resource mod and wants people to use it, and as much poorly articulated crap as he's received in this thread he may have already made up his mind and dug his heels in on this, but this is a non-modder's take on stock game gameplay. I don't have all the preconceived notions of how a certain thing should be because it was like x in y mod. My preconceived notions are all based on what happens in real science, and I think my proposed progression would both make more intuitive sense, and be more rewarding gameplay wise. Half the fun of KSP is learning all the things you didn't know about rocket science. Yes, I realize this game oversimplifies everything about space exploration, but it should at least not be the opposite of reality. My take on the scanning system is that it's a great start, but it needs some tweaking to make it more fun/rewarding.