eu_tomat

1 час назад, hohserg сказал:

Робот может заранее просканировать свой инвентарь и в оперативной памяти хранить его представление. Если считать, что в середине работы в робота не будут подкидываться предметы, то такой подход позволит без ошибки выбирать слот для извлечения предмета "вслепую".

Что ты имеешь в виду, говоря "заранее"? При таком подходе появляется риск сказать, что робот "заранее" просканировал инвентарь, заранее установил компоненты в реактор и заранее выключился, вообще не потратив времени на выполнение поставленной задачи. И вообще, заранее умер, чтобы не погибнуть в будущем.

С точки зрения игрока робот может выполнять работу параллельно тому, как игрок закидывает компоненты в инвентарь робота. Учитывая, что в инвентаре игрока всего 36 слотов, ему придётся сделать две ходки. За это время робот может успеть выполнить часть работы. С этим можно согласиться. Если бы робот автоматически пополнял свой инвентарь все необходимым, то он бы мог знать эту информацию ещё до контакта с реактором. Но по условиям задачи эту работу выполняет игрок. Правда, выяснилось это не сразу.

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

Когда содержимое всех слотов уже известно, то при ожидании пополнения новых предметов нет смысла сканировать весь инвентарь. Для этого достаточно анализировать событие inventory_changed, оно сообщает номер изменившегося слота. Оно не реагирует на изменение количества предметов в слоте, но для этого существует быстрая операция robot.count(slot).

Но даже при умелом использовании inventory_changed на этапе старта программы о содержимом инвентаря робота ничего неизвестно.

Оптимальный алгоритм мне видится таким:

• Грубо сканируем весь инвентарь с помощью robot.count(slot). Это позволит в дальнейшем не тратить время на работу с пустыми слотами.
• В процессе работы следим за событием inventory_changed, на ходу корректируя список ещё необработанных слотов и убирая из списка освободившиеся слоты.
• В произвольном порядке выполняем getStackInInternalSlot(slot) для непустых слотов, обнаруживая полезные для реактора компоненты.
• При обнаружении слота с полезным компонентом выполняем robot.select() и dropIntoSlot().
• Количество вызовов robot.select() можно незначительно сократить, отдавая приоритет в обработке текущему слоту, если, конечно, он не пуст.

Я мог упустить ещё какой-то момент, поэтому предлагайте свои оптимизации.

Приведённый алгоритм предполагает, что реактор на момент старта программы пуст, и не учитывает ситуаций, когда реактор частично заполнен, или параллельно заполняется другим роботом или игроком.

9 часов назад, serafim сказал:

выкладывать или нет ?

Если алгоритм оптимален, то, конечно, выкладывай. Всем будет лучше, если лагодромщики возьмут твоё правильное решение, а не станут тиражировать свои непроработанные варианты с переливанием из пустого в порожнее. Это, конечно, не умаляет их труда, они могли долго идти к своему решению и постепенно улучшать его, но тут у нас коллективный разум, с которым сложно конкурировать.

Я колебался, предложить ли схему на микроконтроллере, но, похоже, не надо. Автор заказа проигнорировал часть моих вопросов, и может оказаться, что микроконтроллер там вообще не уместен. Кроме того, транспозер быстрее работает в основном за счёт уменьшения задержек, искусственно добавленных для робота. Поэтому вряд ли стоит рекомендовать такое решение лагодромщикам.

7 минут назад, serafim сказал:

робот не может выставлять схему в реакторе из 54 компонентов быстрее 0,33 секунды

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

• 0.05 сек на считывание стака
• 0.05 сек на выбор ячейки
• 0.50 сек на перенос предмета в реактор
• повторить 54 раза

33 секунды дают запас времени на анализ 12 лишних компонент, случайно оказавшихся в инвентаре робота.

По теме:

Я ознакомился с кодом. Скажу ту же мысль, что и в теме с заказом программы переработки руды: здесь в первую очередь надо продумывать общую схему, а не отдельную программу. Поэтому снова будет много вопросов.

В программе есть дублирование robot.select(), которого несложно избежать. Но эта оптимизация не даст значительного прироста производительности. Остальные же, более жирные оптимизации возможны только на уровне всей системы из 324 реакторов.

