phoenix_ca

Why not? If you can make simple template files to start from, a user could do whatever they want with them. Even if you just have a standard format you tend to use for a typical note you want to create, like logs, templates could help. (Calling them templates is a bit silly since I'm really just suggesting essentially a copy/paste into a new note, but for lack of a better word...)

I was thinking along the lines of templates for mission details, mission steps, parameters, rendezvous parameters, that sort of thing. Ideally it'd just follow a similar style to how snippets work in text editors like Atom. Not the format but the idea; let the user make their own and just look for those. Could simply be a folder called "templates" inside the mod's GameData directory, holding text files which when in the root directory are single-file templates, but if put in a sub-folder serve as a group template (treat the folder as a single template and let the user generate an entire folder in the mod using all the text files and directory structure of it and bam, piles of saved time). Just a thought. (I'm not overly-invested in the idea. Maybe I should just get my ass in gear this year and learn C# so I can make an in-game mission planner myself. )

Sorry. As I stated in my OP, I explicitly waived that privilege. If moderators here want to do such a temp lock, that's for them to decide. I won't request it. Edit: I will add, the response from the CKAN team has been good, as has the mod authors' to their response. Hell, even @RoverDude and I aren't slinging mud at each other on GitHub. I think cooler heads will prevail. Even if those heads were on fire a day ago. Maybe sleeping on it helped temper everyone's mood. Hell if I know.

I do see what you mean, but I still don't think anyone will be served by such enforcement. If it were strictly opt-in, then your own stance on CKAN would be invalid. No option to keep "hands-off", as it were. With all due respect, I still don't think splitting-up the KSP community like that will help. The CKAN people aren't monsters. I think @politas's extension of good will here is showing that.

So they'd just post it somewhere else. Anywhere else, and it could spread by word-of-mouth. A heavy-handed forum rule about this is probably the worst solution. If you build it, they will come. If it's good enough, people will use it. You could even end-up in a situation where everyone knows about CKAN, so they keep using it, even if it's been ejected from the forums, and then there's no where even semi-neutral to even talk about improving it. All the same problems with no hope of fixing it. I definitely disagree with you on that.

I think that might actually be the best post in both threads so far. I doubt any of us want to see a significant portion of mods all go with extremely restrictive licensing. It'd be better to aim for a bit of reformation to help CKAN be less of a burden, and hopefully seen as being useful instead.

I figured this would be the response when I said that. My point was that people are going to use the tools that save them time and effort when installing mods. This is not something easily changed, even if we just killed CKAN entirely. Someone else will make a new tool that does the same thing. Saying "Well, just don't use mods" is equivalent to me just saying to you "Well, if you don't like the time modding takes, just stop modding." It shows absolutely no respect for the concerns of others. Do you see how this gets us absolutely nowhere? Just more animosity to go around, and no realistic solutions. Part of the reason I'm so opposed to forcing strict opt-in only for everything is because there are no analogues for it in other modding communities (that I know of, and that actually work and don't get supplanted by a more open manager in short order). XCOM 2 and Cities: Skylines are centered on the Steam Workshop. Bethesda's games and a few others are de facto centered on Nexus. KSP has none of that centrality. There is no one-stop-shop where you can see most if not all mods easily. There's SpaceDock, GitHub, Curse, and probably the worst of the lot, just plain links to a download file on a forum thread, which effectively leaves the mod dead and buried unless its page keeps getting bumped in the forums. I've already publically apologized for this: In my own defense, which I omitted in the apology above, the addition was approved and merged by someone on the CKAN team. If you would spare a moment to stop brow-beating me over this: This situation showed a clear issue with CKAN workflow when it comes to contributions that can be changed for the better. I've already done my small part in trying to prevent another such error in future, by updating the guide to adding new metadata to warn about just this case and suggest that contributors instead leave that to the particular mod authors. I even used you as an example: https://github.com/KSP-CKAN/CKAN/wiki/Adding-a-mod-to-the-CKAN#before-you-start On top of that, you've got @politas here saying it won't happen again, and I'm looking-out for it too. We're all human and have to learn from our mistakes. Sorry, but things are going to go wrong, even when we have the best intentions. Fair enough, I misunderstood. I too really like this one. This is an example of where mod authors, who are already familiar with the inner workings of KSP and already have experience with plugins for it, could really help the CKAN team help them. Just because this is getting far too acrimonious, this little YouTube clip bit is totally relevant to what I just said: No problem. I'm a left-leaning libertarian. If I didn't promote more discussion and try to help people as much as I can come to some sort of reasonable accomodation, I'd be a pretty huge hypocrite.

And on the notion of "Well my time is valuable", fine. You guys realize other people's time is valuable too, right? Just take myself as an example. I work split shifts 5-6 days a week (so twelve hour days not counting time spent sitting around at work, transit, or anything else), on top of taking programming and math classes so I can apply to a tech school. If you're going to play the "my time is valuable" card, you have to extend that to users too and understand that some, perhaps a lot, of them also don't particularly like wasting their own time because they only have so much of it to go around. CKAN is at the very least, as solution to that issue and it's what shaves enough time off the entire process of mod installs that I can actually get around to playing KSP instead of testing it and then having a new update come around and have to start the process all over again. @CobaltWolf I'm not the one who brought-up the reddit link comparison. But in legal terms it's effectively similar. That's why I asked for possible solutions that would mitigate the problems mod authors are having. Ferram handed us all a pretty decent list. Though I agree with @cantab that demanding the system be entirely opt-in, especially when the CKAN team has said quite strongly they aren't interested in doing that, is having the perfect be the enemy of the good. If we could settle on improvements that would at least mitigate the main issues, that would at least be a start. It'd be nice if we could scare-up some more of the CKAN team to talk about this though.

@Kobymaru Basically this. I think this point is getting entirely missed in the discussion.

Continuation of discussion here: And to any moderators: I'm waiving my privilege to ask for this thread to be locked. This obviously needs to be hashed-out and some sort of solution reached.

I can't speak for ferram but I think he was getting at that the preferred situation would be that the mod author would, like RoverDude, have their metadata files on their own repo where they are in control of them. The repo that CKAN pulls its metadata from would then just have that stubby .netkan that tells it to get the actual file from somewhere else (the .netkan on the author's repo). Obviously that doesn't cover the case of mod authors who want their mod listed but don't want to bother with the metadata spec or other cases, which I was trying to get at in my previous posts.

