KnightMiner

From a user standpoint, I don't see much reason to use 1.19.2 over 1.19.3. The lack of content changes means there is no reason to not migrate to 1.19.3 other than mods that never got a chance to update (and to me, it seems unlikely someone who jumped on 1.19.2 would not also jump on 1.19.3) On the other hand, 1.18.2 has been around long enough to build up a decent select of mods. I would rather give it more time for those mods to stabilize and expand then have another short-lived LTS version.

I don't want to call anything that is not reversible "storage". Because storage implies reversible. You would not store your quartz as quartz blocks as then you lose it when you need to craft comparators. I went with decorative as all 2x2 recipes are for the sake of decoration thus far, but its a fair point that it may be a bit vague. "compressed" or "packed" are two words that come to mind, but both are used in mods or vanilla for 3x3 at this time. "bricks" is another option, but would probably hit confusion with the stone brick style blocks, so not sure what else to suggest as a prefix.

Currently, Forge tags two things under the prefix "storage_blocks/": 3x3 storage blocks such as iron, gold, redstone, etc., and the one 2x2 decorative block quartz, which is notably not a reversible recipe (making it obviously not a storage block). With 1.17, we are also gaining copper ingots as a 2x2 block instead of 3x3, if this is tagged as "storage_blocks/copper" for "consistency" with other blocks, it means we have an incompatibly with any mod that added a 3x3 copper block recipe before 1.17. We have solved this issue with other mineral types before by using different prefixes, such as there are a few different variants of plates (large plate, small plate) based on the number of ingots needed. I propose doing the same with blocks. "storage_blocks/" will be kept for 3x3 crafting, and a new prefix "decorative_blocks/" will be added for the sake of 2x2 crafting, which should include quartz blocks, the 1.17 copper blocks, and potentially brick blocks (as bricks are tagged under ingots). This will solve any potential conflict with mods adding 3x3 copper blocks as you can guarantee anything tagged "storage_blocks/copper" is worth 9 ingots, while anything tagged "decorative_blocks/copper" (which includes the vanilla block) will be worth 4 ingots. In addition, if a mod wants their metal block to be a 2x2 crafting recipe like vanilla copper, they can tag it as "decorative_blocks/" to prevent confusion with other mods adding the same metal. For the sake of migration, I propose adding a "decorative_blocks/quartz" tag into 1.16, and having it read from "storage_blocks/quartz". Then ideally we deprecate the "storage_blocks" tag for removal in 1.17, so modders can update to the correct tag before then. On a related note, Forge's definition of a "dust" and a "gem" are very odd to say the least. Prismarine shards are classified as a dust and prismarine crystals as a gem, but neither have that many similar properties with the other items in those tags (really, crystals behave more like a dust of the two as its dropped from lamps like glowstone dust from glowstone). Lapis is also tagged as a gem, but its relationship to its ore is different from both other gems (such as diamond) and even dusts (such as redstone). This is mainly an issue when a mod adds a new item and is trying to determine how to tag it, thus it would help in both this case and in the block case to attach a specific definition to what behavior is expected with items in those tags. tl;dr: the main proposal here is the addition of "decorative_blocks/" tags for 2x2 crafting. In addition, this proposal suggests attaching definitions to each tag prefix to help with consistency among mod authors, and to adjust Forge tags to better fit those definitions.

You miss the point. The 1mb loss is disabling pulling buckets out. Because you cannot pull 999mb as a bucket. Any method that lets you pull out 999mb as a bucket brings back the duplication. Let me try to put the duplication more in terms that most players are used to. What if I told you for a low cost of 7 iron and a catalyst of 8 ingots of a particular metal, you could receive a free nugget of that metal in about 20 seconds, and easily an ingot in a minute or two? This could be used to produce enderium, manyullyn, draconium, any metal you have in your modpack. Would you consider such an exploit to be acceptable duplication? The standard for fluid for a nugget is a measly 16mb, and for an ingot 144mb. Neither is a lot if you can get a free 1mb in a few seconds. When you look at duplication as acceptable because on a grand scale it means little, you forget that not all recipes work on a grand scale. Some recipes simply need 16mb of a fluid for an expensive resource. And really, the idea that any duplication is simply "acceptable" is stupid. If you think buckets are unlikely to get switched from 1000mb, argue that it is unlikely to be switched and why, I could accept that argument. But arguing that what we have right now causes no problems that cannot be easily solved is ridiculous.

