Majiir

With a simple plugin, you can feed flight controls directly to the game instead of mucking around with keypresses.

I received a (rather blunt) private message asking me about Kethane content in this mod. I can only guess at what was in the download based on the posts here, but for the avoidance of doubt: I have not granted any license exceptions for this mod. Models and textures from Kethane may not be used, and exceptions for these are granted rarely. Of course, the Kethane API is open for use by anyone as per the license. I strongly encourage those taking advantage of the Kethane API to model their own parts, no matter how basic. You can also reuse stock part models and simply add the relevant Kethane modules to the part config.

I was asked to comment on this; apologies for not getting to it earlier. I will echo what others have said about this versioning scheme being unintuitive and difficult to implement. However, I also want to make another point which pokes at why this is even a topic of discussion: Version numbers from different mods don't have any relationship. What does it mean if Kethane is at version 0.8.1 and KAS is at version 0.4.4? Absolutely nothing. There is also no question we'd ever want to ask about two version numbers from different mods. Is one more full-featured? Does one have more bugs? The answers to those questions cannot be captured by a version number. Comparing numbers from the same software is useful. Which version is newer? Is this upgrade a small change or a massive one? These questions can even be more complex. If Product A is compatible with Product B version 1.2.x, we know that we can use 1.2.1 but not 1.3.0. The other information you've attempted to capture simply doesn't belong in version numbers. It's good information, but it needs to be disseminated through other channels. Version numbers are authoritative; the latest Kethane release was versioned 0.8.1 because I said so. Whether 0.8.1 is compatible with 0.22 or 0.21 or 0.23 is not something I can just will; the answer may be very difficult to determine. It's not particularly useful to publish which version of KSP a mod was built for because that's not a good gauge of compatibility, and you can usually just look at the release date. In summary: This stuff does not belong in version numbers. There are reasons to standardize version numbers, but those are to facilitate computers answering the questions outlined in the previous paragraph, not answering questions for humans like "what kind of mod is this?" That's what names and descriptions are for.

Kerbal scientists are in disagreement about what Kethane is, with some insisting it's a simple hydrokarbon and others claiming it's an oxidizing element. This is why the converters can make both.

Those icons look great. I think it's worth looking into loading icons without requiring them to be in the ARP folder. Suppose I wanted to distribute icons with Kethane: I'd have to include the ARP folder in my download, and this could confuse users who don't have it installed. You could use config nodes to allow modders to configure ARP for their resources, including a path to an icon. For now, it obviously works fine if you just define as many mod resources as you can think of from your end, but ultimately that configuration power should probably rest with the mod authors.

If you do release with a 000 name, consider adding a KSP version check so the plugin deactivates itself after KSP 0.22. This way, you can reevaluate your decision after KSP 0.23, and most people update mods after a major game release anyway. Not that I know of. How would that work, anyway? If a dependency isn't available, a plugin might try to execute code that doesn't exist.

Nicely done! Congratulations on a good release. Staging seems auxiliary to resources, so I'm not sure why it's in the resources view. It looks like a good feature to have, but it might belong in a separate mod. If you're not sure how to support extra resource icons, it never hurts to ask. Modders who add a lot of custom resources probably have some valuable input on the matter. Have you considered some kind of "alert" feature? It might be useful if the window expanded itself when running low on a resource, for example.

It's worth noting that Mu has fixed the assembly loader for KSP 0.23 so alphanumeric ordering will no longer be needed for dependencies.

Just want to clear up a few points: The new resource generator system added in Kethane 0.8 allows for this sort of behavior. Generator classes have full control over how resources are generated, distributed, manipulated and saved. You could achieve this by marking every cell (or most cells) as containing the resource, but change the reported quantity to reflect density. Since the reported quantity doesn't have to agree with the results of drilling, you could have an infinite resource while still rendering a surface distribution. The distribution would still be discretized by the grid, but I'll be adding a scalar field view as well. I have no problems with Fractal_UK building his own resource system. That said, Kethane's system is quite flexible, and much of that flexibility hasn't been tapped by any mod, Kethane included. I'm also happy to support other mods by expanding the API where it's needed.

Cells are about 22km across on Kerbin.

Indeed. Most Kethane code is either so simple commenting would be redundant (and even harmful) or so complex that no amount of commenting would make the code comprehensible. The geodesic grid falls into the latter category. Some of the grid algorithms actually can't be documented (yet) because I derived them empirically. I'll have to reverse-engineer my own work in order to properly document it. Normally this happens because code is undocumented and the original thought process has since been forgotten, but in this case, I never had an understanding of why these algorithms work. I had planned to develop the new grid code more formally before deploying it, but the raycast performance issue presented a need. Pro tip: don't professionally develop software this way unless you're in some kind of breakneck startup environment.

