#Fluid Unit Hell

1 messages · Page 3 of 1

elfin yacht
#

bricks being ingots probably predates to some garbage oredictionary tag from ye olde times™️

pure lynx
#

but yeah, if someone for some reason wanted to make sticks meltable theyd be a different amount than a normal rod

elfin yacht
#

and nobody ever questioned it during migration

edgy ether
tawdry wolf
#

and nobody questioned it for several years? I quite honestly find that hard to believe

edgy ether
#

No one did sooo

#

Even fabric was fine with it.

elfin yacht
#

nobody questions anything

#

there's too many things to sift through, lol

#

We have decade old things that nobody has ever revisited

pure lynx
#

having to deal with decisions people made 10 years ago is tough

elfin yacht
#

Like we still have events from 1.2 that have no javadocs screm

tawdry wolf
#

okay then let's forget bricks

edgy ether
#

Actually stop everyone

tawdry wolf
#

let's do quartz vs. diamonds instead because that will be a recurring issue

edgy ether
#

Bricks is not in ingot tag in 1.21. Who is saying that

elfin yacht
#

Nobody

edgy ether
elfin yacht
#

we were talking about historically™️

#

plus it still references the old ingot tag

pure lynx
#

we just went over that xd

elfin yacht
pure lynx
#

boop

edgy ether
#

Well historically, forge just shat out tags for whatever they feel like

tawdry wolf
#

I said it was, but I was wrong - I was remembering from before the tag rework

elfin yacht
#

Nonetheless™️ - think at the medium here

#

Item conventions are defined at the tag level

edgy ether
#

Legacy to reduce chances of people breaking when porting. These Backport stuff will be removed in 1.22

elfin yacht
#

Perhaps relegate fluids to the same

#

i.e. introduce c:fluids/molten_metal and bind fluid volumes strictly for that type of fluid

pure lynx
#

except we'd have a trillion different tags for a trillion slightly different use cases because we have to deal with stack sizes

#

its not going to help, itll just make things more complicated

#

and harder to change in the future

elfin yacht
#

You can't implement a system against a suggestion, but you can implement one against a standard

#

You can set a standard volume for molten metal fluid quantities

#

and make systems that operate on molten metals

tawdry wolf
#

but that leads to the same problem

pure lynx
#

^

tawdry wolf
#

what do we do for quartz and diamonds

elfin yacht
#

Nobody gets special molten metals™️

tawdry wolf
#

both are gems, I think we can all agree on that

#

but they have different block -> item conversions

#

what is FluidUnits.ONE_GEM gonna be?

#

250 or 100? or 90?

pure lynx
#

if you really wanted to, we could have a default data map that covers some basic use cases. but these would, again, not be required to use and a dev should still be given the power to choose a different amount for their units

tawdry wolf
#

yeah, providing defaults here is absolutely reasonable

elfin yacht
#

what is amethyst again

#

2x2?

tawdry wolf
#

ye

pure lynx
#

yes

tawdry wolf
#

amethyst and quartz are 2x2

#

diamond, emerald and lapis are 3x3

elfin yacht
#

scrims in mojang

edgy ether
tawdry wolf
#

prismarine is both™️

pure lynx
#

should we define gems vs crystals now kek

tawdry wolf
neon sequoia
#

farmer's delight

pure lynx
#

we're gonna end up with a million different tags for a million different standards, its not necessary

tawdry wolf
#

and we also have a similar situation for glowstone and redstone

pure lynx
#

oh truuuuueee

tawdry wolf
#

and for the different mods that add gunpowder blocks

elfin yacht
#

Eh you basically just need STORAGE_3x3 and STORAGE_2x2

tawdry wolf
#

which funnily enough, also can't agree on whether to make it a 2x2 or a 3x3 recipe

pure lynx
elfin yacht
#

is gunpowder a liquid thinkies

pure lynx
#

is this really "better"

tawdry wolf
pure lynx
#

is it simpler? i dont really see this as simpler in any way

tawdry wolf
pure lynx
#

oh god avaritia

neon sequoia
#

wait, what is even being discussed right now? i thought it was just custom fluid units

elfin yacht
#

I think you're missing some parts of a point, codex. Everything claiming it is an ingot should be the same fixed value

edgy ether
#

What is this about. Defining conversion rate of items to blocks for fluids to follow? If so, wasn’t the point of the fluid gui be that it doesn’t need to be standard as each mod would show their own fluid’s rates in ui

tawdry wolf
elfin yacht
#

We don't need to magically define every permutation of "things that might be"

tawdry wolf
#

that's precisely the point

tawdry wolf
elfin yacht
#

but an ingot is an ingot - we know what that is, and we have a rigid definition of it

tawdry wolf
#

you do

pure lynx
edgy ether
#

Shadow, stop scope creeping lol

elfin yacht
#

what thonk

#

I'm doing the opposite of that

tawdry wolf
#

if you say everyone knows how much fluid an ingot is (or is supposed to be), then I will heavily argue against that

edgy ether
#

Adding standards to when this should just be a display thing? That sounds like expanding scope

pure lynx
#

shadows is trying to not have this implemented, instead we're gonna get a 100 line long fluid tag class with a 400 line long fluid constants class

#

at that point is it even a standard

tawdry wolf
#

(Codex: I see you slowly drifting off into toxicity, please try to avoid that)

elfin yacht
tawdry wolf
#

yes exactly

elfin yacht
#

We have the ability to just fix that value

tawdry wolf
#

but you don't solve existing inconsistency by pressing a standard onto everyone

#

because not everyone will follow

edgy ether
tawdry wolf
#

something something xkcd 927

edgy ether
#

I do not want restrictions to mod’s ideas

elfin yacht
tawdry wolf
#

why not

pure lynx
#

no, we really dont. we've given a ton of different examples of why these values cannot be consistently standardized without simply alienating those who deviate from the standard in even the most minor of ways

edgy ether
pure lynx
elfin yacht
#

Well the block can't be a storage_blocks/

tawdry wolf
#

says who

elfin yacht
#

I don't want to imagine what kind of mess would occur if someone made a 2x2 storage block

#

Things that create and transform from ingot->storage block operate on the 9:1 ratio

tawdry wolf
edgy ether
elfin yacht
#

glowstone isn't a storage block

tawdry wolf
#

yes glowstone is a lossy conversation, but definitely out there

#

and it's not 9:1

pure lynx
#

i dont want to have to deal with recipes for 12 different kinds of ingots, 12 different kinds of storage blocks. this doesnt really simplify the system in any way, it just makes it more complicated. Your argument is trying to say that it would add complexity to introduce dynamic amounts for units, but adding and accounting for so many different standards is just as or even more complex

edgy ether
#

Shadow, to be clear, the entire point of storage blocks tag folder was for blocks crafted from only one resource type and has a mirror reverse recipe

neon sequoia
#

question: how would dynamic units work in pipes? would there just a be a FluidAmount class that has a list of fluid units and amounts?

edgy ether
#

So 2x2 and 5x5 can be storage blocks if the recipes are mirrored both ways

elfin yacht
#

5x5 concern

pure lynx
#

im not sure what you mean, no one transfers in measures other than millibuckets

tawdry wolf
#

storage_blocks has no gameplay implications whatsoever

#

at least not directly

astral stag
#

slime blocks are storage blocks

#

there is your counter example

tawdry wolf
#

or both

edgy ether
astral stag
#

<p></p>

#

ffs

tawdry wolf
#

1 ingot/s if the ingot unit is defined on the fluid, and 100 mB/s otherwise

edgy ether
tawdry wolf
#

or you max() them

elfin yacht
#

Perhaps I'm too old™️
The rules of the oredictionary were more strict than that tag definition

tawdry wolf
#

really, your call as a pipe implementer to make

pure lynx
tawdry wolf
#

but yeah, ^

astral stag
#

well it won't affect the API but it will affect how people are expected to implement transfer

neon sequoia
#

so the units will just be multiples of millibuckets?

tawdry wolf
astral stag
tawdry wolf
#

in the new one, yes

astral stag
#

don't you see how many layers of hopium there are

tawdry wolf
#

I do, and on both sides

#

I just personally see the pros outweigh the cons

pure lynx
#

ditto, the alternative doesnt really sound all that attractive to me

astral stag
#

I suppose you don't value simplicity as much as I do

tawdry wolf
#

I do

pure lynx
#

i dont really see it as simple tho

astral stag
#

the simple rule is "if your fluid doesn't fit the standard that's too bad"

#

same as "your mod needs more than simulations"

tawdry wolf
#

see: 1 molten quartz v 1 molten diamond

pure lynx
#

isnt the point of the mod loader to create and improve cross mod compatibility. what would be the point

tawdry wolf
#

both are completely valid standards

#

yet both are wildly different amounts

astral stag
#

what's the problem now? quartz can easily be 250 mb or some other arbitrary value

#

diamond should probably be 90 mb?

tawdry wolf
#

correct

elfin yacht
#

well they're both Gem as a unit

tawdry wolf
#

yet both are one gem

elfin yacht
#

so Gem as a unit can't both be 90 and 250

tawdry wolf
#

correct

astral stag
#

so we've established that a Gem is not a unit to put in the constants API

#

unless we do GEM_4 and GEM_9

elfin yacht
#

I mean you could just call quartz and amethyst a Crystal (which is 250)

pure lynx
#

