05-04-2015, 05:18 PM
Generally, consider chunks a tri-state thing. Either you have a nullptr, which means you don't really have anything. Or you have a pointer to a cChunk, but the instance is not valid (IsValid() returns false, cpInvalid or cpQueued); this means that the chunk is allocated, but its data hasn't been loaded from disk / generated yet. And the third state is when the chunk is fully operational with all its data available (cpPresent).
Chunks are stored in a cChunkMap object, which takes care of the spatial management. It provides coord-to-cChunk mapping (using a two-level hierarchy, hence the cChunkMap::cChunkLayer class, which stores a 32 * 32 area of chunks) and has the master mutex for accessing the chunks. Chunks are accessed by various threads - the world tick thread, the generator thread, the world storage thread. Each of those locks the mutex, of course. This makes the mutex kinda central in the whole server; whenever there is a deadlock, you can be pretty sure that this mutex is involved.
The cChunk instance that is passed to cEntity::Tick() is always valid (because it's the chunk from whose Tick() method the entity's Tick method is called). However, the entity physics code moves the entity according to its speed, gravity etc., and this may move the entity out to a different chunk; that chunk is not guaranteed to be valid (we should fix this - disable moving into a chunk that is not cpPresent).
You should be able to call a_Chunk->GetNeighborChunk() whenever you have a cChunk instance, it doesn't need to even be a valid (loaded) chunk. But note that it may return a nullptr when it cannot reach the neighbor. The function should never crash for any input data.
Chunks are stored in a cChunkMap object, which takes care of the spatial management. It provides coord-to-cChunk mapping (using a two-level hierarchy, hence the cChunkMap::cChunkLayer class, which stores a 32 * 32 area of chunks) and has the master mutex for accessing the chunks. Chunks are accessed by various threads - the world tick thread, the generator thread, the world storage thread. Each of those locks the mutex, of course. This makes the mutex kinda central in the whole server; whenever there is a deadlock, you can be pretty sure that this mutex is involved.
The cChunk instance that is passed to cEntity::Tick() is always valid (because it's the chunk from whose Tick() method the entity's Tick method is called). However, the entity physics code moves the entity according to its speed, gravity etc., and this may move the entity out to a different chunk; that chunk is not guaranteed to be valid (we should fix this - disable moving into a chunk that is not cpPresent).
You should be able to call a_Chunk->GetNeighborChunk() whenever you have a cChunk instance, it doesn't need to even be a valid (loaded) chunk. But note that it may return a nullptr when it cannot reach the neighbor. The function should never crash for any input data.