Fluid Integration

[shartte]

Probably self explanatory.

There's also One probe, but I am not 100% certain on how that works.

[DeadSix27]

Offtopic, but thinking about ExtraCells2 atm, should I,you,we get in contact with the author? I always felt like that mod deserves to be standard in AE2. I would update it but despite knowing java I have no idea how Forge mods work :), however if he still actively develops it, getting in contact might be a good idea.

If needed ill move this to a own "thread" just need others opinion before I open that.

[shartte]

I also thought about making something like extra cells standard. But our first and foremost priority should be to get AE2 back into business for 1.10.

Anything beyond that might be AE3 territority.

I am right now looking at the source code for some AE2 addons to figure out how they made use of the API.

[DeadSix27]

Agreed, just wanted to get this mentioned since WAILA and JEI did get mentioned as well

[Elix-x]

After we finish porting existing features.

[Elix-x]

Concerning extra cells, they will be in AE3.

[DeadSix27]

Including the fluid/gas storage & different I/O for that, elix-x?

[Elix-x]

Yep.

[Elix-x]

Thaumcraft might be too.

[shartte]

You are spamming my issues :[ (And Thaumcraft doesn't exist yet for 1.10)

[Elix-x]

I know, but it will be there (maybe even before AE3).

You are spamming my issues :[

_Muhahaha :smilingimp:

[DeadSix27]

(And Thaumcraft doesn't exist yet for 1.10)

Unfortunately it doesn't ye, but that doesn't mean it won't ever (hopefully), anyway I'm here for help, if there is anything feel free to command me around :P However I might be more of a burdun considering the only Minecraft-java related thing I ever worked a lot on is Bukkit plugins.

[yueh]

Neither fluid, gas or anything other fits into AE2.

The current fluid support is also really clunky and inflexible. It should really be removed and replaced with a more generic approach. Every addon can already register new services to the grid and that is how the fluid integration should be handled. There should only be a way to register custom cells and let them join the correct services (not forced to the item storage).

And there is absolutely no need to have fluid support, I have not encountered any fluid based crafting, which could very easily integrated into the normal autocrafting. It might need pondering a bit about it, but that is also one of the main goals for AE. If a player is not able, let them pick an easymode mod or just play in creative. But do not scare the current users away who like a bit of complexity and hope they might be replaced with another uncertain userbase.

Thaumcraft stuff or mekanism gas was actually designed in a way to explicitly not work with other mods. So they do not want to be part of a larger ecosystem and that is a decision someone should respect. It is fine when there are addons for it, but they should at least be a choice not the default.

Just look at EnderIO or any other mod starting to include support for every specialised stuff out there. They now have huge problem maintaining it and reject pretty much any additional feature.

Also why even have a very extensible API and be open to addons, if you do not want them? Keep it simple, handle the common minecraft cases (items and crafting), leave everything else to addons. There is really no need to kill every addon.

Further official support for fluids or anything else means the need to be fully supported. The autocrafting is already stupidly complex due to every edge case it needs to handle. Fluid crafting would not be just one thing more, but it is essentially a huge mess of edge cases. There is absolutely no common way of handling it anywhere. Gas, thaumcraft or whatever else is even worse.

Where to you even want to draw the line? Why not support Equivalent Exchange or any of its clones? But that means you just have a block to dump cobble into and extract every existing item without crafting. It is virtually a "click to open creative mode".

If you want to put an already complex system into an unmaintainable state, go for it.

[shartte]

My god this issue has derailed quickly. Fluids is about the only thing that an AE3 could handle itself. Everything else is addon territory since it also requires other mods and definitely changes gameplay more than fluid storage would. There are also things that are severly more important, i.e. better ingame documentation. There are fluid P2P tunnels, but in my entire time playing with AE2, I've never used them once. Exposing stuff like that to more players to encourage cooler builds should probably come before implementing stuff like an integrated Extra Cells (which yes, was always a bit clunky).

I changed the name of this issue since we're not talking about Waila AT ALL

[Elix-x]

Well, we can handle fluids without fluid crafting. We can handle item crafting, because the way it works is told by MC and forge. There is fluid handling (transfer-storage) standart by forge, so we can do that. But because there's no fluid crafting standart, we should not touch it.

And yes i agree, what's about mod compatibility (in this way) should be better done with addons (aka "More AE3 crafting storage things addon for essentia, pressure, magic, ee, whatever").

[shartte]

One thing for fluid crafting i could see is provide a Fluid Transposer Like placable object that can fill user-provided fluid containers with fluid from the network. Any crafting would still be based on the filled containers then.

[DeadSix27]

That's what I meant, storage. Current EC2 doesn't have crafting either and that is what I was on about. Just the plain transfer and storage. (Export/Import bus etc for fluids) Everything else is stuff to think about in the future anyway.

[Elix-x]

There are plenty of "fluid transposers" by other mods already.

Also, just want to make sure, we are talking here of not implementing fluid crafting and not fluid processing.

[yueh]

There is no standard in forge really besides fluid transport.

But fluid crafting can mean so many things.

• (Vanilla) Replace the need of a bucket with 1000 mB of stored fluid
• (Modded) Replace the need of any fluid container with any arbitrary amount of fluid not related to the max capacity of the item (ex tank with 16 B, each crafting steps reduces it by 250 mB).
• Conjure a fluid container out of thin air to act as replacement for an crafting table/assember. Try to stop duping.
• Dump fluid into machine
• Place fluid into the world
• Whateverelse another mod dev imagines to stop people from autocrafting.

While every item crafting is either

• Handled by a crafting table (crafting pattern)
• Dump into machine (processing pattern)

We could add basic fluid storage and buses. But that would feel really lackluster. Also if it was added, why add new buses for it? On a lore point of view, AE stores matter as energy and converts it. There is no reason why it should handle solid and fluids in a different way. So it could just work with adding a fluid or (not xor) item card to buses to choose what they support. But why does a crafting card then work for items, but not fluids? It would be pretty inconsistent.

Fluid transposer would be a necessity with fluid support, regardless of other mods provinding it or not. Some packs might not have one and we need at least to provide a way to let players fill their bucket with something to manually craft when needed. How would you otherwise obtain a bucket of X to create a pattern with bucket => bucket of X?

Also how would you add a fluid to an config of a bus? You need it item or at least some sort of container and handle it like

• First click with bucket of X => place bucket of X there to handle the actual item
• Second click with bucket of X =>replace item with fluid
• Further clicks, toggle back and forth.

So this also need some way to fill containers with fluid => transposer required.

Then how to handle exporting exact amounts? (That is what processing patterns actually do) Now the UI needs to behave differently. It is not just a boolean switching between item or fluid, but it also needs to handle defining how much fluid. With items your are more or less limited to 64 items per stack and you can easily create a stack with N items. But that is not possible with fluids. So you need something like

• Left click to increase by 1mB
• Right click to reduce by 1 mB
• Shift click by 25 mB
• Ctrl click by 250 mB
• Alt by 1B
• Shift + Ctrl double or half the current
• Shift + Alt + Ctrl + Click = toggle between fluid and item version

Fluid is really a very difficult topic to handle correctly. Minecraft itself put pretty strict rules regard items and recipes on every mod and most mods follow them. But fluid is really some home-grown system and everyone uses it differently. Or even worse decide that the do not want players to use pipes from other mods because the might be 1 copper cheaper and thus enforce their own system onto the player (gas, essentia & co)

[Elix-x]

So, here's what we can do to handle fluids without hassle and lacking features:

1. Transfer & store fluid in the same way as items.
2. Add a fluid transposer to transpose fluids into containers and back (implemented in similar way to molecular assembler).
3. We do not support crafting with fluids directly, but fluids can be transposed into item.
4. A bit different UI & pattern for processing:
   1. It's a list/table, not a grid (because arbitrary processing has no grid).
   2. Input lines in the beggining, output lines in the end.
      1. 1st column - category (item/flui/API?) - switch.
      2. 2d column - type (apple/lava/...) - slot.
      3. 3rd column - amount/count (35/50mb/...) - numerical input field.
      4. 4th column - options (use nbt/meta/oredict/fluidict/...) - check boxes.
   3. So something like this (github does not support row span :():

Type	Category	Amount	Options
INPUT	INPUT	INPUT	INPUT
Item	Apple	35	[x] Use meta [] Use nbt [x] Use oredict
Fluid	Lava	4536mb	[x] Use fluidict
+Add input
OUTPUT	OUTPUT	OUTPUT	OUTPUT
Item	Burned Apple	0
+Add output

1. Does not change much in current processing code structure.
2. If too "OP" can be added as "Advanced Pattern".
3. Addons can hook into with API and add new categories (eg: essentia).

[yueh]

2 & 3 are basically what we have on the backlog should we ever add fluid directly. But there are still issue with it. Currently the crafting system either needs an item to be actually existing, being craftable with existing items or have an infinite amout available over time (think cobble gen). With fluids these are just virtual items, if you just define 1 Bucket => 1 Bucket of X, it cannot predict, if there is enough X available to craft all buckets. So either the crafting will block after it was started without giving more than stuck on crafting buckets as info. Or the transposer has to act more as storage for buckets. Place 16 buckets into it and 16 B worth of fluid and it can announce 16 Buckets of X are stored.

1 was how AE1 handled it and it is not really ideal. Especially towards the storage amount. 1 Bucket = 1000 items, so cells will store less fluids by 3 magnitudes. And not there is no need for larger cells, over 500k items per cell are way more than enough for most cases. Hoarders can still use DSUs or similar.

4 is clearly a no go. The reason it is a grid is to keep it simple and do not add some stupid powercreep. 9 items per recipe is more than enough. If mods actually want to prevent easy autocrafting they just have to use 10 different items for a recipe. If that is no longer the case expect some stupid things like IE which will require hundreds of items per crafting step. And with some creativity you can even chain multiple patterns together.

Also it is really inconvenient for a player. They have to choose the type from a dropdown, drag&drop the item, switch to the keyboard to type in the amount, deal with some strange checkbox vs drag&drop 8 cobble + 1 coal into the input and 8 stone into the output, done. No chance to mess it up. Being able to ignore metadata? Expect them to do it everytime and then complain why it just smelted their high tier machine into slag, because it uses the same item id as this mods cobble variant, which is also oredict as cobble and dead locks the crafting process because the furnace spit out slag and not stone as defined.

Allowing a player to ignore meta/nbt part is bullshit. Exposing internal data and let the player deal with it is just lazy and poor UX/game design. If a mod author wants that their items can be replaced there is the oredict and it can be handled completely transparent. The user will just have to choose use exactly this item OR something similar. No need to have the player deal with wtf is meta? and wtf is NBT?. Most cannot even differentiate between meta and damage. Also ignoring it can actually lead to dupes and what not. Because you suddenly craft high level ingots from cooper nuggets because the just share the same id as the high level nuggets.

Something like a "Advanced Pattern" and making it more expensive is not really ideal in a game with infinite resources. There is no real point between requiring 1 or 256 iron ingots from an infinite stack. It just means the player needs to grind more or build 8 instead of 1 quarry. It is just brute force you way through the progression. Not use your brain to progress.

[Elix-x]

Well,

• How are we going make player different switch between lava in bucket and lava in fluid form? Change fluid amount? A ton of complex keybindings is way worse than inputting it and is not a solution.
• And if you want 128 items? 2 stacks. And 65536?
• We always can shapshot itemstack, so when user puts itemstack, we snapshot count and auto input it in count field.
• Options for advanced users must always be there. And defaults are always there too for normal users. In this case, default would be to match meta only.

[yueh]

How are we going make player different switch between lava in bucket and lava in fluid form? Change fluid amount? A ton of complex keybindings is way worse than inputting it and is not a solution.

That is the hard part. Creating a simple UI is pretty much the hardest part in UI design. Just showing the user hundreds of buttons and input is easy.

And if you want 128 items? 2 stacks. And 65536?

64 is the maximum. It also needs to be balanced with co procs. Otherwise they would be useless, if you can define 1000000 cobblestone => 1000000 stone.

Crafting itself is already limited to 1 item per stack.

And for processing, show me a machine, which requires more than 576 of the same item or more than 1 stack of 9 different items per step without intentially wanting to prevent autocrafting.

[Elix-x]

64 is the maximum. It also needs to be balanced with co procs. Otherwise they would be useless, if you can define 1000000 cobblestone => 1000000 stone.

Crafting itself is already limited to 1 item per stack.

And for processing, show me a machine, which requires more than 576 of the same item or more than 1 stack of 9 different items per step without intentially wanting to prevent autocrafting.

64 items - ok. But what's max stack size for fluids? Also, rare fluids like molten octuple diamons will be needed in mb precision, while water may be required in large quantities.

That is the hard part. Creating a simple UI is pretty much the hardest part in UI design. Just showing the user hundreds of buttons and input is easy.

What we can do then is leave the current GUI and add a tab for advanced configuration GUI for advanced users. Another option is to leave current gui, when left clicked on slot with empty mouse, below the grid, display configuration for this slot (category, amount, options). In this case, right clicking will empty slot.

[yueh]

Also, rare fluids like molten octuple diamons will be needed in mb precision, while water may be required in large quantities.

That is the reason why there is no fluid crafting. Because it is just ridiculous. It scales from 8 mB to many hundred B. With item crafting there are at least the usual versions for nugget, ingot or block or compressed blocks. So you do not have to define 81 nuggets when 1 block is enough. Or instead of 43046721 cobble => 1 octuple compressed, it is just 7 patterns with 9 items each. It might take a while before you have your first septuple compressed cobble for the final one. But certainly nobody needs the pattern before being able to craft the previous one. Would it be liquids, there would simply be a recipes for 43046721000 mB => 1000 mB octuple compressed molten cobble as the minecraft itself does not enforce any limits onto the dev to stay reasonable.

Actually it even never really different from normal crafting. It just adds an intermediate step between combine 2 items into 1 new and changes it to something like convert 1 item into fluid, combine fluid with the other item to obtain the product. It pretty much never results in a leftover when using the correct ratio and if melting a full ingot is too much, it usually can be defined with nuggets.

It is pretty much possible to substitute every single pattern with fluid through a normal pattern. It is just 1 Bucket + 1 Block of Redstone + 1 Redstone Dust = 1 Bucket of Molten Redstone. It just requires some creativity. Or something like 13 ingots + 8 nuggets = 1 Bucket of .

Fluid crafting would essentially just be there for players who are literally swamped when they have to deal with anything more complicated than place machine, place interface, put pattern in interface, magic.

And the same pretty much applies to every other form of crafting. Essentia is just turn items into essentia before crafting. So instead of putting 64 herba essentia into a recipe, just place 64 leaves.

I would suggest reading http://ae-mod.info/Suggestion-Guidelines/

What we can do then is leave the current GUI and add a tab for advanced configuration GUI for advanced users. Another option is to leave current gui, when left clicked on slot with empty mouse, below the grid, display configuration for this slot (category, amount, options). In this case, right clicking will empty slot.

It will cause problems for players. Even switching between processing and crafting mode is already to complex for some.

So what are the benefits for adding any "advanced" features? (it really is more debug than advanced) What is currently not possible? If so how many players are affected by it? Is adding a new feature for maybe 0.1% of the uses cases enough to justify making the other 99.9% way more tedious or complicated?

[Elix-x]

First, users aren't stupid, they can read, look and think after all (if they are stupid, i don't have anything to say). Interface should be intuitive, yes. But what's intuitive for one user isn't for another. Whatever we do with thing (tab, button, switch), we will satisfy 1 user and dissatisfy one that previously was. Intuitivity should be looked for, but not at cost of functionality in any way.

And as i said,

Options for advanced users must always be there.

> Something like a "Advanced Pattern" and making it more expensive is not really ideal in a game with infinite resources. That's not the point of it. It can be pattern+stick. It's to not make, as you say, users confused by tabs. --- If we remove sophisticated tuning, advanced users, who want to filter charged items for example, will complain. If we keep it, no matter what we do, there will always be users that will go into the advanced tab. And i'm sure that most of users playing with mods already know what it is anyways. Because all mods around introduced (and keep introducing) these concepts and who didn't know yet had to learn if they wanted to understand and use them.

[yueh]

None of these mods deal with crafting. These are always item transport mods, which do not suddenly break because the insert different items into the same chest. Autocrafting not considering NBT or metadata will lead to dupes or break because the input suddenly the machine do not accept that wrong item etc.

And it requires to completely rewrite the current autocrafting and inventory system. None of them are designed to even allow treating different items as the same item. It was always designed around an iron ingot being an iron ingot. Not to use debug tools to filter by internal data and handle a stick like an iron ingot just because some mod dev decided to use metadata to save ids. Damage value and oredict entries are the only reliable ways to determine if an item can be replaced with another one. Everything else is just guessing and hoping the next mod dev will not break it.

Also can you name any case where it is actually needed? It is still sounds like "maybe some day a mod will require it, let us prepare for it never happening and just make everything more complex to deal with it."

[shartte]

So, why is this being discussed in this detail here? This is so far beyond porting to Minecraft 1.10 that I think it doesn't really belong here anyway.

[Elix-x]

@yueh Let's go straight for vanilla forge example, shall we, or should i enumerate all modded ones? Buckets. Fluid type - NBT (in case you didn't know, now forge introduced universal buckets, who use nbt).

@shartte why not?

[shartte]

Oh go on if you like :P

[yueh]

Why do you want to ignore the NBT of a bucket? There is no reason to allow crafting gold blocks from buckets of water by ignoring the NBT data.

[Elix-x]

@yueh Ok, so that's where we do not want to ignore nbt.

Now, vanilla dispensers. Can be crafted even with bows with enchantments. User won't make a recipe for every enchanted bow he gets from skeleton farm, right?

@shartte also, that's something we started in original thread and never finished because it got too long.

[yueh]

@elix-x That already works. OreDict ftw.

[Elix-x]

Ok, crafting of IC2 machines with batteries / crystals works when crystals are charged. Energy - NBT.

[yueh]

NBT is irrelevant here. IC2 explicitly requires the specific item and not an oredict one. So we do not know what are possible replacements.

What you request is essentially an option the player can toggle to dupe. Why charge that energy crystal like the recipe requires, when you can use an empty one? And oh, there is a recipe to remove the crystal from the item and keeping its energy. So why not just use an empty one to craft a full one and loop it?

[Elix-x]

Ok, let's go another way: how can ignoring/matching NBT/meta/oredict lead to dupes? If it's because their machine does not know how to handle item A, while it accepted it, it's their problem and never ours.

Also, i'm starting to suspect that AE does not have rejection handling.

[yueh]

OreDict is the only one not causing dupes. NBT and metadata are completely undefined values.

Example 1: Mod A uses metadata to store the damage value If every mod would behave like this, it would be totally fine to ignore the metadata. (But there are few other limitations towards crafting calculation later on)

Example 2: Mod B uses metadata to distinguish nuggets, ingots and blocks of the same metal. So what happens, if you tell the pattern it is totally fine to ignore the metadata and use 9 availabe nuggets instead of 9 ingots to craft a block? And of course you can uncraft the block to 81 nuggets. See the problem?

Example 3: Mod C uses NBT to store different tiers of the machine. Why require a tier 8 machine, which needs all previous steps, to craft a tier 9 machine, if you can just tell it to ignore NBT and use a tier 0 machine to replace the tier 8 one?

Rejection handling is pretty pointless with minecraft. Crafting in minecraft is really bad in terms of performance. Each time you validate if a crafting table is valid recipe it checks against every existing craftinghandler and there is to guaranteed complexity with them. So you can pretty much assume O(n) with n being the amount of registered recipes. With some mods it is so slow, that you can already notice a slight freeze when shift clicking a full stack because it has to validate 64 crafting attempts. This is really nothing you want to have as base for you autocrafting, when it can easily be a couple of thousands crafting steps.

What AE does is when the pattern is loaded, it will be validated against the normal crafting handlers. So it can mark changed recipes as no longer valid or make the pattern available to the network. The actual crafting with assemblers is then actually just cloning the output without any further validation each time.

Due to this AE2 uses exact matches to construct the crafting tree. So if a pattern requires batteries with exactly 30% charge because the normal crafting will already produce a slightly charged battery. Otherwise the autocrafting had to predict which meta and/or NBT combinations might result in a valid items. With metadata it would at least be limited to 32k permutations. But NBT can easily achieve a few megabytes and that is not something you want to fuzzy test.

The second option when creating the crafting tree is use existing items (that is the prefered option). Here it can at least use oredict or damaged tools. For example it can substitute thermal foundation copper with IC2 copper when available or use the damaged quartz cutting knife to craft facades instead of crafting a new one for each step. (Why this does not work with IC2 crystals, I have no idea the might not match the usual criteria of a damagable item).

Ignoring metadata or NBT might actually not cause dupes as long as the recipe validation is correctly done. But to get it perfect with all the broken crafting handlers around... Saying no at least keeps a bit of sanity. Another issue might also be that it create a bunch of invalid patterns. Sometimes ignore NBT might work with recipe A but not with B without any hint for the player. Or the crafting handler crashing because the never assumed someone could pass an empty NBT to them.

[Elix-x]

Alright, the dupe ignore issue are in crafting (and i was aware of these). I was talking about processing. See the difference? Second one is using outside machinery. I'm TOTALY fine not having nbt & meta precision in crafting, but they must be there for processing.

[yueh]

The same pretty much applies to processing patterns. The only difference is that crafting pattern push the valid crafting inventory to the assembler for valid item in slot checks. But otherwise it still needs the same requirements. If the recipe defines it needs a 30% charged battery and returns a 0% charged battery, the crafting simulation cannot validate that a 1% charged battery is actually the requested result or just the player dumping it into the network. This also means that if an external machine produces something different than the network being told it will just get stuck.

Fun fact. Request 1k stone, and then manually put 1k stone into the network and it will mark the job as completed, while there still sit 500 cobble inside the buffer to be smelted as there is no way of telling what the source of an item is.

Also what are really the requirements for it? And could it not be handled differently? Your examples were only normal crafting ones. What I currently good see is something like keeping all batteries charged. But that is not the goal for autocrafting. This is just "give me a newly crafted one". Keeping every battery charged something like an export bus set to export any battery under 25% into the charger is way more suited for it.

Keep in mind that autocrafting is really complex to get right with every exception already in place regardless of crafting or processing. That is for example one reason why there is no NEI to pattern button and instead it requires the actual item. Because that is how the machine will dump it back. NEI might return some completely different item with some random nbt data just do define it is rendered in NEI and should use a different model or so. You do not want to add more complexity on top of it, just to be able to handle 1 or 2 cases which already are possible through outer ways and simultaneously give every player the ability to break autocrafting by clicking the wrong button or forgetting to switch it back and leave them with one broken recipe hidden in hundreds of other patterns.

[Elix-x]

Well, i think with processing it's full user's (and machine's mod authors cough cough) responsibility. AE in this case should just dump what it's told into machine if it can and take the results. If the machine does not like what we dump into it and rejects it, system stalls (jk, but there should be an error report of some kind). If it didn't get what it wanted to, stall system again (or wait an infinity, but there should be time out for another error reporting).

So yeah, what was there before was there to ensure that everything goes smoothly. But nothing ever goes smoothly, an there are always errors and exceptions. I think we simply should teach AE that mistakes exist and nothing is perfect.

[yueh]

If someone can actually provide some uses cases, where it is clearly not possible with any other alternative and suddenly hundreds of players are reporting it as issue, then I clearly have nothing against it.

But I do not see any reason for it now. It just adds complexity without much benefit for us as well as the players. It clearly will make it easier to create bugs with and it will talk much time to redesign the crafting system.

I cannot even remember anyone ever requesting something along the line. Usually it is something like "plz let me ignore metadata, so the export bus can export every item out there". Which clearly violates the game design of AE to not expose internal data but only work with what you can see ingame (without debug tools). So essentially just a copper ore and optionally if you see a copper ore with a different texture, it should handle that too.

And as you said, nothing is perfect and also does not need to be. So not supporting one or two use cases is perfectly fine.

[Elix-x]

to not expose internal data but only work with what you can see ingame

That explains many things. But should we still follow it? Unclear, because probably all modded mc players already know shallow stuff (nbt & meta), play with F3+H on, and there's no standart way for mods to use one or another.

And as you said, nothing is perfect and also does not need to be. So not supporting one or two use cases is perfectly fine.

Meanwhile AE tries to be perfect (ly stable, ly working, ly compatible...) with the 3rd one...

---

Back to fluids, so how are we going to make processing pattern GUI for them?

[yueh]

But should we still follow it?

I personally consider it a pretty poor design choice. Most players know not really the what is it. Or even the difference between meta data and damage. They use it basically as synonym while it is something completely different. Also some future minecraft version might completely replace metadata (probably in the near future) or even NBT data. What will they then expose? A full regex matcher so players can define (123|5|14|6|modA:pretty.long.and.random.item.id|<insertRussianItemNameHere>)? and a DSL to match NBT? So suddenly everyone needs to know that ignore:damage<0.25 can select anything above 25% damage?

ly compatible

With a vanilla chest as "machine". Not with whatever a mod dev might come up. The most basic one about "dump stuff here, get stuff eventually out"

Back to fluids, so how are we going to make processing pattern GUI for them?

But no idea about the GUI... If we just speak about liquid transposer type machines. Why not just something like Choose fluid, place container to be filled here, click export to create a fluid pattern which completely fills this container?

Regardless that should have a pretty low priority without fully rewriting the inventory system before to better support it.

[Elix-x]

I personally consider it a pretty poor design choice. Most players know not really the what is it. Or even the difference between meta data and damage. They use it basically as synonym while it is something completely different. Also some future minecraft version might completely replace metadata (probably in the near future) or even NBT data. What will they then expose? A full regex matcher so players can define (123|5|14|6|modA:pretty.long.and.random.item.id|)? and a DSL to match NBT? So suddenly everyone needs to know that ignore:damage<0.25 can select anything above 25% damage?

Well, because each mod uses different thing, it comes down to trial and error for everybody. Do DR crystals use meta? Test - no. NBT? Test - yes.

With a vanilla chest as "machine". Not with whatever a mod dev might come up. The most basic one about "dump stuff here, get stuff eventually out"

Yes, sure. Just still AE must have a way to handle invlaid outputs / no outputs and "throw" error into user's face (not really).

But no idea about the GUI... If we just speak about liquid transposer type machines. Why not just something like Choose fluid, place container to be filled here, click export to create a fluid pattern which completely fills this container?

And custom machines? Good example: vat from EIO.

Regardless that should have a pretty low priority without fully rewriting the inventory system before to better support it.

Yes, it should be rewritten. And generalized so it does not work only for items.

[yueh]

And custom machines? Good example: vat from EIO.

There is always the storage bus + level monitors + buses.

Yes, it should be rewritten. And generalized so it does not work only for items.

It is generalized for fluids and items. But they are so different that they do not fit really well.

[Elix-x]

There is always the storage bus + level monitors + buses.

I was speaking about processing pattern.

It is generalized for fluids and items. But they are so different that they do not fit really well.

They are different, but they still have many things in common:

• Both have a type (apple, stone, lava, fluitin)
• Both have amount (32, 2000mb)
• Both have NBT. Items simply have metadata on top of that.

[yueh]

Just because something has a name, it does not mean it is similar to other things with names.

ItemStacks have the id, metadata, damage and nbt as important data. Additionally the oredict to mark similar items. They need a precise way to get exactly the requested item and a way to do a range query. All items regardless of the damage/nbt, all items between 0 and 25% damage and so on. Also range queries for every equal item accordingly to the oredict, without comparing many ten thousand items for matches. No guarantee that the item is actually the instance registered to the game registry, no equals/hashCode do be able to cache them in an easy and fast way.

Fluidstacks have a Fluid as type and this is always the singleton instance registered to forge. That is it. Different type? Different fluid. Different NBT tag? Different fluid. No Fluid Dictionary. No 50% damaged water. The whole fuzzy approach is not necessary. No need for equals, as an identity comparision is enough to determine the same fluid or not.

There is further no way to ever compare a fluid and itemstack by just the shared attributes (there are none).

Thus both need completely different collection implementations. Both need a completely different set of methods to access these collections. Trying to solve both with the same approach just provides you with the downside of both without being able to use the best approach. So no IdentityHashMap for fluids, you have to use the most complex collection to keep items and fluids in the same data structure. Y You have to internally constantly cast the types to subtypes to even be able to actually compare both. This also will need to exceptions should a fluidstack ever be passed to an itemlist because you do not want that to ever happen and also not have to sanitize the input. We are not speaking about methods being called twice per tick. These can easily be invoked a few hundred million times (or even billions) in a few minutes.

We have this approach currently and it really prevents some optimizations or even making it actually typesafe.

[Elix-x]

Fluidstacks have a Fluid as type and this is always the singleton instance registered to forge. That is it. Different type? Different fluid. Different NBT tag? Different fluid. No Fluid Dictionary. No 50% damaged water.

Actually, no. Modders can use NBT to specify fluid's properties, like they can with items. Example: deep resonance molten crystal (quality & other stuff is saved in nbt). And forge fluid registry also acts as fluid dictionary (so no more 10 oils from 10 mods).

[yueh]

If a fluidstack has NBT or not is pointless. If both NBT tags are not equal it is not the same fluid. That is it.

The fluid registry absolutely does not act as fluid dictionary. The only case it prevents mods from registering "oil" multipe times. Which leads to what? Exactly, now you have to deal with "oil", "bc_oil", "pnc_oil", and 10 more prefixed "_oil" and that is already happening because some devs do not wish that their oil can be replaced by someone else.

[Elix-x]

If a fluidstack has NBT or not is pointless. If both NBT tags are not equal it is not the same fluid. That is it.

Not the same fluid stack. Item - Fluid. Item stack - Fluid stack.

The fluid registry absolutely does not act as fluid dictionary. The only case it prevents mods from registering "oil" multipe times. Which leads what? Exactly, now you have to deal with "oil", "bc_oil", "pnc_oil", and 10 more prefixed "_oil" and that is already happening because some devs do not wish that their oil can be replaced by someone else.

Just like some modders avoid using ore dictionary for their copper.

[yueh]

We store fluid stacks not fluids. If FluidStack.isFluidEqual() says they are not equal, they are not equal.