Crater

I don't see how mining Kethane and 3D-printing it is any easier, inherently, than using EL, mining ore, smelting it and making your parts that way. The simplest method will always be just sending up parts from KSP, since the RocketParts are freely available, there.

Personally, my first (few) attempts at this failed because I was trying to launch unmanned probes to be the sats, and they all went out of comms range before I could stabilize the orbit. There are a choice of options for fixing this. You can either use a manned vehicle to take up and deploy the sats - stick it in an eliptical orbit, drop one at each AP and circularize it. Next time you hit AP, you'll be well around the orbit compared to the previous one. Or you can ignore the gravity turn - shoot straight up, aim for keostationary orbit, and circularize there. I'll mean that you have much greater downrange coverage for your second (and further) sat(s). As Kimberly said, 3 or 4 fairly evenly spaced in a high orbit will cover everything but the poles. Even then, the poles are only missed at ground level or low altitude, so you should be okay. Make sure you put enough dishes on your sats to target all the missions (or planets) that you're interested in, and remember that all the sats in your initial Kerbal constellation need to have the same set of targetting for their dishes (e.g. dish 1 points at Duna on all of them), since any one of them may be the one that is on the correct side of the planet at any given time.

While I was looking at whether it was more efficient to lift Kethane to orbit, or to convert it on the ground, I was doing some maths with the converter stats, and I've found what appear to be some discrepancies with the small vs large converters. First of all, using the large converter to generate at 45/55 mix of liquid fuel and oxidizer actually gains mass, the weighted average of the efficiencies is 1.008, compared to the small converter at 0.992. The large converter runs at about three times the speed, and uses about 65% of the power per unit produced. That's all good apart from the mass-efficiencies looking a little high. For monopropellant the mass-efficiency leaps from 0.3 to 0.85, a huge boost for the large converter, with the large generating at 5.7 times the rate, while only using 22% of the power per unit produced. This is a much better case than LF/OX. For Xenon, things get a little squirrelly. The conversion efficiency actually drops from 0.4 to 0.25, which means that the large converter takes 60% more Kethane than the small, to produce each unit of xenon. This also means that the large converter only produces xenon at 83% of the speed of the small converter, and that it uses over 300% of the energy to do so. No wonder it runs hot Is there a rationale behind these numbers, or is it just a case of them not (yet) having been balanced properly?

Lower density doesn't actually help. When it comes to lifting, it is mass that matters, not volume, so shipping Kethane instead of fuel just means that you have to have more tanks to get the same total amount of final resource to orbit, which makes the vessel bigger, and usually less maneuverable for docking. There is also conversion efficiency to consider. For example, using a small converter, the efficiency for monopropellant is 0.3 - that would mean that for every ton of monopropellant that you create in orbit, you would have had to lift 3.3 tons of Kethane up to orbit. Even with the large converter, it only runs at 0.85 efficiency for monopropellant, so you're wasting 15% of your lifted mass compared to converting on the surface. That said, it is always a lot more flexible to keep Kethane on hand in orbit, so that you can, e.g. refuel xenon into an ion probe if you need to, without having to keep xenon stocks on hand at all times.

Well, drills, converters, and the power supplies for them are heavy, so if you want efficiency, I would suggest that you have a semi-permanent installation that you can land on a deposit which has the drilling and converting hardware onboard, enough fuel tankage (&RCS) only for its own needs, and a small amount of kethane storage space, mostly as a buffer for the converter. If you equip that vessel with KAS, you can then very easily land tankers, that have nothing but lots of storage space for the material you are interested it (a fuel tanker, an RCS tanker, a Kethane tanker, etc.) close to the drilling rig, which can connect up a hose, suck the green goop out of the ground, convert it to whatever you are after, and pump it straight into the waiting tanker, it doesn't need much storage on the drilling vessel. This means that your tankers will only be lifting to orbit the essentials - their own fuel, engines, etc. plus their cargo. Other people swear by the all-in-one design, where the tanks are on the driller/converter rig, which simplifies the process, but does use more fuel as you are lifting more weigh more often.

Status: locked means that the animation on the part is not running. Is there any chance that some protruding parts of the two vessels are touching, and preventing the docking from being completed? When they touch does the camera jump to the new center of the combined vessel? Could you try a fuel transfer between tanks on the two separate vessels to see if the game believes they are linked?

Correct. Jr ports can only dock with Jr ports. Sr with Sr. Standard can be used interchangably with the inline and capped versions, though

That is actually a typo in the FusTek parts - I believe that it should read breakingTorque in every case, with a 'g' instead of a 't'. You could try editing the .cfg files and correcting this, to see if it resolves the problem?

No need. The flow-type for kethane is all-vessel, which means in simple terms that kethane can freely pass from any part to to any other on your ship. It is only Liquidfuel and Oxidizer that have the complicated flowtypes that need hoses and such. So for a converter, you are best off stacking it with a fuel tank (otherwise you need a fuel line from a tank to the converter which is what throws people, it sounds like the wrong direction), but for a drill, you just need it to be on the same vessel as a kethane tank, or docked to one, or KAS-docked to one.

I can almost hear Jeb squealing with joy from here! Until he realises that you are trying to stop them!

