, computers.
I couldn't resist creating a mall with multiple assembling machines and full dynamic recipe assignment. It's reasonably fast for expanding your Nauvis base and providing any supply you might need for defense.
It can craft whatever can be crafted by assembling machines and either water or lubricant. Additional fluids can be added with not much work, for example if you intend to bottle fluids to barrels, but I didn't do this here.
The list of items to craft is defined in the constant combinator above the display panel with the arrow. It's the "Mall item requests" logistic group.
The top right substation provides the current item status: positive numbers are items yet to be crafted, negative is the surplus.
It assumes just basic intermediates exist in the logistics network: ore, plates, chemical plant products and green+red+blue chips. Everything else is crafted on the fly.
The top lane of assemblers will craft everything. The bottom lane will additionally craft selected "long running" recipes with 2 additional assemblers per product to accelerate some intermediates. The list is hand picked and hardcoded, since it's not possible to determine recipe duration, but the actual assignment is as dynamic as for the top lane.
If you're interested in how it works, I added comments to every combinator to show its role.
In general, it works by creating lists of signals, comparing/subtracting/adding lists and selecting signals from lists.
such as for example:
- a list of items to craft
- a list of items NOT to craft
- a list of intermediates got by reading recipe ingredients
The most important thing is the main memory cell that gets items to craft one after another. Items enter with value=1, and every tick all items already in the list get incremented by 1, so the order of items will never change and new items are added "at the end" of the list.
This list is being sent to the assembling machines. With a selector combinator, each machine picks the nth item from the list. The 1st machine picks item 0, the 2nd machine item 1, and so on. There are 12 combinators in the first row, so the first 12 items of the list will be crafted. Every assembler gets the same recipe every tick, because due to the incrementing the signal order from the memory cell is stable, no matter how many additional items are added over time.
For every assembler, the list of ingredients is multiplied by 5. This is requested by 2 requester chests to supply the assembler with the required ingredients. Requesting less isn't fully supporting fast crafting recipes.
The individual ingredients are also added up for all machines into a big list, normalized to value=1 and added to the main memory cell, so they will be crafted as well. Reading and adding ingredients is faster than adding new items in general (~8 ticks versus 15 ticks), so it isn't possible all assemblers are stalled with no assembler left to produce the required ingredients.
The 3rd combinator at each assembler checks if the recipe is in the list of recipes NOT to be crafted. In this case, the chests and inserters are deactivated, so crafting will stop eventually. It's not possible to directly deactivate the assembler, because a deactivated assembler stops mid-crafting and its recipe cannot be easily changed. Also, the recipe itself isn't removed from the assembler to keep input buffers and chest content, because demand for some intermediates is satisfied just for a few moments, then requested again. So it's good if the buffered items aren't trashed immediately.
While all assemblers are occupied, every 3600 ticks (1 minute) the memory cell gets reset, so finished recipes are flushed and new recipes can be crafted.
It's being monitored if some recipe requires water or lubricant. The corresponding pumps are activated to provide the fluid and remove the other fluid. Lubricant has priority over water. The storage tanks are just half filled on purpose: there must be enough space to pump the unwanted fluid back into its tank. Each fluid you want to add needs its own tank and 3 additional pumps.
Full dynamic bot high speed mall
Re: Full dynamic bot high speed mall
In Your Blueprint are infity chest present and your testing pipes
Looks interesting.
A clock build with counting the items needed
I think the best part in this design is the fluid handling.
My long term plan is it to feed the automatic mails with signal lines from my EPC (I have 8 bit free) and then read the 1/1000 values .
Your Concepe would fit here with some adaptions.
Looks interesting.
A clock build with counting the items needed
I think the best part in this design is the fluid handling.
My long term plan is it to feed the automatic mails with signal lines from my EPC (I have 8 bit free) and then read the 1/1000 values .
Your Concepe would fit here with some adaptions.
English is my second language and I am not good at languages
My Creations:
EPC - Encodes Planetary Control
Circulet Examples:
Signal Encoding & Decoding
Signal Filtering
My Creations:
EPC - Encodes Planetary Control
Circulet Examples:
Signal Encoding & Decoding
Signal Filtering
Re: Full dynamic bot high speed mall
Well, the infinity items were used for development and help to inspect the operation in map editor. You're supposed to remove them if you use the blueprint on a real map and embed the thing into the map resources.
If you ask me, the best part is the memory cell with the list of items to craft that stays in the same order, even if items are added. That's the core everything else depends on. It enables the selector combinators to always pick the same item. The other difficult part was simultaneously providing the recipe and reading back the ingredients all with just 2 wire colors, without interfering with all the other machines.
And the timeout/reset counter. It has 8 conditions and it implements 2 different range checks in a single decider.
The fluid handling is not that advanced. Just pumping in what you need and pumping out everything else.
If you ask me, the best part is the memory cell with the list of items to craft that stays in the same order, even if items are added. That's the core everything else depends on. It enables the selector combinators to always pick the same item. The other difficult part was simultaneously providing the recipe and reading back the ingredients all with just 2 wire colors, without interfering with all the other machines.
And the timeout/reset counter. It has 8 conditions and it implements 2 different range checks in a single decider.
The fluid handling is not that advanced. Just pumping in what you need and pumping out everything else.
Re: Full dynamic bot high speed mall
OK haven't analysed your design in detail yet. But it is on my list for adaption for my system.
I've only played around a little unmotivated with automatic systems so far. But I have already understood that you can probably only work efficiently if you save values. Otherwise it becomes too chaotic.
How would you design your list for feeding your machine?
I thought about dividing it into lists that are limited to x items and the ones with the highest demand. However, this would have the disadvantage that elementary important ite,ms, which could be fulfilled with ease, might be at the back of the list
At the moment I simply have a system for each item and it starts as soon as something is brewed. Most of the legendary items are built on Vulcanos...
I'm not bothered by the infinite sksites and connections. tick-controlled combinators in particular can hardly be tested in any other way. I just wanted to point out that these are still included.
I've only played around a little unmotivated with automatic systems so far. But I have already understood that you can probably only work efficiently if you save values. Otherwise it becomes too chaotic.
How would you design your list for feeding your machine?
I thought about dividing it into lists that are limited to x items and the ones with the highest demand. However, this would have the disadvantage that elementary important ite,ms, which could be fulfilled with ease, might be at the back of the list
At the moment I simply have a system for each item and it starts as soon as something is brewed. Most of the legendary items are built on Vulcanos...
I'm not bothered by the infinite sksites and connections. tick-controlled combinators in particular can hardly be tested in any other way. I just wanted to point out that these are still included.
English is my second language and I am not good at languages
My Creations:
EPC - Encodes Planetary Control
Circulet Examples:
Signal Encoding & Decoding
Signal Filtering
My Creations:
EPC - Encodes Planetary Control
Circulet Examples:
Signal Encoding & Decoding
Signal Filtering
Re: Full dynamic bot high speed mall
Ok i found it.
I agree that the approach is really good. You can reset it when there is a green signal and if there are faults and something cannot be created, it is also reset after a certain time. It looks quite stable and failsafe.
If I see this correctly, when the recipe is changed, the new production could be interrupted if the timer runs over 3600. But I think that would be acceptable disturbances.
I agree that the approach is really good. You can reset it when there is a green signal and if there are faults and something cannot be created, it is also reset after a certain time. It looks quite stable and failsafe.
If I see this correctly, when the recipe is changed, the new production could be interrupted if the timer runs over 3600. But I think that would be acceptable disturbances.
- 21-11-2024_21-19-26.png (248.86 KiB) Viewed 296 times
English is my second language and I am not good at languages
My Creations:
EPC - Encodes Planetary Control
Circulet Examples:
Signal Encoding & Decoding
Signal Filtering
My Creations:
EPC - Encodes Planetary Control
Circulet Examples:
Signal Encoding & Decoding
Signal Filtering
Re: Full dynamic bot high speed mall
My approach to a similar mall system has always been: once a recipe is chosen, the recipe signal itself is used as a fake content count. By always selecting the most missing material, it ensures that at least this number of fakes is created consecutively.
What I always hate is the fact that you cannot use 'read recipe ingredients' and 'read content' in an assembly machine at the same time and split the signals onto different wires. The lack of this feature has always forced me to use a lot of combinators, which could be avoided if there were an easy way to separate these signals. The best solution I’ve used so far is having a single assembly machine on the side dedicated solely to recipe deciphering.
What I always hate is the fact that you cannot use 'read recipe ingredients' and 'read content' in an assembly machine at the same time and split the signals onto different wires. The lack of this feature has always forced me to use a lot of combinators, which could be avoided if there were an easy way to separate these signals. The best solution I’ve used so far is having a single assembly machine on the side dedicated solely to recipe deciphering.
Re: Full dynamic bot high speed mall
(ou, I cannot delete my own accidental duplicated messages? that is weired)
Re: Full dynamic bot high speed mall
The above mall works by just determining "I need to craft this" and "I don't need to craft this". Items to craft are positive, items not to craft have the MSB=1, which flags the value as negative - but it's not a real negative value.
There's no subtracting (demand - inventory) to determine how many items still need to be crafted. There's simply no space for this info, because the values associated with the signals are used for the increasing counter values to keep the list order stable. The diff info at the power pole is just made for the player, it's not used by the mall itself.
@Stin
Unfortunately, all machines are flushed and filled again after 3600 ticks if all machines are being used, even if they don't get a different recipe. All recipes must go away, so the associated ingredients go away, so the main memory cell is not filled with the intermediates not required any more. And since the requester chests are requesting what the ingredients are and trash everything else, they're flushed as well with this reset.
It's all not a real computer after all.
The order the items are crafted is the order of the original request list: descending value. If you request 1000 rails and this is the biggest request, and you already have 999 rails, rails are being crafted first. The current inventory isn't subtracted. You can do this if you like by using the info from the power pole, not from the constant combinator. In this case, the most prioritized items are what is currently missing most. In both cases, tiny numbers (1-5) are crafted last. I tested performance with both variants, overall crafting time is roughly the same.
How to provide the list of items to craft is a different topic. Instead of the single constant combinator, you could prepend any additional logic that handles some kind of priority. In Discord, there was a discussion about a tiered system for this: up to 10 lists (or "tiers") of items. First craft the items in the 1st tier. If they're all there, consult the list of the 2nd tier and craft whatever is in there. Then the 3rd tier and so on. And if you're currently crafting for tier 3 and 1 item from tier 1 is consumed and being missed, the list is switched back to tier 1 and this one missing item is crafted first before resuming tier 3.
This is WIP and not completely migrated to 2.0 (you don't need that many constant combinators for the lists - just logistic groups). For usage, see the comment in the blueprint. However, I'm not sure if I really need this, since in Space Age production is so distributed and ever-changing, so this kind of final mall solution is probably overengineering, since there is never some final mall with all the different kind of assembling machines on the different planets and with quality.
There's no subtracting (demand - inventory) to determine how many items still need to be crafted. There's simply no space for this info, because the values associated with the signals are used for the increasing counter values to keep the list order stable. The diff info at the power pole is just made for the player, it's not used by the mall itself.
@Stin
Unfortunately, all machines are flushed and filled again after 3600 ticks if all machines are being used, even if they don't get a different recipe. All recipes must go away, so the associated ingredients go away, so the main memory cell is not filled with the intermediates not required any more. And since the requester chests are requesting what the ingredients are and trash everything else, they're flushed as well with this reset.
It's all not a real computer after all.
The order the items are crafted is the order of the original request list: descending value. If you request 1000 rails and this is the biggest request, and you already have 999 rails, rails are being crafted first. The current inventory isn't subtracted. You can do this if you like by using the info from the power pole, not from the constant combinator. In this case, the most prioritized items are what is currently missing most. In both cases, tiny numbers (1-5) are crafted last. I tested performance with both variants, overall crafting time is roughly the same.
How to provide the list of items to craft is a different topic. Instead of the single constant combinator, you could prepend any additional logic that handles some kind of priority. In Discord, there was a discussion about a tiered system for this: up to 10 lists (or "tiers") of items. First craft the items in the 1st tier. If they're all there, consult the list of the 2nd tier and craft whatever is in there. Then the 3rd tier and so on. And if you're currently crafting for tier 3 and 1 item from tier 1 is consumed and being missed, the list is switched back to tier 1 and this one missing item is crafted first before resuming tier 3.
This is WIP and not completely migrated to 2.0 (you don't need that many constant combinators for the lists - just logistic groups). For usage, see the comment in the blueprint. However, I'm not sure if I really need this, since in Space Age production is so distributed and ever-changing, so this kind of final mall solution is probably overengineering, since there is never some final mall with all the different kind of assembling machines on the different planets and with quality.
- Screenshot 2024-11-22 102558.png (1016.97 KiB) Viewed 171 times
Re: Full dynamic bot high speed mall
Thanks
The whole topic is complex.There is a reason why I want to implement automatic production as the last topic in my EPC system.i think the approach is good and nothing in factorio is ever really perfect. That's part of the appeal
The whole topic is complex.There is a reason why I want to implement automatic production as the last topic in my EPC system.i think the approach is good and nothing in factorio is ever really perfect. That's part of the appeal
English is my second language and I am not good at languages
My Creations:
EPC - Encodes Planetary Control
Circulet Examples:
Signal Encoding & Decoding
Signal Filtering
My Creations:
EPC - Encodes Planetary Control
Circulet Examples:
Signal Encoding & Decoding
Signal Filtering