Gt-new-horizons-modpack: [Feature request(?)] Volumetric flask setter

[0lafe]

Which modpack version are you using?

2.0.8.9

What do you suggest instead/what changes do you propose?

If it's easy to add, it would be nice to have a block that would set flask values without player input. You can possibly need lots and lots of flasks, so setting values 16 at a time can take ages. If we could set a value on a machine and have it set them for you on the flasks.

If possible, an easier method could be to have recipes in some other machine and use circuit integrations to set useful values. Multiplies of 144 and 250 for example.

Also, if their stack size could be increased to 64, that could be helpful for manually setting values. Possibly using many thousands of these at varying values, is painful by hand. 4xing the amount you can do would be incredibly helpful alone.

[Retster]

That feature would be wery-wery useful. And stack size 64 is also simple to implement and would help alot. QOL change.

[leagris]

Instead of adding feature, re-enable OpenBlock tanks and uses these in crafting pattern with the fluid export bus.

[Glease]

How good is OpenBlocks tanks though? Never used them before.

[Dream-Master]

they lag as hell that's why we disabled it.

[draknyte1]

Fps wise they can cause lag in large quantities, but that’s it.

[leagris]

Are the flasks able to program patterns with fluid like OpenBlock tanks does?

[Prometheus0000]

Doesn't he want them for on demand recipe amounts? Like, send it to the super tank to get a filled one, and then to the input hatch of a PA for the recipe, then back to storage. I'm not sure what you mean about the openblocks tanks and crafting patterns though. Do you have a link for how 'program patterns with fluid like OpenBlock tanks' works?

[leagris]

• Fill OpenBlock tank with the exact amount of fluid needed for recipe. Example 144l of molten rubber.
• Place filled OpenBlock tank with other items (copper wire) for recipe in the pattern grid in machine recipe mode and select a copper cable as output.
• Encode pattern.
• Place pattern in Fluid Interface/Export Bus

→ Get on-demand recipe for copper cable crafting with exact amount of 144l molten rubber and copper wire...

EC2 bus will provide the fluid amount and the items from the recipe.

[Prometheus0000]

Wouldn't the fluid export bus just export all molten rubber? And don't patterns not go into fluid export busses to begin with? And even if you put it into a fluid interface, wouldn't it just export the 144l molten rubber and not the items? Or do you need a regular interface as well, and a coprocessor on the crafting storage? Or can the fluid interfaces export items as well? And can you not use the flasks for this? Maybe adding compatibility with the flasks would be better if it isn't too hard. Can you use the universal cells? Do you need fluid in fluid cells, or can you grab it with a fluid storage bus?

[leagris]

The fluid interface will export items as well.

It is the nicest feature of EC2 and a good reason to store fluids into the ME.

[leagris]

Here is how it works. Can be done with a volumetric flask:

In Pattern Terminal:

Switch to Processing Patern:
Place Volumetric flask with 144L Molten Rubber and Wire
Encode Pattern

In Fluid Interface

Place encoded pattern into the fluid interface:

In assembler

Has Fluid interface will insert desired amount of molten rubber and cables into the assembler. Place a standard ME interface to recover the assembler output into the ME again so the crafting CPU detects crafting task completion.

Conclusion

There is no need to re-enable OpenBlock tanks. The Volumetric Flask perfectly works in crafting patterns for use in the fluid interfaces.

[Prometheus0000]

Though this is only for if you can directly interface with the machine, it's still cool. But if it's in a PA, can you split the items and fluids using conduits or pipes/item pipes? I heard that import busses aren't fast enough at high levels, do you just use a conveyor to export into the interface?

I especially love how most of this discussion is about something other than what the issue is actually about. Maybe the auto-chisel could be reused? Even if it's just for specific ones, I believe 9, 18, 36, 48, 72, 144, 250, 288, 532 576 would cover almost all volumetric flask uses. But can the auto-chisel work that way? I'm not sure if the size is set with nbt or metadata.

[0lafe]

Nbt iirc. @leagris the issue is I need like thousands and thousands of the 144L cell you start with. You normally have to set them by hand to 144L, which can take hours for whole setups.

Autochisel would probably work, but that seems harder than a recipe I think. I'd also recommend values such as 576, 720 and 864, as well as 500/750. When doing large PA batches, it's a nice cell reduction to use higher quantities.

