I've gotten a chance to do some analysis on our chunk loader situation: Chunk loaders are used by only ChickenChunks, BuildCraft, and ExtraUtilities. ChickenChunks is purpose-built to allow fine grained control of chunk loaders, while the other mods merely have blocks that load chunks. ChickenChunks tracks the owners of the chunks (the player) and the number of chunks allowed to be loaded per player. Chunks loaded by BuildCraft are essentially for its quarries. Chunks loaded by ExtraUtilities are essentially for Enderthermic Pumps. Neither BuildCraft nor ExtraUtilities track the owner of its chunk loaders. The server tends to run pretty well at 2000-3000 chunks, barring any intensive mods. BuildCraft quarries load about >2000 chunks alone. ExtraUtilities loads >1000 chunks alone. Chunks loaded by ExtraUtilities and BuildCraft are essentially "forever loaded." The server is slow primarily due to the incredible number of chunks loaded (5,000-7,000+). Breaking chunk loading by BuildCraft resets quarries' information. The ideal solution utilizes the following rules: The only chunk loaded chunks permitted are ones with attached player information. Nothing should be able to request a ticket for an "unowned" chunk loader. Chunks should continue to stay loaded even after a player leaves the server. Chunks should automatically unload after a preset "timeout period" that starts to count once a player has disconnected from the server but resets whenever the player is connected. Provided that the number of chunks is not too numerous, players' chunks should be re-loaded again on server start as if the server was never restarted, but the timeout period countdown should continue from before. Upon player join, but after all of his or her chunks have been unloaded due to the timeout delay, the player's owned chunks should all be loaded together all at once, as if this was a single player game and he or she had just booted up the game again and chunk loaders had kicked in. The idea is to strike a balance between the convenience of chunk loaders and the pressing need to keep low the number of chunks loaded at any given time. Unfortunately, the chunk loading system in place is not very versatile, and to avoid the task of needing to write a brand new chunk loading mechanism, the current plan is to block all chunk loaders but that of ChickenChunks, while fixing the issue with quarries resetting. Current restrictions with ChickenChunks (i.e. unloading on player log off) may be relaxed. ChickenChunks' loaders would be required in order to load Enderthermic Pumps. ChickenChunks' loaders would be required in order to keep the quarry block loaded. Much of this plan pivots on whether ChickenChunks can implement the rules mentioned in the "ideal solution" above, and the feasibility of fixing the issues of quarries resetting without actually modifying BuildCraft. Should this solution fail, I will write my own chunk loading system.
Sounds great. ChickenChunks' loaders do seem close to ideal. Have you considered adjusting the fuel requirements to encourage players to use them sparingly? With "offline timers" for chunk loading, would it be worth considering idle players? Maybe the chunk load timer could start when a player idles rather than only upon going offline, since idle players are "chunk loading" a large area already.
The problem with offline timers is that what constitutes coming online? Some people do use alts, and could circumvent this timer by simply moving their character every so often.
The thing is the person has to at least move their alt; and you use the honor system if someone uses an afk machine temp ban them.
SK, I don't believe this is a good idea. Restarts would definitely be lag filled with enough players. Could you please consider redefining the load timeout for those chunks during server restarts?
If the chunks weren't forced to load after a restart, the quarries would do their derpy thing again and break, I think?
The quarries would do their derpy thing and break even if the chunks were forced to load at server start. That bug is a save and resume issue. When the server restarts, everything needs to be saved and loaded again.