Dealing with Small/Tiny piles of dust

[mitchej123]

Proposal to deal with laggy solutions to tiny dusts

Early Game 1) Create a "dust drawer" that is essentially a compacting drawer that only works with dusts. You have one per type of dust, and can input any size (tiny, small, normal), and pull out any size. 2) Alternatively a "dust funnel" that acts similar

Late Game 1) "Dust drawer array" similar to above, but a multi that mimics the behavior of the early game but more compact for larger number 2) A new multi, or modification of existing processing to let the player opt between tiny/small dust output, or a (roughly) equivalent percent change for a full output. This would likely not be desirable because RNG sucks in small quantities, but averages out over larger numbers.

[Prometheus0000]

Or, get rid of tiny/small dusts altogether (at least from ores) and give a % chance at a full dust instead.

Or, for recipes that give a tiny dust, do 9 items at a time, get 1 dust instead of a tiny dust.

[mitchej123]

I like tiny dusts, I have no intention of fully removing them. I'm however ok with the ability to toggle whether you want a tiny dust, or a % chance at a full dust. Modifying the parallels to do enough to always give a full dust seems more annoying than it'd be worth.

[GTNH-Afx237v7]

From the top of my head, small/tiny dusts come from: Washing crushed ores Centrifuging impure dusts Centrifuging planet stone dusts (With %chance) Thermal centrifuging purified dusts Centrifuging dusts (with %chance)

The percent chance of full dusts is already implemented for thermal centrifuged dusts

Guess I am still missing a few...

[KiloJoel]

There's also centrifuging various bee combs

[GTNH-Afx237v7]

Plus the chemical processes, such as when making tiny piles of indium in an LCR

[leagris]

Plus

• grinding / macerating various items (nuggets, bolts, screws, sticks…)
• arc furnace outputs
• ashes from small coal boilers and primitive blast furnace
• lath grind (small dusts)

[0lafe]

Imo as much annoyance as they give early game, in midgame+ they offer a cool logistical challenge. A good setup will require the player to be able to abstractly push stack sizes of a specific quantity, usually without defining individual recipes. Given the issues with GT buffers later on (speed/lag) this presents itself as a fairly unique problem to tackle. solving it in a way that isn't tedious as fuck offers some cool challenges for the player to tackle. generally it seems like one of the things that makes you think a little harder if you want a good efficiency from it.

if there is a midgame+ multi for it, imo it would be nice to make it somewhat unique to mirror the current complexity. doesn't have to be 1:1 the same idea of individual stack sizes, but something unique would be cool to fill the spot.

Maybe something related to compressing in world entities? such as filling an inventory, then putting that inventory block inside of a machine, then moving it out once the machine is done. could be setup to do almost infinite parallels based on inventory size, isn't dependent on any specific mods, but still offers a new challenge for the player to tackle. Hell, if the inventory would drop its items when broken, you can't even really use sfm for it :D

could do something in which running the machine takes a specific amount of some catalyst, fluid, or generic other input. If the parallels are related to this alternate input, the player can now decide what the stack size they want to input is, which not only gives some cool player choice, but gives more options in handling that specific item input as 9 stacks of items is a lot easier to abstractly specify than 63 items.

if you just need to input them to a machine that handles everything for you, and you can just put an AE ore dict bus for dustTiny or dustSmall on an input bus, imo it might be better to just not have the dusts at all. setting up another machine that's the same as the rest doesn't offer much to the game imo. you're already setting up a ton of these, and it's not really much different than ore proc at that point. seems more tedious than a cool new challenge

[GTNH-Afx237v7]

For early game I think the compacting drawer version is good and comes in handy. For late game I’d prefer to be able to choose between tiny dusts and %base. And it’s true, when you have a high ore income it won’t make much of a difference with regards to RNG.

[Florexiz]

