Change to the "Mods" folder

[keybounce]

I want to suggest that the current behavior of the mods folder is a disaster and needs to be re-examined.

 

In the past, whether you stuffed stuff into a jar file, or used magic launcher, the basic rule of operation was the same: Stuff was only used in a given configuration of the game if you said "Use this in this configuration".

 

Adding a mod file to a directory containing your mods did not force it to be used all the time. You had to use a launcher to enable it, or a jar file patcher, etc.

 

Now, this wasn't the best or easiest way for users. Not everyone made their mods compatible with Magic Launcher. Some mods needed more stuff stuck into a config file or directory and expected users to unpack and much around. There was no real standard for how all this was set up.

 

With Forge 4, universal, I had to start using the Mods directory. Naturally, this meant that when I had trouble with Forge 4, and went back to 125, I had problems there. So a quick round of Magic Launcher, disabling mods, test, and "ps ax | grep java" gave me the answer:

 

-inactiveExtMods=Superior_Enchanting-132.zip;twilightforest-1.11.3.zip

 

That's a bad answer. And in seeing this, I realized why it's a bad answer.

 

You're not saying "I want to use this mod in this configuration".

You're saying "I want to use everything BUT this mod".

 

What this means is, if I have three or four configurations, then to add a mod to one, I have to go to every other one and disable it. If I replace a mod, I have to do an update dance. If I'm using different servers with different configs, I have an ongoing maintenance nightmare. Heck, just using different single player worlds with different configs becomes a nightmare.

 

Previously, in the thread where this whole issue bit me trying to get forge to work with repackaged mods, I had mentioned using a version specific mod directory. I still think that's a good idea -- so one directory for mods in this configuration, one directory for mods in that configuration, etc., instead of one directory for all mods in all configurations.

 

I still like that idea. I think it's easy enough to explain to users. Instead of multiple configurations for Magic Launcher, and having to deal with maintaining multiple lists, you have multiple directories, and it's either in or not in a directory. At startup, you just select which one you want to work with.

 

Now, that might be enough for mods where order either doesn't matter, or is specified by the mod. It's not good enough in general.

 

What I think would be better: I don't think the whole "order of install" will go away before the mod API is more developed. The whole "Use Magic Launcher" fails on servers -- ML cannot work with server jars. People do change the server and mod configs on their servers, people do connect to different servers, the whole 1.3 "easily share your world with a friend" system, etc.

 

First: Some sort of concept of "One directory for each config". For both server and client configs.

Second: Some sort of "Select these mods from a list", _standard_, for FML, where you can use order. And order is easy enough to explain to users: Number them. I've seen people try to use Magic Launcher from the assumption that the order they click on them is the order they will load (it's not). Magic Launcher doesn't show numbers in front of them, and from what I've seen, the presence of numbers is enough to express "order" for most people.

 

People are going to try to use mods that want to be in the jar, that don't bother with the forge API, at the same time as using forge API mods.

 

Saying "FML won't work with those" is arrogant.

Saying "FML has to read your zip files, even if the class files are loaded" is a disaster. Lex, I believe you've said that users are ignorant and cannot be educated. I disagree, and I feel that as producers of products for people to use, the computer industry as a whole has been a disaster. People will use their operating system to repack files. Telling them "Compress the class files, and stick that zip in your mods folder" is one thing; telling them "Oh, but if you use Apples, you're hopeless and we won't even attempt to work with you" -- and you wonder why users have trouble?

 

Up to 3.3.8, FML could read class files loaded via Magic Launcher, or in a server jar, just fine, even if those classes had been repacked with Apple's flat-fork leftover crud. 4.0 broke that. 4.0, to my surprise, wants to read the zip files even when used as a client from Magic Launcher, with Magic Launcher doing a merge. And while the view of "The Mods folder is there for a reason, use it" is good; the view of "You shall not modify my jar file" is good; that does not mean that all mods can be done that way.

 

===

 

I'm assuming that at this point, there is something either currently in FML, or going in soon, that permits mods to be distributed as a zip containing supplemental files. Take "Ruins" as an example -- it has inside it a resources directory, that is supposed to go into the mods folder, containing samples/templates of buildings to be made in the world. Or look at "Mumble Link" -- it has compiled binaries that are supposed to go inside the bin folder.

 

What these have in common: Right now, they have to be opened up and repackaged. Both have to be opened up, the subfolders and inner zip files moved here, or there; in the case of Mumble Link (written for RML, not FML) the insides contain a single mod_xxx.class file, a second .class file, and a directory of class files; along with a directory of natives. The instructions say "Add this to your jar file". The instructions for Magic Launcher say "Repackage all such problematic mods as a new zip file, and give that to me". All of this works just fine with RML.

 

And if the goal of FML is 100% compatibility with RML -- which you state on every page of this forum -- then you cannot just say "Your mac is useless", or "You're an ignorant user", or "You have to use the mod folder". RML does not require that. I do not have the ability to use RML for some mods, and FML for other mods -- the instant I need a forge mod I have to use FML for everything, even those mods that don't use forge.

 

And things that work with RML now break.

And the "single directory for all mods" fails to work with multiple configs.

And the whole "Use magic launcher" scales nicely for interior mods, but not for exterior mods.

And even that fails completely for servers.

 

 

[OvermindDL1]

A mod that does base edits, regardless of how it bootstraps itself, is not an ML mod.

[LexManos]

Wow that was a long winded post of ignorant statements.

You DO know that the 'Load everything in /mods/' is RML behavior right? It does the exact same thing as FML does, it takes a list of 'Dont load these' and skips them.

As for the whole mac/os issue, users are stupid, mac users are more so as they can not understand the difference between 'merge' and 'replace' and really, its a simple concept, I blame both the user, and the OS for this one. The fact that there issues has come up a few hundred times, been solved a few hundred times, and yet they can't seem to be bothered to search, is the main reason why I have disdain for mac users.

 

The mods folder is defined as a blacklist system. And that's not going to change.

The BETTER solution for you and your different configurations, is just to fucking use different minecraft folders.

That way you don't have to bother with all the hackery.

 

As for the mods that require you to extract them and put things in different places, why the fuck are you putting them in your mods folder? Every mod I have ever used that was like that has stated NOT to put the raw download in the mods folder but to follow the included instructions.

So.. we're supposed to cater to users who cant follow directions... right....

 

So, to sum up, use the mods folder how its designed to be used, not how you think it should be used.