It's incredibly easy to split the cells off. In assline crafting I use GT pipes and an item filter with nbt disabled holding a flask, and a restrictive pipe on the item side. Similar idea for multifluid assembler and things like the fluid solidifier with item inputs

[Houstonruss]

I'd be happy so see the default value at 144mb. After setting 3000 flasks i want to die.

[Prometheus0000]

So after investigating, I may have found a solution, but it's probably sorta janky-ass.

Basically, you use the me fluid interface on a machine hull, which CAN handle both items and liquids, so they both get sent (unlike conduits/item pipes, which won't even connect). Then use conduits (didn't test gt pipes+conveyor+pump, but they'd probably work) to send to the input bus+hatch. I'm not sure what the throughput on a machine hull is though, or if there's another good block that accepts items and fluids.

[leagris]

Machine hull has max speed throughput for fluid (maybe restricted by tier dependent internal fluid storage capacity), has default slow auto-output at the designated side if powered. Sometimes it is a better choice than pipes like for large steam turbines. And yes, conveyor and pump would work.

[Prometheus0000]

The machine hull tier doesn't seem to matter (LV vs UV, no change in speed). I checked, and there seems to be no difference in speed with PA (with one machine) vs single block using this method (both UV assemblers, with UV conveyor+pump+appropriate pipe+item pipe), so long as you do a large enough batch that the PA doesn't stall. The auto-output might be slow, but using conveyors+pumps makes it not it seems.

There might theoretically be a problem with very small pipes if it waits to export items until it finishes fluids first, but it worked fine with tiny void metal pipes and a 192 cable recipe done several times in a row (requested 1000).

Also, you can use a stack of molten rubber cells to do 64 cables at once instead of using flasks to do it one at a time, which does slow it down since the PA turns on and off. Or even 3 stacks for 192. Or 4 if you use the new terminal.

[Glease]

Just use the block variation instead of the panel variation. It can push to all 6 sides, so you can have one side with ender fluid conduit, the other side with chest/input bus (item conduits don't connect, but chests do work).

If the recipe needs more than one fluid, it will push it one after another. It will block until all fluids in current item's recipe is outputted and continue to push fluid/item for next item's recipe.

As a side note, the infamous EC2 fluid dupe bug kicks in again. If there are more than 1 tank/conduit/pipe attached, under certain circumstance it will output more fluid than consumed.

[Prometheus0000]

Glease, could you make a ticket for that? DeForce said they'd look into the EC2 stuff at some point, so I'd like to have an actual issue so they know what to look for from someone who knows exactly how to reproduce it.

[Glease]

I actually know what goes wrong and is now fiddling with the code. If I give up I'll write an issue, otherwise I'll send the PR later when I'm done.

[Glease]

@Prometheus0000 the aforementioned dupe bug is fixed by GTNewHorizons/ExtraCells2@3a7bc94

[botn365]

my problem with the fluid interface is that you can craft fluids on demand you always need it in stock
that means for evry metal fluid you need a fluid extactor and fluid bus while with flask you make a pattern for it

[draknyte1]

Decided to quickly implement this.
Available in my next build.

[GeicowithaBango]

How about a crafting recipe that stores common values. the 3x3 crafting table could hold up to 9 pre defined values for flasks. For example: 144, 250,500,750,(1000) etc.
It seems like an easy solution that can be nicely integrated @Dream-Master

[leagris]

How about a workbench recipe that copy flask volume in first slot to flasks stack in the second slot?

[GeicowithaBango]

even better

[draknyte1]

GUI is still WIP cause it's post-midnight. (Will finish it up tomorrow)
But it's got some preset values and a box for entering your own. Dunno what else it needs?

[Dream-Master]

If we can't update gt++ to a newer version than 53 how we can add it ?

[GeicowithaBango]

i like @leagris approach, gameplay-wise.

[draknyte1]

There’s no reason you can’t update @Dream-Master.. if there is, it would help if you replied on discord to my queries. 🤦🏻‍♀️

Shit won’t fix itself and I won’t fix it if I don’t know what to fix. Ffs.

[GeicowithaBango]

I guess we can just add crafting recipes then......

[draknyte1]

You can’t really add a generic crafting recipe like that though.

You’d be limited to presets only, couldn’t just copy from A->B.

[GeicowithaBango]

having a few parameters is enough, isnt it? You still can give specific values by hand, I dont see how this is argument.

[draknyte1]

The idea is to avoid setting the values for a stack+ by hand, crafting won’t resolve that fully. So no, it’s not an argument. 💁🏻‍♀️

[GeicowithaBango]

my idea works with ae2, yours doesnt.

[draknyte1]

Don't see why not?
You can set default slot with screwdriver, then just pipe them in/out.
Custom value is retained, for slot 8.
it's just simple L O G I C~

[GeicowithaBango]

Just makes it more difficult for the sake of being difficult. Frankly speaking, thats dispensable.

[draknyte1]

It's uhh, exactly the same as circuit programmers. 🤔
People hate doing that via crafting.

Community already likes the idea and even the person to suggest crafting recipes approves. No point adding NEI crafting recipe bloat when it's not required.

I know you don't like my mod, but the anti-GT++ train doesn't hold many passengers or go very far. Poor minority you are.

[GeicowithaBango]

Didnt dream just pointed out that your mod wont get updated anymore?
I dont see then why your content should be used to fix problems or follow suggestions, specifically on this gtnh github.
Shocking, I know.

[draknyte1]

Didnt dream just pointed out that your mod wont get updated anymore?

No, lol. He doesn't have a working build beyond that version, as I haven't given him one. :')
I just find it odd that the mod exists and people try pretend it doesn't. Why not use the content that is there and isn't going away? 🤔
Implementing obsolete alternatives for the few naysayers is pointless, which is more shocking.

[GeicowithaBango]

I just find it odd that the mod exists and people try pretend it doesn't. Why not use the content that is there and isn't going away? 🤔

do you wanna hear the short or long story?

[draknyte1]

Long story, please. 👏
We've already gone so far off-topic, why not derail it even more.

[GeicowithaBango]

hmm bigbass is watching, and i really wanna freakin curse.

[Prometheus0000]

https://www.curseforge.com/

[Dream-Master]

I am watching too ...

[GeicowithaBango]

I will not speak in bad terms. However, there a various thing I want to point out about alks behavior for the time Im playing the pack/ being on the discord, which makes it hard for me to use any of his/hers/its stuff or even writting with him/her/it on the same channel.
1.) He/she/it is an attention whore that would deliberately destroy the game balance just for making his mod more attractable.
2.) He/she/it doesnt cooperate with gtnh-team until Bart pressures him/her/it to the limit.
And even then he/she/it doesnt wants to accept it, and tries to surpass it by devising lies.
3.)Anti-team-player.
4.) Thinks highly of himself while being a cunt to everyone else, I know, probably mental disorder but still....
5.)Doesnt react to feed-back.
6.)Manages to break everything he/she/it touches and doesnt accept clearly own faults.

So in conclusion, i would rather fucking not use gt++. For those who didnt realised that until now.

[GeicowithaBango]

Cuz I have to put on my fucking double seeing glasses to begin to see the amount of Bullshit he/she/it writes.

[draknyte1]

In simple response:
1) I listen to community on balance input & Dream if asked.
2) Bart doesn't do shit, nor work with me. I always cooperate with Dream. (Bart just breaks stuff)
3) I'm not part of any team, so.. irrelevant point.
4) It's the internet, might as well have a superiority complex.
5) Reacts to all constructive feedback and criticism, which people fail to provide more often than not.
6) I will if proven at fault, but generally I can prove otherwise.

Nobody really cares what you do, but speaking for yourself on a community topic isn't really the goal here now is it?

🍿

[ScriptedPiky]

First off, while Alk being an asshole is true for the most part, Alk has added three very important items that will disable three separate things on the multiblocks: Parallel, Speed, and Energy Reduction. Alk has even told me that you can apply this by simply making the base machine class require the 'no bonus chip' in the special-slot (hey Alk, can you confirm this?). Just wanted to point this out on the latest version of GT++ 53a and GTNH 9.0

[Dream-Master]

So i close the conversation now. This is to heated and github issues are not for this kind of discussion.

[Dream-Master]

@GTNewHorizons/core @GTNewHorizons/developers feel free to discusse about the original issue. Thanks

[Prometheus0000]

See #6733 and https://github.com/GTNewHorizons/GT5-Unofficial/pull/321 until/unless alk makes the machine fully usable (automatable)

[botn365]

with my changes this can be closed now imo

[botn365]

my bad sinse this fix is reacent should get closed after a new version is released and just mark it as fixed in dev