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.