Oui. Ton terrain exploré, tes constructions, tes coffres et ce qu'il y a dedans, tes objets, ton joueur, tes mobs, tes animaux apprivoisés, tes villageois, tes cartes et tes circuits de redstone arrivent dans l'autre édition dans l'état où tu les as laissés. Quand une donnée ne peut pas passer telle quelle, on te dit laquelle et pourquoi, plus bas sur cette page.
Tu trouveras ici le détail, dans les deux sens de conversion : ce qui arrive tel quel, ce qui demande une adaptation, ce que Minecraft recalcule de lui-même, et le peu qui n'existe pas du tout dans l'autre édition.
Si tu joues en vanilla (une base, des fermes, des coffres, des animaux, un village, quelques centaines d'heures), tu retrouves ce que tu as construit et ce que tu portes sur toi. Tu réapparais chez toi, à ta position, avec ton inventaire, ton XP, tes effets en cours et ton lit comme point de réapparition.
Ce qu'aucun convertisseur ne peut récupérer, c'est le terrain où tu n'es jamais allé : il n'a jamais été écrit sur ton disque, il n'y a donc rien à convertir, et l'édition d'arrivée le génèrera à sa façon. D'où le réflexe utile avant d'exporter : va faire un tour dans les zones auxquelles tu tiens. Le reste des différences est listé plus bas, avec à chaque fois ce qui est conservé et d'où vient la limite.
Blocs, entités, inventaires, cartes, chunks : rien n'est rangé pareil d'un côté et de l'autre. Renommer l'extension d'un fichier ne convertit donc rien. Il faut relire chaque donnée et la réécrire dans le format que l'autre moteur attend, en connaissant les différences jusqu'au détail : l'ordre des tessons sur un pot décoré, la façon dont une abeille se souvient de sa ruche, ou le fait qu'une minuterie se compte en temps restant d'un côté et en heure d'échéance de l'autre.
C'est le travail que fait WorldSwitch, et c'est ce qui permet à cette page d'entrer dans ce niveau de détail.
La géométrie, c'est la partie facile. Ce qui fait qu'un monde est le tien, c'est plutôt tout ce qui était en cours au moment où tu as quitté la partie.
Pendant la conversion, le moteur note tout ce qu'il n'a pas pu rendre à l'identique : une propriété que la version cible ne connaît pas encore, un état sans équivalent, une donnée mise de côté pour permettre le retour. Chaque famille est nommée et comptée, au lieu d'être résumée en un avertissement vague.
Tu le lis à deux endroits. Sur l'écran de fin, d'abord : le nombre de différences relevées s'affiche dès que la conversion est terminée, et si ton monde contient du contenu expérimental Bedrock, on te dit quelle expérience activer AVANT de l'ouvrir. Dans le monde converti, ensuite : un fichier worldswitch_command_report.json est déposé à la racine, avec le détail famille par famille. Le total y est toujours juste ; le détail porte les 200 familles les plus fréquentes, et le fichier indique lui-même combien il en reste au-delà.
Tout ce que tu as déjà exploré part avec toi, dans les trois dimensions.
Chaque zone déjà générée est reconstruite bloc par bloc : ton relief, tes grottes, tes mines, tes chemins et tout ce que tu y as bâti arrivent à leur place, aux mêmes coordonnées.
Deux bornes encadrent cette promesse, et chacune a sa propre carte plus bas : la hauteur disponible dans l'édition d'arrivée, et les blocs que la version cible que tu choisis sait décrire.
L'Overworld, le Nether et l'End sont convertis ensemble, avec leurs constructions, leurs coffres et leurs habitants. Tes portails restent alignés.
Les trois dimensions n'ont pas la même hauteur d'une édition à l'autre : le cas du Nether a sa propre carte plus bas.
Les biomes des zones explorées sont convertis avec ton terrain. Tes blocs et tes constructions ne sont jamais remplacés parce qu'un biome doit être adapté.
Quand un biome existe des deux côtés, son équivalent est utilisé. Quand il n'existe que dans une édition, WorldSwitch retient le biome disponible le plus proche. La différence porte alors sur ce qui dépend du biome : teinte de l'herbe et de l'eau, ambiance sonore, météo locale, apparitions naturelles.
Différence entre Java et Bedrock Les deux éditions n'ont pas exactement la même liste de biomes.
Un monde plat reste plat et un monde au vide reste vide : la composition, l'ordre et l'épaisseur de tes couches sont conservés, ainsi que le biome quand il existe des deux côtés.
Ce qui se génère AUTOUR ensuite est une autre question : « générer les structures », les features, les lacs et les surcharges de structures ne se décrivent pas de la même façon dans les deux éditions. Le réglage de ton monde d'origine te revient si tu fais l'aller-retour, mais l'édition d'arrivée peut poser des structures là où l'autre n'en posait pas. Une couche faite d'un bloc que la version cible ne connaît pas encore relève de la carte « version cible » plus bas : le cas est signalé, jamais passé sous silence.
Ton terrain ne bouge pas d'un bloc : une bordure n'est qu'une règle posée par-dessus le monde, et tout ce qu'elle entourait arrive intact.
Bedrock n'a pas de bordure de monde : le monde converti s'ouvre sans limite. Ta bordure est conservée à côté du monde, avec son centre, sa taille, sa zone sûre et ses dégâts, et elle revient telle quelle si tu repars vers Java. Depuis Java 1.21.9 chaque dimension peut avoir la sienne : une bordure propre au Nether ou à l'End est signalée dans ton rapport de conversion.
Différence entre Java et Bedrock La bordure est une fonctionnalité que Bedrock n'a pas du tout.
Ton terrain, tes constructions et tout ce qui se trouve à l'intérieur comme à l'extérieur de la bordure arrivent intacts, aux mêmes coordonnées.
Un monde né sur Bedrock n'a pas de bordure à donner : la fonctionnalité n'existe pas dans cette édition, et le monde Java s'ouvre donc sans limite, comme sur Bedrock. Un monde parti de Java, lui, retrouve sa bordure exacte — centre, taille, zone sûre, dégâts et distance d'alerte.
Différence entre Java et Bedrock C'est Bedrock qui n'a pas de bordure ; Java, lui, sait parfaitement en décrire une.
Tes torches, lanternes, lampes, blocs lumineux et vitraux arrivent tous exactement là où tu les as posés.
La carte de lumière elle-même n'est pas recopiée d'un moteur à l'autre : Minecraft la recalcule au premier chargement du chunk, et le résultat est l'éclairage normal de l'édition d'arrivée.
État recalculé par le jeu C'est le jeu qui refait ce calcul, pas nous, et il le refait de toute façon à chaque mise à jour de version.
Les blocs gardent leur sens, leur état et leurs minuteries en cours.
Chaque bloc garde son sens. Une bûche posée à l'horizontale le reste, un escalier regarde toujours dans la même direction, et une porte que tu as laissée ouverte s'ouvre encore du bon côté.
Laine, béton, terre cuite, verre teinté, tapis, lits, bougies et bannières gardent leur couleur exacte, dans les deux sens.
Une demi-dalle posée en haut reste en haut, un escalier retourné garde sa tête en bas, et une porte conserve sa charnière du bon côté.
Un escalier, une clôture, une dalle ou un panneau placé dans l'eau reste immergé après conversion, et les colonnes de bulles gardent leur sens.
Tes blocs de cuivre gardent leur teinte, du tout neuf au complètement oxydé, en passant par les stades exposé et patiné. Et s'ils sont cirés, ils le restent.
Blé, betteraves, carottes, melons, cacao, bambou, cactus : chaque plante repart à l'étape de croissance exacte où tu l'as laissée, et un sol labouré garde son niveau d'humidité.
Répéteurs, comparateurs, observateurs, pistons (base et tête), leviers et torches gardent leur orientation, leur délai et leur état alimenté. Tes circuits repartent dans le bon sens.
La force du signal parcourant chaque fil de redstone est conservée, de 0 à 15.
Rails, rails propulseurs, détecteurs et activateurs gardent leur forme (courbe, pente) et leur état alimenté.
Un répéteur en train de basculer, une eau ou une lave en train de s'écouler, une glace éphémère en train de fondre, une culture prête à pousser : les minuteries en attente sont converties avec le bon délai restant.
Le piston, son bras et le bloc qu'il était en train de déplacer arrivent tous les trois, à leur place, dans le bon sens : rien ne tombe au sol et rien ne devient de l'air.
L'animation elle-même n'est pas rejouée : le bloc transporté est posé sur sa case d'ARRIVÉE, celle que le jeu lui aurait donnée deux ticks plus tard. En pratique tu retrouves le résultat de la poussée, pas son image intermédiaire, et une machine volante arrêtée en plein cycle peut demander une impulsion pour repartir.
Différence entre Java et Bedrock Les deux éditions décrivent un bloc en déplacement avec des schémas totalement différents. Recopier celui de Java faisait tomber le piston en objet au sol et le bloc poussé en air : résoudre la poussée est ce qui garde la construction entière.
Tous tes composants arrivent, orientés, alimentés et minutés comme tu les as laissés : le circuit est physiquement identique, bloc pour bloc.
Java et Bedrock ne résolvent pas la redstone dans le même ordre. Les montages qui reposent sur ce détail (quasi-connectivité, BUD, machines volantes, horloges très serrées) peuvent se comporter autrement une fois en jeu, et parfois demander un réglage.
Différence entre Java et Bedrock C'est le moteur du jeu qui diffère, pas le fichier de monde : aucun convertisseur ne peut changer cela, quel qu'il soit.
Ce n'est pas seulement le bloc qui passe : c'est ce qu'il y a dedans.
Un four allumé garde sa cuisson en cours, son combustible restant et l'expérience accumulée qui t'attend dedans. Fumoirs et hauts fourneaux aussi, avec leur vitesse propre.
Java retient QUELLES recettes ont donné cette expérience, Bedrock seulement le TOTAL. De Bedrock vers Java, le total est donc redistribué sur une recette de référence : tu récupères la bonne quantité d'XP en vidant le four, sans la liste détaillée. Et une recette de cuisson à durée personnalisée (datapack) reprend la durée vanilla.
Différence entre Java et Bedrock Les deux éditions ne stockent pas l'expérience d'un four au même niveau de détail.
Chacun des quatre emplacements garde son aliment ET son propre temps de cuisson : la viande qui était presque prête le reste.
Un alambic garde ses potions en préparation, sa poudre de blaze, son eau et le temps de brassage restant.
Un alambic dont la durée totale de brassage a été modifiée par un datapack reprend la durée vanilla : le brassage en cours continue, à la vitesse normale du jeu.
Différence entre Java et Bedrock Bedrock ne décrit pas de durée de brassage personnalisée.
Une balise active garde son faisceau, ses pouvoirs primaire et secondaire, et le niveau de sa pyramide. Tout est là dès le premier chargement, sans rien à reconstruire.
Un pupitre garde le livre posé dessus et la page exacte à laquelle il était ouvert.
Chaque livre reste dans son emplacement exact, sur les six : le comparateur derrière ta porte secrète lira la même valeur.
Le disque inséré reste dans le jukebox. Le morceau reprend au début quand tu relances la lecture : c'est le jeu qui joue le son, il n'est pas dans le fichier de monde.
Une ruche garde les abeilles enfermées à l'intérieur, chacune avec son état, ainsi que son niveau de miel.
Le texte, les 16 couleurs, le gras, l'italique et l'effet lumineux des DEUX faces d'un panneau sont conservés, panneaux suspendus compris, et la cire aussi.
Deux mises en forme n'ont pas de destination. Le souligné et le barré de Java n'existent plus côté Bedrock : ces deux codes y désignent désormais des teintes de matière (cuivre, redstone). Dans l'autre sens, ces mêmes teintes n'ont pas de nom de couleur Java. Dans les deux cas le texte, sa couleur de base et sa mise en forme restent, et le cas est nommé dans le rapport.
Différence entre Java et Bedrock Bedrock a réaffecté les codes du souligné et du barré à des couleurs. Émettre ces codes pour un style Java donnerait un mauvais coloris, pas un soulignement.
Une bannière garde ses motifs superposés, dans l'ordre, avec leurs couleurs, et sa rotation sur son poteau. Les bannières porte-bonheur et les bannières de pillard aussi.
Les deux éditions partagent les motifs vanilla. Si l'une d'elles vient d'en ajouter un que l'autre n'a pas encore, ce calque-là est le seul touché : il est nommé dans le rapport de conversion, et la bannière garde tous ses autres calques et sa place.
Différence de version Les deux éditions n'ajoutent pas les nouveaux motifs au même moment.
Un pot décoré garde ses quatre tessons, chacun sur la bonne face et dans le bon sens, ainsi que son contenu. Un pot de fleurs garde sa plante.
Depuis Java 26.3, une face de pot peut porter un tesson renommé à l'enclume : Bedrock n'enregistre que l'identifiant du tesson, donc le motif est bien là mais pas le nom personnalisé. Le cas est nommé face par face dans le rapport.
Différence entre Java et Bedrock Bedrock ne stocke qu'un identifiant par face, là où Java stocke un objet complet.
Un cadre garde l'objet exposé et sa rotation ; un cadre lumineux reste lumineux. Un tableau garde son motif, sa taille et son mur.
Un générateur garde le mob qu'il fait apparaître et tous ses réglages : délai, portée d'activation, nombre par vague.
Un générateur réglé sur PLUSIEURS mobs tirés au sort ne garde que le principal : le plus probable de sa liste. Le générateur, lui, fonctionne normalement.
Différence entre Java et Bedrock Les deux éditions ne décrivent pas de la même façon un tirage pondéré entre plusieurs mobs.
Les voûtes et les générateurs d'épreuve sont convertis avec leur contenu : la liste des mobs qu'ils font apparaître, leurs réglages normaux et sinistres, la table de récompense sélectionnée et les joueurs déjà enregistrés.
Pour une conversion Bedrock → Java, renseigne ton identifiant Java : c'est ce qui permet à une voûte que tu as déjà ouverte de rester ouverte pour toi. Sans lui, elle peut te reproposer sa récompense.
Différence entre Java et Bedrock Une voûte retient QUI l'a ouverte, et les deux éditions n'identifient pas les joueurs de la même façon.
Le générateur d'épreuve arrive à sa place, avec ses mobs, ses réglages, sa table de récompense et les joueurs qu'il avait enregistrés : ta chambre d'épreuve reste jouable de bout en bout.
Si tu quittes le monde pendant une vague, l'épreuve ne reprend pas au milieu de cette vague : elle revient à sa phase d'attente et se ré-arme quand tu t'approches. Tu la refais depuis le début, avec le même butin à la clé.
Limite actuelle de WorldSwitch C'est une prudence de WorldSwitch, pas une différence entre éditions : un état de phase avancée écrit avec un contenu partiellement traduit a fait PLANTER Bedrock à l'approche du générateur, en jeu. Nous préférons une épreuve à refaire à un monde qui se ferme.
Chaque emplacement, chaque pile, chaque conteneur imbriqué.
Le contenu des coffres, coffres doubles, barils, entonnoirs, distributeurs, dropeurs et shulker boxes est transféré emplacement par emplacement, dans le bon ordre.
Une shulker box rangée dans un coffre garde tout son contenu, avec les enchantements et l'usure de chaque objet qu'elle renferme. Le rangement en poupées russes tient sur toute sa profondeur.
Un coffre de donjon, de temple, de portail en ruine ou d'épave que tu n'as pas encore ouvert garde sa table de butin : il te réserve encore sa surprise, et la surprise sera celle de l'édition d'arrivée.
Ta barre d'action, ton sac, ton armure et ta main secondaire sont transférés tels quels, avec les enchantements, l'usure et les noms personnalisés de chaque objet.
Les 27 emplacements de ton coffre de l'Ender personnel sont conservés.
Un objet n'est pas qu'un nom : son usure, ses enchantements et son histoire suivent.
Les 42 enchantements que WorldSwitch connaît sont convertis avec leur niveau exact, sur tes outils, armes, armures et livres, y compris les niveaux au-delà du maximum vanilla. La liste nommée est en bas de page.
Un enchantement Java n'y figure pas : Tranchant balayeur, que Bedrock n'a jamais eu. Une épée qui le porte traverse la conversion avec tout le reste (son nom, son usure, ses autres enchantements) et le rapport nomme l'enchantement retiré.
Différence entre Java et Bedrock Bedrock n'a pas de Tranchant balayeur : il n'existe aucun identifiant vers lequel le traduire, et en inventer un rendrait l'objet illisible.
L'usure de tes outils, armes et armures est conservée au point près : une pioche à moitié cassée le reste, et son coût de réparation à l'enclume suit.
Un objet renommé à l'enclume garde son nom, et les descriptions (lore) sont conservées ligne par ligne.
Les 45 variantes de potion que WorldSwitch connaît (normale, prolongée, renforcée) sont converties, en fiole, en potion jetable, en potion persistante ou en flèche à effet.
Un livre et plume signé garde son texte page par page, son titre et son auteur. Un livre enchanté garde tous ses enchantements et leurs niveaux.
Les fusées gardent leur durée de vol, leurs formes d'explosion, leurs effets (scintillement, traînée) et leurs couleurs, celles de fondu comprises. Un feu d'artifice fabriqué en jeu se rallume à l'identique.
Java autorise n'importe quelle couleur, Bedrock travaille avec les 16 teintures. Une couleur fabriquée à la commande, en dehors de ces 16, est rapprochée de la teinture la plus proche : c'est visible sur une map à couleurs sur mesure, pas sur une fusée craftée normalement.
Différence entre Java et Bedrock Bedrock désigne les couleurs de feu d'artifice par une teinture, pas par une valeur libre.
Un objet reste ton objet : son identité, sa quantité, son nom, son usure et ses enchantements traversent la conversion.
Les composants que Java a introduits en 1.20.5 n'ont pas tous une contrepartie Bedrock. Certains ne touchent que l'apparence (modèle personnalisé, couleur d'infobulle, drapeaux d'affichage) : l'habillage tombe et l'objet reste. D'autres définissent son COMPORTEMENT : un objet rendu comestible, planant, portable à un emplacement inhabituel, ou dont la pile maximale a été redéfinie par commande. Celui-là arrive bien dans ton inventaire, mais il retrouve le comportement vanilla de son identifiant. Chaque composant concerné est nommé dans le rapport, et le rapport distingue les deux cas.
Différence entre Java et Bedrock Java a réécrit la description de ses objets en 1.20.5 ; Bedrock ne suit pas le même modèle.
Une tête de joueur reste une tête de joueur, posée exactement où tu l'avais placée, avec sa rotation.
Le skin qu'elle affiche dépend d'un compte en ligne propre à chaque édition : il peut ne pas se retrouver et laisser une tête au visage par défaut.
Différence entre Java et Bedrock Le visage n'est pas stocké dans le monde, il est réclamé aux serveurs de l'édition concernée.
Tu réapparais chez toi, avec tes affaires et ton niveau.
Tu réapparais au même endroit que là où tu t'étais déconnecté, dans la bonne dimension et tourné dans la même direction.
Ton niveau d'XP et le remplissage de ta barre d'expérience sont conservés exactement.
Tes points de vie, ta barre de faim, ta saturation, ton souffle sous l'eau et ta chute en cours sont transférés.
Les 37 effets que WorldSwitch connaît (vitesse, force, résistance au feu, poison, absorption, lévitation, les présages…) sont conservés avec leur niveau et leur durée restante, sur toi comme sur tes mobs.
Quatre effets Java n'ont pas d'équivalent Bedrock : Luminescence, Chance, Malchance et Grâce du dauphin. Quand l'un d'eux est actif au moment de la sauvegarde, il s'arrête là (comme il se serait arrêté à l'expiration de sa durée) et il est nommé dans le rapport. Tous tes autres effets continuent de tourner.
Différence entre Java et Bedrock Ces quatre effets n'existent pas dans Bedrock : il n'y a aucun identifiant vers lequel les traduire.
Ton point de réapparition suit, aux mêmes coordonnées et dans la bonne dimension, que tu dormes dans un lit ou que tu passes par une ancre de réapparition dans le Nether.
Deux réglages fins de Java n'ont pas de champ Bedrock : la direction dans laquelle tu réapparais, et le drapeau qui force la réapparition même si le lit a été cassé. Ils sont conservés à côté du monde pour un retour vers Java ; côté Bedrock tu réapparais au bon endroit, simplement orienté par défaut, et Bedrock applique sa propre règle si le lit n'existe plus.
Différence entre Java et Bedrock Bedrock ne décrit ni l'angle de réapparition ni ce drapeau. Nous préférons les archiver plutôt que d'inventer un champ.
Survie, créatif, aventure ou spectateur : tu retrouves le mode dans lequel tu jouais, avec la capacité de vol qui va avec.
Les profils des autres joueurs sont conservés : inventaire, armure, coffre de l'Ender, XP, vie, position et point de réapparition. Java et Bedrock n'utilisent pas le même système de comptes : WorldSwitch te permet donc de rattacher chaque joueur à son compte cible lorsque tu connais son identifiant.
Si tu ne connais pas cette correspondance, le profil n'est pas jeté : il est conservé, et WorldSwitch peut créer une copie de récupération de ses possessions dans le monde, près du spawn, sans jamais remplacer un bloc existant. Une identité inconnue ne devient donc jamais une perte silencieuse d'inventaire. Dans le sens Bedrock → Java, tu indiques l'UUID Java de chaque joueur avant de lancer la conversion. Dans le sens Java → Bedrock, aucun rattachement n'est proposé : avec les seules informations que porte un monde, nous ne savons pas rattacher un profil à un compte Xbox de façon fiable, et nous préférons ne pas afficher une possibilité que nous ne savons pas tenir ; le profil et la copie de secours, eux, sont bien là.
Différence entre Java et Bedrock Les deux éditions n'utilisent pas le même système de comptes, et aucun fichier de monde ne porte la correspondance : elle ne peut venir que de toi.
Ta vitesse, ta portée, ta chance, ta résistance au recul : la valeur EFFECTIVE de chacune de tes caractéristiques est reprise telle que tu la portais, y compris quand une potion, un enchantement ou un datapack l'avait modifiée.
Java empile ces bonus sous forme de modificateurs séparés, chacun avec sa durée ; Bedrock ne tient pas cette liste sur le joueur. WorldSwitch replie donc leur effet dans la valeur de base : tu arrives avec exactement les mêmes chiffres, mais un bonus qui devait EXPIRER devient permanent côté Bedrock. Le rapport nomme chaque caractéristique concernée. Une valeur sortie de l'intervalle autorisé par Minecraft y est ramenée, comme le jeu le fait lui-même.
Différence entre Java et Bedrock Bedrock n'a pas de liste de modificateurs sur le joueur : il n'existe aucun endroit où écrire « ce bonus expire dans deux minutes ».
Ta position, ta direction du regard, ta vie et tout ton équipement sont repris tels quels.
Si le monde a été enregistré pendant que tu rampais, nageais ou planais, le jeu peut te remettre debout au chargement. Tu es au même endroit, dans la même seconde de jeu.
État recalculé par le jeu La posture est un état momentané que le moteur recalcule à chaque chargement, y compris sans conversion.
152 types d'entités, avec ce qui fait qu'elles sont les tiennes.
Le moteur gère 152 types d'entités : 90 créatures vivantes (animaux, monstres, villageois, boss) et 62 autres entités (véhicules, projectiles, cadres, tableaux, objets au sol). La liste nommée complète est en bas de page.
La couleur d'un mouton et sa laine déjà tondue, le collier d'un chat ou d'un loup, la variante d'un lapin, d'un renard, d'un axolotl, d'une grenouille ou d'un poisson tropical sont conservés.
Tes animaux apprivoisés (chiens, chats, chevaux, perroquets, lamas) restent apprivoisés, assis ou debout comme tu les as laissés, avec leur vie et leur nom.
Ton chien reste ton chien : apprivoisé, nommé, assis là où tu l'as laissé, avec son collier de la bonne couleur.
Il peut ne plus te reconnaître comme maître au premier chargement. Fournir ton identifiant Java pour une conversion Bedrock → Java réduit nettement ce risque.
Différence entre Java et Bedrock Le lien pointe vers un compte joueur, et les deux éditions n'identifient pas les comptes de la même façon.
La variante et la couleur d'un cheval, sa selle, son armure, le coffre d'un âne et son contenu, le tapis d'un lama, la selle d'un cochon ou d'un arpenteur : tout suit. Et une monture garde ses passagers.
Un squelette avec un arc enchanté, un zombie casqué, un enderman qui tient un bloc : l'équipement, la main, l'armure et le bloc porté sont conservés.
Un bébé reste un bébé, avec le temps qu'il lui reste avant de devenir adulte, et un adulte qui vient de se reproduire garde son délai avant de pouvoir recommencer.
Un cas ne suit pas : le bébé dont le vieillissement a été FIGÉ par commande, pour qu'il reste petit indéfiniment. Bedrock ne sait pas verrouiller un âge : ce bébé-là grandira normalement. Le verrou est conservé à côté du monde, donc un retour vers Java le retrouve intact.
Différence entre Java et Bedrock Bedrock n'a aucun champ de verrouillage d'âge sur un mob natif : en inventer un serait un pari, pas une conversion.
Un mob renommé garde son nom au-dessus de la tête, avec sa mise en forme : tes animaux et tes mini-boss restent reconnaissables au premier coup d'œil.
Java sait, en plus, exiger qu'un nom soit rendu EN PERMANENCE, même à travers les murs et sans viser le mob. Bedrock affiche les noms selon sa propre règle : le nom est là, sa permanence forcée ne l'est pas. L'intention Java est conservée à côté du monde, donc un retour vers Java la retrouve.
Différence entre Java et Bedrock Le champ de visibilité Bedrock est une constante de tous les mobs nommés, relevée sur des mondes natifs : il ne transporte pas l'intention « toujours affiché » de Java.
Un animal en laisse reste attaché après la conversion, qu'il soit accroché à un piquet de clôture ou tenu par toi.
Un mob en feu garde son feu, un mob empoisonné son effet et sa durée, un creeper chargé reste chargé, et un piglin ou un loup en colère arrive toujours en colère, contre la même cible.
Ce qui s'ajuste, c'est le temps qu'il lui reste à bouillir. Java compte les ticks de colère restants, Bedrock retient seulement CONTRE QUI le mob est en colère. Un mob venu d'un monde Bedrock natif repart donc sur une durée de colère standard ; venu d'un monde déjà passé par WorldSwitch, il retrouve son compteur exact.
Différence entre Java et Bedrock Bedrock ne stocke pas de compteur de colère sur un acteur natif : la cible existe des deux côtés, la durée non.
Le mob est là, à sa position exacte, avec sa vie, son nom, son équipement, son âge et ses effets.
Le trajet qu'il était en train de calculer et la cible qu'il poursuivait ne sont pas des données sauvegardées : il reprend sa décision au premier tick, comme après n'importe quelle reconnexion.
État recalculé par le jeu Minecraft lui-même ne stocke pas la décision en cours d'une IA dans le fichier de monde.
La ruche arrive avec ses abeilles, leur état et son niveau de miel. Les abeilles retrouvent leur ruche et repartent butiner.
Côté Java, la ruche mémorise la fleur exacte que ses abeilles visitaient ; côté Bedrock, ce sont les abeilles elles-mêmes qui retiennent leur point d'attache. Nous ne fabriquons donc pas un champ inventé : la valeur est conservée à côté du monde pour un retour vers Java, et en jeu l'abeille choisit une nouvelle fleur.
Différence entre Java et Bedrock Les deux éditions ne rangent pas cette information au même endroit. Inventer un champ Bedrock qui n'existe pas sur une ruche native serait un pari, pas une conversion.
Un village n'est pas un tas de maisons : c'est un réseau de métiers, de lits et de postes de travail.
La profession (fermier, bibliothécaire, prêtre…), le niveau, l'expérience et le style vestimentaire du biome de tes villageois sont conservés.
Chaque échange est conservé tel quel : ce que le villageois demande, ce qu'il vend, les quantités, les enchantements du livre proposé et le nombre d'utilisations restantes. Si tu l'as soigné d'une zombification, ses remises te suivent aussi.
Les lits, cloches et postes de travail qui font qu'un village est un village sont convertis avec leur occupation : qui dort où, qui travaille sur quel établi. Un villageois retrouve son lit et son métier au lieu de tout réattribuer au hasard.
Un raid interrompu par la sauvegarde reprend là où il en était : la vague en cours, les pillards déjà présents avec leur groupe et leur capitaine, la barre de progression et le mauvais présage sur ton joueur. Le raid n'est ni déclaré gagné ni déclaré perdu à ta place.
Les deux éditions ne rattachent pas un raid au village de la même façon : Java suit chaque villageois par son point d'intérêt, Bedrock raisonne sur une boîte de village. Le village qui porte le raid est donc reconstruit à partir des villageois, golems et chats convertis autour de son centre, sans quoi Bedrock jugerait le village vide et annulerait le raid au premier tick. Un village très étalé peut être regroupé un peu différemment.
Différence entre Java et Bedrock Les deux éditions ne décrivent pas un village avec les mêmes objets. Reconstruire est ce qui permet au raid de survivre au chargement ; recopier tel quel le ferait annuler.
Y compris ce qui était déjà en l'air au moment de la sauvegarde.
Chaque essence de bateau, les radeaux en bambou, les bateaux à coffre et leur contenu, les wagonnets de stockage, à entonnoir et de TNT arrivent à leur place, avec leurs passagers, mob ou joueur.
Une flèche plantée dans un mur, un trident lancé, une perle de l'Ender en vol, une potion jetable à mi-course, une TNT amorcée avec son décompte, un cristal de l'End, un nuage d'effet en train de se dissiper : tout ce qui volait au moment de la sauvegarde arrive à sa position, avec sa vitesse, et avec son lanceur chaque fois que ce lien existe des deux côtés.
Les deux éditions ne décrivent pas un projectile avec la même finesse. Une potion jetable ou persistante en vol reçoit les champs que Bedrock possède (son effet, son rayon, sa durée) et la description Java complète est conservée à côté du monde, pour qu'un retour vers Java la retrouve entière.
Différence entre Java et Bedrock La description Bedrock d'un projectile est plus courte que celle de Java : ce qui n'a pas de champ est archivé plutôt qu'inventé.
Le bouchon reste posé sur l'eau, rattaché au bon pêcheur.
La flèche reste : posée dans le décor ou en plein vol, avec sa trajectoire et son tireur.
Bedrock n'a pas de flèche spectrale : elle arrive en flèche ordinaire, sans l'effet de contour lumineux.
Différence entre Java et Bedrock Ce projectile n'existe tout simplement pas dans Bedrock.
Le dessin lui-même, pas seulement l'objet.
Tes cartes explorées sont converties pixel par pixel (128 × 128), avec leur échelle, leur centre, leur dimension, leur verrouillage et les marqueurs de bannières et de cadres posés dessus. Ce que tu as découvert reste découvert.
Java décrit chaque pixel par une entrée de sa palette, Bedrock par une couleur libre. En venant de Bedrock, chaque pixel rejoint donc l'entrée de palette Java la plus proche : le dessin, le relief et les ombres sont là, quelques teintes peuvent être très légèrement décalées. Et là où Java distingue chaque type de carte au trésor (océan, manoir, épreuve…), Bedrock n'a qu'une carte : le dessin et le marqueur suivent, l'étiquette du type non. Un drapeau de suivi propre à Java est conservé à côté du monde pour le retour.
Différence entre Java et Bedrock Les deux éditions ne stockent pas une carte dans le même format de couleur : la palette Java et les couleurs Bedrock ne se recouvrent pas exactement.
Chaque carte reste dans son cadre, à sa place et avec sa rotation : un mur de 3 × 3 cartes reste un mur de 3 × 3 cartes, et chaque case affiche toujours son morceau.
Les blocs déjà générés d'une structure sont conservés dès qu'ils existent dans la version cible. C'est l'étiquette interne de la structure qui diffère selon le sens.
Forteresses, monuments, temples, avant-postes, chambres d'épreuve : les blocs, les coffres, les objets et les mobs déjà générés sont conservés.
L'identité interne de la structure est reconstruite à partir de ce que Bedrock enregistre dans ses chunks : Java sait donc de nouveau que ce couloir appartient à une forteresse ; ce qui compte pour les apparitions propres à la structure et pour `/locate`.
Ta forteresse reste ta forteresse : chaque bloc, chaque coffre, chaque objet, chaque mob déjà présent traverse la conversion. La construction est intacte et se visite normalement.
Ce qui ne suit pas encore, c'est l'étiquette interne qui dit à Minecraft « ce chunk fait partie d'une forteresse ». Concrètement, cela concerne `/locate` et les apparitions réservées à la structure, pas la construction, pas son contenu. La donnée est conservée à côté du monde, donc un retour vers Java la retrouve.
Limite actuelle de WorldSwitch C'est une limite actuelle de WorldSwitch, pas une différence entre les éditions : Bedrock stocke bien cette information, mais dans un format dont une partie n'est pas encore établie avec certitude. Nous préférons ne pas l'inventer plutôt que de risquer un monde qui refuse de se charger.
Les réglages que les deux éditions partagent sont repris tels quels.
La seed est conservée. Elle ne sert qu'au terrain pas encore exploré : ce que tu as déjà visité vient de ton monde, pas d'une regénération.
Les règles reconnues par les deux éditions (cycle jour/nuit, dégâts de chute, keepInventory, mobGriefing, feu, TNT, PvP, blocs de commande, pourcentage de dormeurs…) sont conservées avec leur valeur.
Une règle qui n'existe que d'un côté n'a nulle part où aller : Java en a une trentaine que Bedrock n'a pas (portails, portée des commandes, entassement des entités…) et l'inverse est vrai aussi. Ces règles-là sont listées dans ton rapport de conversion. Depuis Java 26, la propagation du feu se règle par un RAYON autour du joueur là où Bedrock n'a qu'un oui/non : le feu reste actif ou éteint comme chez toi, mais sans la notion de rayon.
Différence entre Java et Bedrock Les deux éditions n'ont pas la même liste de règles.
Le niveau de difficulté (paisible, facile, normal, difficile) est conservé, et un monde en mode extrême reste un monde en mode extrême, dans les deux sens.
L'heure du jeu, la météo en cours (pluie, orage) et le compteur d'âge du monde sont transférés : tu reprends au même moment de la même journée.
Ton monde garde son nom dans la liste des mondes, et son point d'apparition commun (là où arrivent les nouveaux joueurs) est conservé.
Le monde plat, avec la composition et l'épaisseur de ses couches, et le monde au vide sont conservés. Ton terrain déjà exploré, lui, arrive tel que tu l'as laissé.
« Gros biomes » et « amplifié » n'existent pas côté Bedrock : le terrain généré ENSUITE, au-delà de ce que tu as visité, sera du terrain normal.
Différence entre Java et Bedrock Ces deux modes de génération n'existent que dans Java.
Pour les maps à commandes : le détail commence ici.
Les blocs de commande sont convertis avec leur mode (impulsion, chaîne, répétition), leur conditionnement, leur nom, leur alimentation et leur dernière sortie, et leurs commandes vanilla sont réécrites dans la syntaxe de l'édition d'arrivée.
Le minutage ne traverse pas toujours. Bedrock sait retarder n'importe quel bloc de commande et lui demander de sauter le premier tick ; Java n'a d'intervalle natif que sur le bloc répétitif. Quand ce minutage n'a pas de forme Java fidèle, le bloc arrive DÉSARMÉ plutôt que de tourner à la mauvaise cadence : sa commande t'est rendue dans le rapport, avec sa position et son délai d'origine, pour que tu la recâbles avec une horloge. En Java → Bedrock, certaines informations attachées à une commande n'ont pas d'équivalent. Quand WorldSwitch peut les retirer sans modifier l'action principale, la cible ni les conditions qui décident si la commande s'exécute, il conserve la commande sans ces informations et signale l'écart. Si leur retrait pourrait élargir un test ou un filtre, viser autre chose, changer l'action principale, ou si la commande est malformée, le bloc reste DÉSARMÉ et la commande d'origine est rapportée.
Différence entre Java et Bedrock Les deux éditions ne règlent pas le temps de la même façon et ne savent pas exprimer toutes les mêmes informations dans une commande. WorldSwitch ne retire une information sans équivalent que lorsque l'action principale, la cible et les conditions d'exécution restent les mêmes ; sinon il désarme le bloc et signale le cas plutôt que de laisser la commande changer de rôle.
Les sélecteurs et leurs filtres courants sont traduits vers la syntaxe de l'édition cible : @p, @a, @e, @s, @r, tag=, name=, type=, scores=, distance=, limit=, sort=, gamemode=, les angles de vue et les volumes, y compris les formes que Bedrock écrit autrement.
Quatre filtres n'existent que côté Java (`nbt=`, `predicate=`, `advancements=`, `team=`) ainsi que le ciblage par tag d'entités (`type=#minecraft:raiders`). Quand l'un d'eux apparaît, la commande n'est jamais recopiée à l'aveugle. Dans un texte de commande, elle est remplacée à son emplacement exact par un commentaire qui nomme le filtre en cause. Dans un bloc de commande, un item ou un wagonnet (où Bedrock n'a pas de syntaxe de commentaire) le bloc arrive désarmé et l'explication te parvient dans le rapport, avec sa position et la commande d'origine.
Différence entre Java et Bedrock Ces filtres interrogent des systèmes que Bedrock n'a pas. Recopier un sélecteur invalide ferait échouer la commande en silence.
Les composants de texte sont traduits entre le format JSON de Java et le format rawtext de Bedrock : couleurs, gras, italique, textes imbriqués, textes traduits avec leurs paramètres, scores insérés et noms de joueurs résolus par un sélecteur.
Deux choses ne trouvent pas de destination côté Bedrock. Le texte INTERACTIF d'abord : un clic qui lance une commande, une infobulle au survol, un texte inséré au clic, une police personnalisée, un affichage de touche clavier, une lecture de données. Le SOULIGNÉ et le BARRÉ ensuite : Bedrock a réattribué ces deux codes à des teintes de matière, il n'y a donc plus de style à viser. Dans les deux cas le message reste, sa couleur et son gras restent, et le composant en cause est signalé à son emplacement au lieu de partir en rawtext vide.
Différence entre Java et Bedrock Le rawtext de Bedrock n'a pas de champ d'interactivité, et ses codes de soulignement servent désormais à autre chose : il n'y a rien vers quoi traduire un clic, un survol ou un soulignement.
Un bloc de structure garde son nom, son mode, sa taille, son décalage, sa rotation, son miroir et son taux d'intégrité, cette dernière valeur étant réécrite dans l'échelle de l'édition cible.
Les objectifs, les scores de chaque joueur et l'emplacement d'affichage (barre latérale, liste des joueurs, sous le nom) sont convertis, titre compris.
Les ÉQUIPES Java (couleur, préfixe, suffixe, tir allié, collision, liste de membres) n'ont pas de contrepartie Bedrock : elles ne sont pas transférées. Les scores, eux, restent intacts.
Différence entre Java et Bedrock Bedrock n'a pas de système d'équipes de scoreboard.
Tes command blocks, tes scores, tes panneaux, tes coffres piégés et toute la construction de la map sont convertis normalement.
Les barres de boss personnalisées et les événements programmés du monde sont des systèmes propres à Java : ils n'ont pas de destination côté Bedrock. Les chunks maintenus chargés, eux, existent des deux côtés (`/forceload` en Java, `/tickingarea` en Bedrock) mais avec des règles différentes : WorldSwitch ne transforme pas automatiquement les uns en les autres, et une map qui en dépend demande de recréer ses zones côté Bedrock.
Différence entre Java et Bedrock Les deux premiers n'existent pas dans Bedrock. Le troisième existe, mais les deux systèmes ne se recouvrent pas assez pour qu'une traduction automatique soit fidèle : nous préférons te dire quoi refaire plutôt que de produire des zones dont le comportement diffère.
Les commandes vanilla sont traduites d'une syntaxe à l'autre, y compris les cas tordus : coordonnées relatives et locales, blocs avec états, NBT, dimensions, sons, recettes, effets.
Quand une commande n'existe tout simplement pas dans l'édition d'arrivée, elle n'est jamais recopiée telle quelle. Dans un texte de commande, elle est remplacée à l'endroit exact par un commentaire qui dit ce qui manquait. Dans un bloc de commande, où aucune édition n'accepte de commentaire, le bloc arrive désarmé et le rapport te rend sa position et sa commande d'origine : tu vois quoi recâbler au lieu de chercher pourquoi la map ne démarre plus.
Différence entre Java et Bedrock La commande n'existe pas dans l'autre édition ; inventer une traduction approximative casserait la map en silence.
Minecraft bouge tout le temps. WorldSwitch suit la version que tu vises, et te prévient plutôt que de deviner.
WorldSwitch écrit ton monde pour la version cible que tu choisis : les blocs et leurs états sont posés dans la forme que cette version sait lire. C'est ce qui évite le grand classique du monde converti qui refuse de se charger.
Une famille échappe volontairement à ce filtrage : les OBJETS. Un identifiant d'objet que notre registre de la version cible ne connaît pas est conservé tel quel plutôt que remplacé, parce que substituer à l'aveugle a déjà fait disparaître des objets parfaitement valides, Minecraft traînant des identifiants hérités qu'aucun registre ne liste. L'objet arrive donc dans ton coffre, et le rapport te dit lequel pourrait ne pas exister dans ta version. Blocs, états et entités, eux, sont bien adaptés ou signalés.
Limite actuelle de WorldSwitch C'est un choix de WorldSwitch, assumé : entre supprimer un objet qui existait peut-être et le laisser passer en te prévenant, nous préférons ne rien détruire. Viser une version cible récente referme le sujet.
Le contenu des tout derniers drops (forêt tachetée, peupliers, coussins, lits de paille, laine en escaliers…) est conservé dans ton monde. Nous ne le remplaçons pas par de l'air : supprimer ta construction serait irréversible, activer une case ne l'est pas.
Côté Bedrock, ce contenu vit derrière une expérience à activer. WorldSwitch te dit à la fin de la conversion laquelle activer, avant d'ouvrir le monde, et te prévient qu'activer une expérience désactive les succès de ce monde, définitivement.
Différence de version Côté Java le même contenu est ordinaire ; côté Bedrock il est derrière une bascule. La présence du contenu ne dit rien de l'état de la bascule.
Ton bloc reste posé, à sa place, avec son orientation ; ton objet reste ton objet ; ton mob reste ton mob, avec tout ce que la version cible sait décrire.
Si Mojang vient d'ajouter une propriété de bloc, un enchantement, un effet ou le contenu d'un bloc tout juste apparu, et que la version cible ne le connaît pas encore, il est retiré plutôt que de faire refuser le bloc ou le chunk entier. Un OBJET, lui, garde son identifiant et arrive quand même dans ton coffre ; sa carte « version cible » explique pourquoi. Chaque cas apparaît nommément dans le rapport, avec son nombre d'occurrences. Exemple concret : la végétation « Spring to Life » de Java 1.21.5 (buisson, fleur de cactus, buisson à lucioles, tapis de feuilles, herbes sèches, fleurs sauvages) existe dans Bedrock depuis la 1.21.70 ; elle passe donc sans un mot si tu vises une version récente, et n'est signalée que sur une cible antérieure.
Différence de version Les deux éditions n'avancent pas au même rythme ; écrire une propriété inconnue fait refuser le bloc, parfois le chunk entier. Viser une version cible récente est souvent la réponse.
Elles sont peu nombreuses, elles ne sont pas cachées, et chaque carte dit ce qui reste et ce qui change. Le rapport livré avec ton monde, lui, nomme et compte les écarts réellement relevés sur le tien.
Tout ce que tu as exploré part avec toi, bloc par bloc : tes bases, tes fermes, tes routes, tes mines. Rien de ce que tu as vu n'est régénéré.
Le terrain jamais visité n'existe dans aucun fichier : il sera créé par l'édition d'arrivée, avec son propre générateur. Et comme Java et Bedrock ne génèrent pas pareil, une même seed y donne un paysage différent : une couture peut être visible à la frontière de ce que tu as exploré.
Différence entre Java et Bedrock Ce terrain n'a jamais été écrit sur ton disque : il n'y a rien à convertir. Le bon réflexe : va faire un tour dans les zones auxquelles tu tiens avant d'exporter.
Tout ton Nether est converti jusqu'au plafond de bedrock : tes routes, tes fermes à or, tes portails et tes bases sous le toit arrivent intacts.
Le Nether de Java est deux fois plus haut que celui de Bedrock. Ce que tu as construit AU-DESSUS du toit n'a littéralement pas de place dans un Nether Bedrock, qui s'arrête à cette hauteur. Rien n'est descendu de force : cela décalerait toutes les coordonnées autour.
Différence entre Java et Bedrock Les deux éditions n'ont pas la même hauteur de Nether. WorldSwitch compte ce qui dépasse et te le dit, hauteur exacte comprise, dans le rapport de conversion.
Ton monde, tes objets, ton XP et tes constructions arrivent intacts. Ce sont tes compteurs de carrière qui repartent à zéro, pas ta partie.
Les statistiques (distance parcourue, mobs tués, temps de jeu) et les progrès débloqués reposent sur des identifiants et des arbres différents entre les deux éditions. Nous ne transformons pas non plus artificiellement tes progrès Java en succès Bedrock : ce serait fabriquer des récompenses que tu n'as pas obtenues dans cette édition.
Différence entre Java et Bedrock Les deux éditions n'ont ni la même liste de progrès ni la même façon de les compter.
Le wagonnet reste sur tes rails, à sa place, et roule normalement.
Bedrock n'a pas de wagonnet à moteur : il arrive en wagonnet ordinaire, sans sa capacité à pousser un convoi au charbon.
Différence entre Java et Bedrock Ce véhicule n'existe pas dans Bedrock. Ce n'est pas un mapping qui manque, c'est la mécanique qui n'est pas là.
Tout ce que les deux éditions partagent traverse la conversion, avec sa quantité, son usure, ses enchantements et son nom.
Quatre outils de création n'ont pas de contrepartie : le bâton de débogage, le livre de recettes et les deux blocs de test. Chacun est nommé dans le rapport de conversion, avec sa raison.
Différence entre Java et Bedrock Nous ne les remplaçons pas par un objet approchant : substituer à l'aveugle a déjà fait disparaître des objets parfaitement valides. Nous constatons et nous nommons.
Les blocs « autoriser », « interdire » et « bordure » deviennent des barrières côté Java : le mur invisible reste exactement là où tu l'avais posé, et il bloque toujours le passage.
Ce que Java ne sait pas reproduire, c'est la règle attachée : autoriser ou interdire la construction pour un joueur en mode aventure. La barrière obtenue bloque le passage sans porter cette permission.
Différence entre Java et Bedrock Ces trois blocs sont propres à Bedrock et sa gestion des permissions de construction. La barrière est le plus proche parent réel : elle garde la fonction visible.
Les 152 types d'entités que les deux éditions partagent sont convertis, mobs, véhicules, projectiles et décors compris.
Les entités d'affichage (bloc, objet, texte), les marqueurs et les zones d'interaction sont des outils de créateur de map que seul Java possède. Elles n'arrivent pas dans le monde Bedrock, et chacune est nommée dans le rapport de conversion plutôt que de disparaître sans un mot.
Différence entre Java et Bedrock Aucun acteur Bedrock ne leur correspond. Écrire une entité que Bedrock ne connaît pas fait planter le chargement du chunk : le silence, ici, serait pire.
L'Overworld, le Nether et l'End sont convertis en entier, avec tout ce qu'ils contiennent.
Une dimension ajoutée par un datapack ou un mod repose sur du contenu externe au monde. WorldSwitch ne la retranscrit pas en définition Bedrock équivalente : sans ce contenu, elle n'a pas de destination dans le monde converti, et une commande qui s'y exécutait est signalée à l'endroit exact où elle se trouvait.
Limite actuelle de WorldSwitch C'est la même frontière que les mods et les datapacks : nous convertissons le monde, pas les extensions qui le font tourner.
Un monde n'est pas un serveur. Voici la frontière, dite clairement avant l'achat.
Le terrain, les blocs vanilla et tout ce que tu as construit avec sont convertis normalement.
Un mod n'est pas une donnée du monde : c'est du code qui tourne à côté du jeu, et il n'existe que sur Java. Les blocs et objets qu'il ajoute n'ont aucune contrepartie ailleurs.
Différence entre Java et Bedrock Aucun convertisseur ne peut porter du code de mod vers Bedrock, ni l'inverse.
Ce qu'un datapack a déjà POSÉ dans ton monde en blocs vanilla reste dans ton monde et se convertit comme le reste.
Le datapack lui-même (ses fonctions, ses tables de butin, ses recettes, ses prédicats) est un système propre à Java. Il ne s'exécutera plus après la conversion.
Différence entre Java et Bedrock Bedrock n'a pas de datapacks ; son équivalent, les add-ons, utilise un modèle entièrement différent.
Le monde et tout son contenu vanilla sont convertis normalement.
Les behavior packs et add-ons sont un système propre à Bedrock : ils décrivent des comportements en JSON et n'ont pas d'équivalent Java.
Différence entre Java et Bedrock Les deux éditions n'étendent pas le jeu de la même façon.
Ton monde arrive complet ; le jeu lui applique ses textures par défaut, et tu peux réinstaller un pack équivalent dans l'édition d'arrivée.
Un monde peut embarquer son propre pack — côté Java `resources.zip` ou le dossier `resourcepacks/`, côté Bedrock `resource_packs/`. WorldSwitch le conserve tel quel à côté du monde converti : rien n'est jeté, et il revient intact si tu repars vers l'édition d'origine. Il n'est pas TRADUIT pour autant : modèles, textures et sons n'ont pas le même format d'une édition à l'autre.
Différence entre Java et Bedrock Le pack est conservé, mais son format n'existe pas tel quel dans l'autre édition.
Le monde hébergé sur ce serveur est converti en entier : terrain, constructions, coffres, joueurs, mobs.
Ce qui entoure le monde (`server.properties`, whitelist, opérateurs, bannissements, permissions, plugins, scripts de démarrage) appartient au logiciel serveur, pas au monde.
Différence entre Java et Bedrock WorldSwitch convertit le monde ; il ne transforme pas le logiciel serveur ni les extensions qui l'accompagnent.
Ce qui suit est minuscule, et ce ne sont pas des avertissements. C'est le niveau de détail auquel on travaille : même là, quand quelque chose ne peut pas passer, c'est écrit.
Ces états n'existent dans aucun fichier de monde, même sans conversion : ils sont recréés à chaque fois que tu ouvres ta partie.
Ces listes sortent directement des tables du moteur, et un test automatique casse la construction du site si elles s'en écartent d'un seul identifiant. Si un élément est ici, il est converti. L'inverse ne se déduit pas : quelques éléments Java n'existent pas dans Bedrock (Tranchant balayeur, Luminescence, Grâce du dauphin…), ils ont leur propre carte plus haut.
L'objectif n'est pas seulement que ton monde s'ouvre dans l'autre édition.
C'est que tu le retrouves comme tu l'as laissé.
Terrain, constructions, objets et état du monde sont traduits aussi loin que les deux éditions le permettent. Quand elles diffèrent vraiment, on adapte ou on signale la différence plutôt que de la masquer. Et si quelque chose nous a échappé sur ton monde, écris à bug@worldswitchapp.com avec la position et la référence de conversion. Ne joins le monde source que si l’équipe te le demande ou si tu choisis volontairement de le faire ; il pourra alors être consulté pour le diagnostic.