BlockState breaking the API - Printable Version +- Cuberite Forum (https://forum.cuberite.org) +-- Forum: Cuberite (https://forum.cuberite.org/forum-4.html) +--- Forum: Development (https://forum.cuberite.org/forum-13.html) +--- Thread: BlockState breaking the API (/thread-3344.html) |
BlockState breaking the API - 12xx12 - 03-11-2021 So the BlockState PR is gonna break the API in some ways. So how are we gonna go about it? There is a function convering BlockState <-> BlockType, NibbleType. We can manually export all the functions manually. (I don't like this - just carrying old stuff with us) We can just dump everything (and when at it dump all the vector 3 overrides) and we have to think about how we interface with the new BlockState - Construct from String - Export the whole BlockState stuff to API (then autogenerate the BlockState API Docs) RE: BlockState breaking the API - NiLSPACE - 03-11-2021 This might be a long shot, but can we replace all E_BLOCK_XYZ global variables to have a blockstate variable instead of the integer we have now? I'm not sure how we would handle nibbletypes with that though. Something like this in manual bindings: tolua_constant(tolua_S, "E_BLOCK_AIR", Block::Air::Air()); ... RE: BlockState breaking the API - 12xx12 - 03-11-2021 (03-11-2021, 09:43 PM)NiLSPACE Wrote: This might be a long shot, but can we replace all E_BLOCK_XYZ global variables to have a blockstate variable instead of the integer we have now? I'm not sure how we would handle nibbletypes with that though. Actually the method Block::Air::Air() returns a short. so that might actually work for the present blocks RE: BlockState breaking the API - NiLSPACE - 03-11-2021 There might be a few problems though. As I understand it a blockstate represents what we currently use two variables for (blocktype and blockmeta/nibbletype). Methods that currently require those two variables could have problems. We could add deprecated bindings for those to automatically convert the old blocktype/meta variables into a blockstate. To be honest, while backwards compatibility is nice, this is such a huge architectural change which we need to move forward that I'm fine with a somewhat lacking compatibility layer like deprecated bindings which translate blocktype/meta on the fly. |