SpaceDock.info (Mod Hosting Site)

[MajorLeaugeRocketScience]

This is simply amazing. Less then 2 days after KerbalStuff shut down, we're already working (finishing?) up a replacement.

KSP community is the best.

[RoverDude]

Nifty work!

Just a few things from reading the past pages.

This should absolutely be opt-in.  In my case, given the velocity of my releases, and the support issues that disparate downloads cause, I'd just as soon have complete control of precisely where my stuff lives.  I will of course at some point upload to this new site - but not before I have the process automated, since otherwise I get a ton of unnecessary work.  Again, opt-in is the right way to go, for a variety of reasons.

Also - RE @Yemo's note:

" 4. Spacedock as a frontend for KSP-AVC version checking/updating
Maybe ability to auto-generate .version files and add them to the zip file for the distant future? "

This is a very very very bad idea, given KSP-AVC works in precisely the opposite way.  I push a version change to GitHub's release branch, and everything else drives off of that.  Checking?  Fine.  Updating?  No bueno.

I like the idea of having alternate delivery and discoverability mechanisms.  I do not like the idea of workflow being dictated, or things being distributed/changed without it being explicitly done by the modder, regardless of whether or not the license technically allows it (again, let's separate 'what we can do' with 'what we should do').  

Or, to paraphrase Philosoraptor, just because a tomato is a fruit does not mean we should put it in a fruit salad.

 

[Manwith Noname]

10 minutes ago, RoverDude said:

...just because a tomato is a fruit does not mean we should put it in a fruit salad.

 

Damn....so that's where I've been going wrong all these years.

[billkerbinsky]

9 minutes ago, RoverDude said:

Also - RE @Yemo's note:

" 4. Spacedock as a frontend for KSP-AVC version checking/updating
Maybe ability to auto-generate .version files and add them to the zip file for the distant future? "

This is a very very very bad idea, given KSP-AVC works in precisely the opposite way.  I push a version change to GitHub's release branch, and everything else drives off of that.  Checking?  Fine.  Updating?  No bueno.

Agreed; the site should serve up the exact artifact it was given by the developer.    Checking that any .version files present are is both different from and newer than all previous uploads (using KSP-AVC's definition of "newer", of course) would help both developers and users - I've had to manually whack .version files in my install tree to shut up AVC when the newest version had the wrong .version file.  

[JedTech]

Please don't go with Opt-In just because a few CKAN critics don't like CKAN. I truly think CKAN will fail if it follows this route.

The intention and spirit of free distribution licenses is exactly that (unrestricted distribution). Those licenses should not be used if an author has objections to the principles of the license. CKAN should not be an automatic-feeling detector which probes modders feelings on if they really intended to use their license or not.

CKAN is all about auto-magically installing mods so that users can focus on playing KSP. It provides a service that looks for mods that allow distribution and then it distributes them.

[Yemo]

1 hour ago, RoverDude said:

Nifty work!

Just a few things from reading the past pages.

This should absolutely be opt-in.  In my case, given the velocity of my releases, and the support issues that disparate downloads cause, I'd just as soon have complete control of precisely where my stuff lives.  I will of course at some point upload to this new site - but not before I have the process automated, since otherwise I get a ton of unnecessary work.  Again, opt-in is the right way to go, for a variety of reasons.

Also - RE @Yemo's note:

" 4. Spacedock as a frontend for KSP-AVC version checking/updating
Maybe ability to auto-generate .version files and add them to the zip file for the distant future? "

This is a very very very bad idea, given KSP-AVC works in precisely the opposite way.  I push a version change to GitHub's release branch, and everything else drives off of that.  Checking?  Fine.  Updating?  No bueno.

I like the idea of having alternate delivery and discoverability mechanisms.  I do not like the idea of workflow being dictated, or things being distributed/changed without it being explicitly done by the modder, regardless of whether or not the license technically allows it (again, let's separate 'what we can do' with 'what we should do').  

Or, to paraphrase Philosoraptor, just because a tomato is a fruit does not mean we should put it in a fruit salad.

With opt-out I meant the same "checked by default" checkbox which was there on kerbalstuff (and did not cause any problems for anyone to my knowledge), but with the added functionality that it works as a toggle and can be changed after the initial upload. All problems I heard of so far were not caused by this checkbox, but by the addition of a mod to the netkan repository, independent of kerbalstuff checkbox and the modders knowledge - anyone please correct me on that.

The problem with "unchecked by default" would be the same as today. There is no simple/external way to differentiate between modders who ask people for help to add their mod to ckan because they can not check that box after the initial upload and lack the time or knowledge to do so, and modders who do not want to be on ckan. While that is easy to remember for the prominent mods/modders, it becomes the same mess as today for the not so prominent ones.

Contrary to that, if the box is unchecked, but was "checked by default", there is no question about it that the modder made the choice to stay away from ckan.

As I said above, I do not know of any case where the "checked by default" box on kerbalstuff was the problem, to my knowledge the problem was always when people (most trying to be helpful) added the mod to netkan independently of the modder. "Checked by default" but toggleable would prevent that while "unchecked by default" would continue the existing ambiguity.

Of course modders who administer their own metadata like eg @RoverDude, the modders invovled in realism overhaul and myself would be independent of that anyway. Though I would like to be able to use a spacedock drop-down interface to generate/edit the metadata file (thus preventing stupid mistakes) and then copy paste it to my repository where it is read from.

 

@RoverDude,  @billkerbinsky

About KSP-AVC:

This was meant as an optional feature for the far away future, for those interested, certainly not active by default. But I agree with the feedback that checking the included .version file as an extra precaution/warning makes more sense then changing it automatically.

Edited February 16, 2016 by Yemo

[RoverDude]

15 minutes ago, JedTech said:

Please don't go with Opt-In just because a few CKAN critics don't like CKAN. I truly think CKAN will fail if it follows this route.

The intention and spirit of free distribution licenses is exactly that (unrestricted distribution). Those licenses should not be used if an author has objections to the principles of the license. CKAN should not be an automatic-feeling detector which probes modders feelings on if they really intended to use their license or not.

CKAN is all about auto-magically installing mods so that users can focus on playing KSP. It provides a service that looks for mods that allow distribution and then it distributes them.

Oh, the difference (and the slippery slope) is going from 'Here's where to find stuff' to 'Here, let me give you my copy of a file that I grabbed without the modder's knowledge and may very well be out of date'.  Or, to bring this more in line with SpaceDock - I would hope (and expect) that they would not include mods on SpaceDock unless a modder explicitly uploaded them to that service.  

Reason being, that if there's a distro floating around that I'm not aware of, it causes support headaches as I can't guarantee it is 100% in sync.  This is why I did not toss mods on KS until I had an automated way of doing this with the same automation tools that I use to publish my GitHub release - which makes my job easier, and guarantees I have no weird versions floating around.

So in short, and based on what I've heard since the original post, as long as SpaceDock stays in the 'upload stuff here if you want to share it' vs. the 'let's find everything to share and upload it ourselves' model (even if that latter case respects those of us who host our own CKAN metadata) then we're fine.  

If on the other hand, we as a community insist on putting tomatoes in our fruit salad, then you're going to see a lot of changed licenses.  Or, to spin it around, imagine how folks would feel if Curse started pulling all open-license mods and adding them there without the modder's knowledge just because the license said they (technically) could.

Edited February 16, 2016 by RoverDude

[regex]

Really glad I don't mod anymore.  These proposed changes to dictate workflow would just make me distribute on Curse...  Make CKAN opt-in, not opt-out.  Same with AVC support (god how I hate that plugin).

[CobaltWolf]

2 minutes ago, RoverDude said:

Oh, the difference (and the slippery slope) is going from 'Here's where to find stuff' to 'Here, let me give you my copy of a file that I grabbed without the modder's knowledge and may very well be out of date'.  Or, to bring this more in line with SpaceDock - I would hope (and expect) that they would not include mods on SpacePort unless a modder explicitly uploaded them to that service.  

Reason being, that if there's a distro floating around that I'm not aware of, it causes support headaches as I can't guarantee it is 100% in sync.  This is why I did not toss mods on KS until I had an automated way of doing this with the same automation tools that I use to publish my GitHub release - which makes my job easier, and guarantees I have no weird versions floating around.

So in short, and based on what I've heard since the original post, as long as SpaceDock stays in the 'upload stuff here if you want to share it' vs. the 'let's find everything to share and upload it ourselves' model (even if that latter case respects those of us who host our own CKAN metadata) then we're fine.  

If on the other hand, we as a community insist on putting tomatoes in our fruit salad, then you're going to see a lot of changed licenses.  Or, to spin it around, imagine how folks would feel if Curse started pulling all open-license mods and adding them there without the modder's knowledge just because the license said they (technically) could.

I'd change my license right quick. I have a fairly open license because I want people to be able to build off my work and create new things, or keep my mods updated if I were to disappear. I don't want my mods to be redistributed for the reason you listed - I don't want to worry about tracking down some bug just to find out it's because some older version of the mod was uploaded somewhere.

[JedTech]

1 minute ago, RoverDude said:

imagine how folks would feel if Curse started pulling all open-license mods and adding them there without the modder's knowledge just because the license said they (technically) could.

Not a bad idea, but I doubt Curse will ever care enough to give KSP that kind of attention. To be a popular mod source, Curse would need to be good at staying updated and indicating which version of KSP the mod is compatible with.

[Darth C3P0]

.

Here is the link to help remake it

Here is a mod backup archive (TORRENT)

You are welcome. These links were at the bottom of the KS page. It was a sad day for all...

Edited February 16, 2016 by Darth C3P0

[RoverDude]

2 minutes ago, JedTech said:

Not a bad idea, but I doubt Curse will ever care enough to give KSP that kind of attention. To be a popular mod source, Curse would need to be good at staying updated and indicating which version of KSP the mod is compatible with.

Kinda like how SpaceDock would have to be...

Given that any info SpaceDock has access to in a situation where the modder has no say-so is the same situation Curse would be in.  Works both ways, and both ways stink.

 

(edit)

tl;dr:  Multiple hosting and discoverability choices are good.  Making that choice for people either against their wishes or without their knowledge is bad.

Edited February 16, 2016 by RoverDude

[MarkusA380]

Thanks alot guys. I really appreciate your effort! Looking forward to using the new site!

(I swear I'm going to donate something!)

[MarkusA380]

1 hour ago, MajorLeaugeRocketScience said:

This is simply amazing. Less then 2 days after KerbalStuff shut down, we're already working (finishing?) up a replacement.

KSP community is the best.

Similar to rescuing some botanist guy from mars. Whole community standing together!

[Yemo]

5 minutes ago, RoverDude said:

Kinda like how SpaceDock would have to be...

Given that any info SpaceDock has access to in a situation where the modder has no say-so is the same situation Curse would be in.  Works both ways, and both ways stink.

 

(edit)

tl;dr:  Multiple hosting and discoverability choices are good.  Making that choice for people either against their wishes or without their knowledge is bad.

Since you have probably the most experience with your large mod catalogue: Would it make sense to be able to use spacedock as a (second, optional at the modders discretion) frontend for github releases? Especially the ability to display permanent (not part of the changelog like on the github page with the download button) graphics/diagrams right on the page with the "download" button could be interesting to minimize support requests regarding resource flows/contract progression and so on. Would that be feasible/worth it?

[oliverde8]

Hi, (my first post here)

I just wanted to say, there was a bandwidth issue for moders on anther game I played as well, it became very expensive to host the mods.

The solution that was found by the community was to create a community driven CDN : about.maniacdn.net

It might be something to think on,

Edited February 16, 2016 by oliverde8

[Manwith Noname]

1 hour ago, JedTech said:

Please don't go with Opt-In just because a few CKAN critics don't like CKAN. I truly think CKAN will fail if it follows this route.

It's not about being a critic of CKAN. Automatic ticking of options and opting in to features is never a good thing. It's like when you download a freeware program but it already ticks to install all that adware you don't really want. It's annoying and opt in avoids problems when people forget to check things thoroughly, plus it's easily corrected later if you realise you meant to do it but didn't.

[RoverDude]

28 minutes ago, Yemo said:

Since you have probably the most experience with your large mod catalogue: Would it make sense to be able to use spacedock as a (second, optional at the modders discretion) frontend for github releases? Especially the ability to display permanent (not part of the changelog like on the github page with the download button) graphics/diagrams right on the page with the "download" button could be interesting to minimize support requests regarding resource flows/contract progression and so on. Would that be feasible/worth it?

Not sure you even need a frontend to GitHub for that - it's just a release.  I'm confused, because the second part of your post sounds more like it references the GitHub Wiki instead?  And for that one I doubt there's an API available (and I would expect folks would want to only have documentation in one place - ideally one that has collaboration features ala GitHub, tho any wiki would do).

[MrHappyFace]

@RoverDude, I think @Yemo means that you could configure it so that SpaceDock would listen for new releases on github, and automatically re-upload the new release to SpaceDock, so you don't have to put in all of the settings and re-upload manually.

Edited February 16, 2016 by MrHappyFace

[RoverDude]

4 minutes ago, MrHappyFace said:

@RoverDude, I think @Yemo means that you could configure it so that SpaceDock would listen for new releases on github, and automatically re-upload the new release to SpaceDock, so you don't have to put in all of the settings and re-upload manually.

The problem with that is the same problem that CKAN has, which is polling cycle.  No biggie if it's an option (and by default off of course), but personally I prefer a push API - a lot easier that way, and updates are instantaneous.  And since I assume SpaceDock is going to reuse the KS one, that's a solved problem.

[jkortech]

24 minutes ago, RoverDude said:

The problem with that is the same problem that CKAN has, which is polling cycle.  No biggie if it's an option (and by default off of course), but personally I prefer a push API - a lot easier that way, and updates are instantaneous.  And since I assume SpaceDock is going to reuse the KS one, that's a solved problem.

GitHub has webhooks for release publishing.  SpaceDock could hook into that to pull updated releases over.

[DStaal]

The only way I'd see opt-out as being acceptable would be if there were big, scary, prominent warnings everywhere to the users that this was not an official distribution channel for mods, and that it was 120% clear that any problems users had installing mods through such a service would likely not receive any support, and that in the case of problems they should uninstall, then reinstall.

Given that CKAN wants to be an official distribution channel - or at least a trusted distribution channel - I don't think that's something that they want to be throwing in their users faces all the time, and therefore CKAN should stick to being polite and only distributing what they've been asked to distribute. 

(I do like the idea of Kwalitee-style checks for a version file and similar in the future - extra info provided to the mod users and makers is good.  But that's info provided alongside the mod, not as part of the mod.  It should be clear that such info/checks are from the site, not the mod's author.)

[RoverDude]

14 minutes ago, jkortech said:

GitHub has webhooks for release publishing.  SpaceDock could hook into that to pull updated releases over.

Still have the latency issue.  Fine as an option, but not something that should be turned on by default unless a modder decides the latency is worth dealing with vs. a publish script.

8 minutes ago, DStaal said:

The only way I'd see opt-out as being acceptable would be if there were big, scary, prominent warnings everywhere to the users that this was not an official distribution channel for mods, and that it was 120% clear that any problems users had installing mods through such a service would likely not receive any support, and that in the case of problems they should uninstall, then reinstall.

Given that CKAN wants to be an official distribution channel - or at least a trusted distribution channel - I don't think that's something that they want to be throwing in their users faces all the time, and therefore CKAN should stick to being polite and only distributing what they've been asked to distribute. 

(I do like the idea of Kwalitee-style checks for a version file and similar in the future - extra info provided to the mod users and makers is good.  But that's info provided alongside the mod, not as part of the mod.  It should be clear that such info/checks are from the site, not the mod's author.)

The only rub is that people don't heed warnings.  Hence, opt-in is the far better choice.  It would also be a good idea to learn from history... the last time this community had a 'discussion' over opt-in vs opt-out, lots of bad stuff went down, to no benefit.

Edited February 16, 2016 by RoverDude

[GreenWolf]

Isn't the whole opt-in vs opt-out disccusion made moot by the fact that the CKAN folks add things to netKAN anyways? It just takes a bit longer if the little tickbox isn't checked.

Or am I completely misunderstanding how netKAN indexes stuff?

[RoverDude]

1 minute ago, GreenWolf said:

Isn't the whole opt-in vs opt-out disccusion made moot by the fact that the CKAN folks add things to netKAN anyways? It just takes a bit longer if the little tickbox isn't checked.

Or am I completely misunderstanding how netKAN indexes stuff?

Well yeah you kinda have that   Which is it's own rather delicate topic.

But I believe the current context is whether or not CKAN (well, SpaceDock) should also get into the file distribution business using that same model (i.e. distribution without the modder's explicit and direct involvement and opting in)... which is a very bad idea.