- Native Minecraft Version:
- Tested Minecraft Versions:
- Source Code:
- ProgrammerDan, Soerxpso, /r/Devoted
Brought to you by the developers from https://www.reddit.com/r/Devoted and https://www.github.com/DevotedMC - Our main website is http://devotedmc.com
Massively configurable, low-impact plugin to allow post world generation ore balance, via either drops, or ad-hoc generation of ores into the blocks of the world on-demand. It works as a wonderful anti-xray plugin, and as a powerful incentive tool for mining.
Notes on Minecraft 1.13
Minecraft 1.13, and Bukkit/Spigot's implementation, introduces a wrinkle for my admittedly "deprecated" approach to sub types of materials; namely, if you're defining a normal ore sequence, you can no longer just define a block config for "STONE" -- you now need to define a block config for STONE, ANDESITE, DIORITE, and GRANITE, and if you use generation, you need to define allowed types for each.
The benefit with this approach, however, is even greater control over every detail of ore generation within your worlds. I wanted to include this note at the top, however, to highlight the importance of this change. You can find an example of this done in detail, in config.yml.
Additional 1.13 notes are included below in the normal place.
Every time you break a block, naturally placed, there will be a lottery run. This will occasionally drop cool stuff instead of the block you broke, or generate new blocks around the miner.
Typical use case is for stone -- instead of dropping stone, occasionally drop ore instead, or generate awesome blocks around the miner.
1:100,000 chance to find prismarine.
1:3000 chance to find a diamond.
1:10000 chance to find a vein of 10 diamond ore.
This plugin is fully configurable with biome-specific settings, tool restrictions, and limited player state restrictions, allowing a significant degree of options and specificity.
As of 1.5.2, you can upend this regime and construct intersecting probability fields via "Noise" generators, which allow a persistent hidden map of drop density regions. The probabilities are a bit harder to constrain, but still quite measurable with some trial and error. Unfortunately, due to the nature of noise generators, once you choose a config it will be difficult to rebalance smoothly -- e.g. player's discoveries of high density regions will likely be rendered invalid on a config change. The traditional probability approach doesn't really suffer from this as players would simply notice changes globally or within defined regions, and the "pain" would be shared, without impacting much secret knowledge. Regardless, both are excellent options for administrators and we're proud to finally support it on the mainline w/ all of our existing performance and anti-exploit features intact.
Note that unlike other branches, our noise-based generation approach is embedded in the existing configuration flow, and is handled as a new feature regime instead of a completely "other" element. This allows you to freely mix and match these "veins", drops, transforms, commands and the like without loss of functionality. As always, the goal is max features and control for you.
The raw technical details:
On block break, checks the config to see if a lottery has been defined for this block. Optionally, a quick check for presence of Silk Touch is done.
You can specify multiple drops, where each drop is computed as an independent probability against the break, and the sum of drops is spawned into the world.
Alternatively, you can indicate only a single drop-type is allowed. In this case a single random number is generated and tested against a probability distribution of possible drops. This allows replication of Minecraft behavior (in terms of how ores are generated).
The chance to drop for each type of drop against a type of broken block is configurable.
With Minecraft 1.13, subtype specification is no longer directly possible; future releases may add groups of native materials to emulate this prior behavior, but for now it has been removed.
You can apply biome-level chance, level, and amount modifiers.
Drops can be restricted to specific Y levels.
Drops can be restricted to specific tools, with a high degree of configure-ability. Check config.yml and config-advanced.yml.
Drops chances can be modifed based on player potion / effect state and level of that state. Currently haste, mining fatigue, nausea, blindness, and luck / bad luck states are supported. See config.yml.
Included is a default config that effectively mirrors Minecraft Vanilla orespawn; it should be possible to generate a normal MC world with no ores or caves, but with this plugin allow effectively normal vanilla riches. Consider it the ultimate XRay defense; you cannot see what literally doesn't exist.
Supports tracking of breaks to prevent "gaming" the system for more drops. Extra event handlers watch for game attempts and directly penalize that "chunk" (technically, the chunk slice). An extra "highly localized" round robin list keeps track of recent breaks and places to completely prevent break-place based attempts at exploits. Finally, a new tracker keeps track of each blockthat is broken or interacted, and prevents it from being converted into ore or producing drops.
You can specify more then one config per block type, although as of Minecraft 1.13 only the first will be used. Also note that in terms of drops, the first matching config to be encountered will be used; so keep that in mind.
You can specify custom messages for specific types of drops, allowing "uber"-finds to have a unique message.
You can turn on or off the debug using /hiddenore debug true or false. Be warned, if people are digging or pistons are active, this will spam the console very badly.
Supports saving and loading of the tracking database, and fully adheres to /reload with no difficulties.
As of 1.4.2, full multiple world support, via name or UUID.
As of 1.5.2, you can specify "veinNatures" which allow complex simplex-noise based distributions of ore probabilities. These are hard to compute as the mechanics aren't as straightforward, but the end result can be quite nice, allowing for layered, overlapping, or otherwise clever intersections of ores. Players like it too, as it allows a kind of density distribution, which once "found" can be leveraged.
In mainline as with all our other features, the full suite of configuration options, including drops, transforms, commands, biome and state modifiers, etc can be applied to veinNature configs. See config-veins.yml for examples.
I'm probably missing some other details but that's it for now.
TODO / In progress features:
Feature Augment List:
- Configure which tool to "use" for cave dusting. Default right now is Diamond Pickaxe.
- Better documentation
v1.5.3 Some general fixes and improvements to block-level exploit tracking.
v1.5.2 Adding in CivClassic style "veins", which are basically just distributions of ore backed by persistent noise fields instead of the classic HiddenOre probability distribution functions. The outcomes are probabilistically compatible, but the generation is quite a bit different. Check out config-veins.yml for a hopefully clear example. Note that due to fundamental implementation differences, configurations made for CivClassic veins are not portable to this implementation, as their implementation refactors the configs and introduces veins as a separate flow, with only some of the tradition drop or generation capabilities; our approach to veins preserves all the existing feature-rich environment and simply implements veins as a probability distribution modifier to existing drop configs (Expanding the features in 1.5.1 for global drop config design as well).
v1.5.1 Adding in a few key QoL features for continued 1.13 support. Specifically (and see config.yml for examples and details) you can now specify drops in a global section, and pick those drops by name in the block drop configurations. You can also specify multiple blocks for whom the drop config should apply, all in the same block config. This should allow significantly improved "terseness" to configs, above and beyond what the prior subtype system allowed. Note you can mix and match global drops and local drop configs for a block, but you cannot mix single or multiple block types for a single block config.
v1.5.0 Added Minecraft 1.13 support. Note that you WILL need to REDO your config. Although your config will load as is it is unlikely to work as expected. Subtype support has been entirely removed and declarations of subtypes will be ignored. Spigot itself has renamed many materials to match their Minecraft normative style, and there is no backwards compatibility in HiddenOre. As of 1.5.0, no prior release of Minecraft is guaranteed active support, and will only be provided on a best-effort basis, if at all. IMPORTANT NOTE on config: All ItemStack serialization has been changed! There is a new v: specification. I've emulated it in the demonstration configs, but to avoid messy and unsupported prior version settings, re-export your serialized drops.
v1.4.2 Added full multiple world support. Standard config is used as default for any world that does not have a specific config. A new section, worlds can be specified, each subsection is either the UUID or name of the world with a specific config. A single blocks subsection under the world identifier contains all the block configurations for that world. It is configured like the default, but within the world's blocks subsection. Check the configs for examples.
v1.4.1 Live use of new tracker shows its disk use is much increased. Added a configuration option to explicitly disable it. Added config example of Command "drops" and some fixes.
v1.4.0 New exploit tracker that tracks the actual blocks broken or exposed. This will fully prevent the "but I already checked that block" problem. Heuristic tracking is, for now, still active.
v1.3.2 You can now run a command on block break. If you use reward crates, could gift, or custom /give, etc -- runs as SERVER so be careful. Use %player% to inject the player name into the command, or %uuid% to inject the player's Minecraft UUID.
v1.3.1 Added a command for OPs only that generates all the drops configured. It has some quirks, but type /hiddenore generate to spawn the items.
v1.2.9 Support for dusting the caves in your map with ore based on your active config; kind of an addendum to v1.2.7's feature. Can be used to prevent the "boring caves" problem when a world is otherwise devoid of ore from the 1.2.7 feature. Don't use your final config, do use a Generate only config, and do turn off drops if generate fails.
v1.2.8 Support for altering drop chance based on 6 basic player effect states, generated by potion or beacon. Configurable by drop and biome (biome acts as override)
v1.2.7 Experimental feature to allow stripping a world of ores during the generation phase. Fully configurable per-world by name; you can set it to replace any set of materials with a single material. Also includes a new anti-bypass method to directly target that "initial return" that can still occur from generators and place-break-place-break cycles
Break down of the Config:
prefix: You found a hidden ore!
This one is pretty simple, it's the message displayed to the user when they successfully rolled a win after breaking a block.
Set this to false if you don't want an in-chat alert sent to the user when they find an ore.
Set this to false if you don't want the user getting the name of the items they just won.
This section is where the magic happens. List the Bukkit material name of the item you want to break first. In this case, STONE.Code (Text):
The next part is 'allTypes' this specifies if you want items with data types, like Granite (0:1, instead of 0:0 which is stone) to be broken as well for rewards. You can directly specify types below in the types section. For this example config, only breaking stone will roll for a reward.
If dropMultiple: false, then it's out of the cumulative chance. If dropMultiple: true then it's independent chance
So for dropMultiple false, what that means is, we stack up all the "chances" for each drop type, based on biome, tool, and block broken; we choose a random number, and see if it is within the "probability range" cut out by those stacked up chances.
e.g. if diamond, lapis, and redstone are all "possible" drops, then if the random number is between 0 and 0.0001 the diamond drops. 0.0001 and 0.0024 the lapis drops. 0.0024 and 0.005 the redstone drops. (using pretend numbers). If the random number is above 0.005, nothing hidden drops(edited)
vs. with dropMultiple true, we pick a random number for each possible drop. If the new random number is < 0.0001, the diamond drops. Then we pick a new random. If < 0.0023, the lapis drops. Then we pick a new random. If < 0.0026, the redstone drops.
The drops section handles what the rewards are. Specify the Bukkit material name of the item you want dropped first, in this case, Emerald Ore. Next specify the type of tool you must mine with to get this material. minY and maxY determine the ranges a player must mine in to get the drop.Code (Text):
Chance is the % chance that a block broken will give the reward item. In this example it is set to 0 so we can specify which biomes will give the reward.
Min and max amounts determine how many of the reward block are given to the player when the win a roll.
Biomes lets you set specific biomes where the reward will be given and different chances. In this case there is a 0.1437% chance of getting a drop when you mine stone.
This section is simply renaming Bukkit materials to more user friendly names.Code (Text):
IRON_INGOT: Iron ingot
GOLD_INGOT: Gold ingot
PRISMARINE_SHARD: Prismarine Shard
DIAMOND_ORE: Diamond Ore
IRON_ORE: Iron Ore
GOLD_ORE: Gold Ore
QUARTZ_ORE: Quartz Ore
EMERALD_ORE: Emerald Ore
REDSTONE_ORE: Redstone Ore
LAPIS_ORE: Lapis Lazuli Ore
COAL_ORE: Coal Ore
4: Lapis Lazuli
[1.13] HiddenOre - Anti-Xray 1.5.3
This plugin makes each stone break roll a lottery to drop or reveal ores, special blocks.