Majiir

Not really, just that the map view exists and mods can interact with it. There's no special "put things around planets" API, but obviously mods can do it manually. The Kethane map will conform to irregular surfaces in the next version (the code is done, it's just waiting for release). The old 2D map was inferior in almost every way; it was ridiculously difficult to tell what the map was even representing, let alone target a landing on a deposit. There's a data export feature if you really want to view it some other way. (Also, what 1960s Kethane map are you speaking of?) We don't have different wheel types; as far as I know, we have exactly one, and that's ISA Mapsat (which is unmaintained anyway). Kethane abandoned the 2D map view because it was unintuitive and the texture format was highly problematic. Even if another mod starts using 2D maps, that's just one because ISA isn't being actively developed anyway, so there's no way for it to integrate with the new mod. Like I said, if we start getting too many systems, we can work on merging them. For now, we have two distinct methods (2D and 3D). In the 2D case there's only one contender, and in the 3D case the use cases are so wildly different that there's no unified API to build anyway.

I understand the desire for a common 2D map view. However, as the developer of Kethane, I'd prefer this not be done by the stock game. Remember, the stock game already has a common map interface (hint: it's the one Kethane, RemoteTech and MechJeb all use). This is something addon developers can do as needed. Since ISA is currently unmaintained, I'd argue it's not currently needed. If someone wants to create a 2D map view and integrate it with other mods, they should speak with the developers of those mods to work out the details. [EDIT] To elaborate on why I'd prefer the stock devs not touch this: Adding a stock system would "lock in" mods to using that system for fear of otherwise being incompatible. Given that addon devs can't even agree on a common system (yet) and the market for such a system is quite small, I think it's much better to let it evolve naturally. If we ever reach the point where too many implementations exist, that's when the stock devs can build something into the game. Until then, it would be a waste of their time to implement something without even knowing what problem it's supposed to solve.

