The interface for set should access the color and then allow you to draw for each piece type. The choice of set is deliberate so you can't play on a board with matching sets, and so the board knows which set goes where. If people gripe, maybe I'll make that dynamic, but I see no immediate benefit.

I will allow (and make) some custom sets, but will try to load dynamic sets via a JSON file that is consistent with existing block and texture notations:

e.g.

assets/chessmod/models/block/chesspieces/setname/pawn.json
assets/chessmod/models/block/chesspieces/setname/knight.json
assets/chessmod/models/block/chesspieces/setname/bishop.json
assets/chessmod/models/block/chesspieces/setname/rook.json
assets/chessmod/models/block/chesspieces/setname/king.json
assets/chessmod/models/block/chesspieces/setname/queen.json
assets/chessmod/textures/block/chesspieces/setname/material.png
assets/chessmod/textures/block/chesspieces/setname/material.png.mcmeta

I'll support the animation notation for the textures with the material.png.mcmeta notation (the file is optional).

The blocks will be scaled to 3/32 but I'll examine the models and use the piece height to adjust each TileEntity's collision box. I'll support the standard JSON notation until (or unless) I find a way to dynamically interpret things using the other notations.

The basic piece implementations that I have now will be the default available and will speficy their own setname

Pieces and complete sets will be registered when found, with an optionally defined item tile for the bag 'o pieces (the complete set) and the standard tile-rendered version of pieces defined in the block subset. Recipes of pieces will live in:

data/chessmod/recipes/setname/pawn.json

but I will override that and use any single block defined in:|

data/chessmod/recipes/setname/set.json

which, instead of using the standard recipe notation will dynamically register a recipe based off of that described in #27