Factorio Forums

mrvn wrote: Mon Aug 10, 2020 4:42 pm

ptx0 wrote: Mon Aug 10, 2020 2:57 pm

Sopel wrote: Mon Aug 10, 2020 10:35 am The usage of loader -> compressor -> loader is due to game limitations. It also incurs unnecessary performance costs (furnaces with a lot of recipes are bad for performance, see here) which this approach is trying to reduce. I think there should be a single entity that does this for transport lines (like a splitter) and (special) assemblers should do it by themselves.

here we go, finally, a suggestion here that makes sense.

i have to often do belt -> loader -> beltbox -> loader -> loader -> buffer box. it's awful.

Not sure why. Beltboxes are natural buffer boxes on their own. One stack of input and one stack of output. Isn't that enough buffer for you?

because beltboxes don't make things available to bots, doi.

I think the usage of loader -> compressor -> loader should remain, where compressor can be an assembler set to "(un)compress only". In this mode you would select the item to compress or uncompress or <any>. This setup should only be used rarely as there would be no need for it. If you want compressed items on the belt the normal way would be to select compressed output at the miner / furnace / assembler that produces said items.

opinions are like... well, we all know how that goes. sometimes you put on a new production and don't wanna retool the old stuff just to make it use stacked components. so unstacking before it goes to the starter base is what i do.

Note: compressing mixed items (with loaders) rarely works out as you have to count perfect or it deadlocks. Compressing <any> really only make sense with a lot of circuit logic. Doubtfull anyone would cry if that doesn't even exist.

any mixed item with inserters or loaders will deadlock if you don't do it correctly.

Only reason I can think of for the dedicated processor would be to convert existing stock (because you want to more than need to) or to uncompress a small quantity if bots aren't allowed to carry compressed items. Otherwise the goal of the proposal was to make compression transparent

it is already transparent, except for the miners. if you can mine stacked items directly, no need for belt boxes, because stacked ores going into furnace become stacked plate which can turn into stacked wire... etc directly, using stacked recipes.

so you don't have to compress/uncompress manually.

you don't.

ptx0 wrote: Mon Aug 10, 2020 7:16 pm

mrvn wrote: Mon Aug 10, 2020 4:42 pm

ptx0 wrote: Mon Aug 10, 2020 2:57 pm

Sopel wrote: Mon Aug 10, 2020 10:35 am The usage of loader -> compressor -> loader is due to game limitations. It also incurs unnecessary performance costs (furnaces with a lot of recipes are bad for performance, see here) which this approach is trying to reduce. I think there should be a single entity that does this for transport lines (like a splitter) and (special) assemblers should do it by themselves.

here we go, finally, a suggestion here that makes sense.

i have to often do belt -> loader -> beltbox -> loader -> loader -> buffer box. it's awful.

Not sure why. Beltboxes are natural buffer boxes on their own. One stack of input and one stack of output. Isn't that enough buffer for you?

because beltboxes don't make things available to bots, doi.

Unless beacons prevent you from having the space you move the stacked items with bots and unstack at the assembler. Saves a ton of bots. Anyway, with the suggestion you wouldn't unstack for the assembler so the point is mood.

ptx0 wrote: Mon Aug 10, 2020 7:16 pm

I think the usage of loader -> compressor -> loader should remain, where compressor can be an assembler set to "(un)compress only". In this mode you would select the item to compress or uncompress or <any>. This setup should only be used rarely as there would be no need for it. If you want compressed items on the belt the normal way would be to select compressed output at the miner / furnace / assembler that produces said items.

opinions are like... well, we all know how that goes. sometimes you put on a new production and don't wanna retool the old stuff just to make it use stacked components. so unstacking before it goes to the starter base is what i do.

Again, obsolete with this proposal as the same tooling would work with both uncompressed and compressed items.

ptx0 wrote: Mon Aug 10, 2020 7:16 pm

Note: compressing mixed items (with loaders) rarely works out as you have to count perfect or it deadlocks. Compressing <any> really only make sense with a lot of circuit logic. Doubtfull anyone would cry if that doesn't even exist.

any mixed item with inserters or loaders will deadlock if you don't do it correctly.

Only reason I can think of for the dedicated processor would be to convert existing stock (because you want to more than need to) or to uncompress a small quantity if bots aren't allowed to carry compressed items. Otherwise the goal of the proposal was to make compression transparent

it is already transparent, except for the miners. if you can mine stacked items directly, no need for belt boxes, because stacked ores going into furnace become stacked plate which can turn into stacked wire... etc directly, using stacked recipes.

so you don't have to compress/uncompress manually.

you don't.

You have to choose a recipe currently (and have a staked recipe mod installed). But I guess that part won't go away completely as with the proposal you would have to switch the assembler output from un-compressed to complressed. Unless the default is to mirror the input, which would probably a good idea. If no override is set and all inputs are compressed then do compressed output.

mrvn wrote: Tue Aug 11, 2020 11:07 am

ptx0 wrote: Mon Aug 10, 2020 7:16 pm

mrvn wrote: Mon Aug 10, 2020 4:42 pm Not sure why. Beltboxes are natural buffer boxes on their own. One stack of input and one stack of output. Isn't that enough buffer for you?

because beltboxes don't make things available to bots, doi.

Unless beacons prevent you from having the space you move the stacked items with bots and unstack at the assembler. Saves a ton of bots. Anyway, with the suggestion you wouldn't unstack for the assembler so the point is mood.

and how do you suggest the bots get access to the stacked item?

ptx0 wrote: Tue Aug 11, 2020 1:49 pm

mrvn wrote: Tue Aug 11, 2020 11:07 am

ptx0 wrote: Mon Aug 10, 2020 7:16 pm

mrvn wrote: Mon Aug 10, 2020 4:42 pm Not sure why. Beltboxes are natural buffer boxes on their own. One stack of input and one stack of output. Isn't that enough buffer for you?

because beltboxes don't make things available to bots, doi.

Unless beacons prevent you from having the space you move the stacked items with bots and unstack at the assembler. Saves a ton of bots. Anyway, with the suggestion you wouldn't unstack for the assembler so the point is mood.

and how do you suggest the bots get access to the stacked item?

Miner / furnace / assembler with output set to "compressed" filling a provider chest.

mrvn wrote: Tue Aug 11, 2020 3:23 pm

ptx0 wrote: Tue Aug 11, 2020 1:49 pm

mrvn wrote: Tue Aug 11, 2020 11:07 am

ptx0 wrote: Mon Aug 10, 2020 7:16 pm

mrvn wrote: Mon Aug 10, 2020 4:42 pm Not sure why. Beltboxes are natural buffer boxes on their own. One stack of input and one stack of output. Isn't that enough buffer for you?

because beltboxes don't make things available to bots, doi.

Unless beacons prevent you from having the space you move the stacked items with bots and unstack at the assembler. Saves a ton of bots. Anyway, with the suggestion you wouldn't unstack for the assembler so the point is mood.

and how do you suggest the bots get access to the stacked item?

Miner / furnace / assembler with output set to "compressed" filling a provider chest.

deadlock's stacking beltboxes are furnaces. i use a loader to get things out of it, and another loader to push it into the chest. so this comes full circle back to my initial statement that some inline entity that behaves like two loaders, compressing items that pass through, would be really nice! it can work sorta like a one-sided splitter.

Granted. But a) completely out of scope of this suggestion b) forgetting, that the loaders in deadlocks mod can be placed over “edge”, which enables nice puzzles.

ptx0 wrote: Tue Aug 11, 2020 6:25 pm

mrvn wrote: Tue Aug 11, 2020 3:23 pm

ptx0 wrote: Tue Aug 11, 2020 1:49 pm

mrvn wrote: Tue Aug 11, 2020 11:07 am

ptx0 wrote: Mon Aug 10, 2020 7:16 pm

because beltboxes don't make things available to bots, doi.

Unless beacons prevent you from having the space you move the stacked items with bots and unstack at the assembler. Saves a ton of bots. Anyway, with the suggestion you wouldn't unstack for the assembler so the point is mood.

and how do you suggest the bots get access to the stacked item?

Miner / furnace / assembler with output set to "compressed" filling a provider chest.

deadlock's stacking beltboxes are furnaces. i use a loader to get things out of it, and another loader to push it into the chest. so this comes full circle back to my initial statement that some inline entity that behaves like two loaders, compressing items that pass through, would be really nice! it can work sorta like a one-sided splitter.

I know they are furnaces. But you missed the point that you already have a miner / furnace / assembler before that which fills the belt in the first place. You set the output of that to compressed and the need for a beltbox goes away. What you will be left with is just a loader into a buffer chest.

mrvn wrote: Wed Aug 12, 2020 10:41 am But you missed the point that you already have a miner / furnace / assembler before that which fills the belt in the first place. You set the output of that to compressed and the need for a beltbox goes away. What you will be left with is just a loader into a buffer chest.

Good point. Never thought to that, even if that is so obvious.

well if that's out of scope, then i guess i change my mind. none of this really needs to be integrated into the base game engine at all. stacking is fine the way it is implemented now, via mods.

ptx0 wrote: Thu Aug 13, 2020 5:59 am well if that's out of scope, then i guess i change my mind. none of this really needs to be integrated into the base game engine at all. stacking is fine the way it is implemented now, via mods.

Not sure what you mean. If nothing changes then you ARE left with the loader -> beltbox -> loader -> loader -> chest design. Would be nice to reduce that.

ptx0 wrote: Thu Aug 13, 2020 5:59 am well if that's out of scope, then i guess i change my mind. none of this really needs to be integrated into the base game engine at all. stacking is fine the way it is implemented now, via mods.

Yes, +1.

mrvn wrote: Thu Aug 13, 2020 11:56 am

ptx0 wrote: Thu Aug 13, 2020 5:59 am well if that's out of scope, then i guess i change my mind. none of this really needs to be integrated into the base game engine at all. stacking is fine the way it is implemented now, via mods.

Not sure what you mean. If nothing changes then you ARE left with the loader -> beltbox -> loader -> loader -> chest design. Would be nice to reduce that.

because your solution is already applied via omnicompression with the compression planner tool that allows setting an ore patch to output compressed ore.

ptx0 wrote: Thu Aug 13, 2020 11:02 pm

mrvn wrote: Thu Aug 13, 2020 11:56 am

ptx0 wrote: Thu Aug 13, 2020 5:59 am well if that's out of scope, then i guess i change my mind. none of this really needs to be integrated into the base game engine at all. stacking is fine the way it is implemented now, via mods.

Not sure what you mean. If nothing changes then you ARE left with the loader -> beltbox -> loader -> loader -> chest design. Would be nice to reduce that.

because your solution is already applied via omnicompression with the compression planner tool that allows setting an ore patch to output compressed ore.

Ok, so miners are covered, nice. Now find us something for the assemblers and furnaces that doesn't mean duplicating all the recipees.

But that’s part of this suggestion...!?

mrvn wrote: Fri Aug 14, 2020 2:50 am
Ok, so miners are covered, nice. Now find us something for the assemblers and furnaces that doesn't mean duplicating all the recipees.

you'd have to demonstrate how this is even a problem that needs to be solved.