To clarify for everyone: the download server is functioning fine. There's an issue where the server (but not the Kethane download itself) has been flagged by some antivirus and filtering services and may be blocked. If you can, temporarily disable those services to download the package, and then feel free to scan the package itself if you're worried. I'm looking into solutions and alternatives, and I'll have something ready in time for 0.8 (which will probably be synchronized with the KSP 0.22 release, but it's hard to be certain). As others have mentioned, third-party mods should create their own detector parts. It is possible for a part to detect multiple resources; see the Kethane API documentation for details.

isEnabled is defined by PartModule. IsEnabled (note the capital I) is defined by KethaneConverter and does what you need. The resource lists aren't directly exposed, but you can hack around it by accessing KethaneConverter.config, which is a copy of the module config node. [EDIT] I should note that the config node will only ever report the configuration, not the current status of the converter. You can assume the converter is running at full speed, but that's often not the case. (You can usually leave a converter turned on without harm.)

I enjoyed the talk. Thanks to both of you! Harvester, there was an item you skipped over near the end that I thought was interesting. You had a slide reading something like "repeat until indoctrination: mods are not competition". I wondered if you could elaborate on that (or just say what you'd planned to originally). Have there been times when mods felt like competition? Getting more broad, how have mods influenced your development methodology or even specific points in the game's development history? Cheers, Majiir

That's why I told you to look at that branch. It's been around for a while now, and it does exactly that. Generator classes are defined in plugins, and then configuration and state lives in the persistence file. (If a persistence doesn't have a generator defined, it loads the default from the KethaneResource definition. This means that even if the default generator is upgraded, you can keep the old one in your saves or choose to upgrade.) It's designed to be used as a third-party API, so there shouldn't be any need to modify Kethane (although for experimentation and feedback purposes that's probably easier).

Not currently. The size in memory is fairly small; there's room for optimization of the fuel tanks, but it's a lot of effort for little memory savings. Kethane is large on disk, which I've regarded as fairly inconsequential. If there's a tool which converts to another format without impacting texture quality or load times, point me to it and I'll switch over the textures. You can use debug mode to show all deposits regardless of your current scan mask. You could also edit the scan masks in your persistence file or edit the rendering code, but those options are both overkill. If you're actually modifying the deposit code in the plugin, you should take a look at the feature-generators branch on Github.

0/10. I don't know any of you and your ratings are all overinflated.

My turn to be blunt: you're leaking self-importance and it's gross. At perfect mass efficiency, a Kerbal would convert to 46.875 units of Kethane, not 150. You're already getting your "kerbal's worth" from it; in fact, you're getting at least three. The most efficient method to transport fuel in KSP is launching racks of seats filled with Kerbals and blending them up as needed. When that's the case, I hardly think the blender is in desperate need of a buff. You might not think it's worth blending up a Kerbal for 150 liters of Kethane, but that's a flaw in your decision-making process, not a flaw in my balancing strategy. Actually, you are.

The download link is and has been working fine. If you're having trouble, it's very likely something on your end.

I was, but it involves reengineering the geodesic grid from scratch, and I've run into trouble with a few of the necessary algorithms. It'll take a good few days of solid whiteboarding to solve, and I'm unlikely to have that sort of time for a month or two. Something like a quadsphere would accomplish a similar objective but just look a little different, so I might even attempt that instead of holding out for the improved grid.

You can absolutely ask KSP for the terrain height at a point. (To be precise, you ask the planet's PQS controller.) For what it's worth, I don't like "reveal" schemes as they're being pitched, mainly because they focus way too much on textures. Forget about textures and images. Store the important data ("what areas have been scanned?") and optionally cache the terrain data, but neither should be stored as a texture. You could get fancy with quadtrees or density maps or what have you, but it could also be a simple grid. I just don't want to see ISA replaced with another technical nightmare.

The Kethane produced by the blender is already more than three times the mass of a Kerbal.

KAS, ISA and Kethane (and possibly others listed) cannot be redistributed as per their respective licenses. It doesn't.

Honestly, if you aren't bringing some kind of talent, you aren't likely to get any takers. People can edit configs and generate ideas just fine. Modders contributing to larger projects want to see that their work will be combined with other high-quality work, and that their work will be presented well.

Could you post (or PM) some details on what you've made and how it interfaces with Kethane? Use of the plugin as an assembly reference is governed by the license, but in all likelihood you'll be fine.

Consider also that you're often licensing many components of a mod. If most of the iterative work is in the plugin, someone could still use your incorrectly licensed parts, and that can be undesirable.

API and Modules Documentation

GPL is a license for the general public and does not constrain the owner of the code, so you can release updates under a different license with restrictions. This is exactly what happened to Kethane. It's conceivable that some license might explicitly waive the creator's right to relicense the work, but as far as I know, all the well-known open source licenses don't have any such clause.

Don't get me wrong, I'm not blaming you for the original code, and I'm well aware of its history. I guess I was expecting you to have impatiently rewritten large chunks by now. It's very likely, in my opinion, that this bug has existed for quite a long time.

Absolutely. I only poked a little at the IR code (and it's not exactly comprehensible), so my hunch may be completely wrong, but whatever's causing joints to drift apart is likely responsible.

Note that KSP plugins can only target .NET 3.5 or earlier, and that version of the framework was released in 2007. Mind you, a lot of tutorials from 2007 will be for older versions like 2.0 and it would be really bad to learn from those, but you shouldn't feel like you have to keep very up-to-date. Programming languages don't move as fast as other technologies.

Mecanum wheels were indeed fun, but unfortunately KSP's wheel physics don't lend well to building them, and after a few minutes IR always bugs out, probably because I crank the speed way up on the rotatrons. On the quaternion issue: quaternions are four-dimensional vectors, but rotation quaternions are normalized (their length is always 1). In game programming, quaternions can often deviate from that property because floating-point errors add up after successive operations. Regularly renormalizing them solves the problem, but it's additional computation time so it's rare that quaternions are automatically normalized. I'm not certain that's what's happening here, but there's definitely some kind of drift associated with high rotation speeds.

If you want something featured, just tell xPDxTV. (Alternatively, drop me a note and I can poke him.) I think the Weekly is currently trying to highlight emerging mods (something I've advocated) but I'm sure he'd be happy to highlight an established mod if it makes a substantial update. (Kethane was featured twice, for example.) On a different note, I've recently been playing with IR to build mecanum wheels, and I'm surprised how buggy things are even though the codebase has had quite the time to mature. I'm getting a lot of what looks like quaternion errors to me (they're not being normalized, so the rotation matrix also performs some translation or scaling of coordinates). These quaternion errors could even be in Unity code, but renormalizing them should still be doable from the plugin.

Suppose you release some code under GPL and shortly thereafter realize it's not for you. You can release your code under a different license, but it's already out there under GPL so people can fork it left and right. That's the sort of trap I'd like to save fellow modders from. Wait, what? Git is a basic programming tool. Just who are these "old-as-hell" project maintainers who aren't using source control? ...and what's hard about downloading source from Github?