@‘robin4002’:
Pour les événements appelé de tant en temps ça devrait aller.
Par contre pour les événement appelé à chaque tick j’éviterai de faire des appels en cascade.
Concernant les proxys, j’ai pris l’habitude d’utiliser ClientProxy pour tout ce qui est client seulement et ServerProxy (que je nomme en plus CommonProxy …) pour le serveur seulement. C’est une mauvaise habitude que j’ai pris car les premiers tutoriels que j’avais suivis était comme ça (et du-coup je répands ma mauvaise habitude dans les tutoriels, bravo Robin x))
Je dis mauvaise habitude car il est incohérent de nommé CommonProxy quelque chose qui ne sert que le pour le serveur.
En fait une manière plus propre de faire serait d’avoir 3 classes. Une classe CommonProxy qui est utilisé pour l’instance dans la classe principale, une classe ClientProxy qui est indiqué dans l’annotation @SidedProxy et est une classe fille de CommonProxy et une classe ServerProxy qui comme ClientProxy est utilisé dans @SidedProxy et est une classe fille de CommonProxy. Chaque fonction du CommonProxy sont override dans ServerProxy et ClientProxy et elles ont en plus un super.nomDeLaFonction(); pour exécuter la fonction dans CommonProxy.
Avec un tel choix les fonctions dans CommonProxy seront toujours exécuté, celle de ClientProxy seulement dans le cas du client et ServerProxy seulement dans le cas du serveur dédiée. Les noms des classes seraient alors beaucoup plus cohérent.
Je pense que je vais utiliser cette façon de faire dans les tutoriels 1.8 et +.
Ça me semble être la meilleur solution ! 😄 Ça résould tout ! 😄
