Majiir

Fractal_UK, could you expand on the distribution and versioning scheme? Is OpenResourceSystem.dll some sort of version picker? What kind of file structure do you recommend (i.e. should API users include DLLs in their own GameData folders)? Is there any shared functionality (like caching or a UI) that will be duplicated if mods distribute their own DLLs? In what way is this not reinventing the wheel, and what previous projects have been reinventing the wheel?

Check out this article and dev interview about Kethane on TheMittani.com! Kerbal Space Program: Kethane Mod Adds Resources Regarding retextures: some part assets are owned by Keptin and will require his permission for derivatives to be released. You can, of course, retexture parts for personal use.

IANAL and all that, but to expand on Greys' post: When you license a work, generally you (the creator) are not also bound by that license. You have full rights to your own work, so there's nothing prohibiting you from releasing your own work under whatever license you want, even if you have already licensed it in some way that's restrictive (e.g. GPL). However, if you make a derivative of a licensed work, you are still bound by the terms of that license. For example, if you derive an MIT-licensed program, you can license your derivative however you like, but you must still abide by the terms of the MIT license by including the original copyright notice. On your original question: You're bound by the license terms of anything from which you make a derivative work. ModuleManager patches are not generally derivative works, but they can be. If you find yourself copy-pasting something from another mod, chances are you're making a derivative work. If in doubt, you can always ask mod authors for explicit permission. We're often happy to grant permission for cases that are ambiguous.

The license terms of the mods in question will determine this. Even "free software" licenses like GPL have restrictions on linking/referencing.

If you're having issues with Kethane, post them on the Kethane issue tracker along with output logs so I can make a patch. I'm not aware of any compatibility issues as long as all mods installed have been updated for KSP 0.23.

I think you mean addons, which refers collectively to plugins, parts or any other kind of mod. Plugins do have the potential to use a lot of memory, but most of the memory used by mods is for part textures.

Kethane has a plugin system for resource generators. Plugins built for the wrong KSP version can crash the loader when it looks for resource generators. I've addressed the issue, and the fix will be in the next Kethane release.

5thHorseman's analysis is correct. The name is derived from methane, so adapt it from however you would pronounce that. I have never advocated the "keh-than-ay" aberration.

I'm afraid there's something missing from both! Those parts are the legacy versions which are no longer available in the VAB. They're still around for craft file compatibility. The textures are omitted because they use a lot of memory. Added to tracker.

I have added a mirror to the first post. (The main download link now points to the mirror, and the old link is in smaller text.) Please let me know if this solves your issue.

Bug reports belong on the issue tracker with the information listed in the bug reporting guidelines. Output logs are essential for debugging purposes. For example, I now know what's causing the disappearing overlay. The presence of plugins which are not updated for KSP 0.23 compatibility can cause Kethane to fail. This is a Kethane bug I will be fixing, but it's not a situation you should be in anyway.

There have been several discussions on this topic in #kspmodders, so I thought I'd bring this to the forum so we can better organize our thoughts. Several mods are limited by the current resource flow mechanics. There's been discussion about overriding the resource request routines to better facilitate the needs of mods. Some relevant mods: Kethane would like to be able to simulate resource flow on unloaded vessels. KSP Interstellar has an internal resource manager for handling vast quantities of electricity. TAC Life Support bypasses the stock resource draw mechanic and substitutes its own. There are implementation details which make it difficult for mods to individually implement desired features without conflicting with others. The goal of this post is to gather requirements for a resource flow API that mods can optionally use. A few items to get us started: Batch resource requests. Producing or consuming multiple resources in proportion is non-trivial, and the rest of the library may necessitate this feature. Storage-independent request resolution. In other words, how much (or little) resource storage a vessel has should not influence how resources flow in that vessel. This applies to high-timewarp situations but also comes up when a vessel has zero storage for some resource but produces and consumes it simultaneously. Offline resource flow. This might be implemented by allowing modules to declare a constant resource flow rate and resolving storage deltas when the vessel is loaded again. My intent is to foster discussion, so please, post suggestions and critiques.

I've tested Kethane with the SCANsat patch posted by rickyhewitt, and I'm unable to reproduce this. If you encounter the issue, please submit a bug report on the Kethane issue tracker so I can investigate.

As long as that older version is 0.4 or higher, you'll be fine. Versions before 0.4 are not compatible.

Please remember to post bug reports on the Kethane issue tracker and follow the bug reporting guidelines. It can be difficult to resolve an issue without all the listed information. Thanks! [EDIT] And thanks to you! I've pledged to myself that (and to you all, I suppose) that I shall post photos of anything purchased with donations so you can see how it's wasted utilized, so keep an eye here.

