Majiir

The stats will be fairly boring at first. A revision patch will probably add some more interesting balance behavior. Spaceport has an excessively restrictive legal agreement for uploaded projects which grants them exclusive distribution rights, among other things. Considering how flaky the Spaceport web service is, I prefer to self-host. Why is this not expected? In order for refining three fuels individually (at full speed each) to be faster than all at once, the reduction would have to go down below one-third. At 40-something percent, you'll still come out ahead. The goal for the heavy converter was to restrict its total conversion rate mid-flight (and to give that awesome heat sink something to do). It could probably use some rebalancing, probably with a very large penalty to MonoPropellant heat production, and possibly some kind atmospheric efficiency bonus. On the development end, I've been experimenting with particle effects. It'll get better, I promise! This is my first time playing with them. I think it'll look a lot nicer than applying the RCS thrust effect to the drill head.

This made me chuckle. I like that Kethane uses a lot more electrical power than you'd normally equip on a design. Your analysis is interesting, and it makes me think I need to take a look at the heat sink math and do some tweaking. This next teaser isn't much to look at, but I think it's a significant addition. This update is shaping up! COMING SOON:

COMING SOON:

Are you targeting your build at .NET framework 3.5?

COMING SOON:

To clarify: The dry mass of tanks did not change in 0.4.4. The dry mass of the largest tank has always been 3.25 tons. The Kethane tanks are balanced a little differently than stock tanks in that their dry mass is not proportional to their capacity. Instead, larger tanks have a slightly better wet/dry ratio. The increased density does not nerf the resource. It makes it strictly more powerful. You may need to redesign some crafts in order to handle a full load of Kethane, but if you want to use old crafts, you could always just fill your tanks half way and get the same results. Originally, Kethane was 200% efficient, so one ton of Kethane would yield two tons of fuel. This was absurdly powerful, and it meant you could nearly double the overall specific impulse of any rocket by converting Kethane to fuel on-the-fly. The converter was slow, so you couldn't do this with large rockets, but it made small interplanetary miners way too easy to build. When the conversion rates were reduced below 100%, it became more efficient to convert Kethane to fuel on the ground. Unless you knew you were going to need the versatility of Kethane, there was no reason to haul it into orbit or even store it in tanks. The dominant strategy simply changed. My goal with this update was to eliminate either option as a dominant strategy and give players more interesting choices. With the better-than-perfect conversion, it may be economical to haul Kethane and convert it closer to where it's burned, but since the gain is fairly small, the mass of the converters and electrical hardware may end up overwhelming the benefit. It might be most economical to have Kethane converters stationed at a fuel depot, or as part of a service module, or on a transport, or... you get the idea. There's no longer one obvious "best" way to use Kethane. If you need a way to rationalize the >100% efficiency, it's been suggested that the excess could be coming from Kerbal flatulence.

You can use the Debugger part to generate deposits underneath you.

Kethane can be transferred without fuel lines, much like MonoPropellant. (They use the same flow mode internally.) LiquidFuel and Oxidizer must be connected somehow, either directly or by fuel line (from converter to tank).

Yes. The converter efficiency works by mass. Since a unit of Kethane now has twice as much mass, it will also yield twice as much fuel. This update does quite the opposite for a couple reasons: Increasing density makes transportation of Kethane more viable because a higher portion of a fuel tank's total mass will be fuel (rather than dry tank mass). Conversion efficiency has been increased such that it's more efficient to convert Kethane to fuel just before burning itâ€â€however, since the converter and electrical hardware have mass, there's a balance to be struck. It might be efficient to have an orbital conversion depot, but not to carry converters on interplanetary craft. Those decisions are left up to the designer and there are tradeoffs all around. Prior to this update, it was strictly better to mine and convert on the ground because the Kethane conversion process was wasteful and the tanks had a higher dry mass portion. Both of these issues have been changed in this update, but the margins in favor of Kethane are fairly small, so I think there are much more interesting choices available for craft designs now.

It is hardcoded to a range between 10K and 500K. The distribution on that range is uniform. That 768K figure is suspicious... The next major project for Kethane is support for multiple resource types. I have no plans to directly integrate with other mods, but Kethane will support multiple resources through the stock game resources system.

P.S. Many thanks to those who released patched versions while I was MIA! You may consider the license to be in effect once more, but I stress that in most cases I grant exceptions to the license, so just shoot me a PM, and if I don't get back swiftly, shoot another.

