Lorsque vous travaillez avec des NBT dans des commandes, quel type de données est supposé lorsque les valeurs n'ont pas de suffixe alphabétique ?

Question

Disons que vous voulez invoquer un mouton qui brille. Vous choisirez probablement /summon minecraft:sheep ~ ~ ~ {Glowing:1b} . Et hé-ho, ça marche comme prévu. Des moutons lumineux.

Ensuite, pour faire un peu plus de bêtises et découvrir les types de données, vous essayez d'utiliser la fonction {Glowing:2b} . Le mouton brille toujours, donc, comme dans d'autres langues, les booléens fonctionnent en fait plus comme 0 et not 0 . Donc, pour continuer à baiser, hum, test ". - tu changes 2b a 2 . Aucun changement. Donc le jeu fonctionne avec des entiers droits quand il attend des octets. Et si nous dépassons la plage d'un octet ?

{Glowing:127} , mouton rougeoyant. {Glowing:128} ... toujours un mouton rayonnant ? Le nombre ne finit pas par s'enrouler autour de 0 jusqu'à ce que 256 . En le forçant à entrer dans un octet, il se transforme en 0 en 128b et -129b . Un test supplémentaire avec des moutons de couleur confirme que le numéro non marqué est non signé.

La page consacrée à ce sujet sur le site Wiki officiel de Minecraft ne montre aucun type de données non signées. Quelqu'un a-t-il une idée ?

Answer 1

Lors de la saisie de NBT, le type de données fourni n'a généralement pas d'importance. Il est automatiquement converti dans le type correct pour ce champ.

Les numéros réguliers deviennent int Ainsi, en saisissant par exemple 3000000000, la valeur déborde et devient négative, même si elle est ensuite convertie en une valeur long .

Les nombres avec des points décimaux deviennent double dont .0 et 0. .

Juste un . semble être accepté comme un nombre, mais je n'ai pas pu déterminer de quel type. Il joue avec d'autres nombres étiquetés " i ", mais cela ne devrait pas être un suffixe numérique. C'est étrange.

Dans les tableaux (comme Motion ), un seul type de numéro est accepté, même s'ils sont compatibles pour la conversion. Ainsi, [1.0,2.,3d] est accepté, mais [0.0,0.0,0.0f] ne l'est pas.

Apparemment, les tableaux ne convertissent pas les types de nombres entiers en types à virgule flottante. L'invocation d'une entité avec Motion:[1,0,0] ne lui donne pas de mouvement.

---

Les autres types sont triviaux : Array, compound et string. Ils n'ont pas de suffixe de type.

---

Passons maintenant à l'autre aspect des choses : Quand lecture NBT, vous devez faire correspondre le type correct. Parce que votre entrée est implicitement convertie en int o double si vous ne fournissez aucun suffixe de format et que seulement ensuite il est comparé avec le NBT existant, il échoue souvent.
Donc même si vous invoquez une entité avec Motion[0.0f,0.0f,0.0f] vous ne pouvez toujours pas le tester avec Motion[0.0f,0.0f,0.0f] vous avez besoin Motion[0.0d,0.0d,0.0d] .