Modpacks, should they be banned?

[Gaarst]

2 minutes ago, linuxgurugamer said:

Understood, but what if a mod author wants to make his own modpack, for whatever reason?  Maybe I'm being too picky here???

I understand that the author could claim the separate mods as his own but not the whole pack in a sense that another user couldn't be forbidden to build the same modpack, or at least a modpack containing the same add-ons (with possible added content), as long as it does not violate any other rule.

Edited March 7, 2017 by Gaarst

[Guest]

12 minutes ago, sal_vager said:

Pack.

An archive (zip, rar etc) containing multiple add-ons other than those of the submitter, which can be replaced with a list of contents, links to original works, or automated installer script to create the same end result.

Or to which any changes:

• Can be removed and the pack remains viable.
• Are insufficient to create a new derivative work.

I'm curious how this applies to Realism Overhaul (for instance) being bundled. Please explain your thoughts if you don't mind, because RO can be removed from the mods themselves and the pack remain viable while definitely creating a new derivative work.

Quote

• Are suspected to exist in an attempt to bypass this definition.

The old "Are you being a jerk?" test, eh?

Quote

Most of this is the same but it expressly permits what @SolidJuho is doing, while allowing moderators to remove anything less without having to waste time or bandwidth.

I don't see any rules pertaining to mod packs in particular save for the single rule under licensing.

This seems pretty reasonable otherwise.

[sal_vager]

6 minutes ago, regex said:

I'm curious how this applies to Realism Overhaul (for instance) being bundled. Please explain your thoughts if you don't mind, because RO can be removed from the mods themselves and the pack remain viable while definitely creating a new derivative work.

The rule is not retroactive, and the changes made to RO are significant, RO would not be affected.

6 minutes ago, regex said:

The old "Are you being a jerk?" test, eh?

Best kind!

6 minutes ago, regex said:

I don't see any rules pertaining to mod packs in particular save for the single rule under licensing.

The more addons in a pack, the more work the packer must endure, failure to do so results in removal and further action if it persists.

Having all licenses means that packs will still have those licenses even if the packer disappears, I may also add that links to the original works must also be provided.

6 minutes ago, regex said:

This seems pretty reasonable otherwise.

Phew.

 

Edit:

Also, generic addon install instructions and how to get help will be a new sticky thread.

[linuxgurugamer]

7 minutes ago, sal_vager said:

Well, naughty you, this rule has been in the addon rules for a very long time, since the time they were first posted actually and was introduced to prevent dodgy plugins from putting files in odd locations

Well, I asked for permission first, because I was aware of the rule and of what I wanted it to do.  May even have been you :-) who replied, but that was back on the old forum, I can't find the email.

Tell me if you want me to remove them or change the functionality

 

[Guest]

3 minutes ago, sal_vager said:

The rule is not retroactive, and the changes made to RO are significant, RO would not be affected.

RO wouldn't be affected anyway because it doesn't bundle, I'm talking about the hypothetical of it actually bundling (I can assure you that it, in all actuality, probably won't but it is a good thought exercise to test your rules on).

The only thing I would suggest, and this may seem pretty odious but I'm going to do it anyway as a former modder, is that all included mods, their authors, and their licensing be listed in the OP of the pack outside of spoiler tags.

Edited March 7, 2017 by regex

[sal_vager]

7 minutes ago, linuxgurugamer said:

Tell me if you want me to remove them or change the functionality

I'll have to review it, and whether that rule is correctly worded, btw it means mods you install in KSP, not programs that are externally run, I forget which yours is.

6 minutes ago, regex said:

is that all included mods, their authors, and their licensing be listed in the OP of the pack outside of spoiler tags.

This seems fine, but why without the spoiler?

Edit:

It's now "Add-ons or packs must document all add-ons, plugins and dependencies they contain, including their authors and links to the original work, in the download and in the download location."

[linuxgurugamer]

4 minutes ago, sal_vager said:

I'll have to review it, and whether that rule is correctly worded, btw it means mods you install in KSP, not programs that are externally run, I forget which yours is.

This seems fine, but why without the spoiler?

I'll PM you the links

[Guest]

11 minutes ago, sal_vager said:

This seems fine, but why without the spoiler?

Someone packaging a mod is taking credit for that mod, in a sense; the content they are using should be prominently displayed and not hidden within spoiler tags despite any arguments of brevity because I believe it obscures the creator of the content. This is purely my opinion as a former modder and I would never allow someone to repackage one of my mods (not that my former mods deserve to be packaged anyway) without that clause.

E: It's a vanity thing. And while I am very permissive with my licensing and ensuring that my mods live on, I am also vain. Even the current derivative of my old Minecraft mod still references my OP from, well, whenever I made it, prominently. E2: Not sure about any packs that use it, but I'm not in the loop anymore so...

