Community Mod Repository and The Majiir Challenge

[K3-Chris]

I'm a freelance web designer (that means css, JS/jQ, etc, aka the fancy bits people look at, click etc) willing to work for free once there is enough to put a design on-top of. Any suggestions for general layout? I can do some static designs for feedback in the meantime.

What we can all agree on I think: Main navigation is a horizontal menu at the top, bellow a logo/banner, search field up there as well, question is what the navigation would contain, mod categories? (what are the categories?) top lists (most downloaded, highest rated etc)?

Navigation is the primary hurdle the spaceport failed to jump, there are a lots of good mods in there, buried by ship files with all tags you can add, if replaceport aim to be an improvement it needs intuitive navigation that quickly and easily gets you what you're looking for while showing you things you might also want.

I think replaceport could also have ship files but they would need to be clearly separated from mods, and the main search shouldn't list them by default, the option to search through ships and the search on the page specifically for ships would ofc allow you to look through them, but not the main search.

One neat feature you could do with the ships is include a list of mods it needs, basically tag those mods on the ship entry, though again if you search for KW, show KW, not ships using KW, unless you search for ships specifically. A similar feature could be used to list needed libraries for a mod, say module manager, SmokeScreen, etc.

Obvious question is obvious: since this is a fan-project and not an official squad site can we use "Kerbal Space Program" or parts of it in the name, logo/artwork etc? I doubt Squad are the sue-happy kind but it's best to get these kinds of things down on paper, if the site's URL is something like "kerbalmods.com" (not a particularly catchy url but you get my point) and at some point in the future squad gets an on-staff lawyer... well... though I guess if they object it's easy enough to switch at that point.

[croxis]

Categories/Tags are hard to get right. One problem faced by the Bukkit mod, which adds a plugin interface for minecraft servers, is that the plugin authors would tag everything that would even remotely apply to their plugin. I might be browsing for an economy provider plugin in the economy but the category list will be polluted with shop plugins listed (which does make sense) to land management plugins like Towny just because there is an option to buy land.

Spaceport's categories seem very part centric. I haven't uploaded a mod to spaceport but I assume the author selects which categories/subcategories of parts the mod applies too. I think this works well for the use case of someone browsing for a specific part type ("None of these engines are working for me which mods have more engines..."). It doesn't seem to serve well for organizing mods by themes (saturn v, space x, etc) or mods around a mechanic (kethane, interstellar, remote tech).

There are multiple use cases that are some combination of: browsing for mods but not looking at something specific, browsing for a part type, browsing for a mechanic, browsing for a theme, searching for one of those categories (mods that offer reentry, parts that are apollo mission themed), and searching for a specific mod.

One solution is to offer a small list of predefined categories/tags where the mod author can only pick one or two tags that best apply for their mod.

[Greys]

Suggestion for a round1.5~2 feature, have the server automatically generate a text file in a specific human readable but easily parsed format with information the uploader gave when creating the listing, and then inject that file into the provided zip archive at */GameData/$1/ so that the user will install this descriptor file without any direct considoration. This is an easy way to provide a completely uniform installed version tag that is agnostic to what kind of mod it is, so long as it has it's own directory (patchs may cause problems), and the modder does not need to do any additional work to maintain this file. Making the file easily parsed will make it easy for client management software to be aware of what version of the mod it is, and because it'a being generated by a single entity they will have a uniform format.

[whaleberg]

As a mod user but not yet creator, these are the features I'd find helpful in a mod repository:

1. The ability to subscribe to mods and have a single RSS feed that I can follow to see changes to any of my subscribed mods. The RSS feed is the really key bit there.

2. Version and compatibility information.

3. Some sort of search/rating/tagging system. A simple thumbs up or down is usually entirely worthless (sometimes worse than no rating system if the total number of voters is small), but some combination of tags/stars/numbers could be quite helpful.

[Javster]

The main thing I'd like is either moderators checking mod uploads (not always possible) or an option to report a mod as spam.

I also think that anyone MUST INCLUDE pictures, source code, description (word minimum & spam filter) etc. to make sure any mods uploaded are actual mods.

Tags (if any) should be limited to 5 to avoid spam.

[Majiir]

Suggestion for a round1.5~2 feature, have the server automatically generate a text file in a specific human readable but easily parsed format with information the uploader gave when creating the listing, and then inject that file into the provided zip archive at */GameData/$1/ so that the user will install this descriptor file without any direct considoration. This is an easy way to provide a completely uniform installed version tag that is agnostic to what kind of mod it is, so long as it has it's own directory (patchs may cause problems), and the modder does not need to do any additional work to maintain this file. Making the file easily parsed will make it easy for client management software to be aware of what version of the mod it is, and because it'a being generated by a single entity they will have a uniform format.

