Ore Stone Variants

Full range of transparency:
 


Which implies automatic CTM support for background layers:

Variant Drop Settings:

"Variants Drop" and
"Variants Still Drop with Silk Touch"

By default, the new variants do not drop unless silk touch is used. This is to avoid inventory clutter. If you like the variants and would prefer to obtain them more easily, you can set "Variants Drop" to true in order to obtain iron and gold ore without silk touch.  If you're still turned off by the thought of inventory clutter and would like to never get these variants, you can set "Variants Still Drop with Silk Touch" to false and, of course, they will not drop even when using silk touch. 

World Generation Settings:

"Replace Vanilla Ore and Stone Generation"

In order to stop normal ore variants from generating in all types of stone, I had to replace their spawn algorithm. You can set "Replace Vanilla Ore and Stone Generation" to false to disable this, which I recommend if you're also using a mod such as Open Terrain Generator or any other mod which spawns underground ore patches (including stone, dirt, etc.) on its own. In effect, this setting simply disables most vanilla WorldGenMinable events. 

x_size

These settings simply change the vein size of any given WorldGenMinable feature. Negative values decrease the vein size, where -2 is completely disabled and -1 is half size (15); 0 is vanilla size (33); and positive values increase size, where 1 is larger (44), and 2 is even larger (52).

"Stone Variant Count"

This setting changes the frequency of andesite, diorite, and granite clusters. A negative value means fewer clusters per chunk, where -1 is half frequency (5); 0 is vanilla frequency (10); and positive values increase them, where 1 is double frequency (20), and 2 is quadruple frequency (40).

"Generate Stone Variants in Layers" and
x_layer

"Generate Stone Variants in Layers" setting changes the stone variants to only spawn at the given y coordinate range. Setting x_layer to 1 will spawn that type of stone from layers 0 to 20, whereas 2 will spawn it from layers 25 to 45, and 3 will do layers 40 to 80. 

"Biome-Specific Generation"

This setting toggles whether certain ores should only spawn in specific biomes. For example, emerald ore typically only spawns in mountain biomes, but setting this to false means it can also spawn in other biomes. 

"Spawn Default Quartz Variants"

This setting adds quartz variants to the overworld. No need for adding the line under "Variant Adder"

Dimensions

Dimensions are whitelisted inside of an array contained within the config file, located under "world generation settings"  > "dimensions" > "Dimension Whitelist." You can see dimensions -1, 0, and 1 are listed by default. If you would like for ores to spawn in any modded dimensions, simply add their numbers here. This setting is for performance purposes. Many users would probably prefer better performance in said dimensions when nothing is supposed to happen, anyway. In that case, they would need to either remove the number of whichever dimension is listed by default, or not add the IDs of any new dimensions. 

Miscellaneous

"Overlays are Shaded / are not Highlighted"

This setting changes whether the overlay textures are shaded. What this means is that certain overlays may become more or less visible depending on their backgrounds or opacity levels. I've set it to false by default because, specifically, the vanilla granite texture makes makes most of the included overlays difficult to see, but it does unfortunately mean that some textures are especially shiny-looking. I recommend setting it to true if you're using a resource pack. In particular, any resource pack for which the overlay textures are at all transparent will probably look better when this is set to false.

"Shade Overrides"

You can enter the names of any ores that should be shaded opposite of the global setting. Any ore that is difficult for you to see based on your setup can be added to this list and it may look better. 

Overlays are Shaded = false


Overlays are Shaded = true


"Disable Transparency"

This setting has been marked as experimental for some time, as I'm still not sure how effective it really is. It should theoretically make all blocks render in the "CUTOUT_MIPPED" render layer instead of transparent, but I've neglected to do much testing with it. 

"Use Built-in Blended Textures"

Certain ores include translucent overlay textures, which allows them to blend into their background blocks more smoothly and also to retain stylistic consistency with the original sprites as closely as possible. Setting this to false swaps the textures to an entirely different set of textures which don't have this. The option is currently provided in case some users prefer one setting vs. the other. This should not affect resource packs, as the file name is the same in both cases.

Bonus: Future builds will also include both 16x and 32x textures by default for better support with some specific mods. ;) That's one of the percs of running a relatively small mod thanks to the way block models are handled / almost don't exist.

Dense Ore Settings

In order to maintain vanilla functionality as closely as possible, dense ores are disabled by default, but they can be enabled under "dense ore variants" > "general dense ore settings" > "Enable Dense Variants." More information about dense ores can be found below.

Dynamic Blocks

This mod allows users to add new stone variants for almost any ore type. Literally. See below, as well as the documentation inside of ore_stone_variants.cfg for more information.

