Sign in to follow this  
Followers 1
MinskWurdalak

Default system of Forge tags for ores will have to expand in the future versions of Minecraft

By MinskWurdalak, in Suggestions

Recommended Posts

MinskWurdalak    0

MinskWurdalak
Posted (edited)

For everyone who make datapacks (and modpacks), it is not a news that mods (mostly technological), when it comes to processing ores into other materials rely on Forge tags, rather than their ID. This allows greater cross-mod compatibility when it comes to processing variety of ores. This system works as following:

  1. All ores are given tag "ores.json" in directories "data/forge/tags/items/" and "data/forge/tags/blocks/".
  2. All ores that contain certain materials are tagged "name_of_material.json" in directories "data/forge/tags/items/tags/ores/" and "data/forge/tags/blocks/ores/".

 

These tags are pretty much enough for most processes that involve ores. However, some mods add process that are more immersive in relation to on what kind of rock this ore is based on. For example, when processing vanilla iron ore Create mod crushing wheels output crushed ores and with 1/8 probability also output cobblestone. But they will also output cobblestone when crushing any ore that has "forge:ores/iron" tag, even if design wise it isn't based on stone. Another example, where ore base is relevant, is mods that allow to reinfuse or turn rock into ore, such as infusion in Mekanism or orechid in Botania. While most mods just add one base per ore types, some are more diverse. Subterranean Wilderness, for example, is mod that refurbish caves depending on biome, adding variants for all ore types, for example desert caves' walls are sandstone based and contain sandstone based variants of all vanilla ores.


Such mods are now uncommon, but it seems that this going to change in the future. Vanilla Minecraft already has ore basis variation: overworld gold ore with stone base and nether gold ore with netherrack base. In upcoming 1.17 Caves & Cliffs update, 5/8 of overworld ores will have two variants: one based on stone and one based on grimstone. In order to confront this new reality and maintain compatibility between technological mods, new family of tags should be added. I propose the following solution:
All ores that are based on certain rocks are to be tagged "name_of_ore_base.json" in directories "data/forge/tags/items/tags/ore_bases/" and "data/forge/tags/blocks/ore_bases/".

For example, vanilla stone gold ore would get additional tag "forge:ore_bases/stone", vanilla grimstone gold ore would get additional tag "forge:ore_bases/grimstone" and vanilla nether gold ore would get additional tag "forge:ore_bases/netherrack". Most processes would still use just old tags that denote carried material, but this additional tag system would allow to maintain many technological mods proper functionality when it comes to ore crashing and ore creation recipes by employing both tags.

P.S. I know that I can add/remove/change recipes and tags with CraftTweaker, Kubejs and/or datapacks. I am talking about default Forge tag convention that might be useful in the future.

Edited by MinskWurdalak
Wording errors

Share this post

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
Sign in to follow this  
Followers 1
Go To Topic Listing


  • Recently Browsing

    No registered users viewing this page.

  • Posts

    • GenElectrovise
      [Answered, not solved] Automated testing in Forge

      By GenElectrovise · Posted

      Right then. I've tried some thing out over the last few days and come to the following verdict:   Unit-testing Minecraft and Forge classes is really hard. Let me give you an example:   For context, I'm using JUnit 5 with Mockito 3.8.  I have a custom implementation of a fluid tank. I first tried writing a simple unit-test to check that "when there is no fluid in the tank and I try to drain some, drain zero units". I used to extend FluidTank, but in trying to write a simple test, I niow implement IFluidHandler and IFluidTank directly. The reason for this is that creating my object to test, it constructs a FluidTank, which contains this field: @Nonnull protected FluidStack fluid = FluidStack.EMPTY; When FluidStack.EMPTY (a static field) is called on, the JVM tries to also load FluidStack's other static field, FluidStack.CODEC. This in turn causes a cascade of other static initialisations which  culminates in crashing the JVM with a NullPointerException sometime around it trying to either load a World or access a Registry. So not good. I tried to @InjectMocks on that field, but the injection occurs after the object is instantiated, so the JVM has already crashed.   In order to get around this, you have to implement the aforementioned interfaces directly because: 1) They are the required interfaces so they have to be there anyway; 2) They contain no static fields, so they won't start a cascade.   The upshot? Forge and Minecraft are not designed to be tested in this way (not surprising), and have interlinking fields with will cause crashes. What can we do? Well, you can test anything that you write. You can't test a FluidTank, but you can test an IFluidTank. Try to not have unnecessary static fields, and use constructor injection when possible. (This would fix the problem above: see my code below)   // How to fix that crash // In FluidTank.java: // Don't initialise the field now! protected FluidStack fluid; // Add a new constructor to allow modders to specify a starting stack. public FluidTank(int capacity, Predicate<FluidStack> validator, FluidStack initialFluid) // Using constructor injection here means that a tester *can* inject a mock object for the initialFluid. This means that no initialisation cascade occurs! { this.capacity = capacity; this.validator = validator; // Probably a good idea to test the stack for safety. if (!validator.test(initialFluid)) throw new IllegalStateException("Whatever kind of error you want"); this.fluid = initialFluid; } // Changing the current constructor to just use the overloaded one. public FluidTank(int capacity, Predicate<FluidStack> validator) { // This time it's safer to default to EMPTY this(capacity, validator, FluidStack.EMPTY); }   I realise that this all sounds very... ahhh... something? (can't think of the word) I'm certainly not the expert on this and I'm not a professional tester so I've probably made some errors or assumptions here. I would put this in as a pull request on the Forge Github if I could actually clone it (never works for some reason...)   Best, GenElectrovise
    • Maxi90909
      Worldgenerator freeze

      By Maxi90909 · Posted

      Hi under this link and the known issues 1.14-1.16 you can find the Worldgenerator freeze tab. I have this issue since I have played on 1.16.4-5 and I don't know how to fix it. The problem is that it just hocks up my game without a crash, I don't have a crash report because I don't get one. The attached file are my mods listed in a Textdocument. Please let me know if there is an issue. I would attach my latest logs and debug logs but I can't because see attached image.   Chunk-Pregenerator - Mods - Minecraft - CurseForge  Known issues and Potential Fixes 1.14-1.16: My mods.txt
    • CommandCore
      Projectile Entity is Invisible

      By CommandCore · Posted

      I tried this with no luck: RenderingRegistry.registerEntityRenderingHandler(RegistryHandler.HEARTBALL_PROJECTILE.get(), HeartballRenderer::new);  
    • Pixelovski
      Stuck on "Configuration file X is not correct. Correcting"

      By Pixelovski · Posted

      Hello, My friends and I just bought a Minecraft hosting to use with forge. And we're encountering problem where the server starts fine, we can connect, but it just keeps spitting out warnings about incorrect config files and it's really annoying and I think it eats up some resources... When we tried forge by itself without any mods there wasn't any issue. When I try to run the server with the exact same files on my pc it works fine. So is there way to just stop the server from trying to correct the config files (or whatever it is that it is doing) or something? Thank you in advance.   Here is the link to the latest log file: https://www.dropbox.com/s/1ni8tko383q4mlg/2021-03-07-10.log?dl=0
    • Nyko
      [1.16.5] overwriting the maximum build height

      By Nyko · Posted

      thanks for the info, since the whole thing sounds pretty complicated, I will probably not change it

  • Topics

  • Who's Online (See full list)