DefiantZombie

Sincere apologies for not responding. Apparently the forums no longer care to send me notifications. All of my mods receive active maintenance and are generally fixed up to work with the latest version within a couple days. If a release is not specifically marked for the KSP version, it's safe to assume it works. I do not waste anyone's time by releasing unmodified files with a simple name change. No. I no longer participate in the forums (beyond replying to the remaining threads). Please do not ping me again for this.

I do not want them there.

I have no intention at this time to put any of my mods on CKAN and I am not accepting pull requests for such.

Collide-o-Scope was developed for KSP 1.3+ I will NOT be backporting any of my mods, ever.

Statements like this are why I will be switching to All Rights Reserved for all future licensing. Not contacting the mod authors to get info on whether the mod is abandoned before you take it upon yourself to distribute/patch/fork causes many problems down the road for mod authors that have not abandoned their work. I don't intend to direct my comment at you specifically, but this is an issue that is starting to creep into the KSP culture more and more. It's not the right path for modding to take.

Putting words in someones mouth is not a kind thing to do. Please don't speak for me. I apologize for leaving y'all in the dark for so long. I removed public support for reasons I shall keep to myself. Those reasons have since been resolved and I do intend on getting the mods back to the public space. However my current schedule is not allowing the time to get this work done. If Curse hadn't bugged out and deleted the projects, I could unarchive the files and it would be good. Unfortunately... Curse is Curse and seemed to delete the projects and the messages I left there to let everyone know what's up. I promise I will get these back in your hands as soon as time allows.

Thanks for showing me where the attitude of the forum community is at. I should've never posted in a public space. Lesson learned. The court cases cited in that article give a clear picture. I'm already exhausted from having this discussion in several other places over the years. Feel free to disregard everything I've said. This will be my last post about this issue anyway. Yes, limiting legal risk is the responsibility of the user. I never stated anything about removing risk. I stated it was allowed (i.e. by the court cases I've read verbatim). As much flak as I've given Squad over the years, I stand with whatever statement they make. Even if it's a copy/pasta requirement from the publisher. IMHO the EULA gives us everything we need to know. I had hoped that by posting information based on research (not doing the research for others) that it would help slow the parrot effect. Apparently I was wrong. Not making that mistake again. Apologies for coming off rough to you. I have no good excuse (no excuses are good). My understanding of the BnetD case is that they circumvented protections in Blizzard's software. The "click-through" statement is 50/50 based on what court case you read. There are others that say it is not enforceable. As far as I can tell copyright of mod authors is not at risk. Licensing of mods to the end user is not at risk. Modding of KSP is not at risk. If mod authors are concerned with the UGC clause as it is worded, then they need to read it and understand what the words mean, not pick and choose sections that feature legalese (all the words matter). I believe it is completely possible to release mods for KSP that avoid the UGC clause. A/V content creators have more to think about. What mod makers need to be worried about is being too loud. A poor community response will result in a Bethesda style change to the EULA. Feel free to DM me about this, but I stand with Squad and the EULA. It's both clear and vague enough to cover mod makers.

https://www.eff.org/issues/coders/reverse-engineering-faq

Please do your research on Copyright and DMCA before stating false information. Reverse engineering is legal if the intent is to create inter-operable software and/or hardware. https://www.eff.org/issues/coders/reverse-engineering-faq

A couple observations that came up in parallel with my research. This is covered under US law. (unsure of other locations) Archival copies are allowed so long as they are not distributed/sold/etc. Reverse engineering is covered under Copyright and DMCA. It is allowed with the intent to create inter-operable code and/or hardware. However, distribution of copyrighted code is where you run into issues. The block you quoted states "the Online services" which does not apply to the KSP software as there is no online service component (yet). As far as licensing for mods, from my research on this topic all mod licensing is still valid as far as the mod end user is concerned. What the EULA does in this case is grant Take 2 an automatic unlimited license.

