Majiir

I think there's a middle ground to be had. Some of the proposed features for the community mod repository fall along these lines, but it would represent a more organic approach. Rather than forcing mods to adopt an untested format, we can instead have modders opt into a format that's enforced only by the repository. This way, boycotting the repository is a valid option for protesting the requirements, and that creates incentive for the repository to create a scheme which is acceptable for everyone. Old mods may never adopt the scheme, and that comes at their peril as tools begin to take advantage of packaged metadata. I'll leave specific designs for the repository thread, since there are a lot of ways this could work.

The server's undergone some upgrades and database purges in the past few days, so the above is no longer the case! It's also now published on the server list, so we may see increased activity. There's still a regular crowdâ€â€and we don't always play KSP, so feel free to come on any time. If you have an old bookmark that isn't working, make sure your bookmark points to ksp.nabaal.net and does not include a port number.

As the documentation says, they are mass ratios. So if you want to make a converter that turns hydrogen and oxygen into water, you'd set the output ratio for water to 1.0. This won't produce one unit of water per second; it will instead produce enough water such that the mass of the output is the same as the combined mass of the inputs. If you set it to 0.5, you'd get half as much mass out as you put in (and the rest is considered waste). If you want to control the rate in units instead of mass, use OutputRates.

There's no reason URLs have to match JSON output exactly. A simpler scheme might be "/mods/kas/0.4.5" yields information about a version, and "/mods/kas/0.4.5/download" retrieves the file. Also remember that a server can respond to the same URL differently based on headers, so a web browser will see a well-formatted page while an autoupdater might see JSON (because it sets an "Accept: application/json" header). You could also run API endpoints on a completely different hostname, e.g. http://api.example.com/json/get-mod-info?id=kerbal-attachment-system ...but I think that's not nearly as clean, myself. The information is retrieved in the same way; it's just a matter of returning it in a different format.

With both HTML and JSON listings available, it shouldn't be difficult to add an RSS feed... but it's additional labor, yet another standard to worry about, et cetera. Second- or third-round feature, in my opinion. There are frameworks (like Passport) that provide a common structure for implementing all kinds of authentication mechanisms. I think it's well worth using such a framework from the get-go, with simple username/password authentication to start. Supporting additional authentication methods might require some additional work to make sure there's always a sensible username available, for example. There's something to be said for URL slugs, too. Example: http://example.com/mods/kerbal-attachment-system These didn't work so well on Spaceport because convention dictates mod names include the mod version and the compatible KSP version. Accordingly, the KAS slug is "0-18-2-kas-kerbal-attachment-system-v0-1" which probably doesn't do wonders for SEO. A brief note about this ("don't include versions or anything else that might change over time") on the mod submission page might do the trick. Providing other IDs could be useful for URL shortening, but string keys are perfectly sufficient for internal use. In any case, it's important that if there are multiple URLs to a mod (e.g. /kethane and /12345), one URL should have a permanent redirect (HTTP 301) to the other. This indicates to search engines that they're the same entity. In my personal opinion, numeric identifiers are unnecessary here. This falls into the API category. Querying "/mods/kerbal-attachment-system" (with appropriate Accept headers) might yield something like this: { "id": "kerbal-attachment-system", "name": "Kerbal Attachment System (KAS)", "owner": { "id": "majiir", "name": "Majiir" }, "description": "Attach pipes and stuff!", "versions": [ "0.4.5": { "released": "2014-03-12T19:19:46.681Z", "description": "Fixes some bugs." } ] } It's probably more information than you're looking for at first, but it can serve a wider variety of purposes this way.

I'm not really sure what you're asking. It sounds like you want to write your own functionality with your own code, which I obviously have no control over. The Kethane API should expose enough for you to achieve this. (Specifically, use the resource generator API by implementing IResourceGenerator in your plugin, and interact with KethaneData.Scans to reveal cells with your own detector module.)

