Majiir

I have been working on a patch, but this is a complicated fix. I'm currently in the process of writing a custom raytracer for mouseover detection. For quite a few months, I've been working on a complete replacement for the geodesic grid code, and in the last several weeks I've made substantial progress. In order to implement the raytracer, I'll probably need to include that replacement, so I also need to integrate that with the rest of the mod. I have other things tying up my schedule so I can't give a good estimate on when that will be done, but it's in the works and I'll make a release immediately upon solving the delay issue.

Primarily just maintenance, but that's for bugs as well as compatibility. I've not had time yet to dive into KAS bugfixes, but after the next Kethane release I should be able to give it a good look. Active development is possible, but I don't expect to have time to devote to new features until mid-December at the earliest.

May I suggest a sort of "wrapper" node where rules inside it have different parsing rules? I'm not advocating this over any other solution in particular, but I thought I'd throw it into the mix. This is absurd. It's an opt-in beta test. Of course it's not guaranteed to be painless. Also absurd. He talked to people (IRC) and then made a thread so people could talk about it more. There's absolutely nothing wrong with his methodology here. Testing isn't about developers doing exactly what you think should be done, and ModuleManager isn't nearly complex enough to warrant a public review of a design spec before releasing a prototype.

That only solves a few use cases. If a mod needs custom ModuleManager behavior, telling users to replace their single installation won't work. The custom behavior might conflict with what the regular plugin does, but even if it didn't, you could only have one such mod installed at a time. If you package a custom plugin inside your mod, the unmodified plugin commonly placed in the GameData root will also apply any ConfigNode patches it finds, often breaking configs in the process. The current ModuleManager architecture very much inhibits customized versions.

I should comment on the proposed changes since I had some part in their conception. Before that, I want to remind everyone that sarbian is coping with a genuinely difficult design challenge. He doesn't deserve harsh treatment. So, on to the reason for a change. ModuleManager's license allows it to be customized for specific applications, which is something I've been wanting to do for a few different projects. The problem is that MM's current design doesn't support customization in the larger sense because every loaded MM plugin will execute on all MM configs and modify all config nodes everywhere. So, my desire was to allow custom ModuleManager instances a chance to be the only instance acting on a particular set of MM configs. This gets complicated because MM is used for a variety of purposes. Here are a few examples (please suggest others): User-created tweaks. These are traditionally tossed into a file in the GameData directory and can apply broadly to parts from multiple mods. Tweak/enhancement packs. A config which adds a mod's parts to the tech tree falls under this category. It's not user-created, but it's user-installed and isn't part of a larger mod. External changes applied by a mod to other parts. FAR uses MM to add its modules to the stock wing parts. It needs the capability to apply configs from its own directory to parts from other directories. Internal changes applied by a mod to itself. I can't think of an example of this in use today, primarily because it's difficult to fit into the current scheme. Configuration of a mod by another mod. This is a particularly tricky one. Someone earlier in the thread mentioned that Kethane uses a MM config to add ModularFuelTanks support. I argue that this is actually an anti-pattern and should be eliminated, but for now it's something we need to support. It's hard to write a hard-and-fast rule that satisfies all of these needs. As evidenced by this thread, you can't just restrict the root GameData/ folder because that makes #1 (and #2 to an extent) more difficult on users. You can't just allow a mod to "hide" MM config nodes in its own directory, because then things like ModularFuelTanks can't see their own nodes. To satisfy #4 (and maybe #3), you can roll a custom MM plugin which doesn't read configs outside its own directory, but the problem here is that the stock MM plugin in the root directory will also apply its rules. There needs to be some mechanism for blocking some MMs from applying a config while allowing others. Note that this doesn't mean blocking target config nodes. I can't imagine many scenarios where you'd want to restrict a part config being modified by other MM files. What I advocate is the ability to keep certain ModuleManager configs (which describe the actual modifications) executed only by the desired MM plugin. That's because the current ModuleManager design doesn't allow for custom plugins. This is evidence in favor of these design considerations, not against. Bear in mind that customized ModuleManager plugins aren't necessarily intended for end users. MM is a powerful tool that has a lot of applications, and many will be completely transparent to users.

It's absolutely a bug, and it's something I've noticed for a while and confirmed last night while working on the grid. I've put it on the tracker now, for your reference: https://github.com/Majiir/Kethane/issues/193

The problem is there are few ways of making it challenging to get into that position. I have a couple projects in the works which would make satellite positioning more challenging than "go polar and timewarp" but without those, an optimal strategy for scanning quickly emerges.

Just to be clear: this is trivial from an implementation standpoint. However, it wouldn't allow for consuming ElectricCharge, which is my primary objection. Over the last couple months my thinking has been slowly shifting on this, but simply removing the electrical requirement and enabling unfocused scanning is unsatisfying, especially since the larger, heavier scanner would either be hugely disadvantaged (no unfocused warp) or not as differentiated (since it currently consumes more power). This is by design. It's unrealistic and needs tweaking, but logarithmic scaling of the timewarp factor achieves a few important gameplay goals. Removing it would also introduce some bugs and technical challenges. I will probably be adding some kind of conical feature to Kethane, but it will be something like "you can pick a cell anywhere in this cone" rather than "you've scanned all the cells in this cone" to keep scan rates from spiking. All of these suggestions are things I've previously given a lot of thought to. SCANsat makes for an interesting testbed for some of these ideas, so I'll definitely be watching it closely. Just remember that Kethane is a different mod revealing a different kind of data, and things like coverage requirements are much different. With all that said, this is a SCANsat thread, not a Kethane thread. It might be appropriate to create another thread if you want to continue this discussion rather than cluttering up damny's.

