faster storage hopper out transfer rate please?

[Jumping Spiders Are Cute]

i see almost no point in rapid zipper merges if storage hoppers dont transfer as fast.
my bottleneck for the longest time has been storage hopper transfer rate. i have plenty of ore, very fast smelting, tons of storage space, but my storage hoppers attached to my cargo lifts cannot transfer fast enough to even keep up with a single normal conveyor line.

strangely, storage hoppers transfer fast enogh to keep up with matter transmitters, but when a conveyor belt is attached, the speed is ♥♥♥♥ in comparison.

do not tell me to use mass storage. i do not want to have a mess of inefficient sorters everywhere, and i dont want indiviidual mass storage systems for each and every function i just need a need a fast storage hopper for.

dont tell me its my conveyor speed either. im using tricky's storage hoppers mod and the 2000 slot hopper can transfer fast enough to keep up with a ♥♥♥♥♥♥♥ transport pipe. which is funny because a normal storage hopper can easily keep up when recieving items.

i tried using tricky's 2000 with cargo lifts and it wont interface for some reason, otherwise they would be perfect for what i need. but they do save me in that they make it so i dont need needlessly space consuming storage hopper spam

but please, i would love to have storage hoppers output rate to at least match normal conveyor belts.

[Reaperrazor]

True, T2 I/O is more than enough in most cases, with T3 for the heavy duty hauling (bars usually). Frankly, Id rather use T2 minimum if I can help it. Still, when you finally learn how they work, they are so worth it. In fact the MS blocks are the first thing I ever truely automated. Was worth it too

[Jumping Spiders Are Cute]

storage of bars is no problem, as i have the infinite stack sizes mod and cannot live without it. i do see how automating EVERYTHING is awesome, but to properly do so would require you have mass storage in the very center of the base on the surface, and because the cph cannot be moved, it is not a good thing. my most thoroughly automated system right now is missile crafting, which pulls gold, copper and iron straight from smelting, into the required stuff and up a mk5 batery tower near the center and it is a hassle to get over the feed lines.

ofc, this may be because i have 8 launchers at the top but occasionally the enemies wil spawn from directly above the cph and instakill it. with 14 seconds per reload and a boss for nearly every two blocks of distance, they are essential.

point being, 12 lines running straight through the center of my base is like having to climb over a big log every time you go into your house.

im not gonna do that with everything unless mass storage is made available cheaper and easlier game, but that will never happen. plus, i dont really need it. by the time i can do it properly, everything important is done and there is nothing left to do but screw around.

although, thanks to tricky's mod, i have nothing else to complain about besides maybe the fact that ablators and liquifiers have a tiny range, but i will ask about this in another thread.

[steveman0]

If you have to run 12 lines of anything in your base it sounds like you need to work on your overall base layout. Mass storage makes it much easier to not have to run a lot of lines across your fortress since you can access items from anywhere around the storage. With clever sharing and stocking of items in adjacent storage you can bus items all around your fortress with very little conveyor clutter.

[DjArcas]

Jumping Spiders Are Cute a écrit :

matter transmitters are a hassle and not worth it in small spaces.

many times more cpu than the same amount of hoppers it requires to keep a transport tube saturated?

So, lemme get this straight, there's about 8 options you've got, and you've just complained about all of them? There's zero reason not to use motorised conveyors.

[Reaperrazor]

Frankly your resin farm should be in a reinforced box that is what no more than 30x30x30. That means depending on the feeding rate, you dont need more than 4 abalator/liquifiers pairs.

Also, bad idea to keep everything so dense in your base. Even worse to keep it all near the CPH. You should spread it out to a decent size to reduce clutter and coveyor belt frenzy. More than 3 lines in a small area (inlcuding branching AND other blocks) makes for logistics hell. If you know what your doin, your problem is set up time alone.

[Vici]

DjArcas a écrit :

Jumping Spiders Are Cute a écrit :

dont tell me the code doesnt work that way. if that were true, tricky would not have been able to make the hoppers in his mod keep up with a transport pipe. if a mod can do it without having any negative effects to the game, it is possible.

i tried using multiple belts on a hopper but it would not increase speed at all. it would either pick one belt or divide the speed between the two of them.