Measuring software productivity by lines of code is like measuring progress on an airplane by how much it weighs.  Bill Gates Keeping the above in mind, you may find the following table interesting: [table] [tr][td]Name[/td][td]Version[/td][td]Files[/td][td]Lines (Code)[/td][td]Lines (Comment)[/td][/tr] [tr][td]MechJeb2[/td][td]2.1[/td][td]68[/td][td]56522[/td][td]23041[/td][/tr] [tr][td]Lazor System[/td][td]31[/td][td]49[/td][td]14471[/td][td]3146[/td][/tr] [tr][td]Kerbal Multi Player (KMP)[/td][td]0.1.3.1[/td][td]26[/td][td]9551[/td][td]1040[/td][/tr] [tr][td]Kerbal Attachment System (KAS)[/td][td]0.4.4[/td][td]24[/td][td]8254[/td][td]307[/td][/tr] [tr][td]KSP Interstellar[/td][td]0.8[/td][td]46[/td][td]7116[/td][td]288[/td][/tr] [tr][td]kOS[/td][td]0.9.2[/td][td]51[/td][td]6565[/td][td]803[/td][/tr] [tr][td]Ferram Aerospace Research (FAR)[/td][td]0.11[/td][td]14[/td][td]6480[/td][td]1106[/td][/tr] [tr][td]RemoteTech2[/td][td]1.2.6[/td][td]50[/td][td]6019[/td][td]143[/td][/tr] [tr][td]Kethane[/td][td]0.8.1[/td][td]34[/td][td]3810[/td][td]41[/td][/tr] [tr][td]Extraplanetary Launchpads[/td][td]3.4[/td][td]4[/td][td]821[/td][td]95[/td][/tr] [/table] Line counts were computed with the cloc v1.58 utility. Only counts for C# code were used. The mods listed were arbitrarily selected.

This is the most likely upgrade the scanning system will see first. I'm not a fan of the cone scanning concepts which would reveal large swaths of cells in a single cycle.

This is a bug in the KSP fuel routing system. I'd love for Kethane converters to be used mid-flight, but that will require a TacLib-style reimplementation of the resource request routines.

I'm glad to see you in the primary maintenance role. You've done good work with EL so far. Would you write a bit about your general goals for EL development? Where do you see the mod in the near and far future?

Okay, fixed the Clouds/Kethane conflict on my end. It'll be in the next patch.

Does the grid appear correctly if you make the radius something ridiculously large, like 1.5? It looks like the grid and cloud shaders could be interfering, but the grid shader should work fine if it's "outside" the cloud layer.

It was just for a night, but it was worth it.

Scanners actually have to be on the active vessel.

You can edit the GameData/Kethane/Grid.cfg file. The values are radius multipliers. You can reload the file by switching to the space center and then back to the tracking station (or flight) view.

I have stated I'll be happy to support KMP as soon as it has a proper API for mods. Simple seed synchronization should be doable entirely from KMP's side by keeping the KethaneData ScenarioModule intact.

This code has seen some interest and controversy, and I've been granting license exceptions for its use, so I thought I'd just release it. There's no magic here, but it's a handy tool for working with animations. The following is released under a CC0 Public Domain Dedication: public static AnimationState[] SetUpAnimation(string animationName, Part part) { var states = new List<AnimationState>(); foreach (var animation in part.FindModelAnimators(animationName)) { var animationState = animation[animationName]; animationState.speed = 0; animationState.enabled = true; animationState.wrapMode = WrapMode.ClampForever; animation.Blend(animationName); states.Add(animationState); } return states.ToArray(); }

We discussed using a method exactly like this in #kspmodders a couple months back. I wrote a plugin that looks similar to yours, even. At the time, we determined this wasn't practical because most or all textures in GameDatabase are marked unreadable, and Compress() calls simply output an error. Is the GetPixel() call before Compress() solving that problem? That's a nifty little hack. Have you considered checking texture sizes before and after the compress operations so you can output a hard number on how much memory is saved? Anecdotal reports are often way, way off. (I've had complaints that a Kethane update increased memory consumption by 100MB when thorough analysis shows the plugin only using maybe 100 kilobytes more. A lot of numbers will be inflated by wishful thinking.)

See: If you have to page virtual memory to disk, you'll take a large performance hit. If you only have 4GB physical RAM, KSP plus other processes can easily blow through that and the game starts living in your page file.

It sounds like you're swapping to disk a lot. More system RAM would help in that case. If you already have 8GB or more, something else is going on.