Edited March 7, 2017 by regex

[sal_vager]

"No spoilers" might be a little too picky, modpacks can be really large.

[Deddly]

5 minutes ago, sal_vager said:

"No spoilers" might be a little too picky, modpacks can be really large.

If I'm downloading a mod pack, shouldn't I know what's inside?

[sal_vager]

6 minutes ago, Deddly said:

If I'm downloading a mod pack, shouldn't I know what's inside?

Yes that's why the full list with authors names, urls and licenses must be in the OP and in the pack.

Edit:

Note to self, find less lazy moderators...

[monstah]

38 minutes ago, sal_vager said:

I believe modders already do this, so no extra work for them.

This is a new point, however:

39 minutes ago, Diazo said:

2a) A mod can not support a newer version of KSP then all the bundled mods do.

Change "mod" to "mod or pack" and I think it has merit to it: many times, a new KSP version comes out, and some mods mostly work just fine, but with quirks. People play with the mods just fine, but sometimes it will behave very unpredictably (KER comes to mind). For all purposes, the mod is compatible with the latest KSP, but officially it's still for an older version since the modder can't guarantee it'll work as advertised under all conditions, in the latest version. And that is a safeguard the modder has against requests for support that he/she isn't able to provide.

But, it's very easy for these mods to be bundled without such notices, and this probably adds to the grief that mod packs cause modders. If, however, the mod pack is required to state what version it's for, and if that version must be at most the lowest of the versions supported by the mods, I think they have at least part of that safeguard back.

Oh, look, there's a whole new page of the thread I wasn't aware of. 

[sal_vager]

Something to avoid though is making more work for the modders, ideally the common practices amongst modders would continue, such as KSP version numbers in the thread titles, without forcing these things.

[DStaal]

19 minutes ago, monstah said:

This is a new point, however:

Change "mod" to "mod or pack" and I think it has merit to it: many times, a new KSP version comes out, and some mods mostly work just fine, but with quirks. People play with the mods just fine, but sometimes it will behave very unpredictably (KER comes to mind). For all purposes, the mod is compatible with the latest KSP, but officially it's still for an older version since the modder can't guarantee it'll work as advertised under all conditions, in the latest version. And that is a safeguard the modder has against requests for support that he/she isn't able to provide.

But, it's very easy for these mods to be bundled without such notices, and this probably adds to the grief that mod packs cause modders. If, however, the mod pack is required to state what version it's for, and if that version must be at most the lowest of the versions supported by the mods, I think they have at least part of that safeguard back.

Oh, look, there's a whole new page of the thread I wasn't aware of. 