Please, let's try to be civil. I'm not trying to "wilfully obstruct" anything. I'm just not seeing how this is a direct parallel. A lot of the hardware and legal issues in mod support on consoles are de facto not solvable. There's only so much you can do when the hardware is grossly inferior to mid-range PCs of today on top of the legal constraints put on everyone because of the nature of licensing on consoles. When there's no script extension, no possibility of ever having that script extension without Bethesda's intervention (which could very well be much worse than a non-trivial effort on their part), and a paltry 2Gb of space for all of their mods to fit in, and you have a recipe for disappointment for all concerned. But those huge issues aren't present here. What we seem to have here are a set of mostly policy issues, not technical ones. The technical stuff is solvable, which means we just need to get everyone on the same page, so-to-speak. No, they aren't. This isn't a KSP version of The Pirate Bay we're talking about here. No one is taking mods from their download pages and redistributing them while claiming they are their own, which is what thievery implies. The .netkan metadata files essentially serve as pointers to tell the CKAN application where the downloads are, how the mod is identified internally, and which other mods conflict or the mod is dependent on. Granted, they can be broken and cause issues, but it doesn't constitute copyright infringement. If I were to take all of RoverDude's mods and re-upload them somewhere, that would be extremely rude and definitely be redistribution and ultimately theft, sure. But what if I just wrote a small script that took a link to his mods' releases on GitHub and then downloaded the latest version and copied its contents into my KSP GameData folder? Is posting the link and the script now stealing? I would contend that it isn't, far from it, and that in principle this is much better analogue for what CKAN is doing. What it obviously needs is some polish and creation of some features that would help mod authors not get overwhelmed with users knocking-down their doors when the blame for a particular problem doesn't lie with them. Also, random idea as I think of them: The CKAN spec could probably use uninstall directives too, to ensure that mods get cleaned-up correctly. ModuleManager for example creates extra data files that CKAN doesn't wipe after uninstalling it. That's something that could be done concurrently with ferram's second point and kill two birds with one stone. (It'd require the checker to have a working KSP install and automatically run it so that plugins actually execute, but it would then be possible to flag mods that need extra clean-up.)

That's the only real corollary I see here. A huge part of the problems with the Fallout modding community right now stem from limitations of consoles, and there are a lot of those limitations to go around. The fundamental problem ends-up being the same, in that you end-up with users who are belligerent in part because they don't understand the problem. (Bethesda can't be blamed directly for a lot of the problems either. Consoles are more restrictive in what they let in than the Apple App Store. There's reams of legal agreements and understandings and licenses controlling every single microcosm of a console; I'm amazed modding happened at all.) The important thing to keep in mind is the comparison breaks-down because we aren't talking about large, seemingly monolithic corporations here. Everyone involved individually is able to be contacted individually and there aren't any legal teams in the way. It should at least be possible to hammer-out some ideas that will be an easement to the problems discussed.

Sorry for the bold text but I think it's important to make this clear: Keep in mind I'm not a CKAN team member, just someone who added and updated some metadata files. I just want to get a handle on what might be an amicable solution for everyone here so no-one gets burned (or continues to get burned...or we all get burned equally...whatever you probably get the gist of it). I'm mostly doing this because I really want to see a good outcome from this where everyone gets to have their cake. Or eat it. Can't do both. I'm getting distracted again. Most of that I would get behind. Especially the troubleshooting one; I can appreciate how that'd be extremely helpful in diagnosing issues when users bug mod authors for support. But I'm not the one who has to implement them. Strict opt-in only is where I differ. What if there was some way to differentiate which mods the author opted-into listing on CKAN and which ones didn't? That could be as simple as a single extra boolean in the schema that defaults to false (indicating a "no, and don't bother the mod author about this because it's squarely in CKAN territory if excrements explodes"). Maybe say it's verified by the mod author, or managed by the author, or something. Or different levels like Managed (e.g. what @RoverDude does), Opted-In (the author does want it listed on CKAN but doesn't provide the metadata files themselves), or Open/Contributed/Whatever for ones where the author hasn't provided any input. I am generally of the opinion that the last case probably shouldn't be the norm, but maybe if each different case was explicit instead of implied as it is now, that'd help? It might be a solution for both 1 and 4. (And it leaves open the possibility of authors passing-off the actual making of the files to someone else if they can't be bothered, which is fine.) If that data was there the application could then provide the user with clear indication of who to blame first when things go wrong with their installation. (Or at least reduce how much they pester authors about problems.) Because the thing is, authors still opt-in to mods going on CKAN via SpaceDock fairly often, and it might be useful to distinguish between the two first cases I brought up. Edit: Another random idea. If how the metadata was added (by the author, by someone else but with the author opting-in, or without direct input from the author) was included in the metadata, it'd be possible to do things like alert mod authors whenever metadata was uploaded in the latter two cases. Heck, you could probably make a case it that the bot should do this whenever it sees a new or changed .netkan. Not sure how to go about passing the right contact info to it though. Just a thought. I hope some of the CKAN team see this and chime in. If you're talking about Bethesda.net, that has a whole pile of problems with it that aren't really relatable to this particular debacle. Or I'm missing the point.