General Settings

"Enable Mods"

These settings allow the user to disable automatic creation of ore variants relative to each mod name, vanilla included.

"mod generation hax"

These settings are hacky and will result in other configurations' comments being deleted, for now. On the other hand, if you don't feel like disabling the ore generation from other mods for better compatibility, you can set these to true per-mod to do so. It doesn't actually prevent the mod from doing anything in-code, just takes advantage of their config files. For this reason, you'll need to restart your game twice for everything to take effect. 



To be updated / missing information (Sept 26, 2018):

• Furnace recipe settings
• Ore dictionary settings
• Background block imitation
• Generate overlays from RPs
• Dense ore frequency
• Large ore cluster settings
• New variant registry settings from 4.0
• Block group settings
• Registry group settings
• Generate starter mods

New Stone Types From Quark:

New Stone Types from Mineralogy

i r someday take photo. so complicated.

New Stone Types from Underground Biomes

For all mods supported in OSV, if the same mod is not supported by Underground Biomes, support will automatically be added using their stone types. 

faux toe go here

All Ores from SimpleOres

These blocks function exactly like their counterparts, including support for all advancements added by SimpleOres. All settings are currently based on the mod's default settings. However, future builds may provide the option to either read from or (if possible) circumvent SimpleOres' configuration file. 

Overworld Ores from Ice and Fire

All Ores from Base Metals

All Ores from Biomes O' Plenty

All Ores from Glass Hearts


All Ores from Thermal Foundation

dev sux geta life

Embers
pix r so hard

Immersive Engineering
I may not even write the next one ...yet.

Thaumcraft

Rustic

As of 2.0, users can now optionally enable dense ore variants in the config file. These variants function mostly like normal ores, but instead drop between 1 and 3 times as much as they normally would. Their textures are procedurally generated and placed inside of "resources.zip," located under /config/ore_stone_variants_mods/, which is a resource pack that does not need to be moved or applied. 

• Enabling this feature in the config file will generate unique probabilities for each ore based on their location, per world seed.
  • See this map for an example of how that looks. Frequencies are slightly exaggerated in the example.
• Ores will most often generate near others of the same type.
• Large ore veins (> 3) will be much larger, but half as frequent in selected regions.
• Small ore veins (< 4) will be much more frequent, up to 20x as likely to spawn in selected chunks, down to 13x in neighboring chunks, and then 6x one chunk farther out.
• Expect large areas with no resources, and equally large areas with far too many.
• Expect a slightly lower generation time on average. It's nothing severe; initial world generation should take an extra 3-5 seconds or so and tick speed appears to be mostly unaffected.
• This feature may be fairly unbalanced. You may start a new world and find that you have absolutely no coal, but already hundreds of iron. If you'd like to help me balance and improve the feature, please comment here, send me a private message, or submit a suggestion under the issues page either here or on GitHub.

Ore variants imitate their background blocks, taking on many of their properties.

