Syndrôme du mob hyperactif

EclipseOnFire

@‘AlphaSwittleTeam’:

Merci à vous deux pour vos réponses rapides Par contre j’ai toujours le même problème x)

As-tu essayé de chercher ce qui pourrait se passer après la création de ton mob ?
Est-ce que la sauvegarde du mob (writeToNBT) ou la lecture (readFromNBT) sont correctes au niveau de la vitesse ?

Ama

Essaie mais alors c’est vraiment la technique Z, rajoute un 0 pas 0.2 mais 0.20 ? Ce qui te donnera 0.20D

Je sais pas si ça a avoir avec quelque chose mais bon

EclipseOnFire

@‘ZeAmateis’:

Essaie mais alors c’est vraiment la technique Z, rajoute un 0 pas 0.2 mais 0.20 ? Ce qui te donnera 0.20D

Je sais pas si ça a avoir avec quelque chose mais bon

0.2 == 0.20 == 0.200 == 0.2000. Désolé mais ça change rien x)

robin4002

0.000000002D ?

EclipseOnFire

@‘robin4002’:

0.000000002D ?

xD

Überfap

Et puis pourquoi pas ? x) Non je pense à un truc : je vais printer la vitesse du mob en jeu et on va tester ta théorie EclipseOnFire

EclipseOnFire

Je te déconseille de Sysout ça chaque tick, tous les 20 ticks c’est mieux

Überfap

Oui oui je vais faire ça quand j’aurais accès à Eclipse t’ta l’heure

Überfap

Up ! J’ai testé et ça me sort : 0.5D. Ta théorie était juste Eclipse mais comment remédier à ça ?

EclipseOnFire

@‘AlphaSwittleTeam’:

Up ! J’ai testé et ça me sort : 0.5D. Ta théorie était juste Eclipse mais comment remédier à ça ?

La première méthode consiste à repérer chaque modification extérieure sur le mob. Pour cela il faut remonter aux sources, simplement en mettant un code foireux dans la méthode setSpeed() (ou autre, j’ai pas eclipse sous les yeux) et dans le constructeur de ton mob, par exemple :

try{
int x = 1/0;
catch(ArithmeticException e){
e.printStackTrace();
}

Minecraft va bugger et tu vas obtenir un stackTrace qui te permettra de retrouver tous les codes qui modifient ton mob, n’oublies pas que ce code peut générer plusieurs StackTrace, il faut tous les lire. De là tu pourras voir où la vitesse de ton mob est modifiée et comment remédier à ce problème. Commence par le constructeur et examine le StackTrace (tu cliques sur les liens bleus dans la console). Si tu ne vois rien de suspect, enlève le code foireux du constructeur, met le dans la méthode setSpeed() et répète la précédente démarche.

On verra la deuxième méthode si celle-ci échoue.

Überfap

Non c’est bon merci de ton aide mais j’ai résolu le problème en réécrivant le code du mob

EclipseOnFire

@‘AlphaSwittleTeam’:

Non c’est bon merci de ton aide mais j’ai résolu le problème en réécrivant le code du mob

Ah d’accord, donc l’erreur venait du mob lui-même ^^.

Überfap

Même pas, elle venait de l’héritage du mob. J’ai une classe GenericMob que touts mes mobs ont pour héritage,et son spee est set 0.5D x)

robin4002

GG x)
Enfin bon je suis pas mieux, je suis resté bloqué hier sur un truc à la con car j’avais mit deux tag NBT du même nom pour deux valeurs différentes x)

Überfap

GG à toi, Robin ! Tu bats tous mes records ! A moins que…

EclipseOnFire

@‘robin4002’:

GG x)
Enfin bon je suis pas mieux, je suis resté bloqué hier sur un truc à la con car j’avais mit deux tag NBT du même nom pour deux valeurs différentes x)

Non j’ai mieux, et j’ai un témoin (toi), j’ai inversé les méthodes WriteToNBT et ReadFromNBT.
@‘AlphaSwittleTeam’:

GG à toi, Robin ! Tu bats tous mes records ! A moins que…

XD Non t’as pas vu mon prototype de balle ! En voulant supprimer tous les calculs de cosinus de la flèche pour supprimer l’effet de gravité, j’ai crée une météorite en forme de carré blanc (texture par défaut des mobs) qui se déplaçait dans tous les sens et qui explosait, sans mourir évidemment, chaque tick. Epic fail quoi… J’avais filmé mais j’ai supprimé la vidéo de ma Dropbox, depuis le temps…