Доработка программы для переработки руды

[demongts1998 Автор темы 6]

5 минут назад, eu_tomat сказал:

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

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

 

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

возможно я смогу поизголятся и запихать 3х роботов и 2 з\у ( ограничение зарядки, 1 на чанк )

 

[eu_tomat 2 158]

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

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

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

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

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

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

 

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

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

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

[demongts1998 Автор темы 6]

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

вокруг зарядки имеется 6 точек

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

[eu_tomat 2 158]

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

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

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

 

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

[demongts1998 Автор темы 6]

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

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

 

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

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

[eu_tomat 2 158]

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

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

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

 

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

 

 

[hohserg 197]

2 часа назад, eu_tomat сказал:

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

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

[demongts1998 Автор темы 6]

2 часа назад, eu_tomat сказал:

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

все бы хорошо, но я великий чайник в программировании

я сюда и пришел чтобы мне помогли допилить код робота

[eu_tomat 2 158]

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

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

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

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

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

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

 

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

[Asior 586]

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

[eu_tomat 2 158]

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

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

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

 

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

 

[demongts1998 Автор темы 6]

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

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

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

 

[eu_tomat 2 158]

Что мы имеем по результатам обсуждения в дискорде:

 

    • 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%, перейдя на схему с независимыми друг от друга роботами.

[hohserg 197]

 

В 02.12.2020 в 17:14, eu_tomat сказал:

В схеме с двумя роботами робот-установщик выполняет одно действие каждые 8 тиков. Робот-добытчик на протяжении этих 8 тиков делает один успешный взмах киркой за 3 тика, а оставшиеся 5 тиков тратит на бесполезные взмахи киркой. Получается 5 бесполезных действий на каждые 8 тиков или на каждый обработанный блок руды.

Как были произведены такие точные измерения?

[eu_tomat 2 158]

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

Как были произведены такие точные измерения?

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

 

Есть функция 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

 

 

 

[demongts1998 Автор темы 6]

интересно, интересно, пока что на сервере решаем проблему крафта роботов, будем решать что как делать

[eu_tomat 2 158]

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

интересно, интересно, пока что на сервере решаем проблему крафта роботов, будем решать что как делать

А крафт роботов стал проблемой?

[demongts1998 Автор темы 6]

20 минут назад, eu_tomat сказал:

А крафт роботов стал проблемой?

скорее негодованием, ввели крафт за донат валюту, которую можно получить по 30 в день ( крафт стоит 60 )

 

[eu_tomat 2 158]

В 07.12.2020 в 00:37, demongts1998 сказал:

ввели крафт за донат валюту, которую можно получить по 30 в день ( крафт стоит 60 )

Раз ценность роботов так повысилась, то, может быть, стоит использовать схему на одном роботе?  Благодаря этом робот быстрее отработает свою цену.

 

При желании можно установить четыре таких робота вокруг одного зарядника.

[serafim 272]

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

перепробовал пол сотни вариантов пока получилось хоть что-то не сильно лагучее

 

Два робота совместно ставят и рубят один и тот же блок получая ускорение

Скрытый текст

вид сзади

Скрытый текст

собственно ссылка на это недоразумене https://pastebin.com/FvGE1qYa

 

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

 

Руду закидывать в сундук над роботом, лут получим снизу как только робот переработает пачку руды

 

Можно использовать от одного до четырёх роботов по кругу (насчёт насколько это будет быстрей, х.з.)

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

Изменено 12 декабря, 2020 пользователем serafim