Hey pop,

This plugin is really awesome, it's replaced worldborder and chunkmaster for me. Thanks.

I don't mind during upgrades to offload things to another server, but we do have some worlds that we don't mind generating in the background while players are using things live. And we don't mind if this would even take a month to complete.

What would be nice though is if it's friendlier for live servers that already utilize the hardware resources. With this I mean if there's a way to auto pause any task when there's less than a gig or two of free ram. And auto pauses when the tps has dropped below some number like 18 or 17.

This way when things are busier, it will just pause and check after a few minutes again if there's enough to continue.

Of course, this can mean a task could take a much longer time, but as I said, for some works that's perfectly fine.

# only set to true if you run chunky on a live server
# enabled defaults to false, so plugin behaves as it does now
# time is in minutes; check every x minutes to try and auto start a paused task
# tps; min-required tps value (19 or better? start a task, tps AND ram)
# ram; min-required ram value in megabytes (2g free? start a task) (ram AND tps)
# stop-tps; when tps is below this value, pause the task (tps OR ram)
# stop-ram; when ram falls below this value, pause the task (ram OR tps)
auto-start-stop:
- enabled: false
- time: 5
- tps: 19
- ram: 2048
- stop-tps: 17
- stop-ram: 256

I hope this will be possible.

I've recently released a Developer API which makes it possible to manage tasks via a custom integration.

For example, the ChunkyPause add-on which can be used to pause and continue at a certain online player count.

Of course, it's also possible to limit by TPS, RAM, or any other custom criteria.

Hi floris, seems like I catch you around a lot! 😛

This is a good idea, and something I've already considered. Generally, for my use case (the one for which I originally designed the plugin) I'll generate the map before going live. Therefore the goal was to have it done relatively quickly. Incidentally, if you're running Paper, the server more or less limits itself already pretty reasonably such that TPS doesn't suffer all that much. Regardless, having an option to run generation within specific resource constraints would certainly still be helpful for live servers.

I'll see what I can do, but it might be a little bit before I look into this. I'd like the plugin to have a solid foundation, so I want to polish out the current features and clean up code before adding anything further.

Hi there pop,

yeah, im here and there.

Thank you for considering it and seeing what's possible. I am all for a solid foundation.

There's a variety of situations where we have expanding borders and don't want to lock and unlock worlds from players until we remotely finish processing things. This is fine during upgrades, but while things are running live and growing, it's nice if certain unique situations can also be done (rather than fill up the todo list of 'maybe one day')

Looking forward to more features! Thanks again.

I would like to add to this. I run a server on a Raspberry Pi 4 (personal server) and chunky causes the server to crash after a while. I think it's causing the main server threads to not get enough resources and therefore to not function properly causing a server crash. It would definitely be nice to be able to throttle this app a bit. It would be also nice to indicate how many processors to use. The Pi4 has 4 cores so it would be nice to indicate using only 3. Or better use all 4 but limit the resource usage to not kill the server. One of the other problems is that the current version of the rpi os is 32 bit, so I can't fully utilize the 8gb of memory on the pi for the JVM running the server (once this goes to 64 bit I shouldn't have this problem anymore). Being able to limit memory usage for this would also be a plus.

FYI I'm also running the latest paper-182.jar for 1.16.2.

Unfortunately it is not possible to directly control exactly how much CPU or RAM the plugin uses (on its own, in fact, it uses almost none) as the real work is done by the server generating the chunks. The most feasible option is probably to allow for the generation rate to be reduced.

Unfortunately it is not possible to directly control exactly how much CPU or RAM the plugin uses (on its own, in fact, it uses almost none) as the real work is done by the server generating the chunks. The most feasible option is probably to allow for the generation rate to be reduced.

Anything that can be done to enable tuning for the device would be great :) I remember running WorldBorder on this same server and not having this problem so maybe they were limiting in some fashion (or maybe their method of causing the chunk generation was different?)

An you asked in another thread about WorldBorder, and as I stated there I had to stop using it due to the fact that for some reason it was missing and not filling large portions of the map.

Hmm then it might seem reasonable to have a setting that enables feeding the server a smaller number of chunk requests at a time and allowing the server to catch up. Some of the errors I'm seeing are related to the server not responding and then it starts to thread dump. If you can allow the server to chew it's food a bit before giving it more (granted an AMD Threadripper can chew really fast, but a Pi4 is chewing rocks with no teeth) then we can do a bit of tuning.

One thing I noticed that leads me to believe this is what is happening is that Chunky works well when I saw it was processing parts of the "world" where there were empty spots for a bit, then it finds a large bit of pre-generated chunks which causes it to no-op for a while before finding another bit to generate. I watched the server processing and even though the server had not received any new chunks to process, it was still writing the chunks out to disk... this took a little bit of time (even on an SSD), and when the CPU activity dropped to near zero, the write activity on the SSD was still active for a short time (too bad you can't get some indication back from the server when all writing is completed). This makes me think of a queue architecture where the thread processes are dropped on a queue and they don't pop off until all the threads have stopped writing. If you keep adding things to the queue faster then they can complete, then the main thread has no time to add it's jobs to the queue. Paper doesn't seem to like this very much :)

The method of generating chunks is not the same, and the default rate WorldBorder generates at is generally much slower, which is the reason for most of the observable differences.

Chunky currently doesn't work in terms of a target frequency (as you have probably noticed). Instead, it asks the server to generate chunks, and if it finishes, it asks for more. This results in an automatic variable rate of generation that goes about as fast as the server is capable of handling.