Лидеры

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

Для начала рекомендую почитать об отличиях прямых вызовов от непрямых. Статья полезная, но даже если не знать теорию и названия, всегда можно обнаружить закономерности экспериментальным путём. И я сейчас попробую это продемонстрировать. Есть функция 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

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

https://pastebin.com/xPzTDkrB пример использования: gcam south 16