Okay im going to start off this thread with a copy-paste from what i started over in the discord...

PhanjamYesterday at 5:25 PM
dont know if anyone noticed but i asked Potterman over in the Runic discord if he wanted to pursue his "1 project to rule them all" idea (http://torchmodders.com/forums/help-wanted/one-common-project-(to-rule-them-all-)/msg7016/#msg7016)
altho he said he couldnt get into that atm, it got me to thinking...

I look at @Viz 's Variant Classes and @Korzeam 's Variant Pets.  Then i look at projects like @Wolven 🐺 's TL2 Refreshed, or F430's Expanded End Game Content mod, all of @doudley 's great UI mods, or even my idea for a mega-merge of items+author-vendors.

And im thinking the Variants "concept" works well and maybe we should use it when we plan our mods.  How does this relate to Potterman's "one proejct" idea?  Well i think "one project" will never work actually but many "variants" might work pretty well (and i was going to suggest this to Potteman)

My idea of expanding the Variants concept is we should have fairly fixed mod "groups" so like...

1. Classes (already have that with Variant Classes)
2. Pets (already have that with Variant Pets)
3. UI (we have tons of those thanks to @doudley lol)
4. Items (biggest ones I know of are RnF's LAO series)

How does mod grouping help?

well like theres one mod type which always, always has conflicts and thats UI mods. RnF's LAO has a UI component, most of doudley's mods are UI mods, Wolvens Refreshed mod has some UI components, etc, etc

so maybe when we make our mods we say "im making an item mod. it would be great if the UI could be (whatever) so i can make a new item unittype. so i'm gonna tell the guys working on Variants UI to put this feature into their mod.  see where im going wth this?

meanwhile over at the Variants UI mod, theyre making the fricking-bestest-ever UI mod that ever was. Has all the features everyone always wants so you dont have to mix-match UI mods and trial-and-error what load order is best for them.  Just use Variants UI and youre gold

and then Variant Items you could go just bat-sh*t crazy here - there are so many items out there but they rarely conflict right? its in their nature - as long as you do the GUIDs and NAMEs thing, your DAT files are always going to be unique!
would love to hear what you guys think

GoblinYesterday at 6:46 PM
Can we have a Variant gamefixes mod also, fixing alot of things in the game not covered by the other mods like armour /hp but wont conflict with the others. Maybe a variant maps also.

PhanjamYesterday at 6:48 PM
ah smaller "qol" mods - absolutley
and maps - i see how that would be excellent, but i dont know enough about levels/maps to appreciate the conflicts issues. but yes, if it can be done that would be really great

GoblinYesterday at 6:49 PM
Well the mappers would be in charge of that, making picking mods really easy for everyone else.
Should be virtually no conflicts done this way.

VizYesterday at 8:16 PM
the fixes should be covered by UA
unless there's some bugs that UA didn't cover
maps sounds like a good idea..

PhanjamYesterday at 10:24 PM
I am curious why TL Essentials is so popular. I think we can "make a better TLE".  Not better because of whats inside, but better because we can solve compatibility issues

VizToday at 12:34 AM
the name being essential certainly helps
and being one of the earliest compilation mods around

steffireToday at 3:36 AM
Truth is that now we have a "one project" hive mind (I mean that in a very good way) where as before when people were transitioning from TL1 to 2 it was more of every one figure out how to use this thing called Guts... "oh you figured out something? cool!". Today we mapped years of advice towards bug fixes, impossible edits, probable work zones to push the frontier of what we can do in TL2 modding. It's more clear today what needs to be worked on and who gets agreed to produce such mod. Good times!

I love this idea, but a few key questions come to mind. Nothing that too much of a problem, but I think we'd need to make sure we clarify before we start so we don't spend the whole time arguing!

How do we decide what content does and doesn't "make the cut"? ie what level of polish is considered acceptable?

Also how do we deem whether something is useful/useless? ie meets the critera of the mod?

Do we need to consider making sure that we "spread around" the mod contributions to reflect the community or just stick to a small handful of modder friends?

How do we chose between mods that are very similar or serve the same function?
 
Who makes the final decision? Is it a vote? Do we have an all powerful director who calls the shots?

I love this idea, but a few key questions come to mind. Nothing that too much of a problem, but I think we'd need to make sure we clarify before we start so we don't spend the whole time arguing!

How do we decide what content does and doesn't "make the cut"? ie what level of polish is considered acceptable?

Also how do we deem whether something is useful/useless? ie meets the critera of the mod?

Do we need to consider making sure that we "spread around" the mod contributions to reflect the community or just stick to a small handful of modder friends?

How do we chose between mods that are very similar or serve the same function?
 
Who makes the final decision? Is it a vote? Do we have an all powerful director who calls the shots?

These are good points. Making something like this requires an organized group of collaborators where participants have roles relative to their skills. It also requires "management" and an overall vision and design idea. It would have to function much like a game developer studio, where you have your lead game (mod) designer(s) mappers, UI designers, character designers, graphics designers, etc. All working towards a unified goal and design idea.

Again, I'm not sure I understand the idea correctly. Is the idea to create "yet another mod pack" where you take existing mods and wrap them up together in a non conflicting package. Or is the idea to create a new big mod, which incorporates ideas and designs from existing mods?

Okay so with the inputs from the original posts, that idea of "mod groups" is looking like...

1. UI
2. QoL
3. Items
4. Levels, Quests
5. Classes
6. Pets

I agree with @Phanjam to make it into "mod groups". Because we can only use 10 Mods. That way, will be more focused.

Maybe it can be started by making "Variant Item Mod", so it will ease the work in the future.
Because there is a lots of items (Weapons, Armors, etc.) are still separated. It would be good if all of that could be combined with no conflict.

Maybe it can be started by taking items in large Mods such as Torchlight II Essential (because he already combined several Mod Items in it), Synergies, FEP, LAO 2-3, Ruination, Noddyngineering, etc.

And keep in mind that Variant class & pet Mod can still be developed more further. I hope it can be even better in the future.

Just in case any of you might be interested, I thought I would post the results of my Github repository experiments. 

• TL data files (DAT, LAYOUT, and ANIMATION extensions) must be formatted in UTF-16LE (the default Unicode text format on Windows) for GUTS to properly read them.  Otherwise, the program spits out an error dialog for every improperly-encoded file.
• Git (and by extension, Github) is incapable of parsing text data more complex than UTF-8.  This means that all TL data files are interpreted as "binary" files in Git-based diffs (such as those used by the Github website).  Needless to say, such Github diffs are effectively meaningless.
• The method described in [
  How to make git consider .strings files as text file instead of binary file - Stack Overflow

  Stack Overflow · stackoverflow.com
  ], does not affect Github diffs for the relevant files.  They are still displayed as "binary" files.
• The method described in [
  diff - git gui - can it be made to display UTF-16? - Stack Overflow

  Stack Overflow · stackoverflow.com
  ]—which converts the relevant files to UTF-8 when uploading, and to UTF-16 when downloading—does work, but it requires significant client-side preparation to be able to download usable files from the repository, as well as upload them.  Note that Github's "download as ZIP" option, also results in a MEDIA directory full of unusable UTF-8 files.
• To mitigate the client-side difficulties in Point 4, I had experimented with trying to write a Windows batch-script to perform a 1-click conversion of all relevant text-files to UTF-16.  I can confirm that the "iconv" tool does not work in the Windows batch method.  Unfortunately, my computer completely failed while I was trying to find a working alternative.

I am reading everyone's replies and they're making me happy I think the feeling is mostly positive and that it's somehow an "important" project.

But even if it's important, the last thing i want is that it will become "not fun" for us to make it! I know everyone has so little time for modding and we do this for the fun of creating and the love of the game, so no way should this project become a burden!

My suggestion is that we:

1. Decide the mod groupings. I'll make the forums/sub-forums to have more organized discussions about...

2. agreeing the main features for each mod-group; the "must have" features almost everyone looks for plus new stuff we might think of;

3. once we agree the features, we write it down as something we all think is the "best balanced design" for that mod-group;

4. Then each of us, according to the time we have and whether something interests us, can contribute in any group.

This is just my idea so that no one "has to" own, or be the leader of, any group. Whoever is the most active in that group is the "natural leader" at that time. And if that person has to go away for a while, the work can still continue because we already wrote down and agreed the "most balanced design".

Also remember this is still mod-merging work, so many of the ideas we agree already exist in other mods. But how we "add value" is in eliminating conflicts or finding ways to make 2 or more features work together which have never worked together before and of course adding new stuff which make the mod-group even more useful/fun.

@Aherin to anwer your question about "how" we decide what to include in the merging, I think we need to go "below" the level of mods and be driven by the features that we're after. If we want a feature and it was first made by modder "X" in his "ABC" mod, then we should say so in our credits.  So okay, what features then? Well let's talk about those in the mod-groups.

What do you all think?

(my next post will be about the groupings - i'm thinking "difficulty mods" need to be handled differently / may not fit our OneProject concept...)

@Sch123 : Your scouting and gathering mod info skill is the best among us. Could you continue to generate more lists of unique functioning Weapons for the mod of Ruination?

Sure, I'm happy if I can help even if it's just a little.

For Modders : Consider this mod which could hopefully be fixed (arrows miss targets when shot from slopes and cliffs) and ready to use for battle in game:
https://steamcommunity.com/sharedfiles/filedetails/?id=518311085&searchtext=arrow

@steffire3 : Maybe you can try Classless Character Mod, because in Rogue the skill "Immolation Ammo" seems to use the same idea as you meant. It's just that this is inserted into the skill not as a normal attack on a weapon. Maybe this could be used as an initial idea to make the arrows look real.