Readd Meteor Filler

[koolkrafter5]

Reimplement the concept of "filler" blocks to Blood Magic meteors.
Look for filler block list and fillerChance (chance for any individual block to be replaced with filler out of 100) in meteor config files in config/BloodMagic/meteors. Default filler block is minecraft:stone and default fillerChance is 0.
NEI meteor pages correctly show how much filler is expected in a meteor.
Fix an error in the block yield estimation function for more accurate results in NEI.

[koolkrafter5]

Here is an example config file for a meteor that uses filler. Meteor is summoned with a 4:1 ratio of coal ore to iron ore, and 20% is replaced with sandstone as a filler block. Tenebrae, crystallos, and incendium may be added to replace the sandstone. Terrae/orbis terrae currently do not increase the filler chance.

CoalBlockMeteor.json

[AbdielKavash]

Extra comments:

• Add filler blocks to NEIMeteorRecipeHandler.loadCraftingRecipes, this means the meteors will show up when the player searches for recipes for e.g. stone. I can't see this ever being particularly useful, but it is consistent.
• Not a huge fan of how the replacement filler (ice/obsidian/etc.) is currently generated in MeteorParadigm starting from around line 170. I know this is not your code. But since you now have a generic setMeteorBlock, you could precompute a new List<MeteorParadigmComponent> at the place where you check for reagents, and then just call setMeteorBlock on this list instead of fillerList if any reagents are present. (Or even better, replace sortedFiller by this list, so that it "magically" happens on its own.) This also future-proofs it for if/when we want to add more reagents.
• Something to consider, and honestly I am not sure what is the best solution or even if this is a problem at all: Currently you have stone hardcoded as a default filler block, both in the NEI handler, and in the meteor spawning code.
  It would be perhaps more sensible to always initialize MeteorParadigm.fillerList; either in the constructor or when you are reading filler from config -- if fillerChance is not 0, and fillerList is empty, then add a stone block.
  Alternatively, MeteorParadigmComponent could have a static field that defines what the default block is?
  Since it is literally just stone I don't consider this a big "magic value" issue; but still if for whatever reason someone wants to change the default filler block, it is better to have it declared in one place.

[koolkrafter5]

Extra comments:

* [*]  Add filler blocks to `NEIMeteorRecipeHandler.loadCraftingRecipes`, this means the meteors will show up when the player searches for recipes for e.g. stone. I can't see this ever being particularly _useful_, but it is consistent.

Addressed in d9d70bb.

* [*]  Not a huge fan of how the replacement filler (ice/obsidian/etc.) is currently generated in `MeteorParadigm` starting from around line 170. I know this is not your code. But since you now have a generic `setMeteorBlock`, you could precompute a new `List<MeteorParadigmComponent>` at the place where you check for reagents, and then just call `setMeteorBlock` on this list instead of `fillerList` if any reagents are present. (Or even better, replace `sortedFiller` by this list, so that it "magically" happens on its own.) This also future-proofs it for if/when we want to add more reagents.

Addressed in 1af2bbb by making a new local fillerList and replacing it if any reagents are present.

* [*]  Something to consider, and honestly I am not sure what is the best solution or even if this is a problem at all: Currently you have `stone` hardcoded as a default filler block, both in the NEI handler, and in the meteor spawning code.
  It would be perhaps more sensible to _always_ initialize `MeteorParadigm.fillerList`; either in the constructor or when you are reading filler from config -- if `fillerChance` is not 0, and `fillerList` is empty, then add a stone block.
  Alternatively, `MeteorParadigmComponent` could have a `static` field that defines what the default block is?
  Since it is literally just stone I don't consider this a big "magic value" issue; but still if for whatever reason someone wants to change the default filler block, it is better to have it declared in one place.

Addressed in 3fe4b5b by setting the fillerList to stone with a weight of 1 when the weight is 0 or there is no block list supplied.

Minecraft crashes in MeteorParadigm.parseStringArray() if a filler or block list in a meteor config is written improperly. It appears to be a problem with parseInt in the legacy config section, and removing that section prevents that crash. Should there be more error checking there, or will that be removed soon enough that it won't be a problem?

It also crashes from a MalformedJsonException JsonSyntaxExpression in Meteor.loadConfig() if a meteor config is malformed (E.g. missing a comma). Should I move that to a try catch block add a catch block for that error and write an error to the log if that happens so Minecraft can continue to load?
Edit: Addressed in 4dc4573

[AbdielKavash]

Sorry about the delay; functionally everything looks good, check my comments for last couple of technical details.

[AbdielKavash]

All looks good now!

As I said above we will wait until 2.7 to actually merge this, so if you have any other ideas feel free to continue working on it.

[koolkrafter5]

All looks good now!

As I said above we will wait until 2.7 to actually merge this, so if you have any other ideas feel free to continue working on it.

Awesome! I think I'll look into making the reagent effects for meteors configurable next.

[AbdielKavash]

All looks good now!
As I said above we will wait until 2.7 to actually merge this, so if you have any other ideas feel free to continue working on it.

Awesome! I think I'll look into making the reagent effects for meteors configurable next.

We should probably have a discussion about this before any big changes, because it might significantly affect balance. (Which might not be a bad thing necessarily.)

One thing I would like though is to keep the effect of the "base" reagents (as on the FTB wiki for example) unchanged, so as to not confuse people googling information about the rituals. There are plenty of other reagents we can use to add fun effects without having to change those.

[koolkrafter5]

One thing I would like though is to keep the effect of the "base" reagents (as on the FTB wiki for example) unchanged...

That was my plan for when I would add this. The current reagents would stay the same in the default configuration, but it would leave the ability for people to tweak their effects and for other reagents to be added.

Latest commit was for something that simplifies the code added here and is useful for the reagent stuff, but I will make another PR from a different branch of my BM repo for the rest of the reagent configuration feature.

Could we possibly add dynamic pages to NEI that explain the reagent effects? I feel like that would make these and any future changes more discoverable for players.

[AbdielKavash]

Could we possibly add dynamic pages to NEI that explain the reagent effects? I feel like that would make these and any future changes more discoverable for players.

That would be awesome, though ideally it should be done in a way that it works for all rituals.

[Dream-Master]

Is this frozen or should be added for 2.7.0 ?

[AbdielKavash]

This currently does not have any gameplay impact, as no meteors that are currently defined contain any filler blocks. Thus I think it is safer to delay until after 2.7. Then we can adjust the composition of various meteors, and possibly add filler where needed or reasonable. (This would be a balance change.)