Multiple issues with local libraries and optifine

[zomabies]

Instead of relying on implicit behavior that is changed on commit 17e09a2,
consider adding option to "MMC-hint" to explicitly load from the global libraries.

[peterix]

And why is that a good idea?

From my point of view, the use of something like this reduces quality of instances, leads to the libraries structure containing random non-replicable/untracked files and essentially doesn't provide anything of value.

[zomabies]

Good point actually, the principle of self contained instance will not be exists if those libraries are scattered around.

Why is it a good idea?

The ability to de-dupe file(s), having a single location rather than scattered around instances.

Is introducing $mmcRoot/instances/libraries/ folder so that it won't mess with the "global" libraries but accessible to all instances a viable option?

---

The same issue can be apply to per-instance libraries (random non-replicable/untracked files)

Currently, local instance does not follow maven structure, per-instance library will become messy if there is a lot of files.
Is there a way for per-instance libraries to follow directory structure like in global libraries?

[peterix]

I am not interested in following the maven structure. It is very anti-user, and stupidly hard to work with if you need to monitor the whole maven tree for unmanaged changes.

I don't think sharing or deduplicating anything that cannot be trivially recovered by downloading from remote repositories is ever a good idea. A local library, by definition, is not recoverable. It has no source. It is a unique artifact.

The user can -- and will -- mess with the files directly. When they do, they will be left with broken instances and/or dead leftover files. The policies I enforce in MultiMC are there to prevent accidents. Think of it as the guard rail on top of a deep ravine. I see this as the equivalent of you asking for the removal of that.

Storage is cheap, and is getting cheaper every year. Duplication is the only way to preserve data in a noisy and chaotic environment. I wish people would repost all the mods ever on all the websites. That way, we would still have some of the older ones and could play them.

I don't see any benefit to using the maven directory tree at all, aside from it being a java developer convention. Techically, it does not make sense. Usability-wise, it's a disaster.

Considering the above, is there any other reason for this?

[peterix]

TL;DR: why do you actually want this? How does it benefit the user in any way?

[zomabies]

Agreed on what you have said and I think is it not a good idea anyway.

For user that wants pseudo global like library, host your own "server" and point the artifact towards it on the patches (it will be less hacky in my opinion).

EDIT: Since this change is intended, it is possible to fail-fast instead of only logging it $instance/libraries/<mod-library-name>.jar (missing) because some very old instances patches rely on this implicit behavior unknowingly.

[peterix]

I'd really like to know why you need this.

[peterix]

So, I have this feeling that you came here with a problem, and a solution. You described the solution you would like to have, but never described the problem.

I suspect you are doing something like this:
https://v1.meta.multimc.org/net.minecraftforge/14.23.5.2783.json

Is that true?

Please describe what you are doing, and why are you doing it. There could be better ways of achieving whatever goal you have.

[peterix]

Since this change is intended, it is possible to fail-fast instead of only logging it $instance/libraries/.jar (missing) because some very old instances patches rely on this implicit behavior unknowingly.

Hmmm.... where do those come from? It's possible I missed something and they need to be auto-migrated.

Can you show me an example?

[zomabies]

I suspect you are doing something like this:
https://v1.meta.multimc.org/net.minecraftforge/14.23.5.2783.json

Is that true?

Sort of.
Here's the use case: Replacing Netty version (MC 1.12.x)

Reason:

https://github.com/PaperMC/Paper/issues/895
https://bugs.mojang.com/browse/MC-118372
https://bugs.mojang.com/browse/MC-120362
(there isn't the need to create reference on their side)

Before:

{
    "libraries": [
        {
            "name": "io.netty:netty-all:4.1.29.Final",
            "MMC-hint": "local"
        }
    ],
    "name": "Netty",
    "uid": "io.netty",
    "version": "4.1.29.Final"
}

Having it locally because it doesn't need to download/check with the remote server.
Imagine having to replace the library in every library update by copy pasting in every 1.12.x instance versions.

After:

{
    "formatVersion": 1,
    "libraries": [
        {
            "downloads": {
                "artifact": {
                    "sha1": "efce189397bfce0a561b25512696de8d241070b5",
                    "size": 3861743,
                    "url": "<artifact URL path>"
                }
            },
            "name": "io.netty:netty-all:4.1.29.Final"
        }
    ],
    "name": "Netty",
    "uid": "io.netty",
    "version": "4.1.29.Final"
}

Can you show me an example?

Instances that are created with this patch: https://gist.github.com/peterix/5c8b655ffafb866ccb2519f421dab671
After updating MultiMC that contain the commit, it does not warn the user and fails silently. https://i.imgur.com/0CrhLNV.png

[zomabies]

I don't know if it is related, is reload on the instance version menu has changed? You can only add patches via Add Empty, manually pasting the .json and hit reload does not add it to the patches list.

[peterix]

Yes, that is intentional. Nothing outside MultiMC is supposed to mess with the metadata files.

[peterix]

Alright, that should fix the broken reporting of missing local libraries.

[ProjectSynchro]

This appears to break launching older FTB packs
For instance FTB Ultimate which runs on Minecraft 1.4.7
https://paste.ee/p/EnchQ

This affects the jar mods specifically as it is reporting the jarmods as 'missing'
The libraries in question are referenced in mmc-pack.json

        {
            "cachedName": "liteloader (jar mod)",
            "uid": "org.multimc.jarmod.b1b79bb7-b9ad-410e-b756-6676eb0c119c"
        },
        {
            "cachedName": "MinecraftForge (jar mod)",
            "uid": "org.multimc.jarmod.364d242c-90d5-44f9-be12-4b9daea5c89f"
        }

[ProjectSynchro]

Fixed by creating a 'libraries' directory within the instance folder and copying the files within 'jarmods' into it.

I suggest fixing this as importing packs from ftb in launcher creates a broken instance by default

[zomabies]

As you have said "There could be better ways of achieving whatever goal you have.".
Is the post solution I made is suitable or plain unreasonable, if so, in what way it could be better?

Side note, is modifying the title suitable instead of creating new issue that reference it because it does not make sense when user find this issue.

[peterix]

Well, the root cause is that people are using a random old gist with outdated information.
Since then, I expanded the local libraries functionality to be loadable from inside the instances and later made it a mandatory thing.

The correct place to look at is this: https://github.com/MultiMC/MultiMC5/wiki/MultiMC-and-OptiFine

I guess it would be nice to extend the check for libraries and make it copy the global 'local' libraries in if they are present in ${mmc}/libraries, but missing in ${instance}/libraries. This would self-correct everything without any user intervention in most cases.

Then again, the few people that found and followed that gist could just as well move the file themselves. It will tell them what is missing now.

I should also remove the gist, or somehow make it redirect to the official documentation.

[zomabies]

That's reasonable, and I think
JSON-Patches
Directory-Structrue
Jar-Modding
should be updated to reflect the current changes, it's quite old.

I have edited the post above.
This issue is bigger than I have expected tbh.

[peterix]

In any case, this is a real issue. I just don't want to keep weird traps for people to fall into.

Some bad examples of those traps:

• People only backing up their instances folder and everything stops working because libraries are gone when they restore.
• Broken instances after manual export and import elsewhere.
• Things breaking because the user deleted the libraries folder in a futile attempt to fix something else.

The reason for the libraries folder in the instance not having a maven structure is that it is simply too hard for most people to create the exact correct folder structure. I want people to be able to easily add or override libraries. I guess I could make some UI for it and 'automate out' the complexity of maven, but it is still more complex than necessary on the code side. For example for mods (which ARE libraries), everyone is used to the mods folder and you can easily see all the mods you have installed in your default system file explorer without me having to write a specialized tool for it.

If we go with maven and make it user-facing, I have to write a ton of ugly code to make the user experience not horrible. And it doesn't make anything better.

[peterix]

Problems:

• Missing local libraries are not reported correctly on launch
• Fix Creating new FTB Instances that use Minecraft 1.4.7 report missing libraries #2478
• Old local libraries can be in the global folder for legacy reasons. Auto-migrate them to the instance libraries folder instead of showing errors.
• Update https://github.com/MultiMC/MultiMC5/wiki/JSON-Patches
• Update https://github.com/MultiMC/MultiMC5/wiki/Directory-Structure
• Update https://gist.github.com/peterix/5c8b655ffafb866ccb2519f421dab671 and/or make it point to https://github.com/MultiMC/MultiMC5/wiki/MultiMC-and-OptiFine
• Optional/Split-off: Make the experience of adding missing local libraries easier by having a UI with 'slots' the users can drag files into. This should validate that the files are correct when the checksum is known. As a followup, implement optifine support this way.