if i wanted to truly create a tank that holds 1 ingot of any fluid, id need to go through every single standard and check what fluid is being inserted to dynamically set the limit based on which ingot standard im accepting. this is not simpler than just fluid.getUnitAmount("ingot")

tawdry wolf
#

do you mind elaborating on that constants API you're talking about?

edgy ether
#

I don’t think there should be any constant. Just bottle with javadoc to say non-water bottles

tawdry wolf
#

because that seems to actively work against this

astral stag
edgy ether
#

And bucket constant too

tawdry wolf
#

trivial is not necessarily good

pure lynx
astral stag
#

I say that's an irrelevant use case tbh. Make it 90 mb if you really want to.

pure lynx
#

-_-

tawdry wolf
#

how is melting a vanilla resource into a fluid an irrelevant usecase

#

lol

astral stag
#

I had this exact type of discussion for the transfer API 4 years ago

#

"we need <use case that doesn't exist> so we MUST have the more complicated API"

elfin yacht
#

is anyone actually out there making ingots that don't fit the player expectation of what an ingot is?

tawdry wolf
#

except that melting quartz and diamonds into fluids are both valid usecases

pure lynx
#

like im trying to not get upset but like, i feel like this is an entirely reasonable thing to want to do and the solution being presented by the neo maintainers is just "well yeah, you cant do that, tough shit i guess"

astral stag
#

and the valid answer is: 250 mb and 90 mb

elfin yacht
#

Okay so we call those different things™️

#

quartz is not a Gem if Diamond/Emerald/Lapis are a Gem

astral stag
#

™️

tawdry wolf
#

which you seem so keen on using (which I understand)

astral stag
#

isn't that a gem? kek

drifting wraith
#

no, that's a shard harold

tawdry wolf
#

if we can assume c:ingots to have 9:1 conversations to blocks, then we should also be able to assume that for c:gems, right?

#

well, here's your problem

astral stag
#

but it doesn't really matter; mods that choose non-equivalent "gems" will conflict and that's FINE

tawdry wolf
#

we cannot

tawdry wolf
astral stag
#

you'll have this exact problem with recipes

tawdry wolf
#

as a player, this is incredibly frustrating

astral stag
#

one mod has a 4x c:gems/xxx and one has a 9x c:gems/xxx recipe to a block

#

you're fucked anyway

tawdry wolf
pure lynx
#

but we can make a system that isnt that much more complicated that fixes all of these problems, i dont understand why you wouldnt at least consider it :/

elfin yacht
astral stag
tawdry wolf
#

your example is literally not related to fluids in any way

astral stag
#

that is precisely my point

tawdry wolf
#

I don't see how that is a point relevant to the discussion at hand

astral stag
#

it shows how pointless it is to find a solution in terms of fluid amounts, when the same issue exists for items already

pure lynx
astral stag
#

if multiple mods don't agree on what a gem is, you will already have a problem with your item recipes

tawdry wolf
#

but there is no issue for items because items don't have amounts

astral stag
#

there is nothing to solve with a complicated fluid amount system

astral stag
elfin yacht
#

Say the per-fluid-display-magic thing is implemented - what happens if you have two fluids in a shared tag that have different volume definitions?

#

that sounds like a mess

tawdry wolf
#

I did, and it's quite frankly useless

astral stag
#

that shows me that you didn't even understand the argument

pure lynx
drifting wraith
pure lynx
#

wdym?

elfin yacht
tawdry wolf
drifting wraith
#

haven't we just moved the goalposts from being defined based on blocks instead of mB?

elfin yacht
#

I'm asking about conflict resolution between tag-level definitions and fluid-level definitions

tawdry wolf
#

I really want to understand your point, but as it stands, I don't

tawdry wolf
#

no problem

astral stag
#

mod A: has a a:topaz_gem tagged as c:gems/topaz, and a recipe to create 4 c:gems/topaz to a topaz_block
mod B: has a b:topaz_gem tagged as c:gems/topaz, and a recipe to create 9 c:gems/topaz to a topaz_block

tawdry wolf
#

yes

#

I get that

astral stag
#

do you see how you can turn your 1 block of topaz into 2.25 blocks of topaz?

tawdry wolf
#

where is the part where this relates to fluids

#

ah that's what you mean

#

ok yeah that is an issue

#

however not as much as fluids are

#

by far not

pure lynx
#

your recipe would turn 1 block of topaz into 1 block's worth of liquid. then another recipe would accept 1 gems worth of liquid to return 1 gem item. the same liquid is used, this is not an issue because the fluid defines the ratios

tawdry wolf
#

and that is because fluids mostly reuse vanilla materials

#

like, I can think of at least 4 different mods that add molten iron

#

while I can think of exactly two that add topazes (and both of those I think use 9:1)

astral stag
#

two items (topaz gems and topaz gems) having the same tag, but different quantities

pure lynx
tawdry wolf
#

be my guest to extend this discussion to items

#

but that is the one case here where I will argue a non-issue

astral stag
pure lynx
#

we're talking about fluids here, it has to be converted to a fluid at some point for your argument to make any sense

tawdry wolf
#

which is correct, but doesn't make this system any less valid

elfin yacht
# tawdry wolf you specify "1 ingot of #c:molten_iron" in your recipe

This seems fine from a technical perspective. When we get into player expectations of how two fluids that should be the same behave I think it might have problems. This is mostly why I don't want to have the granularity be at the individual fluid level, or at least the individual fluid level should adhere to a tag-level bound

#

The expectations bleed into transfer and storage though

#

but realistically two people implementing molten iron will probably not randomly decide to use different representations

tawdry wolf
#

but you will run into issues for c:molten_gems

tawdry wolf
tawdry wolf
#

which is just bad

elfin yacht
#

GT has (iirc) mini dusts, which are 2x2 of a dust (which is 1:1 with ingots)

#

So they need all manner of weird factorization

tawdry wolf
#

or well, yes

elfin yacht
#

well that's just 144

#

I think™️

#

so not really any manner of weird factorization, just the same classic™️ ingot value

tawdry wolf
#

but why should that stop people from using Gregtech molten iron in a Tinkers smeltery

pure lynx
# 
{
  "input": "1x topaz block", 
  // result
  "fluid": "c:topaz",
  "amount": { "block": 1 }
}

Mod A has a 2x2 recipe and returns 1000 mb with each gem being 250 mb
Mod B has a 3x3 recipe and returns 900 mb with each gem being 100 mb

{
  "input" : {
    "fluid": "c:topaz",
    "amount": { "gem": 1 }
  },
  "result": "1 x topaz gem"
}

Mod A's 1000 mb of fluid gets consumed to return 4 gems because each gem is worth 250 mb, no dupe has ocurred
Mod B's 900 mb of fluid gets consumed to return 9 gems because each gem is worth 100, no dupe has occurred

tawdry wolf
elfin yacht
#

well why did tcon move to 90?

#

I know it used to be 144

#

its not like its any cleaner against the bucket value

tawdry wolf
#

I don't know

#

but that's really not important

#

the important part is that these different standards already exist

elfin yacht
#

Anyway, a player should be able to understand how much a tank holds in terms of the definition for that fluid, right?

tawdry wolf
#

correct

elfin yacht
#

i.e. a player knows how many ingots of X fit in a tank

tawdry wolf
#

correct

elfin yacht
#

now if the definition of that is inconsistent, they don't really get to know that

tawdry wolf
#

how so

pure lynx
#

limits cant be defined per fluid atm

#

BUT MY PR FIXES THAT 🥳

elfin yacht
#

it might hold N ingots of a:molten_iron on 90mB/ingot but only K ingots of b:molten_iron on 144mB/ingot

#

This might be particularly relevant with a smeltery

pure lynx
#

So the solution to all our woes is to merge my PR !

elfin yacht
#

because you have to alloy in certain ratios

#

so the sum of those alloys has to fit

tawdry wolf
astral stag
tawdry wolf
pure lynx
#

no, please do not do this

tawdry wolf
#

this will not solve anything

elfin yacht
pure lynx
#

if anything itll cause more issues, let us discuss the solution we've been actually talking about for the last few days :/

elfin yacht
#

So we have to address that as well

tawdry wolf
#

making a PR like this, over the heads of the ones actually proposing the system (because they will be the ones using it), will not solve anything

astral stag
#

the best way to counter a proposal is to make a counter-proposal

tawdry wolf
elfin yacht
#

Which means we do need to couple with fluid containers instead of acting like containment/transfer is separate

tawdry wolf
#

and, to reiterate, will not solve the problem at hand

astral stag
#

have respect for the solution that has been working for 10 years 😛

tawdry wolf
#

"working" is an overstatement

pure lynx
#

who said anything about "working"

#

i like this person

tawdry wolf
#

you mean the same "working" that has had capabilities "working" for several years?

#

or that had the damage pipeline "working" for several years?

astral stag
#

we're not going to throw everything out and start over; reworks are always a tradeoff

pure lynx
#

the point of neo is to look over decisions made a decade ago and consider better solutions that would benefit modders. this is not that

tawdry wolf
elfin yacht
#

ingots being 90 will be incompatible with GT systems

#

does MI not have mini dusts thonk

tawdry wolf
#

this PR can change that though

astral stag
elfin yacht
#

I mean yeah idk if GT minidusts are meltable

astral stag
#

and a limited amount of tiny dusts

#

tiny dusts™️ can be 10 mb

#

the question is: what is the amount for a small dust™️?

elfin yacht
#

there's small dusts?

#

gt is too complicated

pure lynx
#

understatement of the century

astral stag
#

MI had small dusts for some time until I realized that they were pointless

#

even tiny dusts are kept to a minimum...

tawdry wolf
#

Tech, it honestly surprises me that you're so against this, because I'd absolutely expect you to make use of this system if available

astral stag
#

most of my fluids have no connection to items

drifting wraith
#

was there a PR for the proposal? or just for the counter-proposal?

elfin yacht
#

There's a design doc for the original

#

no prs atm

tawdry wolf
#

design doc for the original, and the PR itself is WIP iirc

drifting wraith
#

I'm not sure I'm understanding how this is supposed to work

pure lynx
#

knightminer hasnt had time to start it. if he doesnt start by the time i finish the thing im working on ill start on a PR for this

elfin yacht
#

A set of "fluid volume types" is established, and the actual mB volume of those types is delegated to individual fluids

#

I'm oversimplifying a bit

#

but that's the short form™️

#

Does everything need a mB mapping for every type of thing thonk

astral stag
#

a 1x #c:gems/topaz -> <gem> x a:molten_topaz recipe is broken for b:topaz_gem as an input

elfin yacht
#

Do I need to be able to reference 1 ingot of liquid experience

pure lynx
#

no, you would use the logical unit of experience

#

which would probably be experience

drifting wraith
#

how do you get the logical unit

pure lynx
#

the same way you get a tool action, its just a string

drifting wraith
#

without knowing you're moving experience in particular around, I mean

elfin yacht
#

Well, okay, but how do you know if a fluid needs to support a unit type, and what happens if you request an invalid unit type for a fluid?

tawdry wolf
# drifting wraith I'm not sure I'm understanding how this is supposed to work

Fluid A can define that one gem is worth 250 mB of fluid A. Fluid B can define that one gem is worth 100 mB of fluid B.
Users are able to have a tank that stores 100 molten gems, regardless of how many mB that would actually be. Similarly, recipes can request one gem of molten fluid A (particularly relevant for two mods adding the same molten fluid, but with different mB amounts per ingot/gem/etc). And of course, display can also use this.

elfin yacht
#

how does the author of fluid experience know they need to supply what set of volumes

#