You misunderstand how KethaneParticleEmitter works. There aren't actually particle emitters defined on the auger model itself. KethaneParticleEmitter is a self-contained module for defining a Unity particle emitter from a part config file. In the case of the auger (and the normal Kethane drills) the KethaneExtractor module manipulates any KethaneParticleEmitter modules it finds, positioning them at the drill point and controlling whether they emit particles. The reason adding KethaneParticleEmitters to the smelter doesn't work has nothing to do with the smelter model. It's not working because your emitter definition has "Emit = False" and there are no modules on a smelter that programmatically turn emitters on. The Kethane particle effects have nothing to do with the stock FXGroups system.

The built-in effects are also Unity particle systems, so performance will be similar. Converters don't currently support particle effects, but I could add that easily.

Results of performance testing the search algorithms of the new grid code (cell values are milliseconds of execution time):

You just can't be sneaky about it. As long as it's obvious to the user where and what you're saving, there are no problems. Just don't act like malware and you'll be fine.

The OP clearly explains this mod does in fact query the game directly and does not reveal a prebuilt texture. In the case of biomes, they're internally defined by a texture, so that texture is the best possible representation (color encoding issues aside). I'm not sure why you assume he would have stolen something. ISA code is a mess, and mapping isn't difficult. Saying it "works" is technically correct but doesn't accurately capture its usability problems. That's why users are clamoring for something even remotely close to a mapping mod.

"No offense, but you suck." Rather than prefacing a nasty comment with this sort of disclaimer, try writing a more diplomatic comment in the first place. The config switch for the main menu overlay was added over three months ago, and so was the settings file documentation on the wiki. For a small fee, I'd be happy to prioritize your request over my four other KSP projects and not insignificant real-world responsibilities. I'm well aware of the issue and I've done extensive profiling. The slowdown is occurring in a Unity routine I'll need to work around. The longest delay I measured was four seconds, enough to be obnoxious but not enough to be completely game-breaking. I will fix the issue, but it requires rewriting the grid positioning code. It's not something to rush without thorough testing. If you're an unimaginative player, I understand why you wouldn't see the point in a highly efficient engine for use on Duna and Eve.

This is correct. This is a log entry caused by KSP and doesn't actually represent an error. I can silence it now that System.IO is unblocked. You may post ModuleManager configs for integrating Kethane parts with the tech tree, as I posted earlier. I've wanted a 2.5-meter drill like this for some time. More drills are currently in the works, but it's a little too early to say anything for sure.

Nice work! It looks like you handily beat me to the prototype phase. It's great to see someone get a mapper working with deferred terrain queries without using a prebuilt map outright. Don't get too hung up on some of the scanning challenges like interpolating through timewarp or draining electricity while unfocused. Depending on how picky you are, the solutions to those problems can be straightforward but unsatisfying or just incredibly difficult. I also suggest you not stay in the development forum for too long. Fix up a few issues, and go for a release. Too many good plugins get lost in this forum for fear of releasing. (You can always continue development after release!)

Innsewerants has rights to his creation. However, he made a restrictive licensing decision, and that decision is open to criticism. You should chase people away for violating the license, not for asking why it was chosen.

KAS 0.4.4 is only compatible with KSP 0.22.

The latest release notes are always linked in the first post. There are actually two KE-X130 part definitions now. One has a new model, and the old one is there for craft compatibility but isn't available in the VAB. It will eventually be removed completely.

It's not attractive from a modding standpoint. Obviously, it's fun to unlock mods if you're playing career mode. At some point I'll do a proper writeup on career mode and how Kethane and KAS fit into it, so be looking for that. I think both can have a much larger role than simply "getting unlocked" but it's substantially more work to get them there than adding parts to nodes. (KospY might prefer I just throw KAS into nodes, and if that's the case, I certainly will. In this instance I'm applying a personal modding bias, preferring quality and richness over speed or breadth.)

I may eventually, but don't hold your breath. I encourage people to post MM configs. I'm working on a number of things for KSP and I'm relatively busy otherwise, so career mode support is a low priority. (Why? Career mode has no endgame. Mods are all about endgame.) If I can get to working on Kethane in the next few days, my first priority will be solving the performance issues with the map screen.

You may post config edits for tech tree integration in the form of a ModuleManager config file. Please do not post entire modified configs. Cheers.

Does anyone know of a software license which allows use (as in linking/referencing) and distribution of source, but requires attribution and does not allow derivatives? (Basically CC-BY-ND, but CC recommends not using their licenses for source code.)

A few have asked me via PM, so I've authorized ModuleManager-based config edits that add KAS (and Kethane) parts to tech nodes. (I arguably don't need to grant permission for that kind of edit anyway, but I'll make it explicit here.) In keeping with KospY's license, please don't distribute the edited config files themselves.

Yes. I noticed the planet-switching issue during 0.22 prerelease and spent quite a while looking into it. It's not, as you and I both guessed, caused by the adaptive grid adjusting itself. Profiling showed that the game is spending seconds on the same two lines of code, and they're lines which in theory should return near-instantly. The code that's hanging is all in Unity, so it's hard to diagnose exactly what's causing the problem, but it's related to repositioning the grid over the new body. I have an idea for working around it, so 0.8.1 may come with a fix.