Echoing various discussions on IRC:

• The biggest problem I see is that this presupposes that every mod will be exclusively distributed on this repository. If client programs depend on repository-specific metadata, then a mod could not be reasonably distributed elsewhere because that metadata would be lacking. Installing a new version from elsewhere would result in metadata being missingâ€â€or worse, stale. (You could upload to this repository first and then distribute the product elsewhere, but that directly contradicts the requests from a number of developers for publishing hooks to write into build scripts.)
  
• This is a repository and distribution platform, not a mod manager. Those exist, and they often have their own metadata regime. Including metadata on the repository side blurs the line between publishing and distribution. This site should be excellent at distribution of mods in a way that's useful to both developers and users. Publishing tools, which might automatically package metadata, should be used before a mod is uploaded so that distribution can happen anywhere.
  
• Other schemes already exist for conveying version information and other metadata. Threads periodically crop up about mandatory metadata files, and they rarely see much support. I don't see that a repository-forced scheme would go over any better.

[ROFLCopter64bit]

Just my 2 cents:

What would be really good is direct links and hashes. Speaking as a mod manager developer, the first one is needed for mod updating, and the second is for the ability to check for updates without having to download the entire file (I could download only the first 1kb and check against the archive downloaded, but there would be major flaws).

While we're at it, the ability to host modpacks would be nice, since the only way I can provide access to modpacks is if the modpack creator or myself hosts the list file, which can be problematic at times.

[orcaman]

Update Notification system

An opt-in system that allows users to be notified that a new version of this mod is available. The most obvious push method would be an email (w/user selectable frequency). For a passive notification, logging on to the site would yield a notification icon that would link to a page listing mods that are newer than the version last downloaded by the user. This requires two significant elements. First, users must be logged in when downloading for this to be tracked. However, requiring registration as a barrier to entry is probably not what we want. Second, date and version of download must be tracked by the server for logged-in users. The opt-in system would ideally be something simple, like a subscribe button on individual mod pages.

^^That's a quote, in case I've done this wrong. ^^

Tracking user downloads isn't really necessary, and may even end up becoming confusing to users. All you need to do is notify them when an update is available. They follow, mod updates, they get an e-mail. It's not like we'd want to harangue them them reminder e-mails if they didn't log on and download. And for a notification icon, you could just use their last logon date. If they downloaded some while not logged on, sure, it'd be redundant, but worst case scenario, they take their time re-downloading and reinstalling the same version, and if they've made it that far, won't know the difference. What I meant by "It could become confusing" is if they downloaded, but never got around to installing, it could falsely inspire confidence that they were sorted on their end.

If mods start integrating updating with Toolbar, I think it'd be easy enough to use links that could point to a new mod site, Spaceport, or anywhere else, and could be changed with every new version of the mod., so there's no reason work on that kind of system couldn't go ahead and start, and integrate with a community mod board as it develops.

[Caelib]

We need this now that we know about the Curse thing

[stupid_chris]

Yes, this really needs a bootup.

Any no-ad, no-curse alternative will be praised.

[czokletmuss]

I just came here to say that I support the initiative.

[Justin Kerbice]

Yes, this really needs a bootup.

Any no-ad, no-curse alternative will be praised.

What does it means ? The brand new thing Squad set up is not ultra-super-amazingly-good ?

[John FX]

Please offer ANY alternative to curse. I would use it to upload my craft. It would be the place I would search for mods.

I imagine people use whatever link is in the thread so if people use it instead of curse then curse will just die (for KSP).

[stupid_chris]

What does it means ? The brand new thing Squad set up is not ultra-super-amazingly-good ?

I don't like the system, and don't feel like putting my users through the barrage of ads curse offers. I'll be hosting myself on Dropbox or Mediafire, at least until someone comes up with an awesome alternative.

[FEichinger]

As I already hinted at in the Curse thread, I've got some time on my hands right now and do this kind of stuff for a living. I need a few more hands and a bit of a run-up with organization, but I could probably get around to doing something like this. I'm not keeping tabs on this thread here, though, hence why I asked Majiir to contact me directly. Just thought I'd leave that note here as well for you folks.

[John FX]

Well I only hope that the good that comes from all this will be an ad free community made mod hosting website.