I actually find myself disagreeing with this one.  One of the best uses for modpacks in KSP would be to bundle up a couple of old (abandoned) parts packs that allow redistribution but not modification with some patches that bring the parts into compatibility with current versions of KSP.  (So the part mod is bundled unmodified, satisfying it's license, and the new mod which is a set of patches against that mod.) Then the mod pack would be supporting a version of KSP newer that the original mods that it includes.

[monstah]

Just now, DStaal said:

I actually find myself disagreeing with this one.  One of the best uses for modpacks in KSP would be to bundle up a couple of old (abandoned) parts packs that allow redistribution but not modification with some patches that bring the parts into compatibility with current versions of KSP.  (So the part mod is bundled unmodified, satisfying it's license, and the new mod which is a set of patches against that mod.) Then the mod pack would be supporting a version of KSP newer that the original mods that it includes.

It seems to me that patches that bring unsupported mods up to speed would be considered derived work, and not merely packs. I'm talking about when a user is simply repackaging a mod that only supports and old version of KSP, then the pack only supports at most that version, too.

[DStaal]

1 minute ago, monstah said:

It seems to me that patches that bring unsupported mods up to speed would be considered derived work, and not merely packs. I'm talking about when a user is simply repackaging a mod that only supports and old version of KSP, then the pack only supports at most that version, too.

Even then, if the user can say that 'I have specifically tested these old mods in KSP version X and attest that they work', I can see value in allowing the mod pack to support more recent KSP versions than the individual mods are rated for - especially for some parts packs, where the author may not bother to update if the pack still works.

The presumption should be that it *doesn't* work unless the packer has verified it, but making the assumption of a good repacker who is actually adding value and doing their homework, having a mod pack that supports newer versions of KSP than the mods they repack would seem to be not uncommon, given the way mods work in KSP.

[sal_vager]

I don't think there's anything to be gained by saying modpack X is for version N only, it may still work, but it would be important for users to know the versions of the mods inside it.

[magico13]

31 minutes ago, monstah said:

 if that version must be at most the lowest of the versions supported by the mods, I think they have at least part of that safeguard back.

Your concern is that outdated mods don't work in newer versions of KSP, but I present a counter concern of newer mods don't work in older versions of KSP. I'm fine with the pack having an intended version that is publicly visible.

I am also fine with the mod list being in spoiler tags just so the OP isn't huge. It's still publicly visible and credited.

Can we be explicit in what is required in the document that is included with the pack, and maybe require that the document is in the root of the archive (or one folder down if the root is just a single named folder other than GameData, like "My Awesome Pack").

[Guest]

16 minutes ago, magico13 said:

Can we be explicit in what is required in the document that is included with the pack, and maybe require that the document is in the root of the archive (or one folder down if the root is just a single named folder other than GameData, like "My Awesome Pack").

Why couldn't you be? It's your content, you set the terms of its use, that hasn't changed.

[linuxgurugamer]

31 minutes ago, monstah said:

It seems to me that patches that bring unsupported mods up to speed would be considered derived work, and not merely packs. I'm talking about when a user is simply repackaging a mod that only supports and old version of KSP, then the pack only supports at most that version, too.

I agree about it being a derived work.  One mod I support is EVA Handrails. The author is gone, the license is restrictive.  I include the original along with a MM patch that updates it to make it compatible with the current version.  It's not a pack, because it's a single mod, with a MM patch, and I release it together as a "Continued" version

52 minutes ago, sal_vager said:

Something to avoid though is making more work for the modders, ideally the common practices amongst modders would continue, such as KSP version numbers in the thread titles, without forcing these things.

As a slight aside, while most modders do put the KSP version numbers in the thread titles, what do you think about making that a requirement, or at least a strong suggestion?

[sal_vager]

8 minutes ago, linuxgurugamer said:

what do you think about making that a requirement

I think I already did.

[magico13]

23 minutes ago, regex said:

Why couldn't you be? It's your content, you set the terms of its use, that hasn't changed.

Sorry, I meant "can we" as in "can the moderators/the rule" be explicit in what is required in the document. Section 3A in the WIP rules is pretty explicit already, so my concern is unfounded. I just want to make sure it's clear what is required, and that what is required is sufficient with regards to attribution and ability to find the correct mod and version.

 

E: I see though that you're saying that mod authors could amend 3A to include additional provisions when including their mod in a mod pack. I agree with that idea.

 

E2: I just had another thought and don't want to double post.

While having an open license that allows redistribution doesn't prevent the modder from having their mod redistributed (for obvious reasons), it doesn't imply that the modder must provide support. That's something modders provide for free and is often explicitly indicated in the license that no support is required to be given. I'm just thinking out loud about whether modders can (and the associated "whether they will") detect if their mod was installed with a mod pack and refuse to support users of that pack. Frankly, from an informational support perspective it would just be nice to see if they installed it through a mod pack so that I can see if that pack is somehow causing extra problems.

But I think back to the mods that were created to stop certain functions of other mods, or authors refusing to support their mod if it was installed with CKAN (the first is questionable, the latter is definitely within their right as they can refuse support for any reason) and I worry about another divide where even though something is technically permitted, if it's unwanted then people will develop means to fight it. I am on the fence as to whether I like the idea of mods detecting if they're installed in a pack (perhaps by checking that document that we're requiring), whether the rules should explicitly require that document to exist in the install in a specific spot to make it a well defined process for modders to check this, or if we should somehow discourage preferential treatment by how the mod is installed.

Maybe a good solution is that the rules for reporting a bug include reporting 1) if the mod was installed through a pack, 2) if from a pack, include the name and version of the pack, and optionally 3) a link to where the pack is hosted (the forum thread if hosted here). Of course mod authors could require this even if it's not part of the general bug reporting guidelines since, like previously mentioned, support is at our discretion. The only problem is that most people don't follow those guidelines (or even read them) and any additional guidelines mentioned in a mod's OP are ignored even more often.

Personally, if my mod is added to a pack and starts getting more support requests I likely would start checking for that file just for my own data collection purposes.

Edited March 7, 2017 by magico13

[Poodmund]

32 minutes ago, linuxgurugamer said:

As a slight aside, while most modders do put the KSP version numbers in the thread titles, what do you think about making that a requirement, or at least a strong suggestion?

23 minutes ago, sal_vager said:

I think I already did.

This has been brought up previously but it would be nice to get some standardized (required?) way of presenting thread titles for organization and structure, however, getting thread creators to follow these guidelines would be quite the task.

... but the conversation digresses.  

[sal_vager]

Starting to get into the "too much work for modder" territory.

But I guess for lists of included dependencies/add-ons it'd be like this.

Spoiler

Add-on title, author, license, version, link

 

[nascarlaser1]

before I post my opinion, what is a modpack?