`Orum

I should have clarified. This would still be 'one' plugin, that can still function exactly as it does now (i.e. a fuel cell) if that's all you want. I merely added additional options if you want to use it as a general purpose converter, which is all controlled by the part config files. Don't stop on my account. I just need to get the habit of committing what I have done regularly, and if I plan on making big changes, making sure I have the time to finish them before I start. Right now I'm stretched thin, as I work at a school and classes are resuming, so I don't think I'll get code to you until later this month at the soonest. Heh, I'll definitely take a look, but I don't always write the most intelligible code. I have an especially bad habit of naming variables very short, cryptic names, but I'm working on getting better. I'm certainly a lot better at commenting things than I used to be. Definitely. I want to get ODFC updated first and then I'll look at some of the other stuff I was working on. It's somewhat of a collection of random things (hovercraft, iris doors, tractor beams) so I'm not sure whether to ball it all up or release each thing separately. Either way, they all needed work back when I stopped working on them a few years back, and KSP has gone through a lot of updates since then. Ultimately it all comes down to how much time I have available.

The fault is entirely mine. In the ~18 or so years I've written and released OSS, this is literally the first time someone other than me has done something with my code (to my knowledge, anyway). I should have uploaded my changes to GitHub, I just never got in the habit as I've never gotten code/patches from anyone else. You're entirely within your rights. To be honest, I don't play KSP much any more, as real-life obligations keep getting in the way. I'd like to turn things over to you, assuming you're willing, but I'd also like to get these last few changes into the plugin before I completely check out. Well, actually there are a couple other things I have almost complete for KSP, but I don't know if I'll ever get time to finish them. So my thoughts are, I'll use your code base, and port the features I wrote over to work with whatever you've done. You can then approve (or deny!) the pull request, and take over from then out. If I get the time to work on KSP mods in the future, I'll just submit them to your project if they're ODFC related, or at some point finish the other few things I was working on. Hopefully one day I'll get around to releasing some new parts, like the iris doors you can see in my forum avatar (in a separate pack, of course), along with some other surprises.

Sorry, I actually updated this back in June/July, but never got around to testing it to verify that all of the new features worked. In any case, it looks like zer0Kerbal has taken over, though I don't think that his is anything more than patches to make the old one work with newer versions of KSP. Let me know if I'm wrong. If the community is interested in the other features, I'll try and describe them as best I can. Basically it has become a more general purpose on-demand converter, which can convert from anything to anything (not just electricity). As part of this it can now both consume and output several things simultaneously, and not just as byproducts, but as limiters to the conversion. If you guys are interested, let me know and I'll go through the hassle of updating it again (as it seems at least one version of KSP was released between when I last worked on it and now) and testing. If not, and you'd rather have zer0Kerbal's version, don't worry. I won't be offended .

This doesn't seem to be working in 1.6.1 for me. When trying to open the UI to configure the wing (which I assume is done with the "Show wing data" button), I get an exception: [EXC 17:42:27.255] NullReferenceException: Object reference not set to an instance of an object WingProcedural.WingProcedural.InfoToggleEvent () BaseEvent.Invoke () UIPartActionButton.OnClick () UnityEngine.Events.InvokableCall.Invoke () UnityEngine.Events.UnityEvent.Invoke () UnityEngine.UI.Button.Press () UnityEngine.UI.Button.OnPointerClick (UnityEngine.EventSystems.PointerEventData eventData) UnityEngine.EventSystems.ExecuteEvents.Execute (IPointerClickHandler handler, UnityEngine.EventSystems.BaseEventData eventData) UnityEngine.EventSystems.ExecuteEvents.Execute[IPointerClickHandler] (UnityEngine.GameObject target, UnityEngine.EventSystems.BaseEventData eventData, UnityEngine.EventSystems.EventFunction`1 functor) UnityEngine.EventSystems.EventSystem:Update() Any ideas? Edit: Nevermind, the UI was there it was just hiding, camouflaged in the corner. The wing can be tweaked, but the "show wing data" button is still broken.

Does anyone have the "Auto-deploy Antennas" working for ascent guidance? I'm not sure if it's because I have RemoteTech installed, but it doesn't seem to deploy them even though solar panels are auto-deployed. Here's the log.

Documentation is included in the zip file, it's HTML based and should work in any modern browser. If you're looking for examples, look at the parts I've made that use this mod; just keep in mind that they're under a different license from this plugin.

Hello pot, my name is kettle... In all seriousness, ad homonym gets us nowhere. It's naive to think that a policy change compromise from CKAN, while welcome, would do anything to prevent this from happening again in the future. Tomorrow Curse could come out with a download manager that does far more insidious things than CKAN, and if developers don't arm themselves with the licenses to remedy such situations, it will happen all over again. I get this, but there are pretty powerful things you can do with licenses that actually do remedy the situation. See the CFAA and US v Swartz for an idea of the power that downloading restrictions can have, even if the case was ultimately dropped.

Then write a license that says that. You can (and is often the case with proprietary software) put more, or less, restrictions on software than even ARR provides. It's the very way software companies get around the first sale doctrine which would otherwise allow people to resell their products.