Agreed. When you first praised MongoDB, I was going to say it doesn't really make a difference for a site like thisâ€â€but now that you mention it, schemaless databases do make it a lot easier to add things like that after-the-fact. (Adding fields doesn't require modifying the existing database.) I wonder how often people search for things that aren't mod names. Searching for "kerbal" will probably fail, and "rocket" likely won't do much better. But something like "mining" or "pipes" will probably work quite well. So long as an existing search library is carefully selected, I doubt we'll have too much trouble. In any case, search is something that can easily be replaced later. (You've gotta rebuild the index, but that's no big deal.)

I understand what you're saying, and my statement stands. "His point is that such laws don't forbid any of the above for personal use." You're debunking a point he never made in the first place.

His point is that such laws don't forbid any of the above for personal use.

I largely agree with what you've done here. A few more thoughts: It's fair to make search a priority, but the requirement needs to be much more specific. You're right that we need a bit more discussion about that here (since tagging vs. full-text search is a core part of that). I've mentioned my thoughts on search elsewhere, but I'd be happy to enumerate in more detail if anyone likes. (I'm personally very much opposed to tags, but I'm interested in hearing a rationale for them. I find them spammy and ineffective.) Upload timestamps might be insufficient. It works for new releases, but if I want to upload all past Kethane versions, that won't be a useful indicator. An additional optional field for release date would be useful (and it could default to upload date). For a first round, it may be easier to skip building a permissions system for users, and instead allow administrators to interact with the database through a private back-end interface that's secured through some other mechanism. We're looking good here. I don't think it represents a super solid consensus, but it gives a good picture for implementers to start working. A lot of the remaining uncertainties may be best settled after the construction of a prototype.

