Bucket Volume: Or, imperial vs metric.

[hanetzer]

Previously

Basic gist: 1000mb of molten iron/gold/etc does not divide evenly by 9 (ingots per

block) or 81 (nuggets per block). Molten $x is a fairly common concept in a lot

of mods and is a large use of the fluid system.

 

We're '''soon''' to be moving to 1.16, so if a change like this is to be done, now would

be the time to do it.

Edited June 17, 2020 by hanetzer

[laz2727]

The best value would probably be an anti-prime, like 720 or 5040.

[NinjaPhenix]

I don't work with fluids in any way, but I'd rather see a solution like a Faction data type which can cope with someone taking away any fractional amount e.g. 5/17

 

and if someone wanted to make an apple pie which required pi apple sauce buckets? ¯\_(ツ)_/¯

[Lanse505]

So as I wrote on Github this concept of fluid amounts and fluid granularity has been discussed in length several times in several minecraft-related communities.
The issue always boils down to an acceptable standard that fits most peoples use-case and makes sense from a human-level base math standard.

The concept of 1 bucket = 1000mB is rather straight forward since it's all just a power of 10 or whatever.
So it's easy for people to do the math "oh okey so I need 32 buckets, that's 32 * 1000 so 32000.

The counter point is that the very granular nature of a system based around singular increments instead of measured objects is inherently less coherent when dealing with stuff like item/block to fluid conversion rations.

For example:
1 Block = 1000mB = 1 Bucket
1 Block = 9 Ingots
1000mB / 9 = 111.111111...mB

If we then divide it further into nuggets so
1 ingot = 9 nuggets
111.111111.../9 = 12,345679... mB.

So the suggested alternative is going to something more akin to a "imperial system" where things are tied to "in theory" objects and not singular units.

Aka 9 Nuggets = 1 Ingot = 1/9 Block

This means that if we establish the value of one core object, we can iterate it through-out for most cases.
For example:
1 Nugget = 16mB
1 Ingot = 144mB
1 Block = 1 Bucket = 1296mb

Through this we can easily establish that 1 bottle is about 1/3 block since 1 bucket of water in a cauldron yields 3 bottles.
So the value of 1 bottle is 1296/3 = 432mB.

We can also establish through block measurements that in theory:
A Slab (half a block) should be equivalent to 648mB.
A Pane (1/16th of a block) should be equivalent to 81mB (not accounting for the recipe).
If we do the calculation based on the recipe, a pane is worth about: 498mB (accounting for 1 block being worth about 2.6 panes).

Etc.

Once again as I said on the github issue the biggest issue with a suggested change like this is while it in theory "makes more sense".
It's changing a fundemental concept of how the modded fluid system has functioned for the longest system and uprooting the established status-quo of fluid recipes, values, tank sizes, etc.
And people will need time to get used to a change like that if it were to go into effect.


I'm not against it, but it's certainly something that needs proper deep discussion and at least a majority acceptance if it were to be applied.

[hanetzer]

14 minutes ago, Lanse505 said:

I'm not against it, but it's certainly something that needs proper deep discussion and at least a majority acceptance if it were to be applied.

Which is why I've brought it up. It is definitely something that should just 'be done' without

some back and forth between various modding groups.

[DaemonUmbra]

If it changes we'll need new units which will spawn another debate, as mB (or milli-buckets) is inherently a metric measure and is by definition, 1/1000th of a bucket (which itself is a full cubic meter of fluid because Minecraft).

[hanetzer]

1 hour ago, DaemonUmbra said:

If it changes we'll need new units which will spawn another debate, as mB (or milli-buckets) is inherently a metric measure and is by definition, 1/1000th of a bucket (which itself is a full cubic meter of fluid because Minecraft).

Agreed, whole point of the pr, and now this thread, is to spawn debate and ideas. Perhaps this is

overthought but it is a common enough use of fluids in mods to warrant consideration.

[DavidM]

I don’t see why a block of metal should be melted down into exactly one bucket of liquid.

There is no reason why the two should be equal (besides perhaps a slight convenience in calculating resources, but will likely cause more troubles than benefits).

Edited June 18, 2020 by DavidM

[KnightMiner]

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.

[hanetzer]

Never even considered the cauldron angle but if you can get three 'even' bottles out

of it then the metric units are a bit unfit as well.

[Darkere]

I'm all for fixing the weird inconsistencies with bucket volumes.

 

All potential issues I can think of can be fixed by each mod dev by using other display methods. 

1/9th of a bucket or 1 Ingot's worth of fluid is easier to work with than the two split systems, where machines tend to use round numbers if the fluid is not a metal or the ingot values every time it can be converted into an item. 

 

However, what do we call 1/1296th of a bucket? Mini Buckets?

Edited June 18, 2020 by Darkere

[MFMods]

look, this isn't a new question to be answered. tech mods exist. old, established tech mods. and in them, one ingot is 144mb. so what choice do you have?
choice "a": ingot is 144mb, block is 9x that much, somewhat more than fits in a bucket.

choice "b": you make it configurable, and then users set it to choice "a" so there wouldn't be a magical fluid creation loop. it doesn't necessarily have to be 144mb.

 

some other value is possible if all overlapping mods (within a pack) make it configurable. but i assure you no one will set the option to 111mb or 111.11mb

[TheGreyGhost]

Howdy

 

From a physical interpretation point of view, I think it really boils down to either

1) You define a single base indivisible unit (such as a nugget, or if that's too big, then a "molecule" of fluid) and make sure all your derived units are an integer multiple of those; or

2) You permit folks to use fractions of a unit (i.e. use floats instead of ints) - perhaps by adding new methods to your interface; or

3) You ensure that conversions between units (when topping up buckets) automatically converts using a float factor with a separately-tracked residual (think ticks and partialticks); or

4) Your change your gameplay definition so that nine ingots won't fit into one bucket, i.e. if you try to fit nine ingots into a bucket you get a full bucket, but when you try to convert back from the bucket into ingots, you only get (eg) eight.  The rest is "lost during the melting and casting process".

 

-TGG

 

[KnightMiner]

1. Making a nugget the smallest unit is not great when you want to support things that are not a multiple of 9.
2. 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.
3. 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.
4. 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.

[Draco18s]

11 minutes ago, KnightMiner said:

We also want compatibility not just with base 9, but also base 4.

Funny how 144mb for an ingot means that a nugget is 16mb, which is divisible by 4, and the 144 is also divisible by 9.

But oh no, a bucket is only 1000mb, meaning an entire metal block block (9 ingots) does not perfectly fit in a bucket.

 

So no, you don't want compatibility with base 4 and base 9, but also base 10. This is as mathematically possible as perfectly tuning a piano.

Edited June 19, 2020 by Draco18s

[hanetzer]

2 hours ago, Draco18s said:

Funny how 144mb for an ingot means that a nugget is 16mb, which is divisible by 4, and the 144 is also divisible by 9.

But oh no, a bucket is only 1000mb, meaning an entire metal block block (9 ingots) does not perfectly fit in a bucket.

 

So no, you don't want compatibility with base 4 and base 9, but also base 10. This is as mathematically possible as perfectly tuning a piano.

True, but the 'bucket is only 1000mb' is purely our (forge's) invention. Vanilla only has (iirc)

one liquid which can be divided, and it only divides into thirds (water in cauldron into three

bottles). Do correct me if I'm wrong, however.

[Draco18s]

You're correct, the only dividable liquid in vanilla is water, and only into thirds (although how many mb actually goes into a bottle and why only three bottles to a cauldron, we can't really say (i.e. a lot less water is stored in a cauldron than out in the world as a single block, as a cauldron takes up some of the space and a source block is enough water to partially fill its own volume AND seven other blocks)).

 

But even if we disregard the 1000mb unit and try to find another amount that fits, I contend that you're not going to find one.

 

It needs to be divisible by 81 (9 nuggets * 9 ingots to a block, this fortunately gets us a divided by 3 for free) and divisible by some number of 4s.

So we get 324 as the smallest possible value that satisfies this requirement, but is a really awkward number to work with.

The next is 1296 (already the value in use)

5184

20736

82944

331776

and so on, none of which are particularly nice to work with (ie. close to a whole power of 10).

 

The only one that's small enough to be useful, but round enough for humans to easily work with, is 1296.

Why doesn't a bucket actually hold 1296? Well because another mod came up with the milibucket unit of measure and 1296 was adopted afterwards as the rational value to work with (due to the 81*16 composite) and the two were *close enough* to just deal with the discrepancy as either imperfect conversions, transportation loss, or by just making the user have to use more than one bucket worth to get a full iron block out of it.

Edited June 19, 2020 by Draco18s

[laz2727]

 

You seem to be having issues with simple mathematics. You can't make a number divisible by 10 without having 10 (or, rather, 2*5) in its factors somewhere.

The smallest number that can be divided by 81, 4 and 10 is very easy to get: 81x4x5=1620. It was already proposed by KnightMiner.

[TheGreyGhost]

40 minutes ago, laz2727 said:

 

You seem to be having issues with simple mathematics. You can't make a number divisible by 10 without having 10 (or, rather, 2*5) in its factors somewhere.

The smallest number that can be divided by 81, 4 and 10 is very easy to get: 81x4x5=1620. It was already proposed by KnightMiner.

Well to be honest, it's not quite as simple as that, because folks want milliBuckets, i.e. divisible by 1000

 

If our desired "whole units" are:

1 bucket

1 nugget

1 ingot

1 block

1 mBucket i.e. 1/1000 of a block 

 

and the conversions are

1 bucket = 1 block

1 block = 9 ingots             (3^2)

1 ingot = 9 nuggets           (3^2)

1 block = 1000 mBuckets  (2^3 * 5^3)

 

then if you want to retain integral numbers for all of those units, you need to define 

"1 atom" = the smallest indivisible unit --> 81,000 times smaller than a block

i.e.

1 mBucket = 81 atoms

1 nugget = 1000 atoms

1 ingot = 9000 atoms

1 block = 1 bucket = 81000 atoms

 

if you're measuring atoms using 32 bit ints, this is still reasonable (can hold up to 50,000 blocks' worth which seems like plenty)

Even if you want to add a further divisibility into 1/16 of a block (i.e. panes), it probably still works (-> max value of 25,000 blocks)

1 atom = 1 / 162,000 of a block

i.e.

1 mBucket = 162 atoms

1 nugget = 18,000 atoms

1 ingot = 2,000 atoms

1 block = 1 bucket = 162 atoms

1 pane = 10,125 atoms

 

But it seems very silly to me to define a milliBucket as anything except 1/1000 of a Bucket.

 

I think this discussion would benefit a lot from systematically writing down what the goals of the users are from a gameplay perspective.

 

TGG

 

13 hours ago, KnightMiner said:

1. Making a nugget the smallest unit is not great when you want to support things that are not a multiple of 9.
2. 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.
3. 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.
4. 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.

I agree with you for (1), (3), and (4).

I don't understand what you mean for (2):  You're right that many numbers can't be exactly represented by floats, there is a round off problem, but there are many ways to deal with that.  In practice the roundoffs are so small you would never notice from a user's point of view.

 

To paraphrase your final statement - you need to define an atom, the smallest indivisible unit.  "milliBuckets" is a red herring.

 

 

 

 

 

 

 

 

 

 

[laz2727]

People want mB because they're used to the unit, not because it's actually important.

[hanetzer]

Here's an idea. baseline unit: boz (bucket ounce).

1 nugget = 16boz

1 ingot = 9 nuggets = 144 boz

1 3x3 block = 9 ingots = 81 nuggets = 1296boz

1 bucket = 1 block.

For things that are like the quoted text

On 6/17/2020 at 3:44 PM, Lanse505 said:

The concept of 1 bucket = 1000mB is rather straight forward since it's all just a power of 10 or whatever.
So it's easy for people to do the math "oh okey so I need 32 buckets, that's 32 * 1000 so 32000.

Just say buckets and don't invoke the lower measures at all. No one in the real world thinks "oh okey so I need 32 gallons, that's 32gal * 128oz so 4096oz",

they just get 32 gallons.

[TheGreyGhost]

So what I think the goals are, based on the discussion above:

1) the user wants to think in easy ratios for recipes- nuggets, ingots, blocks

2) the user wants to think in easy ratios for panes - a pane is 1/16 of a block

3) the choice of the "atom" ("bucket ounce" or just "ounce" or "grain" or "blob" or whatever) should ensure that panes, nuggets, ingots, and block can be represented as an integral number of atoms, which ensures conservation of mass during conversion.

 

The milliBucket could be maintained but would be a representation (rounded off) of the actual number of atoms; eg 1 ingot is approximately 111 millibuckets, not exact.   Recipes etc use the atoms, not millibuckets. If a method does take millibuckets as an input, it would be rounded to the nearest atoms.

 

A recipe for making panes would either have left over partial nuggets, or would throw some away in a round trip (nuggets -> panes -> nuggets) but that's unavoidable unless you enforce nuggets -> blocks -> panes.

 

 

 

 

 

 

 

 

[Draco18s]

10 hours ago, laz2727 said:

 

You seem to be having issues with simple mathematics. You can't make a number divisible by 10 without having 10 (or, rather, 2*5) in its factors somewhere.

The smallest number that can be divided by 81, 4 and 10 is very easy to get: 81x4x5=1620. It was already proposed by KnightMiner.

Except that we don't want it divisible by 10, what we actually want is for it to be a clean power of 10. 1620 is not a "nice round number" as far as we, decimal loving, humans like.

I mean, yeah, there's the imperial units system which is all over the place, but we don't actually deal with worrying about how many ounces are in a gallon. The problem with fractional bucket values is you'd have to assign unique names to those values and then have to figure out how to display quantities in a UI. "One bucket, two bottles, and three nuggets of liquid iron."

Edited June 20, 2020 by Draco18s

[hanetzer]

13 minutes ago, Draco18s said:

The problem with fractional bucket values is you'd have to assign unique names to those values and then have to figure out how to display quantities in a UI. "One bucket, two bottles, and three nuggets of liquid iron."

This is pretty valid, but its honestly pretty easy modular math? And I don't think we'd ever consider liquid iron in terms of 'bottles' since that's (as far

as I have seen in existing mods) just a thing that's not done. Would be, assuming 3 bottles a bucket, 'One bucket/block, 6 ingots, and 3 nuggets of

liquid iron'. TiC for 1.12 had a thing that handled it pretty nicely, and the UI side of things is mostly mod controlled right?

[hanetzer]

On 6/20/2020 at 10:15 AM, TheGreyGhost said:

So what I think the goals are, based on the discussion above:

1) the user wants to think in easy ratios for recipes- nuggets, ingots, blocks

2) the user wants to think in easy ratios for panes - a pane is 1/16 of a block

3) the choice of the "atom" ("bucket ounce" or just "ounce" or "grain" or "blob" or whatever) should ensure that panes, nuggets, ingots, and block can be represented as an integral number of atoms, which ensures conservation of mass during conversion.

 

The milliBucket could be maintained but would be a representation (rounded off) of the actual number of atoms; eg 1 ingot is approximately 111 millibuckets, not exact.   Recipes etc use the atoms, not millibuckets. If a method does take millibuckets as an input, it would be rounded to the nearest atoms.

 

A recipe for making panes would either have left over partial nuggets, or would throw some away in a round trip (nuggets -> panes -> nuggets) but that's unavoidable unless you enforce nuggets -> blocks -> panes.

Honestly I don't think mb would be useful to keep around, or perhaps keep it equal to a bucket ounce/whatever

so folks doing chem mods which use liquids which never become blocks (or came from blocks) can stay metric.