Idée
Supposons :
- id1 = ID du bloc sans tenir compte des BS (les ID se suivent)
- id2 = ID du block en tenant compte du BS (en gros, c'est ce qu'on a actuellement dans la Glib-Core > module 'block', et les ID se suivent également)
Évidemment dans ces conditions, block.id1 =/= block.id2
- qu'on ai un système BS -> NBT
- qu'on ai un système block -> id1
- qu'on ai un système id1 -> id2
A ce moment là si on veut modifier un BS d'un block, on utilise BS -> NBT, on stock le NBT résultant, puis on utilise block -> id1 suivit de id1 -> id2, ce qui nous donne le premier "id2" du bloc en question (parmi toutes les variations de ce-dit bloc).
De là, on fait un id2 -> block en boucle suivit de BS -> NBT et block -> id1 en incrémentant id2 à chaque fois jusqu'à ce que :
- le nouveau NBT soit égale à celui qu'on a stocké au début -> Le système a réussi à éditer le BS
- le block ne corresponde plus à celui désigné par id1 initial -> Le système n'a pas pu editer le BS car la combinaison indiqué par le NBT n'existe pas sur le bloc indiqué par l'id1
Exemple - Mettons qu'on ai un block d'escalier suivant :
cobblestone_stairs[facing=west,half=bottom,shape=straight,waterlogged=false]
On veut changer l'état de son facing pour le mettre sur north
Du coup :
- On fait BS -> NBT ce qui copie les blockstate dans un NBT qu'on stock quelque part
- On modifier ce NBT stocké pour appliquer la modification qu'on veut (en l'occurrence, changer facing en north
- On utilise block -> id1 pour récupérer l'id "simple" du bloc de cobblestone_stairs
- On utilise id1 -> id2 pour avoir le premier id "complexe" (incluant les blockstate) correspondant au block de cobblestone_stairs
- On fait un id2 -> block ce qui va placer un block de cobblestone_stairs avec des BS inconnus
- On fait un block -> id1 pour s'assurer que le bloc placé soit toujours un bloc de cobblestone_stairs (sinon ça sert à rien)
- On utilise BS -> NBT pour connaitre les BS de ce bloc
- On compare ces NBT avec ceux qu'on cherche à avoir (ceux qu'on a stocké à l'étape 1 et modifié à l'étape 2)
- Si l'étape 6 n'a pas posé de problème et que le test de l'étape 8 n'est pas concluant, alors on incrémente id2 et on revient à l'étape 5
Si à la 6 ème étape on a un score id1 différent de celui obtenu à l'étape 3, alors le système s'arrête cr ça signifie qu'il a testé toutes les variatiosn du bloc en question sans jamais tomber sur la combinaison de blockstate voulu.
Si en revance à l'étape 6 on a toujours le même id1 et qu'en plus à l'étape 8 les deux NBT sont identiques, alors on a réussi à éditer le blockstate.