Mob Spawn Control
Mob Spawn Control allows you to take control of the XP grinders (experience grinders, mob farms) on your server. Our server had a problem with XP grinders bringing the server to its knees. I created this plugin to limit the number of monsters (mobs) that could pop out of a given spawner. Once the spawner is maxed it will prevent further monster spawns until a monster is killed. Once the monster is killed it is decremented from the list. Basically the plugin keeps track of active/alive monsters attached to a spawner.
Feature List
- Limit monsters spawned from a single spawner
- Report on top spawners currently on the server
- Assigns spawner to a player in the report
- Teleport to a given spawner for investigation
- In-game debugging option
- In-game enable/disable option
- In-game stat reset
- In-game configuration reload
Why Should I use MSC?
There are many different plugins that handle mob spawners. I've reviewed each of them and they all have their advantages. Rather than tell you "MSC is the best" I will give you a break-down of the problem each plugin resolves. I fully support the other plugins in the community which is why I've linked them below. You decide which is best for your scenario.
My thoughts on other Mob Spawner control plugins can be found HERE.
Commands
All commands can be accessed by typing /msc or /mobspawncontrol followed by the following subcommands:
- HELP = shows the help menu
- STATS = shows the current spawner stats
- TP = teleports to a given spawner in the stats report
- RESETSTATS = reset all current stats on the server
- DEBUG = enabled debugging mode in the console (Lots of spam here!)
- RELOAD = reload the config from disk
- TOGGLE = toggles the plugin on and off in real time
Permissions
- msc.*: Gives access to all MobSpawnControl features
- msc.command: Allows player access to MSC commands
- msc.stats: Allows players access to STATS command
- msc.tp: Allows players access to TP command
- msc.resetstats: Allows players access to RESETSTATS command
- msc.debug: Enables MSC debugging
- msc.reload: Reloads config from disk
- msc.toggle: Toggles the plugin on and off in real time
Config Options
- spawnsAllowed:
- reportSize:
- pluginEnable:
- debug:
- oneTimeUse:
- warnThreshold:
- alertThreshold:
- spawnerRadiusX:
- spawnerRadiusY:
- spawnerRadiusZ:
- playerDistance:
Detailed config descriptions can be found HERE.
Source
Source can be found HERE.
@midnightfang22
Correct. We track the number of alive monsters attached to each individual spawner. If you set the spawnsAllowed to 30 than only 30 alive monsters will be allowed from that spawner. If one of the monsters is killed or despawned an additional monster will be allowed to spawn. Make sense?
@Score_Under
Well said... I just sent you a commend on your pull request. If everything is working I will merge and upload here. Thanks Score_under. Thanks!
@XxTRAINEExX
Player objects also keep in memory everything that they need to know about to properly operate: - All plugin channels (for packet 250) and the plugins they belong to, even if /reload'd - Connection handler - Packet queues - Loaded chunk list - Inventory contents - Last entity that attacked it (this can form a chain of undisposed entities/players) - Last entity that was attacked by it (ditto) - Last EntityDamageEvent, and all attached info, and all entities involved (ditto) - All permissions and attachment information - The bounding box for the player - The NMS World object for the world the player is in, even if unloaded ...etc.
Some people do not rely on server restarts, I try to restart only when absolutely necessary, and try to inject code or updated versions of plugins into the server while it's running, if possible.
So, this works like if 80/60 or whatever limit you put mobs spawn, then until a mob is killed, no more mobs can spawned from that spawer correct? Just trying to double check. Our server lagged big time today and it might have been from everyone and their grandma having a mob xp farm so we are trying to find a way to limit that.
@Score_Under
There are most certainly player objects referenced in various lists/hashmaps even after players log out. This could be corrected several ways but I didn't think it was a huge issue given that any major server is rebooting every day at a minimum and player objects are not a major memory consumer. I use a few attributes of the player objects even after the players log out which is why I never spent the time pulling this out.
But to your point, I will open this up to the community for review. Feel free to send pull requests if you would like to make adjustments :) Source is posted above.
I wanted to fix a possible memory leak, I believe Player objects are being persisted when they should either be stored under a WeakReference (if it doesn't persist past logouts) or keyed by name (if it persists forever)
A compilation of screenshots taken around roughly the same time: https://dl.dropbox.com/u/518733/msc_memleak.png
This is why I believe projects benefit far more greatly from being opensource :P
@rasnyderiii
In typing my previous response it caused me to go check my code for some verification. I realized my previous search pattern was actually more agressive than it needed to be. I've updated the search pattern to be less agressive (3x1x3) instead of the previous (7x2x7). Thanks rasnyderiii! I've also updated the version to reflect support for R4.
@rasnyderiii
I haven't seen any performance issues but I will let you be the judge. Bukkit fires a "creatureSpawnEvent" when a monster pops out of a spawner. I intercept this event and search for the surrounding spawner. Once found, I check a list (in memory) of the number of times that spawner has popped out monsters. If the list is higher than the number you defineid in the config, I tell bukkit to cancel the "creatureSpawnEvent". When a monster dies i decrement the list.
The most intensive component in this plugin is the player search. For each creatureSpawn it grabs the current location of all players on the server. It checks them to see how far from the spawner they are. The nearest person is usually the trigger for the spawner. But this is extremely light calculations compared to other processing on the server.
In short... I don't think performance will ever be a problem with this plugin.
@Mayhem777
Its working on R4.. I run R4 on my server :)
@Score_Under
Sorry Score_Under the code is not yet available. I've changed the project licensing to reflect this. I will release it if the project goes stale. Is there anything you are interested in adding?
This looks... fantastic.. is there any performance issues with it? Removing/suppressing entities?
Is there source for this? It's GPL but there's no link to source, google finds nothing, and github reports 404.
Working fine for me :3 will be updated to R4? :D
@Waterworth12
What problem are you referring to? There are no known issues to my knowledge.
Having the exact same problem, best plugin ever. Keep it going!
@qwertyhgfdsaqwertyhgfdsa
Can you elaborate? This plugin already supports multiple spawners so I might be misunderstanding your request. Each "spawner" has an associated list of mobs that pop out of it. The quantity of monsters in the list is the effective spawn limit you set in the config file under spawnsAllowed. Each "spawner" is tied to an individual. One individual can have an unlimited number of spawners attached to oneself. Make sense?
Could you add support for multiple spawners? For example: We allow the placing of spawners. Could you limit the chunk spawns?
I use squid spawners! XD
@Mayhem777
Squids dont have spawn blocks so they aren't part of this plugin. I don't know of anyone who XP grinds squids although that would be awesome :)
Works for any mobs but squids spawn without control till server crash... the stats says 2/3 but there are hundreds...