Although I haven’t read everything here, I tried to get the gist of what Cliff has replied to.
I think that if we added in the local only/preferred/any behavior Cliff described as “resource management” along with improvements in how stockpiles handle the resources, then yes I would think the current conveyor behavior would be fine to keep. When I look carefully at the problems I’m running into, it usually isn’t so much a result of import behavior being broken, or conveyors working unpredictably, but rather that the stockpiles don’t seem to work very well. Fine-tuning the stockpile behavior should help with a lot of this.
I’ll be honest, I don’t really see any improvement to the speed of either the imports or the conveyors when the research for those improvements are taken. If the improvements are only marginal, like 10% for each, maybe those should be changed. Speed everything up as it comes in.
In my megafactory, where basically everything is connected to everything and I’ve tried to set it up where it goes import -> manufacture -> assemble, with (theoretically) manufacturing outpacing the needs of assembly, I am still only maxing at out 60% efficiency, with about 35% inefficiency due to waiting for components. A lot of these are servos and other things I can’t manufacture, sure. But I really don’t see any way with the current system to reach higher than 60% with the car flow I have on the small map. I really don’t want to have to game the system by making a custom map with imports every-other-square, it seems like the default maps given with the game should represent the “vanilla” challenge and be the basis on which the overall performance is judged. On those standards, the game is failing somewhere.
Of course my factory has like $50M so obviously I’m not losing in that sense, but money is a doddle so the real challenge from my perspective is throughput and efficiency.
I’d have to disagree - if the factory is as good as it can be, then nothing has failed, you’ve just reached the limits of the map (i.e. with that configuration of Importers and Exporters.
If OTOH someone else has built (on the same map) a more efficient factory with higher throughput, etc, then you may be able to modify your design to equal or better it.
To me the problem is importers, not resource conveyors.
Until importers are completed I think resource conveyors are always going to be lacking.
Thats why I suggested that “load sharing” mechanic for importers.
Right then! I have basically been doing this today, and here is how it looks so far. I haven’t tested it yet, but how does this look to people? Better?
This makes me think we may need some kind of ui feedback for when a particular importer is overloaded so we can adjust these values. Can we get like a graph of how often an importer peaks at 100% load?
Another idea is you could color code the different import types so you know which importer is local etc, because in the center of maps this could be more difficult to trace the problem.
… so at all a window with settings that I could use in previous game versions just by intelligent placement of stockpiles, importer, manufacturing slots and production slots. But it will not make it impossible to arrange everything like now?
One thing I find being an issue is that the Importers just don’t order fast enough. I have to have my lines literally beside the door for the resources to get there before they run out (Valves, wheels, tires, doors, windows). A solution I propose is the ability to manage how often a stockpile orders parts. I often find the line runs out because the parts are still on their way to the stockpile. They were ordered when there was still parts, but it emptys before they get there.
So I would like to see A GUI on the actual build stages that allow you to set when it actually orders new parts. Like a slider that forces the stockpile to order 4 more valves after the first 4 are used, and not as the last 4 are being used. This would, of course be unlocked through R&D, like the other options mentioned.
I also really like the idea of the 3 different colour importer lines. But Don’t assign them for certain uses. Code them to never attach to each other, and the only place they can be on the same block is on a stockpile storage input/output.
Ok… in testing the new stuff I have finally realised a big reason why people may be having issues…
When the ratio of resources required by a slot changes, the game never rebalances its resource demands…
So say you are building windows and have 16 windows in the stockpile… You then upgrade to electric windows which requires servos…
The game orders a servo, destroying one of the windows to make room. Awesome!.. but now there is no mroe room until a window is made, freeing up 2 stockpile spots…
At this stage the game orders 1 more window, and 1 more servo…and the cycle continues.
Clearly the code needs the C++ version of ‘hang on a minute, we have more windows than servos and we should have equal numbers, lets hold off on the darned windows for a while!’
So I intend to code that…then release the next patch
Yeah that’s also one of the issues… but there are several issues coming together I think.
Slot Stockpiles not balancing requested resources out well (just like you pointed out Cliff)
Making Components in-house often doubles the resource demand for a single component, easily overwhelming resource importers that were sufficient before one started to make stuff oneself.
A lot of Slots often gang up on the same 2 nearest Slots (due to how each slot only checks the 2 nearest ones) and it requires tricky resource conveyor layouts (separating the resource flow) to overcome the rising queue issue.
So even with the options for a slot to only take from a make component slot instead of importing them it would eventually end up problematic: All make component slots again gang up on the same few resource importers and even more ugly because they often double the resource requirements…
Like for example from 1 Wheel to 2 Steel… 1 Tire to 2 Rubber. And all of a sudden instead of importing 8 Wheels you have to import 16 Steel, instead of importing 8 Tires you are importing 16 Rubber, etc.
Even if you don’t make the components yourself… bigger factories have 4-8 slots Fit Wheel slots for example… routing all the stuff there through only 2 Resource importers is impossible… and if they all gang up on the same 2 importers then not even a stockpile will help.
So eventually the true bottleneck is the resource importers and how queues are handled.
I agree. My solution for this problem was to place a stockpile somewhere it will prefered by the production or manufacturing slot but will pull all the requested items from a different less used importer. It’s a nice workaround but chellenges the game mechanics (which source is why preferred, how will expands to the production line influence the existing chains, …)
But at all it’s as MeduSalem said: Fighting either with the price of the components or the overwhelming number of base materials you need when making the parts inhouse.
I’d also like to talk about resource conveyors but in a different way. I’m not sure if to put this here or in suggestions so here goes.
On the topic of the resource conveyors, why are they limited to one “item” per “tray” for lack of better terms. Much like the problem with the valves (which are now in valve sets), I think alot could be improved by looking at what each “tray” could hold in terms of materials. For example, an axle takes up so much “weight” and “space”, so does a single wheel “set” of brakes. These two items take up vastly different amounts of space and weight, so why do they each occupy a single “tray” coming into the factory? Ideally one “tray” should be able to easily hold a set of 16 or more brakes considering weight and space limitations. Another example would be tires. While a set of 4 tires are not as heavy as an axle, they do take up alot of space on the “tray”. Same with headlight sets; you could put several sets on a single “tray”. This idea, with some work mind you, could be applied to every item in the factory both finished and unfinished. As a sideways idea this could also be applied to stockpiles because items in stockpiles are “palletized” for lack of a better term. You could even expand on this idea for at-area storage areas and say that items arrive in their boxed or crated states and are unpacked/unboxed at the assembly site by the employees.
Maybe even make this a researchable item, maybe call it “Conveyor Logistics” with it’s own tech tree. That way as factories expand and the need to bulk import resources grows, the stress on the conveyor system can be lessened.
As a side note this could also help with computing lag because you could make it so less objects are being tracked within the factory ex. one object “pallet of headlights” which when “unpacked” has a value of 16 object “headlight sets”? This is a guess on my part because I’m not familiar with the code you are using in this application.
Even if you limit the items a resource importer will take care of it will not solve the fundamental problems of huge factories: The higher quantity when making the parts at your own and the basic ‘calculate nearest available source’. It will move the problem - through your mega factory and through the time but it will hit you again and harder than before. The smart placement of stockpiles show this at the moment: You can direct the stream a bit but will have to surrender …
Btw.: In the meaning of cost and efficiency it makes no sense to have more capacities to manufacture a part than you need for the production. This goal reuqires just to have enough manufacturing slots that none of them will have to wait for ‘Export Room’. E.g. if you need 20 pcs of an item but a machine can produce only 6 at the same time you would not want to have 4 machines … The only exception for this is that the part is not available on the free market so either you make it yourself or you can’t consume it.
This is just a game balance issue that can be solved by messing with the ratio of items being consumed for manufacturing cannot be greater than the number of things it creates. The problem should actually be the other way around, where 1 steel = 2 wheel. There could even be item stacking in stockpiles to solve this exact issue. Fragile materials with strange shapes do not stack, heavy raw ones with simple shapes do. There you go.
one thing that would be very helpful for routing…
Let us “paint” the conveyor lines different colors. painted lines will only connect to lines painted the same color, or existing non-painted lines. They will not connect to lines painted a different color.
And then research options to let us unlock as many different colors as we want.
The routing still can be weird. The bug report related to this was closed as ‘Fixed’ but in some cases the resources take a long way.
Atm. it looks like the resources move as far right as they can go to meet the right-coordinates of the destination and as far top as they can go to meet the top-coordinates of the destination and so on. But because pictures will explain better than thousand words here two examples of the attached savegame:
The Axles move the whole U (so passing the painter) while the max right of the U is less or equal than the right coordinates of both slots (Fit Front Axle & Fit Rear Axle).
The Drive Shaft and the Undercarriage turn to top-direction earlier so the also do not pass the right-coordinate of the slots while moving a smaller U.
So when working on routing and Resource Conveyors as mentioned here this could be one more point of improvement. restart_1.12.xml (391 KB)
“EvolGrinZ wrote:
I would like to see 2 types of importers we can put down, 1 imports components only and not raw materials, while another only imports raw materials. Together with it’s own resource conveyor in a different color, so it’s easy to identify what conveyor is transporting components and which one is moving raw materials.
I never really noticed any difference in speed of import and conveyor speeds when doing the research, so maybe boost the speed bonus for them somewhat.
It would be nice to see the resource conveyors act the same as the car conveyors, so they don’t snap unless you tell it to do so. But for me personally, it’s not critical.”
"Enkyig wrote:
Idea, just make two or three different color resource conveyors that can’t connect to the other colors but connect to each other. I know that would also be useful for identifying where they go/what you use them for. Such as specific lines, imports/stockpile to production, etc.
Only place they should be able to connect would be a stock pile. Or maybe a special connector for that?
With out a special connector possible color means could be:
Blue - General connects to anything
Red - Imports only
Green - From stock pile to production line"
I like EvolGrinZ’s idea each conveyor should be Separate.
Enkyig’s idea is also on the money.
start with blue (early Game)
research red and green lines for (late Game) when most people are refining there production lines.
also (Resource Importer slots) could be capable of feeding both red and green lines at the same time.
… and one more point related to Resource Conveyors and Routing.
Atm I’m not sure if this is just a misinterpretation by me or a bug but when I was continuing on the earlier mentioned savegame I could see that the nearest two bays have been skipped and the resources have been requested at a far away Resrource Importer. In this case the ‘Fit Steering Column’ and ‘Fit Steering Wheel’ should order their components from the Resource Importer at location A or B but the importer at location C is used:
So I would expect that the locations A and B would be the nearest bays for these 3 slots and A would be skipped because of the number of queued resources. But this only happens for a short time after load but after that short time it behaves like mentioned before.
Does this happen only on my side or can anyone else confirm this strange behavior? restart_1.12_nearest-bay.xml (797 KB)
