Un mrpack est un zip qui ment sur son propre format
Renommer un .mrpack en .zip vous donne un manifest et un dossier overrides, pas les mods — les jars résident sur le CDN de Modrinth et sont récupérés par hash.
Un .mrpack est une archive ZIP, donc le renommer en .zip et l'extraire fonctionne — et ne produit presque rien d'utile. Vous obtenez un modrinth.index.json, un dossier overrides, et aucun mod. Les jars n'ont jamais été à l'intérieur.
Pourquoi les mods sont absents
Les packs Modrinth stockent un manifest, pas une charge utile. Chaque entrée dans modrinth.index.json liste une URL de téléchargement ainsi qu'un hash SHA-1 et SHA-512 pour le fichier que cette URL est censée renvoyer. Le launcher lit le manifest, récupère chaque fichier, vérifie le hash, et ne le dépose qu'ensuite dans l'instance.
Cette conception garde les packs légers et permet à un pack de se mettre à jour sans re-téléverser chaque jar. Cela signifie aussi qu'un pack est inutilisable hors ligne tant que quelqu'un ne l'a pas résolu une fois.
Ce que contient réellement le manifest
| Champ | Signification |
|---|---|
formatVersion | Version du schéma du manifest |
game | Version de Minecraft cible et loader |
files | Tableau de path, hashes, downloads, env |
dependencies | Versions du loader et de Minecraft à installer d'abord |
Le champ env sur chaque fichier est celui que les gens oublient. Il marque un fichier comme client, server, ou les deux. Un mod marqué client-only ne doit pas du tout être copié dans le dossier mods d'un serveur — c'est une cause fréquente de serveur qui refuse de démarrer.
La vérification du hash n'est pas facultative
Si le SHA-1 d'un fichier téléchargé ne correspond pas au manifest, le fichier est incorrect : téléchargement tronqué, page d'erreur CDN enregistrée en jar, ou miroir altéré. Un convertisseur qui saute la vérification emballera allègrement une instance cassée. La vérification est la raison même de faire cela localement plutôt que de faire confiance à un repack aléatoire.
Sortie client versus serveur
Le même manifest produit deux archives différentes selon la cible :
- Pack client — tout, plus
overridesfusionné à la racine de l'instance, prêt pour un launcher qui accepte un ZIP. - Pack serveur — ignorer les entrées
env: client, conserverenv: serveret celles non marquées, et retirer la config client-only des overrides.
Java Edition uniquement. Bedrock n'a pas de format équivalent ; les add-ons Bedrock sont des archives .mcaddon/.mcpack avec un manifest.json d'une forme complètement différente, et aucun pack Modrinth ne s'y résout.
Les overrides écrasent, ils ne fusionnent pas
Les fichiers sous overrides/ sont copiés par-dessus l'instance après le placement des mods. Un fichier de config dans overrides remplace purement et simplement la valeur par défaut du mod. Si un pack fournit une config dans overrides et que vous modifiez aussi cette config dans l'instance, la copie des overrides l'emporte à la prochaine résolution.
Convertissez un manifest, vérifiez chaque hash, et obtenez un ZIP prêt pour launcher ou pour serveur dans le Convertisseur MRPACK vers ZIP.