Как сделать импорт строки factorio
Обновлено: 05.07.2024
Здравствуйте. На прошлой неделе мы начали экспериментальный цикл выпусков обновлений 1.1. Мы устранили большинство проблем, связанных с поломкой игры и повреждением сохранений, но обновление пока не совсем стабильное. Это означает, что вы должны выбрать его, используя бета-функцию Steam.
Но будьте осторожны: библиотека чертежей и файлы сохранения не имеют обратной совместимости , поэтому, как только библиотека чертежей будет перенесена в 1.1 или вы сохраните карту в 1.1, вы не сможете загрузить их в стабильной версии 1.0.
Кроме того, не все моды были обновлены до версии 1.1, и разработчики модов могут не успевать за изменениями в будущих патчах, поэтому ожидайте, что время от времени что-то ломается, если вы играете в сильно модифицированную игру.
Если вы не хотите иметь дело с менее стабильной игрой или поломкой ваших модов, подумайте о том, чтобы пока оставаться на стабильной версии 1.0.
Основные особенности
- Добавлены логистические запросы к spidertron.
- Остановка поезда позволяет установить лимит входящих поездов.
Характеристики
Незначительные особенности
Оптимизация
- Многопоточная логика обновления ленты.
- Общее сокращение времени обновления малых объектов + статистика времени, необходимого для обновления отдельных объектов.
Балансировка
- Модуль производительности 1 снижает скорость машины на 5% вместо 15%.
- Модуль производительности 2 снижает скорость машины на 10% вместо 15%.
- Добавлен звук здания чертежа.
- Добавлен звук отмены.
- Добавлен звук для активации планировщика рельсов.
- Добавлен звук для копирования / вставки.
- Добавлен звук открытия предметов и брони.
- Добавлен звук для начала и окончания выделения. Относится к инструментам чертежей.
- Добавлен звук для трубы на землю по трубе.
- В главное меню добавлены звуковые эффекты и конкретная музыкальная композиция.
- Сборка машины 2 и 3 сделана менее шумной
- Ремонт роботов переработан, чтобы звучать более высокотехнологично
- Удалено мертвое пространство в конце некоторых звуков, которое могло приводить к остановке воспроизведения звуков.
- У здания призрачного рельса теперь есть звук призрачного здания.
- Уменьшена громкость звуков выигранной и проигранной игры
- Сборка машин 2 и 3 сделана менее шумной.
- Ремонт роботов переработан, чтобы звучать более высокотехнологично.
- Удалено мертвое пространство в конце некоторых звуков, которое могло приводить к остановке воспроизведения звука.
- У здания призрачного рельса теперь есть звук призрачного здания.
- Уменьшена громкость звуков выигранных и проигранных игр.
Исправление ошибок
- Список исправлений и изменений моддинга слишком длинный, если вам интересно, вы можете увидеть полный список изменений на нашем форуме.
В Factorio можно открывать консоль и вводить команды. Эти команды могут кардинально изменить вашу игру, так как есть варианты для режима бога, неограниченного крафта, увеличения скорости и многого дру
Содержание
Ниже вы можете узнать, как открыть консоль, а также список полезных команд. Чтобы узнать больше о Factorio Guides, обязательно посетите нашу специальную область здесь, на PwrDown!
Как открыть консоль
В левом нижнем углу экрана откроется консоль. Здесь вы можете вставлять свои команды и вводить их. Чтобы закрыть консоль, снова нажмите Return, ESC или ~.
Лучшие консольные команды и читы
Сейчас доступны десятки команд и параметров сценария, но только некоторые из них будут вам полезны.
Во время игры просто скопируйте команду ниже, измените любые параметры, если хотите, и вставьте их в командную консоль Factorio.
Многопользовательские команды
Эти команды будут работать только при игре на многопользовательском сервере, но не в режиме одиночной игры. Большинство из них также могут использоваться только администраторами.
Другие команды и читы
Все эти читы влияют на ваш игровой процесс, будь то скорость сбора ресурсов, скорость добычи или другие настройки. Использование их отключит достижения для вашего сохранения.
Дядя Боб
Теперь, когда здесь остались одни разработчики, я могу поделиться своим новым открытием — дядей Бобом и его очень хорошим объяснением некоторых фундаментальных принципов, связанных с управлением проектами. Если у вас есть в распоряжении есть восемь с половиной свободных часов, то рекомендую посмотреть эти видео, потому что в дальнейшем я буду на них ссылаться.
Раньше я думал, что мы поддерживаем достаточно высокий уровень кода и имеем вполне неплохую методологию работы. Но на самом деле мы были жертвами избирательной слепоты. Интересно, что некоторые части кода изначально были хорошими, и оставались довольно неплохими все эти годы, даже когда игра сильно расширилась… а другие части кода значительно деградировали.
Ответ заключается в метафоре искусственной вощины.
Что такое искусственная вощина и как она связана с программированием? Мой дед очень любил содержать пчёл. Я провёл детство в нашем саду, где нужно было смотреть под ноги, проверять, куда садишься и нельзя было оставлять ничего сладкого, потому что довольно скоро это оказывалось облепленным пчёлами. Я должен был помогать деду и время от времени узнавал что-то новое о пчёлах, которых, честно говоря, ненавидел и знал, что у меня никогда их не будет. Но в одном он был прав — всё, что ты узнаёшь, в той или иной степени будет тебе полезно.
Одна из работ с пчёлами заключается в том, что при извлечении мёда нужно вставить в улей искусственную вощину, которая выглядит вот так:
Её основная функция заключается в том, что пчёлы строят свои соты равномерно и довольно быстро, потому что для них естественно повторять уже существующую оптимизированную структуру. То же самое происходит и с кодом, изначально имеющим качественную и расширяемую архитектуру.
С другой стороны, существует код, или изначально спроектированный лениво, или не предназначавшийся для повышения его сложности, и каждое изменение становится ещё одним мелким дополнением к хаосу. Со временем мы просто привыкаем, что эта часть кода представляет собой сущий ад, и что внесение мелких изменений напрягает. Это подразумевает, что нам просто не нравится эта часть кода, и мы хотим тратить на него как можно меньше времени. В результате проблема постепенно выходит из-под контроля.
Но потом я посмотрел на мир глазами дяди Боба и быстро увидел несколько подобных проблемных мест. Эти места неслучайно отнимают непропорционально много времени разработчиков — не только потому, что вносить изменения тяжело, но и потому, что в них полно регрессионных багов; к тому же, они обычно являются бесконечным источником проблем.
И вот что здорово в том, что владеешь компанией, которая не выставлена на фондовый рынок. Представьте, что у вас компания, которая каждый квартал развивается всё медленнее и медленнее, после чего вы заявляете держателям акций, что решить эту проблему можно, вообще не выпуская один-два квартала новых фич, отрефакторив код, изучив новые методологии и т.п. Я сомневаюсь, что держатели акций на такое согласились бы. К счастью, у нас нет никаких держателей акций, и мы понимаем жизненную необходимость таких инвестиций в длительной перспективе. Не только для проекта, но и для наших навыков и знаний, чтобы в будущем мы работали лучше.
Вот график количества строк кода Factorio с течением времени:
Он бы выглядел вполне логичным, если бы над проектом от начала до конца работало одно и то же количество людей, но это не так. В самом начале был только я, а теперь у нас девять программистов. Можно объяснить это тем, что игра становится больше, и в ней появляется множество взаимосвязанных механик, которые сложнее поддерживать. Или же это может означать, что сильно увеличилась плотность кода. Но этих причин недостаточно для объяснения того, почему увеличение количества программистов не приводит к ускорению разработки.
Это показывает, что описываемые дядей Бобом проблемы актуальны и для нас, и что на самом деле решение заключается не увеличении количества людей, а в изменении подхода к разработке. Если создать хороший чёткий фундамент, нанять новых программистов и дать им освоиться с кодом, то это будет намного быстрее.
Позвольте мне объяснить несколько типичных примеров проблем, которые у нас были, а также рассказать о том, как мы их решали:
Пример 1 — взаимодействие с GUI
Мы много писали о GUI (например, в FFF-216) и о том, как мы итеративно поднимали планку приемлемого с точки зрения пользователей и программистов. Обычно из FFF и кодинга мы делали выводы о том, что часто недооценивали возрастающую сложность логики GUI/стилей/структур. Из этого можно понять, что усовершенствовав код GUI, потенциально мы можем очень много выиграть.
Мы довольны тем, как структурированы и выстроены объекты GUI, начиная с обновления 0.17. Однако код по-прежнему кажется гораздо более раздутым, чем должен быть. Основная проблема заключалась в том, что для добавления интерактивного элемента требовалось вносить изменения во множество мест. Позвольте показать пример — простую кнопку, используемую для сброса пресетов в окне генератора карты.
В заголовке класса:
у нас есть определение объекта кнопки
В конструкторе класса MapGenerator нам нужно создать кнопку с параметрами
Нам нужно зарегистрировать слушатель этой кнопки
Затем нам нужно переопределить метод ActionListener в классе MapGeneratorClass, чтобы мы могли слушать действия нажатия мыши.
И наконец мы можем реализовать метод, в котором обрабатываем через if/else элементы, которые нам важны, чтобы выполнить саму логику
Слишком много бойлерплейта для одной кнопки с одним простым действием. У нас было более 500 мест, где регистрировались actionListener, так что представьте, насколько распухшим был код.
Мы заметили, что когда используем лямбды для передачи колбэков и подобных вещей в GUI, то работать с ними удобнее. Что будет, если мы сделаем их основным способом реализации GUI?
Мы решили полностью переписать его, чтобы вместо добавления слушателей и фильтрации в функциях отслеживания событий можно было просто написать:
Что само по себе является серьёзным улучшением, ведь теперь для добавления и поддержки логики достаточно смотреть только в одно место, а код становится более читаемым и менее подверженным ошибкам.
А поскольку нам не нужно хранить указатель для сравнений, мы можем полностью удалить его определение из класса и сделать его анонимным во многих местах подобным образом:
Переписывание (повторное) внутреннего устройства GUI было большой задачей, но в конечном итоге нам показалось, что оно того стоило, потому что теперь я не представляю, как бы мы могли продолжать работать по-старому. Также оно привело к удалению нескольких тысяч строк кода.
Единственный способ двигаться быстро — двигаться правильно!
Пример 2 — строительство вручную
Когда стремишься сделать код чище, то преследуешь несколько основных целей. Самое важное — это устранение дублирующегося кода. Эту проблему решить достаточно легко, когда код плохо структурирован, функции слишком длинные или странно выбраны имена, но если у тебя есть пять версий одного и того же кода с незначительными отличиями, то всё гораздо хуже. Возникновение проблем — просто вопрос времени: исправления багов/изменения вносятся только в некоторые из вариантов, и постепенно становится всё менее очевидно, были ли различия между вариантами преднамеренными или случайными.
Логика строительства вручную — это настоящее чудовище, потому что она поддерживает множество вещей:
Кроме того, всю эту логику нужно умножить на два (если ты ленив и копипейстишь), потому что бывают обычные здания и прозрачные здания-призраки.
После этого ты умножаешь весь этот чудовищный код снова в два раза. Почему? Потому что нам нужна вся эта логика и в режиме сокрытия задержек. Выглядит уже плохо, но и это ещё не всё, ведь эту логику постоянно патчат и изменяют множество разных людей, а ядро кода представляло собой безумный длинный метод, код которого походил на упомянутый дядей Бобом горизонт.
А теперь представьте, что вам нужно изменить что-то в этом коде, особенно если учесть, что в коде, естественно, многие пограничные случаи обрабатываются неверно, или исправлены только в одном из вариантов кода. Это отличный пример того, как ленивое проектирование на долгую перспективу приводит к низкой производительности.
Сначала это воспринималось как мой побочный хобби-проект, для завершения которого потребуется несколько недель, но в конечном итоге я объединил весь дублирующийся код, создал красивую структуру и тщательно его протестировал. Теперь для управления кодом требуется гораздо меньше времени, чем в предыдущем состоянии, потому что читателю необязательно читать огромную кучу кода, чтобы получить общее представление о нём и что-то в нём менять.
Это напомнило мне фразу Лу, которую он сказал после подобного рефакторинга: "Когда мы с этим закончим, добавление новых функций в код будет настоящим удовольствием.". Разве это не прекрасно? Код не только становится более эффективным и менее забагованным, с ним ещё и приятнее работать, а работа с чем-то приятным ускоряет выполнение задачи, вне зависимости от других аспектов.
Единственный способ двигаться быстро — двигаться правильно!
Пример 3 — тесты GUI
Очевидно, что мы бы не добрались до этого этапа без автоматизированных тестов, и мы уже несколько раз говорили о них (в FFF-29, FFF-62, FFF-288 и в других постах). Мы постоянно стремимся повышать планку того, какие области кода покрываются тестами, и это постепенно привело нас к тому, что нужно покрывать и ещё одну область — GUI. Это вполне согласуется с постоянным пренебрежением к GUI, из-за чего ему не хватало внимания разработчиков. Отсутствие его тестов стало частью этого пренебрежения, и очень часто бывало, что после выпуска релиза он ломался из-за какой-то глупой проблемы в GUI, просто потому, что у нас не было теста, нажимающего кнопки. А в конечном итоге оказалось, что автоматизировать тесты GUI не так сложно.
Мы просто создали режим, в котором тестовая среда создаётся с GUI (даже когда тесты проводятся без графики). Мы объявили несколько вспомогательных методов, позволяющих задавать места, в которые нужно перемещать курсор или выполнять нажатия кнопки мыши, вот так:
Единственный способ двигаться быстро — двигаться правильно!
Пример 4 — TDD — разработка через тестирование
Должен признаться, что до недавнего времени почти ничего не знал о TDD. Я думал, что это какая-то чушь, потому что кажется очень непрактичным и нереалистичным сначала писать все тесты какой-то фичи (без возможности проверить или даже скомпилировать её), а затем пытаться реализовать нечто, что удовлетворяет этим тестам.
На самом деле TDD — это постоянное быстрое переключение между расширением тестов и обеспечением их прохождения. В процессе написания тестов ты практически одновременно пишешь удовлетворяющий им код. Это позволяет мгновенно тестировать то, что ты пишешь, и использовать тесты в основном в качестве спецификации того, что должен делать код, что формирует процесс мышления, чтобы ты думал, в каком направлении двигаешься, и чтобы с самого начала писать более структурированный и тестируемый код.
После момента осознания того, что же такое TDD, я сразу же стал его фанатом. Теперь я прикладываю много усилий к тому, чтобы максимально следовать методологии TDD, и чтобы заставлять следовать ей и других участников команды. Кажется, что это медленнее, тебе приходится писать тесты даже для простых фрагментов кода, в которых вроде бы не может быть ошибок, но тесты уже множество раз доказывали то, что я был не прав, и позволяли избежать раздражающей низкоуровневой отладки в будущем.
Единственный способ двигаться быстро — двигаться правильно!
Пример 5 — тестовые зависимости
Это продолжение темы тестовых зависимостей в тестах GUI.
Если тесты должны быть по-настоящему независимыми, то нужно протестировать C и иметь некие имитации A и B, чтобы тест C не зависел от правильности работы системы A + B. Похоже, консенсус заключается в этом, и это приводит к более независимому проектированию и т.п.
Возможно, это применимо во многих случаях, но я считаю, что попытка реализации такого подхода везде почти невозможна, она приведёт к хаосу. К тому же, подобные проблемы возникают не только у меня.
Например, допустим, что у нас есть тест правильности соединения на карте опор ЛЭП. Но я вряд ли смогу протестировать его, если не знаю, правильно ли работает поиск сущностей на карте.
Если тесты не имеют какой-то особой структуры, ситуация, в которой одновременно сбоят сто тестов, очень неприятна. Тебе остаётся выбирать некоторые тесты полуслучайным образом и начинать их отлаживать. Но сильно вводит в заблуждение ситуация, когда какой-то сложный тестовый случай даёт сбой и ты тратишь много времени на его отладку, а потом выясняется, что сбой вызывает какой-то очень простой низкоуровневый баг.
Задача довольно проста — мне нужно найти самый простой уровень сбоя, вызванного моими изменениями.
Для этого я реализовал простую систему тестовых зависимостей. Тесты исполняются и перечисляются таким образом, что когда ты отлаживаешь и проверяешь тест, то знаешь, что все его зависимости уже работают правильно. Я пытался найти, как другие разработчики используют зависимости, и как они их реализуют, но, на удивление, ничего не нашёл.
Вот пример графа тестовых зависимостей, связанных с опорами ЛЭП:
Я создал и использовал эту структуру при рефакторинге дублируемой логики соединения призрачных/реальных опор ЛЭП, и это определённо ускорило процесс обеспечения правильности их работы. Я уверен, что этот способ структурного тестирования мы будем использовать в обозримом будущем. Он не только делает более полезными результаты тестов, но и заставляет нас разделять наборы тестов на мелкие, более специализированные юниты, что тоже помогает в работе.
Единственный способ двигаться быстро — двигаться правильно!
Пример 6 — покрытие тестами
Когда Boskid присоединился к нашей команде, чтобы работать в QA, одна из основных его задач заключалась в том, чтобы любой обнаруженный баг сначала покрывался тестами, а уже потом устранялся, а также в общем улучшении покрытия кода тестами. Благодаря этому релизы стали гораздо более уверенными, и у нас стало возникать меньше регрессионных багов, что напрямую ведёт к эффективности на длительную перспективу. Я верю, что это подтверждает сказанное дядей Бобом. Работа с тестами кажется более медленной, но на самом деле быстрее.
Покрытие тестами — показатель того, какие части кода выполняются при работе приложения (что обычно означает выполнение тестов в этом контексте). Я никогда раньше не использовал инструменты для измерения покрытия тестами, но поскольку они были одной из тем, о которых говорил дядя Боб, я впервые попробовал поработать с ними. Я нашёл инструмент, работающий только в Windows, но требующий самой минимальной настройки — OpenCppCoverage. Он возвращает результаты в HTML вот в таком виде:
Сразу же становится заметно, что обе условные команды не сработали в тестах. По сути, это означает, что или код не тестируется, то есть его нужно покрыть тестами, или это мёртвый код, и его нужно удалить. Я уверен, что использование этого инструмента сильно поможет нам в написании чистого высококачественного кода.
Концепция Blueprint-чертежей в этой сверхпопулярной стратегической игре реализована гениально и просто, обеспечивая фантастическую вариативность во время геймплея. Изучим, как в Factorio создать чертеж и использовать его для изготовления разнообразных механизмов и прочих устройств. Многие геймеры не понимают, как корректно юзать эти механики.
Для создания выберите в инвентаре (или на инструментальной панели) необходимый чертёжный предмет. После этого жмите на левую клавишу мыши или отметьте рамочкой интересующие вас постройки. Произойдёт их автоматическое добавление в зелёную рамку. Затем отпускайте ЛКМ и увидите, что откроется специальное меню.
В чём удобство? В возможности быстро возводить огромные комплексы, на которые не придётся тратить дополнительные клики и минуты. В верхнем уголке обнаружите слоты для иконок. Исходя из числа выбранных архитектурных сооружений вы сможете быть уверены в том, что задействуете доступный инструментарий по максимуму.
Как в Factorio создать чертеж? Гайд по стратегии
Вместе с этим обратите внимание на правый верхний уголок, где размещены два символа – Create Blueprint и Cancel. Ниже указывается общее число построек, входящих в эту конструкцию. После утверждения зайдите в инвентарь, где и увидите необходимый элемент. Используйте его на своё усмотрение, существенно упрощая себе жизнь.
Благодаря тебе @Seriys, я начал играть снова в эту Factorio и так весь свой отпуск просижу. Пообещал написать тебе написать пост про, то как на одном конвейере размещать по 6 предметов. Так вот получай.
В стремлении оптимизировать и автоматизировать крафт всех предметов - возникла новая проблема, предметов в игре много, и для постройки каждого из них делать конвейер и несколько сборочных автоматов для крафта необходимых компонентов выглядит слишком громоздко и требует, чтобы я опять крафтил вручную очень много предметов для этого.
Методом долгих экспериментов, проб и ошибок получилось собрать, более менее, приемлемую и оптимальную, на мой взгляд, схему. Смысл в том, чтобы на один конвейер затолкать как можно большее разнообразие предметов.
Здесь представлен крафт всех доступных манипуляторов Factorio, где на одном конвейере размещается 6 предметов.
Проще для понимания пример крафта простых предметов:
Здесь на одной конвейерной линии движется 5 компонентов и собирается 13 предметов. На самом деле, здесь можно собирать 28 предметов, но для примера этого достаточно.
Смысл в том, чтобы разместить на одной конвейерной линии как можно больше предметов и поставить вдоль нее сборочные автоматы, которые из этих компонентов соберут нужные предметы.
Самое важное в этой схеме - выкладка предметов на конвейер. Выглядит она так:
Длинный конвейер - на эту линию выкладываются нужные материалы.
На короткий конвейер, сверху, поступают материалы. Синий манипулятор их выкладывает на основную линию материалы по 1, 2 или 3 шт. зависит от того, как прокачана наука.
Пройдя круг по основной конвейерной линии фильтрующий (фиолетовый) манипулятор заберет материалы обратно на короткий конвейер и они пойдут по новой, при этом закроют доступ, на время, новым поступающим материалам.
При заполнении конвейерной линии, новые материалы поступать не будут, пока не освободиться место. Т.к. синий конвейер подает материалы с определенной скоростью, то он не сможет заполнить всю конвейерную линию, всегда будут пустоты на равных промежутках.
Но этого недостаточно, чтобы создать бесперебойную работу.
Подключаем простую логическую схему. Ее задача заблокировать синий манипулятор, если на текущем участке конвейера уже есть этот материал.
Зачем это нужно? Чтобы исключить переполнение конвейерной линии одним материалом. Фильтрующий манипулятор, иногда, пропускает материалы, нельзя доверять ему всю работу и логическая схема подстраховывает.
Далее пример работы этой схемы:
С другой стороны, если убрать фильтрующий манипулятор, то схема сохранит свою работу. Но с прокачкой науки ваши манипуляторы будут брать по 2 и по 3 предмета за раз. В итоге конвейерная линия опять переполнится, необходимо постоянно перекладывать материалы по новой. Я не нашел другого способа, чтобы не перекладывать материалы. Разве, что конвейер не построен в кольцо и материалы просто собираются в очередь.
Вот пример, где на конвейере 3 компонента. Конвейер не забивается, новые компоненты не производятся, пока не освободиться место.
И еще полезная информация, которой мне не хватало:
1. Если вы еще не знаете, то изучите основы работы манипулятора. Кладет на дальнюю линию, забирает с ближней. На конвейере две параллельные линии.
2. На желтом конвейере можно запустить до 4 предметов (по 2 на каждой линии). На красном 6, на синем 8.
3. Если использовать пакетные манипуляторы, то вы сможете обеспечить линию большим количеством одного материала.
4. Крафт на конвейере дольше в несколько раз. Но это не бутылки, которые нужны постоянно в большом количестве, поэтому как правило ваш завод должен успевать пополнить все запасы, к тому времени как вам понадобится что-то строить.
5. Такая схема неприменима для крафта бутылок.
6. При таком производстве предметов необходимо ограничивать инвентарь сундуков. Зачем вам сразу 3000 сборочных автоматов? Потратите кучу ресурсов на то, что не сможете использовать сразу.
7. Предметы, которые расходуются в большом количестве (манипуляторы, конвейеры, боеприпасы) лучше производить отдельно от всех.
8. Так как готовая продукция лежит в сундуках (логистических сундуках), то вы можете поставить триггер на отключение этого завода, когда он наберет полные запасы предметов. Иначе манипуляторы там будут бесконечно перекладывать на конвейере материалы.
Собирая каждый раз новую схему, придумаешь новые способы оптимизации, эти примеры не идеальны и всегда можно собрать что-то лучше.
Конечно можно собрать более компактные схемы по сборке абсолютно всех предметов с помощью дроносети или без конвейерную, но это уже другая тема.
Почему же я не использовал самые быстрые синие конвейеры, потому что 8 компонентов на конвейере это очень много и это слишком сложно для меня.
Еще раз про скорость крафта. Персонаж ручками собирает быстрее чем сборочный автомат. Но на конвейере сборочных автоматов много и собирают они пусть медленно, но суммарно больше и инвентарь у них не так ограничен. На практике это очень выгодно иметь в запасе всегда все предметы для новых построек и получать их от дронов по команде и не таскать с собой ресурсы.
Спасибо за интересный пост!
У меня есть некоторые мысли по этой схеме.
Во первых система с двумя манипуляторами и Т-образным буфером кажется немного избыточной. Во первых это лишние затраты энергии на дополнительные манипуляторы, во вторых требуется как вы написали логическая цепь для отключения манипуляторов когда сундуки заполнены, чтобы не таскали туда сюда, а это тьма проводов. Понимаю, что энергозатратами можно и пренебречь, но такие решения как это - все таки в большей степени претендуют на красоту и эстетику - меньше места, меньше энергии, все красиво и работает как часы.
Так вот вопрос. Так уж ли необходим фильтрующий манипулятор? Что будет если класть одним манипулятором сразу на ленту кольцевую, то есть избавится от фильтрующего манипулятора и от Т-образного "буфера", а оставить только отслеживание количества предметов на ленте и в пустующие участки добавлять нужное? Если проблема только в количестве предметов которое за раз перемещается манипулятором то мне кажется можно для каждой исследованной технологии подобрать параметры нужные. например если по три предмета перекладывает то можно удлиннить секцию на которой отслеживаются пустоты (отслеживать не на двух а на трех тайлах ленты например), поиграть со значениями логического условия. Наверняка эксперементы такие вы делали, интересно почему пришлось так усложнить схему. Или я чего то недопонял?
Вы написали "На желтом конвейере можно запустить до 4 предметов (по 2 на каждой линии). На красном 6, на синем 8."
А собрать свой похожий конвейер я обязательно попробую, мысль мне понравилась! Если получится улучшить схему, отпишусь)
Читайте также: