eu_tomat

До тестирования я не добрался, но почитал код. Есть замечания и вопросы: Функцию сканирования инвентаря можно немного ускорить, отказавшись от выполнения getStackInInternalSlot(slot) для заведомо пустых ячеек. Наличие предмета в слоте помогает определить функция robot.count(slot), и работает она очень быстро. И только уже зная, что слот не пуст, появляется смысл запрашивать getStackInInternalSlot(slot). В остальных случаях получаем экономию в один тик на каждый пустой слот. robot.inventorySize() вызывается больше одного раза, каждый раз тратя на это один тик времени. Такое решение полезно для случая съёмных апргейдов инвентаря. Но удобнее всё же сделать несъемные. Тем более, автор заказа не ограничен в материалах. Ему под силу сразу скрафтить нужного робота. При поступлении сигнала inventory_changed программа заново сканирует инвентарь, тратя на это 3.2 сек при 64 слотах в инвентаре робота, хотя достаточно обработать лишь те слоты, для которых поступил сигнал изменения. При обнаружении отсутствующего компонента в инвентаре робота необязательно тратить время только лишь на ожидание его появления. Достаточно сообщить игроку список отсутствующих компонентов и продолжать заполнение, возвращаясь к пропущенным слотам позже. У на же есть контроллер инвентаря, поэтому вместо robot.drop() можно использовать component.inventory_controller.dropIntoSlot(side,slot,count), помещая предмет строго в нужный слот. Или на сервере какие-то особенности приватов не позволяют так обращаться с внешними инвентарями? Если использовать dropIntoSlot допустимо, то заранее сканировать инвентарь робота имеет смысл только для того, чтобы сообщить об отсутствующих игроку компонентах. А если сообщение игроку поступает ровно в момент попытки поместить компонент в реактор, то и сканировать слот инвентаря можно непосредственно перед этим. Обнаружение изменения инвентаря сейчас реализовано проверкой на 0 значения robot.count(slot). Это работает только для случая извлечения предмета из слота. Но игрок может произвести замену предмета. В этом случае программа рискует поместить в реактор не тот компонент. Зачем функция set сделана рекурсивной? В чём удобство именно рекурсивной функции?

Для полной уверенности придётся проверять и статус операции отправки в реактор, а сразу после отправки вдобавок ещё проверить, не поступили ли за это время какие-то лишние события по этому слоту. Или можно тупо проверить нужный слот в инвентаре реактора. Это, конечно, немного замедлит работу, но обеспечит полную устойчивость алгоритма без его сильного усложнения.

Сигнал inventory_changed генерируется в случаях изменения предмета в инвентаре: в пустом слоте появился предмет; предмет исчез из слота; предмет в слоте был заменён другим. Оно не возникает лишь при изменении количества предмета в слоте. Логично, что программа должна уметь обрабатывать все три ситуации. Даже если мы в какой-то таблице хранили количество предметов в слотах инвентаря робота, то без дополнительных вычислений однозначно идентифицировать мы сможем только ситуацию появления предмета в слоте. А отличить исчезновение предмета в слоте от его замены можно, например, анализируя значение robot.count() при получении сигнала. Есть ещё один нюанс. Робот настолько медлителен, что за время, пока он перекладывает предмет, игрок может изменить состояние одного слота несколько раз. Поэтому накопившиеся события следует обрабатывать сразу пачкой, а не по одному. А перед чтением информации о предмете и отправкой его в реактор надо проверять, не прилетело ли очередное событие по этому слоту. Так как алгоритм обработки inventory_changed рискует сильно усложниться, то можно просто написать в инструкции пользователя, что если игрок извлекает предметы из инвентаря робота в процессе загрузки компонентов в реактор, то правильность работы программы не гарантируется.