Regarding craft files: My hosting offer is for a mod repository. While we can certainly have that discussion, I'm not really a fan of supporting craft files, and it's definitely not a core feature. I think it's worth simplifying your document a bit. It's wordy in some places, vague in others, and even overly specific in a few. Any place where you say "by this I mean two things" or "this has two parts" you should split those into discrete parts. (You even say this yourself at one point.) The document also contains a lot of open questions, and I think those should be resolved rather than documented. Specific comments: Update notifications are mentioned in the "major features" list, but subscriptions are not. My impression from discussion in this thread is that these ideas are linked, and that subscriptions may also play into mod rankings somehow (even if it's just a visual indicator). Search might not belong in the required features list. (Either that, or things like versioning and download metrics also need to be required.) A repository that allows modders to create listings and then link to them from a forum thread would still be quite useful. I'd go so far as to say download metrics are more important, at least from an adoption perspective. Mod metadata could be split into a few categories for requirements levels. Name, author and description are undoubtedly core features. Mod version is probably up there. The rest might not be; the thread has yielded varying opinions there. A document doesn't necessarily have to iron all that out right away, but it could help to categorize how certain we are about each feature. Regarding the description field: I haven't seen any objections to rich text. I like Markdown. Might as well just specify it and be done with it. The search feature needs a lot of work (in this thread, not just in the document). We've said we want it to be better, but exactly how it accomplishes that is something to discuss. My personal thoughts: full-text searches are cleaner than tagging systems, and it would help to use download and subscription counts to weight results. Requiring users to log in to download is a show-stopper, so it's fine if the update notification system only works for people who are logged in. We should think about what situations could cause the site's perception of a user's installed mods to differ from reality. A user might download a newer version without actually installing it, or they might download the latest version from a different location (e.g. an auto-updater packaged with the mod). What facilities should be available for users to correct their download history? I'm not completely convinced that mod versions need to have some discernible ordering. Is there some way we can save ourselves the headache while giving mod owners flexibility to decide which versions come before others? I think I agree with your second paragraph about mod versioning, but we need to be clear that this means we're dealing with two kinds of objects, mods and uploads, where each mod may have many uploads. It is thus not mods that have versions, but uploads; and not mods that have download statistics, but uploads. I think mods should certainly have a description, but perhaps uploads should too (for release notes and the like). As an alternative to uploads, we could call these "files" or "versions". I don't think the dichotomy you present in download metrics is necessary. The server collects and records statistics on things like downloads and subscriptions. Users can view some of these statistics. Perhaps we say that mod owners can view more detailed statistics while normal users can only see summaries, but that's a lot more clear than slicing and dicing it. I would move the first section in administration tools elsewhere. Administration tools are for administrators. If mod owners need some privileged controls over their own mods, we should enumerate exactly what they can do. On that note, something is missing: user accounts. They need to be created, authenticated and probably modified. What properties comprise a user, and how they can be changed, should be specified. Authentication can get really complicated, so for now I suggest we stick with simple password authentication and consider social media and third-party authentication later. I think it's okay to allow users to transfer mods without admin intervention so long as there's a big scary warning about it. I have a minor amendment to make to the proposed system architecture: nginx can handle file uploads and pass just the metadata onto Node.js for processing. It doesn't need to go into the document, but I thought it was neat. Overall, I quite like it. Documents are good. MongoDB allows you to configure write concern so you can trade performance for safety. That said, my server has been online for four years or so, and it's located in a datacenter with redundant battery and generator units. MongoDB can be made to dump data to disk regularly, and I doubt losing a few seconds of data in the rare event of power loss will be a problem. We're not dealing with financial transactions here. (Even if we were, it could be made to work.) It's not too hard to implement, but I think it's overly complex and you've already pointed out some problems. We can tell spiders to ignore the relevant endpoints, but consider that you could reduce the rating of a competitor's mod by simply downloading it a lot! Additionally, a mod's rating might sink as it becomes more popular because less invested users don't take the time to do anything more than view or download. Being linked on Reddit (generating a lot of view-only entries) could kill a mod's rating. [EDIT] I have offered my response. If we had some official announcement or support upon release, that would be grand. If not, I'm not sure what "it's welcomed" really means.

Yep, that's the place. It's pretty laid-back.

Popular threads are already popular. They don't need more attention. I say this as someone who owns two.

I've conspicuously avoided front-end. It will become clear when the server's mostly done what sort of front-end capabilities are needed. Something like Ember could be quite heavyweight, although I have no qualms about requiring Javascript support. This conflicts with the versioning feature. Fully agreed on the rest. A full-blown package manager is a project in and of itself, but a site could definitely support package managers by exposing a machine-readable API. That's minimal effort to accomplish. I've had to deal with this on Spaceport and it's not fun. This is a great second-round feature.

I do have opinions. Remember, that's what these are. If you disagree, great: build an awesome site to prove me wrong. While most of this is negotiable, it's probably easier for everyone if the technologies used are ones the host likes. As I wrote in the OP: Linux, please. It's free and can be more conservative with system resources. It also greatly simplifies deployment, setup and maintenance if all VMs run the same OS. All new VMs on my server get CentOS 6, and there's one currently on CentOS 5. This will be hard to negotiate; if your website is so tightly connected to a particular operating system, it's probably not a very good website. I like nginx. Other high-performance web servers can be considered, but I don't think there's yet a performance concern that justifies another choice. I will have objections to Apache, again based on experience. Note: For server platforms like Node.js that include HTTP servers, I'll still ask that a proxy server like nginx sit in front. This is to make configuration easier down the road, to avoid running the server as root, et cetera. I have a lot of experience with PHP, and accordingly I am not a fan. It's slow, it's constantly playing catch-up on technology support (radical things like "unicode") and it's a pain to get anything done without slotting your code into a framework with dozens of files that you'll need to tweak because configuration isn't flexible enough. There are many developers with some PHP experience, but there's a dearth of real talent. If someone builds a really excellent PHP-based site, I can roll with it, but I'll certainly be looking out for something else. I have vague philosophical and practical objections to Ruby and, to a lesser extent, Python. (That probably means Rails and Django in the context of this discussion.) This is a step up from PHP, but I'll roll my eyes a lot and take the time to refine my arguments against. C# is great! We love C# in the KSP modding community, right? Thing is, something like ASP MVC is really quite heavyweight, and it's probably overkill for a simple site like this. Setup and configuration will be substantially more complex. I could be convinced, but prepare for a very raised eyebrow. I like Node.js. This is weird, since Javascript is a highly dynamic language, and that's not usually my style. However, having spent some time developing with Node.js, I've come to really appreciate the ecosystem that's grown around the platform. Building a high-performance, data-oriented web service with Node.js is really easy. This opinion is controversial to some, and I am prepared to defend it. (In #kspmodders, please, not here.) MySQL is alright. I think it shines in more complex applications where data needs to be highly structured. For this site, I think we could benefit from the relative simplicity and easier-to-obtain performance of a NoSQL database. MongoDB is a good go-to choice, and there are plenty of other good options. Here's an example site architecture (overly simplified) using the bolded technologies: In this setup, nginx handles all HTTP requests. Static content like images and file downloads are served directly by nginx. Requests for dynamic content are proxied to Node.js. To track download statistics, nginx writes access logs for Node.js to parse. User file uploads are processed by Node.js and written to the filesystem to be served by nginx. I stress that this is just an example. Alternative suggestions are encouraged.

On the other hand, it's useful for new players, or players who are new to modding. "Most popular this month" might be better. In any case, I think multiple such indexes are a good idea. This kind of feature is quite easy to duplicate with different flavors. I agree. As far as I know, .zip is the only archive format supported by all platforms. I generally agree. We could go back and forth on the metadata requirements, but I'll agree that every mod should have a name, date, author and version. What you've outlined is a great starting point. I also don't like mod managers. Moreover, Nexus has been around, and yet there are just two mods there. It clearly doesn't meet the needs of most modders. Absolutely. Negative requirements are important. Consistency with statistics and uploads is fairly easy to accomplish; it just means not screwing up caching. As for your last point, I will personally guarantee that at least half the content available on the server is pretty girls. This is getting at a few issues simultaneously, but this is an important takeaway: the site should have a machine-friendly API. A mod manager should be able to query the site for structured information. (Luckily, this is easy.) You both make good points. Version indication and notification seems to be an important differentiating feature. Without even that, the site is just a file repository. With it, the site can resolve an often-requested community wish list item.

There are a few pages I want to comment on, but I'll get to that another time. Calisker, You're likely to get some negative responses to this, so I'd like to illuminate why. In the first place, you've given us some vague information about yet another mod hosting project, but the first public indication of this is in a thread dedicated to a community-driven replacement. It seems like damage control, not sincere interest. Squad has a habit of making bold statements and not following through. This is certainly the case with Spaceport. This new project is yet another initiative with no stated time frame, and many of us frankly have no confidence that Squad will get the job done. Bringing this news only makes it harder for us to motivate the creation of a community platform since a Squad solution will always feel right around the corner. I have some experience with this feeling: I author Kethane, a resource mining mod. Many of us resent Spaceport's continued existence because its inertia makes establishing a superior alternative more difficult. There's a deeper problem, though. The modding community has long tried to have some influence on Spaceport, or some transparency in its development process, to no avail. I've requested many times that Squad have detailed discussions with modders about what we want out of Spaceport. I've communicated specific requests (e.g. change of uploading terms) on behalf of the community, and they've come back with assurances of resolution followed by long silence. (It's particularly bewildering because most recently, Squad approached me about the modding community's grievances, and yet no public action has been taken.) From its inception, Spaceport was a Squad project to further Squad's goals. That's fine; it's Squad's duty as a business to work in its own interest. However, it's become clear that the modding community needs to look out for itself and its interests. Personally, I think it's not worth Squad's time. Let us handle it. Spend your resources on building the game. If you want to help now, a few people are curious about Spaceport traffic statistics. If you want to help us later, you can help me recoup my server costs. In the meantime, I ask that Squad follow up on its prior promises to the modding community before getting involved in a new undertaking. (I have documents for your reference if you require.) As always, feel free to get in touch. You've got me on Skype. Cheers, Majiir

Interesting. I'm inclined to say subscriptions are a good indicator of a mod's popularity, especially if combined somehow with downloads. It's true that "stars" are not particularly descriptive. I can see the "last download date" being very useful. I wonder how to handle new subscriptions. Should the subscribe date be considered the "first download" if the user hasn't downloaded the mod? I also wonder if this would get irritating for users who don't log in to download mods. I suppose there can be a "dismiss" option, but as always I prefer caution with new features.

How would this work? If it's a mod that requires a plugin, then that plugin is what's listed as the download. If not... how do you download a hardware mod? It might be a good idea to take this up with the forum moderators to get a dedicated hardware projects section. Before I address your points in detail, I have to say I think you've missed the point of simplicity. There is no lack of feature ideas here. What we lack is a cohesive set of core features. In other words, we haven't yet (in my opinion) established a good starting point. If someone had to start coding right now, they wouldn't have even a basic idea of how the site should function. One file per mod or several? What kind of files are allowed? Can people download from the site, from an external link or both? Who gets to upload files? There are many such decisions to make before we can even think about more complex features. I highly recommend everyone read Minus 100 points. With that said: Voting on compatibility is possible, and it's been suggested earlier in this thread. I have doubts about both the efficacy and necessity of this. I doubt its efficacy because I've seen too many cases on the forums where the masses get it wrong. I doubt its necessity because ultimately, only the mod developer can say whether a plugin is intended for use with a particular KSP version. Yes, an unmaintained mod might still appear to work in a newer versionâ€â€and this is the sort of information, with all its caveats, that's best communicated on forums. A simple up/down vote cannot encapsulate the nuances of version compatibility. Dependency linking is possible, but it's overly complex. Dependencies are fairly rare and easy to communicate with a simple link in the mod description. I'm not really sure what this idea actually accomplishes. Others have come out strong against comments. You offer a middle ground where comments are highly restricted, but again, I wonder what the point is. If we treat them as reviews, maybe we can design a proper review system, but that doesn't seem appropriate for a core feature. Version history would be nice. The question here is not so much if but how. What do you mean by "third party download site support (GitHub pages)"? And more acutely, what benefit justifies the feature? Github has a set of standard names and formats for README files. It would be possible, like NPM, to link a mod to a Github repository and automatically fetch the README. I'm not arguing that this is a bad idea, but I do think the feature should be justified. Mod update notifications would appeal to a lot of people. The same questions apply: Should it be a core feature? What justifies the feature? Exactly how should it work? And one more, specific to notifications: How, if at all, should this interact with other features like star/favorite/endorse rating systems? Push notifications to specific mobile services is getting way outside the realm of core features. Start with e-mail. Uploading large files is a server configuration issue, and e-mail often fares worse. If the site is built and some users have problems uploading, that's an issue to address then. I don't expect any mod will exceed a couple hundred megabytes anyway. When you mention links to support and development threads, you're talking about four pieces of data (two links for each thread) with constraints on that data (the release posts have to be from the same thread as the original post, and all links have to be from the KSP forums). Since the support/dev thread dichotomy is not universal among mods, I don't think it's reasonable to expend development effort on something that could just as well go into a mod description. If you're interested in coding, I highly recommend you take a more conservative approach to development. "Finding the time" is hard if you make yourself a feature list that large. I can't say this enough: start simple. Squad has failed in its responsibilities and promises to maintain and develop Spaceport. Squad has also failed to resolve the simplest of the community's concerns. At this point, I don't think they have any business being upset if another site obsoletes Spaceport. Regarding retextured stock parts, there's nothing this site would do that others haven't already done. A lot of modified stock parts are distributed outside of Spaceport. Modders are de facto allowed to create and distribute derivative works of stock parts. I put in a request to Squad's lawyer several months ago to clarify the status of derivative mods, and the response was that there's not yet an official license, but they like the idea. I wouldn't worry about this.

The legacy generator is limited in this regard, but you can create your own resource generator plugins by implementing the IResourceGenerator interface. (Any class implementing IResourceGenerator must also have a constructor that takes a single ConfigNode argument.) You might check in with TaranisElsu, since he was working on custom resource generators for a while.

I'm leaning this way. I particularly like how NPM has an indicator like "last updated 2 months ago". For mods, another decent indicator could be the KSP version when the mod was released. It doesn't give a complete compatibility picture, but it gives a first-glance look at whether a mod has actually been updated for the latest version. I don't think it would be a good idea to allow non-authors to create entries by linking to other sources. Some projects are licensed such that anyone can distribute the work, so that's fine. As you mention, direct-linking can bypass such license restrictions, which isn't an intended effect. My personal opinion is that direct-linking isn't worth what it costs. If a modder isn't comfortable with the repository hosting files, he can give feedback on why. It's healthy for the site to have to earn adoption by modders. If multiple competing projects launch, they'll likely still be in a beta phase. It would be good to make an announcement to the general public if a clear winner emerges. I think it's worth considering that moderation might not really be necessary. Crowdsourcing quality control can be really advantageous. Taking download counts and user feedback into account, we might be able to get away with a flagging system for egregious cases (e.g. illegal content). It would be great to have access to a login API to authenticate forum accounts. I don't think any other involvement by Squad would be a good idea. They've already demonstrated incompetence in this arena, which is why we're here. My concern is that we'd be starting with a huge pile of features aimed at accomplishing a different goal. Large systems are harder to maintain, so adding the features we want (and removing the ones we don't) becomes more difficult. If modders don't take advantage of our Gitlab clone as a source repository, we get nothing except the releases system; if they do, we lose a lot of history on Github and switch everyone from a well-maintained, reliable service to our amateurish installation where we don't really care so much about the source control features. This is along the same lines as cloning Wordpress (which is what Spaceport did). I'm not convinced that the benefits of a "head start" are outweighed by the significant development and maintenance costs.

Yes, that's what I mean. Think of Github's star system, or a browser's favorites list. Github displays a count of how many users have starred a repository, and each user can view his list of stars. It's a loose way of gauging popularity, and it tends to work as long as the action of starring also does something like adding the item to a quick reference list. (This way users don't just star everything they see.) I mentioned to Greys in #kspmodders that NPM is a great example of a simplistic repository: https://www.npmjs.org/ NPM serves a very different purpose, but it does a good job at providing a consistent and informative experience without much complexity. I agree that it's possible to be too open-ended, but I also think it's important to carefully justify each additional piece of information that's made into a first-class feature. For KSP mods, it might be important to display author, version and release date, but a donate button might be too esoteric. These are issues to sift out keeping in mind that complexity can always be added later. This is why I created this thread instead of working on code. I'd really like to see this happen, and while I think I have the skills to get the job done, I don't think I can make the time commitment. Plus, a lot of the feedback so far deviates from what I expected, so that's valuable knowledge. MongoDB is certainly a good candidate technology for a site like this. Of course, that final determination will require more details on what exactly the site will do.

In the spirit of simplicity, I'll distill this down to one feature: rich description field. A simple text formatter like Markdown can be extended to support video embeds. I agree that commenting is a bad idea. I also think traditional rating systems are a bad idea, although I'll address this in more detail in response to Greys. Automated build is a huge feature, but something that's very easy and allows for the same end result is a simple submission API. If the site is well-built, this wouldn't even need to be a separate feature. This way, you can use an automated build system like Jenkins and have your built script automatically upload releases. I think I agree with this at a fundamental level, but what you've described is getting very complex, especially when you talk about logins, versions, flags, moderators, et cetera. A system that brings more responsibility to mind than Reddit is StackOverflow, but that works because reputation is earned as a sort of currency, and that must be spent in order to vote down. Another alternative is a "star" system, which is essentially upvote-only (and can seem less like a voting system if it's used to give users a "favorites" list). Crowd rating systems are hard to get right (even Reddit is still refining its algorithms) so I'm not sure this is a core feature. There are a number of ways to do that, but it can get complicated if you try to be too automatic. If the system is to support multiple versions of a mod, is it not enough to have a "latest" (or "default") and then a chronological listing of all other versions? The fanciest you have to get is allowing the mod author to manually reorder the listing. This is getting way too complex. It seems simple on the surface, but when you consider all the API endpoints, database routines and front-end scripts that would go into it, this becomes a huge feature item. It's not worth it. Either the mod will have been updated after the latest KSP release or it won't. If someone wants detailed compatibility information, they can go to a linked forum thread. Sure... in the general-purpose description field. KISS. This is making my head spin. KISS again. That's a whole lot of work for a problem that isn't fully articulated. This won't be operated by Squad, so it doesn't need to conform to Squad's community rules. I personally disagree with making license selection mandatory; so long as a sensible default policy is clearly communicated, the worst case is that mods are licensed more restrictively than intended (and this can always be amended). I've said this about Spaceport, but the reason is because Spaceport doesn't have good analytics, and as an author I want to be able to track downloads. Off-site download is not completely unreasonable, but it does introduce complexity, so I'd be interested in justifications. There are advantages to requiring that files be hosted. (If a link is broken or leads to a slow download server, that could irritate users while reflecting poorly on the mod repository.) I like this idea. I don't think it's a core feature, but it's a good second-round addition. It could go very nicely with a "star" system since users would be disinclined to star mods they don't care to keep easy track of. As others have mentioned, this is both detrimental to users and simply unnecessary. (Seriously, I have plenty of bandwidth. I host one of the most popular KSP mods, and my monthly bandwidth readout always rounds down to 0% utilization.) Documentation is just something that quality mods do. You can't force quality.

Community Mod Repository The goal of this project is to replace Kerbal Spaceport with a community-built, community-run alternative. Spaceport is in disrepair, and both it and its planned successor are effectively abandoned. By producing our own repository, we can ensure that it serves our interests as the producers and consumers of mod content. There's been some discussion (e.g. in #kspmodders) on what a replacement should look like. I hope this thread will both consolidate those scattered discussions and attract more of the community at large. The Majiir Challenge One of the greatest obstacles to this project is the cost of server infrastructure. Weighing in at just 15MB, Kethane alone generated 650 gigabytes in download traffic in January. A popular mod repository would easily overwhelm any free or inexpensive hosting plans. To eliminate that obstacle, I am offering free hosting for a community mod repository. My own server infrastructure is highly underutilized, and some back-of-the-envelope calculations indicate it's more than enough to handle this project. Specifically, I can provide virtual private servers on a baremetal hypervisor that I manage. This means I can support any needed server software and configuration so long as it doesn't incur additional licensing costs. (That means Linux, please.) The server is located in a Tier III datacenter (that's good), and it has a gigabit Internet link with plenty of bandwidth. I can also provide SSL certificates and (probably) domain names. In other words, I can take care of anything that really costs money. Since we may see multiple projects in the works, I'm willing to provide service for any promising candidates until a clear winner emerges. Note that I have a preference for scalability, so a lightweight server will be more likely to win the challenge than a Wordpress reskin. (Super bonus points for using Node.) There are no hard-and-fast rules at this point. My goal is to encourage development by removing the cost concern. My Two Bits As a mod developer, these are some things I'd like to see that would convince me to host Kethane on a repository: Detailed download statistics with an option to export raw data. This is my biggest sticking point. Effective search system. I don't care if it picks up every keyword, but if someone searches for Kethane, my mod ought to come up first. No moderation queue. At the very least, there should be some way to graduate out of moderation. Previous version support. I like to keep previous versions available for reference purposes, and some users like to hold off on updating. But above all, I suggest to start simple. There's no point in getting wrapped up in a complicated categorization system before producing a first version. Let's talk core features, technologies and objectives.

Hi psyper, Your download looks good as far as licensing is concerned. Just one note: You've placed a config file in GameData/Kethane/Resources, which is unnecessary. Kethane looks everywhere in GameData for matching files. You can put that file in GameData/Psyper and then everything will be nicely self-contained. The rule of thumb of good mod packaging is to only ever touch files in your own directory. If another mod makes it necessary to modify their files, ask them to change their API so that's not necessary. Cheers, Majiir