Les choses étranges du code de Minecraft
-
Pour les items tu es sensé utiliser les jsons.
-
Le problème c’est que je veux créer un bouclier et pour ça minecraft n’utilise pas les jsons, donc je vais utiliser cette méthode à la place
-
Dans net/minecraft/entity/monster, une classe (non de Mojang) quelque peu inutile. Jugez par vous-même :
// Auto generated package-info by MCP @ParametersAreNonnullByDefault @MethodsReturnNonnullByDefault package net.minecraft.entity.monster; import mcp.MethodsReturnNonnullByDefault; import javax.annotation.ParametersAreNonnullByDefault;EDIT : j’ai oublier, il n’est pas avant la 1.10
-
@‘Axaurus’:
Dans net/minecraft/entity/monster, une classe (non de Mojang) quelque peu inutile. Jugez par vous-même :
// Auto generated package-info by MCP @ParametersAreNonnullByDefault @MethodsReturnNonnullByDefault package net.minecraft.entity.monster; import mcp.MethodsReturnNonnullByDefault; import javax.annotation.ParametersAreNonnullByDefault;EDIT : j’ai oublier, il n’est pas avant la 1.10
C’est marqué en commentaire en haut du fichier, ça donne des infos sur les méthodes présentes dans les classes du package ‘net.minecraft.entity.monster’
-
Effectivement ces annotations sont générées automatiquement, en revanche je vois pas l’utilité de les mettre dans la classe vu qu’elles sont déjà dans le package-info
-
Peut-être, mais alors juste peut-être, que ce sont des annotations plutôt destinées à des analyseurs statiques, qui peuvent lever des warnings avant même la compilation si l’analyse montre qu’il y a des null potentiels dans les paramètres ou les valeurs de retours.
-
Non, ce sont des annotations qui indiquent que les paramètres de fonctions ne doivent pas êtres nuls (par défaut). Donc si tu essaies de mettre null dans une fonction ton IDE te dira que c’est pas possible (il me semble que c’est le but)
-
Donc de l’analyse statique
C’est le nom générique des analyseurs qui tentent de faire des vérifications sur un programme au niveau du code source (ça peut aller bien plus loin que ça).
-
@‘Mokona78’:
Peut-être, mais alors juste peut-être, que ce sont des annotations plutôt destinées à des analyseurs statiques, qui peuvent lever des warnings avant même la compilation si l’analyse montre qu’il y a des null potentiels dans les paramètres ou les valeurs de retours.
J’en suis sûr, c’est exactement ça.
-
Dans Particle.java:
public void moveEntity(double x, double y, double z) { double d0 = y; if (this.field_190017_n) { List <axisalignedbb>list = this.worldObj.getCollisionBoxes((Entity)null, this.getEntityBoundingBox().addCoord(x, y, z)); for (AxisAlignedBB axisalignedbb : list) { y = axisalignedbb.calculateYOffset(this.getEntityBoundingBox(), y); } this.setEntityBoundingBox(this.getEntityBoundingBox().offset(0.0D, y, 0.0D)); for (AxisAlignedBB axisalignedbb1 : list) { x = axisalignedbb1.calculateXOffset(this.getEntityBoundingBox(), x); } this.setEntityBoundingBox(this.getEntityBoundingBox().offset(x, 0.0D, 0.0D)); for (AxisAlignedBB axisalignedbb2 : list) { z = axisalignedbb2.calculateZOffset(this.getEntityBoundingBox(), z); } this.setEntityBoundingBox(this.getEntityBoundingBox().offset(0.0D, 0.0D, z)); } else { this.setEntityBoundingBox(this.getEntityBoundingBox().offset(x, y, z)); } this.resetPositionToBB(); this.isCollided = y != y && d0 < 0.0D; if (x != x) { this.motionX = 0.0D; } if (z != z) { this.motionZ = 0.0D; } }this.isCollided = y != y && d0 < 0.0D; if (x != x) { this.motionX = 0.0D; } if (z != z) { this.motionZ = 0.0D; }Celle-là, je l’avais jamais vu!</axisalignedbb>
-
Assez étrange en effet.
-
Oui c’est bizarre… Je pense que les mappings y sont pour quelque chose.
-
Peut-être une erreur de décompilation et de mappage oui.
Mais je ne vois pas d’autres variables dans la fonction donc ce n’est pas certain. Et puis si le code ne fait pas la même chose que celui de minecraft, on devrait constater une anomalie sur le déplacement des entités en ayant forge, or ce n’est pas le cas. -
C’est du code tout à fait valable. C’est du code de protection contre la valeur NaN.
Lorsqu’un flottant se retrouve à la valeur NaN (Not a Number), un moyen de réinitialiser la variable est de vérifier si elle est différente d’elle-même. En effet, par définition, NaN est différent de tous les autres nombres, y compris de NaN.
-
Et comment qu’un double pourrait ne pas être un nombre ?
-
Quand le résultat d’une opération ne donne pas un nombre.
Avec des entiers, 1/0 ou 0/0 vont envoyer une exception ; en flottant, le résultat est défini, 1.0/0.0 donne +inf (infinity). -1.0/0.0 donne -inf. Et 0.0/0.0 donne… NaN.
De même, le résultat de Math.sqrt() avec un nombre flottant négatif NaN, puisque la racine carrée d’un nombre négatif n’est pas défini pour les réels.
-
Ah et ben tu viens de m’apprendre quelque chose, bizarre qu’on puisse deviser par zéro quand c’est un flottant.
-
@‘Mokona78’:
C’est du code tout à fait valable. C’est du code de protection contre la valeur NaN.
Lorsqu’un flottant se retrouve à la valeur NaN (Not a Number), un moyen de réinitialiser la variable est de vérifier si elle est différente d’elle-même. En effet, par définition, NaN est différent de tous les autres nombres, y compris de NaN.
Tu m’as appris quelque chose!
J’aurais plutôt penser à ça qui est moins ambigu:if(!Float.isNaN(x)) -
Ça serait bien plus lisible en effet.
Après, si c’est du code décompilé, il est possible que le compilateur est remplacé l’appel à IsNaN() par son implémentation en ligne et qu’à la décompilation, on se retrouve avec ça. Je ne sais pas assez comment se comporte le compilateur Java.
Ou bien, c’est quelqu’un qui a l’habitude de cette formulation dans d’autres langages qui n’ont pas de fonction IsNaN().
(on pourrait objecter que x != x est plus rapide qu’un appel de fonction, mais je pense que le JIT se charge de l’optimisation lors du premier appel… si le compilateur ne s’en ai déjà pas chargé. Là encore, ça sort de mon champ de connaissance)
-
Ouai mais du coup ça renvoi une erreur
