cBlocksToTick

[xoft]

UPDATE: This whole idea was wrong and has been scratched, never to be revived again

This thread is only to document what I'm doing at the moment; I'll put a link to this thread into the source so that if anyone wants to touch the source, they'll know what I meant to do

Current blockticking in MCS is rather chaotic. Each chunk has a list of blocks that it wants to "check", and then a coord triplet where to start random blockticking.
"Checking" means that the block is checked if its surroundings allow it to stay (cBlockHandler::CanBeAt() ), if not, the block is dropped.
"Blockticking" means picking 50 random coords and calling cBlockHandler::OnUpdate().

I believe this should be merged together. So there should be a list of blocks "to be ticked"; each block should then be both checked and updated. And since this is gonna be called 20 times per second for each live chunk, it needs to be fast. Therefore it's a bad idea to make the list dynamically-allocated.

I'll be making a cBlocksToTick object that will represent the list of block coords to tick. This object will have a fixed number of coords that it can take without dynamic memory allocation, and an overflow area just in case there are more blockticks at the time.
Each chunk will have two pointers to two such objects. One will be written to when a blocktick is requested; the other one will be "waiting in queue". When the tickthread wants to tick the chunk's blocks, it will swap the two pointers and use the inactive one for reading and the active one for writing (many blocks, when they update, schedule more blockticks) (<-- doublebuffering, more or less )

---

It seems reasonable that the cBlocksToTick will have a Tick() method that will tick all the coords stored in the object - because it's simpler to iterate over the elements that I own than exporting some kind of an iterator to an external object. Additionally, it will make possible some optimizations, such as calculating the chunk base coords for adding to the relative coords only once.
This method will take all the parameters needed to call all the blockticking handler functions.

[FakeTruth]

Block ticking can be pretty CPU intensive because it happens so much, why do you want to add block "checking" to that? Checking only needs to happen when a block changed AFAIK

[xoft]

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.

[FakeTruth]

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.

Ah interesting, I never thought about it like that.
I did implement something similar in the redstone simulator, but it is limited to and specifically for repeaters.