(and which ones they don't need to supply)

tawdry wolf
#

They don't need to supply any set of volumes.

astral stag
drifting wraith
#

then how do you write a recipe if you don't have a known volume of a particular fluid?

tawdry wolf
#

Just so we're clear.
Gem A converts into, say, 250 mB of molten gem A.
Gem B converts into 100 mB of molten gem B.
Both gem A and gem B are tagged as c:gems/something.
Is that what your example is?

astral stag
#

yes

pure lynx
astral stag
#

this is an item input in a melting recipe

pure lynx
#

yes, anything else isnt really relevant

tawdry wolf
# astral stag yes 
{
  "type": "example:my_melting",
  "input": {
    // item tag
    "tag": "c:gems/something"
  }
  "output": {
    "fluid": "example:my_fluid",
    "amount": { "gem": 1 }
  }
}
#

This is easily implementable by resolving the tag to an item before trying to query how much fluid one gem is for that ingredient

pure lynx
#

what happens when they're items is not relevant. because you could dupe with this in item form anyways. you craft 4 gems into 1 block, uncraft the block and get 9 of the other gem, now you have 9 when you started with 4. the system is flawed to begin with, the fluids would be flawed by extension

astral stag
tawdry wolf
#

except it can

astral stag
#

resolving the tag to an item before trying to query how much fluid one gem is for that ingredient
the proposal doesn't have any item <-> fluid amount link yet as far as I know

tawdry wolf
#

it breaks the system either way, so considering this case is irrelevant

astral stag
#

but it's the case that you use as an argument for why this system needs to exist in the first place...

tawdry wolf
#

if item recipes are broken, fluid recipes will be broken as well

#

but we would like to have non-broken and interchangeably-useable fluid recipes for non-broken and interchangeably-useable item recipes

pure lynx
#

wait wait wait, no, this system does not break even with this stuff. the system stays strong maintaining the ratios set by the fluid author, they cannot then be converted to cause a dupe

#

the dupe happens when they are in item form

#

thats another issue entirely

astral stag
#

the goal is to avoid dupes entirely

#

if you can't avoid dupes anyway then your system is goddamn useless

pure lynx
#

the dupe happens soley when they are in item form

tawdry wolf
elfin yacht
#

Avoiding dupes entirely ends up being a modpack author's burden though

tawdry wolf
#

if you want to avoid dupes, be my guest, but then this is the wrong discussion

astral stag
#

a resource system is either sound or not sound

#

there is no "oh but it's half correct trust me it's good"

#

if you don't handle the item case, your system is unsound

pure lynx
#

if you want to extend the scope of this to apply to items as well this would actually solve this issue as well kekw

drifting wraith
#

this part of the resource system is "sound", in that regard though

tawdry wolf
astral stag
#

then you're not solving anything

tawdry wolf
#

wrong

astral stag
tawdry wolf
#

we are solving the issue of 144 mB of Molten Iron (Gregtech) being not comparable to 90 mB of Molten Iron (Tinkers)

pure lynx
#

it was mostly a joke, this is overkill for items

tawdry wolf
#

that is the original intention of this entire discussion

drifting wraith
pure lynx
#

but the situation where itd dupe as an item is really a horrible example. This system does not seek to solve dupe issues created by conflicting recipes. Its trying to establish different materials adhering to a similar standard without rigidly defining what said standard is

drifting wraith
#

so the constants are the simpler solution for the same effect?

tawdry wolf
drifting wraith
#

the reason they used 144mB was because they should fit 9x into one bucket, to mirror block form. I don't know what reason they chose to change it

pure lynx
#

so tech, can you go over why this is an issue again?

#

i dont really understand it

elfin yacht
#

hm...

#

another thing to think about

#

fluid unification and/or things that attempt to translate fluid to fluid might be weird

#

I don't really know how those operate under the hood

#

so what "weird" means is arbitrary

echo lily
#

you mean like tinkers alloying?

pure lynx
#

afaik they just unify the resource, they shouldnt be touching the amount field

#

so they'll be fine

elfin yacht
#

No that would be even more problematic

#

see

#

If you just converted 1000mB of a:iron to b:iron with different ingot volumes

pure lynx
#

if the amount field is defined with the string map itll be fine

#

you can convert 1 ingot of iron a to 1 ingot of iron b

astral stag
pure lynx
#

that doesnt solve... anything?

#

i dont get the point there

drifting wraith
#

doesn't it? I don't understand what this is trying to solve then, with the variable units

astral stag
#

maybe you should bring up a list of problems before thinking too muhc of solutions 😛

tawdry wolf
pure lynx
#

its 1 instance of a million of fluids being inconsistent across the board, it doesnt solve the issue as a whole

tawdry wolf
#

as long as they are not (or there is not enough to convert one), then you don't convert

drifting wraith
#

the simple solution to inconsistency is standardisation, i.e. constants
so in what way is this variable system actually better than constants?

pure lynx
#

because there are too many edge cases, you would have to define dozens of constants to properly account for common modded and vanilla behavior. most of those being just small variations of the same things

#

it also just restricts devs to only being able to define their content in those specific set of rigid standards

elfin yacht
#

(that is not explicitly a bad thing)

pure lynx
#

i see it as a bad thing

drifting wraith
#

I don't really understand the point of defining things relative to nothing

tawdry wolf
pure lynx
#

wdym relative to nothing

tawdry wolf
#

which will be an issue here

drifting wraith
#

what point is there to allow a fluid to assign 5 different units of differeing size if the only one ever programmatically interacted with is ingot?

pure lynx
#

thats not the case tho?

drifting wraith
#

the units only have meaning when they're equivalent to something else, is what I mean

pure lynx
#

yes, a millibucket amount

#

this is not replacing millibuckets, its a system over it

drifting wraith
#

like, I can see no reason to not allow fluids to define their tooltips as saying "ingot" per 10mB or whatever, but as soon as we start using those units in recipes we're dredging up a whole lot of nasty

pure lynx
#

?

#

i think we have spoken at length about why its beneficial

elfin yacht
#

I mean I still don't really think different ingots should have different volumes

#

regardless of if you can make it work at a technical level

pure lynx
#

yeah but you believe that because you think "ingots" should be rigidly defined

#

i dont want to deal with 12 standards of ingots just to make my mod compatible with all things that are "ingots"

#

currently every thing that is not in the definition of a standard ingot is ignored, because the system is not flexible enough to allow devs who need to do things slightly differently to express their differences.

#

we can and should change that

astral stag
#

this is not really different from tag conflicts... you have to talk to the other modders and/or get a standard implemented in neo if that doesn't work out

pure lynx
#

except we cant get everthing to fit a standard, or if we do we have to establish multiples that we have to take into account

astral stag
#

my opinion is that we should pick a standard that covers 90% of the use cases

pure lynx
#

:/

#

a single standard does not exist to cover all use cases

astral stag
#

indeed; that's why we limit the scope to 90% 😄

pure lynx
#

you know what i meant

astral stag
#

I know exactly what you mean. And this is exactly the discussion I had 4 years ago on simulations vs transactions

#

simulations are the 90% solution

#

the reality is that the 10% will need to make adjustements in other places to fit the standard, or accept that they are left out of the standard entirely

pure lynx
#

except introducing fluid units is not nearly the same amount of burden as transactions, so lets just implement them..

#

this is really not as hard as you guys are making it out to be

#

its a datamap and a getter on the fluid

tawdry wolf
astral stag
#

there is a lot of additional complexity that is not immediately visible

pure lynx
#

that require you to completely rewrite how your storage is implemented. this does not require that same level of burden

#

and ultimately the edge cases that transactions cover are alot more niche than the cases that fluid units cover

tawdry wolf
pure lynx
#

and idk why you're making this argument anyways, if you could you would implement transactions because you know they're better

astral stag
tawdry wolf
#

Except that you will not be

#

And modders won't have to agree either

pure lynx
#

i mean, i guess but that wasnt a problem we were trying to solve

tawdry wolf
#

that is the entire point

echo lily
#

thonk aiui, fluids just define both, which can be anything

astral stag
tawdry wolf
#

That is already an issue with items, thus irrelevant to discuss in the context of fluids

astral stag
#

this proposed system doesn't solve many of the issues it claims to solve

#

you claim to solve it but you don't; it's still a problem

pure lynx
#

different materials being "ingots" and defining ingots differently. the same ingot of 2 different mods is a unification issue which is not relevant to this discussion

tawdry wolf
#

this is not an issue it claims to solve

pure lynx
#

this does not solve unification of the same material across different mods. it solves unification of the term "ingot" of different materials across all mods

drifting wraith
#

has it solved anything then?

astral stag
tawdry wolf
astral stag
#

where you can turn 1 obsidian into 2.25 obsidian

pure lynx
#

AAAAAA

tawdry wolf
#

but that, again, is not what this PR is trying to solve

pure lynx
astral stag
#

it doesn't unify "obsidian ingot", how can you claim that it unifies "ingot" lol

tawdry wolf
#

it does not unify ingot

#

it unifies the unit of ingot

pure lynx
#

^

tawdry wolf
#

these are not the same

pure lynx
#

thank you, much better wording

drifting wraith
#

I just do not understand how it solves anything, sorry, but I do not get it. It is however getting late, so I guess I'll try again tomorrow harold

tawdry wolf
#

just like in real life, you have miles and (nautic) miles. which are two different units, named the same, used in two different contexts

#

(yes I know bad because imperial system, but that's beside the point)

tawdry wolf
pure lynx
#

i think i might try and write up a gist about its use case in non display applications tonight, hopefully itll help a bit

#

@astral stag do you have something you can link me for how you currently consume liquids when you execute the consumption of one in a recipe?

fluid mortar
#

the only one who ever did that is tinkers' Construct for the record. Everyone else just does buckets. We are breaking something no one uses except me, who is willing to use this system

fluid mortar
fluid mortar
kind stratus
#

gunpowder's definitely not a liquid, but there's at least an argument that powders are fluids [tinkers currently has powdered snow as a fluid, apparently] and we're not mekanism

fluid mortar
kind stratus
#

hmm, that's another benefit of this system

#

a modpack that adds a mod that adds diamond nuggets (or "shards" or whatever) can change it to 90 without patching the mod

#

[re obsidian, for the record, given there are multiple mods that have 1/4 obsidian dusts, i'd be somewhat surprised at a mod that had 1/9 ingots]

kind stratus
fluid mortar
# pure lynx knightminer hasnt had time to start it. if he doesnt start by the time i finish ...

For the record, its partly I don't have time to start it, partly I want some consensus on whether we want a unit API or just a tooltip API. I'll probably toss together a design doc on a tooltip API to pin alongside the more complex unit API, see what people think about both alternatives. I do highly suspect its going to be the same complexity level for both though, so we might as well just do unit API

fluid mortar
fluid mortar
#

and that solves nothing

#

just changings who is on which standard, not the standard people use

#

Overall, I'm not against doing standard fluid values, I just don't see any point including those values in Neo. The upside is they are simple, but they are useless to the player without a unit display API

#

I do like the idea of letting mods define their own standard without losing compatibility, which would be trivial except in the purely hypothetical cases people keep bringing up (but what if you want half an ingot). The cases people actually use can easily just make capacities relative to a given standard

fluid mortar
#

I will note, this proposal is identical impact on the modders side, except they lose the option to define capacities and recipes in terms of the units defined for their tooltips. The other proposal those were optional capabilities

#

In both proposals, its just a datamap Neo adds which lets mods define lists of units for a fluid

#

data map with the unit API proposal:

# 
{
  "values": {
    "#tconstruct:fluid_units/metal": [
      { "name": "c:block",  "value": 810 },
      { "name": "c:ingot",  "value":  90 },
      { "name": "c:nugget", "value":  10 },
      { "name": "tconstruct:copper_can", "value": 90, "show_in_tooltips": false }
    ],
    "#tconstruct:fluid_units/gem": [
      { "name": "c:block",  "value": 900 },
      { "name": "c:gem",  "value":  100 },
      { "name": "tconstruct:copper_can", "value": 100, "show_in_tooltips": false }
    ]
  }
}
#

data map with the unit tooltip proposal:

{
  "values": {
    "#tconstruct:fluid_units/metal": [
      { "translation_key": "fluid_unit.tconstruct.block",  "value": 810 },
      { "translation_key": "fluid_unit.tconstruct.ingot",  "value":  90 },
      { "translation_key": "fluid_unit.tconstruct.nugget", "value":  10 }
    ],
    "#tconstruct:fluid_units/gem": [
      { "translation_key": "fluid_unit.tconstruct.block",  "value": 900 },
      { "translation_key": "fluid_unit.tconstruct.gem",  "value":  100 }
    ]
  }
}
crude heath
#

why a list and not a map

pure lynx
#

if its purely for display the units should be global. that said, i dont think its really worth doing purely global values

fluid mortar
fluid mortar
crude heath
#

as opposed to a list of pairs that is essentially a map?

fluid mortar
#

the string being a translation key will be super bulky

pure lynx
#

well if they are purely for display mods cant set their own standard. so they should be global. but like i said, i dont want this to be global

kind stratus
#

if it's purely for display we can have the map contain "gem", provide translations for common types in "fluid_unit.gem", and let mods add an extra dotted namespace if they want.

fluid mortar
# 
{
  "fluid_unit.tconstruct.block": 810,
  "fluid_unit.tconstruct.ingot": 90,
  "fluid_unit.tconstruct.nugget": 10,
}

plus we lose the readiblity that is a transltaion key

#

though the format is arbitrary, not worth bikeshedding over imo

kind stratus
#

[though at that point we might as well make it a resloc and use "c:gem" so that if we do add something else in the future it won't require changes]

fluid mortar
#

as long as it can b e defined

pure lynx
#

why is it a translation key and not just "block" or "c:block"

fluid mortar
fluid mortar
#

lets me use an existing key from elsewhere in my mod instead of defining something new

#

it could be a shorter string, sure. No objection either way

kind stratus
#

so

fluid mortar
#

just means neo forces a particular format on the key that is used in exactly 1 spot

pure lynx
#

but also it should probably just be a list of strings, the values arent needed here if they are defined globally

fluid mortar
#

yeah they are, I discussed this yesterdasy

#

who is registering these units?

pure lynx
#

you would

kind stratus
#

i am concerned that, in particular if this is a datamap rather than a special json loader that only runs on the client, mods may attempt to introspect it and use it for other api use cases anyway.

#

in which case now we just have a worse fluid unit api

fluid mortar
#

if I do it in code, then me registering ingot and you registering ingot with different values will cause a crash

#

so now I am forced to define tconstruct:ingot and codex:ingot

kind stratus
#

i mean

fluid mortar
#

and since they are now different, what is the point defining them in code? just define them in the one place they are used

kind stratus
#

they could be completely valueless, a system like tool actions

fluid mortar
#

but if they are valueless, we now have no way to dispaly them in tooltips

#

or we just have the other proposal

kind stratus
#

i.e. they only have a string and nothing else, from which the translation key is generated

pure lynx
#

i prefer the other proposal catnod

fluid mortar
#

these have no logical use in code

#

they are just a list of display name and unit values

#

they construct display in tooltips, nothing else

fluid mortar
#

I think most people will agree that unit display is important

kind stratus
#

i am not entirely convinced that being translation keys will actually stop mods from misusing them for other stuff

fluid mortar
#

and the fact that unit display is either the same effort or just a worse API might help argue towards unit API

fluid mortar
#

though that prevents you from constructing a tooltip serverside that is synced

kind stratus
#

and... maybe we should support that usage, and the simpler proposal should just be mods can bring their own logic to implement conventions that we define

fluid mortar
kind stratus
#

well

#

i mean no transfer api integration, no built-in recipe ingredient type, etc

fluid mortar
#

a lot of people here keep inferring the first proposal does more than it does

pure lynx
#

if its just for display, the units would have to be agreed on as constants. and if you want to do something different you'd have to use your own namespaced unit

fluid mortar
#

There is no transfer API integration (unless you define it), no built in ignredient (unless you define it), etc.

kind stratus
#

I thought the ingredient at least was part of the proposal

fluid mortar
fluid mortar
#

I mean, its a trivial impl

#

if they are logical, we might as well define the ingredient

#

but its not essential

pure lynx
#

it can be in json, but "ingot" could only ever mean 1 value is what im saying

fluid mortar
#

thats false

crude heath
#

why would display only require units to agree

fluid mortar
#

ingot only means 1 thing for molten metals in tinkers construct

#

though block means 20 different things

pure lynx
#

i agree with you, but im saying if its not used in any functional places you'd have to use a different name and establish a different standard for those 20 different things

fluid mortar
#

I have a couple of weird ingots on non-metals in tinkers

fluid mortar
kind stratus
#

so, in the context of the first proposal where they really are some kind of objects that are usable for api-shaped things, and they are "registered" in some way: where are they registered? a static registry, a dynamic registry, a special datapack loader, tool-action-style code?

fluid mortar
#

they all are just block, resuse the translation key

#

again, this is literally the only place using that number

#

there is not a benefit to abstracting it out just to type less in one JSON

fluid mortar
#

data maps are a neo thing

kind stratus
#

no, the datamap associates units with fluids, where are the units themselves defined? are they still just strings?

fluid mortar
#

just strings, or some internal object

#

Something like TagKey

kind stratus
#

by 'internal object' a tool-action-like thing then?

pure lynx
#

itd get confusing. like what does

"tcon:iron": { "block": 810 },
"tcon:diamond": { "block": 900 }

resolve to

fluid mortar
#

or ToolAction, based on whether we want namespacing

kind stratus
#

ok

fluid mortar
#

there is no guarantee that a specific translation key is always the same size

#

its not logical, purely dispaly

#

In the tooltip, iron might dispaly as 3 blocks, 2 ingots, 5 nuggets

#

diamond displays as 3 blocks, 4 gems

#

those are just the same word, "block", they don't need differentiation unless the mod wants to differentiate them

#

if you are going to make a tank use these, block is a poor choice of unit as its not consistent. Hopefully ingot is consistent in your own mod, but if not, thats not a new problem

pure lynx
#

idk, it might get confusing. If you define your tank as being able to hold 270 mb, aka 3 ingots, and you say the capacity is 3 ingots but then you insert a fluid who says they contain 3 ingots but each of their ingots is worth 180 and they dont all fit itll confuse players. So "ingot" would have to mean the same thing everywhere in order for that to make sense, hence why i do not like the display only approach

fluid mortar
#

tinkers has been doing it since 1.8

#

people can understand that a block of diamond is not a block of quartz is not a block of iron

#

and we have an item that holds 1 ingots worth of fluid, you just need to specify somewhere that means 90mb

pure lynx
#

yeah but they're all called a block, they might reasonably expect to be able to store 12 blocks of anything in there

fluid mortar
#

no

#

not unless you make a tank that says it holds 12 blocks

#

which I never do as block is such a volatile standard

#

its one of those "what if" hypotheticals that is never done

#

I could say "this tank holds 12 blocks of molten metal" if I wished, but I just always use the word "ingot" for simplicy

pure lynx
#

exactly, you wouldnt be able to define those things. so the new display system wouldnt work in all places. id really like to also use it in empty containers to signify capacity in more meaningful units than buckets, but if everyone still defines "ingots" differently without me being able to know how much they intend an ingot to be worth it wouldnt be possible

fluid mortar
#

thats nothing new

#

and thats a non-issue

#

and the other proposal does not really solve it either

#

if you wish to do an empty container that holds a logical unit without a fluid unit API, you just have to accept its a logical unit for a subset of fluids, its an arbitrary amount for the rest

#

If it matters so much to you, then in the fluids you define in your mod, never use block without an adjective

#

again, tinkers has been doing this for years, we define both a tank and an item that store ingots worth of fluid. We just also display the mb equivelent with that name

pure lynx
fluid mortar
#

eh, I suppose

crude heath
#

what if a liquid doesnt say how much a block is

fluid mortar
#

a lot of it comes down to what people want neo to do

fluid mortar
#

in the logical proposal, you don't store it in a blocks tank unless you define a fallback (e.g. 1 block = 1 bucket is reasonable)

pure lynx
#

if i show my container as storing blocks, i probably only want it to contain block based fluids

fluid mortar
#

in the tooltip proposal, a block is just an arbitrary unit you made up, it maps to mb

#

I really don't get why so many people who I assume are coders are asking "what if the unit is not defined" when thats just an if statement

# 
if (fluid.hasUnit(INGOT))
  return fluid.getUnit(INGOT) * 4;
else
  return 90 * 4
#

its my decision as a mod author if I define a tank as "holding ingots" how that interacts with either proposal

pure lynx
#

or return 0 and reject the liquid

fluid mortar
#

yep

pure lynx
#

display only doesnt allow this :(

fluid mortar
#

display only you just use a tag for that

# 
if (fluid.hasTag(FLUIDS_THAT_CAN_BE_EXPRESSED_AS_INGOTS)
  return 90 * 4;
else
  return 0;
#

you'd give it a better tag name of course, I like overly verbose in pseudocode

#

ideally the tag you use is more than just "supports ingots" e.g. "c:molten_metals"

#

something that has some meaning to the player

#

alternatively, you could just define a datamap for this

#

tconstruct:copper_can_size would be

{
  "values": {
     "#tconstruct:fluid_types/metal": 90,
     "#tconstruct:fluid_types/gem": 100
     "#tconstruct:fluid_types/slime": 250
  }
}
#

datamaps are pretty easy to define on an individual usecase like this

#

its what I'll end up doing if the fluid unit idea gets rejected

#

the downside to this approach is for a large variety of standard units such a thing will be a pain to query, but for a few specific usecases like pipe transfer rates or a special storage container size its not too bad

#

.
ultimately, I think the long term goal is ditching the idea that a fluid bucket must hold 1000mb, we want to be able to match it to a block volume instead of just dividing it into units cleanly. Before such a change is made, at minimum I'd want unit display to be a concept modders are using in Neo so its not such a break for players, unit display being a thing is how tinkers managed to get away with changing our fluid standard without confusing players.

Fluid unit API would be nice, but I don't view it as essential for the change in bucket divisions, just might be nice to have to solve a different conventions problem

kind stratus
#

i guess you know that because that's what a casting basin does

pure lynx
#

well the casting basin's capacity is probably recipe based on based on this

#

like, i assume it renders fullness based on how much of the found recipe its completing

fluid mortar
#

yeah, it reports 0 for the size if no recipe is active, but once you try filling it it reports the size as the fluid you try using to fill on simulate, or using the cached recipe on execute

#

its a very non-standard tank though. better to say its a fluid handler but not a tank

#

I am not sure how well other modders would accept a tank with fluid based size right now even if the API technically supports it

#

(thats something we can push for independant of this proposal)

pure lynx
#

rn its not super well supported. itll be something modders will easily be able to adapt to when the method to get the tank capacity of a slot has the fluid as part of the the method

#

thats part of #1183818213134446742 and a separate discussion altogether

fluid mortar
#

Yeah, with both the unit proposal and no unit proposal, its still something up to the transfer API to support

#

all the unit proposal does is standarize concepts such as "4 ingots" so you don't need to make your own data maps

#

though tbh, most of the cases I wanted units for are specifc to a single thing so I'd be fine with a datamap for that anyways

astral stag
#

Was it 144 in older versions?

elfin yacht
#

I think it might have been, but its been a while

pastel herald
#

144mb was the ingot value for older versions

kind stratus
#

i don't know what diamond was but emeralds were some batshit value like 333

#

666

#

public static final int VALUE_Gem = 666; // divisible by 3!

elfin yacht
kind stratus
#

took me a while to remember how to navigate the tinkers 1.12 source

#

(why did gems need to be divisible by 3 but not 9? why wasn't 144, which is divisible by 3, suitable? it is a mystery.)

#

probably to balance how many emeralds you got by melting villagers

grizzled tulip
#

I don't think anyone will ever agree on how much of a bucket you can fill with a molten block

#

it's a silly undertaking

#

it has been seen for years that people have incompatible opinions

#

allow me to propose what I think is the ultimate bad idea. maybe someone can take something good out of it:

  1. FluidStacks don't hold a numeric amount, they hold a NumberWithUnits(long, Unit).
  2. Unit is a datapack registry. -- yes that means there can be "mod1:ingot" and "mod2:ingot" as different units! by design!
  3. UnitConversion is a datapack registry.
  4. Neoforge provides stock units for things vanilla has conversions for, such as 1 bucket <-> 3 "thirds bottle"s, and 1 bucket <-> 4 "fourths bottle"s
  5. any conversion that can't be done as a whole number, is invalid and rejected (you can't convert 1 thirds_bottle into fourths_bottles, but you can convert 3 thirds_bottles into fourths_bottles)
  6. we actively choose not to care how people deal with "leftovers" and we intentionally stay away from trying to define bucket <-> molten block
#

why I think this is a bad idea:

  1. it doesn't solve the ultimate issues, which is that people disagree on how to handle leftovers, and how to handle bucket<->molten block
  2. it requires a graph structure and computing shortest paths across the graph (and Orion will shudder at the thought of implementing Aequivaleo-lite into neoforge)
  3. it puts additional load into modders
  4. it puts HUGE load into modpack developers
midnight vortex
#

I don't see how that's the case for 3 and 4

#

Neo providing units for most common units would satisfy the problem

#

And have everyone converge

#

There might be discussion on how many buckets an ingot is, but at that point, Neo being a centralized API would dictate it, like we do with RF

grizzled tulip
#

there's no meaningful way to define how 1 bucket and 1 molten block relate to each other

#

I mean we can say 1:1 I suppose

midnight vortex
#

#2 is also not needed, as we can simply require every unit to have a mapping to every other unit

grizzled tulip
#

that increases issue #4

elfin yacht
#

We don't need conversions between fluids

#

that's way out of scope

grizzled tulip
#

not fluid, units

elfin yacht
#

you don't really need that either

midnight vortex
grizzled tulip
#

like mod1:ingot <-> mod2:nugget

elfin yacht
#

you need to be able to write "I want 1 ingot of fluid"

midnight vortex
#

If they want to measure something in not Bucket, Block, Ingot, Droplet, Gem, Bottle

elfin yacht
#

and anyone can give you an ingot of fluid without thinking about the mB value

grizzled tulip
#

that only works if "ingot" is a predefined amount

elfin yacht
#

yes, the fluid defines that amount

midnight vortex
elfin yacht
#

it is a property of the fluid

midnight vortex
#

Centralized by Neo in this cas3

#

Not the fluid, but Neo

#

(Note my idea is based on your idea, Giga)

grizzled tulip
# elfin yacht it is a property of the fluid

that would mean some fluids would work in some circumstances but not others, without a clear way for the player to know why. imho that would be the worst case version of this idea

#

I believe it makes a lot more sense to keep units and fluids defined separately

elfin yacht
#

Well, no, there's a fallback value

#

if the fluid doesn't define a value, or doesn't interact, it is treated as the fallback quantity for the type

grizzled tulip
#

if there's fallbacks, that means you have to perform unit conversions

elfin yacht
#

no, you just consume the amount specified by the fallback

grizzled tulip
#

wat

#

so if my fluid doesn't define "nugget" it suddenly consumes a whole bucket's worth without warning?

elfin yacht
#

no...?

#

it consumes the default definition of a nugget

#

which is like 10mB

#

or whatever

grizzled tulip
#

err

#

notice that I said we wouldn't have a base granularity at all

#

there wouldn't be a mB int in my idea, it would always be tied to a unit

fluid mortar
grizzled tulip
#

this would impose that all units have a defined conversion to mB, which by this whole conversation, is the main point of contention

midnight vortex
#

Why would you have a base mB unit?

#

There is no reason for that to happen

#

mB is dumb and arbitrary

#

We don't need it

elfin yacht
#

Yes, but its still there, and does need to exist for now

#

you cannot randomly remove it, that will go nowhere

midnight vortex
elfin yacht
#

the whole conversation™️

#

Removing it outright is a far larger change than this and is going to trigger even more alarm bells

#

Fortunately, we can build a little abstraction around it

grizzled tulip
#

in my (clearly labeled as bad) idea, the convept of mB would be intentionally removed, so that no one can complain about granularity

midnight vortex
#

So the solution to trying to fix something is by not fixing the root problem because breaking changes

#

Even though Neo is all about breaking changes

grizzled tulip
#

it would be cleave out the problem by introducing a lot of other headaches instead :P

midnight vortex
#

Well, sounds like a great plan, really

elfin yacht
#

The solution is to build an abstraction away from it so we can reason about what things actually need doing

grizzled tulip
#

anyhow I have to get work done

#

so i'll close discord for a bit

midnight vortex
#

An abstraction that exacerbates the problem

elfin yacht
#

how did you arrive at that conclusion

#

If you wanted to remove mB surely you would be in favor of less things referencing it

midnight vortex
#

Except things are still referencing it under the hood

elfin yacht
#

so...?

#

They'll have to reference something

midnight vortex
#

Nothing

elfin yacht
#

you can't have a quantity of nothing thonk

midnight vortex
#

If the problem is that people cannot agree on how many mBs an ingot is, then this won't solve that at all, because the fluid itself decides how much it is

#

So every mod has a different standard and this makes the problem even worse

elfin yacht
#

The point is you don't have to agree

#

you just want <fluid ingot>

#

Given a thing that consumes a <fluid ingot> you don't need to think about the mB value

midnight vortex
#

With random amounts, completely fucked up conversion rates, and overall with the same underlying system

elfin yacht
#

Where did conversion rates come from thonk

#

If you had to convert something you would just make a recipe that takes <1 ingot> of <fluid tag> and produces <1 ingot> of <real fluid>

fluid mortar
#

Standards are about what mods do

#

If people have the ability to make fluids that display in nice units, it does not matter what standard they use

elfin yacht
#

Hey, I enjoy standards

midnight vortex
#

Neo is the standard

elfin yacht
#

I would happily impose "ingots are X fluid units" everywhere

midnight vortex
#

Otherwise what's the point of having it?

elfin yacht
#

I think I would get yelled at though

fluid mortar
#

No, neo is an abstraction layer

#

Mod compat layer if you prefer

#

It provides library's to make mods work together

midnight vortex
#

Evidently it isn't

fluid mortar
#

We don't need neo for standards

#

Some people are just afraid to define them outside of neo

midnight vortex
#

If it were just that, we wouldn't have standardized stuff

fluid mortar
#

See previous comment

#

We have been doing standards outside of neo since before the dawn of neo

midnight vortex
#

Such as?

fluid mortar
#

Been doing them since the early days of forge

#

Tag standards, oredict standards, fluid unit standards

midnight vortex
#

Fluid units are so non-standard it's insane

fluid mortar
#

We use the good old fashion trick of talking to each other other to make standards

#

Fluids are pretty dang standard, just a few weird expectations like Greg tech

#

What's non standard that you see?

midnight vortex
#

So if they're standard, all of this is useless

fluid mortar
#

No?

midnight vortex
#

Everyone agrees on how much 1 ingot is

#

We don't need this PR

#

That's what Standard means

fluid mortar
#

The point of this is not to fix a problem with mods disagreeing

#

The point of this is to add flexibility to mods that we are not allowed right now

#

And to add potential for future change to bucket volume for more flexibility

#

It's all outlined there in the proposal document

midnight vortex
#

Which is inaccessible because pins don't exist in here

fluid mortar
#

Yeah they do

midnight vortex
#

Not on mobile

old berry
#

they do, in settings, because discord...

fluid mortar
#

That sounds like discord is dumb, not a problem with the proposal

astral stag
elfin yacht
#

sir that's the pull requests search page

midnight vortex
#

Literally one of the first sentences is "TCon says ingots is 90 and another mod 100"

#

Very standard

#

Perfection

fluid mortar
#

Apparently pins on mobile require going to the forum directly and clicking pins

elfin yacht
#

we love mobile discord™️

#

Which is actually stupid, because I have the old mobile discord before their garbage UI changes, and I can access the pins of the thread from the sidebar

astral stag
#

My browser trolled me

fluid mortar
#

Just a java class with static constants does not solve anything as we have discussed

midnight vortex
#

It will

fluid mortar
#

Though you are free to pin it here if you think it's important

midnight vortex
#

Anyone knows how much an ingot is

#

That's the unit

fluid mortar
#

The problem is not modders knowing, modders already know

#

The problem is players knowing

#

The problem is a mod being able to communicate the standard they use to players in a way that won't break just by putting their fluid in another mods machine

midnight vortex
#

No

fluid mortar
#

Yes

midnight vortex
#

That sentence is already wrong

fluid mortar
#

Do you even use fluids in a mod?

midnight vortex
#

a mod being able to communicate the standard they use

#

No, a standard is not what the Mod uses

fluid mortar
#

Because I do, and that is a problem

midnight vortex
#

It's what everyone uses

fluid mortar
#

Yeah, a standard is what a mod uses

elfin yacht
midnight vortex
#

Not what a specific mod uses

elfin yacht
#

Part of what i prefer about the proposed is that you can just have type names for quantities in data

fluid mortar
#

There are multiple standards, and there might be a most popular standard

#

Standard does not mean only one, you should know this as a coder

midnight vortex
#

Sure

#

Which in turn means, if there are multiple all of this is bollocks

fluid mortar
#

Ultimately though, none of this matters to players

#

All players need to know is howany useful increments of fluids they have

#

It literally does not matter if a useful increments is 90mb or 14b as long as they don't have to be shown the useless unit of mb

#

So this proposal is about unit display in tooltips

#

And unit display in tooltips could be trivially adapted to removing the need for all mods to follow the same standard, which gives modders more freedom

#

Apparently modder freedom is not supposed to be the goal of Neo though, neo is supposed to force all the mods in line

astral stag
midnight vortex
#

No more mBs

astral stag
#

There is no need to build an abstraction around it

#

Just change it and be done with it

midnight vortex
#

We don't need to break stuff twice

#

Just one big break

#

And have everyone adapt it

fluid mortar
#

The proposal is 0 breaking changes

#

It's written as a fully optional API

#

When you use it, it means the break later won't be as bad, 1 file to change

#

Or you don't use it and have to deal with more work

#

Either way though, as outlined in the proposal, changing the bucket volume without unit display is a horrible idea, any fabric dev can tell you that

#

No one displays droplets as droplets. You need a human parsable method of display

#

That is what this proposal is about, human parsable display

midnight vortex
#

Buckets would be buckets as units, not droplets

fluid mortar
#

Oh, you are taking about the make every fluid pipe mod more difficult approach

#

As opposed to the make the magic number bigger approach

#

I have nothing against that approach, but good luck getting modders on board

elfin yacht
#

I'm very much in favor of doing the abstraction instead of trying to blow everything up all at once

fluid mortar
#

Such an approach would need a unit API anyways, might as well make such an API map to mb for now

elfin yacht
#

One of the things I hate about how we do stuff here is the inability to do gradual change

fluid mortar
#

The proposal outlines three potential paths from a unit API, such an API could lead to any of the three and need not even be decided now

#

Or if you think no unit API is needed at all, consider the fluid tooltip proposal below it

#

The horrible path is just changing the bucket volume and telling modders and players to figure it out

astral stag
midnight vortex
#

Then again, note I am no Neo maintainer; so my opinion here is as relevant as any other one

astral stag
#

I don't want my deps to break a little every update

elfin yacht
#

Well we also have a build-on-commit paragidm

#

So large changes are a pita

#

rather, release-on-commit

#

not build, build is fine

astral stag
#

You just squash them 🤷

fluid mortar
#

Again, the proposal is not a breaking change until you make it one

astral stag
#

It doesn't change the user facing model, only the neoforge developer side

fluid mortar
#

You introduce it as optional, make it mandatory later if desired.

#

Give people plenty of time to start using it before deciding on how to fix bucket divisions sucking

elfin yacht
#

At some point, once we get this abstraction, we can abstract the bucket to the fluid as well

#

and then a bucket can just be whatever the fluid wants it to be™️

fluid mortar
#

You could do that, definitely an option

#

That is easier for recipes, harder for transfer APIs and storage

elfin yacht
#

Well it isn't that difficult for them

#

they just have to do that conversion from bucket to <magic internal number> when doing i/o to a bucket

#

and to in-world, I guess

pure lynx
#

If bucket is dynamic what’s the anchor?

#

I guess there wouldn’t have to be an anchor

#

having bucket be a fluid unit would be nice, but might be controversial. It would be the logical conclusion of the idea

drifting wraith
#

So I've slept on this, and while I approve of the display side of this, the whole "what is an ingots worth of fluid" stuff for the logical side seems backwards.
Whether an ingot requires 100mB or 144mB (or whatever arbitrary value we decide on in the background) should just be left to the recipes.
The concept of a tank that stores "4 ingots of fluid" is silly, fluids aren't the same density as solids IRL. The tank should hold a static volume of fluid, and how much that is in ingots should, in my opinion, be completely divorced from the storage parts.
Perhaps it would make more sense if these units were loaded from recipes? So that an ingot worth of fluid in the tooltip is always an ingot worth in reality.
A bucket of fluid is a measure of the volume of the bucket, if one bucket of fluid is enough to form into one block should be entirely up to the fluid. But how much fluid fits inside a bucket shouldn't be per fluid, IMO.

pure lynx
# drifting wraith So I've slept on this, and while I approve of the display side of this, the whol...

Using IRL is not great here because we do, in fact, use different units for different contexts when measuring different things. And the reason we don’t measure in ingots IRL is because an ingot can be of any size in the real world, something that is obviously not true in Minecraft.

Since this system is data driven, it basically is a recipe. It just allows devs to set their own ratios between the bucket constant and the logical units you’d use the fluid with. The reason it shouldn’t be a recipe is because this concept would get used so much outside the context of a consuming a recipes. Every mod would also need to define its own recipe system to be able to define these conversions, which would not allow for cross mod compatibility if I needed to understand what x mod fluid sets an ingot as because I’d need to either expliclty hook into x mods recipe or have x mod define their thing with my recipe. Fluid units is more compatible

drifting wraith
pure lynx
#

Right, which is what the current proposal does, keeps bucket as a constant

#

Essentially the whole thing is setting ratios between logical units, buckets, and millibucket.

Everyone is expected right now to set bucket to 1000 and all other values in the ratio must be positive integers. If a bucket was allowed to be set to anything it’d still always hold a buckets worth of liquid, the other logical units just wouldn’t have to be relative to 1000

#

So instead of 10:90:810:1000 it’d be 1:9:81:81. It doesn’t necessarily represent the bucket in any particular unit, it’s just a ratio. In this sense we would end up changing how we interact with liquids in Minecraft to just be alot more like how we interact with items, and a bucket would represent the “max stack size” so to speak, and containers would hold multiple “stacks” of liquid.

But again, this would be if we allowed bucket to also be dynamic, which this system does not currently propose

tawdry wolf
#

I think we should clarify what we do not want this PR to do

#

we do NOT want to remove the mB unit.
we do NOT want to introduce breaking changes if we can avoid it.
we do NOT want to force modders into standardizing what an ingot or a gem is, because it just doesn't work.

#

and we do NOT want to check for duplication loopholes (as Tech suggested), because that is way out of scope and has nothing to do with the system at hand

deep hamlet
#

I don't think I would make use of this proposal, on the basis that I want to show mB amounts, not ingots/nuggets, to the user. And in that case, I don't see the benefit of using this API for the extra indirection, unless there is some compatibility advantage to doing so that I am missing.

pure lynx
#

this system doesnt introduce any breaking changes, if you choose not to use it and you want to make say, a container that hold 10 ingots worth of liquid, your mod will be just as incompatible as it was before the system was introduced

fair egret
#

what's your usecase? do you use fluids as fuel for machines?

deep hamlet
#

I have 100mB ingots and 10/15/25/35 mB ores, and alloys that work with percentages

pure lynx
#

oh you develop terra firma craft. im reading the wiki for how your metal working stuff works, you'd definitely be able to make good use of it

#

if you dont want to thats fine, but its not true that it wouldnt benefit you

kind stratus
#

still not sure why that means displaying mb specifically, it seems like your real unit is one hundredth of an ingot.

#

"1 ingot, 47 mb" or "1.47 ingots" could be a useful display there

deep hamlet
#

yeah, which in our case is exactly = to a mB, so again I'm not sure what benefit this API provides except for indirection

#

I think both of those are worse than "147 units", especially when you have to add those together and ensure that it is between 8-12% of your target amount

pure lynx
#

ngl, 147 units doesnt mean anything to me

#

im not sure how thats better in any way

kind stratus
#

i mean ultimately, when it's just multiplying or dividing by 100 it's easy enough for users to convert between mb and ingots in their head but that doesn't mean displaying it as ingots isn't friendlier

#

i haven't played tfc in ages and i didn't get very far in it so i don't know much about how your metal system works

#

but it looks like you have a couple of screens that actually calculate the percentages

#

like how would it be substantively different if these said "48.8 ingots" and "5.6 ingots"

UjzHuld.png
pure lynx
#

it really seems like terrafirmacraft is designed to be its own, complete independent universe of how things work. especially considering your metals already dont follow the standard ingot amount. But if you wanted to you could assign these values to your liquids so other mods understand how many millibuckets of fluid TFC assigns to an ingot.

kind stratus
#

i'm not sure i understand why a "unit" is better 1 mb rather than 100 mb with two decimal places anyway - just because other things use mb so this way people can understand it in other mods' tanks?

#

1.47 and 147 provide exactly the same information

#

and if a bucket ends up being 81000 units, is it better to display 1.4789 or 11979? i suppose you could display 147.89 but i don't really see the attachment to 1/100 of an ingot as a size unit when you're displaying the actual percentages in a quantity-independent way

deep hamlet
#

and if a bucket ends up being 81000 units
I don't care at all what the size of a bucket is - just an ingot. If an ingot is any multiple of 100, I could see a point in using this display API wherein a "unit" is whatever I need to make an ingot "100 units"

#

it really seems like terrafirmacraft is designed to be its own, complete independent universe of how things work.
mhm, true (but also there is no standard - there's a TFC pack using ingot=144 rn because of gregtech, and TFC is customizable enough to make that possible).

pure lynx
#

there is a standard, 90 mb is the current "standard" for mods that arent gregtech

kind stratus
#

i mean let's be real there aren't all that many molten metal mods

#

there's tinkers and embers, and gregtech which doesn't use the standard and tfc which doesn't use the standard

#

there was some other mod in the 1.12 days which i think used 108 mb instead of 144

low hinge
#

can we take a moment and appreciate how this discussion already almost has 3k messages

kind stratus
#

*waves at @elfin yacht *

elfin yacht
#

scrim

low hinge
elfin yacht
#

whimch

low hinge
kind stratus
fluid mortar
#

Yeah, I don't think a mod that does not intend to make their fluids have compat cares about a compat API

#

If TFC wished they could use the proposed API to support their iron in machines from other mods despite using a 100mb standard

#

But they might encouter trouble trying to go the other way, 90mb ingots in their logic

solemn sand
#

Or I mean, heck, they can just check whether the size of the ingot of the fluid they might support is divisible by 100

pure lynx
#

Yknow, i think most of the concerns with the fluid unit system are non issues.

Major concern right now is that this system would introduce discord among fluid standards when we should just be using constants. But ultimately i think the PR introducing this system and tech's PR for constants can actually both be merged and it would be fine.

The constants would just set the established standards in stone, and people who put their tag in the molten metal tag or some other "standard" tag could still be required to follow it. This would essentially just be how the system is right now. You apply the standard to the things that follow the standard and everything else is ignored. This system does not try to say anything in those tags can have any value, so you are unaffected. If you are content with only being compatble with the liquids in that tag, you need not change anything

But if you want to be more compatible with other "ingots" then you need only make a few changes to be able to do so. You'd use units instead of the constant. This is, overall, less work than what someone would need to do to be compatible with more than one standard anyways. If someone wanted to do this without the fluid unit system they'd need to figure out what the other standards are and special case them in their mod. This system will just handle all of that for you, so in that sense it makes things easier. Your mod now becomes compatible with all standards, not just the 1 standard.

The old tag would still exist, and if you really want we can even make constants for the standards. This system just makes it friendly for other authors who want to establish something abnormal without being completely left out in the cold. As of right now, they would be left out in the cold because its too much effort to account for them. If after its established people still think its too much effort, they can continue to leave those devs out in the cold, nothing prevents them from doing so.

@rugged barn @astral stag ^

deep hamlet
#

As another example, I could potentially convert from one instance of molten iron to another by scaling based on the ratio in INGOT unit values for each.
Hypothetical then: user melts a 15 unit ore (TFC) and wants to pipe it into a tinkers' machine using 90mb=ingot. How does this transfer the 13.5 mB it should. Is this just the limitations of what this compatibility would achieve?

#

If I'm using the display API, user sees "0.15 Ingot" in the TFC machine, and they should see "0.15 Ingot" in the tinkers machine, but from their PoV, it just doesn't work, sometimes, seemingly without reason (either lossy, discrete, or other restricted transfers have to be in place here, unless I'm missing how this would work)

elfin yacht
#

You would need to have a "smallest" unit that doesn't involve fractions against mB values

#

But I think you've misinterpreted slightly how it works

#

tcon will not attempt to treat your fluid at 90mB/ingot

#

tcon will query your fluid for what your fluid declares is an "ingot" in mB

#

and use that when tcon wants to consume 1 ingot's worth

#

So you can use whatever scale is appropriate for your fluid (which I guess is 100/ingot?), while tcon's fluid uses 90mb/ingot

All the while, recipes are just written against the fluid-defined "ingot" value instead of a specific mB amount

pure lynx
deep hamlet
#

I still don't think I quite see the benefits this would bring for compatibility between mods a priori using different standards - trying to reconcile with code I know. And switching standards is dependent on a lcm() argument over anything else, which is going nowhere. So I guess I'll just wait and see if/when this API gets real use.

elfin yacht
#

It means mods don't need to reference static mB values for compat, or even need to agree on the same values

pure lynx
#

Yeah that’s fine. I think the important part is that it wouldn’t require you to change any code if you didn’t want to try to be compatible with other standards

kind stratus
#

the main effect on compatibility would be that if tfc declares an ingot is 100 mb, then tinkers could - at least for the metals that have recipes built into tinkers construct - use 100 mb to cast that ingot and 900 to cast a block, since it has a way of knowing that this fluid is 100 mb per ingot

#

and could use e.g. 300 mb of tfc copper and 90 mb of some other mod's tin to make bronze

#

tfc could, if it so chooses, do the same for its alloys - treat the 90 mb of tinkers construct tin or 144 mb of gregtech tin as being the same as 100 mb of one of its own fluids and calculate the ratio in the alloy as 75% 25% [which is to my understanding not enough copper for tfc bronze, but pretend i calculated a ratio that would work]

pure lynx
#

yeah, basically the fluid unit system operates under the assumption that you rarely ever actually want to use the raw millibucket amounts for things. Usually you're combining 2 logical amounts of something in order to turn it into another logical amount of something, eg for bronx you're turning 2 copper ingots and 1 tin ingot into 3 bronze, so instead of specifying the specific amounts you specify "2 ingots" and the fluid tells you how much liquid that should be.

#

but if you do need to use the base mb, those are still there

#

nothing stops you from just using that

#

in fact there are alot of situations where that might make sense, like if you want to do very small conversions. like, converting 3 mb of water into 2 mb of hydrogen and 1 mb of oxygen

solemn sand
# pure lynx Yknow, i think most of the concerns with the fluid unit system are non issues. ...

The issue is that tech's PR is fundamentally a step backwards. Like, I shouldn't have to have a block be less/more/whatever-the-fuck-it-is-now than a bucket for my fluid to be a molten metal! I should be able to have a molten metal -- in the molten metal tag -- with a block as one bucket, and the unit system would let me do that but let things expecting certain properties for "molten metal" to still respect that

pure lynx
#

because now youd have to use the fluid unit system to understand whats what

solemn sand
#

Sort of a two part change

pure lynx
#

sounds nice in theory, but in practice getting people to agree to that would be a nightmare

#

lets just try getting this through, its still a massive step forward

#

even while not breaking anything

solemn sand
solemn sand
pure lynx
#

yes, but that would fundamentally require everyone use the fluid unit system

#

which is not currently a requirement in the proposal

solemn sand
#

My point is just let's not push through something else that makes an end goal of not forcing everything into these arbitrary standards harder

#

Which is what tech's PR does -- it bakes in the annoying, inconsistently-followed, and generally hard-to-make-sensible standards that we're working with, and makes any down-the-road change to peple having to use the unit system to reason about ingots, etc much harder

solemn sand
#

But regardless, as you've said, that's much further down the road, and shouldn't really effect the proposal too much

pure lynx
#

yeah, techs PR after the introduction of the fluid unit system wouldnt so much be "the" standard, but rather the default standard

#

its what everyone who doesnt use the fluid system will use, and that, to a certain extent, is needed for backwards compatibility

solemn sand
solemn sand
#

The fluid unit system would be a way of saying "my fluid makes sense to measure in ingots and here's what I mean by one"

pure lynx
#

i mean, it should still be supported that "any metal in the very specific x tag should function like this". you and I, users of the fluid unit system, dont have to care about the tag stuff cuz you and I will be using fluid units to tell what supports an ingot, not the tag

solemn sand
#

If you have a "default standard", people are going to start expecting other people use it

solemn sand
#

The number of ingots per bucket is determined by the fluid unit system, not the tag

pure lynx
#

well what purpose does the molten metal tag serve

#

we'd have to define that

solemn sand
#

It tells me that it's a metal, and its molten

#

And it also tells me -- I would argue -- that I should have defined certain units on it, namely probably ingots and blocks

pure lynx
#

then yeah i think i agree. maybe we should have a c:standard_metal tag for molten fluids that support the 10:90:810 stndard

solemn sand
#

Those fluids shouldn't get special treatment

#

Like: what would you conceivably do with such fluids, that you couldn't do with other molten metals if you used the fluid unit system correctly?

pure lynx
#

we gotta have something, we cant fundamentally get rid of the old standard, there still has to be a way to do this in a rudimentary way without the fluid unit system, otherwise this is a breaking change and the proposal is a million times harder to get through review

solemn sand
#

Also there is no standard that's followed now

#

So its not a breaking change in that regard either

#

The only "standard" that's consistently followed is 1000 units per bucket

pure lynx
#

thats not necessarily true, i think people current expect things in the molten metal tag to behave as 90 mb. but idk, thats not a neo established standard so its quite fluid (badum tsch)

solemn sand
pure lynx
#

hmm

solemn sand
#

Tech's PR bakes in a standard that obviously doesn't work. The fluid unit proposal provides a new system that currently is just a nice tool to work with and let people talk about those currently-non-standardized things sensibly, but in the future could be used to remove the standardization on even the number of units per bucket if necessary

#

At the end of the day they're just two different ways of asking "how much fluid goes into an ingot"

#

And the PR that adds a bunch of constants -- that is an approach that we've seen, with a lot of different examples, isn't actually what mods need

#

The point is that once a fluid unit system, like the proposed on in the pins, exists -- mods shouldn't make assumptions about default-mB-per-ingot or whatever. They should just query the fluid unit system

#

Currently they have to make assumptions because there's no standard. This lets them not make any assumptions, without introducing a restrictive standard

pure lynx
#

its a standard that does work, but not for every use case. our PR works for almost every usecase. the only thing our PR does not work with is that it currently registers them in data, so it doesnt account for fluidstack specific units like tool actions do. so if a unit was dynamic based on its data components it wouldnt be supported. BUT it wouldnt be supported in the old system because of tags so im okay with this

#

i say our PR like it exists lol

solemn sand
#

Or even what that'd look like

pure lynx
#

idk, you could have a data driven fluid that behaves differently based on a datapack entry

#

@vernal bane do you have data driven liquids in productive bees?

#

resourceful bees doesnt have this issue because it just registers new things at start time, but i think productive bees is more datapack based

#

so their fluids would realistically need to be different units based on the type of bee the liquid came from

solemn sand
#

But the other lovely thing is that the proposal as-is could always have that feature added later without changing how the unit API looks to anyone using it normally, even for querying fluids

#

Its a system that adds flexibility and lets people not make assumptions, making extending it down the road easier

fluid mortar
#

Something adjacent to the idea of fluid units that might be worth handling is defining a better standard for fluid tags

#

right now, people just use root tags like molten_iron

#

Its possibly a better idea to use tags that specify the standard in some way, perhaps metals/iron gives you the 90mb ingot standard, and we encourage a different tag folder for the 100mb standard and the 144 standard, should they wish to tag

#

if the fluid unit proposal gets accepted, it would be good to distinguish the legacy "we use the 90mb standard" tag from the new "we use the fluid unit API" tag

#

worth figuring out before mods with molten metals start porting to 1.21

fluid mortar
#

Some broader questions to ponder: do we want a root tag for all fluids under the 90mb ingot standard? E.g. c:metals

Do we want a tag for all molten iron regardless of unit standard? Something terrafirmacraft and gregtech can use if they wish with no assumed size

#

@deep hamlet is worth asking on that note, do you have any use for identifying a fluid is a molten metal in TFC via tags even if it's not using 100mb ingots? Or is that something that won't benefit you?

astral stag