##Description
This plugin adds MobRepellers. A repeller is a ‘+’ shape built of valuable block: Lapis, iron, gold, diamond. All registered repellers prevent mob spawning in a radius calculated based on the amount and worthiness of the blocks.
##Usage
Build a ‘+’ shape(lying on the ground) out of the lapis, iron, gold and/or diamond blocks.
Mobs won’t spawn in the radius around the repeller.
####Radius increase of blocks(Screenshot below illustrates it better):
Lapis: 2
Iron: 2
Gold: 4
Diamond: 6
Emerald: 10
##Screenshots
The most basic repeller in the 4 different materials.
An ugly repeller which has a radius of 42 = 52+32+24+36.
5 * lapis, 3 * iron, 2 * gold, 3 * diamond.
I tried that before(don’t know if I pushed that to GitHub). I think it wouldn’t be good for the performance. I mean only my plugin on the server -> everything is fine but with some more plugins, every checking each block placement and iterating over some more blocks around the changed block: That would cause lags.
I could make it configurable. But before I have to fix some bugs and make this plugin more user friendly.
Just something to consider: Minecraft, on its own, without sponge, tracks 100s of entities, 1000s of blocks, and potentially 100s of block places and mutations to the world, every tick. Checking block placement, and 4 blocks around it, shouldn’t really cause lag, now if you did something like parse a database on every EntityMove event (which that Portal plugin accidentally did), the lag is noticeable, but still technically playable. Put simply Computers are really fast.
If you do this, either cache the block states at a given x y z location, limit the amount of objects you create in the loop.
The other option you may want to think about creating a tree of all the possible rotations / offsets that a given blockshape can be in, that will reduce the amount of times you need to loop drastically.
The final thing is do you get people to configure block types, block states, or block snapshots? block states and block snapshots are user unfriendly as they may “over specify” a block.
What we really need is a config serializable block matcher / partial block snapshot that can be easily understood by users.
I’d suggest some way of specifying the blocktype, blocktraits, and letting the user leave block traits unlisted to create a set of blockstates as a minimum of what this matcher should be able to accomplish.
You mean the users of the SpongeAPI = developers or users of this plugin? There should only be one shape this plugin reacts to.
If you meant users of SpongeAPI, then I agree, it would be really cool to have a ‘shape matcher’ built into Sponge. Or someone could create a library.
The shapematcher would be just for your plugin, minecraft has a shape matcher built in (wither, snow golem, iron golem, creeper face), but it’s busted as heck so it’s not worth exposing.
The block matcher on the other hand would be shapeless, just matches against a single block location, and returns true or false depending on whether the block matches the predicate. The reason why we can’t use predicates is that they are not serializable or immutable. The reason for having it built into sponge is to create a common serialization format that is easy for users to use. If plugins don’t like it, they can always create their own format.
For what it’s worth, since the 4.0 release, there’s been an increase in the ability to cancel entity spawns before the entity is even constructed. If you listen to ConstructEntityEvent.Pre, you can get the EntityType and the proposed location. This should decrease most of the overhead of creating entity objects that aren’t going to spawn regardless.
I really like having players capable of setting up their own MobRepeller zones.
I got a bit confused about the text in the message. And thought it mighty help to clarify what the red/green X’s were the players position relative to the radius of each MobRepeller. (inside or outside). I didn’t really see it explained anywhere, after checking the code I felt dumb.
It’s a minor thing, but if you get a chance a flourish in the text I think would clarify what I got confused on. I would appreciate it anyhow
=== Position Radius X/X(in radius) ===
129, 62, 265 78 X
14, 62, 334 38 X
Mobs won’t spawn in the radius around the repeller.
Jar-Download 
I will improve that