12-10-2019, 06:13 PM
I don't think basing it on the generator queue length is a good idea - the chunks are only generated once, so when the players walk over already-generated chunks, the view distance would grow very large. I'd base the view distance on cWorld:GetNumChunks().
As I said, lowering the view distance doesn't affect the chunks that are already loaded in the client, so perhaps that was giving you the wrong idea? Also note that the client usually needs more chunks generated than are actually sent - the lighting calculation needs the neighboring chunks, so to send 1 chunk to the client, its 8 neighbors need to be generated as well.
The world's max view distance is clamped between 1 and 32, then each client's view distance is clamped between 1 and world's max view distance (but only when calling cClientHandle:SetViewDistance()). Setting the world's max view distance doesn't have any effect on already connected clients for whom the SetViewDistance() is not called! (Consider this a bug). Also changing worlds doesn't currently affect client's view distance (another bug).
As I said, lowering the view distance doesn't affect the chunks that are already loaded in the client, so perhaps that was giving you the wrong idea? Also note that the client usually needs more chunks generated than are actually sent - the lighting calculation needs the neighboring chunks, so to send 1 chunk to the client, its 8 neighbors need to be generated as well.
The world's max view distance is clamped between 1 and 32, then each client's view distance is clamped between 1 and world's max view distance (but only when calling cClientHandle:SetViewDistance()). Setting the world's max view distance doesn't have any effect on already connected clients for whom the SetViewDistance() is not called! (Consider this a bug). Also changing worlds doesn't currently affect client's view distance (another bug).