Главный вопрос: эта куча реакторов строится за один раз или постепенно? Если за один раз, то зачем долго копить реакторы на складе, в то время как они могли бы уже работать? А если постепенно, то зачем этой схеме быстродействие? Неужели ресурсы на реакторы собираются так быстро?

Реакторы строятся руками или роботами? В случайном порядке по ситуации или по сетке? Какие коммуникации подведены к реакторам кроме кабелей, отводящих энергию?

Эти 9 приватов, каждый по 9 чанков являются смежными? Они позволяют построить единую площадку для реакторов? Или же приваты разбросаны по карте? Как осуществляется обмен ресурсами между приватами?

Каким образом предполагается использовать эту программу?

• Игроком подойти к реактору, поставить к нему робота, закинуть в него компоненты и ждать, пока они выложатся в нужном порядке? А если какого-то компонента не хватит? Порядок будет нарушен, а программа даже не предупредит об этом. Без доработки программы такое использование не годится.
• Или же это лишь часть другой программы, которая где-то загружает компоненты, подползает к реактору и заполняет его по шаблону? Тогда роботу вообще не надо знать, что находится у него в инвентаре. Ему достаточно знать соответствие слотов собственного инвентаря слотам реактора. Это позволит исключить лишние действия с контроллером инвентаря, который работает слишком медленно в сравнении с транспозером.

38 минут назад, whiskas сказал:

Я знаю что. В основному реакторы и механизмы. Просто я знаю о каком он сервере говорит.
Там потому и ввели ограничение на реакторы ибо их ставили по 200 штук в чанк

Тогда у меня две группы вопросов к тебе, как информированному человеку:

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

2 минуты назад, nikitaaaaa сказал:

ну частично согласен а вот принести то не знаю что с этим не согласен потому что принисти надо Онлайн конвертер в .pic

Назвать это "не пойми что" мы можем как угодно. Смысл от этого всё равно не проясняется.

Предлагаю два варианта:

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

1 минуту назад, nikitaaaaa сказал:

Ну я хз описание его, там вроде-бы в мультискрин этот формат используется

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

2 минуты назад, nikitaaaaa сказал:

Файл PIC представляет собой растровое изображение, которое может быть создано различным программным обеспечением, например, IBM Lotus, Advanced Art Studio, Micrografx Draw. Для просмотра графики в формате PIC подойдут такие программы, как XnView MP, ACDSee Photo Studio, Corel PaintShop Pro и некоторые другие.

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

8 минут назад, nikitaaaaa сказал:

OpenComputers image (pic) есть еще  конвертер на "java" от ECS

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

@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 спартанцев реакторов пусть решает администрация сервера.

25 минут назад, Asior сказал:

Тебе код уже дали, чего еще то надо? Параллельно перепроверили теорию о том "что 2 робота справятся с переработкой руды быстрее" и опровергли её.

Спокуха, братуха! Мой код не подзаряжает инструмент, поэтому не может закрыть заказ.

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

5 часов назад, hohserg сказал:

Не очень понял. В чем состоит эксперимент?

Эксперимент, описанный в том же посте, чуть выше:

8 часов назад, eu_tomat сказал:

Я провёл эксперимент. Действительно, операции полностью распараллеливаются при использовании достаточно быстрого инструмента. Робот-установщик установил 64 блока за 25.6 секунд, затрачивая на каждую операцию стандартно отведённые для этого 8 тиков. Скорость переработки руды в этой схеме составляет 2.5 блок/сек. Получается, что нет смысла в использовании ваджры, достаточно даже скорости иридиевого бура.

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

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

3 минуты назад, demongts1998 сказал:

меня больше интересует программа которая будет быстро работать, со схемой я и сам справлюсь

Хорошо, к чёрту схему.

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

1 минуту назад, demongts1998 сказал:

точки 4, и роботы которые ползают куда - то слишком трудозатратно, лучше парочка стационарных

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

Если не нравятся перемещающиеся роботы, можно использовать шесть стационарных на одном заряднике. В каждом чанке.

1 минуту назад, demongts1998 сказал:

ограничения серва

А какие там ещё имеются ограничения? Потому что изначально говорилось:

10 часов назад, demongts1998 сказал:

ресурсы условно безграничны

Но потом выяснилось, что и ваджра дорого стоит, и количество механизмов ограничено.

Если есть ограничение на количество зарядок и энергохранителей, то схему можно масштабировать следующим образом:

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

Кроме того, вокруг зарядки имеется 6 точек, в которых робот может зарядиться. Но тут надо знать, какие ещё имеются ограничения на сервере.

31 минуту назад, demongts1998 сказал:

вот схема для роботов которую я использовал ранее, вид сверху

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

1 минуту назад, demongts1998 сказал:

лучше использовать 1 рубящего робота, т.к. ваджра очень дорогая в крафте на проекте в который я играю

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

24 минуты назад, demongts1998 сказал:

тикрейт сервера: 16 тиков

Стандартное значение 20 TPS. При 16 TPS сервер будет работать медленнее стандартного. Но если тикрейт составит 160 TPS, то и вправду скорость с заданных 2.5 блок/сек возрастёт до 20 блок/сек. Но это уже не имеет отношения ни к программированию, ни к оптимизации.

27 минут назад, demongts1998 сказал:

если поставить 2 робота которые ставят руду и 1 который рубит, насколько это ускорит процесс?

Я провёл эксперимент. Действительно, операции полностью распараллеливаются при использовании достаточно быстрого инструмента. Робот-установщик установил 64 блока за 25.6 секунд, затрачивая на каждую операцию стандартно отведённые для этого 8 тиков. Скорость переработки руды в этой схеме составляет 2.5 блок/сек. Получается, что нет смысла в использовании ваджры, достаточно даже скорости иридиевого бура.

Но всё равно два независимых робота смогут перерабатывать руду со скоростью 3.6 блок/сек при использовании ваджры в каждом из них, что лучше в 1.44 раза в сравнеии с изначальной схемой. При использовании иридиевого бура результат улучшается всего в 1.2 раза.

3 минуты назад, hohserg сказал:

А что, если сделать такую схему: красный робот ставит зеленые блоки перед собой и под собой, а синий ломает перед собой и над собой?

Хорошая идея, но запоздалая. Если описанный выше эксперимент воспроизводится, то схема с двумя точками установки блоков лишается смысла.

Впрочем, схема со вспомогательным роботом всегда имела смысл только по причине экономии на дорогом инструменте.

16 минут назад, demongts1998 сказал:

крафт роботов дешевый, 2 чтобы быстрее работали: 1й ставит, 2й рубит

Можно сделать гораздо дешевле. Для работы программы нужен корпус второго уровня, процессор первого, самая дешёвая планка памяти, EEPROM, инвентарь и контроллер инвентаря.

2 минуты назад, demongts1998 сказал:

как раз 2

7 часов назад, demongts1998 сказал:

обычно юзали 2 и я видел как афигенный програмист на серве написал прогу и показал это мне ( роботы рубили порядка 20 руды за секунду мб поменьше )

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

Схема без вспомогательного робота перерабатывает руду со скоростью 1.8 блок/сек при использовании ваджры. А два таких робота будут перерабатывать руду со скоростью 3.6 блок/сек, что уже получается в 1.44 раза быстрее схемы со вспомогательным роботом.

9 минут назад, demongts1998 сказал:

потому надо как то решить проблему скорости переработки, а вот уже то как извлечь\хранить\доставить это другой, менее важный вопрос

Скорость переработки как раз самая банальная задача. Приведённый мной скрипт рубит руду с максимально возможной для робота скоростью. Там только алгоритм выгрузки не очень эффективен. Поэтому следующий вопрос связан именно с логистикой.

Например, если взаимодействие с системой хранения можно осуществить через один сундук, то можно будет реализовать заряд инструмента без поворотов. А может быть, вообще, в системе хранения предусмотрен централизованный заряд инструмента, и достаточно будет лишь поменять инструмент на свежий.

3 минуты назад, demongts1998 сказал:

вот как выглядит сборка 2 роботов

Это очень избыточно для такой задачи. Для чего так дорого?

4 часа назад, demongts1998 сказал:

Требования к ПО: правильно расставлять схему,  и делать это быстро.

А в чём текущая проблема? Схема расставляется недостаточно правильно или недостаточно быстро?

5 часов назад, demongts1998 сказал:

ресурсы условно безграничны, т.к. на роботов я готов потратить достаточно много, обычно юзали 2 и я видел как афигенный програмист на серве написал прогу и показал это мне ( роботы рубили порядка 20 руды за секунду мб поменьше )
мы не копим руду, просто нас много ( 15 человек и руды аля драконьевой, алмазов, перидота, рубинов, сапфиров крайне много роботы не успевают перестукивать )
про кол-во роботов: от них высокая нагрузка, да и реализация так себе, но на руду они нужны
+ основная задача - нужны роботы для варпа, а с учетом того что человек может принести 10к+ руды нужна скорость
роботы копали ваджрой на эфективность5+удача5

Ваджра из Gravitation Suite? Робот с её помощью вроде бы рубит руду за три тика независимо от чар эффективности. Установка руды выполняется за восемь тиков. Всего требуется 11 тиков на полный цикл переработки руды. Получается, что скорость переработки руды в 20 блок/сек достигается с помощью 11 роботов. Кстати, а сколько роботов задействовал "афигенный програмист"?

Для достижения скорости переработки 20 блок/сек при использовании иридиевого бура потребуется 13 роботов. Конечно же, без учёта времени презарядки инструмента.

Я провёл эксперимент:

• В слот инструмента робота поместил полностью заряженный иридиевый бур.
• Над роботом установил сундук и поместил в него 48 стаков алмазной руды (3072 блока).
• Под роботом установил пустой алмазный сундук на 108 слотов.
• Слева от робота установил зарядное устройство.
• Запустил простой скрипт:

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

За 36 минут робот переработал все 48 стаков алмазной руды из верхнего сундука и поместил полученные алмазы в нижний сундук. Свободными оказались два последних его слота. Остаток заряда в буре: 54.2 из 300 kEU.

Как можно ускорить этот процесс?

• Использование ваджры позволит сэкономить 5 минут на ускорении рубки, и, возможно несколько секунд на перезарядке инструмента, что не очень много на фоне 36 минут.
• Можно оптимизировать алгоритм очистки инвентаря робота, что позволит выиграть около 20 секунд, что тоже немного.
• Масштабировать схему на несколько роботов. В этом случае скорость возрастёт кратно.

Возникает вопрос, как именно предполагается масштабировать переработку. Схема переработки руды будет зависеть в первую очередь от используемой системы хранения. Я вижу такие варианты:

• При наличии AE можно пополнять и освобождать сундуки МЭ-шинами или даже вообще обойтись без сундуков.
• Вручную раскидать руду по сундукам над роботами.
• При использовании системы хранения на сундуках и транспозерах главная сложность будет заключаться уже не в переработке руды, а в логистике.

Но в условиях задачи про систему хранения ничего не сказано. А здесь вообще что-то непонятное:

21 час назад, demongts1998 сказал:

Оборудование: роботы, сервомеханизмы\поисковики

Что такое сервомеханизмы и поисковики?

10 часов назад, demongts1998 сказал:

очень быстрая переработка руды

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

Схема перерубки руды на двух роботах имеет смысл лишь в случаях использования очень дорогих или редких кирок. В противном случае предложенная схема оказывается неэффективной, и появляется смысл реализовать схему на одном роботе. Или на двух, но с одинаковой программой. Или даже на сотне или тысяче одинаковых роботов, если сервер справляется с нагрузкой, и другие игроки не возражают.

11 час назад, demongts1998 сказал:

руды приходится перерабатывать по 60к+ минимум, и крайне долго это все делается обычными роботами ( приходится на ночь в афк вставать

За какое время требуется перерабатывать такое количество руды? Также возникает вопрос, зачем копить такое количество руды, и затем стоять AFK, если руду можно перерабатывать постепенно, по мере её накопления, параллельно занимаясь другими задачами? Или даже по мере добычи руды, поставив такую схему рядом с буровой установкой.

1 час назад, nikitaaaaa сказал:

я уже наговнокодил какую-то фигню

А вопрос-то в чём?