This site works best with JavaScript enabled. Please enable JavaScript to get the best experience from this site.
I know configurability isn't a word. But its meaning is still clear. Here's a list of all the things you can make configurable. Some of them seem obvious to implement, but I'm including it anyway for the sake of thoroughness. This list will point out all the aspects you can make configurable, but won't detail how exactly you can make it configurable. (e.g. For most of them, I won't say "can be specified as an integer, or boolean, or etc.", that is mostly up to you.)
This one is a weird request, but could you consider the option to have all blocks spawned in by this plugin (only spawned in, not blocks removed) to "disappear" after a configurable amount of time, depending on the creeper type? And note, when I say disappear, this is being nitpicky of me (again), I mean remove the block only if it's the right material. So if the plugin spawned in "iron ore" at (0,0,0), which used to be AIR, and for some reason that position now has a dirt block (due to some other plugin), leave that block alone; don't revert it to AIR. The reason behind this strange request is that some admins like me use a plugin called CreeperHeal, where all blocks that are removed by explosions get regenerated after a specified duration. If you implemented a "revert created blocks" feature, it could potentially interfere with CreeperHeal when that plugin tries to revert block damage.
Now I know you could just ask, "Okay, but instead of all this hassle, can't you just disable that creeper type?" Well, yes, that's a good hypothetical point. But say a Cube Creeper goes off and spawns a lot of dirt; players won't have the incentive to remove the dirt, unless they're like me and are very meticulous, so the server ends up with a clump of dirt that will never go away until someone does something about it.
Oh, and last but not least, more advanced multiworld support. This one is a stretch, and is completely optional, but you could possibly have multiple config.yml files, each pertaining to its specified world. The reason this might be necessary, is because with all this configuration, things might become a jumbled mess when you consider intricate multiworld support too.
These are actually all amazing ideas, thanks :D That being said, it will take a considerable amount of time to implement them, and there may be a few in there that are currently beyond my ability. I'll start going down the list and adding these, they'll probably be released in a mass update. Thanks again for all of the ideas!
EDIT: Aren't the first and second suggestions basically the same?
They're pretty similar, but there's small differences.
The first point asks "does this creeper type even make an explosion at all?" whereas the second point asks "assuming this creeper type makes an explosion (depending on the first point), will that explosion cause block damage?"
And take your time. There's no rush. :)
To post a comment, please login or register a new account.