AutoMall v2.0 (Авто сборка предметов и blueprint) [F2.0 SA]

video v0.1: https://www.youtube.com/watch?v=1JCPZQgVD38
video v1.0: https://www.youtube.com/watch?v=aSblim_r16A
video v2.0: https://www.youtube.com/watch?v=iY3gkuLuw0E
AutoCraftFactory v1.2 [F2.0 SA] https://www.factorio.school/view/-Om0FtdByP9MmtKcOLsB (финальная идея)

Обновление v2.0:

Сделал более усиленную версию и пофиксил некоторые баги

Обновление v1.0:

1. Блок управления имеет таймер сброса и его настройки.
2. Блок управления не делает очередь по качеству предметов и все будет собираться подряд.
3. Блок калькулятор теперь умеет приблизительно вычислять продуктивность до 300% (максимума в технологиях)
4. Блок жидкости обзавёлся уведомлением о нехватки жидкости
5. В калькуляторе и блоке управлении сделал визуальное разделение логики по блокам с помощью бетона. (мне так проще читать логику самому)
6. Старые версии вынесены в отдельную книжку принтов

Система сложна в логике, но проста в использовании.

1. Что это и зачем нужно?
2. Почему не сделать обычный молл ?
3. Зачем так много логики?

1. По сути сборка кучи рецептов с разным качеством и минимум перепроизводства. Делал для сборки blueprint и всякой мелочи.

2. Обычный молл минусы (по моему мнению):

   • Требует много места
   • Требует настраивать каждый сборщик на каждый рецепт
   • Куча сборщиков просто будут простаивать
   • Для крафта blueprint нужно тоже заморочиться с логикой
   • Производит куча лишнего если не настраивать

3. Нужна для минимизации перепроизводства (с модулями скорости и маяками), расчетов рецептов и распределение задач (рецептов) между сборщиками.

Логика или проще сказать система поделена на 5 блоков:

1. Калькулятор ингредиентов дерева рецептов (самый важный блок)
2. Обработчик запросов. Принимает любые рецепты с любым качеством (рецепты на обычный сборщик)
3. Блок управления, блок распределения задач между сборщиками, блок таймера сброса + уведомление о сбросе, блок настроек с дублированием их в качество
4. Блок сборщика
5. Блок подачи жидкости

Процесс (Workflow):

1. В постоянный комбинатор записываем то что нужно собрать с разным качеством или вставляем blueprint и включаем его.
2. Логика запросов для начало отделит по качеству список (от обычных до легендарных) и отправит сигналы одного качества в калькулятор ингредиентов. (теперь без очереди собирает все подряд)
3. Калькулятор разом будет рассчитывать кучу рецептов одного качества и выдаст очередь заданий в блок управления.
4. Блок управления получив очередь заданий сбросит калькулятор и начнёт спамить сигналы в блоки сборки.
5. Блоки сборки получив задание отправляют ответный сигнал блоку управления который сразу уберёт задание из очереди и начнёт сборку.
6. Блоки сборки будут собирать все пока очередь не опустеет.
7. Как тока блок запросов узнает что нужная очередь собрана то сделает сброс и сразу кинет дальше задание со следующим качеством если оно есть в запросе или включит сброс если все задания выполнены.
8. Если процесс остановился и кол-во не выполненных рецептов менее или равно (в настройках таймера) то, будет запущен таймер (1800 или 30 секунд в настройках) и отправлено уведомление (если включено) далее будет выполнен сброс, что бы сборка рецептов стартовала там где остановилась

Настройки:

1. Постоянный комбинатор со списком приоритетов ингредиентов. (в текущем виде настроено оптимально, но возможно требует доработки потому что проводил мало тестов)
2. Постоянный комбинатор со списком ингредиентов которые нужно распределить по нескольким сборщикам. Так как ящики запросов не резиновые и не могут все вместить то луче указать максимум на 1 сборщик. Пример: 10 ракетных шахт 😓 требует очень много игредиентов и они не влезут в обычные ящики запросов и луче указать что 1 сборщик собирает 1 ракетную шахту.
3. Самый важный 😁 комбинатор с сигналом R (сброс или reset). При залипании или любой внештатной ситуации просто делайте сброс 😅 и система начнёт с того места где остановилась.
4. Постоянный комбинатор со списком процентов продуктивности
5. Постоянный комбинатор таймера сброса

