Les choses étranges du code de Minecraft
-
S’il a été mis, c’est sans doute pour une bonne raison.
Envoyé de mon Nexus 4 en utilisant Tapatalk
-
Vérifie par toi même, getItemInUseCount a le SideOnly mais pas la valeur, la preuve en est que la méthode que j’ai fait pour l’utiliser côté serveur fonctionne
-
Lorsque Minecraft est développé le client et le serveur sont séparé, c’est Forge qui le fusionne et met les Sideonly par comparaison. Quand une fonction est client only ça veut donc dire qu’elle n’existe que sur le jar client. Et si c’est le cas c’est sûrement car Minecraft n’a que besoin de cette méthode pour les rendus.
-
Sauf que là çà devrait pas être le cas, comme j’ai dit, mon code static fonctionne côté serveur.
-
Si cette fonction n’existe pas côté serveur ça ne veut pas forcément dire qu’elle ne peut pas fonctionner côté serveur, ça veut dire que Mojang n’en a pas besoin côté serveur.
-
Pour continuer le sujet, je n’aurai que deux mot:
Les. BlockPos.
Ils auraient au moins pu faire en sorte de les réutiliser au lieu de surcharger le GC. -
Moi j’ai une petite trouvaille, la class MinecraftError:
@SideOnly(Side.CLIENT) public class MinecraftError extends Error { private static final String __OBFID = "CL_00000657"; }Conclusion: Utilité: 0%
-
+1 xavpok. J’espère qu’ils ne seront plus là en 1.9.
-
@67clement il y a le nom de la classe ce qui fait qu’au lieu d’afficher “Error”, çà affiche “MinecraftError” donc on sait que çà vient de Minecraft.
@jglrxavpok +1.
-
J’étais en train de faire des tests avec Isador, lorsque j’ai remarqué ceci :
Faites un Math.cos(Math.PI) et MathHelper.cos(Math.PI), au début je croyais que l’un utilisait les radians et l’autres les degrés sauf que ce n’est pas le cas, les 2 utilisent les radians. Sauf que celui de MathHelper a moins de précision et qu’il utilise ses propres valeurs. -
Ah, bon à savoir, il faut utiliser le premier
-
Pas forcément! MathHelper utilise ce qu’on appelle une “lookup table” et une interpolation (de mémoire, je n’ai pas le code sous les yeux) pour avoir les résultats plus rapidement, ça permet d’éviter de faire le calcul à chaque appel de cos.
-
Oui mais en attendant cette méthode fait perdre de la précision et mange de la mémoire : donc je sais pas si la gain est si important que çà au niveau des performances.
-
net.minecraft.item.Item$ToolMaterial :
WOOD(0, 59, 2.0F, 0.0F, 15), STONE(1, 131, 4.0F, 1.0F, 5), IRON(2, 250, 6.0F, 2.0F, 14), EMERALD(3, 1561, 8.0F, 3.0F, 10), GOLD(0, 32, 12.0F, 0.0F, 22); /** The level of material this tool can harvest (3 = DIAMOND, 2 = IRON, 1 = STONE, 0 = WOOD/GOLD) */ private final int harvestLevel;Diamant ou émeraude? >.<’
-
Emerald est bien Diamond. Le nom du field n’a juste pas changé, en fait.
-
@‘elias54’:
Emerald est bien Diamond. Le nom du field n’a juste pas changé, en fait.
Oui il me semble qu’en 1.9 Nathan avait parlé du fait qu’il avais enfin remplacer tout les EMERALD par diamond ^^
-
Oui sauf que là ça vient de MinecraftForge qui n’a pas changé ses mappings.
-
@‘jglrxavpok’:
Oui sauf que là ça vient de MinecraftForge qui n’a pas changé ses mappings.
Mauvais MF ! ;o
-
La classe BlockVine a attiré mon attention.
Pourquoi elle n’utilise pas un EnumFacing comme les autre classes qui nécessite un placement particulier ? A la place, elle utilise une série de PropertyBool
-
Il me semble que c’est parce que les vignes peuvent êtres présentes sur plusieurs faces


