seedlookout
Français
Tous les articles

SeedCard Finder 1.0.0 : corrections des structures Java 26.3

SeedCard Finder 1.0.0 · Java 26.3 corrections

Un temple du désert en grès et un village au bord de badlands orange et d’une étendue d’eau côtière. Capture du jeu, Java 26.3.

SeedCard Finder 1.0.0 est le nouveau nom de notre version de l’outil de recherche de graines. Sa version produit est distincte de la version de génération Minecraft sélectionnée. Nous avons amélioré nos outils Java 26.3 en corrigeant les conditions de génération des structures, les vérifications du terrain et les positions des coffres des temples du désert. Une correction rétablit un temple réel que notre ancien modèle omettait à tort. D’autres concernent les mines abandonnées, les fossiles du Nether, les cités de l’End, les ruines du sentier et les prédictions de géodes d’améthyste.

Ces changements concernent le moteur de génération utilisé par notre carte des graines, nos outils de recherche de structures et notre outil de recherche de graines dans le navigateur. Ils traitent un problème courant des outils Minecraft : un marqueur plausible peut passer les vérifications du modèle alors que le jeu rejette la structure, ou une vérification approximative peut éliminer une structure qui existe réellement.

Pourquoi d’autres cartes de graines peuvent indiquer une structure absente

D’autres générateurs décrivent eux-mêmes ces limites. La documentation de la carte des graines de Chunkbase mentionne des positions incorrectes ou manquantes pour plusieurs éléments, dont les géodes d’améthyste près de grottes ou de mines abandonnées. Elle explique aussi que certains marqueurs de fossiles, de portails en ruine et de ruines du sentier indiquent le centre d’un chunk, potentiellement à une distance de 10 à 20 blocs de l’élément, et que certains éléments n’ont pas de coordonnée Y.

La FAQ sur la précision de mcseedmap.net indique de même que des structures peuvent manquer sur sa carte ou être marquées à des endroits où elles ne se génèrent jamais. Elle avertit aussi que les estimations du point d’apparition peuvent être incorrectes pour certaines graines. Ce sont les limites déclarées par ces outils ; elles ne nous indiquent pas la fréquence des erreurs de l’une ou l’autre carte.

Un modèle de génération doit tenir compte de plus qu’une position X et Z probable. La documentation originale de Cubiomes explique la distinction entre les tentatives de placement et les vérifications de biomes, puis décrit comment les conditions du terrain peuvent entraîner le rejet de certaines structures. Une position compatible avec le biome ne constitue qu’une partie de la réponse.

SeedLookout s’appuie sur la version dérivée Java de Cubiomes par xpple. Nos travaux ajoutent à cette base des vérifications et des corrections pour Java 26.3. Les améliorations ci-dessous comparent notre modèle corrigé à notre modèle précédent ; nous n’avons pas mesuré de classement global de précision face aux autres cartes actuelles.

Un temple réel que notre ancien modèle manquait

Dans Java 26.3, la graine 635482260673531 possède un temple du désert aux X, Y, Z : 32, 72, 0. Nous avons vérifié ce lieu dans le jeu ; il est publié sur la page de la graine avec temple et village sur la côte des badlands.

Temple du désert en grès près de maisons de village, de badlands orange et d’une eau côtière bleue. Capture du jeu, Java 26.3.

La capture montre le temple à cet emplacement vérifié. Notre ancienne vérification approximative du terrain rejetait son placement. La carte Java 26.3 corrigée et la recherche du temple le plus proche le conservent.

Cette correction compte près du seuil de niveau marin du jeu. Au lieu d’utiliser une hauteur approximative du terrain comme règle finale de rejet, la nouvelle vérification des temples pour les mondes Java 26.3 par défaut examine les colonnes de terrain occupées aux quatre coins de la structure. Elle conserve le seuil de génération du jeu. Dans les cas de référence sélectionnés, le modèle correspondait aux 80 hauteurs de coin et aux 20 décisions de génération de temples issues des règles de Java 26.3.

Pour un joueur qui cherche des temples, cela change les candidats qui passent la vérification du terrain et rétablit ce temple réel sur la carte. Cette correction précise couvre le Monde normal de Java 26.3 avec les réglages par défaut. Elle ne transforme pas l’ombrage du terrain en carte exacte des blocs et n’établit pas le même résultat pour les Grands biomes.

Nous avons aussi corrigé les prédictions de butin des temples du désert. Le modèle associe désormais les tirages de butin liés aux directions aux bons coffres et transforme leurs positions selon l’orientation du temple. Cela corrige un cas où une prédiction de pomme dorée enchantée désignait le mauvais coffre.

La couche des pommes dorées enchantées couvre toujours uniquement les coffres des temples du désert Java. Le temple du catalogue illustré possède des coordonnées de structure vérifiées ; sa capture et son statut dans le catalogue ne promettent aucune pomme dorée enchantée dans son butin.

Corriger plus que les marqueurs de temples

Plusieurs corrections concernent les conditions déterminant si un candidat peut se générer ou l’emplacement de ses éléments. Il s’agit de changements apportés au modèle de génération Java 26.3 :

Élément Ce que nous avons corrigé
Temples du désert Vérifications du terrain aux quatre coins, positions des coffres et tirages de butin liés aux directions.
Mines abandonnées Vérifications des biomes à la hauteur de génération sur l’ensemble des éléments assemblés de la structure.
Fossiles du Nether Biome à l’origine de placement aléatoire et vérification du terrain de support.
Ghasts desséchés Position X, Y et Z après rotation du modèle du fossile.
Cités de l’End Emprise du terrain utilisée pour juger si le candidat peut se générer.
Ruines du sentier Vérification du biome à la position initiale utilisée pour commencer la génération de la structure.
Géodes d’améthyste Terrain du monde par défaut, grottes creusées et fluides souterrains modélisés avant de conserver un candidat.

La correction des géodes concerne particulièrement la réserve exprimée par d’autres cartes de graines. Une origine de géode plausible ne tient pas compte de toutes les interactions avec le monde environnant. Ajouter les vérifications manquantes du terrain et des matériaux permet à notre modèle de rejeter davantage de candidats inadaptés avant de les afficher.

Des limites subsistent : le modèle des géodes ne reproduit pas toutes les interactions avec les structures, la surface ou les éléments générés auparavant dans le monde final. Un marqueur de géode reste une prédiction. La correction améliore les conditions de génération modélisées sans rendre chaque marqueur souterrain certain.

Ce que montrent les derniers résultats

Les examens du 2 octobre couvraient chacun 135 comparaisons dans 45 familles d’éléments Java 26.3. Le graphique montre les résultats enregistrés avant les corrections et ceux du modèle corrigé dans SeedCard Finder 1.0.0.

Graphique : avant les corrections, 118 comparaisons ont réussi, 15 ont échoué et deux étaient partielles ; après les corrections, 133 ont réussi, aucune n’a échoué et deux étaient partielles. Java 26.3, 135 comparaisons par examen.

Certaines zones de test ont changé entre les études, et certains cas d’éléments n’ont toujours pas d’exemple positif. Ces totaux décrivent donc les cas examinés, plutôt qu’une hausse contrôlée de précision pour l’ensemble des graines Minecraft. Ils ne signifient pas non plus que chaque lieu ayant échoué auparavant a été résolu individuellement.

Les estimations de planéité et de surface des îles restent partielles : toutes deux dépassent la tolérance déclarée d’erreur de hauteur. Un terrain approximatif peut encore vous induire en erreur lorsque vous choisissez un endroit plat pour construire ou jugez la surface d’une île.

Graphique : l’erreur de hauteur maximale observée est de 26,6 blocs pour la planéité et de 27,5 blocs pour les estimations des îles, toutes deux au-dessus de la tolérance de 16 blocs du dernier examen Java 26.3.

Les outils de recherche de minerais ont une limite distincte. Une cible de diamant ou une cible de débris antiques représente une origine de placement modélisée. Elle ne garantit pas un bloc de minerai final à ces coordonnées.

Les corrections et les résultats présentés ici concernent Java 26.3. Ils n’établissent pas de nouvelles affirmations de précision pour Bedrock ou les anciennes versions Java.

Utiliser les outils mis à jour

Choisissez l’édition et la version de génération avant d’interpréter un marqueur. Pour un monde mis à jour, utilisez la version qui a généré la région explorée. Les mods, les packs de données et les réglages personnalisés du monde peuvent modifier la génération ; la nouvelle vérification exacte du terrain des temples décrite ici concerne les mondes Java 26.3 par défaut.

Ouvrez SeedCard Finder 1.0.0 pour Java 26.3 pour chercher un nouveau monde selon les conditions choisies. Le lien sélectionne Java 26.3 ; une recherche enregistrée conserve ses réglages d’origine si vous la reprenez. Les résultats restent des prédictions issues d’un modèle.

Pour voir le temple rétabli, ouvrez son résultat dans l’outil de recherche de temples du désert. Le lien utilise la graine 635482260673531 et lance la recherche depuis les X, Z : 32, 0. Comparez la prédiction au lieu et aux captures originales de la page publiée de cette graine avec temple.

Pour des mondes avec des lieux vérifiés séparément, parcourez les pages de graines Java 26.3. Chaque page indique ce que nous avons vérifié dans cette version ; la page À propos en explique la portée.

PARTAGERReddit

Graines dans cet article

Sources

  1. Carte des graines de Chunkbase : limites connues
  2. mcseedmap.net : questions sur la précision
  3. Cubiomes : génération des structures
  4. Version dérivée de Cubiomes pour Java utilisée par SeedLookout
  5. Manifeste du moteur de génération de SeedLookout