This is, supposedly, to reduce load on servers whenever player log in because of sudden massive chunks loading at spawn.
However, this is utter stupidity!
First, this applies only to new players anyway, because players can log back in anywhere in a world.
Second, loading the chunks around a player that is logging in doesn't really cause that much lag. Otherwise, you'd get noticeable lag on ALL servers, because players are already constantly logging in and out of servers and most of them do that away from spawn, so this aspect of "CPU savings on spawn chunks" is so negligible that it becomes flat out laughingstock material. This is like saying you'll keep your leather gloves in your house instead of in your car's gloves compartment, in order to save on gas... while still keeping all your heavy sports equipment on the backseat. Riiight.
Third, keeping spawn chunks always loaded causes 2 very real game-play problems:
- Players normally have 5 minutes of "chunk loaded time" to get back their stuff upon death, which means that the player can literally take whatever time he wants to prepare and THEN go get his stuff back, with then 5 minutes available in the "where death occurred" area. But at spawn, where new players are particularly at their MOST vulnerable, this becomes "5 minutes total" because the chunks simply never unload. While "5 minutes being more than long enough" can be subject to hot debates, what always remains true is that this creates some kind of unfairness / imbalance in the amount of time allocated to go get back your stuff, depending on where this occurred near spawn or not.
- Players can plant a crops farm at spawn and they don't even need to be logged in for the crops to grow. Plant right at the end of your play session, log out, then go eat dinner or d your homework or something, then log back in afterwards and voilà, perfectly "all grown up" crops, for almost zero actual playtime investment, which can, by some fraction of players or servers, be seen as a form of "exploit". Replace "crops farm" with "iron grinder" and "logging out for a couple hours" for "a full real-life day" to see my point in full.
Thus, simply put, Spawn chunks are "unfair" relative to the rest of the world's chunks. Wether what happens differently at spawn is a "good" or a "bad" thing, and whether these things count as cheating or not, are NOT my point here: the point is ONLY the fact that it works differently according to an arbitrary location, while a game's game-play should work in a consistent fashion everywhere.
- - - - - - -
So, I suggest the following changes:
- Spawn chunks should load & unload the exact same way as any other chunk.
- When any chunk would become "unloaded" (player logging out, or player moving out of area), the chunk doesn't unload immediately. Instead, it just gets bit-flagged as "inactive" ("sleeping"). Nothing occurs in there, no mob movement, no crops growth, not even video rendering! The chunk just remains in RAM, and that's it, and for all other intents and purposes it "acts" the same as if it was an unloaded chunk. Then, after a short and reasonable delay, let's say 30 seconds or 1 minute, the "sleeping" chunk gets unloaded (purged from memory) for real.
In addition to fixing "spawn chunks unfairness", this would also avoid all the chunk loading/unloading occuring whenever a player gets momentarily disconnected from the server, or just decides to log out but only for a few seconds, which are things that happen a WHOLE LOT MORE than "new player joining a server for the first time.".
It would also avoids all the "peripheral" chunk loading/unloading occurring from players constantly moving back 7 forth in an area, which is 90%+ of all movements in player bases/mines.
AND it would even avoid the extra spawn chunks loading/unloading when there are tons of new players constantly streaming into a new "huge" server, which was the originally stated intention for the "keep spawn chunks always loaded". When there are not enough players around spawn, at least these chunks would not hog any CPU time. In other words: the server load would be as if there was approximately half a player less on the server.
Yes, the overall RAM needed would increase a bit. Only increase "somewhat", though, not a lot, and the% increase would be the most visible only for really-low-player-count servers, and when players are mostly moving WITHOUT turning back such as when exploring around.
Basically, you'd end up storing in RAM the equivalent distance worth of chunks of 30 seconds / 1 minute of running around, so yeah, about double the RAM for storing chunks. But note that this is ONLY for the RAM usage, not for the actual amount of chunk loading/unloading (more disk and CPU), which would remain the same. But even on such servers, the low player count means there is ample RAM room to spare anyway. So that wouldn't cause any performance hit, as the java cache cleanup is based much more on the rate at which memory blocks are allocated/cleared (actual chunk loading/unloading) than on the total amount. The overall reduction of chunks loading/unloading would in fact increase performance, not the other way around, not greatly but way more than the really currently totally negligible performance "boost" from keeping spawn chunks loaded at all times.
Only REALLY low end "old junk PCs" servers would "suffer" (those that can't even allocate 2GB to Minecraft, that is). I guess for these guys, the "30 seconds to 1 minute unload delay" would just be ignored (determined directly at server start according to the available RAM for the game, a simple threshold), and all their chunks would just unload immediately, like they ALREADY do now for most players. Meaning: they wouldn't be penalized, they just would not get the performance increase the others more-RAM-allocated-for-the-game setups would get, that is all.
But on high-player-count servers, the effect on RAM would be pretty negligible (applying only to those players currently doing long distance exploration, which is usually less than 5% of player activity), while the effect on the CPU/disk savings of chunk loading/unloading would be even more noticeable (as most of the time, chunks wouldn't get unloaded, then reloaded shortly afterwards, instead they'd just "go to sleep", stopping being active for a short period). So the overall CPU performance saved would be much more noticeable.
I kinda don't want to remove a feature people depend on at this point, it would be like removing the current command blocks in favour of command blocks that used a programming language instead. Sure, it would probably be much easier for people to use, but it would also wreck about a million command block creations.
Rollback Post to RevisionRollBack
My avatar is a texture from a small block game I made in Python. It's not very good and it probably won't work if you install it.
I'm very alone in my Minecraft worlds as I don't have a very good internet connection to run a server. If you're like me, you might be interested in my Posse mod suggestion.
I kinda don't want to remove a feature people depend on at this point, it would be like removing the current command blocks in favour of command blocks that used a programming language instead. Sure, it would probably be much easier for people to use, but it would also wreck about a million command block creations.
Dinnerbone currently has a list of command changes that are likely to break maps once 1.13 rolls around. Mojang isn't particularly concerned about that kind of issue, especially when it already relies on exploiting game mechanics.
I really don't see a need to change this though. Both problems you present are edge case scenarios that don't really matter.
For example, with dying and losing their stuff, in most scenarios if they die near spawn they live near spawn or haven't set up a bed and would respawn at spawn anyways. It would be extremely uncommon for a player to make a base 1000 blocks from spawn, then wander all the way back to spawn and die with a bunch of gear. If on servers, chances are the stuff would be stolen by other players at spawn anyways.
For the farm exploit... Forgive my sarcasm but "oh no, a player managed to grow wheat while AFK, something they can already do just by putting themselves in a small dirt box. Whatever will we do?" This is almost an absolute non-issue. Most servers have a set spawn area that you can't build in or otherwise use, or contains a farm specifically for new users. If new players will likely be keeping those chunks active anyways, they will stay loaded, just not as often. I know Iron farms can use this, but if someone wants to exploit game mechanics, not my problem.
Finally, even though I just gave an example of Mojang not really caring about breaking maps, tons of servers and maps rely on this feature to keep command blocks running. So in short, if it causes more strain on servers, will break thousands of maps and servers, and only kind of fixes a few tiny issues, that sounds like more harm than good to me.
Rollback Post to RevisionRollBack
Want some advice on how to thrive in the Suggestions section? Check this handy list of guidelines and tips for posting your ideas and responding to the ideas of others!
The biggest drawback mentioned for going this route would be losing "global" command block functionality but it seems to me they could just implement commands or server controls specifying a chunk range within a given area to always remain loaded.
Either that or some other more efficient way to implement global commands that's not dependent on chunks being loaded in memory.
The biggest drawback mentioned for going this route would be losing "global" command block functionality but it seems to me they could just implement commands or server controls specifying a chunk range within a given area to always remain loaded.
Either that or some other more efficient way to implement global commands that's not dependent on chunks being loaded in memory.
Yeah I didn't think about the command block aspect. And it's a really big one, too.
Yeah I suppose special server commands (or whatever mechanic) would be good, as it would allow setting up the "server command blocks control room" anywhere and any size, instead of always 12x12 chunks at spawn. Heck, personally I'd go with a separate "void dimension". Only server admins can go there, user-chosen specific chunks are loaded, with full control on overworld or any other dimension.
Dying at spawn with valuable items while your base is further away isn't that unheard of. Happened to me several times. It depends on the type of server, really. Some servers have spawn areas where it is litterally impossible to die unless you do it on purpose. Other servers, its the most dangerous place to be. Some servers, you die at spawn, your stuff is mostly safe for 5 minutes. Other servers, you die at spawn, other players will grab it all within seconds. I was going for a general "most fair" approach.
You could fix the two problems with some command blocks or a server-side looped function.
1) Teleport non-player mobs out of spawn chunks to reduce the chance of death,
2) Change the mode of any players in spawn chunks to adventure mode, so that they can't plant crops.
Optionally, also give players in spawn chunks resistance and regeneration.
(Edit: I just checked the wiki, and apparently crops don't grow if a player isn't within update range, period, so that doesn't appear to be an actual problem.)
But take heart... Bedrock engine MC is getting a /tickingareas command that keeps chunks loaded, so maybe they will turn off spawn chunks in Java engine MC and port /tickingareas over so that you can have more control.
Currently, Spawn Chunks remain constantly loaded.
This is, supposedly, to reduce load on servers whenever player log in because of sudden massive chunks loading at spawn.
However, this is utter stupidity!
First, this applies only to new players anyway, because players can log back in anywhere in a world.
Second, loading the chunks around a player that is logging in doesn't really cause that much lag. Otherwise, you'd get noticeable lag on ALL servers, because players are already constantly logging in and out of servers and most of them do that away from spawn, so this aspect of "CPU savings on spawn chunks" is so negligible that it becomes flat out laughingstock material. This is like saying you'll keep your leather gloves in your house instead of in your car's gloves compartment, in order to save on gas... while still keeping all your heavy sports equipment on the backseat. Riiight.
Third, keeping spawn chunks always loaded causes 2 very real game-play problems:
- Players normally have 5 minutes of "chunk loaded time" to get back their stuff upon death, which means that the player can literally take whatever time he wants to prepare and THEN go get his stuff back, with then 5 minutes available in the "where death occurred" area. But at spawn, where new players are particularly at their MOST vulnerable, this becomes "5 minutes total" because the chunks simply never unload. While "5 minutes being more than long enough" can be subject to hot debates, what always remains true is that this creates some kind of unfairness / imbalance in the amount of time allocated to go get back your stuff, depending on where this occurred near spawn or not.
- Players can plant a crops farm at spawn and they don't even need to be logged in for the crops to grow. Plant right at the end of your play session, log out, then go eat dinner or d your homework or something, then log back in afterwards and voilà, perfectly "all grown up" crops, for almost zero actual playtime investment, which can, by some fraction of players or servers, be seen as a form of "exploit". Replace "crops farm" with "iron grinder" and "logging out for a couple hours" for "a full real-life day" to see my point in full.
Thus, simply put, Spawn chunks are "unfair" relative to the rest of the world's chunks. Wether what happens differently at spawn is a "good" or a "bad" thing, and whether these things count as cheating or not, are NOT my point here: the point is ONLY the fact that it works differently according to an arbitrary location, while a game's game-play should work in a consistent fashion everywhere.
- - - - - - -
So, I suggest the following changes:
- Spawn chunks should load & unload the exact same way as any other chunk.
- When any chunk would become "unloaded" (player logging out, or player moving out of area), the chunk doesn't unload immediately. Instead, it just gets bit-flagged as "inactive" ("sleeping"). Nothing occurs in there, no mob movement, no crops growth, not even video rendering! The chunk just remains in RAM, and that's it, and for all other intents and purposes it "acts" the same as if it was an unloaded chunk. Then, after a short and reasonable delay, let's say 30 seconds or 1 minute, the "sleeping" chunk gets unloaded (purged from memory) for real.
In addition to fixing "spawn chunks unfairness", this would also avoid all the chunk loading/unloading occuring whenever a player gets momentarily disconnected from the server, or just decides to log out but only for a few seconds, which are things that happen a WHOLE LOT MORE than "new player joining a server for the first time.".
It would also avoids all the "peripheral" chunk loading/unloading occurring from players constantly moving back 7 forth in an area, which is 90%+ of all movements in player bases/mines.
AND it would even avoid the extra spawn chunks loading/unloading when there are tons of new players constantly streaming into a new "huge" server, which was the originally stated intention for the "keep spawn chunks always loaded". When there are not enough players around spawn, at least these chunks would not hog any CPU time. In other words: the server load would be as if there was approximately half a player less on the server.
Yes, the overall RAM needed would increase a bit. Only increase "somewhat", though, not a lot, and the% increase would be the most visible only for really-low-player-count servers, and when players are mostly moving WITHOUT turning back such as when exploring around.
Basically, you'd end up storing in RAM the equivalent distance worth of chunks of 30 seconds / 1 minute of running around, so yeah, about double the RAM for storing chunks. But note that this is ONLY for the RAM usage, not for the actual amount of chunk loading/unloading (more disk and CPU), which would remain the same. But even on such servers, the low player count means there is ample RAM room to spare anyway. So that wouldn't cause any performance hit, as the java cache cleanup is based much more on the rate at which memory blocks are allocated/cleared (actual chunk loading/unloading) than on the total amount. The overall reduction of chunks loading/unloading would in fact increase performance, not the other way around, not greatly but way more than the really currently totally negligible performance "boost" from keeping spawn chunks loaded at all times.
Only REALLY low end "old junk PCs" servers would "suffer" (those that can't even allocate 2GB to Minecraft, that is). I guess for these guys, the "30 seconds to 1 minute unload delay" would just be ignored (determined directly at server start according to the available RAM for the game, a simple threshold), and all their chunks would just unload immediately, like they ALREADY do now for most players. Meaning: they wouldn't be penalized, they just would not get the performance increase the others more-RAM-allocated-for-the-game setups would get, that is all.
But on high-player-count servers, the effect on RAM would be pretty negligible (applying only to those players currently doing long distance exploration, which is usually less than 5% of player activity), while the effect on the CPU/disk savings of chunk loading/unloading would be even more noticeable (as most of the time, chunks wouldn't get unloaded, then reloaded shortly afterwards, instead they'd just "go to sleep", stopping being active for a short period). So the overall CPU performance saved would be much more noticeable.
Iron farms mayb? (Spelling mistake intentional.)
I kinda don't want to remove a feature people depend on at this point, it would be like removing the current command blocks in favour of command blocks that used a programming language instead. Sure, it would probably be much easier for people to use, but it would also wreck about a million command block creations.
My avatar is a texture from a small block game I made in Python. It's not very good and it probably won't work if you install it.
I'm very alone in my Minecraft worlds as I don't have a very good internet connection to run a server. If you're like me, you might be interested in my Posse mod suggestion.
Dinnerbone currently has a list of command changes that are likely to break maps once 1.13 rolls around. Mojang isn't particularly concerned about that kind of issue, especially when it already relies on exploiting game mechanics.
I really don't see a need to change this though. Both problems you present are edge case scenarios that don't really matter.
For example, with dying and losing their stuff, in most scenarios if they die near spawn they live near spawn or haven't set up a bed and would respawn at spawn anyways. It would be extremely uncommon for a player to make a base 1000 blocks from spawn, then wander all the way back to spawn and die with a bunch of gear. If on servers, chances are the stuff would be stolen by other players at spawn anyways.
For the farm exploit... Forgive my sarcasm but "oh no, a player managed to grow wheat while AFK, something they can already do just by putting themselves in a small dirt box. Whatever will we do?" This is almost an absolute non-issue. Most servers have a set spawn area that you can't build in or otherwise use, or contains a farm specifically for new users. If new players will likely be keeping those chunks active anyways, they will stay loaded, just not as often. I know Iron farms can use this, but if someone wants to exploit game mechanics, not my problem.
Finally, even though I just gave an example of Mojang not really caring about breaking maps, tons of servers and maps rely on this feature to keep command blocks running. So in short, if it causes more strain on servers, will break thousands of maps and servers, and only kind of fixes a few tiny issues, that sounds like more harm than good to me.
Want some advice on how to thrive in the Suggestions section? Check this handy list of guidelines and tips for posting your ideas and responding to the ideas of others!
http://www.minecraftforum.net/forums/minecraft-discussion/suggestions/2775557-guidelines-for-the-suggestions-forum
I support this.
The biggest drawback mentioned for going this route would be losing "global" command block functionality but it seems to me they could just implement commands or server controls specifying a chunk range within a given area to always remain loaded.
Either that or some other more efficient way to implement global commands that's not dependent on chunks being loaded in memory.
Yeah I didn't think about the command block aspect. And it's a really big one, too.
Yeah I suppose special server commands (or whatever mechanic) would be good, as it would allow setting up the "server command blocks control room" anywhere and any size, instead of always 12x12 chunks at spawn. Heck, personally I'd go with a separate "void dimension". Only server admins can go there, user-chosen specific chunks are loaded, with full control on overworld or any other dimension.
Dying at spawn with valuable items while your base is further away isn't that unheard of. Happened to me several times. It depends on the type of server, really. Some servers have spawn areas where it is litterally impossible to die unless you do it on purpose. Other servers, its the most dangerous place to be. Some servers, you die at spawn, your stuff is mostly safe for 5 minutes. Other servers, you die at spawn, other players will grab it all within seconds. I was going for a general "most fair" approach.
You could fix the two problems with some command blocks or a server-side looped function.
1) Teleport non-player mobs out of spawn chunks to reduce the chance of death,
2) Change the mode of any players in spawn chunks to adventure mode, so that they can't plant crops.
Optionally, also give players in spawn chunks resistance and regeneration.
(Edit: I just checked the wiki, and apparently crops don't grow if a player isn't within update range, period, so that doesn't appear to be an actual problem.)
But take heart... Bedrock engine MC is getting a /tickingareas command that keeps chunks loaded, so maybe they will turn off spawn chunks in Java engine MC and port /tickingareas over so that you can have more control.