KAS 0.4.5 has been released. The download on Spaceport (link in the first post) has been updated. This is a compatibility update for KSP 0.23. There are also a few fixes and usability improvements. Changes in this version: Added parts to the stock tech tree. Updated module info strings in the editor part tooltips. Most of the strings have been simplified. EVA must be in range of both the source and destination in order to attach a part. The attach pointer will only turn yellow (indicating out-of-range) if the target surface is valid. "Drop" and "Grab" buttons will correctly change state in open context menus. Pipes and struts can no longer be linked while a Kerbal is carrying one end.

Kethane 0.8.2 has been released. The download link on the first post has been updated. This is a compatibility update for KSP 0.23. There are also a few fixes and balancing improvements. This update is only compatible with versions 0.6 through 0.8.1. Changes in this version: Added a deploy/retract right-click option for drills in the ship editor. Reduced the masses of the KE-C090 Medium Converter, KE-C191 Heavy Converter Unit and KE-G35 Kethoelectric Reactor Unit to bring them in line with similarly-sized parts. The generator in particular is much more mass-efficient for power generation. Modified the geodesic raycasting algorithm to use triangular cell frusta rather than hexagonal. This fixes the flickering on grid mouseover. Updated the module info string formatting for KethaneConverter. Fixed a rendering conflict with the Visual Enhancements: Clouds & City Lights mod. Fixed the scan overlay disappearing when the center moves out of the camera view. Fixed a number of cell caching issues which could, in rare cases, cause stack overflows and cache corruption. Fixed exception spam in the editor from the KE-J65 jet engine.

Thanks for the kind words! Resource concentration is what I had in mind, and the altitude data is just filler for now. I want to be able to support different modes of visualization to support different styles of resources. Your question speaks in broad terms, but I think I understand what you're getting at. I hadn't been thinking along those lines, but there's no reason other resources couldn't fit that model. For example, a Laythe base with sufficient equipment and power might constantly generate life support resources in a way that's tracked while offline and through timewarp, so you could set up infrastructure and not worry about it as long as your crew is inside. Exploitation will probably remain the primary mode of operation for Kethane, but I'll ponder alternatives. (And, of course, feel free to elaborate.)

SCANsat is mostly concerned with 2D map rendering. There's very little that could translate to Kethane. Of course, damny could add Kethane rendering support to SCANsat, but the other way around doesn't make much sense.

Not quite. In that shot, it's showing altitude data. I'm developing that shader to display arbitrary data with a heatmap. This will probably be used for a new resource, not Kethane. I might also make altitude and slope maps available.

I doubt that. (Or rather, Kethane already is really popular.) I know there were some holdouts who were waiting for stock resources, but my guess is that number is pretty low. The download stats will tell us in any case. The recent announcement about stock resources changes nothing about Kethane development. Since early this year, I've been operating under the assumption that the stock game will never have resource mining (or at least, nothing good enough to warrant canceling Kethane). I've been planning to add more resources to Kethane for a long time; the first step in that direction was version 0.5 with the Kethane API. More details on my expansion plans later. Kethane development has seemed relatively slow for two reasons. The first: I've been busy. As of Saturday, I have a lot of free time to work on things, so this no longer applies. Second: My recent work has been highly technical, mostly laying the groundwork for new features. It will take some time for those features to materialize. One of those features might look something like this...

Kethane has a license which describes how it can be used. This mod does not appear to violate that license, so no permission is necessary. It wasn't protectiveness that made me write the Kethane API.

What I want to know: Why do some bases and landers have more than two drills?

The community is rightfully upset that it took this long for Squad to come to this conclusion. When the resource mining plans were first announced, I asked Squad to leave that feature as the purview of modders, since it's a feature the community can build and Squad should focus on more difficult things. This year-long charade has done nothing but give the game undeserved attention.

For obvious reasons, I've long opposed the idea of Squad implementing resource mining. It's a lot of work, but it's nothing revolutionary, and Squad should be working on things that are. I had hoped there would be more interest (both collaborative and competitive) in resource mining from the modding community, but I suppose there may have been hope that Squad would eventually come through. (Beginning with Kethane 0.5, I operated under the assumption this day would come.) I'm not necessarily pleased with Squad's performance, but I think this is a step in the right direction. Regarding Kethane: Modding has been on my back-burner for the last few months. I will resume coding in earnest in a few hours when I complete my last deliverable of the year. (Woohoo!) I've set my sights on the third week of January for an expansion to Kethane that adds more resources. The API will remain open to the general public.