It is a big deal. Any fluid duplication is fluid duplication, which is bad design. You may think 1mb is almost nothing, but some mods add fluids that are expensive enough and used in small enough quantities that it quickly becomes a big deal, and automated users exist that let you automate "do thing 1000 times" super easy, so now my mod becomes a free fluid generator. I will not subject my mod to such an obvious fluid duplication bug even if its as "trivial" as you claim. That is just taking a broken system and using it despite it being broken. And no, disabling pulling buckets out is equally bad. Players should not have to suffer and lose vanilla functionality because forge fluid units do not work with vanilla. Until we have something divisible by 3, fluid stacks are not practical to use for cauldrons or water bottles.

The main problem in this debate is not ingots. While ingots point out a clear flaw in the fluid units since 1000mb does not work with vanilla crafting, it is fair to say that does not have to match. However, the fact that forge fluid units are incompatible with two out of three of Mojang's one fluid container, that is bottles and the cauldron, is a huge problem. By this incompatibility, we are stuck with no fluid amount attributed to water bottles, and no mods can safely use bottles or cauldrons as a fluid container due to competing standards. Yes, in Java the cauldron can only hold water and bottles just water or potions, but in Bedrock it works on any fluid and there is a good chance that will one day end up in Java, so it needs to be considered in modding APIs. As soon as you write off cauldrons as an "acceptable duplication" or 1/1000mb as an acceptable loss, you negate an entire vanilla mechanic being used in fluids at all, because if its an acceptable dupe for water, anything using that is an acceptable duplication. It is terrible game design to expect your math to not work out so you delete remainders or duplicate amounts. It is also terrible mod design to actively ignore mechanics in the base game like that. An additional point is does it really matter that a bucket is 1000 parts? Players only see "I need X amount to craft this", that number can mean whatever modders want. I think its much more likely a player is thinking "1 bucket lets me craft 10 of these" than "I need 100mb to craft this" as the way you obtain most fluids is by the bucket.

Making a nugget the smallest unit is not great when you want to support things that are not a multiple of 9. Using fractions or floats will lead to users having tiny useless fractional units. Some mod dev will always come along and require a smaller and smaller fluid. Plus, floats are incredibly inaccurate for precise numbers when it comes to any non-base 2 fraction. Having two numbers for conversion is just a pain to both the developers and the end users. Hidden amounts of fluid are bad, and having two visible numbers is just unneeded complexity. Why would you delete the user's fluid for wanting to use a fluid container? Fluid containers should not be lossy The biggest things to remember here are we want a system that is easy to use for the end user, so ideally there is only one number they have to keep track of. We also want compatibility not just with base 9, but also base 4.

The reason to make them equal is its better for the player. Its a bit dumb that you cannot just pour one block of a molten metal into a bucket, then carry that to another location, you have to either make a custom fluid container to hold a "block", or get stuck with leftovers. All vanilla unit crafting is base 9 or base 4, so its pretty odd that buckets would use base 10. The bigger problem is Forge buckets are inconsistent with vanilla's one fluid container, the cauldron. There is no way to express a cauldron level (bottle) in mb, it always comes down to 333 and a third. This makes things very difficult in one of my mods as I attempt to add more cauldron recipes using fluids, but am stuck not allowing proper fluid pipe support. For specific number, its hard to choose one. I like the idea of 720, as you can divide 10 into it, but you lose support for nuggets then as its block / 81. 1620 is the smallest number that is divisible by 81 (ingots, nuggets, and blocks), 10 (nice round numbers), and 4 (quartz, glowstone), so its an option. I agree a unit name change would be required, unless we come up with another word besides "milli" that means part and cheese the whole thing. I agree this is a potentially huge change, but with vanilla moving towards proper fluids, it might be a good time to start supporting their units rather than ignoring them entirely.

Is is possible to get an array of all variants of an ItemStack with a wildcard metadata, for the sake of iterating? Specifically, I have a recipe that is suppose to return any type of sapling, but when grabbing the possible types ("treeSapling") from the OreFictionary, I just get a few ItemStacks with wildcard meta rather than what I want which is a list of all possible sapling types.