Server Render Distance Based on Current Players

[N8-Ball]

So I run my Cuberite server on a Raspberry Pi. As such I can't support many players and a high render distance at same time. But a high render distance would be nice when alone on the server. Would it be possible for a plugin to change the server render distance based on the number of current players in the server without restarting?

[xoft]

Hello, welcome to the forum.

Such a plugin would be already half-possible with the current API. The render distance (called View Distance in our code) is settable on a per-client basis through cClientHandle:SetViewDistance(); it is clamped to the world's max view distance (cWorld:SetMaxViewDistance()). However, just setting the view distance will NOT unload the chunks that were already loaded for the client and it will not load new chunks; it will only affect loading and unloading while the player moves around. This may be insufficient for your use case. There are internal methods that load and unload chunks (cClientHandle::StreamNextChunk(), cClientHandle::UnloadOutOfRangeChunks()), we might export them to the API for plugins to use.

[N8-Ball]

Those api commands actually sound perfect for my use case. I have coding experience so if I do a bit of research on lua, I should be able to make a plugin for that. I'll make sure to post the plugin if I get it to work!

[N8-Ball]

So I tried it out, slightly modifying my original design where instead of basing the view distance of the number of players, I based it off the number returned by cWorld:GetGeneratorQueueLength(). Basically I had it so that the cWorld:SetMaxViewDistance() was dropped by 1 repeatedly until the number of chunks in the queue was less than 20. This worked as confirmed by cWorld:GetMaxViewDistance() which returned a 1 after repeated drops, however on the client side it was very clear that the render distance hadn't actually changed to 1 and the chunks in the queue continued to climb rapidly as they moved (indicating a view distance more in line with 10). Does cWorld:SetMaxViewDistance() clamp the cClientHandle:SetViewDistance() in real time or only when the client connects?

[xoft]

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).

[N8-Ball]

Ok, thank you for the response, that makes sense. The idea I had was that I wanted to decrease the chunks the server had to load or generate when a player was moving a large distance quickly (i.e. boats, minecarts, or just sprinting), so I had the idea that the chunks generated at one time gave a good estimate of how much players were moving around (I see why this doesn't work now). The PI I'm running on can handle normal server functions with a decent view distance (basically the chunk number isn't the problem, it's the process of loading them), but if players are moving quickly with a high view distance, the server can't keep up, even with loaded (non-generated chunks). I'll keep looking into it, maybe something to check player movement speed and decreasing their view distance until they slow down and then slowly raising it back up, but I'll look into other things as well.

[N8-Ball]

I've finished the plugin and have gotten fantastic results! The server runs super smooth using this plugin on Raspberry Pi 3B, almost never even approaches 100% CPU (used to hit 250%). I'm just going to clean up the code and put some comments and then I will post the plugin for everyone.