blu3wolf

Its not a bad idea. I dont think it will prevent modders from getting annoyed at idiotic bug reports, mind, but its not a bad idea.

If its a CKAN issue, then sure. Still irrelevant though. Joe User already disregards clear instructions on where to make posts for support. Doing support via a single forum thread... Seems like this is based on poor choice of medium by mod authors for support, really.

Thats not the impression Ive gathered today. I dont think the impression matters, though. Plenty of modders have already tried to segregate CKAN and non CKAN install issues by thread, with varying and limited success. The suggestion I made further up was an attempt at fixing this issue at the stem; make the default CKAN install an opt in, stable release only setup, as modders have requested elsewhere at length. Add two other official repositories, one for official experimental releases by mod authors, and one for absolutely anything, with no support by the mod authors - so basically what we have now. Users would have to manually add experimental or unsupported repos to their mod list, and could have them visually differentiated within that list - perhaps unsupported ones being highlighted a cautionary orange, or a pale red glow. Still not a perfect system, but one that would at least make it significantly harder for the average user to screw up.

As my reply was to a comment about legality, legal 'nitpicking' is relevant.

As above, CKAN does not actually distribute mod files. It merely tells the end users computer from where your mod can already be downloaded. If you were to prohibit the use of computers to download your mod, you might have some difficulty in distributing it IAW your license. Its no different to having a text file on your hard drive with a list of your preferred mods on it, and making sure to install those mods whenever KSP updates. Other than efficiency, anyway.

No, I think FOSS licenses would be better. But we have already established that modders dislike such licenses, because they dislike blanket permissions. A FOSS license that has the caveat you may not use it in a certain way, is neither free nor open.

If the license permitted it, its not particularly an issue... I suspect I would have stopped using them as I disagree with adware on principle, but its not like they did something wrong - legally. If you want to control distribution of your work, thats fine, and there is nothing wrong with that. You just need to say so - and not release your work under a permissive license, if you do not want to grant blanket permissions.

Im still a fan of the option presented above, where you would have the option to opt out of any repo other than Unsupported.

Then I would humbly suggest, that open source licenses are not for you. I would also point out that a number of users do not have the time to set up an install of several hundred mods when those mods are sourced from a thread, or from Curse (aptly named)... but from CKAN, it suddenly becomes viable without spending days curating the install. For a subset of users, your mods not being on CKAN is equivalent to your mods not being available. Also, after you went to the trouble of having your mods removed from CKAN, I might point out that several are still floating around. The Community Resource Pack, and the Alcubierre Warp Drive, are both still present - as are deprecated versions of Asteroid Day, FirespitterCore, ORS Fork, Regolith, Sounding Rockets, and USI Tools.

No, it wouldnt. Both the outcomes you propose are identical - not using your mods, or you not promulgating your mods. That isnt a solution, not so far as the user is concerned. If its a solution for you, then you should do whatever you feel you need to, for your health and peace of mind. If that was a serious thought on your part, echoed by all mod authors, all that would happen is a majority of users would stick to 1.1.2, much as there was a large portion of users with 1.0.5 and previous versions.

To be honest, I feel like that is a mistake on their part. They should not discriminate between ARR and FOSS licensed works, WRT delisting mods. They should simply not delist mods at all. This would work best with various CKAN repositories, though. The present single source one is just not maintainable. Using a set of Stable, Experimental, and Unsupported repos would be the ideal fix for this. Rename the current CKAN repo Unsupported, then let modders opt in to the Experimental repo. Their metadata gets moved there, and removed from the Experimental repo. Give it a week or a month or whatever, and the metadata gets then moved to the Stable repo. Set the CKAN client to be able to display mods from multiple repos at once, and by default only show mods from the Stable repo. Users who want to use Unsupported mods still can, and its immediately clear to them that they should expect no support with them.

Well no, it isnt something completely beyond their control. They have as much control over it as anyone does, something RD has been demonstrating with mixed success. Its not so much about copying files. Up to now, Ive been manually installing USI stuff and FAR, just so I can get support if I need it. Its more the chain of malice. Mod authors get more users than they want, because maintaining a modded install is a lot of work (time spent not playing KSP). They then figure that is the fault of the software letting users use their mods. Compounded in cases where CKAN metadata has been messed up, making those new users vocal about what they see as the mod not working. On the Trainz forums, they complain about gimme pigs. Here, its CKAN users. I really think the best solution here is a set of CKAN repositories, being Stable, Experimental, and Unsupported. Saying that CKAN should delist mods entirely is a little like saying RD should delete all his mods.

Nothing preventing them from doing so. The vocal minority so far seem frustrated at users, not CKAN. Its just CKANs fault that it happens to work as well as it does.

Well, that is exactly what you should do, if you dislike the implications of a specific license. If you released an older mod under a GPL license, you made specific guarantees to the users of that product, about their rights to use, distribute and modify that work. Its possible I am misremembering, and that you did not in fact release those mods under a GPL license. Im sure the threat implicit is that woe betide the community if you move your mods to ARR, but its not much threat tbh... and if you wanted greater control over the distribution of your mods, its something you should do. ARR on its own is not something that legally deters users from using your mods, but it does at least make it a little harder to ensure its survival. Of course, you have already made it clear that you have no interest in your mods survival, and that the point of releasing it is to ensure you get public bugtesting for your work. If that is the case, I have no idea why it wasnt ARR from the start.

The deprecated mods in question though, were if I recall correctly, released under a license where you made a guarantee to the users that you would not interfere with the distribution of them. Why shouldn't a mod index include old mods for those users who want to use them?

Seems like a lot of this could be solved if maintaining specific NetKAN entries was the responsibility of a dedicated Maintainer position, perhaps the mod author, a nominated third party or a member of the CKAN contributors/staff. With one person in charge of a specific file, there is a clear place that the buck stops in case of stuff ups. That means its slower to update than the current all open method. Possibly that could be combined with having a second main index, one for stable and one for experimental/recent updates. The maintainer could put updates to the experimental source, then say a week later move issue free ones to the stable source. That way would still be a little slower than present, but more than justified, I think - and it largely addresses RD's qualms over 'random guy off the internet' messing with his entries. It would also be a step closer to the process that apt uses without these kind of acrimonious discussions.

It is added by KSPRC, but I too would like to know if it is intentional.

But thats half the problem! It starts out with lots of holes.. and gradually gets less holes!

One would imagine such a dish in orbit IRL would run into issues from micrometeorites.

I thought the point of SIGINT is to listen, not to transmit... in which case, the receiver does not need much power at all.

Val feels so useful right now haha! Presently on the way back from the Mun... used every last bit of propellant on board to get a periapsis in atmosphere, too. Plenty of science gear already there for the next mission, saving mass! Of course that only works if I go back to the same spot, which would preclude getting science from other biomes. Guess that was just a waste of funds At least we got plenty of non SEP science on the mission!

yes.

Well for me, the difference between the styles is that with the default style, I cant get the new document button to show buttons XD

Just hauled my first SEP assemblage out to the Mun... only to discover that Val cannot equip the tools necessary for assembly! Curses! Guess Im just gonna be leaving the stuff strewn across the munar landscape... cant bring it back home, the ascent vehicle wasnt designed with that in mind!

Im not using reflection at all.