im currently using tricky's hoppers and wow. what a life saver. soon, i will have reduced the needless mess of hoppers down to one per item type instead of 4 or 10. it will probably increase my fps as well.

Tricky's approach uses up many times more CPU. That's fine for a mod, not fine for the main game. Use Motorised conveyors or Matter Movers if you need to strip the contents of a hopper in a heartbeat.

This (explanation for why it's not fine for the main game) seems off to me. I do agree that the main game should be as performant as it can, but in this case I see worse performance from this decision. The solutions seem to be:

1) Use multiple belts out of a hopper to simulate a motorized converor (as the initial poster has done, which I do as well as the cheapest option of these). This causes us to use those cpu cycle anyways with each extra conveyor as well as the additional computational resources each additional conveyor needs (memory, rendering the model, stack frames calling into the machine, etc.).

2) Use a machine that already invokes these CPU penalties (motorized conveyor, matter mitter). The motorized conveyor sounds like it's already doing exactly what the OP requested, except it takes power, which means you now have the CPU overhead of the machines required to transfer that power to the motorized conveyor. Matter mitter may be the most CPU performant as it can replace 64 conveyors with a single machine, but that can be lost if the additional power distribution infrstructure is too big.

3) Tricky's hoppers. Odd, since as a logistics game, you'd expect something to already provide perfect conveyor splitting. The turn table is too slow (or too easy to make it run slow) and hoppers are the discussion point. Maybe I'm missing something?

Did I miss a solution? Please let me know if I did. Honestly this feels like the Cobra Effect[en.wikipedia.org], where the solution actually makes the problem worse.

I'm looking forward to the priority splitter, though I kind of wish it was built into hoppers (allow a hopper to have a "priority out" side). I agree with the hassle of setting up matter mitter networks - I find setting up the power distribution to be tedious, and due to massive power requirements of the mitters, you're limited on your ability to chain before maxing out the power you can push through before needing another power branch.

It's been awhile since I've looked at the code, some of my above assumptions may be off, and please correct me if they are.

[steveman0]

Vici a écrit :

DjArcas a écrit :

Tricky's approach uses up many times more CPU. That's fine for a mod, not fine for the main game. Use Motorised conveyors or Matter Movers if you need to strip the contents of a hopper in a heartbeat.

This (explanation for why it's not fine for the main game) seems off to me. I do agree that the main game should be as performant as it can, but in this case I see worse performance from this decision. The solutions seem to be:

1) Use multiple belts out of a hopper to simulate a motorized converor (as the initial poster has done, which I do as well as the cheapest option of these). This causes us to use those cpu cycle anyways with each extra conveyor as well as the additional computational resources each additional conveyor needs (memory, rendering the model, stack frames calling into the machine, etc.).

This is pretty minor compared to making all hoppers do 6 times as much work when only maybe 1 in 10 actually even need more than 1 output conveyor. Also, from a performance point of view conveyors are incredibly efficient. Many times better than a hopper. A few extra belts are irrelevant.

2) Use a machine that already invokes these CPU penalties (motorized conveyor, matter mitter). The motorized conveyor sounds like it's already doing exactly what the OP requested, except it takes power, which means you now have the CPU overhead of the machines required to transfer that power to the motorized conveyor. Matter mitter may be the most CPU performant as it can replace 64 conveyors with a single machine, but that can be lost if the additional power distribution infrstructure is too big.

Actually, the motorized conveyor works on entirely different principles which is why it isn't a performance issue.

[Jumping Spiders Are Cute]

as i said before, i TRIED using multiple belts out of a single hopper, but even when said hopper was full and being filled(by a cargo lift) the hopper did not split the time between the belts, only one belt would be used at a time, this has happened across EACH situation where i tried it and i have yet to see any base game hopper work like this. only tricky's hoppers do from my experience.

and no, arcas. the 9th solution is to put more effort into optimizing a storage hopper so that it is consistent with the rest of the system. why cant hoppers work like conveyor belts? it isnt something simple like "if x = a, b"? storage hoppers dont even have an animation. this system must be incredibly screwy for 8(one side must be touching the thing the hopper is pulling from, and it requires 8 hoppers on four sides, one to pull from the hopper and one to put onto the main belt) conveyor belts to have less of a performance impact than a single, faster storage hopper.

i have maybe 30 2000 slot storage hoppers running at least one tube line from them at full blast and my fps went up by 3, which isnt much to most people, but for me with my usual 3-7 fps when im in my base, it is a godsend, because it reduced the sheer number of polys it required to store my pcbs, plates, wires, coils, and all that. ofc, this is due to my overcrafting that 1 out of every 4 items stored required 2-3 storage hoppers to hold it all, but regardless, it reduced the mess down to ONE PER TYPE instead of 2-3 per type.

it also reduced 2 extractors, 3 zipper merges, a turntable, 12 hoppers and 4 conveyor belts per lift to 1 extractor AND TWO STORAGE HOPPERS per lift. you cant tell me my previous method had less performance impact than my current, unless storage hoppers are stupidly unoptimized.

motorized conveyors would require i redesign everything so that I HAVE TO RUN EVEN MORE POWER LINES through everything that uses a storage hopper. no.

i have said it many times, i will not deal with janky, inefficient sorting monstrosities i saw what tango built in tango's tutorial and that thing is a logistical nightmare compared to simply placing the lifts directly above the vein and running lines from the top of the lift to smelting system, which by the way reduced my bar storage from 10 hoppers to 2(which holds 4 times as much as my normal 10 hoppers per bar type. i understand this is unbalanced, but it increased my fps by 3 like i said, which is like you all getting a +20 fps increase.

hold on, i said INCREASE, didnt i. i certainly did. that would mean a faster storage hopper system is less taxing than multiple belts. this is true because my system most of all would feel the negative effects because i probably have the weakest machine. even a nudge in the negative i would feel. yet i do not.

the hivemind i am dealing with is one that has been growing since the start of my lithium extraction. i accidentally left a section of the line unprotected and did not notice a hivemind 50 blocks from my cph until it was 20 blocks above ground, and so i have kept it as my pet. i lost the need for lithium long ago and so im just letting it eat all that comes out of it(i have storage of 12k bars so im good) and i have many self-sustaining farmers keeping it at bay. in fact, i will probably just post screenshots of it on another thread.

[Munda]

Jumping Spiders Are Cute a écrit :

i have maybe 30 2000 slot storage hoppers running at least one tube line from them at full blast and my fps went up by 3, which isnt much to most people, but for me with my usual 3-7 fps when im in my base, it is a godsend, because it reduced the sheer number of polys it required to store my pcbs, plates, wires, coils, and all that. ofc, this is due to my overcrafting that 1 out of every 4 items stored required 2-3 storage hoppers to hold it all, but regardless, it reduced the mess down to ONE PER TYPE instead of 2-3 per type.

What are you storing 60,000 of where you need that many 2000 slot hoppers?

[Jumping Spiders Are Cute]

i said it based on an esitmate of total number of 2000 slot storage hoppers in my base. i use them nearly everywhere because they allow me to easier control the amount of something i want to place in a hopper more easily, have extremely fast output rate, have the ability to restrict what gets put into the hopper as well as having enough storage space for anything i want. this means ive replaced almost all of my normal storage hoppers with 2000 slot hoppers because why tf not?

[steveman0]

So basically, they allow you to trivialize many of the game's challenges?

Jumping Spiders Are Cute a écrit :

it isnt something simple like "if x = a, b"?

http://e.lvme.me/pzv5j7l.jpg (FYI, the storage hopper, perhaps right behind the conveyor, is one of the game's most optimized machines.)

In general it sounds like you've got layout issues in general. Probably don't have very efficient manufacturing lines if you're relying on several hoppers to do anything. 100 slot hoppers should be good for just about anything. If you find you need more than this it's probably because you're doing it a very odd and inefficient way. Seems rather than build a better design you've just thrown the entire problem out the window with cheat hoppers.

Your FPS is also a sign of a cluttered mess. Unless you're running on a potato, the only way you can get to below 10 FPS would be to mash everything into one space rather than spreading out and building compartmentalized systems.

[epgeek]

Maybe a screenshot of a multi-face output will help?

http://steamcommunity.com/sharedfiles/filedetails/?id=1309370776

(note image is from P15 era.)

Later setups, once power wasn't a concern, just used powered conveyors to keep things simple and compact.

http://steamcommunity.com/sharedfiles/filedetails/?id=1309373175

TangoTek played on a very early version of FCE, before there were cargo lifts, even. He certainly was not an expert on FCE, and didn't seem to do any maths before making that clusterfck of a sorting system to deal with his mixed bars. There are number of more reent LPs on youtube by legit FCE experts, though I'm only familiar with Flexible Games' LPs.

[Jumping Spiders Are Cute]

i wouldnt use cheat hoppers if regular hoppers were just FASTER. like, ♥♥♥♥ you couldnt just make a separate, faster hopper for the base game instead of changing the existing ones? like, sure a mk5 battery may have more power, but it is also more polys than a mk4. as do minecarts compared to transport tubes, yet, the performance impact was completely ignored. does everyone use minecarts? no. but do they have a bigger impact on performance vs transport tubes? yes, yet you still have them added.

my fps is only due to the fact that i am running a potato computer.

i only have three manufacturing lines, one for advanced machine blocks, one for alloyed machine blocks, and the big one for missile crafting. i do not have them set up with manufacturing plants though, if thats what you are talking about. i just add bars to the lines and they make what i need, which is too various to have a line for all the uses.

[Vici]

steveman0 a écrit :

Vici a écrit :

This (explanation for why it's not fine for the main game) seems off to me. I do agree that the main game should be as performant as it can, but in this case I see worse performance from this decision. The solutions seem to be:

1) Use multiple belts out of a hopper to simulate a motorized converor (as the initial poster has done, which I do as well as the cheapest option of these). This causes us to use those cpu cycle anyways with each extra conveyor as well as the additional computational resources each additional conveyor needs (memory, rendering the model, stack frames calling into the machine, etc.).

This is pretty minor compared to making all hoppers do 6 times as much work when only maybe 1 in 10 actually even need more than 1 output conveyor. Also, from a performance point of view conveyors are incredibly efficient. Many times better than a hopper. A few extra belts are irrelevant.

Perhaps a compromise then - instead of making all hoppers max their output rate, make a new hopper that's specifically designed for this (that isn't a mod)? While I agree we don't need all hoppers maxing their output all the time, there are definite logistic advantages to doing it in a few places. As a player, I don't want to build multiple conveyor belts out of a single hopper, It feels jankity and lessens the fun I'm having, and does have a increase on the load on my machine. It doesn't matter how efficient something else is if it's negated by building even more of that efficient thing.

By chance, do you have numbers for how efficient each machine is (along with how many of each machine a typical world has) to compare to? Might be a better determiner if this request should be fulfilled or ignored.

steveman0 a écrit :

Vici a écrit :

2) Use a machine that already invokes these CPU penalties (motorized conveyor, matter mitter). The motorized conveyor sounds like it's already doing exactly what the OP requested, except it takes power, which means you now have the CPU overhead of the machines required to transfer that power to the motorized conveyor. Matter mitter may be the most CPU performant as it can replace 64 conveyors with a single machine, but that can be lost if the additional power distribution infrstructure is too big.

Actually, the motorized conveyor works on entirely different principles which is why it isn't a performance issue.

Does that "isn't a performance issue" statement include the additional power infrastructure that gets set up with it? It's great that it is so performant, but if it's saddled with additional overhead requirements that negate that performance gain, it kind of defeats the purpose.


Oh! An efficiency idea - replace many machines with a single (expensive) machine that performs the same function (probably multiblock?). i.e. instead of having 18k conveyors (which probably are bogging down my CPU/GPU no matter how efficient they are), let me replace them with a few 10s / 100s... matter mitters? Item teleporters? ... something. Same with power distribution; late game I have lasers / conduits going all over the place, often in parallel simply because there's nothing higher I can upgrade to pump more power into.

[Vici]

steveman0 a écrit :

So basically, they allow you to trivialize many of the game's challenges?

I like this game because of the logistic challenges it presents, but I think the problems Jumping Spiders is encountering is less natural to logistical problems and more artificial to the game implementation in that the necessary logistic tools don't exist (in this case adequate saturated line splitting with variable outputs) and the solutions encourage more machines.