Majiir

Correct. You'd have to write your own module to read the current thrust from the ModuleEngines and relay that to the particle emitters.

It's a technical challenge. I could simply blend the colors in shared cells, but that could be hard to read. I could split cells into sections, but that would require inserting additional vertices. Currently, every cell has exactly six vertices (pentagons have a center vertex) so cell<->vertex conversions are fast integer operations. Additional vertices would mean using a lookup table and I'd have to write in some way to adjust cells, preferably without rebuilding the entire mesh every time. There's also the problem that I'm running up against the per-mesh vertex limit, so if I want to add many more vertices I need to split the mesh. It's all possible, it's just more work than I want to do right now for a minor detail. Yes. The last screenshots I linked showed Ore from the Extraplanetary Launchpads mod. The first release of the map won't do anything more than show resource scans, but I do have plans to add more. I wrote a custom shader for the grid renderer, so I can texture cells individually and shade those textures by the cell color. So, even without changing the mesh structure at all, there's a lot of flexibility in what the grid can display.

The first scan results are in! Kethane and Ore (Extraplanetary Launchpads).

Right-click the scanner to bring up the menu. Make sure you're not in time warp.

If you mean manual placement, this isn't possible with the current deposit system. If/when I revamp that system to support multiple generators and storage formats, this will become possible.

Quite well. You can change any of the particle parameters on the fly, so for an engine you could change its emission rate. This is how the electrical generator exhaust effect works.

You'll have to be a bit more specific! What situations cause lag? Any errors showing in the debug log? What hardware are you running? What other mods? What sorts of rockets are you flying and where? The scan map is a challenging feature, so it's the primary attraction. There are also some particle performance fixes and other minor improvements that will make it in, but I'm only working on those when I get bored/frustrated with the map. My plan is to release as soon as the new map is ready, regardless of whatever other items remain.

The deposit save format will remain the same. 0.7 will only change how scan maps are saved. Yes, all known information about resources will be displayed on mouseover. I'm not sure yet what other information (size, center, etc) will be available, but at the very least, the quantity of scanned resources will be there. (Computing the area under a cell is actually quite a bit harder than you'd think!) I had this concept as well, but it would require modifying the mesh and the whole thing isn't flexible enough for that right now. Brighter green indicates higher quantity. The old map was 256x128 pixels, or 32,768 "cells" in total. The geodesic grid has 10,242 cells. An average geodesic cell is 441.7 km^2. This holds true everywhere; cells do vary a little, but there's no trend along latitudes or longitudes that makes cells larger or smaller. At the equator, a 2D map cell is about 430 km^2. At the poles, cells are clustered and are closer to 15km^2 each (very rough estimate). So, at the poles, the cells are much larger than before, but that's okay. There was way too much resolution at the poles before anyway. This new map also makes it very obvious why you shouldn't just go for a straight 90-degree polar orbit; you'll find yourself rescanning the same handful of polar cells over and over again.

Actually, they're a little smaller: https://github.com/Majiir/Kethane/blob/master/Resources/Kethane.cfg#L50 That config is a legacy holdover. I think I'll add a new generator (and keep legacy support for the old one) in 0.8.

Below is a shot from the current dev build. The 2D scanning code has been ripped out to make way for the new.

What version did you upgrade from? This looks like you upgraded directly from 0.5 to 0.6 or 0.6.1, without upgrading to 0.5.1 as an intermediary step. If not, upload your save file so I can take a look.

That's odd. Delete that config.xml file (it's nothing important) and see if that fixes things. Check file permissions (read-only, etc) to make sure Kethane can write there. In any event, I hate the XML system so I'll be getting rid of it soon.

It won't wipe deposits. It will probably wipe scan maps.

The live development stream is up at: http://www.twitch.tv/majiir/c/2477016 I worked on particle effect performance and aesthetics, and Dani-Sang (creator of Kethane) made a surprise visit to show off a surprise. Give it a watch! Make sure you delete the Kethane file from your saves; if you just reinstall the mod, it won't wipe your save file and you'll keep the same deposits.

Where you put the file depends on how you're using it. If it's an effect for a specific part, throw it in that part's folder. If it's for general use in your mod, put it in GameData/{yourmod} or even GameData/{yourmod}/Sounds. You can use GameDatabase to load the audio clip. (It's something like GameDatabase.Instance.GetAudioClip() and you pass a KSP URL.)

Have you played with other UI frameworks? One of the biggest annoyances with Unity is that it's not declarative. (It's a procedural UI... yuck!) I don't have trouble with it myself, but if you're looking to make a UI framework, make sure you're familiar with frameworks like WPF. Even a primitive form of data binding could go a long way.

Yes, it's possible for deposits from different resources to overlap. There is currently no interaction between different resources when they're generated.

You're free to rescale it yourself. There won't be a 2-meter generator in the Kethane package unless it's a distinct design.

It will be recorded.

I will be streaming live Kethane development tomorrow. I'll be explaining my process and taking questions throughout the show. I'll be working with extractors and particle effects. Time: June 25 (Tuesday) at 4PM EST (when's that?) URL: http://www.twitch.tv/Majiir See you then!

You can't hook into those like you would with a C# event (those exist, but KSP and Unity don't use them). You might be able to register a callback with Vessel, but your best bet is just checking each frame for the current state of the vessel.

The main difference is that a given part only has one class deriving from Part, and it can have many different classes deriving from PartModule. The latter is definitely the more flexible system. The vast majority of projects won't require Part. You can still get a reference to the Part from a PartModule, so most of those methods are still accessible. PartModule has different (fewer) overrides, but it's not really more limited than Part; you can still get access to those events or just run checks during Update/FixedUpdate. tl;dr use PartModule, it's much more modular.

It's probably the docking ports; they're known to have crossfeeding issues.

I'm putting together the milestone for the 0.7 update. If there are features or improvements you'd like to see, please add them to the tracker. (Note that some issues are in the tracker but not in the 0.7 milestone; be sure to check!)

Only the heavy drill uses particle effects at the moment. I'll be adding particle effects to the small drill in the next update, and this might be the focus of a live development stream.