You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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
The text was updated successfully, but these errors were encountered:
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.
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:
but I will override that and use any single block defined in:|
which, instead of using the standard recipe notation will dynamically register a recipe based off of that described in #27
The text was updated successfully, but these errors were encountered: