Factorio Forums

In my opinion loaders are too easy, too perfect and too boring solution. They take away fun from engineering of practical and efficient belt systems.

I do no resist them, because there seems to be much demand, but I do not see a situation in which I would use a loader.

Ok, so after drooling over Zeblote's loader graphics, I decided to take a crack at it.

This design borrows *heavily* on the Angel Logistics Mod (respect and credit to Arch666Angel!), but what drove me nuts is how clean those loaders looked. There were some graphical issues as well, like lining up with belts, the length of certain loaders, etc. So I roughed them up a bit, extended some of the loaders and tried to make it my own. Here are the originals (again, respect to Arch666Angel and Angels mods in general... WOW) and here's what I came up with.

Angel's Logistics Loader Graphics My take... In Game... It certainly feels more "factorio" in my opinion, but would love to hear your comments. I felt the combinator arrows looked more authentic and that the loader should be more industrial (like thick). I tried as best as possible to match the color to the yellow on the underground belts. I loved the idea of the rivets and the raised "direction display", but I'm not as talented as so many of you out there. I'll upload the fast and express versions if there is interest.

With respect to the folks who don't like loaders, awesome! Community discussion is certainly pushing me towards circuit conditions and the "perfect" inserter setup. If only I had more time...

That's nice, but you need to get with the times and make HD graphics for those

Zeblote wrote:That's nice, but you need to get with the times and make HD graphics for those

What's interesting about that comment is the loader template isn't high res. If you try to incorporate the new graphics (from any new high res graphics) with the old, Factorio won't load. Tried to use the high res.

But I admit - I have no idea what I'm doing.

Well I've no idea how to set up high res graphics either, but it's probably as simple as changing the loader prototype to look for sprites with twice the size.

Loaders?
https://youtu.be/aVAxHHCdA4E
Yes, please...

That's exactly how I imagined them to be used

Yeah, can we make this happen in 0.15.8?

The Loader was abandoned because it's way to OP... Full compression and insta-collection have little to no gameplay value (no more throughput problems).

nemostein wrote:The Loader was abandoned because it's way to OP... Full compression and insta-collection have little to no gameplay value (no more throughput problems).

It's a funny comment. Loaders just don't want to die. I LIKE'EM!

Omarflyjoemacky wrote: My take...

loader.png

They would look really weird on sand.

Ok, final product. If anyone wants a copy, PM me. Thanks for the input from the various members.

Loaders are nice. They need some tweaks, but they have their specific niche in bulk throughput designs, and open up some opportunities for over-beaconized assemblers (which aren't terribly efficient, but space consraints might be a factor sometimes).

I'd say loaders need:

1. Removal of filtering ability, it doesn't make sense. Their job is the bulk throughput, not smart filtering.
2. Randomization of output. Again, a bulk item transfer device shouldn't be able to sort through item types in the chest it's emptying. So random items from the chest should be picked, not last ones in the chest's inventory. This will also give loaders a unique twist, as no other item in the game is capable of randomizing.
3. As an extension of randomization, there should be a small chance that loader will output nothing instead of an item. So if someone is concerned about belt compression, their precious designs will still be useful.
4. They should have separate hatches for left and right lane, controllable manually or by circuit network.
5. Loaders should be dumb. So if loader picked an item to output via it's right hatch, it shouldn't be able to change it's choice even if recipient doesn't accept this item. This can cause jams.
6. I completely disagree on the running cost issue. Splitters are doing a much more energy-intensive task, but I hear no objections against them. The entire belt system energy costs come from aether, why should loaders be different?
7. Cost for normal loaders is approximately between UG belt and splitter, but no electronic parts, it's a purely mechanical system.
8. However loader costs should escalate exponentially with their speed: fast loader should have a much higher cost relative to fast belt than normal loader to normal belt. Express loaders should bankrupt a small country be even more expensive.

Overall, loaders will take over inserters in mono-resource train stations, storage input/output and lanes merging into a faster lane. Lane splitting will still be more effective with a splitter. Their use in factories is meaningless with very few exceptions which inserters cannot handle anyway.

P.S. Oh, and another area where loaders would shine is pre-electricity gameplay. Regular inserters are not yet functional, burner inserters require too much work to setup, and doing everything manually gets pretty old pretty fast. Loaders fit into this nicely and resolve a lot of early-game issues.

Those are a lot of valid points. What I truly find interesting is that this discussion is still going on... and only 22% of users who voted said they shouldn't be implemented. How is their voice heard but ours were not? I'm trying to recall a recent FFF (or was it reddit?) where one of the developers said "that's the way it is, get used to it"... and the community did. It's not like everyone will stop playing.

Developers... 4 out of 5 users say put'em in! Finish the idea.

People will play the way they want to play, whether it's with biters or not, circuit conditions or not... hell - even my first few games were without trains because I didn't want to use them. It was a choice. To all the haters of loaders, don't use them. Some people play mega bases, some play tiny bases. It's all about choice.

klonan... kovarex? Please, finish the graphic, turn on the code and kill this thread.

Of course, they could respond to this with "that's the way it is, get used to it.". That would kill the thread too.

Omarflyjoemacky wrote:Of course, they could respond to this with "that's the way it is, get used to it.". That would kill the thread too.

That's bascially what they did when they implemented the Stack Inserters. Some people just can't get over it.

Lav wrote:1. Removal of filtering ability, it doesn't make sense. Their job is the bulk throughput, not smart filtering.
2. Randomization of output. Again, a bulk item transfer device shouldn't be able to sort through item types in the chest it's emptying. So random items from the chest should be picked, not last ones in the chest's inventory. This will also give loaders a unique twist, as no other item in the game is capable of randomizing.

Completely agree here.

Lav wrote: 3. As an extension of randomization, there should be a small chance that loader will output nothing instead of an item. So if someone is concerned about belt compression, their precious designs will still be useful.

No. The entire point is to load/unload a compressed belt.

Lav wrote: 4. They should have separate hatches for left and right lane, controllable manually or by circuit network.

What for? Doesn't this contradict with making them as dumb as possible?

Lav wrote: 5. Loaders should be dumb. So if loader picked an item to output via it's right hatch, it shouldn't be able to change it's choice even if recipient doesn't accept this item. This can cause jams.

Can't see where this would apply. The loader is always between a belt piece and a storage unit, so this will never happen unless you put the wrong things on the belt.

Lav wrote: 6. I completely disagree on the running cost issue. Splitters are doing a much more energy-intensive task, but I hear no objections against them. The entire belt system energy costs come from aether, why should loaders be different?

Same here. If splitters didn't exist already, would people also claim they're "OP"?

Lav wrote: 7. Cost for normal loaders is approximately between UG belt and splitter, but no electronic parts, it's a purely mechanical system.
8. However loader costs should escalate exponentially with their speed: fast loader should have a much higher cost relative to fast belt than normal loader to normal belt. Express loaders should bankrupt a small country be even more expensive.

The costs of making rarely-used items like loaders will always be negligible compared to making the other thousand belt pieces. We have millions of iron plates anyways

Zeblote wrote:

Lav wrote:3. As an extension of randomization, there should be a small chance that loader will output nothing instead of an item. So if someone is concerned about belt compression, their precious designs will still be useful.

No. The entire point is to load/unload a compressed belt.

We see it a bit differently then. I don't mind if loaders cannot perform to the level of a fully compressed belt - you can add an inserter or two to supplement the loader, or simply put a higher-level loader. Or split a blue belt into two reds and put two red loaders. There are options. But for me the loader is a bulk loading/unloading item primarily - a replacement for overcomplicated hordes of stack-inserters in a situation where simply dumping the entire content of a belt into container should have sufficed.

Zeblote wrote:

Lav wrote:4. They should have separate hatches for left and right lane, controllable manually or by circuit network.

What for? Doesn't this contradict with making them as dumb as possible?

This is mainly for controlling throughput. When unloading from a source where only one item type is stored, this also allows to create single-lane output easily. Finally, this allows to pick a specific lane from a mixed belt. Essentially, gives loaders a small (and realistic) degree of flexibility.

Zeblote wrote:

Lav wrote:5. Loaders should be dumb. So if loader picked an item to output via it's right hatch, it shouldn't be able to change it's choice even if recipient doesn't accept this item. This can cause jams.

Can't see where this would apply. The loader is always between a belt piece and a storage unit, so this will never happen unless you put the wrong things on the belt.

This can very much apply when loading into "picky" containers from mixed belts. Like wagons, or logistic chests, or factories. In other words, as soon as you need something more complicated than "dump everything from left/right/both lanes right there", you'll have to use inserters instead. Because otherwise, as soon as an inapplicable item gets randomly selected - whoops, you're stuck.

Zeblote wrote:

Lav wrote:6. I completely disagree on the running cost issue. Splitters are doing a much more energy-intensive task, but I hear no objections against them. The entire belt system energy costs come from aether, why should loaders be different?

Same here. If splitters didn't exist already, would people also claim they're "OP"?

Definitely. Because there would be dozens of inserter-based designs for splitting belt contents, and people would complain that introduction of splitters invalidates all of them. Totally OP, must introduce lubricant cost for sure.

But what cracks me up most is the positive reaction to the pumps being able to fill liquid wagons directly. Developers introduced a loader in disguise and the community ate it up and asked for more.

Lav wrote:

Zeblote wrote:

Lav wrote:5. Loaders should be dumb. So if loader picked an item to output via it's right hatch, it shouldn't be able to change it's choice even if recipient doesn't accept this item. This can cause jams.

Can't see where this would apply. The loader is always between a belt piece and a storage unit, so this will never happen unless you put the wrong things on the belt.

This can very much apply when loading into "picky" containers from mixed belts. Like wagons, or logistic chests, or factories. In other words, as soon as you need something more complicated than "dump everything from left/right/both lanes right there", you'll have to use inserters instead. Because otherwise, as soon as an inapplicable item gets randomly selected - whoops, you're stuck.

Hmm. But what's there to "randomly select"? If you have a mixed belt going into the loader, there's nothing random about it - it will load items in exactly the order they come on the belt. So if you have the wrong things on your belt, it's stuck.

Zeblote wrote:

Lav wrote:

Zeblote wrote:

Lav wrote:5. Loaders should be dumb. So if loader picked an item to output via it's right hatch, it shouldn't be able to change it's choice even if recipient doesn't accept this item. This can cause jams.

Can't see where this would apply. The loader is always between a belt piece and a storage unit, so this will never happen unless you put the wrong things on the belt.

This can very much apply when loading into "picky" containers from mixed belts. Like wagons, or logistic chests, or factories. In other words, as soon as you need something more complicated than "dump everything from left/right/both lanes right there", you'll have to use inserters instead. Because otherwise, as soon as an inapplicable item gets randomly selected - whoops, you're stuck.

Hmm. But what's there to "randomly select"? If you have a mixed belt going into the loader, there's nothing random about it - it will load items in exactly the order they come on the belt. So if you have the wrong things on your belt, it's stuck.

Hmm, makes sense. So that part of description was needlessly overcomplicated I guess.

IMHO it should be for loading only and interact only with chests and trains.

Power consumption is debatable.