I know I`ll not be using curse ever. I`ll be using mediafire and dropbox links from the threads until this travesty is stopped or an alternative is forged from the ashes of the old...

[The Jedi Master]

My question is, will this be allowed? Squad might not like it.

[FenrirWolf]

My question is, will this be allowed? Squad might not like it.

From the beginning, KSP mods have been uploaded wherever people feel like putting them. If people wanna put them on Spaceport, Curse, or some other place it's up to them.

[stupid_chris]

My question is, will this be allowed? Squad might not like it.

How would that not be allowed?

[Majiir]

My question is, will this be allowed? Squad might not like it.

Squad has stated they'll support (with words, at least) a community repository.

[Ignath]

Squad has stated they'll support (with words, at least) a community repository.

They also stated (with words, at least) that they would be the ones handling Spaceport 2 (though their actions have been telegraphing otherwise for some time now), but then turned it over to the turd sandwiches at Curse. Sometimes hard to know if SQUAD really means what they say now...

Plus, think Curse will be "happy" in their partnership if the "clicks just aren't there" and their "revenue stream is drying up" on KSP mods.

All the more reason for a great Community Mod Repo! I applaud your efforts Majiir and the efforts of everyone working to get this done after the crap SQUAD forced on us today. If my, meager tho they are, web development skills could come in handy with anything you're doing, please let me know. I fully support this idea!

[croxis]

Source on github

I think I'm at the point where help would be awesome. Most of the basics are in place: rudimentary search, user accounts, atom update feeds.

Frontend:

* Right now I'm using bootstrap so I can get something that looks ok quick. I know squat about web design so a lot of work is needed there.

* There is still no page for presenting download stats.

* There is no page or spot for mod makers to upload or manage additional images.

Backend: I am also not a professional programmer

* Optimizations are needed in the database query.

* Search uses mogondb's built in implementation but needs to be replaced with something that can do partial word matches.

* The search and mod list page should also be combined into one with some simple filters.

* Mod download stats are recorded but there is no front end to present that data.

* The admin page is run by the flask-admin package, but it really needs some work or rewritten from scratch to make back end administration a bit more flexible.

* I'm also still debating on switching user accounts to just oauth/openid.

Edited May 6, 2014 by croxis

[Rowsdower]

They also stated (with words, at least) that they would be the ones handling Spaceport 2 (though their actions have been telegraphing otherwise for some time now), but then turned it over to the turd sandwiches at Curse. Sometimes hard to know if SQUAD really means what they say now...

Plus, think Curse will be "happy" in their partnership if the "clicks just aren't there" and their "revenue stream is drying up" on KSP mods.

All the more reason for a great Community Mod Repo! I applaud your efforts Majiir and the efforts of everyone working to get this done after the crap SQUAD forced on us today. If my, meager tho they are, web development skills could come in handy with anything you're doing, please let me know. I fully support this idea!

When it came down to SP2, ultimately we didn't have the bandwidth and resources available to present an experience with a quality as initially conceived. Going with Curse allows for a better organized experience with greater stability, run by a team with the resources to properly handle community mod hosting needs.

Curse is well aware of the fact that they're not the only game in town when it comes to KSP mods. They are the official repository, but not the only one. I, of course, encourage everyone to give it a try if they'd not done so, but if you're not into it, that's fine. The forums will continue to be available for use and if Majiir or anyone else steps up with an unofficial community one, I'll gladly shine a spotlight on that, too.

[TMS]

Is it worth making contact with N3X15 to gauge his interest?

No idea if he's been burnt too much on the issue or how draconian his NDA is, but his earlier dev notes indicated that he'd progressed pretty far with Spaceport 2.

[O-Doc]

So, did anything concrete in the way of documentation come of this thread? Yes, I'm here after reading the curse thread and checking out the website. Yuck. I think the best approach is to split between the front and back and get to work on a restful API, URL mapping and UI specification. All the wish list stuff should go in later once a basic prototype is up and running.

So, will Replaceport be Spaceport2? Or, is radical departure envisioned? Here's a list of requirements I want to see.

• Solid browse pathing
  
• Working search form
  
• Basic user management
  
• Primitive versioning
  
• Project assets
  
• User comments
  

Really simple stuff you can punch out and then go back to the back-end and work out higher order objectives like security, performance, authentication, version control, community integration.

I'm happy to punch out a prototype with a LAMP framework like CakePHP. I'd like to learn NodeJS, it's on the list of things to do for this year but, it's easier just to get a working site up with the RESTful API in place and do the port later. I'd go far as using a crappy free design/template just to put something up.