Fix for stockpiles (buffering / balancing supply lines)

Production Line Suggestions
1

Problem:
Stockpiles are not utilized to their max potential (if at all), rendering them ineffective for balancing supply lines, necessary for improving the utilization rate of production processes (especially those that require multiple supplies per stage and are starving now).

Example:

Example: A supply stockpile dedicated to servo components, to supply nearby processes. At most 1 item will queue up in the buffer.

Diagnosis:
It appears that supply orders are generated when either:

  • A production station does not have (sufficient) resources for the current production step;
  • Regularly when a production station has spare room in its included stockpile, or when a stockpile has spare room.

In the first case, an immediate order will be generated and supplied as soon as possible. In the second case, it appears there is an internal timer that regularly checks for this condition. For a production station, sufficient goods are sent to its inventory for its full production step (ergo, if the station requires per step 4x A and 2x B, it will send 4x A and 2x B). The supply process is then based on FIFO-ordering, when demand is really high.

However, for a supply stockpile, no urgent demand exists and it will only generate requests (/ be supplied) at regular intervals with 1 unit at a time, even when the supply line itself has a low utilization rate and should be more than capable to resupply more units to the supply stockpile

Potential Solution:

(I) When a Resource Importer does not have immediate requests of starving production processes (= not at max. capacity), it should attempt to fill up all stockpiles with its slack capacity by whatever these stockpiles request, while obeying its max capacity of spawned supplied per time unit.

(II) In addition to the first fix, users can even be given control over the priority of items within the supply line, as this would also ensure that critical processes (i.e. bottlenecks) can be preferred to resupply first before other processes. For example, a priority queuing system with 4 steps can do:

  • Essential*: highest priority before all else, these processes will be resupplied first (for bottlenecks / critical processes);
  • High: default for production processes currently out of inventory and waiting for supply (starving);
  • Normal: default for all production processes with spare room in their stockpiles;
  • Low: default for supply stockpiles, will only be filled up when no higher priority orders exist.

For each production step and supply stockpile, its priority can be selected. When an unimportant production process is out of goods, it has a high priority, since critical processes (bottlenecks) should be resupplied first before anything else, hence the differentiation between essential and high. By default, stockpiles have a low priority. By adjusting the priority for certain stockpiles, important supplies can be buffered in the supply line reducing time to restock and improving the utilization rate of the production processes associated with it.

Meanwhile the resource importer can only spawn supplies at a fixed rate, for which it will attempt to fill up the demand based on the priority system. So if it spawns 10 supplies per time unit, first the essential demand will be filled (lets say 3 units), and if there are sufficient items available, it will attempt to fill up all demand until all its resources for the time unit are utilized (distribute the remaining 7 in order of priority). When the demand for supply goods is higher than the spawn rate per time unit, it will only supply the most important processes and neglect the less important ones.

Although this last solution sounds a lot more complicated, it will also provide additional tools to ensure the resupply of processes deemed critical in the production process. This should encourage players to analyse their bottlenecks and balance the supply line accordingly, and would enable them to improve the utilization rate of processes of their choosing, when these are starving of supplies.

Other thoughts
Effectively, this would also reduce the necessity to separate supply lines as much as possible (and consequently the desire to remove the auto-connect feature of supply lines). The resource importers and supply lines themselves often have plenty of capacity left, while the production processes down the line are starving nevertheless. Most people attempt to fix this by separating the supply lines as much as possible and running dozens of supply lines separated by 1 tile across the place, while each line itself is hardly utilized.

2

right now StockPile’s are a big hold back in the gamplay.
Also that if you have two lines that produce windows only one exports parts and the second one stops exporting.

3

I think that the best solution for this is going to be a combination of things…

First each car needs an ID so that the game knows which design is going to be applied to that car. The game can then calculate how many resources are necessary to complete the car. Then the game does this for every car in the factory. Import orders are made based on the number of cars you are currently building and their proximity to the next section of machines.

So to brute force it:
If you are building lets say 17 cars, then the game will order (17x4=) 68 doors to be added to your stockpile if you have one that is unassigned or if there is one assigned to hold doors.
Obviously this is not ideal because all 17 cars are not going to be built at once, and this will again stress the importers to be at 100% load without streaming out 1 car at a time, at a consistent rate. However, this might be a good option to include for massive factories with higher demands and more structured inventory management.

Ideally:
the game knows I have 17 cars on the conveyor. However, I have only built 2 body stations. So instead of brute forcing it, the game would try to maintain 8 doors in the stockpile at all times.

The key to this is a queue for items that are next in line to be used.

Instead of waiting for the 8 to begin to be used, it would predict and know that the 2 body stations are free and the cars are on the way, so pretend they don’t exist and go ahead and order 8 more doors, because they are already in a queue to be used.

