Setting the dynamic view distance max to a 5-digit value and being the only player in a low load area allows the view distance to rise indefinitely, but going into a higher load area (with some mobs ticked around) the view distance is, for some reason, decreased (though it's proven that it has little to no perfomance impact & is not the source of the load in the scenario).

A better suggestion name here would be to manage the 4 options depending on which one of the attached factors pressures the server most, instead of in a set in stone order.

I would like to make this part configurable at some point, if I can find a clean way to do that.

Regardless though, view distance already has the lowest priority to be modified by the mod.
View distance won't lower unless the simulation distance is at its minimum value, and this works the same for other values.

The current "set in stone order" is:

1. Chunk-tick distance (randomticks & mobspawns)
2. Mobcap multiplier
3. Simulation distance
4. View distance

If it is modified, that would most likely mean your simulation distance is already at or below its set minimum value.

Modifying them depending on what factors pressure the server the most at a specific time would be difficult, as it would need to measure all these different factors every tick and how long they take, which I feel is a little bit out of scope for this project. It would also need a ton of time to figure out how to finetune everything so it doesn't affect certain settings when they (probably) shouldn't. It would likely still be inconsistent and unreliable, even when finetuned.

Apologies for the late response.

I'm not entirely sure what you mean specifically by locking them to eachother proportionally, its a bit vague.
The main reason why it only does 1 at a time is because if it changes multiple at a time, from my experience it often overshoots the "exact" value we really want. Especially so with (relatively large) fluctuations in tick time, which are pretty common.

Thats also why I'm not sure if its worth 'trying' to immediately set it to the perfect value instantly, since the calculated value will almost never be perfect.

The other thing is how much of a requirement it really is to move values by more than one at a time. Back when a similar system I made (back then using scarpet) did exactly that, it would overshoot the 'perfect values' way too often, hence why they're locked to eachother like this.

The only use case I can imagine is if some mod has some machine that is so incredibly laggy that once the chunks containing it are loaded, the server needs a very significant amount more time to process each tick. But in that case it would really be more of an issue with that specific mod, and often changing vanilla settings (or here dynamic settings) wouldn't really change that, besides maybe simulation distance but only to completely deactivate that machine.

If the main concern is just fluctuating playercounts, I've never really had problems using it for that purpose. At least not on a more vanilla-focused server, unless you consistently have over like 10 players joining and leaving every minute (on default config). If you want it to change settings faster there's also an option for that in the config, pretty sure the default is 15 seconds for everything that isn't viewdistance.

^^^^ @Wesley1808 please any comment on this?

Apologies for the late response.

I'm not entirely sure what you mean specifically by locking them to eachother proportionally, its a bit vague. The main reason why it only does 1 at a time is because if it changes multiple at a time, from my experience it often overshoots the "exact" value we really want. Especially so with (relatively large) fluctuations in tick time, which are pretty common.

Thats also why I'm not sure if its worth 'trying' to immediately set it to the perfect value instantly, since the calculated value will almost never be perfect.

The other thing is how much of a requirement it really is to move values by more than one at a time. Back when a similar system I made (back then using scarpet) did exactly that, it would overshoot the 'perfect values' way too often, hence why they're locked to eachother like this.

The only use case I can imagine is if some mod has some machine that is so incredibly laggy that once the chunks containing it are loaded, the server needs a very significant amount more time to process each tick. But in that case it would really be more of an issue with that specific mod, and often changing vanilla settings (or here dynamic settings) wouldn't really change that, besides maybe simulation distance but only to completely deactivate that machine.

If the main concern is just fluctuating playercounts, I've never really had problems using it for that purpose. At least not on a more vanilla-focused server, unless you consistently have over like 10 players joining and leaving every minute (on default config). If you want it to change settings faster there's also an option for that in the config, pretty sure the default is 15 seconds for everything that isn't viewdistance.

Yes, though it's a bit inconvenient that I can't set it below 1 second.
By locking them to each other I meant what I meant - if one changes, all others adjust proporionally. Would be a nice to have as an option.

@Wesley1808 I think the core issue behind this is that every update it's only one value moved by 1 in the direction of the ideal value, rather than setting it to the perfect value instantly.

Also, there is a way to at least balance out the 4 values - make an option to keep them locked to each other proportionally. Like, the mobcap is 14% of the chunk tick distance, which is 70% of the simulation distance, which is 35% of the view distance.

These two additions would make the dynamic feature perfect, making the server able to actually accurately adapt to different playercounts.

@Wesley1808 please respond here.

I might look into it in the future. But for now I'm rather busy with other things and its not very high priority.

I've made a few changes to the dynamic setting manager, you should now be able to (in addition to before):

• Easily disable specific settings from being modified automatically
• Modify the order in which the settings change
• Modify the value that settings increment with each update (ex. instead of decreasing by 1, decrease by 3)

I'm still not quite sure if its any good idea to modify 'linked' settings when its own settings change, makes things quite a bit more complex and I doubt it really helps.

I would also recommend not updating values every second, because the point of there being some time between updates is that we can measure the MSPT after each change, to see how it affects it. Otherwise that data is more or less going to stay the same and the server is gonna keep on lowering or increasing it without knowing if earlier changes already solved the problem. The new configurable incremental values should be a better alternative.