>> La recherche se fait sur tous les élements du jeu Minecraft <<
Aidez nous a financer le site: Joignez l'utile à l'agréable et profitez d'FR-Minecraft sans publicités en devenant VIP ! Ou ajoutez FR-Minecraft dans vos exceptions, nous n'abusons pas des pubs
Aidez nous a financer le site: Joignez l'utile à l'agréable et profitez d'FR-Minecraft sans publicités en devenant VIP ! Ou ajoutez FR-Minecraft dans vos exceptions, nous n'abusons pas des pubs

Minecraft snapshot 18w22a: Bientôt les PreReleases !

Le 30/05/2018 à 5h27
Aidez nous a financer le site: Joignez l'utile à l'agréable et profitez d'FR-Minecraft sans publicités en devenant VIP ! Ou ajoutez FR-Minecraft dans vos exceptions, nous n'abusons pas des pubs

Une nouvelle snapshot est sortie ce mardi, la version Minecraft snapshot 18w22a, apportant comme dans les dernières snapshots de nombreuses corrections de bugs, dont un très ancien rapporté il y a 6 ans !


Outre une amélioration des performances annoncée par Mojang (sans plus de détail), cette snapshot corrige une trentaine de bugs.


Les arbres perdaient leurs feuilles
Vous l'aviez peut être remarqué en explorant le monde, lors de l'exploration de nouveaux chunks fraîchement générés, certains arbres (particulièrement visible dans les biomes jungles) perdaient naturellement leurs feuilles comme si on venait de leur couper le tronc.

Ce bug a été rapporté il y a 6ans déjà (en 2012), pour la version 1.4.3 de Minecraft Java. Il affecté au début les arbres du biome jungle (biome ajouté en 2012 dans la version Minecraft 1.12). Avec le temps et l'ajout de contenu dans le jeu ce bug s'est étendu à d'autre biome et d'autres types d'arbres, comme les arbres géant du biomes taïga, les acacias et les chênes noirs.

Le problème était technique: une feuille a plus de 4 blocs d'un bloc de tronc disparaît naturellement (c'est pour cela que quand on coupe un tronc les feuilles despawnent naturellement). Hors durant la génération des arbres de la jungle (et des quelques autres cités) produisaient des feuilles trop loin des branches.

Résultat, un arbre de la jungle bien rond comme celui ci:

Voyait ses feuilles les plus lointaine de-spawn, produisant une forme de losange dans ses feuilles:


Une résolution partielle du bug fut implémenté dans le jeu en 2016, les feuilles ne de-spawnaient plus naturellement en visitant le biome... Mais ce n'était qu'un artifice visuelle, puisque le bug était toujours la, et il suffisait de réactiver la zone (en construisant un bloc a proximité des feuilles par exemple) pour réactiver le despawn des feuilles a plus de 4 blocs du tronc.

Finalement c'est dans cette snapshot 18w22a que le bug a été définitivement corrigé. La solution la plus logique était d'ajouter des branches dans les arbres pour s'assurer que les feuilles ne soient jamais à plus de 4 blocs de distances d'une branche (tronc). Mais ce n'est pas la solution choisit par Mojang, qui a préféré augmenter la distance de de-spawn des feuilles à 6 blocs. Les arbres restent donc rigoureusement les mêmes qu'avant, avec des feuilles allant jusqu'à 6 blocs de distances du tronc:

Les anciens block-states "check_decay" et "decayable" ont été remplacé par "distance" (la distance du tronc le plus proche) et "persistent" (true si c'est un bloc posé par un joueur, et qui doit donc pas despawn).


Les autres bugs corrigés
Voici les principaux autres bugs corrigés:
  • Corrections de plusieurs problèmes de compatibilité avec les anciennes version de Minecraft (1.12, 1.11, 1.10, etc.): Les tapis disparaissaient, certains portails du Nether étaient corrompu:

  • Les Ocelots et les Perroquets ne spawnaient plus naturellement
  • Les dauphins pouvaient spawn par millier dans une même zone:

  • L'eau n'avaient pas la bonne teinte derrière les blocs de verre:

  • Les prefixes et suffixes de scoreboard n'étaient pas enregistré (j'en avait parlé dans la présentation de la snapshot 18w20a)
  • Corrections de plusieurs problèmes de corruptions de blocs en bordure de chunk à la frontière du monde.
  • La commande "/setblock ... destroy" ne droppait pas le contenu des containers (coffres, etc.)
  • Le tag NBT "SelectedItem" n'était pas retourné par la commande /data
  • L'achievement "Sniper duel" peut maintenant être gagné avec le trident (la description a été mise à jour pour le prendre en compte)
  • Corrections de plusieurs problèmes mineures sur les textures:
    • Un pixel blanc sur la queue d'un des chevaux:
  • Des pixels vert sur l'armure en fer des chevaux:
  • Le pixel en bas a droite du saut avec un poisson tropical est trop sombre (il n'est pas sombre pour les autres poissons):

Pour les autres poissons ce pixel est gris clair:

(Oui il y a des gens qui rapportent ce genre de "bug", pire c'est accepté par les modos, et c'est même "corrigé" par Mojang... la preuve)
  • etc.


Mojang corrige de plus en plus de bugs mineures, Adrian (qui s'occupe de la publication des snapshots depuis quelques semaines) a donc annoncé que nous sommes maintenant très proches des Pre-Release ! Il n'est donc pas impossible que la mise à jour Aquatique, alias Minecraft Java 1.13, sorte en version Release durant le mois de Juin :-)


Vous pouvez tester cette snapshot dès maintenant en un clic sur "Tester la snapshot" depuis le launcher FR-Minecraft. Si vous souhaitez tester cette snapshot il est recommandé de faire une sauvegarde de vos mondes, puisque les snapshots sont des versions instables qui risquent de corrompre votre monde.
Cet article a été publié par Tronics, le 2018-05-30 05:27:54. Source
Validé par  Tronics. Dernière modification par  Tronics le 30/05/2018 à 5:31.
Partager :
Commentaires de la news Minecraft
Minecraft snapshot 18w22a: Bientôt les PreReleases ! :
Tronics (administrateur)
le 30/05/2018 à 06:39
Je ne serait personnellement pas aussi optimiste que Adrian sur la stabilité de ces snapshots, perso lorsque j'ai ouvert mon monde 18w21b Minecraft a crash immédiatement, je n'ai jamais pu réouvrir ce monde, j 'ai du en recréer un nouveau. Coté performence c'est toujours aussi exécrable, il n'y a aucun recyclage des objets dans le code source du jeu, résultat la RAM utilisé monde en flèche (visible sur l'écran de débug "F3") et le garbage collector (qui libère la RAM) se déclenche tous les secondes, provoquant d'horribles ralentissements intempestifs :-(

J'avais regardé le code source il y a quelques temps, et quand j'avais vu qu'ils supprimaient toutes les types générique (int, etc.) pour les remplacer par des objets (qui ne contenait que l'int en question), j'en ai fait des cauchemard, ce sont des motifs qui n'apportent rien mais qui plombe les performances comme pas possible (utilisation massive de RAM, et création/destruction d'objet en permanence), et on en paye le prix aujourd'hui :-( Je n'ai toujours pas compris ce choix, peut etre un confort de developpeur (typage fort) ? Mais pas à ce prix svp ...
franswa (rédacteur)
le 30/05/2018 à 07:35
Je crois que je n’ai jamais vu ça! Une succession de snapshots instables peu de temps avant une release, ça fait quand même franchement amateur. Pour le fait que tout est en objet, dans le code, j’imagine que ça vient de leur volonté de pouvoir tout personnaliser. Ils préparent juste le terrain pour ne pas tout recasser aux prochaines mise a jour.
DadouLeChatChat (anonyme)
le 30/05/2018 à 08:38
Après, les devs ils s'en fichent un peu que les performances soient toutes pourries dans les snapshots : eux ils ont des PC du futur avec des tonnes de Go de RAM alloués à Minecraft... Et puis ils corrigeront certainement ça avec les Pre-Release...
Anonymus (anonyme)
le 30/05/2018 à 08:51
Coucou !
Merci tronics pour cette news. C'est trop bien que la 1.13 pré release sorte fin juin !!!
Youpi
CubiBoxSauvage (anonyme)
le 30/05/2018 à 08:53
completement debile comme resonement DadouLeChatChat ... ce jeu est mondiale c pas un jeu .io c connu donc non ils s'en fichent pas c juste que la se sont les correction de bug donc il optimiseron un peu plu tard apres perso mon pc ne peu pas demarrer les snapshot apres la 18w16 donc je peu pas tester r.i.p
Alg (anonyme)
le 30/05/2018 à 09:27
Snapshot injouable dès qu'on bouge vite (elytra, bateau sur glace...). Ça gèle, ça plante...
hansculer (anonyme)
le 30/05/2018 à 11:17
C’est normal que les dauphins ne spawn plus qu’à côté de structure sous-marine ?
C’est peut être ça « les dauphins montre les trésors »
SkyRyan (anonyme)
le 30/05/2018 à 12:50
Minecraft avais dis avant les snapshots 1.13 que les snapshots sortiraient bientôt,2 semaines plus tard elles sont sorties.Maintenant,ils disent Vraiment bientôt donc peux être dans 1 semaine si "Vraiment" veux dire que c'est plus proche que 2 semaines ?
franswa (rédacteur)
le 30/05/2018 à 12:59
Pour moi, ils sortent la 1.13 pour l’E3. Je serais même pas surpris qu’ils la sortent pendant la conférence Microsoft. Le 10 juin, donc.
Anonymus (anonyme)
le 30/05/2018 à 13:08
Juste svp arrêtez de faire de fautes dans les commentaire car c'est vraiment impossible à lire (comme les snapshots impossibles à jouer)
Merci !!
azor54 (anonyme)
le 30/05/2018 à 17:52
Eh ben ... 0_0 , ils ne sont pas prets de sortir leur 1.13 !
carreaux (anonyme)
le 30/05/2018 à 18:39
elle est sortie officiellement la 1.13 de la java?
Bah-non (anonyme)
le 30/05/2018 à 19:44
Bah non. mais ça vient
franswa (rédacteur)
le 30/05/2018 à 19:50
Sinon, pour @tronics dans la news de la snapshot du jour. Il y a eu des annonces au minecraft creator summit : 3 futures mise a jour prévues. Une qui améliorera les graphismes (la 4k update sur bedrock et, vraisemblablement, aussi des optimisations graphiques sur java), et une mise a jour concernant le PVP, ce qui est une annonce importante au nombre de joueurs jouant encore en 1.8 a cause du PVP. Ca voudrait aussi dire que le dernier grand domaine ou la version java et la version bedrock sont très différents pourrait enfin réunir les deux versions.
carreaux (anonyme)
le 30/05/2018 à 21:03
Merci de la réponse bah non
franswa (rédacteur)
le 30/05/2018 à 21:13
@carreaux on a appris aujourd'hui au minecraft Creator summit que la 1.13 aurait du sortir aujourd'hui, mais qu'elle a pris du retard a cause des bugs.
Tronics (administrateur)
le 31/05/2018 à 04:01
franswa: Merci pour les infos ! j'était même pas au courant :-S

[Paragraphe hyper technique:]
Pour rép a ton premier commentaire, lorsque j'ai écrit mon commentaire je pensais a un changement qui peut paraitre anodin pour un débutant: Ils avaient remplacé l'appelle de fonctions avec des coordonnées X, Y et Z (3 entiers) par un seul parametres, un objet contenant les 3 parametres en question (X, Y et Z). A premiere vu on peut se dire que ca revient au même: le code est pas plus long, ca regroupe les coordonnées ensemble, etc.., et pourtant... pas du tout. Car a l'éxécution ca ne fonctionne pas du tout de la même manière: ça signifie qu'il va falloir instancier un objet en plus, affecter les valeurs a ses attributs dans le constructeurs ou ses setters, les relires plus tard via de nouveau appelle aux getters (et donc utilisation de la pile juste pour lire un entier), et surtout, attendre que le garbage collector passe par la pour liberer les ressources. Pour etre un peu plus technique (oui encore plus, désolé) c'est une question de type de mémoire: Les parametres de type int sont placé sur la pile avec l'appel de la fonction et sont libéré automatiquement à la fin de la fonction, alors qu'un objet est aloué dans le tas, qui lui n'est jamais libéré... C'est donc du boulot en plus pour le garbage collector qui va devoir s'occupé de ça, et donc une RAM utilisé massivement (car jamais libéré), et des performances en berne. Et des coordonnées, autant dire que le jeu en traite des millions chaque secondes, donc ce problème infinime à première vue est loin d'être négligeable. Et ce n'est qu'un détail sur lequel j'était tombé par hasard, je n'ose même pas imaginer le reste du code. Tout un pavé pour dire que ces problèmes de RAM et de garbage collector ne m'étonne pas du tout.
franswa (rédacteur)
le 31/05/2018 à 09:06
@tronics en même temps, il était demandé aux créateurs de garder l'information secrète d'ici le début de l'évènement, ce qui ne m'avait pas empêché de deviner ce qui se passait 5 jours avant en regroupant des infos de aypierre et d'aurélien sama ;)

sinon, je vois bien le problème, en terme de performance. Je pense qu'il font ça pour 2 raisons :

D'une part, ce sera plus simple d'ajouter des fonctionnalités a l'avenir. Par exemple, avec un objet de position, si tu veux rajouter des coordonnées relatives par rapport a tel ou tel emplacement, tu rajoute les attributs a l'objet, et dans la methode ou t'en a besoin, tu appelles le getter, fin de l'histoire.
Par contre, avec des types primitifs, si tu veux rajouter des fonctionnalités, il faut rajouter des nouvelles variables. Du coup, ça veut dire ajouter des paramètres aux méthodes et prendre le risque de faire des erreurs en modifiant le diagramme UML du projet.

D'autre part, vu que beaucoup de fonctionnalités sont portées de java à bedrock et de bedrock à java, on se retrouve avec du code sur java qui est codé comme en c++, sauf que comme tu le dis, il y a pas de destructeur en java, ce qui fait que des objets inutilisés s'accumulent en RAM.
le 31/05/2018 à 14:11
Java aurait quand même dû inclure un destructeur, je trouve ça bête qu'il n'y en ait pas dans ce langage ...
franswa (rédacteur)
le 31/05/2018 à 18:26
@lattyange c’est pas que java en a pas, c’est qu’il est automatique et ne peut pas être géré par le developpeur, contrairement au C.
Tronics (administrateur)
le 01/06/2018 à 00:42
franswa Oui je pense que c'est pour un conford de code, mais autant je peux comprendre ce choix pour un tableur ou un traitement de texte ou les performances ne sont clairement pas un problème, autant pour un jeu vidéo qui doit garantir a tout moment 60 FPS minimum, je trouve ça plus contestable. Dans ces cas la le conforme du joueur passe normallement devant celui du developpeur ! Et je doute qu'ils utilisent des diagrammes UML honnetement, ils ont déjà du mal a suivre leur méthode de dev agile, alors un diagrame UML n'en parlons même pas lol.

Lattyange: Techniquement il y a en des destructeurs, mais il ne servent pas a ça ;-) (ils servent a exécuter des action lors de la libération de l'objet par le garbage collector, donc rien a voir). Après c'est pas forcement un reproche au langage, le langage a été conçu spécifiquement pour que les devs n'aient pas a s'occuper de la gestion mémoire, donc c'est normal. Mais c'est aussi pour ça qu'en général quand on fait un logiciel qui a des impératif de performance on le fait pas en Java, mais en C++ (un langage plus complexe puisqu'il faut gerer manuellement la mémoire, mais qui permet de meilleurs performances), c'est d’ailleurs pour cela que Minecraft Bedrock est programmé en C++. Je vais pas dire que la plupart des jeux sont programmé en C++ car c'est faux, la plupart des jeux Indies tournent sous Unity, un framework .NET (l'équivalent de Java, ça fonctionne pareil, avec un garbage collector). Par contre les gros jeux AAA eux sont en C++.

Vous devez être connecté pour laisser un commentaire.