At early and midgame tiny dusts are indeed provide interesting challenge for players, but at UV+ (maybe even zpm) it just changes to "spam more machines, increase pipe size". Some late game multis that can compete with GT++ in terms of speed per machine and changes tiny piles to 10-12% chance of full dust looks perfect to me. Maybe even 1 step ore to dust processing with byproducts. At this point Its not a challenge in terms of gameplay mechanics, but rather game limitation.

[0lafe]

i'd argue there's a bit more to it than that. When you start parallelizing your multis, you need to adjust your inputs to be able to handle multiple outputs while keeping the stacks separate. with more speed you also end up needing faster transfer, which can be tricky if you just spam more GT buffers for stack sizes.

promotes fun things like efficient transfer setups with better scaling. trying to find ways to solve the problem, that aren't incredibly tedious, promotes some other fun things to think about. it might not be perfect but i'd take it over something you just throw an ore dict bus on. the machine spam isn't really that bad comparatively, so imo it's justified given the uniqueness of the logic

[Florexiz]

I cant understand why you cant do this with simplistic design - input to output pipe with few filters for unique processing. Well, unless your output busses produce more than 512 stacks per second each, so you cant connect conduit to pipe.

Maybe its not so crucial when you are playing sp, but at servers any ms is important. Its not a healthy situation when your main problem isnt efficiency and cleanliness of setup, but game performance.

[0lafe]

usually you're doing 64x parallels with PAs, but you need 9x item inputs for packaging. if you don't regulate in some ways, you'll end up with excess tiny dusts in the inputs. there's more than enough ways around it for sure, but it's a little more unique than just constant inputting from an output/AE

[zgggz]

I'm at late game. I need to work with about 1 mil small/tiny dusts per min. Any solution make TPS lower significantly.

When i started to work with problem i made 8 bezos machines in 1 chunk. I got fail. TPS go to 1-3. Separeted to 1 bezos in a chunk: tps grow to 3-5. Replaced them to PA: tps come to 7. Now i made special system with molecular assemblers. One for small dust, one for tiny and TPS come to 10. When they off - 20!

big dusts with % of chance will be nice solution to remove this lags.

[0lafe]

yea you happen to have some of the laggier things in those pics. super buffers aren't great on the server, especially late game and when you have a lot of them. i'm also assuming that constant large scale molecular assembler usage isn't great, but that for sure has its own downsides with pattern setup and such.

my main point is that attempting to handle the items without super buffers is pretty innovative and complex. there's a bunch of ways you can do large parallels that don't occur every tick, like filling set buffer sizes then moving when full, or moving entire buffer blocks themselves. OC/SFM can of course do this no problem, but apparently people like more options for late game? i could see some cool options with drawers, translocators and quantized single item movement to specify 63x stacks

[Florexiz]

63x stack size is a basic thing to do at this stage. SFM doesnt have any way to specify universal pattern for every dust. OC cant work at such speeds. Translocators are extremely bad tps wise, Moving gt machines with teleposers even worse idea performance and efficiency wise, also prohibited by rules

[0lafe]

i'm not sure it's so basic given the fact that you seem to not have a solution. with sfm/OC i wouldn't recommend counting specific items, or attempting to use crafting table recipes, but rather use some more complex logic to handle the inputs into a packager multi. drawers and baby chests give a good option as you can make many inputs of a given item type, then check if they're all full, remove some items, then move a batch of 63x items up to how many inventories you have.

moving GT machines generally isn't too bad, but i more meant moving things like drawers, chests, etc. some things struggle to pull quickly from things like drawers, so you need to get a little more creative with your solutions to that.

[0lafe]

translocators can be laggy but that's usually when they have glow stone and are doing stack/t into some types of inventories. i was more suggesting using them with a red stone toggle as a way to semi quickly remove a specified amount of items from an inventory. as 63x can be a bit weird, you could for example give it a 1t pulse to remove 1 item from a full baby chest to make 63 items

sure the idea of getting 63 items alone isn't terribly complex, but doing it at the speeds that late game requires, with minimal tps impact is much more complex

[mitchej123]

All of these silly tps hungry workarounds... as opposed to just fixing it later game.

What you're proposing is not fun, it's annoying.

[0lafe]

quite quick to label something as tps hungry without much knowledge on it i see. they aren't too bad if you do them well. you won't need to run it every tick, nor check every item every time, which is two big bonuses over the superbuffer method.

this is really pretty late game stuff, it makes sense that it's harder to handle than using a single buffer block, or multiple AE patterns. i'd argue it's a lot more annoying when the machines and processes we have don't change much with progression. seeing people still using interfaces on busses or single item sorters by UV is kind of boring when you've been doing that for so many tiers already. why not allow the player to make more complex setups in tiers that should in theory be more complex

[mitchej123]

quite quick to label something as tps hungry without much knowledge on it i see.

I'm fairly certain I've dug further into the TPS of things on MC, and have sped up far more of them than you have. Stop with ignorant throwing of shade.

[mitchej123]

this is really pretty late game stuff, it makes sense that it's harder to handle than using a single buffer block, or multiple AE patterns.

Handling of small piles of dust... late game .... should be harder. wat?

You can run fusion, you can fly to other galaxies, but you can't have a machine to efficiently handle your tiny piles of dust? Seriously?

[0lafe]

You can run fusion, you can fly to other galaxies, but you can't have a machine to efficiently handle your tiny piles of dust? Seriously?

you can, you just need to build it. why does everything need to be handed to you based on the same dumbed down progression? why not get the player to do some of the more difficult aspects as you progress? fusion and rockets are cool, but those too are pretty low tier in their function tbh. hell, solar boilers present more of a challenge than either of those options lol

[leagris]

I propose a Silo multi-block structure like this one:

The Silo

The Silo is a dust storage, filtering and distribution multi-block structure of varying height and construction materials.

It may be built out of wood, stone, steel, stainless-steel, tungsten-steel, titanium… with each construction material allowing various structure height limits and storage capacity.

It is gravity powered and mechanically driven, so require no power source to work.

The Silo Capacity

The Silo can store large amounts of a material's dust in its raw form as unit count. Material dust units are:

• Full Dust: 144 units
• Small Dust: 36 units
• Tiny Dust: 16 units

The Silo itself may store varying amount of units, depending on its height and the material used for its casings structure.

The storage density and capacity of the silo may be aligned to that of Railcraft tanks for the steel structure.

Loading the Silo

Atop center of the Silo, is the Loader and Filter funnel.

It is the structure controller and the only input access to charge dusts of a given material into the Silo.

The filter may be locked to the currently stored Gregtech material, so even when the Silo is empty, only dusts of this material are allowed to enter the Silo.

The loader accepts Dusts of any size, of a given material and, if the Silo has enough room left, for the units amount of the dust.

The controller may also control the size of dusts available at the bottom unloader output bus.

Unloading the Silo

Bottom center is the output bus that is filled by gravity once every second.

The controller checks available space into the output bus, then place dusts of the selected size, up to the stored material units and, available space into the output bus.

[Prometheus0000]

? Why would we want a MB to store dusts? You forgot to mention it's purpose, if there is one other than that? And why store fewer of the things there would be more of? How is it different from the much smaller super buffer?

[Florexiz]

It can replace super buffer with packager setup and have different storage mechanic (similar to fluid). Well, this can be interesting, but Im not sure if it solves main purpose - performance. Input filter? Output bus speed? Just filtering tiny dusts from main flow? Still an issue

[johnch18]

The full output from processing VM stuff far outpaces any kind of packaging system atm.

[github-actions[bot]]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 3 days

[github-actions[bot]]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 3 days

[hohounk]

What about having a special cover one could slap on a machine (or a block in a multiblock) that makes it output percentage-based full dusts instead of small/tiny ones? That way you won't have to generate two versions of a recipe (I think/hope).

I would see it function as when the machine picks a recipe to do and if it has small/tiny dusts in output it automatically calculates (or probably pulls from cache) the chances of full dust outputs it should have.