Kethane 0.4.4 has been released. The download link on the first post has been updated. This update is a compatibility fix for KSP 0.20.2. It also has some balancing changes that should make Kethane more interesting to use. Warning: This will erase your existing deposits. Existing craft files should work fine. Changes in this version: Adopted the new plugin folder structure. Increased Kethane density from 1 to 2 kg/L to make it competitive with other fuel types for storage. Rebalanced detector range and scanning period to make the KE–S110 Medium Survey Unit more attractive. The KE–S210 range has been reduced to 250 km and its detecting period increased to 1.5 seconds. The KE–S110 range has been increased to 1,200 km and its detecting period reduced to 0.9 seconds. [*]Rebalanced converter efficiency to make Kethane economical to store and transport. KE–C090 Medium Converter Unit LiquidFuel efficiency increased to 97% Oxidizer efficiency increased to 101% MonoPropellant efficiency reduced to 30% XenonGas efficiency increased to 40% [*]KE–C190 Heavy Converter Unit LiquidFuel efficiency increased to 103% MonoPropellant efficiency increased to 85% XenonGas efficiency reduced to 25% [*]Fixed an issue with the extractor part name. [*]Removed an unused bitmap.

Will get back to you Soonâ„¢. Working on things right now.

Update on Kethane development: I've been preoccupied during this update cycle and haven't prepared an update for Kethane. I plan to find time this weekend to push out an update. In the meantime, for the purpose of providing 0.20 compatibility, I encourage people to post solutions and/or distribute modified packages. You may consider the license restrictions to be void until I next release an update. Please be careful when using a third-party distribution; most of the Kerbal community have good intentions, but there might always be bad apples. If there are specific issues I can help with, please use the Github issue tracker to communicate about them.

I haven't given it a hard look, but it sounds fairly straightforward. Kethane doesn't do anything crazy with part definitions.

In two hours (8PM BST / 9PM CEST / 3PM EDT / 12PM PDT) I'll be on Kerbal Space Pod to discuss the future of Kethane. And possibly other ramblings.

The efficiency indicator on the large Kethane converter is cooling efficiency, which impacts the speed of conversion but not the waste portion, which is a fixed property for each converter type. If the converter actually produces more waste while overheating, that'd be a bug. (...or a feature that I forgot I put in...?)

This is the official link I distribute Kethane from. Thanks!

That is, in fact, the official URL I distribute Kethane from. No need to obfuscate the link: http://nabaal.net/files/kethane/Kethane-0.4.3.zip Feel free to distribute that link far and wide. Cheers, Majiir

They might be able to.

I don't maintain those parts. This thread is only for the Kethane Pack. Your deposits were regenerated. Until I implement a different method for saving deposits, this will happen on some releases. It's a design decision from the original Kethane developer. I'll be removing the controller part altogether in a future release.

Yes, but how many of those atoms are methane?

Regarding scoops on different planets: each planet will have an associated partial pressure of Kethane, and this partial pressure might vary by altitude. So, Jool will have a high partial pressure of Kethane (it's green, after all) that's mostly uniform throughout. Kerbin won't have any Kethane at low altitudes, but at the very outer parts of its atmosphere, it might have a little. Interplanetary space won't have Kethane. There's no drag in interplanetary space, so it doesn't many any sense that you'd somehow be able to collect gas. If we ever get to the point where we're modeling solar wind and whatnot... then I'll think about it. In the long run, the plan is to make scanning more fun and Kethane more scarce so that you can't fuel your entire space armada from one deposit on Minmus, and so that different extraction options exist with real tradeoffs.

Version 0.2 has been released. The download link on the first post has been updated. Changes in this version: Flipped the scan map so north is now at the top Fixed an issue where processes would happen at different rates under physical time warp Fixed an issue where scan maps would fail to load Fixed an issue where deposit quantities would reset when exiting time warp Fixed an issue where extraction could occur at time warp even if the drill did not reach ground

You canâ€â€in fact, you scan scan at any speed, although I don't recommend higher than 100x if you want good-looking results. The bad part is that you can only scan one pixel at a time, straight down, and the scanner doesn't even require a line of sight to the planet. I'd like to change all of this at some time, but it's going to take an entire release cycle to overhaul the scanning system. The current cycle is focused on bug fixes, and the next probably won't get to this. Maybe expect a scanning overhaul in 0.4 or 0.5.