`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.

I've just installed KSPRC, and while in some cases everything is copacetic, I get very peculiar frame rate stuttering when I'm "in flight", i.e. controlling any vessel. Doing some digging, I found this only happens when I have Kopernicus active (I 'deactivate' it by simply removing the Kopernicus directory from GameData). The performance difference is extreme to say the least, and here are some screenshots to prove it. With Kopernicus, frame rates look like a square wave, though the screenshots don't quite do it justice, as the game essentially completely locks up in the 'valley' of the wave for ~100-200ms or so, resulting in a frame rate of ~30 FPS, at least as reported by KSP, though with how extreme the stutter is it feels much worse: Without Kopernicus (but still every other part of KSPRC), it easily renders at the refresh rate of my 60 Hz monitor, and is simply limited by Vsync: Any idea what might be going on? The log shows nothing of note in either case, and I have a hard time believing it's normal for Kopernicus with the KSPRC configs alone to be doing this. I am using 64K, so I wonder if there is some incompatibility with that? I'm going to try with some other mod combinations, but any guidance on troubleshooting is appreciated.

I posted a patch as well about 4 posts ago, but your looks good too, though I'm not sure why you're adjusting the RT antennas as well. However, I think you're better off setting the ranges for stock, and then creating a separate patch if people are also using the OPM. This way they aren't over powered if people are only playing stock and not using the OPM.

Alright, after much tweaking and bit of testing, I've finally got a patch for RemoteTech for the new antennas, using Rodger's patch as a starting point and making a few changes where I felt they were appropriate for balance and aesthetic reasons. You can get it on pastebin here. Feedback is welcome and encouraged.

Thanks! I've been poring over the numbers, and I think I'm going to make a few adjustments to what you came up with. I hope to have it out within a day or two, and I'll post it in this thread as soon as it's done.

I'll write the MM patches, but I'd like to solicit what others think the stats should be. I'd like them to be different from the other RT antennas, but still be balanced. Please let me know what "holes" reside in the stock RT antenna suite, as I'm only getting back into the game now after > 1 year of not playing, and only just starting with RemoteTech again.

Yeah, that's exactly what I'm already doing. Alright, thanks, I won't worry about this until a fix comes along at a higher level.

I've been thinking about that actually, and it should be relatively easy to make it a generic resource converter. However, this presents another potential problem, as with generic converters, you often want several outputs. Take for example the common case of converting ore to liquid fuel and oxidizer, and maintaining the 0.9/1.1 fuel ratio. While this can be done right now with some trivial modification to the code, which amounts to basically swapping anywhere it uses ElectricCharge to instead using LiquidFuel, and then setting up the appropriate configuration for Oxidizer in the part configuration as a byproduct, this has some potential pitfalls. What if the user has plenty of liquid fuel, but is nil on Oxidizer? Then the converter won't trigger. So I've thought of two potential ways around this. The crude way is to just have a single 'mode' that checks both resources and if either condition is satisfied, performs the conversion (e.g. in the case of Ore -> LF + OX, with full LF and no OX, it would perform the conversion and the LF converted would just disappear). But this is again wasteful, so I'm thinking of instead allowing for multiple modes to be active simultaneously, but that trigger independently (i.e. it checks all potential conversions, and runs those that are needed). This is certainly a bit more complex, because for balance reasons one might want a single mode being active to convert faster than if two different modes were active simultaneously, or maybe only have a byproduct when a specific set of modes are not performed at the same time. However, I've never been one to shy away from necessary complexity, so yes I'm planning on implementing it. I still have to hash out the final details, so I can't tell you for sure what will be possible yet. Sorry for the long winded answer, but here's a... tl;dr version: Yes. It will be in the next release that's anything more than just supporting a newer version of KSP. EDIT: Here's an example of what a new config might look like, if you have any feedback, speak now or forever hold your peace. EDIT2: Just to clarify the previous example, a preempting conversion will only preempt for the portion of the duty cycle it requires. E.g., if you can convert 0.5 units of MonoPropellant per second, but only require half of that, the other half of the duty cycle could be spent producing LiquidFuel/Oxidizer.

Yes, they are. So, I take it that it's something I can't fix, and need to be resolved upstream in Unity or KSP?

Sorry, I wasn't trying to blame EVE, I know it's not their fault. It'd be nice to have a warning though for anyone else in the main post (I found out by accident when looking at scatterer).

First of all, thank you for maintaining this mod. However, using the stock stuff (EVE & your configs), KSP does not even start, it crashes before I even see the load screen. Full log after KSP has crashed. I hope a screenshot isn't necessary in this case... Edit: This happens even without the configs, just EVE installed. Edit2: Seems to be an incompatibility with forcing DX11, which I still had in my shortcut to save RAM on the 32-bit 1.0.x installs. It works fine when you don't force DX11.