Désactiver la deuxième main (et drop)

[Sala85]

Bonjour,
J'aimerais savoir comment désactiver le drop d'un certain item sur Minecraft (par exemple des blocs invisible dans l'inventaire) et comment l'empêcher d'être changer de slots.
Et j'aimerais également savoir comment faire pour désactiver la deuxième main.
J'utilise un spigot 1.16.1.
Code que j'ai essayé pour le drop des items (qui ne marche pas) :

 

[ShE3py]

Deux problèmes avec ta fonction actuelle :

• Tu ne peux pas affirmer que si un joueur drop un item, alors celui-ci est forcément dans sa main.
  Il est possible de dropper n'importe quel item de son inventaire en l'ouvrant, en déplaçant le stack hors de celui-ci sans passer par sa main.
  
  Tu dois utiliser PlayerDropItemEvent#getItemDrop().
  
  
• Les opérateurs d'égalité == et d'inégalité != ne fonctionnent que pour les primitives (boolean, int, long, etc.) et les énumérations.
  Sinon, c'est le pointeur qui est comparé, donc l'emplacement mémoire.
  Est-ce que blocinvi et inv.getItemInMainHand() sont stockés exactement au même endroit dans la mémoire ? Non, ce sont deux variables différentes, donc ta comparaison sera toujours fausse.
  
  Tu veux comparer la valeur qui est représentée à cet emplacement mémoire, tu dois donc utiliser .equals() à la place :
  

  if(inventory.getItemInMainHand().equals(barrier)) { ... }

  
  Seul problème, là tu compares si les deux stacks sont égaux, c'est-à-dire :
  • Même type (Material.BARRIER)​
  • Même quantité​
  • Mêmes enchantements​
  • Même durabilité​
  • Même nom​
  • Même description (lore)​
  • etc.​
  
  Or tu souhaites juste comparer le type ; tu n'as nullement besoin de créer un nouvel ItemStack.
  Donc :
  

  @EventHandler
  public void onPlayerDropItem(PlayerDropItemEvent e) {
  	if(e.getItemDrop().getItemStack().getType() == Material.BARRIER) {
  		e.setCancelled(true);
  	}
  }

  À noter qu'il s'agit là d'un == car il ne peut y avoir qu'un seul Material.BARRIER (impossible de faire new Material() puisqu'il s'agit d'une énumération).
  Je te conseille de faire pareil avec EntityPickupItemEvent afin d'empêcher que les joueurs puissent récupérer des éventuelles barrières au sol (au cas où un op meurt).

comment l'empêcher [l'item] d'être changer de slots

Avec InventoryClickEvent, lit bien la documentation car il y a plusieurs cas à gérer.

Et j'aimerais également savoir comment faire pour désactiver la deuxième main

Tu peux regarder le code source de plugins qui font déjà ça et t'en inspirer.

BukkitOldCombatMechanics/src/main/java/kernitus/plugin/OldCombatMechanics/module/ModuleDisableOffHand.java at b177662e38aea5f46678c64c4ddc099fccfde68b · kernitus/BukkitOldCombatMechanics

Spigot plugin to configure combat mechanics from 1.9 onwards - kernitus/BukkitOldCombatMechanics

github.com

J'utilise un spigot 1.16.1.

Spigot 1.16.5 utiliser, tu dois.

Cordialement,
ShE3py

 

[Sala85]

Ok merci.

 

[Niz]

Spigot 1.16.5 utiliser, tu dois.

Bonjour, l'API pour la 1.16.5 n'est pas la même que celle de la 1.16.1 ? (1.16)

 

[ShE3py]

Bonjour, l'API pour la 1.16.5 n'est pas la même que celle de la 1.16.1 ? (1.16)

La 1.16.2 effectue pas mal de changements niveau gameplay, comme l'ajout d'une nouvelle entité et de son œuf, donc un plugin 1.16.1 fonctionne sur une base légèrement différente que la 1.16.2, donc après c'est au choix mais je ne pense pas qu'il ait explicitement choisit de vouloir rester en 1.16.1 plutôt qu'en 1.16.5.

De plus comme d'habitude les autres versions mineures (1.16.2-1.16.5) corrigent quelques bugs donc c'est un peu débile de ne pas les vouloir, et les développeurs ne mettent généralement pas les anciennes versions à jour ; par ex. la dernière version de Forge date d'il y a 7 jours pour la 1.16.5, contre 10 mois pour la 1.16.1 ; Spigot doit probablement faire la même chose.

Après pour répondre à la question, autre l'ajout de quelques constantes dans l'API (EntityTypes.PIGLIN_BRUTE, etc.), l'API sera à 99% la même, mais après c'est plutôt au niveau de l'implémentation derrière qu'il peut y avoir éventuellement des modifications, et c'est toujours mieux de faire un plugin dans la même version qu'il sera utilisé pour éviter les mauvaises surprises, et dans le cas d'un plugin public 1.16, il sera probablement plus utilisé en 1.16.5 qu'en 1.16.1.