Yes and no, there are legal complexities that are involved with ARR that could prevent CKAN from listing (particularly if you look at the US's DMCA), but if you're really that protective of your content, you probably wouldn't be releasing it to the public at all.

No, law is amoral, it says nothing about what you should or shouldn't do. The point of a license is to express your intent, and if your license fails to enforce what you "want" people to do, then perhaps you should have picked a different license or written your own. One cannot simply expect CKAN to know that you do or do not want your mod listed, so simply spell it out in black and white and this entire issue could have been avoided. It's not about understanding the words, or being nice/mean, you as a developer should assume anyone can and will do whatever they are permitted to by your license, and should write or choose a license accordingly. To release something that allows said rights, and then get upset when people exercise those rights is hypocrisy.

Thanks for the update, and that sounds like a reasonable fix, even if the info tabs aren't 100% accurate. Also, thanks to your tip, I found out how to fix my issue with KSP locking up whenever I opened the "big" altimetry map of Laythe. The defaultMinHeightRange / defaultMaxHeightRange values (with ridiculously high exponents) were saved in the game save file, so it wasn't even trying to load them from the SCANcolors.cfg. Thus, when it tried to load the map, and generate the legend, it would try to put so much text down on the legend that it would instantly lock up KSP. So, I had to dig through the massive save file to find those for Laythe, set them to sane values, go back into the game, and do the final adjustment and everything works now. Just wanted to let other people know in case they were having problems.

I've been using this (v16.1) in my career game for a while now, and everything was going fine except for one little hiccup due to Sigma Dimensions. However, I finally got to Laythe, and fully scanned it with all three scanners, which showed up just fine in the little map. However, now, when I try to open the map of Laythe in the big map, the game instantly locks up. No more frames render at all, and the only thing that's left to do is kill the KSP process. I looked in the logs, and didn't see anything suspicious. As the entire log file is > 3.5 MB, I grepped out anything with the word 'scan', and you can see it here. Also, here's the tail of the log just before I tried to open the big map, after which it abruptly ends as the game has to be killed. As I was still suspicious of problems relating to SD, I opened the SCANcolors.cfg, and found that Laythe had minHeightRange = -5.40432E+10 and maxHeightRange = 1.080864E+11. I changed these in a text editor to more sane values (-100 and 2000), thinking that was the issue, but it still just freezes when I try to open the map of Laythe. Any ideas?

That's what I've been doing, just it's quite tedious when you have to restart KSP a lot. I was thinking more about it, and I think it should be possible to just scale the range of the scanning parts themselves, without affecting the color configuration variables. I'd have to look at the code to be sure, so I'll poke around in it this weekend when I have a chance. Worst case scenario, you could do it with a MM patch instead, and that does not affect those variables.

I've have some annoying behavior recently in my heavily modded install, and I think I've finally traced it back to Sigma Dimensions. I'm using 64K and SCANsat, and I noticed when trying to adjust the colors on the SCANsat maps, the sliders for min/max altitude had insanely large values (e.g. gigameters for max altitude), which made setting the actual limits I wanted on the maps impossible, short of editing the SCANcolors.cfg file. However, when looking at the first post in this thread, I noticed you have a scanAltitude setting, so I opened up 64K's config, and set that to 0.15625 (i.e. the inverse of 6.4), and manually set defaultMin/MaxHeightRange and rangeAboveMin/MaxHeight back to sane values in SCANcolors.cfg. Now, these values would keep their setting, but this created another problem; now the scanners themselves would only work from a very low altitude. I played around a little more, and I now know exactly how to reproduce the issue when using SD and SCANsat (and some scaling config like 64K). This assumes you are leaving scanAltitude at 1 to allow scanners to scan from appropriate altitudes: Make note of the defaultMinHeightRange, defaultMaxHeightRange, rangeBelowMinHeight, and rangeAboveMaxHeight in SCANcolors.cfg. Start KSP. Open up SCANsat's big map, and go into the configuration screen, and then the colors config. Change any settings you want to, and then save them to config. Now if you look at SCANcolors.cfg, those 4 values will be scaled by whatever your universe is scaled by (e.g. 6.4 if using 64K) You can now change any other settings in SCANsat and save them, and and long as you don't close KSP, it those values won't be scaled any more. Restart KSP, and reopen SCANsat and its color config. Now if you change any settings again and save, those 4 values will again be scaled by your Resize value (so they are now the initial value * 6.42). As you can see, they will just keep growing, where they'll have a value of: Vc = Vi * Rx, where Vc = current value, Vi = initial value, R = resize value, and x = number of times you have initially saved a SCANsat color config after each KSP start. This grows into those gigantic values pretty quickly, and as I said, while using the inverse of your resize value for scanAltitude fixes that behavior, it will cripple your scanners if you still have more bodies to scan. I haven't yet tested with your latest prerelease, but I just wanted to make you aware of this ASAP. Other than that, thanks for the excellent mod!

Don't worry, I've played without Kopernicus for a long time, so I'm okay playing without it for a while longer. Thanks for looking into it though, and I'm going to continue poking around myself to see if I can figure out the root cause.