• Specifically, 
  • Hardness
    • Hardness is relative to an ore's background blockstate. If its hardness is higher than that of normal stone, the ore's hardness will also be higher; if it's lower, it'll go down by up to 1.5F (stone's hardness level).
  • Light level
    • Returns the ore's light level or the background blockstate's light level, whichever is higher.
  • Gravity
    • Falling sand entities will spawn if the background blockstate should also fall.
  • Placement and walking sounds
  • Material type
  • Harvest tools
    • Harvest level will stay the same for balance purposes, but the tool type used will change, unless disabled.
  • Light opacity (how much light is blocked)
  • Transparency (boolean)
  • Mobility (whether they can be pushed by pistons)
  • Custom breaking progress
  • Slipperiness
  • Leaf sustaining
  • Plant sustaining
  • Flammability
  • Fire spread speed
  • Ability to sustain fire
• This can be disabled, of course.

All ores are automatically registered with ore dictionary support, dynamic and manually added ores included. 

Normal ores:

• ore + Name

Variants in netherrack:

• oreNether + Name

Variants in end stone

• oreEnd + Name

Dense variants

• denseore + Name
• ore + Name + Dense
  • Also denseoreNether + Name, etc. if applicable.

Ores with multiple names:

• Adamanium
  • Adamantine
  • Adamantite
• Aluminum
  • Aluminium
  • Bauxite
• AluminumBrass
  • Aluminumbrass
  • AluminiumBrass
  • Aluminiumbrass
  • AluBrass
  • Alubrass
• Chromium
  • Chrome
• GalvanizedSteel
  • Galvanizedsteel
• Mythril
  • Mithril
• StainlessSteel
  • Stainlesssteel
• Tungsten
  • Wolfram

Please let me know of any entries that aren't working or if there are any you would like added. 

In its current state, the mod uses multiple different texture paths for the same textures, depending on the user's setup. This may complicate things for resource pack makers, so I've included a workaround. 

Create a file inside of assets/ore_stone_variants/ called "osv.cfg" Inside, you can add a line that reads "force_single_texture_location = true" which will tell the mod to only retrieve the basic textures for any use. Since you'll be replacing them anyway, it shouldn't matter. You can look inside of config/ore_stone_variants_mods/resources.zip (a resource pack) for an example. Just change false to true. 

There may be other options for resource pack developers in the future. Let me know if you have any ideas and I'll consider adding them.  

Because some people just want to watch the world burn; and others just want coal in a log.

This mod allows users to add ore variants to any block whatsoever using its dynamic model system. All you need to do is open the config file, look for "Add Blocks Here," and enter the ore type followed by the block name to register new blocks, following the model in the config file. There is no need to provide a texture, blockstate file, block model, or item model. The block will function exactly like its parent ore type, inheriting the background block model of the chosen background block, and overlaying the appropriate ore texture on top.

Users can also enter a given mod's namespace in place of "x_ore" and the mod will automatically create variants for all of that mod's ores. For example, ""Add Blocks Here"=simpleores, stained_hardened_clay:3" will create a new variant for adamantium, copper, mythril, and tin, inside of stained_hardened_clay:3.  

These blocks also function exactly like their counterparts, with world generation (whichever dimension is applicable), ore dictionary support, advancement support (if applicable), and even redstone ore effects. They can be configured just like any other block using the configuration settings mentioned above.

Because there are so few blocks in other vanilla dimensions, this does mean that you can add all ores to the Nether by typing this line under "Variant Adder" :

minecraft, netherrack

Likewise, you can add all ores to the End by typing 

minecraft, end_stone

Note: I can't guarantee it will work with any block (because of the way background block models are found), but I have tested quite a few mods with no issues. 

As of 2.0, users can now reconfigure most of any ore's properties by copying a template located under /config/ore_stone_variants_mods/. This file can also be used to create entirely new ores fairly easily. Everything is already typed out for you; you just need to know how much experience is supposed to drop, how frequently they're supposed to spawn, etc. To get started creating a new ore, either copy the template, or add the name of the ore in the config file under "dynamic blocks" > "Generate Starter Mods". This will find or estimate most of the working properties to get the basic ore in the game, minus the world generation and things like additional item drops; however, all of these things are possible. See below for a list of details. 

For a basic explanation of how this all works, all ore properties are stored in three basic objects in the code: OreProperties (which contains DropProperties), RecipeProperties, and WorldGenProperties. Users can modify these objects or create entirely new instances of the objects by creating a respectively named json file--i.e. OreProperties.json--which is stored in /config/ore_stone_variants_mods/, either in a new folder or zip file with the name of the ore. See template.zip for a great example and more information. See below for a list of properties that can be modified.

OreProperties: 

• PropertyGroup
  • This is the group of properties to which this particular property belongs. Used for managing multiple properties at once using a single key, e.g. for adding the ore type to a new background block.
  • This is most often just the mod name, but it doesn't have to be for custom ores.
• Original ore texture
• Original background texture
• Whether to blend the resulting texture
• Language key
• Block hardness
• Harvest level
• DropProperties
  • OreProperties can contain any number of DropProperties. Each of these contains the following pieces of information:
    • The item dropped--can be a block
    • The amount of items dropped
    • The amount of experience dropped
    • The object's percent chance to be selected, i.e. how likely this group is to drop.

RecipeProperties

• Result
• Quantity
• Experience

WorldGenProperties

• Vein size
• Frequency
• Height range
• Biome list
  • Can be a whitelist or a blacklist
• Dimension list
  • Can be a whitelist or a blacklist
• Additional WorldGenProperties
  • Each WorldGenProperties object can contain additional properties, which is useful for getting ores to spawn differently in different biomes, dimensions, or altitudes.

Example Configurations:

• OreProperties.json
  
  • Main example: https://pastebin.com/EvjtaBme
  • Basic: https://pastebin.com/ySPxBn75
  • Advanced: https://pastebin.com/ikBt34ew
  • Default settings: https://pastebin.com/K1XnK8HW
• RecipeProperties.json
  • Main example: https://pastebin.com/8QwXeGNN
• WorldGenProperties.json
  • Main example: https://pastebin.com/T33nrLYP
  • Advanced example: https://pastebin.com/jf9zTuiN
• Basic jsons can be automatically generated for both OreProperties and RecipeProperties. See the config file for instructions.