O.o No it hasn't. They're all still there. It's not about what I or anyone else "wants to hear", it's about what is a reasonable solution. A purely opt-in system is just going end-up with moving the problem back a step. Instead of a centralized repo of CKAN metadata files, there will be a mess of CKAN files distributed between users and there simply won't be a single authoritative copy unless the mod author makes one. That'll go for any mod author who doesn't opt-in. And then you're going to end-up with mod authors being angry at users for helping distribute their mods to other CKAN users, and users being angry at mod authors for being angry at them because they'll see it as just trying to help-out other users. People like me who have such large installs will probably end-up making their own repos just so they have a place to keep the atrocious amount of CKAN files they end-up with. (With the assistance of a short Python script to recreate those files on a schedule.) And then to top it all off have an angry mod author throw a spanner in the works every time one tries to update. (I know I said angry a lot but boy, are the profanity filters on the forums sensitive or what?) All I see down that path is ruin, with absolutely no one being happy. It's a matter of which is the lesser evil. But if both sides of this are beyond reason and coming to the table in good faith to create a solution that's amicable for both parties (and I'm starting to suspect this is the case), then I don't see how any progress can be made.

Well as a CKAN contributor, albeit a very recent one, I take umbrage with that. I and other users here have already posited the question to you guys, the modders, "What would help to make it better?" (Other than the snide "just install your mods manually and use AVC". We've been over that; if someone wants to use hundreds of mods, that's just untenable.) So I put it to you guys again, what features would make CKAN better for you guys? An optional extension of AVC's version files for dependency versioning maybe? Fixes to any specific problems with CKAN's behaviour? What if it's something as simple as a kindly message inside CKAN somewhere reasonable reminding people to make sure they don't confuse mod problems with CKAN problems? Or point them to the simple troubleshooting method of "try a manual install instead just in case"? I'm just throwing ideas out here. You're the ones in a position to tell what would be helpful. It goes back to what @cantab said: You're also the ones in the best position to actually get the goodwill of users on your side to affect the changes you want. I hope you guys can see that. (You'll kill that goodwill if you go waging a flame war and breaking CKAN intentionally though.)