I don't understand why people are missing the main clause that is different/new that may directly apply to the KSP mod community. I haven't completed my research on this statement. It appears to be "standard" and directly states that "The Software may allow you to create content...gameplay map, scenario..." That's the bit I'm still looking into. KSP does not directly allow us to create certain mod content. However if this is to be interpreted to include the act of loading and facilitating the execution of mod content, then mod authors are releasing their copyright to Take 2. I'm hesitant to post anywhere publicly about this, but the short notice on this has made other avenues hard to pursue. I'm involved in projects that require my knowledge of how this is clause may be applied, and would very much like clarification from Squad and Take 2 on how this clause will affect my copyright and the license(s) I have been granted access. EDIT: Redacted. Further research invalidates my statement and turns it into a licensing, not copyright, issue.

I can't speak for other mods. What the resource conversion limiter does is run the equipment (ore processor or fuel cell) until the converted resource (fuel or EC) reaches the % that you set. So if you want to maintain 50% EC at all times, set the fuel cells to 0.5. The fuel cells will turn on when EC drops below the limit and turn off when it reaches or exceeds. This gives you power through the night while allowing solars to do their job and not waste your fuel during the day.

Hey! I apologize for not responding to this sooner. All this mod does is expose a hidden value on the fuel cells. Kamuchi did a great job (where I failed) to explain what this does: If you've ever done ore processing with the stock parts, it's the same feature that the processors have.

@linuxgurugamer I'm a bit confused now. Nothing in my mod is looking at RCS thrust transforms (there isn't one in the stock config files). Unfortunately because of the scope I've placed on my mods 'Should Be Stock' I will be unable to implement a bug fix on my end. If you're using a PartModule designed for engines and not RCS, I suggest rotating whatever transform you're adding so that the stock code operates as intended.

Oh! I was not aware of this. I'm submitting an issue and will get the mod fixed in the next week (life stuff permitting)

What @Skalou said is correct. It looks like you're building the part from scratch in code and have misaligned the thrust transform. @linuxgurugamer If you cheat the craft to orbit, how does it react when you fire the engine/rcs?

I don't recall this being a bug. It's entirely possible I missed it. Thank you for reporting, building out a patch now. Will have it up shortly.

I apologize for not responding to this post sooner. Red is drag, blue is surface lift, cyan is body lift (in combined mode those become purple and one arrow), magenta is thrust. The yellow sphere is center of mass, and the green is the root part. I will create a support issue to have this added to the readme with the next point release. Edit: Note that the next point release of Collide-o-Scope will be removing the flight markers. Those will be released under a separate mod.

Edit: Redacted. I dumbed and didn't read properly. Apologies.

Please do. I'd like to see it.

Yep. The lines that Collide-o-Scope draws are not rendered objects that are susceptible to the clipping plane bug in KSP. They are transformed and drawn in 2D over the main camera.

Thank you very much for the kind words. That is indeed a bug. It was something discovered early in development. Unfortunately I'm not a graphics programmer, and it's a bug with the line renderer code I'm using that someone else wrote. I'm hoping to have a completely new method of rendering with the next major version of Collide-o-Scope. It should be compatible with any modded parts. Be aware that the wheel colliders in Collide-o-Scope are 100% not working correctly. The code was very quickly slapped together at the last minute and is something I plan to address with the next major version of Collide-o-Scope.

1 step forward 3 steps back. So much for not using hacks to get UI hooked up in this release.

The red is a sphere collider. Sarbian's mod will show you the exact same display. My code is based on theirs as it wasn't updated to 1.2pre at the time I built this mod. All it's doing is showing you what Squad has added to the parts. You'd have to ask them why there are random spheres all over the places, but not in all places. From my experience, the sphere colliders are generally not physics colliders. They are for raycasting. Same as all the extra non-colliders on ladders and pods. And no, I will not be filtering them out. They have come in handy to know about on more than one occasion. Edit: Also, don't trust the pink wheel colliders. They are extremely bugged. It's something I plan to address (hopefully) in the rewrite.

My Windows install of Unity 5.4.0p4 is not importing the assets properly. It seems like KSPAssetCompiler and KSPAssets are not loading. I did a fresh install of Unity 5.4.0p4 on my OS X machine with the same result. No asset compiler.