Alshain

My biggest problem was getting it back. I had to send a tanker out to refuel it 3 times to get back the Kerbin station where I needed it. Mostly because I had trouble getting back into equatorial orbit on the return and those rapiers with that little fuel really don't do that job.

The main thing that helped me with rendezvous/docking was understanding the Navball. First, figure out that burning retrograde to the orbit is not the same as burning retrograde to the target (or even the surface). Second, slow relative speed by burning retrograde (yellow/green), move toward the target by using the target's location (pink/purple)... this was my biggest mistake. Never try to slow down with the pink retro-marker and never try to approach with the yellow pro marker. Getting those backwards will basically cause you to fly circles around the target. Eventually those targets should come close together or even on top of each other but may drift apart due to minute inaccuracies in your burns. But first and foremost make sure the gimble is in Target mode, not Orbit or Surface.

I landed an SSTO on Minmus the other day. I thought I needed the Flats to do it but ended up setting it down just like any lander with the only exception being I had to quickly bring the nose down to have the gear below me. I probably could have done it on the Mun. This is the plane I landed but I didn't upload the screenshots and I'm not at the computer at the moment. Maybe later today.

Yeah I saw after I posted. Thanks for all the help. I saw your fix and since I am a C# developer I think I can recompile it for my personal usage with your fixes. One other thing though. Back to my original screenshots, is it within the realm of your capabilities to edit the text on the targeting? So instead of 3 "Set Target" it would be "Set Target 02", "Set Target 03", 'Set Target 04" (based on the texture numbers)? I don't know if you can do that but it would be incredibly helpful if you can. EDIT: Another little nuance I discovered. If you retract the FLAT, your ships stay docked and kind of "float" there in space still linked. Can you force an undock of all ports when a retract is initiated? Or alternatively, possibly "safer" option would be to not allow it to retract when a docking port is in use.

Ok, I will go ahead and report it. I did notice that the Navball docking addon does work properly since I posted that. Thanks! EDIT: Oh! I see you already have. Well nevermind then, I will just watch it closely!

No need to be scared of them, just don't go overboard on them, especially the larger parts packs. If you have a low end computer and you install LLL, Novapunch, B9, KW Rocketry, and Kosmos all at the same time, yeah you might have issues. But if you just install one or two of those it's probably fine. FWIW, GUI based addons (like Docking Port Alignment Indicator) or GUI + part addons (Like Engineer) cause very little impact at all. It's the part packs to be conservative on.

No, it will not improve load times as that has more to do with your hard drive speed than the amount of RAM you have (SSD for the win!), the real problem here is that the mods and other files are not using very efficient file system. That's not the fault of the mods, it's more the fault of KSP (or possibly Unity). Text files are big and slow to parse compared to other more compressed/compiled methods, but text files is what we have. They do have the advantage of being user readable and editable. Textures are also very large and the game loads all of them "up front" rather than on demand. It doesn't use thumbnail pictures in the VAB or SPH, the parts UI is actual renderings so all the parts have to be loaded up front rather then when they actually get put on a craft. This of course makes the loading slow because of all the work that needs to be done. It would be nice to have a more "load active parts" functionality, maybe someday Squad will work on that. You don't want to load completely on demand because that would cause lots of apparent "lag" but you could load only the parts in active flights when the game is loaded and then load on demand when new parts are put on crafts in VAB and SPH. That would be the ideal method, but again parts would have to have thumbnails added to them for that. So back to the orignal question, no 64 bits will have nothing to do with the game load time.

Early landing attempts will take more fuel. Once you get skilled you will start to learn when to slow down, how to control your throttle, and how to better design your crafts and you will find yourself using less fuel. I've only been playing a few months and have mastered landing on the mun (and minmus is easier!), so it won't take long if you keep trying.

I think many people turn down the DRE settings when using FAR. Even Scott Manley thinks the two don't go together with defaults.

I think you have the wrong game.

FAR doesn't come with any parts. EDIT: Oh it's a ship. Nevermind. I never install the ships, I like to build my own.

Pretty much this. The only other option early game is to stack a probe (or a second command pod) onto a command pod and land near him, taking the science and leaving the old ship. You just have to make sure one pod is empty.

Kerbal Attachment System Give your Kerbals a reason to actually get out of the ship. In stock KSP, EVA has little purpose for existing. But hey, welcome to the community!

I hoping for a little sooner than that. The devs keep talking about a new UI for 0.4, but we don't know how involved that UI change will be. We know there is going to be enough for the economy obviously, but there may be a lot more included.

Most SSTOs will use both Jet engines and rocket engines. The idea is that Jet engines are significantly more fuel efficient so you need to carry less weight. You ascend to just a little shy of running out of intake air, level off to build speed, then when you finally switch from jets to rockets (use action groups or RAPIERS, don't let your engines flame out on their own) you will have so much speed that you can pitch up and get into suborbit using very little fuel.

Yes and no. No for the stock chutes, yes for RealChute. I do it all the time. RealChute even has a stack chute option that fits perfectly behind the 1.25m engines. http://forum.kerbalspaceprogram.com/threads/57988-0-23-x-RealChute-Parachute-Systems-Presets!-v1-1-0-1-27-04-14

Only Interstellar? I have Interstellar, KW Rocketry, NovaPunch, B9 (who's parts are all misplaced btw), Firespitter, Spaceplane Plus, and LLL. I reeeeeeallly want engines and fuel separated. It would also be nice to have major divisions for parts intended for rockets vs aircraft, still able to access them from both VAB and SPH, but divided tabs.

Yay! Thank you much!

Porkjet, I mentioned a problem on the Habitat pack thread with the docking ports. It seems to exist in this plugin too (though I haven't tried the new one yet). I just wanted to make sure you saw it. Great job, keep em coming!

Search bar would be nice. The Part Catalog addon has one, but it really should be standard.

There are a few. I can't name which ones off the top of my head but I know a few of them I have come bundled with it.

Well I didn't say it was a bad addon or anything, I use it for everything that supports it and actually try to limit myself to addons that do support it. But it's still a dependency and in fact serves no purpose itself without other mods, so logically it shouldn't count toward the cap. But that's just my opinion.

Lol, I'm going to say required dependencies don't count. If Toolbar has to be installed for it to function, it's not part of the total 3.

I'm hoping the new GUI in 0.4 brings us a new way to organize parts. The current method is fine for stock, but they know part mods are coming. There needs to be more divisions. Engines and Fuel need to be separated. Utility needs to be divided up between mechanical and electric. They keep talking about the new GUI and I'm hoping improvements to this will be included.

Connected Living Space support. Add it to a new text file and save it somewhere in your GameData folder with a *.cfg extension. Alternatively the MODULE tag can be added to the part's config file. It would be nice to see this included in the release. @PART[SW.StationHub.5]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[SW.StationHub.8]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } }