AntiBranchMining
Branch-mining, the process of digging out organised tunnels at low levels in order to increase chances of finding valuable ores. A valid technique in most survival games, but in Ultra-Hardcore tournaments its use is often banned due to the ease and safety in which you can gain ores. This has led to a great deal of drama, accusations, lack of understanding of the rules, and time required on the part of the host to police such behaviour.
In an attempt to avoid the problem entirely, I have created this plugin. It is simple, efficient and effective in removing all ores that can only be found by branch-mining while retaining all ores that can be found while caving and exploring underground structures. The practical upshot of this is that all forms of branch-mining become profitless and therefore pointless, and effectively removes branch-mining from the game.
As all ores that could be found by caving are retained, most players will not even notice a difference to the world unless they are tunnelling rather than caving.
This is advantageous to both hosts and players, as hosts will no longer need to worry about monitoring the tunnels of players to see if they are branch-mining, while players will no longer have the confusion about rules, will no longer need to worry about digging straight tunnels for genuine reasons, such as searching for caves.
Features
- Simple
- Just download the plugin jar into your plugins folder before generating a new world, no additional setup required
- Efficient
- Causes chunk loading to take only 15-20% longer on average, typically a difference of only a few milliseconds per chunk
- If you pre-generate your arena with AntiBranchMining installed, it need do nothing during play and so causes no lag
- Fast enough to be used without significant lag in unlimited sized worlds
- Effective
- Removes all ores only available through branch-mining, while retaining all of the ores that can be found while caving
- approx 14,000 gold and 5,000 diamonds remain in a 1600x1600 map available just from caving alone
- Customisable
- Exclude certain types of ores from being removed
- Reduce the max height to check for ores to remove, if you allow branch mining at higher levels
- Record ore compositions to show how much ore is left in the world afterwards
- (0.2) Apply different settings or disable AntiBranchMining on a per-world basis from the config.yml
- (0.3) Change the ore removal factor to optionally retain some percentage of ores that would normally be removed
- (0.3) Use AntiBranchMining on worlds with radically different terrain generation by settings which block IDs count as ores and what material they should be replaced with
Multi-World Support (Available from v0.2)
In order to provide support for multiple worlds, I have added a some extra options in the config.yml file. Here is an example: config.yml
Customisable Ore Removal Factor (Available from v0.3)
By default, AntiBranchMining will remove 100% of the ores that can only be found through branch-mining. However, in some cases you may only want to encourage caving rather than prevent branch-mining entirely. You can now add a "removal-factor" key with a percentage from 1 to 100 to the default or any given worlds. If you set it to 90 for example, then 90% of the ores would be removed, and only 10% of the ore available only through branch-mining will remain. This works per vein of ore rather than per block, so either the whole vein will remain or the whole vein will be removed. This should maintain the natural vanilla feel of the world.
Custom World Generation Support (Available from v0.3)
In order to better support worlds with other than the normal world generation (e.g. nether and quartz ore?), I have added an "ore-replacement-material" option, this allows you to set what material to replace removed ores with. This default to stone on normal maps, but in the nether for instance you would more likely want it to be netherrack.
I have also added an "ores" option, a list much like "excluded" ores, that allows you to customise which materials should be considered ores for searching purposes. This is useful if you are using a different set of ores to the standard ones e.g. nether quartz instead of coal, iron, gold etc.
This should not be used as a replacement for the "excluded" option as it may have unwanted side-effects. For instance, if you didn't want coal ore to be removed, so you took it out of the list of ores, it would prevent the coal ore from being removed, however it would also mean that if you mine out the coal any other ores behind it would have been removed due to the coal not being considered an ore. The ores list should be considered a list of all known ores for the world, whether you want them removed or not.
Commands
- /OreStats - Displays the remaining ore composition of the world per chunk and the average time it has taken to remove ores from them. Set debugstats to true in the config.yml before generating the world to see all the information.
Permissions
- antibranchmining.commands.orestats (defaults to op) - Allows use the /orestats command
Troubleshooting
This plugin uses Java 7
If you get the followed error on starting up the server with this plugin installed "Unsupported major.minor version 51.0". This means you are using an out of date version of Java. If you don't know how to upgrade, please contact your server hosting provider and ask them for help in upgrading to Java 7, or contact Oracle customer support. Mac OS X users require JDK 7 instead of JRE 7.
Compatibility
This is a Bukkit API-compliant plugin. This guarantees that it is compatible with other Bukkit API-compliant plugins, and will continue to work in later versions of Craftbukkit (unless the Bukkit team specifically state that a particular update will break plugins, this has very rarely ever happened).
Donations
If you'd like to contribute towards the continued development, support and maintenance of this project, please consider joining me on Patreon, and making a one-time or recurring pledge.
Help
If you need help you can leave a comment below and I will get back to you as soon as I can. You can also join my IRC chatroom using the following link. Please note, I am not always at my keyboard! http://webchat.esper.net/?channels=XHawk87&prompt=1
@Darkeh57
This is not a problem in the UHC format as there are still approx 14,000 gold and 5,000 diamonds remaining in a 1600x1600 map available just from caving alone, and the matches only last a few hours, and a new world is generated for each match.
If you're talking about a permanent survival world with a limited boundary, you will run into this problem eventually whether you are running AntiBranchMining or not. You would have to create some other means of bringing new ores into the map. This could be through opening up new worlds, or increasing the size of the boundary, or creating new ores through some other means, or generating a new world.
Adding in a custom cave populator to AntiBranchMining is not an option as it would no longer have a vanilla feel to the world, which is an essential part of a standard UHC game. However, in your particular case, if someone else made a custom cave populator you could run both this and AntiBranchMining at the same time.
This sounds great, the only thing I am worried about however, is the total availability of ores, especially on a limited boundary map. Maybe increase the cave spawn rate a bit by adding a second cave populator and the ability to adjust that one.
@XHawk87
Perfect! And wow what great response, thanks!
I'm looking forward to v0.3, too, to check out the % (removal factor key) stuff you've developed. Should be interesting. :-)
@OrfulBiggun
Here is a list of all material names supported by Bukkit as of version 1.4.7-R1.0: http://jd.bukkit.org/rb/apidocs/org/bukkit/Material.html
You can also use their block id number instead: http://www.minecraftwiki.net/wiki/Blocks
In v0.2, the default set of ores as recognised by the plugin are:
These are not case sensitive.
In v0.3, you will be able to set which blocks should be considered ores without relying on the defaults. This is almost finished, I just need to update it for 1.5 materials, and test it. I am just waiting for a more reliable build of CraftBukkit before updating. Apparently there are still a number of serious bugs in the dev builds.
Hey, Hawk - would you please list the "official" ore names (like "COAL_ORE" and "IRON ORE") that we'd use in the "excluded" part of the config? Unless I did something really stupid, which is always a possibility, I tried to exclude a couple ores (lapis and emerald, for example) that weren't recognized by the plugin, which I think must be because I had the name wrong ...
@OrfulBiggun
Thanks, OrfulBiggun. I have long been a fan of the UHC format, having played a few matches myself, I know how much drama can be generated by these kinds of issues.
Visually the world will look the same, as it uses standard world generation and comes through afterwards to remove the unwanted ores. Although this adds a small overhead as opposed to generating a world with fewer ores in it, I wanted to retain the authentic vanilla feel that UHC has, as well as remain within the Bukkit API for compatibility and maintenance.
The ore in the veins are replaced with stone as standard, however in debug mode it replaces them with sponge to make them more visible. This is currently not configurable. Stone made the most sense to me as ore veins can only spawn in stone in the first place, and therefore looks quite natural in its place.
Players who were unaware of the plugin would most likely just think they were being unlucky in not finding any ores on the way down if they are tunnelling, and in caving there is no difference at all.
Kudos to you, Hawk, this kind of thing is GOLD (pun intended)! Seriously, would that more plugin writers were paying attention to the UHC format.
In fact, this might be something that will be perfect for us and our UHC PvP matches. We tried (in vain) to do something very similar, once upon a time, using the MultiVerse & TerrainControl plugins in such a way that gold/diamond ore blocks could not generate where they won't be touching an air block.
Our cunning plan worked ... sorta ... but looked very weird, too. Cave with a mound of diamonds in the middle of the floor ... gold stalactites/stalagmites ... that kind of thing.
Anyway back to the here and now ... question time. Assume that we'll pre-generate the world with a radius of 1000 blocks (we use WorldBorder fill/trim), so it shouldn't add any overhead.
1) Visually, and other than the obvious, does a world generated with your plugin look the same? I.e., other than if I were mining straight through stone, and not finding any ores ... would I be able to tell within normal gameplay that something was different?
2) What does your plugin do with the veins where the ores were? Replace each ore block with stone? Or is that configurable?
Again, thanks for your attention to UHC ... we're very likely going to be checking this out!
OrfulBiggun
@xuromon
Retaining a percentage of non-cave ores is something I could do without much of a tick cost, if it were a chance per chunk rather than per block. A chance per vein is a possibility too, I reckon I could find a way to do it efficiently. Generating a random number doesn't carry too high a cost, but its not something you want to do thousands of times per chunk.
Range to caves or natural structures would be much more tricky, I would have to revise the algorithm and come up with a different way to locate the air and the ores in order to do so in any efficient manner. I will give it some thought.
P.S. I like the sound of travelling to varied, exotic and more dangerous worlds. Could you PM me a link to check out your server?
Excellent, this is just what I was looking for! I want to encourage players to travel to varied exotic and more-dangerous worlds, but if they get there and immediately become strip-mining-mole-people it rather defeats the purpose. This should help encourage exploration more. I look forward to experimenting with it more this weekend.
If you're looking for other suggestions, from my purely self-interested viewpoint a couple very useful features would be:
I'm not sure what kind of tick-cost those might add to the processing, so it may be good to have them be disableable.
@XHawk87
you're a gentlemen and a scholar =)
@xuromon
@orodai
I can add this to version 0.2. Shouldn't take more than a couple of days.
@xuromon
Im wondering the same thing.
Looks very interesting. Is it possible to have this only apply to certain worlds, and/or have different settings by world?
The file has now been approved. Everyone is free to download it using the download link.
@Sharovon
The file is currently awaiting approval by Bukkit moderators. It doesn't usually take them longer than a day.
I have tested it myself of course, but if you want to see its effectiveness for yourself, I recommend setting the debugstats in the config.yml to true before generating a new world. This allows you to see the remaining ore composition after removal, and any ores that were removed are turned to sponge for visibility. You can then examine the world quickly using X-raying tools. This may slightly decrease performance, so its best to leave it off for normal use.
I certainly want to see this plugin made and tested out. I'll be happy to place it into my server, and inform of anything that may or may not happen. Good luck and thank you for developing such a great plugin.