5. Item complexe : gui, bouton, packet et model custom

Item complexe : gui, bouton, packet et model custom


  • Résumé de tout ce sujet : ( Résumé de tout ce sujet : )

    Page 1 : fonctionnement des boutons et utilisation des packets
    Page 2 : synchronisation des items serveur - client
    Page 3 : synchronisation des items client - gui
    Page 4 : model d'item custom en fonction du NBTData
    Page 5 : model d'item custom en fonction du NBTData et rendu d'un item dans un gui avec un taille custom

    Premier poste 😞 Premier poste 🙂

    Salut tout le monde !

    Je suis en trains de créer un nouvel item ( un pierre sur laquelle on pourra graver des signes pour faire une rune ) mais le gui qui vas avec est assez compliqué.
    Je créé donc ce sujet pour pouvoir poser toutes mes questions et mes problèmes.
    J'ai déjà pas mal de questions donc je vais les poser au fur et à mesure que les anciens problèmes soit résolus.
    Tout d'abord, je poserais des questions sur ce qui ne fonctionne pas puis sur ce qui peut éventuellement être simplifié.

    Voici les deux premières questions :

    • sur mon gui il y a des buttons, je voudrais savoir si on est obligé de passer par des packets pour envoyer le bouton sur lequel on clic à l'IInventory / à l'item. Y a-t-il un moyen de passer directement à l'inventaire ou en passent par le container ?

    • si je suis obligé de passer par un packet, comment à partir du packet connaitre celui qui l'a envoyer ? Car si j'enregistre le joueur dans le packet, n’importe qui pourrais mettre quelqu'un d'autre à la place du joueur.( Par exemple, si le bouton c'est un bouton suicide, ça peut poser des problèmes car un joueur peut envoyer au serveur qu'un autre joueur à cliquer sur ce bouton alors que ce n'est pas vrais. )

    0

    1. ça dépend si tu gères l'action des boutons côté server (obligé) ou côté client (inutile).
    2. Dans la méthode qui reçoit le packet (je sais plus son nom), tu as un MessageContext, il a deux fonctions pour récupérer le netHandlerPlay <server client="">qui contient le joueur correspondant, tu as juste à utiliser la fonction correspondant à la side où tu recoit le packet (donc Server).</server>
    0

  • @'AymericRed':

    1. ça dépend si tu gères l'action des boutons côté server (obligé) ou côté client (inutile).
    2. Dans la méthode qui reçoit le packet (je sais plus son nom), tu as un MessageContext, il a deux fonctions pour récupérer le netHandlerPlay <server client="">qui contient le joueur correspondant, tu as juste à utiliser la fonction correspondant à la side où tu recoit le packet (donc Server).</server>

    Merci pour ta réponse ! Mais comment fait-on pour gérer les boutons coté serveur ?

    0
  • Administrateurs

    Salut,
    Les boutons sont forcement coté client, le serveur n'a pas d'interface graphique.

    En passant dans ton post tu as écrit qui au lieu de gui.

    0

  • Si tu veux gérer les boutons sur le serveur, il faut que t'envoie un packet, mais c'est plus simple à gérer sur le client et ça ne sert à rien dalourdir le serveur avec ça

    Envoyé de mon RAINBOW LITE 4G en utilisant Tapatalk

    0

  • Donc, étant donné que mon bouton agit sur l'inventaire du joueur et sur le NBTTag de l'item, je suis obligé de passer par un packet ?
    Et dans ce cas, on en vient à la question 2,  et là, je vais essayé ce que tu m'a envoyé, AymericRed.

    0

  • Nouvelle question :

    A partir du packet, pour avoir accès à l'IInventory de l'item, je doit l'enregistrer(enregistrer l'IInventory) dans l'item ?

    D’ailleurs, comme il n'y a pas de slot à mon gui, est-ce que c'est utile d'avoir fait un IInventory et un container custom ?

    Edit : il y a bien des slots des mon gui mais ce ne soit que les slots de l'inventaire du joueur, donc je pence qu'il faut forcément un container mais pour l'IInventory custom, je pence que c'est inutile.

    0
  • Administrateurs

    En effet pas besoin d'inventaire dans ce cas.

    0

  • @'robin4002':

    En effet pas besoin d'inventaire dans ce cas.

    C'est bien ce que je pensais.

    J'ai entendu parlé du block try/catch pour les packets, donc je voilais savoir si il y en a encore besoin en 1.8.9 et si il y en a encore besoin, où est-ce qu'il faut les mettre et pourquoi ?

    0

  • Il n'y a pas besoin de bloc try/catch, si il y a une erreur, Forge la catchera, mais tu peux toujours en mettre, par exemple si tu veux print plus d'infos (la position, le joueur…).

    0

  • @'AymericRed':

    Il n'y a pas besoin de bloc try/catch, si il y a une erreur, Forge la catchera, mais tu peux toujours en mettre, par exemple si tu veux print plus d'infos (la position, le joueur…).

    Ok, merci pour l'information.

    0

  • Maintenant, le packet fonctionne mais il y a un problème de synchronisation : quand le serveur reçoit un packet :
     - Il enlève un item de l'inventaire du joueur mais on ne le vois que si on ferme le gui puis qu'on en rouvre un nouveaux.
     - Il modifie un NBTTag d'un autre item mais même si on ferme et rouvre l'inventaire, le NBTTag coté client ne change pas.

    Je me demande donc - si il y a une fonction pour resynchroniser l'inventaire,
                                 ou - si le serveur doit renvoyer un packet avec un boolean pour dire au client qu'il doit ou non faire les modifications.

    0
  • Administrateurs

    player.inventory.markDirty()

    ça devrait résoudre le soucis.

    0

  • Où est-ce que je doit le mettre ? J'ai essayé dans lorsque le serveur reçoit le messages, après les modification de l'inventaire et j'ai aussi essayé après l'envoi du packet par le client mais aucune des deux manière ne fonctionne.

    0
  • Administrateurs

    Après avoir effectué les modifications, côté serveur.
    Cette fonction met la booléan inventoryChanged sur truc, étrange que cela ne fonctionne pas.

    0

  • Sinon tu fais aussi les mêmes modifs sur le client avant/après avoir envoyé le packet.

    0

  • @'AymericRed':

    Sinon tu fais aussi les mêmes modifs sur le client avant/après avoir envoyé le packet.

    Oui mais j'aimerais bien ne pas avoir à mettre toutes les conditions ( ça ma fait environ 50 lignes) du coté client, ce serais plus simple si je pouvait utiliser player.inventory.markDirty().

    J'ai mis System.out.println(playerInv.inventoryChanged); pour savoir si la fonction markDirty() fonctionnais bien et c'est bon, ça m'affiche true ( quand je met la fonction après les modifications coté serveur. ) mais j'ai l'impression que markDirty() seul ne sert  rien car tout ce que ça fait c'est mettre le boolean inventoryChanged sur true et quand on regarde le description de cette variable, il y a marqué :
    Set true whenever the inventory changes. Nothing sets it false so you will have to write your own code to check it and reset the value.

    Donc j'ai l’impression que je doit faire une fonction qui détecte si inventoryChanged est true et qui dans ce cas synchronise le client et le serveur et on reviens à la question initiale : comment synchroniser le client avec le serveur.
    Donc je fais essayer de faire la deuxième solution coté client.

    0

  • J'ai une nouvelle question qui se compose de deux parties !

    - Pour modifier le model d'un item selon une certaine propriété, je voudrais savoir se qui est le plus simple entre enregistre cette propriété dans les NBTTag ou dans les Metadata ?
     - Pour le model, comme il y à des tonnes do possibilités, je voudrais savoir si c'est mieux de passer par un model custom (plutôt que faire un model par possibilité) donc je voudrais savoir comment faire un model custom qui, en fonction du NBTTag ou du MetaData, vas être différant.

    PS : Pour la question précédente, je vais tr,ter de passer par une réponse du serveur en envoyant un message au client pour qu'il fasse les modifications.

    0

  • C'est plus simple avec metadata, il y a une fonction pour return un model en fonction de ça regarde dans l'arc

    Envoyé de mon RAINBOW LITE 4G en utilisant Tapatalk

    0

  • J'ai trouvé la fonction ```java
    ModelResourceLocation getModel(ItemStack stack, EntityPlayer player, int useRemaining)

    0
1.8.9 85