no way to compare when less than two revisions

Differences

This shows you the differences between two versions of the page.

@@ Line 1: / Line 1: @@
+====== Foire Aux Questions (FAQ expert) ======
+Cette page est la version plus technique de la [[fr:faq:utilisateur|FAQ utilisateur]].
+==== Interopérabilité ====
+=== Quel est la progression du support sur Bukkit/Spigot/Paper ? ===
+Il existe quelques fonctionnalités expérimentales sur la branche de développement 0.5.0 du Loader pour faire tourner Fabric sur Paper, mais il existe de nombreuses réserves concernant les lacunes de l'API Bukkit (comme le codage en dur de la liste des blocs et des items dans une énumération (enum), ce qui rend la prise en charge des blocs et des items modifiés très compliquée). Bukkit ne sera certainement jamais officiellement supporté et doit être considéré plus comme une curiosité ou un cas spécial.
+=== Fabric peut il fonctionner avec Sponge ? ===
+La meilleure approche serait de porter SpongeCommon et une version modifiée de SpongeVanilla comme mod Fabric implémentant l'API Sponge. Comme Fabric utilise un fork du SpongePowered Mixin comme noyau, cela rend la tâche un peu plus simple - mais les différences de mappings rééquilibrent le tout.
+=== Pourquoi l'API Fabric casse les shaders Optifine ? ===
+Indigo, le patch de rendu utilisé par l'API Fabric, suppose (pour des questions de performances et de simplicité de code) que le format vertex du moteur de rendu vanilla doit être gardé intact. Généralement, les mods ne le modifient pas, mais les mods du style de ShadersMod (ou le chargeur de shaders d'Optifine) sont des exceptions connues. Du coup, Indigo ne fonctionne pas très bien avec ces derniers.
+Des solutions à ce problème ont été étudiées, mais rien de fonctionnel pour le moment. En complément, certains projets de mods non officiels essaient de travailler sur une de ces solutions. Malheureusement, les solutions de contournement actuelles ne fonctionneront pas en présence de mods de contenu qui utilisent l'API de rendu de Fabric.
+==== Rétrocompatibilité ====
+=== Sur quelles versions de Minecraft Fabric peut-il fonctionner ? ===
+En théorie, rien ne vous empêche de faire tourner le chargeur de mod Fabric sur n'importe quelle version de Minecraft, sous toute couche d'obfuscation, jusqu'à la version c0.0.11a. En revanche, les mappings Yarn n'existent pas pour beaucoup de ces versions -  ce qui rend le développement de mods bien plus compliqué.
+=== Fabric peut-il tourner sur des versions plus anciennes de Minecraft moddées ? ===
+Oui! Généralement, tous les mods modifiant le minecraft.jar (comme les anciennes versions d'Optifine, ou encore Better Than Wolves) devraient fonctionner correctement, et autoriser le même degré de moddabilité que vous auriez avec une version 100% vanilla de Minecraft. En revanche, il y a quelques notes spéciales:
+Pour beaucoup de chargeurs de mods pre-1.13, vous devez activer le //compatibility mode// dans le Fabric Loader, en ajoutant le flag JVM ''-Dfabric.loader.useCompatibilityClassLoader=true''.
+En ce qui concerne le fonctionnement avec Minecraft Forge:
+  * 1.6 ~ 1.12.2: Alors que Fabric fonctionnais auparavant sur le LaunchWrapper, cette fonctionnalité n'est plus maintenue et doit être retravaillée.
+  * 1.3.1 ~ 1.5.2: Pas de planification prévue.
+  * 1.2.5 et antérieur: Fonctionnel, comme ModLoader
+En ce qui concerne le fonctionnement avec ModLoader (<= 1.2.5): pas de problèmes connus.
+==== Philosophie ====
+=== Pourquoi avez-vous créé vos propres mappings au lieu d'utiliser les mappings existants de MCP ou Spigot ? ===
+En ce qui concerne le Mod Coder Pack, MCP:
+  * Les mappings de MCP n'ont pas de termes de license clairs entre l'ancienne licence MCP ([[https://minecraft.gamepedia.com/Programs_and_editors/Mod_Coder_Pack#License_and_terms_of_use|tel que préservé sur ke Wiki de Minecraft]]) et le nouveau dépôt MCPConfig. En revanche, Yarn est sous license [[https://github.com/FabricMC/yarn/blob/1.14.4/LICENSE|Creative Commons Zero v1.0]] et est libre d'utilisation, de modification et de redistribution si nécessaire.
+    * Alors que d'autres projets tels que Sponge ou Optifine utilisent MCP, redistribuer les mappings MCP - ce qui est interdit sans autorisation explicite - est nécessaire pour supporter les mods SRG offusqués, chose qui n'est faite que par [[https://github.com/MinecraftForge/MinecraftForge/blob/1.14.x/LICENSE.txt#L32-35|Minecraft Forge]].
+    * Même si nous avions eu l'autorisation, il est peu probable que nous aurions pu être libre d'étendre cette autorisation aux autres développeurs. Cela irai à l'encontre des valeurs fondamentales de Fabric au niveau du développement, de liberté et de transparence.
+  * Les mappings MCP ne sont pas toujours mis à jour pour les versions "non-release" de Minecraft, et les autres ne sont généralement pas autorisés à le faire eux-mêmes... Cela empêcherait Fabric d'être mis à jour vers les snapshots ou toutes les versions expérimentales de Minecraft.
+    * De plus, la chaîne d'outils de mise à jour de MCP - depuis quelques années - repose sur des informations propriétaires de Mojang, inaccessibles pour les utilisateurs classiques, ainsi que les logiciels sans conditions de licence claires. En revanche, la chaine d'outils de mise à jour de Fabric repose entièrement sur des outils open-sources et libre (Stitch, Matcher, Tiny-Remapper, Enigma), et les artéfacts du processus - comme les mappings - sont accessibles au public.
+  * La mise à jour des mappings de MCP utilise un processus qui, à notre avis, est insuffisant au niveau de la revue de code, utilisant une [[http://mcpbot.bspk.rs|soumission via un bot IRC]] par le biais d'un système de demande d'implémentation. (Toutefois, c'est en grande partie une question de préférence.)
+En ce qui concerne Spigot:
+  * Les mappings Spigot ne couvrent que le côté serveur et sont vraiments incomplets.
+  * Les mappings Spigot souffrent des mêmes problèmes de licence que les mappings MCP.