Для начала рекомендую почитать об отличиях прямых вызовов от непрямых. Статья полезная, но даже если не знать теорию и названия, всегда можно обнаружить закономерности экспериментальным путём. И я сейчас попробую это продемонстрировать. Есть функция computer.uptime(), она возвращает время работы компьютера в секундах. Но время всегда пропорционально одному тику. Вычисляя разницу во времени, прошедшем от начала и до конца измерений, можно измерить скорость выполнения операций. Грубо, в тиках, но можно. Выполняя операции массово, в цикле, можно обнаружить, что некоторые операции всегда требуют целого количества тиков. Количество затрачиваемых тиков на некоторую определённую операцию всегда одинаково, и может задаваться в файле конфигурации. Это непрямые вызовы, и они замедлены намеренно. Также можно заметить, что во время лагов не только сервер снижает TPS ниже стандартных 20, но и вызовы периферии могут выполняться за большее количество тиков в сравнении с заданными значениями. Также существуют вызовы прямые. Они не отличаются от вызова обычных функций, и время затрачиваемое на их выполнение, очень мало. Какого-то фиксированного времени для их выполнения не существует. Время определяется быстродействием сервера и его текущей нагрузкой. А ещё есть не особо прямые вызовы. По терминологии, наверное, может проконсультировать @Fingercomp. Время, затрачиваемое на эти вызовы, не кратно размеру тика, но количество таких вызовах на протяжении тика ограничено некоторыми предельными значениями. Теперь практика. По счастливому стечению обстоятельств я не закрыл документ с текущими записями по этой теме. Записи такого вида я обычно не сохраняю в файлы, а веду их только для удобства вставки скриптов в консоль робота. Текущее содержимое документа (комментарии добавлены сейчас): -- Ссылка на получение времени time=computer.uptime -- Тестирование затрат времени на установку блока и его рубку -- Я уже знаю, что это непрямые вызовы, поэтому не использую сложных измерений -- Для исклчюения влияния случайных лагов повторяю выполнение скрипта раза три t0=time() robot.place() print(time()-t0) t0=time() robot.swing() print(time()-t0) -- Это пробная версия скрипта, рубящего руду -- Именно этот скрипт я выкладывал где-то в ранних постах этой темы t0=time() robot.select(1)while robot.suckUp() do for i=1,64 do robot.place()robot.swing()end for slot=4,1,-1 do robot.select(slot)robot.dropDown()end end print(time()-t0) -- Тут я проверял алгоритм выгрузки результатов переработки for slot=4,1,-1 do robot.select(slot)robot.dropDown()end -- Так я обычно пишу несложные программы -- Ничего не сохраняю в файлы, пишу скрипт в текстовом редакторе, -- а потом сворачиваю до одной строки для удобства копирования в консоль робота -- Самые простые скрипты сразу пишутся в одну строку ---------- рубщик руды time = computer.uptime while not robot.detect() do end t0=time() for i=1,64 do while not robot.swing() do end end print( time()-t0 ) time = computer.uptime while not robot.detect() do end t0=time() for i=1,64 do while not robot.swing() do end end print( time()-t0 ) ---------- установщик руды time = computer.uptime t0=time() for i=1,64 do while not robot.place() do end end print( time()-t0 ) time = computer.uptime t0=time() for i=1,64 do while not robot.place() do end end print( time()-t0 ) ---------- -- Похоже, вызов robot.count непрямой, операция заняла 0 тиков t0=time() robot.count(1) print(time()-t0) -- И сейчас 0 тиков t0=time() for i=1,1e2 do robot.count(1) end print(time()-t0) -- А сейчас 1 тик t0=time() for i=1,1e3 do robot.count(1) end print(time()-t0) -- Ну, ясно, быстрая операция. -- А как быстро выполняется выбор слота в роботе? t0=time() robot.select(1) print(time()-t0) -- И т.д... t0=time() robot.drop() print(time()-t0) t0=time() component.inventory_controller.getStackInInternalSlot(1) print(time()-t0) Полученная разница во времени не всегда кратна ровно размеру тика по причине погрешности вычислений. Но округление решает эту проблему. Для полной ясности можно сразу считать целые тики: print( ((time()-t0)/0.05+0.5)//1 ) Но мне обычно лень писать такой код во время разовых исследований. Да и есть шанс пропустить какое-то значимое расхождение с размером тика, превышающее погрешность вычислений. В программах я обычно использую что-то вроде такого: (dt*1e6+0.5)//1/1e6

Что ты имеешь в виду, говоря "заранее"? При таком подходе появляется риск сказать, что робот "заранее" просканировал инвентарь, заранее установил компоненты в реактор и заранее выключился, вообще не потратив времени на выполнение поставленной задачи. И вообще, заранее умер, чтобы не погибнуть в будущем. С точки зрения игрока робот может выполнять работу параллельно тому, как игрок закидывает компоненты в инвентарь робота. Учитывая, что в инвентаре игрока всего 36 слотов, ему придётся сделать две ходки. За это время робот может успеть выполнить часть работы. С этим можно согласиться. Если бы робот автоматически пополнял свой инвентарь все необходимым, то он бы мог знать эту информацию ещё до контакта с реактором. Но по условиям задачи эту работу выполняет игрок. Правда, выяснилось это не сразу. С точки зрения нагрузки на сервер не имеет значения, что было сделано заранее, а что было сделано позже. Главное, что оно было сделано, а сервер потратил ресурсы на выполнение этих операций. Максимум, что может программист, это по возможности уменьшить количество операций, выполняемых сервером. Когда содержимое всех слотов уже известно, то при ожидании пополнения новых предметов нет смысла сканировать весь инвентарь. Для этого достаточно анализировать событие inventory_changed, оно сообщает номер изменившегося слота. Оно не реагирует на изменение количества предметов в слоте, но для этого существует быстрая операция robot.count(slot). Но даже при умелом использовании inventory_changed на этапе старта программы о содержимом инвентаря робота ничего неизвестно. Оптимальный алгоритм мне видится таким: Грубо сканируем весь инвентарь с помощью robot.count(slot). Это позволит в дальнейшем не тратить время на работу с пустыми слотами. В процессе работы следим за событием inventory_changed, на ходу корректируя список ещё необработанных слотов и убирая из списка освободившиеся слоты. В произвольном порядке выполняем getStackInInternalSlot(slot) для непустых слотов, обнаруживая полезные для реактора компоненты. При обнаружении слота с полезным компонентом выполняем robot.select() и dropIntoSlot(). Количество вызовов robot.select() можно незначительно сократить, отдавая приоритет в обработке текущему слоту, если, конечно, он не пуст. Я мог упустить ещё какой-то момент, поэтому предлагайте свои оптимизации. Приведённый алгоритм предполагает, что реактор на момент старта программы пуст, и не учитывает ситуаций, когда реактор частично заполнен, или параллельно заполняется другим роботом или игроком. Если алгоритм оптимален, то, конечно, выкладывай. Всем будет лучше, если лагодромщики возьмут твоё правильное решение, а не станут тиражировать свои непроработанные варианты с переливанием из пустого в порожнее. Это, конечно, не умаляет их труда, они могли долго идти к своему решению и постепенно улучшать его, но тут у нас коллективный разум, с которым сложно конкурировать. Я колебался, предложить ли схему на микроконтроллере, но, похоже, не надо. Автор заказа проигнорировал часть моих вопросов, и может оказаться, что микроконтроллер там вообще не уместен. Кроме того, транспозер быстрее работает в основном за счёт уменьшения задержек, искусственно добавленных для робота. Поэтому вряд ли стоит рекомендовать такое решение лагодромщикам.

Не понял. А за 0.33 секунды может что ли заполнить весь реактор? По моим прикидкам это число должно быть на два порядка больше. Если в инвентаре робота нет лишних компонент, то схему можно выложить за 32.4 сек: 0.05 сек на считывание стака 0.05 сек на выбор ячейки 0.50 сек на перенос предмета в реактор повторить 54 раза 33 секунды дают запас времени на анализ 12 лишних компонент, случайно оказавшихся в инвентаре робота.

По теме: Я ознакомился с кодом. Скажу ту же мысль, что и в теме с заказом программы переработки руды: здесь в первую очередь надо продумывать общую схему, а не отдельную программу. Поэтому снова будет много вопросов. В программе есть дублирование robot.select(), которого несложно избежать. Но эта оптимизация не даст значительного прироста производительности. Остальные же, более жирные оптимизации возможны только на уровне всей системы из 324 реакторов. Главный вопрос: эта куча реакторов строится за один раз или постепенно? Если за один раз, то зачем долго копить реакторы на складе, в то время как они могли бы уже работать? А если постепенно, то зачем этой схеме быстродействие? Неужели ресурсы на реакторы собираются так быстро? Реакторы строятся руками или роботами? В случайном порядке по ситуации или по сетке? Какие коммуникации подведены к реакторам кроме кабелей, отводящих энергию? Эти 9 приватов, каждый по 9 чанков являются смежными? Они позволяют построить единую площадку для реакторов? Или же приваты разбросаны по карте? Как осуществляется обмен ресурсами между приватами? Каким образом предполагается использовать эту программу? Игроком подойти к реактору, поставить к нему робота, закинуть в него компоненты и ждать, пока они выложатся в нужном порядке? А если какого-то компонента не хватит? Порядок будет нарушен, а программа даже не предупредит об этом. Без доработки программы такое использование не годится. Или же это лишь часть другой программы, которая где-то загружает компоненты, подползает к реактору и заполняет его по шаблону? Тогда роботу вообще не надо знать, что находится у него в инвентаре. Ему достаточно знать соответствие слотов собственного инвентаря слотам реактора. Это позволит исключить лишние действия с контроллером инвентаря, который работает слишком медленно в сравнении с транспозером.

Тогда у меня две группы вопросов к тебе, как информированному человеку: Что побуждает игроков вашего сервера строить поле из 300+ реакторов? Зачем им столько энергии? Что они с ней делают? Что мешает администрации сервера выполнить сет_нуль всех этих полей из реакторов?

Назвать это "не пойми что" мы можем как угодно. Смысл от этого всё равно не проясняется. Предлагаю два варианта: Кинуть этот заказ в корзину, чтобы не отвлекать людей на чтение заведомо бесполезной темы. Сформулировать техзадание в понятном для программиста виде.

Тогда это не заказ, а квест: пойди туда, не знаю куда, принеси то, не знаю что.

И как, руководствуясь этим описанием, ты предлагаешь конвертировать изображение?

Эти слова мало о чём говорят. Где описание формата?

@nikitaaaaa Что такое ".pic"? Где описание формата?

Что мы имеем по результатам обсуждения в дискорде: • 16 TPS это именно 16 TPS. Тикрейт на сервере не повышенный, а пониженный. И не специально, а по причине лагодромов. Соответственно, тикрейт может только замедлять чудо-схему с предполагаемой скоростью переработки в 20 блок/сек. • Предполагается, что чудо-схема отличается от описанной в теме лишь программным кодом, что и делает того программиста "афигенным". Но что там за волшебный код, мы не знаем. • Лагодромщики, пытаясь экономить на дорогих инструментах, используют асинхронно работающих роботов в своих схемах и творят прочую дичь. В результате администрация сервера ограничила количество зарядников до одного на чанк. Этот подход не гарантирует отсутствия лагодромов, но усложняет их масштабирование. • Из предыдущего пункта следует вывод: какие бы способы масштабирования схемы мы в этой теме ни реализовали, они окажутся публичными, и рано или поздно администрация сервера начнёт борьбу уже с ними. Поэтому отметаем такой способ увеличения производительности, или делаем это втихаря среди узкого круга посвящённых. Я до конца не уверен, является ли заявление автора розыгрышем, или же он сам стал жертвой розыгрыша. Но я попытался исследовать тему настолько глубоко, насколько хватило опыта: Самым узким местом обсуждаемой схемы является установка блоков. Я знаю только два способа ускорения этой операции: правка конфигов или увеличение тикрейта. Правка конфигов исключена, т.к. она ускорила бы операцию установки блоков роботами на всём сервере для всех игроков, чего не наблюдалось. Глобальный тикрейт оказался даже ниже стандартного, но не исключена возможность локального увеличения тикрейта с помощью модов, например, ProjectE. Аргейд опыта также не может ускорить установку блоков роботом. Поэтому при стандартных настройках теоретически максимально возможная скорость установки блоков составляет 2.5 блок/сек. Скорость добычи блока можно повышать чарами на эффективность и апгрейдом опыта. Но пределом является скорость 6.66 блок/сек. На добычу блока роботом тратится минимум три тика (0.15 сек), даже если добывается блок грязи максимально эффективной киркой и с полностью прокачанным апгрейдом опыта. Для того, чтобы скорость установки блоков превзошла скорость их добычи, необходимы три робота на установку блоков. Три робота могут устанавливать блоки со скоростью 7.5 блок/сек. Но эта скорость будет ограничена добывающим роботом. Выше 6.66 она не поднимется. Исходя из этого простой вариант схемы мне видится таким: Вокруг зарядника стоят 4 робота лицом к заряднику. Под одним из роботов расположен энергохранитель для заряда инструмента. За спинами роботов стоят интерфейсы для загрузки руды и выгрузки полученных материалов. В этом положении роботы подзаряжаются, заряжают инструмент и ожидают пополнения запаса руды в своих инвентарях. По команде роботы поднимаются на один блок вверх, трое из них выставляют блоки руды, а четвёртый рубит. По завершении переработки порции руды роботы возвращаются на исходную позицию, делая шаг на один блок вниз, и весь цикл повторяется с начала, если остались ресурсы для переработки. Плюсом этой схемы является экономия на дорогом инструменте. Плюс сомнительный, т.к. при наличии апргрейда опыта иридиевый бур выполняет работу не хуже вадржы. Апргдейд опыта даже алмазную кирку с эффективностью 4 уровня делает не хуже ваджры. Теперь попробую оценить эффективность расходования ресурсов сервера этой схемой. В схеме с двумя роботами робот-установщик выполняет одно действие каждые 8 тиков. Робот-добытчик на протяжении этих 8 тиков делает один успешный взмах киркой за 3 тика, а оставшиеся 5 тиков тратит на бесполезные взмахи киркой. Получается 5 бесполезных действий на каждые 8 тиков или на каждый обработанный блок руды. В схеме с тремя роботами-установщиками непрерывно работает только робот-добытчик. Если сервер не лагает, то каждый взмах кирки успешен. Роботы-установщики рано или поздно самосинхронизируются, но для поддержания синхронизации роботы выполняют избыточные действия. Для непрерывного обеспечения робота-добытчика блоками каждый из трёх роботов-установщиков должен устанавливать блоки со скоростью 2.22 блок/сек (с интервалом 9 тиков). На успешную установку блока робот тратит 8 тиков. Оставшийся тик тратится на неудачную установку. Это значит, что робот выполняет одно бесполезное действие на каждый блок руды. Эффективность новой схемы также будет плюсом в сравнении с изначальным вариантом. Казалось бы, это успех, но нет. Схема с четырьмя независимыми роботами всё равно более эффективно расходует ресурсы сервера. Каждое выполненное действие ведёт к успеху. На каждый обработанный блок руды тратится одна установка блока и одна добыча. Заодно и роботов никуда не надо двигать. Вместо одного MFSU потребуется установить 4 MFE для зарядки инструмента. А для экономии на инструменте роботам вместо ваджры можно выдать иридиевые буры и апгрейды опыта, раскачанные до 25 уровня. И ещё важный момент: я ошибся в порядке чисел. robot.select требует на выполнение не 10 тиков, а 1 тик. Поэтому, оптимизировав её использование, мы сможем получить ускорение не в 2.2 раза, а всего в 1.12 раз. Впрочем, и 12% это тоже хорошо. Но разумнее будет получить выигрыш в 44%, перейдя на схему с независимыми друг от друга роботами.

Поступила жалоба на оффтоп в этой теме. Да, оффтоп уже развился, но я не знаю, как с ним правильно поступить. Пусть пока остаётся как есть. У автора темы очень специфические заказы. Их сложно обсуждать в отрыве от темы лагодромов. 16 TPS на сервере это ненормально. Каков вклад в лаги сервера со стороны автора темы, это вопрос дискуссионный, но обсуждение желательно вести с доказательствами и какими-нибудь методиками измерения. Надо выяснять, что именно там сильнее всего нагружает сервер. Сообщество computercraft.ru не заинтересовано помогать строительству лагодромов. Чем больше лагодромов будет создано с помощью компьютеров, тем меньше будет шансов встретить OpenComputers и ComputerCraft на серверах Майнкрафта. Такая перспектива не радует. Но сообщество заинтересовано помогать лагодромщикам в поиске схем, более эффективно расходующих ресурсы сервера. Если на производство какой-нибудь лепёшки можно затратить 2 действия вместо 10, то пусть лагодромщик выберет более экономный вариант. Тогда компьютерные моды будут меньше раздражать администраторов серверов. Предлагаю сосредоточиться на оптимизации программ, если кому интересно. А судьбу 300 спартанцев реакторов пусть решает администрация сервера.

Спокуха, братуха! Мой код не подзаряжает инструмент, поэтому не может закрыть заказ. Другое дело, что автор темы настаивает на использовании изначально неудачной схемы, придуманной "афигенным программистом". Это сильно снижает привлекательность дальнейшей работы над заказом.

Эксперимент, описанный в том же посте, чуть выше: В изначальной схеме один робот устанавливает блок перед собой, а другой рубит блок перед собой. На установку блока требуется 8 тиков, а на его добычу 5 тиков. Если бы эти две операции были совершенно не пригодны к распараллеливанию, то полная итерация цикла требовала бы 13 тиков на своё выполнение. В случае же полного распараллеливания итерация должна занимать 8 тиков. Повторюсь, использован только один блок пространства для установки и рубки блоков. Полное распараллеливание операций установки-рубки достигается также и при использовании инструмента, добывающего блок за 7 тиков. Но если инструмент добывает блок за 8 тиков, то распараллеливание не всегда бывает полным: на установку стака блоков уходит 25.65 сек, то есть примерно одна из 64 попыток установки блока занимает 9 тиков вместо положенных 8. При появлении даже несущественных лагов сервера количество итераций с неполным параллелизмом возрастает ещё сильнее.

Хорошо, к чёрту схему. Рекомендую в программе установщика отказаться от выполнения robot.select на каждой итерации. Эта операция требует 10 тиков. При этом на выполнение основной задачи (установка блока) требуется всего 8 тиков. А учитывая, что самым узким местом оказывается именно установка блоков, только эта одна оптимизация позволит ускорить работу схемы в 2.2 раза.

Почему четыре-то? Куб имеет шесть граней. Обычно у зарядника одна из граней занята кабелем или ещё каким-то блоком. Но ничто не мешает запитать его удалённо через MFU в адаптере через 2 блока. Если не нравятся перемещающиеся роботы, можно использовать шесть стационарных на одном заряднике. В каждом чанке.

А какие там ещё имеются ограничения? Потому что изначально говорилось: Но потом выяснилось, что и ваджра дорого стоит, и количество механизмов ограничено. Если есть ограничение на количество зарядок и энергохранителей, то схему можно масштабировать следующим образом: Робот подползает к зарядке, кидает в MFSU свой бур, в это время заряжается сам, выгружает переработанные ресурсы, забирает свежую руду. По завершении зарядки робот отползает в сторонку и перерабатывает несколько стаков свежей руды. В это время к зарядке подползает следующий робот, а зарядившись, встаёт рядом с первым роботом. И так далее вплоть до такого количества роботов, пока они успевают последовательно заряжаться друг за другом. Далее всё повторяется по кругу. Кроме того, вокруг зарядки имеется 6 точек, в которых робот может зарядиться. Но тут надо знать, какие ещё имеются ограничения на сервере.

А обязательно придерживаться именно этой схемы? Что мешает использовать несколько зарядников и MFSU по количеству использованных роботов?

Два робота с иридиевыми бурами перерабатывают руду быстрее, чем пара из робота-установщика и робота, оснащённого ваджрой.

Стандартное значение 20 TPS. При 16 TPS сервер будет работать медленнее стандартного. Но если тикрейт составит 160 TPS, то и вправду скорость с заданных 2.5 блок/сек возрастёт до 20 блок/сек. Но это уже не имеет отношения ни к программированию, ни к оптимизации. Я провёл эксперимент. Действительно, операции полностью распараллеливаются при использовании достаточно быстрого инструмента. Робот-установщик установил 64 блока за 25.6 секунд, затрачивая на каждую операцию стандартно отведённые для этого 8 тиков. Скорость переработки руды в этой схеме составляет 2.5 блок/сек. Получается, что нет смысла в использовании ваджры, достаточно даже скорости иридиевого бура. Но всё равно два независимых робота смогут перерабатывать руду со скоростью 3.6 блок/сек при использовании ваджры в каждом из них, что лучше в 1.44 раза в сравнеии с изначальной схемой. При использовании иридиевого бура результат улучшается всего в 1.2 раза. Хорошая идея, но запоздалая. Если описанный выше эксперимент воспроизводится, то схема с двумя точками установки блоков лишается смысла. Впрочем, схема со вспомогательным роботом всегда имела смысл только по причине экономии на дорогом инструменте.

Можно сделать гораздо дешевле. Для работы программы нужен корпус второго уровня, процессор первого, самая дешёвая планка памяти, EEPROM, инвентарь и контроллер инвентаря. На стандартном конфиге OpenComputers схема с двумя роботами, один из которых вспомогательный, не позволит даже приблизиться к скорости переработки в 20 блок/сек. Скорость установки блоков ограничена значением 2.5 блок/сек. Это потолок. Даже если предположить, что операции установки и срубания блока могут выполняться полностью параллельно, то выше этой скорости всё равно не прыгнуть. А это предположение вряд ли верно. Возможно, частичное наложение операций и присутствует, но оно точно не полное. Реальная скорость будет меньше. Схема без вспомогательного робота перерабатывает руду со скоростью 1.8 блок/сек при использовании ваджры. А два таких робота будут перерабатывать руду со скоростью 3.6 блок/сек, что уже получается в 1.44 раза быстрее схемы со вспомогательным роботом.

Скорость переработки как раз самая банальная задача. Приведённый мной скрипт рубит руду с максимально возможной для робота скоростью. Там только алгоритм выгрузки не очень эффективен. Поэтому следующий вопрос связан именно с логистикой. Например, если взаимодействие с системой хранения можно осуществить через один сундук, то можно будет реализовать заряд инструмента без поворотов. А может быть, вообще, в системе хранения предусмотрен централизованный заряд инструмента, и достаточно будет лишь поменять инструмент на свежий. Это очень избыточно для такой задачи. Для чего так дорого?