Majiir

I'll have this fixed for the next update. I'm not sure why surface attach is enabled at all. The fan doesn't run in vacuum. (The fan control function gives zero when at zero pressure.) The generator still works; it just doesn't get the efficiency bonus. Kethane is drawn from the fuel tanks. Bear in mind that in atmosphere, you're only drawing something like 0.3 Kethane per second to produce 75 ElectricCharge per second; running just a drill or two, you're probably not going to notice the missing Kethane. No. There is currently no 2-meter generator part in the works. The green gas only emits when you're mining from a Kethane deposit.

Latency is intended, even; that's what the moving average is for (that and smoothing). Adding a PID controller would add latency on the consumption side as well, but I could tune it to have a pretty quick response. At the very least, I think it should ignore total battery capacity and instead set throttle based on how much energy has been drained relative to peak output. I hadn't even thought to make the generator create heat. Its exhaust is hot, but I'm not sure the generator needs a heat mechanic; since you can't throttle it manually, it would be obnoxious for the thing to blow up on you just because you dock with a discharged battery. It also may not be burning the Kethane completely; it could be working like a fuel cell for much of the energy and burning some of the products. It definitely puts out heat, but it's not going to heat up like the turbine. I'll take a look at all this at some point along with the mass and reaction stats. I'd like the generator to be competitive with solar panels when running at high load for relatively short periods of time. I think it's already competitive with RTGs; it's much more compact and even including fuel requires a lot less mass for certain loads.

You can use Part.GetConnectedResources (I believe that's the name) to get a list (it's an awkward pass-by-ref syntax) of objects which represent a resource capacity and current amount for each connected part. This takes fuel routing into account, but for ElectricCharge the routing rules allow you to get access to any part so you can just call this on the vessel root. Then you can set the current amount on each of those to zero. If I may suggest: you could use this to build an improved RequestResource, which many of us would love to see!

I didn't have any issues with the generator, but my method of attaching parts is always to view the craft from the side so I can plop the part straight down. I'll play with it when I'm back. I suspect it's not fixable by anyone except Keptin, at least not without some fancy plugin voodoo. In his defense, the generator is still an in-development part; it's missing an animation and presumably the centering is all part of testing that would happen before he gives the final certification. It did have two of its animations working and looked damn gorgeous to boot, so I released it anyway. The generator has a few different mechanics. First, a demand ratio is computed from the current percentage of ElectricCharge using a logistic curve. The function looks like this. The X axis is the current level of ElectricCharge and the Y axis is the demand ratio. There will only be demand if it comes out to 10% or higher, so the generator won't try to run above about 85% capacity. By the time you're at 40-50% capacity, it's trying to run at full speed. I say trying because the demand doesn't directly translate into power output. The demand is used to consume Kethane, and each frame, the demand is multiplied by the ratio of Kethane we were able to draw. (This just accounts for situations when we're running out of fuel.) The resulting value is fed into a 3-second moving average. Waste XenonGas is produced immediately after Kethane is consumed. Simultaneously, the moving average is sampled to give the output ratio. This is used to produce the actual electricity and scale the exhaust effect. The intake fan has its own 1-second moving average. The input to this average is this function of atmospheric pressure. The result of the average animates the fan and reduces the quantity of Kethane required. (It doesn't affect output, though, so it's an efficiency mechanism only.) The value of the average is multiplied by the current atmospheric pressure to figure the actual efficiency gain, which gives this function under constant pressure conditions. There are a couple things I could do to make it feel a bit better. I could replace the demand controller with a PID, but that would introduce another source of latency; or I could make the demand function scale off something other than total battery capacity. (Instead, it could scale off something like fifteen seconds worth of full power output.)

I officially updated Kethane for KSP 0.20 compatibility about two weeks ago. Since then I've released four other updates, two of them substantial. You should only download Kethane from the thread here: http://forum.kerbalspaceprogram.com/showthread.php/23979-Kethane

I'll be developing live. Since I'll be working with particles, it'll be a lot more interesting than just staring at code.

I've not recorded anything yet, but: http://www.twitch.tv/Majiir

I'm taking a break from development for a couple days. When I get back, I'll be running a stream showing the development of a feature or two. In particular, I'll be working with the Kethane particle effects modules, which should make for some good eye candy. More on that soon!

It sounds like you may have installed Kethane in the wrong location. You should copy the GameData folder directly into the KSP root directory and allow the folders to merge. Upload your output log if reinstalling the mod doesn't solve the issue.

You may also be interested in the Kethane documentation.

Awesome! I love seeing what people build with Kethane. I'm not a KSP dev. ;-) Release dates are sometimes hard to pin down, but versions are easier to talk about. Kethane has a narrower scope so it's easier to plan releases. The geodesic grid map will be in the 0.7 update. As you can see, a lot of it already works great!

