In the backporting guidebook, there is mention of BlockStates (or lack thereof) in 1.7.10. I was thinking that defaulting to using EndlessIDs to build the mod from could help alleviate that issue significantly, as it provides close to 66000 extra block metadata I believe. https://github.com/GTMEGA/EndlessIDs
Maybe helpful, maybe unnecessary. Just a thought I had!
4.1. BlockState - the elephant in the room
BlockState is one of the best features of Minecraft 1.8+. Before this update one block was only able to have 16 different states, which was handled by its metadata - an integer stored along with the block. Addition of BlockStates changed that, allowing developers have virtually infinite amount of states for every block. For example, prior to 1.8 repeater and lit repeater were two different blocks, because having both 4 different lengths of delay and 4 different directions took all 16 of its possible metadata values, leaving no room for on/off state. After the 1.8. update these two blocks were merged.
So what should you do when dealing with a BlockState?
Firstly - calculate the total amount of its states. If it's 16 or lower - there's nothing to worry about. You just need to write a few methods to get block's state from its meta and vice versa. For example all the rotations of shafts and gears in ReCreate are contained within their metadata.
If the amount of states of the block is higher then 16 then one of the parameters should be moved to the block's tile entity. Such is the case for belts in ReCreate: their rotations are stored in metadata, but directions and casing material is stored in the tile entity.
In the backporting guidebook, there is mention of BlockStates (or lack thereof) in 1.7.10. I was thinking that defaulting to using EndlessIDs to build the mod from could help alleviate that issue significantly, as it provides close to 66000 extra block metadata I believe. https://github.com/GTMEGA/EndlessIDs
Maybe helpful, maybe unnecessary. Just a thought I had!