Friday Facts #128 - Back down to earth

[Nemoder]

I think it would be overpowered.
If the main goal is to make train unloading more viable why not make a special building that only works when unloading directly from trains?

[Supercheese]

If anything, I'd rather it expands into a new system: Make chests movable by belts (much like how you can move a car around in the belts), with a crane (an "inserter" of sorts) capable of placing said crates in and out of the belts; plus crate wagons. Thus the loader would become a packager of sorts, kinda like how the assembly fills and empties crude barrels: keep it stocked with crates when packaging, take out the empty crates when unpackaging, all this with inserters.
---
EDIT: Just found out that ske already proposed something like this:

Instead of chests, we could load "containers" which could be moved around. In extension to this idea I could think of a whole set of new "heavy" equipment (let's call chests containers here):

• The heavy inserter moves containers around.
• The heavy belt transports whole containers.
• The containers waggon moves them by rail.
• The heavy robot shaped like one of those army helicopters transports a container from one place to another. (Still, keep throughput much lower than land based equipment.)
• The heavy furnace/assembly machine for bulk processing takes whole containerloads of items like iron ore and outputs containerloads. (Then increase the amount of ore we need to process for one plate by 10x.)

Obviously the heavy equipment would be bigger in size (4x4 or 5x5?) and consume more power but provides much higher througput per area. Limiting containers to one kind of item (one single huge stack) might be necessary and also makes sense.

Will have to agree with the "heavy duty" belt, it does sound nice; although the heavy duty furnaces and assembly machines would detract from the packaging/unpackaging I had in mind...

This is actually a fascinating idea and I believe it can be implemented given the current modding interface... hmm...

[Redominus]

Sarcasm:
Because the magic of factorio is complex builds remove blueprints because those make building train unloaders a chore.
/sarcasm
TBH unloader are a great addition for big basses in late game. One entity vs dozens is going for the frame rate. Just put the tech way before blueprints.

[kikass]

Loaders, NO.


You can achieve the same functionality with inserters. You just have to think twice to get a better (more optimized) result.

Mods with 90° Inserters, Extra Long Inserters, Near Inserters and Ultra-speed inserters allready exist, add them to the vanilla game and youll be fine.

The robots actually make teh game far to easy and remove a high chunk of the early to midgame complexity.
The game is eassy, even producing millions of copper and metal is way to EASY (if you just play the game (puzzle around))

The point is, even if its "easy" and "mostly obvious" to achieve a better result, you have to tech (or gear up) for it and it is satisfying to do so.

its not that hard to create a HIGH density Ore/Item Line ... dont ruin the game by destroying the core mechanics.




EDIT:

i like the idea of movable Containers though. This wouldnt require a massive change in your codebase either because all mechanics exist atm


Youll have to place a 3x3(small) 4x4(big) loader structure with 2 belt connections. These Loaders work on intersections and can be configured to input contents from 1 Side and Containers from 2 other sides(kinda like a T-shaped intersection).

You have to provide Containers (from left to right or right to left(configurable in gui or defined by Belt direction)) which the loader will fill up on a specific condition (configurable in gui of the loader).

If the End Condition is true (configurable in gui), the loader will push the (now filled) container out onto a normal transport belt.
The Same Setup can be used while unloading the containers (configurable in the loader itself).

The Containers work like the Power Armor and the items like the Player Modules. Every Item has a specific "size", so the items in the container wont Stack normally (like chests do). Instead theyll use a Volume approach(due to the fact that this is a 2d Game you can also achieve that by taking the 2d Area ... 1x1, 2x1, 2x2 ect )

The Small Loader is 3x3 Tiles big, so a small container (1x1) will filla whole transport belt and will be connected in the middle of the loader.
The big Loader size is 4x4, so big Containers (2x2) will fill two transport belts at once and will be connected in the middle of the loader..


Ive drawn a picture (dont judge my paint skills) for better representation, even if its not that complicated

[teqqra]

Loaders, NO.!


Thanks for all the fun im having with this game!

[ivosh]

I would preffer to have "double-inserters" instead. It would have 2 arms, each would load one side of belt. Smart-double-inserter could be setup per-arm, so you could specify which resource should be loaded to which side of belt.

You could also add faster class of inserter, with more arms alternating for same work on same side of belt (for example when one arm puts resource on belt, another one is at the same time already picking next resource from the chest).

[V453000]

Loaders, NO.

movable Containers though....

Youll have to place a 3x3(small) 4x4(big) loader structure with 2 belt connections. These Loaders work on intersections and can be configured to input contents from 1 Side and Containers from 2 other sides(kinda like a T-shaped intersection).

You have to provide Containers (from left to right or right to left(configurable in gui or defined by Belt direction)) which the loader will fill up on a specific condition (configurable in gui of the loader).

If the End Condition is true (configurable in gui), the loader will push the (now filled) container out onto a normal transport belt.
The Same Setup can be used while unloading the containers (configurable in the loader itself).

In this thread I love three ideas. First one is the raw ore hoppers for trains - DAMN, industrial train stations! , second one is the lubricant consumption and pipe requirements (even though I think it should be used for more high tech things for consistency), and the third one is this container thing.

Effectively putting items on top of each other on belts thanks to stuff like containers sound like:

* an excellent way to apply inserter stack bonus to belts (inserter could pick up multiple items from the container)
* a very interesting way to add complexity to belts later on in the tech tree (I would place it somewhere to lvl2 logistics on the level of trains)
-- I am thinking it would be a container of a size of 2x2 items on belt, that way it would always fit on 1 belt (I can't think of a way to make it work nicely with 2 belts)
-- it would also add a new entity like a container re-router (it would split only the containers from the belt, normal items would continue on the belt) - on normal splitters it would get stuck and it would have to be moved by this re-router(question is how it would work with underground belts, could do the same thing - get stuck)
* definitely not OP as 1 container could only carry 1 item type , and would require extra treatment due to splitter/underground limitations
* if done right, it should look amazingly industrial
* perhaps the loader should fill them, indeed

However, I think making containers like 2x2 or more tiles, is just going way too far, and the solution would be come very clunky.
I don't think making them as individual as a power armor is a good idea. Just make it carry only 1 item type, depending on which item is inserted first. No extra setting up, no extra gui.
You can imagine the item slots like levels, first all 4 item slots are filled, and each slot can have, say, 4 stacks - that way you effectively quadruple the belt efficiency if you take that extra step and build the infrastructure necessary for containers. But with regards to not using UG belts or splitters for them.

The container idea would be worth more thinking tbh, I think it has great potential but one has to be careful with it.

My thoughts

V

[ssilk]

BTW:

There is a suggestion thread:
viewtopic.php?f=6&t=20874 Contributions to "Loader" idea

Just for completeness of this discussion.

[Sensei]

Chalk one more vote up for the "I like loaders, but they should have lubricant as an ingredient" camp.

[ssilk]

@Kovarex: From the sight of a moderator I would like to suggest you that you select the most promising ideas from this thread (or others): show the direction you want to go for now. That can be changed later, but for now it makes sense to do it like so. Maybe you already did that with viewtopic.php?f=38&t=20847&start=110#p131135 - but I think that kind of response is not clear for everybody.

Cause (also seen as moderator) I fear, that every owner of Factorio has an own opinion about this (even myself ).

Well, I think that is currently not a problem - it reveals, how everybody wants to play this game... But it just doesn't make sense to wait until everybody has told his opinion; that breaks the discussion, if we have a thread with 50 pages; nobody can read that anymore and many people have put some of their time into this and it's useless time. I want to avoid that.

This would help the community to concentrate more into the "right direction". See it as a chance to control the community to think for you.

[tecxx]

i agree with the guy who posted that the "inserter minigame" is overrated. factorio becomes tedious after a while, once you have done your personal "perfect" factory several times, it's not that challenging anymore and you're craving for something else. mind you, factorio is great, but after a good year and a half i'll pause and will come back once something radically new comes to the game (still hoping that future development brings more openttd style elements
besides of that - congrats on the steam launch!

[sillyfly]

@Kovarex: From the sight of a moderator I would like to suggest you that you select the most promising ideas from this thread (or others): show the direction you want to go for now. That can be changed later, but for now it makes sense to do it like so. Maybe you already did that with viewtopic.php?f=38&t=20847&start=110#p131135 - but I think that kind of response is not clear for everybody.

My opinion is that the best thing they can do now is wait and think about it. There will be more discussions the following days, maybe they'll discuss it in the office, and everyone will be able to come to terms with the ideas. Maybe they would try a few games in the office and see how it changes the game-style.

I don't think there will be any harm done if we only hear official word about this in the next FFF (or even in two or three FFFs).

[MeduSalem]

I would preffer to have "double-inserters" instead. It would have 2 arms, each would load one side of belt. Smart-double-inserter could be setup per-arm, so you could specify which resource should be loaded to which side of belt.

You could also add faster class of inserter, with more arms alternating for same work on same side of belt (for example when one arm puts resource on belt, another one is at the same time already picking next resource from the chest).

I somehow find that idea quite interesting, though the consent about it will most likely be "could be modded" or something like that because of how discussions about more diverse types of inserters normally end up with hordes of zombies entering the thread moaning "mooooodssss" in resemblence of "braaaaaainssss"


Also to be honest I would have removed Long handed inserters etc already.

Instead I would have regular inserters become more sophisticated with an integrated UI in which one can set following settings:

• How far it reaches out (1 or 2 tiles for the most part, taking the job of long handed inserters as an option, at the cost of speed or energy consumption)
• Angle to operate in with 45° steps. Not only 90°/270° inserters would be covered but diagonal angles too. It could be displayed graphically in the UI with a circle. (the angle would also influence speed and energy consumption)

And possibly some other stuff too. Most of which is covered in various threads on the suggestion board as well as mods section.

[edit]

Made a quick sketch of how the "circle" I mentioned above could easily be used as a tool to adjust the inserter to work in almost any way desired (not only angles, but also the reach):

Inserter

Inserters.png (89.56 KiB) Viewed 6253 times

[Koub]

Effectively putting items on top of each other on belts thanks to stuff like containers sound like:

* an excellent way to apply inserter stack bonus to belts (inserter could pick up multiple items from the container)
* a very interesting way to add complexity to belts later on in the tech tree (I would place it somewhere to lvl2 logistics on the level of trains)
-- I am thinking it would be a container of a size of 2x2 items on belt, that way it would always fit on 1 belt (I can't think of a way to make it work nicely with 2 belts)
-- it would also add a new entity like a container re-router (it would split only the containers from the belt, normal items would continue on the belt) - on normal splitters it would get stuck and it would have to be moved by this re-router(question is how it would work with underground belts, could do the same thing - get stuck)
* definitely not OP as 1 container could only carry 1 item type , and would require extra treatment due to splitter/underground limitations
* if done right, it should look amazingly industrial
* perhaps the loader should fill them, indeed

However, I think making containers like 2x2 or more tiles, is just going way too far, and the solution would be come very clunky.
I don't think making them as individual as a power armor is a good idea. Just make it carry only 1 item type, depending on which item is inserted first. No extra setting up, no extra gui.
You can imagine the item slots like levels, first all 4 item slots are filled, and each slot can have, say, 4 stacks - that way you effectively quadruple the belt efficiency if you take that extra step and build the infrastructure necessary for containers. But with regards to not using UG belts or splitters for them.

The container idea would be worth more thinking tbh, I think it has great potential but one has to be careful with it.

My thoughts

V

I thought of an even simpler (I think) way to put things :
- Only one slot
- Only one item type
- Maximum of stacksize
- 1x1 size item

It would behave like a single item, but would contain a stack.

Just by that, you'd become able to carry via belt stacksize x more items at full density, with no change to how belts work.

[Guest_4544]

A loader huh? Very nice, I'd say when that thing got a majority vote of no, at least give the modders a option to add the thing by themselves, so that some users who wants it can get it via mod instead.

[Koub]

A loader huh? Very nice, I'd say when that thing got a majority vote of no, at least give the modders a option to add the thing by themselves, so that some users who wants it can get it via mod instead.

There's already a mod called slipstream chests that does exactly that
viewtopic.php?f=93&t=7121

[Dranzer]

I'm not super keen on the idea of a loader as a situational souped-up inserter. How about this instead:

The loader is a 1x1 container with a single item slot, a front, and a back. If you attach a belt to the back end, it eats the contents as efficiently as the belt can feed into it. If you attach a belt to the front end, it dumps its contents as efficiently as a belt could. It does not empty or fill containers by itself. It is simply a small container that can be directly fed by, or feed into, a belt. Its key purpose, then, becomes a tool to facilitate the inserter stack size bonus when being used with belts. In this sense, it would be a tool which builds off of inserters, rather than simply replacing them in certain contexts.

Perhaps make them a part of the logistics tech, one for each belt speed, with loading/unloading speeds that correspond to the three belt tiers?

[Powderking]

I have a screenshot of what I would want the loaders for:



This is the connection of my iron smelting to the "distribution backbone roboport area".
On the top left you can see that I use several requester-inserter-provider (RIP) groups.
The requesters are located on the border tiles of the iron smelting and the providers are in the distribution area. There is a similar traversing system into the steel smelting area adjacent in the north to the iron smelting area. So the iron plates get carried to both the backbone in the west and the steel area in the north.

[Koub]

Isn't this design a little inefficient ?

[MeduSalem]

Isn't this design a little inefficient ?

Nope. It is actually brilliant to do it that way because the seperated robot networks prevent the robots from going all over the place, thereby preventing a lot of chaos and delay (depending on recharge problems, storage chest problems etc). It helps a lot in channeling bot efficiency.

I am using such a thing too quite often if I don't want the robots to leave a certain area or if I have a certain storage system in mind which I don't want to be interfered/spammed with items that don't belong there. The storage chests in the seperated network will never get spammed with items from god knows where

There seems to be huge priority problem when it comes to Storage chests where the bots don't try to fill up the closest storage chest first but instead in the order they were placed down. Don't know if it is a bug or not but the problem becomes severe the bigger the factory, which is why seperate logistic networks are the only way to counter the problem.

Since we aren't able to have multiple subnetworks within the same logistic network (with color coding or whatever) the above contraption is the closest we can get to that currently.

The only downside is that if you want the contents of the logistic network to be carried over to another logistic network you have to hardwire stuff with circuit networks, but most people don't play around with that kind of stuff anyways.