Again the CarID becomes important because the game needs to make sure not to count the same car twice while its in line for the next station. Take one car at a time, fulfill its item order and remove it from the item queue list at that station and then repeat.

Then this could be calculated per production line so that if the throughput changes, more importers are required to maintain the inventory.

Rather than you waiting on importers I want the importers to be waiting on the stations to be free. So some code might need to be added so that the importers bring the item directly to where they are needed, and wait for an open slot to deliver them and maintain a constant inventory. This is why factorio belts work better than conveyors do. Its not about the flow of resources, its about the availability.

In addition to upgrading the speed of the conveyors, we would also want to upgrade the number of resource conveyors so that we can increase the size of the queue to reduce waiting time and increase item availability so that items are used as soon as possible. The bottleneck should be the stations, not the resource importer.

4

Although it may sound elegantly, the problem with your approach is that inventory will get out of hand very quickly, and very badly as well. By ordering stock parts as soon as a new car is first created, would mean that:

  1. we have to know beforehand which exact model it is going to be, changing the game fundamentally from make-to-stock to make-to-order. Although not necessarily bad to have this choice (making high-end luxury cars has a different ordering process than a generic production model), it would alter the entire game (and coding) very significantly, and for now, I assume Positech is looking mainly at generic production models.

  2. the inventory will get out of hand very quickly. For every car you create, all of its parts are immediately ordered and stockpiled in the entire line. For 20 cars it would be 80 tires, 80 wheels, 40 axles, and so on, on every station of the line. If you want to have all stations occupied as well as some buffers on the assembly line, imagine what 50 cars would do to your factory. Each individual process would then attempt to stockpile all of these parts simultaneously as it would require immediately all of these components. You’ll need enormous stockpiles for every station in the entire line. I’m not joking when I say that most of your factory will look like a gigantic warehouse rather than an assembly line, and that can’t be a desired situation. In reality, you will want to have your buffer filled with items for the current, and depending on your variability, perhaps also for the next car but that’s about it.

  3. the required logic for this system to work is indeed something that would normally be engineered, but again, I certainly hope no production engineer / supply chain manager will ever attempt to put exactly the items at each station for the cars that are on the conveyor.

In a very modern factory, systems will indeed know exactly when the parts are needed at each process step in the assembly line and will order them exactly in the right time with a minimum of slack possible. In fact, I’ve seen examples of a truck manufacturer with a complicated supply chain where such systems are implemented (image multiple factories assembling sub-components, hauling everything to the mother factory for final assembly over distances of hundreds of miles with a time buffer of less than 30 minutes between the moment a cargo transport arrives and its supplies are needed in the production line…)

You don’t want full buffers, but exactly only the parts you need at exactly the right time and not a minute earlier (or late). At least, that’s the ideal when you apply Lean Manufacturing / Toyota Production Model / Lean Six Sigma etc. From all these perspectives, specifically in a car manufacturing process, inventory is a (necessary) evil you’ll want to minimize.

Implementable in this game? Yes, if the game knows the processing time of your entire production line (which is variable due to event based simulation), as well as the entire production layout and logic (for example, you have 2 stations in parallel in the same line or were they in fact 2 different lines?). It is predictable when specific models enter a station, how long they are at a station and when they leave in the station again and arrive at the next station. So yes, theoretically it can be completely calculated and predicted.

Desirable? I would say no. Since this is a game, yes, it can be fully calculated and optimized without any human interference and automatically implemented, but this would let the game run and optimize the factory for you and removing any challenge for attempting to optimize the factory yourself (apart from layout issues and putting the processes in the right order).

For this game, since there is no real preference yet for specific parts for a specific ordered model type, an approach based on stockpiling generalized components seems more preferable. However, the current stockpile simply does not work as a buffer, making such approach useless and hence the suggestion to fix to make them an effective tool as they should be. Furthermore, I would like to add, that there are several other reasons, one of them being line balancing, another being takt time (referring to Lean Manufacturing / Toyota Production Model once again), why you shouldn’t want to see entire warehouses of inventory in your production line.

Although this game still has a long way to make before we even can get towards realistic car production lines (read: the most specialized lean production lines imaginable) (cough variability / cost / breakdown / failures / production quality / maintenance / Work-in-Progress items / inventory items / Kanban-systems and more /end of cough), it would help to add more options for a player to the game for things that can be optimized manually.

5

By reading your post I’m not sure you read my entire post or maybe misunderstood what I said. I talked about your #2 and #3- I talked about all this.

This is not true, it only needs to query the next station once for each CarID. The CarID doesn’t even necessarily need to have anything to do with design. The game already has a lot of the function required to do this, as I understand it.