Sadly, don't hold your breath. The reason that it is done the way it is, is that the physics engine already struggles somewhat to cope with the ships we users throw at it. You'll already see a drop in framerate and responsiveness when you approach another ship to dock and it unpacks it and starts to simulate that one as well as your focused one. Imagine if it unpacked and activated every single ship you have in filght. How slow would that be? It might be possible to have a system where strictly passive information-gathering sensors could be active even on a ship on rails, but, honestly, it would be a real can of worms. e.g. Oh, I just want to run a kethane scanner but that uses energy and now the batteries are out but that's okay, there is a generator on board but that's burning fuel but that is changing the center of mass... of a rotating body that was -almost- skimming the atmosphere and so much for the part being passive. There would be absolutely loads that you could do if they could continue to simulate other ships. Imagine active station-keeping on keostationary sats, or MechJeb processing maneuver nodes for non-focussed ships. But until Unity is multi-threaded and 64bit, and you have 32GB of RAM and loads of CPU to throw at it, there's a reason why distant objects (2.5km+) are on rails.

Actually, it IS the fact that you're using the Hooligan Labs launchpad - it has debug mode switched on. You need to edit the .cfg file for the launchpad, go down to the EL module, and remove the debug line from it. If it is on, you get full fuel, and can always build regardless of parts-availability.

Current behaviour is that the part loader recursed through GameData (and the legacy folders), loading all DLLs, Sounds, Textures, Models, Config files. All in that order. It then compiles the part-configs and builds the catalog in memory. This is in accordance with how Mu described it, and can also be plainly seen if you take a look at KSP_Win\KSP.log after loading the game up. Basically, it will suck in anything and everything in those folders that has a file extension that it recognises, whether it is going to be needed or not. So the only way to reduce memory footprint (at the moment) would be to delete the files from disk so they never load. Pity, coz it would be awesome to be able to do it with MM.

There is a fixed version you need to download from post comment #711 a few pages back in this thread.

(Spot on, and very nicely explained) The "deal" is that the generic instructions on the SpacePort are for KSP verisons up to 0.19. From v0.20 onwards the places to put files have changed to the format you described, but, as of now, the SpacePort hasn't updated it's instructions.

They will in atmosphere. Anything that moves out of the 2.5km sphere from your controlled craft while inside atmosphere gets deleted - even if it has Kerbals onboard.

Oh, if that's sufficient to classify it as debris, then that's fantastic! And I completely understand that you don't want to have to create some complex UI to allow for vessel selection, and I can already imagine the people sadly explaining how their recycling tug had just annihilated their 30-launch space station, and then exploded because it had so many rocket parts onboard So yeah, keeping it as debris only is great

First of all - thanks for your awesome work on this mod. Do you have any plans to allow for recycling of other things than debris? I usually stick probe cores on my upper stages, so I can deorbit them tidily, but occasionally I miscalculate the fuel load, and end up with an empty stage in a stable orbit that has a probe core attached. I'd love to be able to sweep them up and make use of them... I was thinking about a tug with KAS to drop their PE into the atmosphere, then return to orbit itself, but recycling would be way cooler!

You'd be surprised just how creative some people are when it comes to screwing up simple things. You are spot on on that being the correct method, but in the case of ModuleManager.dll, some people do the (apparently) sensible thing of putting the ModuleManager.dll that comes with FAR in the FAR folder, and the ModuleManager.dll that comes with Kethane in the Kethane folder, and the ModuleManager.dll that comes with B9 in the B9 folder, and the ModuleManager.dll that comes with ModularFuels in the ModularFuels folder..... which can seem perfectly reasonable, and can cause some wonderful collisions in the code. Edit : I'm not totally sure on every single one of the addons I name using ModuleManager, but you get the idea. It is also in the new RemoteTech, some of the life support mods, etc. but please don't take any of these as gospel or avoid mods because I said they used it, or yell at me on here to correct me (pretty please )

As far as I can tell, all the current parts are there. Many of the old ones have been renamed, or reworked. Nothing has been "missed". This is why Majir warned everyone it was a ship-breaking release.

Both have already released official 0.21 updates, I believe.

He means a major update to RemoteTech, which Cilph said was likely to come about a week after 0.21 dropped ( http://forum.kerbalspaceprogram.com/showthread.php/16347-0-20-RemoteTech-Relay-Network-%E2%80%93-V-0-5-0-1?p=539353&viewfull=1#post539353 )

Glad it helped. Bear in mind that since the EL addon uses the KethaneConverter module, which is mass-efficiency based rather than unit-count based, that edit will also mean that you get a lot more RocketParts from your metal.

Benie, it sounds like all you want is for the weight of your rocket part storage to not sink a floating base. In that case, the most direct fix would be for you to edit the file at GameData\Extraplanetary Launchpads\Resources\ExtraSpaceCenters.cfg and look for the RocketParts definition - it should be RESOURCE_DEFINITION { name = RocketParts density = 1 flowMode = ALL_VESSEL transfer = PUMP } Edit the density line to read density = 0.0001 and suddenly your parts will have miniscule mass, so their weight shouldn't sink your base any more.

As I understand it, the range between two antennae is the LOWER of the two, not the sum of the two ranges. So if you point a 5Mm omni at a 5Mm omni, you get 5Mm range So if you point a 50Mm dish at a 50Mm dish, you get 50Mm range If you point a 5Mm dish at a 5Mm omni, you get 5Mm doubled as the other end is a dish to 10Mm range Basically, you need bidirectional comms. Think of the range as their transmitter ranges, not reception ranges. Since a dish is more efficient at receiving, it can pick up signals from an omnidirectional antenna that are fainter, hence effectively doubling their transmission range.