Doing that will guarantee genuine (and justified) user backlash. Users who just want to mod their games easily and have no idea that this issue is such a hot-button topic here that mentioning it is practically guaranteed to start a flame war are just going to see it a petulant mod authors throwing a fit. It wouldn't solve anything, just breed more animosity between everyone, which is obviously something the KSP needs absolutely no more of, frankly. Again, at hundreds of mods, this becomes untenable. Manual installation and patching becomes extremely time-consuming. Frankly, I don't have the time, which is why I use and will continue to use CKAN until there's a better solution. Define "very quickly". It takes several minutes for KSP-AVC to complete its checks for me (about 6-7, and my KSP startup time is 10 mins in total). Going through that however many times a day, manually patching things and hoping that I don't slip-up somewhere (which can and has happened to me in the past, sometimes creating bugs that result in corrupt saves)? No. Then your problem isn't with the distribution platform specifically, it's with the users. I fail to see how this is any different then the problems faced by mod authors in other communities, especially Nexus and for Bethesda's games. They all have to deal with users running into problems, sometimes caused by the software they use to manage their mods, the thing is that there's a culture where people adding mods obviously "get" that doing something wrong with NMM or Mod Organizer can cause issues. Maybe CKAN is a victim of it's own efficiency and KSP's somewhat more sane addon management (and that the game, being a sandbox, doesn't result in nearly as many conflicts), because both combined makes adding mods so trivially easy. You have to keep in mind that if CKAN dies, someone will create a new distribution platform in relatively short order. Hell, I'd do it myself, and probably do it even worse since I'm far from experienced in dealing with such design problems. And then we'll all be exactly where we started, except two steps backward.

Yeah. I looked back at the history and that was actually my bad. It was my first contribution and I didn't know you were managing your own mods. It got merged; later I realized you manage your own files by looking at all the other USI ones and once I knew what was going on I edited the wiki to point-out to anyone else new wanting to contribute that some authors manage their own stuff and it's better to leave them to it (there was no such information when I looked at that guide and thus, that didn't occur to me; at the time I didn't know CKAN even had that ability, to pull from some other metadata file somewhere and the one in the repo being effectively just a pointer to it). Anyway, that was mostly a documentation issue and has since been fixed. Hopefully no one else new who wants to add your mods to CKAN will do what I did because they'll read the guide and be clued-in. Or at least I can promise to bring-it-up as long as I'm keeping my eyes on that repo. (I had the best intentions! The Malemute Rover is a great mod. ) That's an annoyance I have sympathy for. Though I disagree that being entirely opt-in is a preferable solution. At least not for CKAN. As I said, people are just going to scare-up their own CKAN files (I certainly would), and that'll end-up with more headaches on both sides. (Edit: And more animosity when users circumvent mod authors.) The crux of that issue is that CKAN depends on the original metadata being correct, and while large portions of that is automated (including versioning by reading the AVC .version file if it's there), as far as I'm aware things that specific are limited to users having to manually add them to the .netkan file for the mod. That leaves some room for human error, which can definitely be frustrating for both users and mod authors alike. The obvious solution, I think, would be to get AVC to support dependency versioning as well (not just the mod version + KSP version). If it's there, CKAN could read it and use it. It would add some robustness without the mod author needing to understand the vagueries of the CKAN metadata spec (of which there are many ). As for the spec itself, that's something of a documentation issue. I've tried to add important bits when I can (like editing the "getting started" part for new users who want to add a metadata file so that it mentions specifically to look-out for authors like RoverDude who prefer to manage their own metadata files that I mentioned earlier), but a lot of the extra bits like overrides and stuff really needs better documentation and examples. (Not being well-versed in C# and Perl myself doesn't help.) That certainly seems to be the biggest complaint, unless I'm missing something. While true, this does also require periodic human intervention to make sure those versions are up-to-date, which is a problem. As far as I'm aware, this is it. It's not enough to deal with dependencies, conflicts, recommendations, etc. (All of which are really, really handy as a user.) Edit: Which actually has me a little confused. @RoverDude, didn't you say earlier that AVC "handles" dependency versions? Or did you just mean it'll probably check the plugin that someone else's depends on and prompt the user to update it if it's out-of-date? Because if so it's not quite the same thing.

If you would care to be specific, I'd make a PR to fix it right now (assuming I could without a priori knowledge of whatever the next update will be). But I just went through all of the mods on CKAN that have you as the author, and aside from Asteroid Day and Firespitter Core, all of them just point to your repo. O.o There is another option. Close the NetKAN repo, make it a walled garden more fortress-y than Apple's App Store, and only let mod authors touch their metadata files. I think it's obvious how that'll end-up though. We'll end-up with users passing around their own hacked-together CKAN files that they'll use for installs when mod authors inevitably forget or don't update the metadata files (or simply have no interest in doing so and thus don't create them at all, like @JPLRepo; and to be clear, JPLRepo's stance is an entirely understandable one that I fully support). We'll be in an even worse situation than we are now, because instead of there being one place to point to and say "AHA! That's the problem!" we'll have dozens of unique files buried in threads or completely out-of-sight in PMs between users. Driving users "underground" like that by putting the full onus on mod developers to support CKAN or any manager like it will serve no one.

I have no idea. Modders here are in the best position to do exactly that. This topic is like playing with a live grenade (which I'm sorry to say, is extremely reminiscent for me of the reasons I left the KSP community years ago...coming back to this mess reminds me why I left in the first place ). With all due respect to RoverDude, KSP-AVC is not a solution for heavily-modded installs. Full stop. It's great to have as a backup to know when CKAN is going wrong (as it recently did with Historian Expanded; AVC's warnings let me know there was something off). However, it doesn't support dependencies, and it doesn't detect conflicts. What's worse, running AVC requires you run the game itself, which is a slow-as-molasses operation compared to CKAN checking for updates. The reason I use CKAN is because it's the only viable solution for running 200+ mods at once. At that scale, human error becomes a very major concern, and can make debugging the install because you fumbled and installed some older dependency file over a newer one because hey, mod authors aren't perfect and/or aren't around and sometimes do that, a major pain-in-the-ass. I use it for the same reasons I use Mod Organizer for Skyrim. It's the best solution available, not necessarily the best solution. So I'll keep using it and keep contributing metadata files and/or updates when appropriate, for the sake of keeping it running. This is going to sound rude but: If there's a problem, how about we all shut up and fix it instead of bickering?

It's false. Sophos Home detects nothing. That and AVG seems to be extremely prone to these kinds of errors.

That's what happens to me. If I just naively install this mod via CKAN, plop the ranger plus it's engines into the SPH and launch, as soon as it's finished loading it flips itself.

The VTOL engine is active by default. Couple that with KSP's (absolutely stupid) default throttle setting of 50% on launch, and you're bound to do flips on the runway before you can cut the engines.

Trying to figure-out what license you want on this for CKAN. CC-BY-ND ?

KSP is using the PhysX 3.3 SDK, which is what comes with Unity 5. The two key points I was making was that PhysX 3.3 does not provide GPU acceleration for rigid-body physics, but it does use parallel processing on multiple CPU cores for rigid-body physics. Since rigid-body physics is the main constraint on KSP's performance, that's what should be concentrated on when offering possible solutions to people experiencing low frame rates (which are coupled with a low physics-to-time ratio, which can be viewed easily with KerboKatz utilities; if it's just a low frame rate but the physics simulation is fine, you actually do need a better GPU). When it comes to the other things in PhysX 3.3, like hair, particle interactions, and the like (so all that "pretty stuff"), I'm pretty sure KSP hasn't touched any of the GPU accelerated parts. If they did, then we'd see very obvious differences between people's visual experience when using Nvidia cards or not. Yeah, all the GPU has to do in KSP, as far as I'm aware, is pump-out frames as per normal. There isn't any compute stuff being done on it. Sure. Take a five-hundred piece rocket and then explode it in some horrible fashion on the pad. Chuck-in the Destruction Effects mod on top of that and I'm sure you'd have enough particle effects going-on at once to start stressing an older GPU. Or you could try putting a few thousand lights on a single part or something. Not much physics going on there (since lights attached to the surfaces of parts don't have physics to speak-of; they're basically super-glued to the part, so-to-speak), but a whole lot of lighting and excess geometry.