Majiir

Might it be more convenient to check for the presence of Kethane and default the setting on that basis? (To me, it makes most sense to default debug=false and let people launch cans full of rocket parts if they don't want to mine for resources; if the cans come pre-filled, this seems like the obvious choice rather than doing a Kethane check.)

Understood. I filled in some details because the scanning system has undergone a number of subtle changes, and they add up in a way that can make the current scanning experience rather different than the original. There's no need for anyone to get wound up about it. Scanning will probably see yet another buff in the 0.8 update, but at the same time the new deposit generator will add incentive for advanced players to have more detailed scans. Note that I say detailed and not complete; there won't be any real benefit to a 100% scan of the entire body, but there will definitely be benefit to having a complete scan of a deposit once you've decided to mine it. Entry-level players shouldn't have to worry about any of this because any landing on a deposit will make some resources available, but in order to extract large quantities (in excess of ~25-50 tons, still tweaking this) you'll need to be careful about where you land.

No, the KSPAddon issue is a stock bug that causes compatibility issues between completely unrelated mods. Universe Replacer had the most well-known conflict with Kethane, but a fair number of mods are affected by the issue.

True enough, my bad again. For now, the config is an easy tweak, and I'll have a patch out as soon as I've collected some other fixes. One issue was the KethaneData module not starting after it was created, and the other was the KSPAddon issue that causes mod compatibility. For the first, I manually added the module to the ScenarioRunner when it's created, and for the second, I implemented the fix I posted in another thread. This is incorrect, but for different reasons than you've already been given. December is circa-0.3, and since then a new detector was added, deposits were shaded by quantity, the hex map was added which reduces the number of cells you have to scan for a full map from 32,768 to 10,242, scanners skip already-scanned cells which dramatically increases scan rate in some situations and makes multiple scanners on a single satellite work efficiently, and altitude attenuation was changed to be multiplicative and much reduced on top of that. As a result of all that, a medium scanner at 500km altitude now scans twice as fast, has fewer cells to scan, shows more useful information when you do get a scan, and coordinates with other detectors to increase overall scan speed. There's also the bit where Kethane data isn't lost all the time now, so once you scan, you can be confident your data will remain even through updates. I wrote the KethaneParticleEmitter module to be a wrapper around the Unity particle effects system (legacy, not Shuriken). This module lets me configure the entire particle system in a part config file, but I can also interact with it from other plugin code. For example, the extractor module positions the particle emitters at the point where the drill head enters the ground and turns them on and off. A lot of the fun happens in the KethaneParticleDynamics module, which is responsible for all the "realism" effects on particles: gravity, atmospheric pressure, et cetera. This changes the emitter properties in real time to reflect the emitter's surroundings, and it's why you get long plumes of gas when you mine on Eve but only fast-escaping wisps of vapor when you mine on Gilly.

Every update has one or more major elements, but I also package all the miscellaneous improvements that are ready to deploy. The reason for the 0.7.6 update was to fix two game-breaking issues, and the reason for 0.7.7 was to fix a balance issue that was accidentally introduced in 0.7.6.

Whoops, that's my bad. It won't auto-deploy in flight, so you can use the locking feature of Procedural Fairings to get the right size. This will be fixed in the next version of Kethane (but I'll probably accumulate a few more fixes before I put out another update).

Kethane deposits are procedurally generated for each save.

Regarding keeping your deposits from version to version: the release notes specify compatible versions. If your current version is compatible, you can upgrade straight to the new version. If not, you need to first upgrade to the newest version which is still compatible with your current, and then upgrade from there. (In between upgrades, be sure to fly a ship with a drill on it so the persistence file can update.) If your deposit data is particularly important, make a backup of your save folder before attempting an upgrade.

Kethane 0.7.7 has been released. The download link on the first post has been updated. This update contains fixes and minor API improvements. This update is only compatible with versions 0.6 through 0.7.6. Changes in this version: Reverted an accidental change to the KE-C090 which combined its LiquidFuel and Oxidizer converters. InstallChecker now matches Kethane plugins by name, not assembly, so it will detect old versions. Fixed KethaneDetectorAnimatorUnity not playing the retract or running animations. Extractor animators are now optional. If an extractor has no animator, it will deploy and retract instantly with no animations. Removed KethaneExtractorAnimatorLanded. IExtractorAnimator is now public.

Modular Fuel System

Just to clarify: you can modify Kethane however you want for personal use. The Kethane license only restricts distribution.

They were initially configured to detect all resources for the benefit of Extraplanetary Launchpads since it didn't have detectors of its own. Making them Kethane-only potentially helps other third-party mods, too. Suppose someone wanted to make a resource that can only be found by scanning very close to the surface, e.g. with a rover or aircraft. If Kethane satellites can quickly discover any resource from orbit, such mods are impossible.

Kethane 0.7.6 has been released. The download link on the first post has been updated. This update contains fixes and API improvements. This update is only compatible with versions 0.6 through 0.7.5. Changes in this version: Detector parts will now only detect Kethane. Mods which define their own resources should include specialized detector parts. KethaneConverter modules now support multiple configurable input and output resources. Implemented a workaround for the stock KSPAddon conflict bug. Fixed an issue where Kethane functions would break when starting a new game. Fixed a potential performance issue on full-map cell refreshes. Added a flag by Dani-Sang. The KethaneWetMassIndicator label text is now configurable. Silenced an exception in ScaledSpaceFix.

KethaneGenerator does this: var resources = Misc.GetConnectedResources(part, "ElectricCharge"); var ratio = resources.Sum(r => r.amount) / resources.Sum(r => r.maxAmount); Misc.GetConnectedResources is just a convenience wrapper for Part.GetConnectedResources(). This works for other resources, too, and will only look at resources that can be accessed through a RequestResource call.

Yes. For now, it's just a technical change.

Input Rate is units/second consumed by the converter. All inputs must be present for the converter to run. Output Rate is units/second produced by the converter. Output Ratio is in terms of the total mass of the inputs. If a resource is specified in both of these categories, the result is summed. There must be enough room for all outputs for the converter to run. I'd like to implement optional "waste" modes where a resource can be discarded, but I don't think that will be in the first release.

The converter module now supports multiple input and output resources. I'll be releasing it sometime during/after this weekend, along with some fixes. I haven't had rep from you recently, but I am getting close to two bars...

The only file Kethane creates is settings.cfg, and it's perfectly happy to find that file missing. It just fills in default values. I only know of one major issue currently, and it's fixed by quicksaving/quickloading.

Regarding transport efficiency: run the numbers on other tanks. Kethane tank mass ratios are not constant across the board the way stock tanks are. Over time, Kethane's popularity has grown and I've fixed tons and tons of bugs. The result, oddly enough, is that Kethane seems more buggy because the remaining issues are more difficult for people to understand. The ratio of user error cases to actual bugs has dramatically risen, and the quality of bug reports has nosedived. (There's also a much greater incidence of bugs caused by something other than Kethane, like the stock game or another mod.) All that coupled with a larger user base means that supporting Kethane has nearly become a part-time job. The forums are really a poor format for handling bug reports, so I ask people to use the issue tracker because it makes things more manageable for me. It's helpful because it indicates that something is wrong on your end. It might be some rare bug you're running into, but it's much, much more likely that you've done something wrong with Kethane or your KSP install, or that you're running into the IO issue where antivirus or other software interferes with the KSP code that Kethane relies on. The fact that it works smoothly for so many people is a big hint!

Just to throw in another wrench: since scanning scales logarithmically with timewarp, all else held equal going to higher time warp makes scanning take less real time and more game time. Of course, if your satellite is built such that going to that higher time warp reduces idle time, you may not be incurring a game time penalty, but you also won't make it faster.

I've written about the Kethane/UniverseReplacer conflict here. Turns out (surprise surprise) it's a stock bug that causes mod conflicts.

This issue has been resolved and the fix is no longer necessary. --------------- Hi folks, If you're having issues with mod compatibility where one seems to "disable" the other, you may be a victim of a KSPAddon bug. I discovered this while hunting down the cause of the Kethane and UniverseReplacer conflict. What is KSPAddon? This feature was added in the KSP 0.20 update. A class tagged with KSPAddon can start without an associated part, which is useful for mods that add behavior at a higher level. Some mods that have part functionality also use KSPAddon to run background tasks or handle plugin-wide data. What's the problem? There's a bug in the addon loader (in the stock game) that can cause mod compatibility issues. KSPAddon has a "once" parameter which, if set to true will cause that addon to only be started once (until the game is restarted). Once an addon starts, the addon loader adds it to a list of addons to skip for next time. The problem is in how entries in this list are compared; the addon loader only looks at the two attribute parameters. So, if you have two addons from two different mods that are both configured to start at the main menu and start only once, only one addon will ever start because when the loader sees the second one, it thinks it's already been loaded and skips it. How do I fix it? Until this is fixed in the base game, you have two options. You can set the "once" parameter to false and refactor your code to support that, or you can use my KSPAddonFixed attribute. This requires an additional type parameter which should equal the type you're applying the attribute to. Example usage: [KSPAddonFixed(KSPAddon.Startup.MainMenu, true, typeof(MyAddon))] public class MyAddon : MonoBehaviour { // ... } KSPAddonFixed source (under CC0 Public Domain Dedication): /// <summary> /// KSPAddon with equality checking using an additional type parameter. Fixes the issue where AddonLoader prevents multiple start-once addons with the same start scene. /// </summary> public class KSPAddonFixed : KSPAddon, IEquatable<KSPAddonFixed> { private readonly Type type; public KSPAddonFixed(KSPAddon.Startup startup, bool once, Type type) : base(startup, once) { this.type = type; } public override bool Equals(object obj) { if (obj.GetType() != this.GetType()) { return false; } return Equals((KSPAddonFixed)obj); } public bool Equals(KSPAddonFixed other) { if (this.once != other.once) { return false; } if (this.startup != other.startup) { return false; } if (this.type != other.type) { return false; } return true; } public override int GetHashCode() { return this.startup.GetHashCode() ^ this.once.GetHashCode() ^ this.type.GetHashCode(); } } I advise including the KSPAddonFixed source in your plugin. You could reference another plugin using it, but that's a hassle; multiple definitions with the same name won't cause any harm (since they'll be in different namespaces). [EDIT] On the KSP issue tracker: http://bugs.kerbalspaceprogram.com/issues/1176

Reminder: Bug reports in this thread will be ignored. Submit them to the issue tracker and follow the bug reporting guidelines.

2^16 = 65,536 (bytes, in this context). The 32-sub grid has 10,242 cells, which is indeed lessâ€â€but when you store a double (8 bytes) for each cell, you blow through that limit. Seriously guys, stop trying to armchair program if you don't know what you're talking about. I love the enthusiasm, but you're spreading a lot of information on both sides that's just downright wrong. No part of Kethane requires (or even encourages) you to have a full scan. It takes about ten seconds to find your first deposit. (Yes, I have actually done test runs and timed this.) Even scanning on a highly inclined orbit, it doesn't take more than a minute to find a nice equatorial deposit on suitable terrain. If you find yourself leaving your computer on to scan, you're either using a poor satellite design, misunderstanding your gameplay options or both. My goal with Kethane design is to make it easy to get your toes wet and rather challenging to swim in the deep end. To that end, I think scanning is very successful in its current form. If you disagree, excellent, let's talk about it, but let's talk in terms of that balancing goal.

Everyone hold on a second. Implementation is absolutely possible and well within the bounds of my coding capabilities. Vessels don't need to be loaded at distance for this to work. Multi-sat/background scanning has absolutely nothing to do with 64-bit support. It would take a negligible amount of RAM (at worst, a list of vessel references and some metadata; we're talking a few hundred bytes here) to do. On-rails calculations do not require physics. KSP uses idealized Keplerian mechanics, so orbit positions can be solved in constant time for any timestep (SOI changes notwithstanding). Compatibility with future KSP updates is not a concern; anything could change, and I'm prepared to make compatibility updates. Every modder is.