Les choses étranges du code de Minecraft

SCAREX

Aujourd’hui je vous propose ce nouveau topic où vous pourrez parlez de toutes les parties du code fait par Mojang absolument inutile ou qui pourrait être fait d’une autre manière.

Je commence ce topic avec toutes les fonctions créés par Minecraft en plusieurs fois et qui reviennent au même :
MinecraftServer.class

ligne 29

/** The server MOTD string. */
private String motd;

On voit un joli MOTD

et maintenant, les getters et les setters :
ligne 1222

public String getMOTD()
{
return this.motd;
}

ligne 1560

/**
* Returns the server message of the day
*/
@SideOnly(Side.SERVER)
public String getMotd()
{
return this.motd;
}

2 getters, juste un avec des minuscules et un autre avec des majuscules.

ligne 1227
public void setMOTD(String p_71205_1_)
{
this.motd = p_71205_1_;
}

Ce dernier getter est inutile puisque le motd est géré par un autre composant, celui-ci sert juste au démarrage du serveur.

Même getters inutiles :
Entity.class

public UUID getUniqueID()
{
return this.entityUniqueID;
}

ligne 1567

public UUID getPersistentID()
{
return entityUniqueID;
}

Même résultat différent nom.

PS : ce topic n’est pas fait pour insulter Mojang ou Minecraft, c’est juste un moyen de regrouper toutes les choses étranges de Minecraft.

Laserflip33

On pourrait recopier la quasi-totalité des classes de Minecraft sur ton sujet tellement c’est bien fait.

Diangle

@‘Laserflip33’:

On pourrait recopier la quasi-totalité des classes de Minecraft sur ton sujet tellement c’est bien fait.

Il y a des mécanismes qui sont bien. C’est sur le code aurait besoin d’être un peu plus clean et un peu plus optimiser, mais bon (on peux pas tous avoir).

SCAREX

Les mécanismes sont bons, mais si le code était plus propre, ce serait plus facile de modder. Comme par exemple avec l’EntityThrowable : on peut rien faire avec car toutes les valeurs sont en private alors que çà coûte rien à Mojang de les mettre en protected, résultat on est obligé de recopier la classe entièrement. Et y’a aussi d’autres problèmes : la 1.7 est là pour supprimer le fait de récupérer un joueur en fonction de son pseudo mais si tu regardes la classe EntityThrowable, Mojang utilise encore le nom du joueur.

Ramech

Oui je suis d’accord, lorsque j’ai du créer une nouvelle torche de redstone, j’ai du recopier en intégralité le code de cette torche ._.

RedRelay

C’est pour la backward compatibility
Oui j’explique du code fantôme par une notion qui n’existe pas dans Minecraft
Ce que je dis est donc faux, c’est du troll.

SCAREX

Nouvelle trouvaille :
La méthode getItemInUseDuration n’est disponible seulement côté client alors qu’elle utilise des valeur qui existent côté client ET serveur

/**
* gets the duration for how long the current itemInUse has been in use
*/
@SideOnly(Side.CLIENT) // Le SideOnly qui énerve
public int getItemInUseDuration()
{
return this.isUsingItem() ? this.itemInUse.getMaxItemUseDuration() - this.itemInUseCount : 0;
}

Donc si vous voulez savoir savoir depuis quand l’item est utilisé, il faut passer par l’ObfuscationReflectionHelper :

public static int getItemInUseDurationForPlayer(EntityPlayer player) {
return player.isUsingItem() ? player.getHeldItem().getMaxItemUseDuration() - (Integer) ObfuscationReflectionHelper.getPrivateValue(EntityPlayer.class, player, "itemInUseCount") : 0;
}

Tout çà à cause d’un SideOnly qui ne devrait pas être là.

jglrxavpok

Il me semble que les SideOnly sont gérés par FML/Forge

Superloup10

Les SideOnly sont rajouter par Forge et non par Minecraft

Envoyé de mon Nexus 4 en utilisant Tapatalk

SCAREX

Oui mais il devrait pas être à cet endroit de toute façon

Superloup10

S’il a été mis, c’est sans doute pour une bonne raison.

Envoyé de mon Nexus 4 en utilisant Tapatalk

SCAREX

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

robin4002

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.

SCAREX

Sauf que là çà devrait pas être le cas, comme j’ai dit, mon code static fonctionne côté serveur.

robin4002

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.

jglrxavpok

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.

w67clement

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%

robin4002

+1 xavpok. J’espère qu’ils ne seront plus là en 1.9.

SCAREX

@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.

SCAREX

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.