Administration
Read me completely before logging-in players!
Setup
This plugin does NOT require SQL or any other plugins.
This plugin will work very well on a brand new server, but it's also compatible with an existing world and active player population.
- Copy PopulationDensity.jar into your plugins folder.
- Start your server.
- A config.yml file will appear under Plugins/PopulationDensityData. Read the configuration details below carefully.
- Adjust configuration settings and /reload. At the very least, if you have more than one "normal" environment world, then you must specify which world should be managed by the plugin.
- Leave a comment if you have any problems or suggestions!
What You Need to Know
Regions
PopulationDensity invisibly divides the world you choose into 400-block x 400-block areas called "Regions". One of those regions is "open" meaning it's accepting players, includes plenty of wilderness space, and includes plenty of easily-accessible materials (wood, coal, iron, etc) to build with (guaranteed). The open region stays open until its easily-accessible resources drop too low or the region starts to feel "crowded" with builds, at which time that region "closes" and a new one opens.
Unless you disable them, region posts will be built at the center of each region, and can't be moved (except vertically). In an established world, this may be problematic in a few cases where the new region post lands on top of an existing build. To move a region post higher, build a single block platform above it and /AddRegionPost. The old region post may now be removed. Alternately, you might use another plugin like WorldEdit to move the player build horizontally.
Spawning and Respawning Players
Unless you configure otherwise, players who start fresh on the server (log in at the default spawn) after you install the plugin will instead spawn in an area where other new players have recently started surviving. This area is their "home region" until they change it. This creates a valuable opportunity to join a community of active players, because nothing's more frustrating than joining a server for multiplayer and always being alone. If you choose to disable the teleport-to-home-region-on-first-login feature, then you should post a sign notifying new players about the /homeregion command (or another you define in your commands.yml file) which will take them to a great starting location.
Also under the default configuration, players who die and have no bed respawn in their home region. So as far as the player knows, the "spawn" is right there near where they live and mine, instead of halfway around the world. There's a configuration option to disable this, so that players will spawn at the default spawn in the default world (unless another plugin does something else).
Players have the option to "move into" a new region with /setHomeRegion. When a new player joins, he or she may immediately move into any named or wilderness region. And they can change their minds as often as they like.
Teleportation
A lesser issue large servers experience is that there's tons of cool builds to see, but it takes too long to travel around and see them. This is what keeps strangers from sharing builds and becoming friends - they happen to be too far apart. Popular player commands like /tpa and /sethome can solve a lot of these problems, but players also abuse those commands to save themselves from combat or from being lost, which changes the core Minecraft experience by removing a the sense of danger in adventuring. This teleportation post system alternative allows players to trade and socialize without being abusable, and it does that by requiring players to locate and stand near a post before they can teleport.
Because presumably any player who intentionally moves into the wilderness instead of building where other players are active is anti-social, only residents of wilderness regions can teleport into their home regions. :) Those residents can invite others to teleport to their home region with /invite. However just like real life, civilization may eventually impede on said wilderness (with more remote wilderness being more protected).
There's a configuration option which allows players to teleport from anywhere at all, should you like to remove the restriction. You can also restrict teleportation to ONLY connect home region post with city (this very restrictive option is similar to a pair of connected portals), or even disable ALL PopulationDensity teleportation entirely.
Automated Maintenance
To ensure new players don't get assigned to a region where resources are scarce, regular resource scans are necessary. Scans occur on boot, and every six hours during uptime.
The AddRegion command is available to FORCE a new region to open. The system is really smart, so you'll probably never need this command. If you find yourself using it often, please contact me so that I can investigate what's happening on your server and maybe adjust the resource scanning code so that it will work better for you. It's available to ops, and there's also a permission you can grant for it.
Configuration Reference
NewPlayersSpawnInHomeRegion
By default, new-to-server players start in a region with space, active neighbors, and natural resources sufficient for building. If instead you want them to spawn at the default location (with tons of instructional signs, for example), or if you prefer another plugin to control this first login experience, turn this off. If no other installed plugins are influencing the first login experience, your new players will start at the default spawn in the default world, same as Vanilla.
RespawnInHomeRegion
By default, players who die (without a bed) will respawn in their home region in the managed world rather than the default spawn in the default world. Set this to "false" to get the default behavior (go back to default world spawn) or to allow another plug-in to take effect instead when a player respawns.
TeleportFromAnywhere
By default, players can't teleport unless they're standing next to the region post. This is to avoid teleport abuse to escape from dangerous situations, like getting lost in a mine or getting cornered by a scary monster when low on health. Set this to "true" to allow teleportation from anywhere in the managed world, at any time.
AllowTeleportation
Setting this to "false" will disable most teleportation commands. This will make it difficult for friends who join the server at different times (especially days or weeks apart) to meet up, but will leave players with that "immense world" feeling they get from Vanilla servers.
IF you have a city world set, players can still use /cityregion to visit the city (but ONLY if they're standing next to their HOME region post), and /homeregion to get back home again (ONLY if they're in the city). Use the "maxDistanceFromSpawnToUseHomeRegion" variable to set how close to the spawn players must be to use /homeregion. If you set it less than 1, then they can use those commands anywhere in the city world. If you don't have a city or don't want those teleportation commands to work at all, just leave your CityWorldName option (see below) blank.
CityWorldName
Specifies the name of the world where players will be sent when they use /SpawnRegion or /CityRegion (they land at the world's spawn point). This should be set to match the name of the world where administrators have built a city or added important specialized builds like shops, portal rooms, and self-refilling food chests. This can be set the same as the managed world, if you have a city there. If left blank or set to a world which doesn't exist, those teleportation commands will be disabled. Use "MaxDistanceFromSpawnToUseHomeRegion" to set how far away (in blocks) a player can be from the spawn to use /homeregion to teleport back "home" (recommendation - set to the approximate radius of your city so they can teleport out from anywhere within the city's walls).
ManagedWorldName
This is the name of the world where PopulationDensity will place region posts based on resource scans. If you use this on an existing world, be careful because there's no way to move the posts... they just appear every 400 blocks, so they might land on top of somebody's house. In that case, some worldedit to move the player home, or some player compensation may be in order.
DensityRatio
This controls how closely packed players will be on your server. It only changes the population density of NEW regions going forward - it doesn't relocate users who already have homes, or return to closed regions to fill them in. Very small increments make a big difference - 1.1 would be 10% MORE dense than 1.0. I recommend against changing this config variable until you've had a region automatically close due to density (total player blocks counted). At that time, you can visit that region and fly around to see how much players have built and decide how much more or less dense you'd like future regions to be. Also, I recommend changing it by no more than 0.2 at a time, and always waiting for a region to automatically close before changing it again. The default 1.0 value was very carefully chosen based on lots of real server data, so don't change it lightly!
MaxIdleMinutes
Full server is a problem, especially when some online players aren't playing (they're just taking up space). By default, if a player doesn't change the world, fight something, or move around for 10 minutes, he will be kicked (but may reconnect when he's back at his computer). Set this config variable to the number of minutes a player must idle before being kicked. If you set it to zero, no players will be kicked. To exempt a specific player from being kicked for idling, assign him populationdensity.idle. Note that if a player rides around in a minecart for the full idle period, he will be kicked (otherwise, a minecart track would be a way to stay online without actually playing).
SlotsReservedForAdministrators
This is how many player slots should be reserved for administrators on the server. When the server is NOT full, administrators fill standard player slots. This guarantees administrators can log in during peak time without having to kick out players first.
Permissions Reference
All of these default to "on" for server ops. They all start with "populationdensity.", so for example "buildbreakanywhere" is actually "populationdensity.buildbreakanywhere".
| Permission | Description |
|---|---|
| * | Grants all of the below permissions. |
| buildbreakanywhere | Grants permission to edit near region posts. |
| teleportanywhere | Grants permission to use teleportation commands away from region posts. |
| addregion | Grants permission to use /AddRegion, /AddRegionPost, and /NameRegion. |
| idle | Grants permission to idle without being kicked. |
| setloginpriority | Grants permission to use /LoginPriority. |
| adminlogin | When the server is full, the player may fill slots reserved for administrators. |
| prioritylogin | Grants login priority = 25. |
| elitelogin | Grants login priority = 50. |
Command Reference
| Command | Description | Permission | Aliases |
|---|---|---|---|
| /AddRegion | Forces a new region to open. Should be used very infrequently. | addregion | |
| /AddRegionPost | Regenerates the closest region post. | addregion | |
| /LoginPriority | Checks or sets a player's login priority level. Does not reflect priority level granted via permissions. | setloginpriority | |
| /NameRegion | Names a wilderness region, allowing any player to teleport there. | addregion |
What You Don't Need to Know
What does the resource scanner measure?
The short answer is surface wood, near-surface ore, and space to build. Near-surface ore means ore touched by surface air and relatively close to the surface. Any resources completely surrounded by solids OR in caverns which can only be reached by digging through solid walls don't count (because nobody likes to mindlessly dig through solid rock in search of randomly placed resources). Space to build means that player-placed blocks are under a certain threshold. As long as a "sufficient amount" of all of these resources are available, new players will continue to pour into the open region. Once a region is closed, the existing residents will continue to live there, fueled by the remaining resources. When resources run low or neighbors are no longer active, remaining residents always have the option to move into a new region (for example, the currently open region where new players are pouring in).
Is there a pattern to region layout?
Regions are opened in a tight spiral pattern to keep them packed close together. On a mature server, new-to-server players will find old builds on 3 sides, wilderness on 3-4 sides, and an actively developing region on 1-2 sides. On a brand new server, there will be more wilderness while the spiral works its way away from the center (x=0, z=0).
What happens to regions which don't have enough resources on day 1?
Some regions get skipped over entirely because they don't have enough resources. Usually, these are oceans, deserts, or treeless fields. Unlike wilderness regions which may eventually be opened for new players, these "skipped-over" regions will never get "automatic" new residents. There's nothing to stop players from venturing into those regions and using /movein to make them their home, though.
Where do these region names come from?
Regions are named automatically from a list. When the list runs out, it starts over with numbers (Redstone -> Redstone1 -> Redstone2). Feel free to suggest some!
Why isn't there an option to change the size of regions?
Changing it would shift existing regions, rendering some existing players unable to access their builds, and displacing region posts. Using default server view distance and maximum client view distance, this size of a region is approximately as far as the eye can see (while floating above the tree level). That means plenty of space to explore and natural formations to build around, but small enough that you can visit your neighbors on foot. Besides, the current ratio of resource requirements, player block limits, and region size has been carefully tweaked based on real high-population-server data, so opening these settings to administrators would probably lead to more problems than solutions.
Why bother?
High-population public servers all face the same problem - there's one spawn point, and after 20 or so players start there, its underground is stripped of attainable resources, its surface covered with builds. Over time, new players have an increasingly difficult time finding a suitable location for their first home, to the extreme of dying repeatedly to nighttime baddies and maybe even giving up on the server completely. The new hunger mechanic has exacerbated this problem. Finally, when players find a decent location, they discover they're all alone because other new players chose different routes away from the spawn. By dropping new players into a resource-rich region until it gets crowded, we're helping players socialize while at the same time letting them start surviving right away rather than spending lots of time looking for a suitable location.
Why not just use any of the other obvious solutions?
The usual solution seems to be to spawn everyone in a "safe" zone which has lots of portals to other places. This way, new and old players alike can travel to distant locations to simply explore, or to start a new survival adventure without spending a lot of time traveling (and hiding, at night) over the surface to where they want to be.
Unfortunately, this is just a delaying tactic. Eventually, all the places those portals lead to have the same problem as the original spawn had - their valuables are all mined, their surface area covered with impressive builds. So now the overall problem is worse - before players can start an absurdly long journey in a random direction to try and find a suitable build location, they have to first figure out where the portals are and how they work (sometimes servers will only let new players use certain portals, etc), then try several portals before starting their marathon. Admins can continue adding more portals, but it's a maintenance issue because the safe zone must be repeatedly manually adjusted to accomodate more portals.
I've also seen some systems where there's a /wilderness type of command which will teleport a player to a RANDOM location. This works for providing space and resources, but the randomness spreads players very far apart, and they end up feeling lonely - what's the point of playing online if you're all alone except for chat?
Changing /wilderness to take all new players to the same location (or providing only a single portal) eliminates the randomness and places new players together, but when they die without a bed or tele back to the spawn after the portal/wilderness location has changed, they need to learn a new command to get back home again. Further, administrators must constantly monitor the portal/wilderness location to decide when it's time to move it, then manually make that adjustment.
Routinely deleting the world to start it over kind of works. After all, most players move on to another server or take a longish break from Minecraft after their initial spurt of creativity, and probably don't care whether their builds hang around or not. But for those who really love the game and want to keep building more and more and more, world deletions can hurt. Those loyal players on your server who have the potential to contribute to your community, financially support your server, and possibly take on some administrative/maintenance responsibilities may abandon ship when administrators delete their creations.
All of these approaches help the situation, but none of them solve it in a way that eliminates the need to explanatory signs, scales to a very large number of players over a long period of time, minimizes maintenance, and avoids disrupting long-term players who just want to keep their builds. With PopulationDensity, the initial server join experience can work with very little (or zero) explanation, the "open" region moves automatically over time based on resource availability, and old builds can stick around as long as you have hard drive space to accomodate them because they don't get in the way.