Is "mod rec" really an umbrella category that we want to use? Or is it confusing the situation?

Question

This is a bit of a take on the discussion largely brought up by this question of last Fall, but to take a different approach to it. One might also gander at this oldie.

As an upfront note, any instance I use of "native" refers to the original game design, without any modifications.

Game-rec worked the way it did because it had a very specific entity that it embodied - acquiring new games to experience. Whether the goal was play, research, or what else, they all manifested in the same fashion. This is why we were able to really produce a general ruling on the class as a whole - it's straight forward and identifiable, we don't build repositories of games.

---

I do not believe that mod rec is so simple. I think it is, in fact, ambiguous and encompasses too much to manage in a single class - and making our rules based on this feels confusing and entangled. And this lies a bit in the fact that, as tzenes wisely pointed out, "mod" is itself ambiguous and refers to many classes of elements. The two most notable of which are "Standalone Game Mods" which are mods of a game distinct enough to be their own game (the original DotA, Parallel Worlds for LttP, etc.), and "Modifications to add elements to a game" that are things like, well, what a lot of people be doin' to Skyrim and Minecraft.

"mod rec" as applied to the former is, essentially, Game Rec - the Reckoning, the vile sequel meant to turn our innards to copper. Or, in less inane terminology, it is identical to asking for new games in exactly the same way that asking for new games is asking for new games. Because those mods are standalone games, and trying to build a repository of them falls under the same class we already dealt with. There's almost no questioning that it would be odd to permit these when we have a standing ban on game rec.

In the latter, though, "mod rec" is... actually diverse. Because the inquiries for it are variegated and contain a number of different types. It encompasses a much different problem space, which includes things like "subverting obstacles", "introducing new gameplay elements", "rebalancing the original game", and other such. There are a lot of different kinds of problems, and trying to group them all into one kind of category to apply a wide policy on is detrimental, in my opinion. It's a distraction in the same way that "list question" is a distraction to logical enforcement of the rules.

People should look at the core question, not to be confused with the motivation behind asking a question. "How can I land a successful hit with Real Impact?" is identical in core to "What combos exist that can lead into Real Impact?" - the core problem being how to connect with the attack. This same logic is something to apply when the core problem's solution space may consist partially or entirely of mods to a game.

"How do I Wavedash in Brawl?", "Can I make a functional cannon in Minecraft?", "How do I track when my cooldowns are up?", and many other kinds of core questions like these. They embody very isolated problem spaces, some of which do not exist in the game's native programming at all while others are more effectively done by mods, while yet others just offer a complete alternative option than the inherent options in the game.

Basically, in my eyes, trying to fit everything into one category of "mod rec" for judgment is like a subset of classifying our site as "solution rec", because that's what we do, people ask us for recommendations on how to solve a problem. It's the nature of that problem that defines whether we accept it or not, and there's a lot of different natures out there.

---

Some of the problem spaces that turn up where the phrase "mod rec" rears its ugly head would be:

• The aforementioned standalone game mod rec
• Problems that can entirely be solved natively, but which a mod might make it easier
• Problems that can entirely be solved natively, but which a mod provides an alternative or more direct approach
• Problems that can be solved exceptionally awkwardly when in the native game
• Problems that are not designed with the intention of being solved natively
• Problems that are designed explicitly that cannot be done (You can't get General Leo into your party)
• Accessing easter eggs (You might consider seeing John Romero as a better illustration)
• Wrench Tennis and other elements not intentionally designed in a wieldy way
• Problems involving the lack of English in Simon's Quest
• Problems involving altering the experience of gameplay as a whole
• Problems involving simulating a different game experience than is natively intended, whether or not it is natively possible
• Problems regarding the apparent design of the game and the means to get around its shortcomings or obstacles

There's a lot more but I hope the diversity can be seen here.

To that end, I ask that we don't think "Do we want to allow people to ask about mods?", but rather start to think about questions on these cores. Do we want to allow questions about problems that the game deliberately doesn't want you to address? Are mod-based problem spaces fundamentally identical to glitch-based problem spaces? Do we want to allow questions about altering the native game experience? Are alternatives to a game's native design appreciated? Those kind of thoughts, I think, are more useful to identifying what we should or should not allow than trying to group it all in one umbrella that not only masks what possible issues and natures are present, but also conflates the entire thing with an ultimately unrelated issue.

Answer 1

I've written extensively on this subject (mostly here and in comments therein). I'll provide my still-too-long tl;dr version:

Closing is our go-to solution for too many things.

"I want to find a way to like this game more" or "what is the most fun total conversion mod for (game)" is a bad problem for our site, just like "I want to find a game I will like." It's game-rec, and it's not constructive, and I think we should close and delete questions like this. Thumbs up, 100%, let's go, close close close.

"I want to do this ridiculous thing in a game and it was clearly not intended for me to do it" can sometimes be a stupid question, and deserving of downvotes. "How do I get a magical pony in black ops 2 multiplayer because I love magical ponies" is a stupid question, and deserves downvotes. If a simple google search or 10 minutes playing the game tells you "no, this isn't possible" - it's a poorly researched, dumb question - downvote it and move on. It may have other issues (it falls into not constructive or NARQ, etc) that cause it to get closed, too, but dumb (in and of itself) is not a close reason. Closing is not punitive so much as downvoting is.

Question class bans are made far too easily sometimes, and they tend to stretch to encompass not only the things they were explicitly designed for, but onto related areas, or even just expanding to cover things that sound similar but aren't really.

On our site, these questions take a form where a mod is generally a solution to a problem. Judge questions by the problem being posed instead of the presupposed answer.

"I want to solve this concrete problem" is a good question for this site, with or without "using a mod" at the end.

Knee-jerking on a question based on language is problematic. "I want to like this game more, but the stage 4 boss is too hard. I saw a youtube video where a guy used a mod to win. Can anyone recommend a mod (or identify the one in the video) to make the stage 4 boss easier?" is a misguided question that uses some misleading language, but the core problem is still okay.

Sure, there might be a "make the stage 4 boss easier mod" out there, but there also might be a game setting (go to easy mode) a console command (boss.kill), a strategy (just use the lazer cannon and he goes down in one shot), level skip cheat, etc. The core problem is "I can't beat this boss, help!" and that's OK. I've answered many questions (and seen others do the same) by patiently explaining why the answer already jumped to in the question is wrong or non-optimal.

Mods, config files, maps, ini files, controller layouts, etc are all solutions to problems. They don't automatically make a question good or bad for being mentioned in it, or for being the only way to solve a given question. Similarly, their mention doesn't make a bad question good. Disconnect the two, and look past the word choices and presupposed answers.

Recommending solutions from a large number of possibilities is the core of a wide swath of questions.

People suggest multiple answers to questions frequently. They vote on this site and others, on a wide variety of answers where there are multiple valid solutions. To me, that's part of the core of the SE network. The asker gets a "super vote" in the form of accept, which says "this is what worked best for me."

For many problems, multiple valid solutions exist, and the community votes to determine which one they feel is "best." Best should be somewhat dictated by the question - good questions should provide an axis for judging a solution - but it's also dictated by the will of the community and whatever they happen to prefer. We might all be mod-happy this week, or console-happy next week.

Answer 2

Very well then. Let's ignore for a second the implied argument that you can't just take the same slicing and dicing Grace used on mod-rec and use it on game-rec. Let's instead review the list of issues that got us to our game-rec ban and see what still applies to mod-rec, shall we?

Main issues with game-rec, see here for the full story:

• Motivation for Quality. Game recommendation questions ask for repositories, a.k.a. curated lists of things. We have shown to do a terrible job at this. We only reply with those things that are hot and popular here and now and we don't go back and update them when newer things come out.
  • Deduplication. Game recommendation questions, just like identify this X questions, are heavily focused on what the asker wants. This makes handling duplicates quite difficult.
  • Accepted answer. What does it mean for an answer to be accepted in a game-rec question? Not much, really.
• Values dissonance. Voting on these posts isn't based on the quality of an answer towards the goal of the asker, but on the popularity of a given item.
  • Items vs answers. If voting on a single items is based on popularity, should you answer with a list instead? Do we want list of repository questions?

Let's now see how Grace's suggested categorization works against those core issues, and just how much of the "game-rec" issues (that we have accepted to be absolutely incompatible with the rest of the engine - deal breakers, if you will) also extend to them.

(Ignore the "why did they do it this way" category, that's actually a whole different can of worms.)

Columns map rather obviously to the entries above, excluding for an additional column I named 'Is actually a "mod-rec"'. I don't believe we've actually ever called some of these problem types mod-rec questions to begin with. This might just be me being confused with Grace's taxonomy, however. Hopefully this column will shed light on the fact.

So, at any rate, I think we can neatly bunch these questions up in three nice groups:

1. "You can, natively."
2. "You can, natively. You can alternatively use mods." (The line with the kinda's)
3. "You can't, natively. You must use mods."

When you can do something directly, natively, properly, the fact that you can also use mods is rather incidental and you would be actually rather hard pressed for bringing out a mod as a "solution" to begin with. This is why I didn't mark them as "actually a mod-rec."

When you can't do something natively, then there either are some mods that address this or there aren't. There's typically more than one mod per problem, some of those are more fashionable than others, some of those are maintained better than others, some of those don't have one "homepage" and the "thread link" will change at every new game release, you don't know if you should put all the mods you know about in one list (because real questions have answers, not items) or one per answer (to avoid having multiple answers with partially overlapping lists).

These questions are those we've been calling "mod-rec." They share the same problems with game-rec, regardless of whether or not there is a practical problem behind these questions; a goal towards with we can sort the answers in metrics of fitness. We should treat these questions just like we treat game-rec, and for the purpose of this post we've already accepted that this means "unsalvageable: always close".

Finally there's the mixed animal that's #2. You can do it ingame, or you can do it through mods. Think "How to mine stone most efficiently in Minecraft?". You can craft a diamond pick and enchant it, or you abuse the hell out of Equivalent Exchange or build quarries or, well, not mine it at all and use either explosives or creative mode/give cheats if you only care about removing stone or having a bunch of cobblestone for building.

This is both a repository (because there's going to be many mods that allow you to mine in Minecraft) and not a repository (because there's only so many in-game native ways and those aren't quite as subject to maintenance).

---

One possible, simple solution is to always answer with the native methods and always comment with the mod solutions. If there is no native way to do something, say so and make that your answer. There is value in saying that something cannot be done, and there is politeness and/or in suggesting one popular mod that you can use today to work around the issue. As GLaDOS would say, killing you and giving you good advice aren't mutually exclusive.

In addition, close questions that are obviously looking for repositories of mods, or what we've been calling mod-rec. If you can change it into a question looking for a native answer, good, but then we can't go around and make a mod repository anyway. That's just asking askers to jump through a meaningless hoop; it's basically insulting their intelligence.

Answer 3

I agree with fbueckert's comment. "Is there a mod that does X?" can't be answered with "No" unless you're omniscient. Similarly, "How can I do X?" can't be answered with "You can't" if mods are valid answers, given that a mod could theoretically alter the gameplay in any way you think of. Both amount to an unbounded search that may or may not end happily if someone knows of or finds an appropriate mod.

I think the kind of questions we want are the ones where the asker knows that X can be done but there is some issue in doing so. Examples:

Mod X is supposed to let me do Y, but I nothing happens when I try it. What am I doing wrong?

I rebound the key for X to 'Y' and now it doesn't work. How can I use 'Y' for X?

How can I beat this boss?

Answers might recommend or otherwise involve mods, or discuss built-in features, suggest strategies or alternatives, or whatever. At the end of the day you're solving a clear and bounded problem, and not doing someone's shopping for them.

I don't think we should host questions about every potential feature that someone has dreamt up and now wants. Questions should be about things that exist. To me, this follows directly from the "What kind of questions should I not ask here?" section of the FAQ:

You should only ask practical, answerable questions based on actual problems that you face

[...]

[A]void asking subjective questions where ... we are being asked an open-ended, hypothetical question: “What if ______ happened?”