Conversation
|
I hope this PR will also help players manage performance, as level maintainers can be noticeably performance-heavy. I was also thinking about adding an option in the config to set the minimum and maximum refresh rates, so server owners can increase the minimum level if needed to make them more manageable performance-wise. |
|
With this PR, The old global The main issue is if i load the old default minimum was too aggressive. If we want to keep a configurable server-side minimum, the existing One option would be to introduce a new key, for example:
Then any per-block interval below that value would be clamped to the configured minimum. Another option would be to add a temporary clamp when loading the config. If an existing server still has one of the old, overly aggressive values, we could clamp it to the new minimum instead of allowing the old setting to carry over unchanged. For now, I’m leaning toward adding the clamp and setting a safer new default, probably around 120 ticks (6 seconds). That should prevent existing configs from accidentally causing LevelMaintainers to run far too frequently while still leaving room to make the interval configurable. Thoughts? |
|
Okay, I think I had a better idea. I’ll leave the existing minTick behavior for the active state unchanged and add a separate config option for the idle refresh interval, with something like 6 seconds as the default. That way, server owners can adjust how often an idle LevelMaintainer checks for updates. Once it becomes active, it will behave exactly as it does now and use the existing tick settings. This should solve the performance issue without changing the current active-state behavior. It would still require an additional config entry for the minimum idle interval, so server owners can adjust it depending on their performance requirements. |
22b65bb to
c3fd2d7
Compare
The requester now re-checks its request list on one interval, in seconds, set per block: how long it waits between checks, editable in the GUI, saved with the tile and carried by the memory card next to the lite mode override. 0 follows the server default, LevelMaintainer.maxTick (120 ticks = 6 seconds), which is what the requester effectively ran at before. Both ends of the registered TickingRequest are that interval, so the tick manager cannot park on the midpoint of a range and the value the GUI shows is the value the grid uses. updateTickRate is called on change so it applies immediately instead of at the next grid or chunk rebuild, and the deadline handed to Waila is re-based at the same time so the countdown cannot point at a time that has already passed. minRefreshTicks/maxRefreshTicks bound what a player may set (default 1 second to 24 hours, hard bounded to the same range) and every value - player set, config default, loaded from NBT or applied from a card - goes through one clamp that also snaps it to whole seconds, so the seconds shown in the GUI and in Waila are exactly the interval used. The old minTick key is no longer read and is gone. Waila shows the interval in effect and the time left until the next check, the countdown only once the tile has actually been ticked. In the GUI the field sits under the request rows on the field's own background with a white value: an untouched Enter no longer pins the default in as an override, an edit survives the one-per-second refresh while it is being typed and is discarded when focus leaves, and the field is re-seeded from the block after a resize. Old worlds load unchanged, a card from a build without the key resets the rate to the config default, and client and server must ship together: the packet gained a field and the action enum gained a member.
c3fd2d7 to
1142e9e
Compare
1 participant
Summary
with this pr let you set the interval at which the maintainer re-checks its request list. It has a per maintainer setting: editable in the GUI in seconds (1-60s, 0 goes back to the server default), saved with the tile and carried by the memory card, mirroring the lite mode override next to it.
The tick manager only reads a tickable's request when it registers or is told to, so the new interval is pushed through ITickManager.updateTickRate to apply immediately rather than at the next chunk or grid rebuild.
Waila now shows the effective rate and the time left until the next check.
Checklist