I may be misunderstanding you, but just to clarify: KethaneDrillAnimatorLegacy is, well, a legacy animator. It's only for the original Kethane drill and shouldn't be used on any other part. The KethaneExtractorAnimatorLanded module lets you use any old part as an extractor, and it simply uses the vessel status (whether it's landed) to determine whether the extractor can harvest resources. The KethaneDrillAnimator module powers the heavy drill and supports animations, particle effects, ray casting for ground, the works. It's definitely the best of the three, but it's complicated to use. Details are in the documentation. The EPv2 auger uses the ExtractorAnimatorLanded, but I've been discussing the DrillAnimator with skykooler and making enhancements so it's suitable for his use. I cold brew, myself. Iced coffee year round! (On a serious note, donations are a tough issue because it's hard to put a value on someone's contributions to a project. But I digress...)

Why are you modifying the Kethane drill? You don't need to modify Kethane parts to make this mod work.

It included Kethane models and modified textures. You can see them in the screenshot links which remain.

You can check. KSP/GameData/Kethane/Plugins/MMI_Kethane.dll > right-click > Properties > Details > Product version.

RTGs fluctuate because they run in Update instead of FixedUpdate. I reported this bug during 0.18 experimentals when RTGs were introduced, so don't hold your breath. (You can observe this by creating a module which consumes resources during Update; RTGs supply it smoothly, and everything else will make it fluctuate.)

I'll save you the time: the scanners use the vessel center. Unless you can substantially change your center of mass between scanner pings, you're not going to get anything from spacing them apart.

Wait, you want the map to go slower? Jots down note and credits this to HoY...

Actually, I threw that together after a good 18-hour sleep. It was part of my wake-up routine, I guess. Are you out of battery power? This sounds like your ship is uncontrollable. Or, you could be in time warp.

Kethane 0.6.1 has been released. The download link on the first post has been updated. This update fixes a few issues and makes minor improvements to the modding API. This update is only compatible with versions 0.6 and 0.5.1. See the 0.6 release notes for information about upgrading from 0.5. Changes in this version: Fixed an issue where deposits would not be reloaded when moving between saves, which could overwrite another save's deposits. Fixed an issue where scan map colors were scaled from the wrong resource definition. Fixed an issue where Body nodes would not override scan map colors. The KethaneDrillAnimator deploy animation is now optional. Particle effects for the KethaneDrillAnimator are now optional, and multiple particle emitters can be defined for the same label. (KethaneParticleDynamics may still fail with multiple effects using the same label.)

0.7 or 0.8, depending on how those updates shape up. 0.7 will definitely include the new scan map, which means it will also have a new save format for scans. It probably won't have a new deposit generator or a new save format for the actual deposits; I expect that will be a major feature of 0.8. I like to include miscellaneous improvements in every update, and since one of the major features of Kethane is the modding API, that means improving modules. I'm glad to hear it! My goal with Kethane has always been to balance it while keeping it fun.

Yes, that's the plan. (To clarify for others: this is mainly a coding change, not a parts change.) This would mean making each hex its own GameObject. There are about ten thousand of them, and that means at least a hundred thousand .NET objects instantiated, and I'd have to update the position and rotation of all ten thousand GameGbjects every frame, whereas now I just update one. The more I think about it, the more I'm convinced UVs are faster. :-) This is planned along with a bunch of other features for a new deposit generator. Probably in 0.8? 0.9?

Heh, I should have been clearer. I know how to write the module code. (I'd make it a distinct module, anyway, since it has more advanced behavior than a simple extractor.) The issues are: how to design the mechanic so it fosters enjoyable gameplay how to balance it with other parts and mechanics getting models of similar caliber as the existing ones planning when in the roadmap to insert this I'm a programmer, but programming parts is really easy. There's a lot of extra thought that goes into maintaining and improving the overall quality of the mod. Module code alone can't keep it afloat! Alright, I'll check it out. I kind of like seeing the hexes as they go "around the bend" but it could definitely be softened up. I'm currently using the KSP/Alpha/Unlit Transparent shader, so I'll see if that has what I need. A lot of things that are easy in Unity are much more difficult in plugin code, so it might take a bit of experimentation. Yes, but I need some way to assign colors to each hex individually, and changing the material color would affect all hexes simultaneously. Instead of changing UV coordinates, I could move meshes between objects with different materials. I'm not really sure which is best. My current method seems a tad heavier for each frame rendered, but the other way might be really problematic when updating a lot of cells at once. Or maybe it doesn't even matter. :-)

Thanks! I like it a lot better than the old method. I can't believe I didn't think to try it earlier. What shader would do this? I could try writing my own, but I have no experience with shader languages. The hexagons are a procedurally generated mesh. Each hex is its own set of vertices and triangles, all in one MeshFilter. There's a texture for it but it's just a color palette, so each hex gets its color from UV coordinates. I was planning to have cooler textures at some point. These are all cool ideas, but I'll have to play with the hex grid first! I'm still experimenting with some of the mechanics like mouseover detection.

Yes. The map redesign is the core feature for 0.7. The two colors are green and black. The missing cells don't have geometry at all. This was just a technical proof of concept; I needed to test programmatically assigning colors to each cell.