Лидеры

В этом случае резервирование прочности инструмента фискированным куском способствует не столько минимизации затрат времени, сколько упрощению кода. Но, например, в случае протяжённых челночных перемещений робота таки образом можно было бы экономить и время тоже. На сравнительно коротких дистанциях для работа более важна способность корректного возврата ровно к той позиции, где он прервал свою работу. Предложенная же эвристика не способствует экономии времени, потому что затраты на проверку прочности инструмента крайне малы в сравнении со временем, затрачиваемым роботом на перемещение к заряднику. Разберём несколько примеров. Для упрощения предположим, что роботу для рубки блоков не требуются перемещения, блоки каким-то образом сами появляются перед роботом. Но для зарядки инструмента роботу требуется переместиться на 10 шагов к заряднику и обратно. Пусть на рубку одного блока требуется 8 тиков. Столько же требуется для единичного перемещения. Также предположим, что инструмент заряжается мгновенно, и для его зарядки робот тратит время лишь на дорогу. 1) Остаток прочности инструмента: 1000/1000. Очевидно, что в этом случае нет смысла перемещаться к заряднику, а можно смело рубить 1000 блоков, сразу после проверки реальной прочности инструмента один раз перед началом работы. Накладные расходы: 1/(8*1000) = 0.000125. 2) Остаток прочности инструмента: 100/1000. Если робот сразу приступает к работе, то накладные расходы = 1/(8*100) = 0.00125 Если робот сначала идёт к заряднику, то накладные расходы = (1+20*8)/8*1000 = 0.020125 Видно, что к заряднику идти не выгодно, имеет смысл сначала израсходовать имеющуюся прочность инструмента. 3) Остаток прочности инструмента: 7/1000. Если робот сразу приступает к работе, то накладные расходы = 1/(8*7) = 0.018 Если робот сначала идёт к заряднику, то накладные расходы = (1+20*8)/8*1000 = 0.020125 Аналогично: сначала имеет смысл потратить прочность инструмента на добычу блоков. 4) Остаток прочности инструмента: 6/1000. Если робот сразу приступает к работе, то накладные расходы = 1/(8*6) = 0.0208 Если робот сначала идёт к заряднику, то накладные расходы = (1+20*8)/8*1000 = 0.020125 А уже в этом случае теряется смысл расходовать прочность инструмента до последнего, выгоднее сначала зарядиться. А теперь другой пример: расстояние до зарядника = 40, остаток прочности 2/1000. Если робот сначала идёт к заряднику, то накладные расходы = (1+80*8)/8*1000 = 0.080125 Если робот сразу приступает к работе, то накладные расходы = 1/(8*3) = 0.0625 В этом случае имеет смысл расходовать прочность инструмента практически до нуля. Вывод: Для экономии времени на вызовах robot.durability() нет смысла дробить работу на крупные блоки. Запас в 48 блоков приведёт не к увеличению, а снижению скорости копки. Дополнительный смысл такого решения может появиться при длинных челночных проходах роботом или же для упрощения кода, чтобы не прерывать копку в произвольных точках карьера.

Магия тут вполне себе светлая. @Doob находит скорость износа экспериментально, совершая несколько попыток применения инструмента, т.к. робот изнашивает инструмент не при каждом использовании, а с некоторой вероятностью, определённой в файле конфигурации OpenComputers. Метод медленный, но не требующий наличия контроллера инвентаря в роботе. Контроллер же инвентаря позволит выполнить эту операцию быстрее: W_R = 1/maxDamage. Запоздалое, но важное дополнение к абзацу выше: Метод, использующий контроллер инвентаря, успешно работает только с обычными инструментами. Значение maxDamage для перезаряжаемого инструмента имеет другой смысл. А здесь обратная операция: robot.durability()/W_R, остаток прочности инструмента переводится в остаточное количество использований инструмента. Реальное количество при стандартном конфиге примерно в 10 раз больше, но гарантированное количество именно такое. Это количество сравнивается с манхэттенским расстоянием до исходной позиции робота. Именно такое количество блоков может потребоваться прорубить при возвращении. К этому добавляется запас в 64 блока. Скорее всего, это максимальное количество движений, которое может потребоваться для полной выработки слоя. Если я верно помню, эта копалка копает столбиками площадью 8x8=64 блока. Да, именно так. Вызвав robot.durability(), имеет смысл сразу сохранить остаток использования инструмента в переменную и декрементировать её при каждом успешном использовании инструмента. Но при снижении её значения ниже критического уровня не надо сразу бежать на базу, а следует перечитать robot.durability() ещё раз и уже после этого принимать решение. @Doob решил эту задачу иначе. Его программа уже знает, что слой может быть полностью выкопан до того, как возникнет необходимости вернуться на базу, и проверяет прочность инструмента после обработки очередного слоя. Такая частота проверки, скорее всего, избыточна, и robot.durability() можно вызывать реже.

Это поправимо: file:seek( "set", blkSize*blkNum ) blkData = file:read( blkSize ) if blkData then array = blkData:byte( 1, blkSize ) end