10-08-2012, 05:45 PM
You're right, after all, those two should be separate. At first I thought that the checking should be a part of the ticking, but now it makes sense to have both ticking without checking and checking without checking.
An example why it shouldn't be combined: placing a torch next to crops would make the crops grow every time
But we definitely need to change the names. m_BlocksToTick actually has blocks to check. cBlockHandler::OnUpdate() actually does blockticks. And the block checking using three virtual functions could be reduced to one virtual function - OnCheck().
With this, blockticks don't need to be stored at all, they can still be random (except for the beginnning, so that the debugging plugin sTick works). but the blocks to check still need storage, so I'll rename cBlocksToTick to cBlocksToCheck
There's one more thing to this: scheduled blockticks ( http://www.minecraftwiki.net/wiki/Tick#Block_ticks , 2nd paragraph). These might be needed later on if we want our redstone implementation to be complete and compatible. These will need storage, but I won't be implementing them yet.
An example why it shouldn't be combined: placing a torch next to crops would make the crops grow every time
But we definitely need to change the names. m_BlocksToTick actually has blocks to check. cBlockHandler::OnUpdate() actually does blockticks. And the block checking using three virtual functions could be reduced to one virtual function - OnCheck().
With this, blockticks don't need to be stored at all, they can still be random (except for the beginnning, so that the debugging plugin sTick works). but the blocks to check still need storage, so I'll rename cBlocksToTick to cBlocksToCheck
There's one more thing to this: scheduled blockticks ( http://www.minecraftwiki.net/wiki/Tick#Block_ticks , 2nd paragraph). These might be needed later on if we want our redstone implementation to be complete and compatible. These will need storage, but I won't be implementing them yet.