Extended Entity Properties
-
Niquel merci beaucoup robin exact erreur de débutant
et oui je vais passer par des tableaux XD -
Bonjour, je ne m’étais jamais rendu compte jusqu’à aujourd’hui, mais ce tuto n’a jamais été revu pour prendre en compte les uuid des joueurs, car là pour le moment, il enregistre les données en fonctions des usernames que contient la hashmap. De ce fait, si un joueur se déco, change son pseudo sur minecraft.net, puis revient, il aura perdu toutes ses données relatives
-
La hash map est utilisé pour la persistance des données lors de la mort.
Donc non, si un joueur se déconnecte, change de pseudo puis revient il n’aura rien perdu car lors de la déconnexion les données vont dans le nbt du joueur qui lui est bien lié à l’uuid.
Le tutoriel date aussi de la 1.7.2 (et il y a toujours écrit 1.7.2) à ce moment les uuid n’existait pas.
Les points qui me pose surtout problème, c’est l’utilisation des paquets de FFMT libs et le code de synchro qui n’est pas correct, ainsi que l’utilisation d’une map et deux event pour la persistance des données de la mort alors qu’il y a un moment plus simple en un event avec PlayerEvent.Clone.
Mais une fois de plus en 1.7.2 il n’y avait pas tout cela.
-
Je n’ai pas compris. Moi ce que je vois, c’est une hashmap qui traite les NBT en fonction du getDisplayName, du coup, j’ai dû mal à croire que ce soit bien saved peu importe le username. Malheureusement je ne vais pas m’amuser à changer mon pseudo, comme il y a un délai de 1 ou 2 mois il me semble, avant de pouvoir remettre l’ancien…
Par ailleurs, l’event EntityJoinWorldEvent synchro les NBT de l’extProp avec ceux de la HashMap, du coup j’ai dû mal à croire, que si on a un nouveau pseudo, la HashMap puisse avoir une entrée avec celui-ci, comme il s’agirait de notre première connexion. Au pire je te fais confiance, mais je n’aime pas coder à l’aveugle sans comprendre.
En fait, je n’ai surtout pas compris cette partie de ton message :
@‘robin4002’:car lors de la déconnexion les données vont dans le nbt du joueur qui lui est bien lié à l’uuid
Où vois-tu cela ? En tout cas, pas dans mon event handler ^^’
-
Donc tu n’as pas compris l’intérêt de la hashmap ni de l’event EntityJoinWorldEvent dans la situation ici présente.
Relis mon message précédent.La sauvegarde des données se fait via la fonction saveNBTData et loadNBTData de l’eep qui sont appelé par forge, qui lui envoie en argument un nbt qui est lié au fichier .dat du joueur (pseudo.dat en 1.7.2 et bien uuid.dat en 1.7.10).
-
Pour moi la HashMap servait à récupérer les NBT en fonction du joueur possédant répondant au username contenu dans l’entré, mais comme il semblerait que j’ai faux sur toute la ligne…
Sinon tu sais quoi, je vais essayer de reprendre depuis le début, y’a quelque chose que j’ai loupé. -
Lorsqu’un joueur meurt, les données sont sauvegarder dans la map.
Lorsqu’un joueur rejoint un monde (ce qui est le cas quand on respawn), si les données sont dans la map, il les restitues. C’est tout.La map ne gère pas la persistance quand le joueur se déconnecte, encore heureux sinon cela voudrait dire que le joueur perd tout si le serveur est redémarré ! (la map n’est que en ram).
-
Mdrr, + tu en rajoutes, + c’est flou…
Et que se passe-t-il quand le joueur meurt, se déco, que le serveur redémarre (on a donc la map qui se vide, hein ?), et que le joueur rejoint ? Il a bien tout perdu, non ? -
À mon avis, quand tu meurs, l’entité du joueur est toujours là avec les données enregistrées en NBT et elles restent jusqu’à ce que je joueur fasse respawn. Donc il n’y as pas de problème, comme les données on été enregistrés dans les NBT du joueur mort, le restart du serveur ne va pas faire perdre les données.
-
Dans ce cas, si l’entity du joueur ne disparaît jamais, pourquoi se servir d’une HashMap ? Elle est forcément passé à null je pense.
EDIT = Du coup j’en profite pour poser ma petite question ici : j’ai 2 joueurs sur un serveur, mais le client A ne semble pas connaître la valeur ds’un boolean quelconque enregistré chez le B. En revanche le B, joué en première personne n’a aucun problème de synchro entre client et serveur. Du coup comment résoudre ce genre de bug, où 1 client ne parvient pas à connaître les valeurs de l’ExtProp d’un client 2. Je pense que ça vient du serveur, j’ai tout de même essayé un sendToAll dans ma méthode sync, mais rien à faire
Merci d’avance ! -
Si lors de la mort le joueur clique sur se déconnecter au lieu de respawn et que le serveur est redémarré avant que le joueur ne revient il va en effet perdre les données, c’est le défaut de cette méthode.
-
Ah oui c’est problématique
Il faudrait enregistrer les différents objets NBTTagCompound aux données des joueurs correspondants, non ?
Ah nan, donc plutôt enregistrer la HashMap dans le dossier du serveur, ou carrément dans les NBT du monde ? -
Pour moi si on se déco avant de respawn après sa mort, ça doit quand même le sauvegarder dans le .dat, vu que si ya la gamrule de garder l’inventaire, on le garde quand même, on ne le perd pas.
Faudrait vérifier dans le code. -
Oui, mais en fait, c’est pas ça le problème ( je viens de comprendre pourquoi mon message était faut ) je problème est au niveau de la map. Dans le tuto, les données du joueur sont enregistrés dans la map quand le joueur meurt. Et sont restitués quand le joueur respawn. Donc si le serveur restart entre les deux, Ali s la map sera vide quand le joueur appuiera sur le bouton respawn donc les données ne seront pas restitués.
Comme solution, je pense que ce qu’on peut faire c’est : quand le joueur se connecte, si il est mort, alors on enregistre ces données dans la map.
-
Je comprend pas comment utiliser les packets qqn peux m’expliquer?
-
Salut,
Je t’invite à suivre le tutoriel dédié au réseau : https://www.minecraftforgefrance.fr/topic/1000/1-7-2-le-network -
@robin4002 merci
-
Y a-t il un tutoriel pour créer la classe d’évent ?
-
-
moi j’ai un problème au niveau de l’abstractPacket (dans mon packet) qu’il connait pas et RcMod (dans mon extandProp) et proxy (dans mon evenhandler) comment régler ses problème?
mon crash-report:
A detailed walkthrough of the error, its code path and all known details is as follows:
.---------------------------------------------------------------------------------------– System Details –
Details:
Minecraft Version: 1.7.10
Operating System: Windows 10 (amd64) version 10.0
Java Version: 1.8.0_202, Oracle Corporation
Java VM Version: Java HotSpot
64-Bit Server VM (mixed mode), Oracle Corporation
Memory: 1922093768 bytes (1833 MB) / 2112618496 bytes (2014 MB) up to 2112618496 bytes (2014 MB)
JVM Flags: 3 total; -Xincgc -Xmx2G -Xms2G
AABB Pool Size: 0 (0 bytes; 0 MB) allocated, 0 (0 bytes; 0 MB) used
IntCache: cache: 0, tcache: 0, allocated: 29, tallocated: 77
FML: MCP v9.05 FML v7.10.99.99 Minecraft Forge 10.13.4.1558 5 mods loaded, 5 mods active
States: ‘U’ = Unloaded ‘L’ = Loaded ‘C’ = Constructed ‘H’ = Pre-initialized ‘I’ = Initialized ‘J’ = Post-initialized ‘A’ = Available ‘D’ = Disabled ‘E’ = Errored
UCHIJAA mcp{9.05} [Minecraft Coder Pack] (minecraft.jar)
UCHIJAA FML{7.10.99.99} [Forge Mod Loader] (forgeSrc-1.7.10-10.13.4.1558-1.7.10.jar)
UCHIJAA Forge{10.13.4.1558} [Minecraft Forge] (forgeSrc-1.7.10-10.13.4.1558-1.7.10.jar)
UCHIJAA zombiecubefree{1.0.0} [Zombie Cube Free] (bin)
UCHIJAA examplemod{1.0} [examplemod] (bin)
GL info:ERRORRuntimeException: No OpenGL context found in the current thread.
Profiler Position: N/A (disabled)
Vec3 Pool Size: 0 (0 bytes; 0 MB) allocated, 0 (0 bytes; 0 MB) used
Player Count: 0 / 8; []
Type: Integrated Server (map_client.txt)
Is Modded: Definitely; Client brand changed to ‘fml,forge’
[15:12:43] [Client thread/INFO] [STDOUT]: [net.minecraft.client.Minecraft:displayCrashReport:393]: #@!@# Game crashed! Crash report saved to: #@!@# .\crash-reports\crash-2019-03-19_15.12.42-server.txt
AL lib: (EE) alc_cleanup: 1 device not closed
Java HotSpot 64-Bit Server VM warning: Using incremental CMS is deprecated and will likely be removed in a future release