Важные нюансы при работе с этой системой:

1. Система будет собирать все из низкоуровневых крафтов к высокоуровневым и это может занять много времени даже со скоростью и большим кол-вом сборщиков. Для уменьшения времени сборки или исключения некоторых крафтов нужно заранее иметь в ящиках нужное кол-во и тогда калькулятор их учтёт и не будет добавлять крафт в очередь. Так же возможен маленький рассинхрон логики и сборщика, что может произвести больше чем планировалось. (бывает остаётся несколько труб и тд. но это не критично)

2. Калькулятор считает почти точно за исключением некоторых моментов:

   • Учитываются почти все рецепты которые создаются более чем в одном экземпляре к примеру медная проволока x2
   • При расчётах возможны дробные значения и может получиться -1 или +1 в рецепте и может чутка лишнего произвести(это не сильно влияет, но может быть причиной залипания в редких случаях 😅).
   • При расчетах используется приоритизация позиций ингредиентов в списке (без этого не возможно в прицепе правильно рассчитать все)
   • Калькулятор учитывает при расчетах все что есть в ящиках в наличии и на момент расчётов. (если то что он учел убрать то система может в какой-то момент залипнуть и в этом случаи просто нужно сделать сброс, где будет перерасчет и процесс продолжится)
   • Калькулятор не учитывает продуктивность в рецептах! (не придумал еще как это решить) К примеру синие микросхемы имеют продуктивность в технологиях и после сборки могут остаться красные и зелёные микросхемы даже в огромном количестве (если собираете много всего). Но то что было лишним произведено будет учтено в следующих сборках рецептов и пере использовано или проще сразу иметь нужное кол-во синих микросхем что бы их не собирало.
   • Калькулятор может отправить уведомление о том что он не может собрать и в этом случаи просто нужно убрать с запроса и сделать сброс. Пример: электро магнитный завод нельзя собрать на Наувисе, но если сборка происходит на Фульгоре то уведомления не будет и сборщики соберут завод.
   • Я вывел некоторую закономерность и сделал из этого формулу расчета продуктивности. Работает не на 100% потому что есть проблемы с дробями, но в целом оно снижает кол-во лишнего в разы. Заложена погрешность на 1% (сборщики могут перепроизвести чуть лишнего и из-за этого может не хватить на другие рецепты).
   • Погрешность не много снижает вероятность залипания, но не на 100%.

3. Возможно случайным образом назначается 1 рецепт на 2 сборщика если это не предполагалось через настройки. Такое бывает при рассинхроне сигналов при спаме блока управления и в этом случаи просто сделайте сброс и процесс продолжится при перерасчёте там где остановилось.

4. Не меняйте буферный сундук на сундук запроса. Сундук запроса не выводит в дрон сеть то что внутри лежит, а при замене будет бесконечная сборка не нужного.

5. По моим наблюдениям сборщики тратят кучу времени (легендарные сборщики с маяками и модулями скорости) на сборку микросхем и это занимает кучу времени если их нет в наличии. Лучше держать все виды микросхем в наличии, что бы система не собирала их кучу времени. (за исключением технологий продуктивности которое может снизить кол-во ингредиентов для сборки рецептов)

6. Прежде чем пихать blueprint какова нибудь корабля в комбинатор луче в отдельном калькуляторе (есть тестовый blueprint калькулятора) посмотреть сколько насчитает и исходя из результата уже сделать запасы для уменьшения времени крафта или добавить запасы жидкости если в наличии её мало.

7. После сборки важно вытащить из сети собранное, что бы калькулятор не учитывал при новых расчетах.

Надеюсь я смог объяснить общую концепцию работы этой логики. Не думал что мне придётся такое изобрести, но оно того стоило при учёте затраченного времени и экспериментов. 😊