Перейти к публикации

В ближайшее время постараюсь разобраться с картой сервера/ЛК/бб кодами

Внимание, с 14 февраля до 20 февраля могут проходить работы на сервере, где также находится лаунчсервер. В связи с этим авторизация в лаунчере может не работать

eu_tomat

Модераторы
  • Публикации

    900
  • Зарегистрирован

  • Посещение

  • Дней в лидерах

    88

Последний раз eu_tomat выиграл 3 февраля

Публикации eu_tomat были самыми популярными!

Репутация

1 257 Очень хороший

7 подписчиков

Информация

  • Пол
    Мужчина

Посетители профиля

947 просмотров профиля
  1. eu_tomat

    Робот с геосканером. Часть #7 [способы добычи]

    @Doob, я поспешил с плотностью алмаза. Сейчас посмотрел твою таблицу плотностей, и даже не поверил. Запустил Майн, проверил. Таблица верна. То ли Алекс накрутил плотность в одной из старых сборок, то ли мне это приснилось. Я был уверен, что алмаз имел более высокую плотность, чем другие руды, а уран с большим отрывом имел плотность 9 или около того.
  2. Без доработки мода вряд ли возможно. Впервые узнав о стороне, задаваемой аргументом, я сразу попробовал копнуть во всех направлениях и получил ошибку везде кроме сторон 0, 1, 3.
  3. Именно так. robot.swing() в библиотеке копает только вперёд, а для копки вверх и вниз имеются robot.swingUp() и robot.swingDown(). Компонент же располагает единственной функцией, направление задаётся аргументом.
  4. eu_tomat

    Робот с геосканером. Часть #7 [способы добычи]

    Наиболее интересной мне показалась эта идея: Хорошая эвристика. В идеале хорошо было бы найти такие штрафы на перемещения во вертикали (а также на повороты), чтобы при плотном расположении руд робот перемещался по кластеру как в классической копалке "слой через два". Мои идеи в этом направлении пока что сводятся к увеличению глубины поиска ближайших целей.
  5. eu_tomat

    Робот с геосканером. Часть #7 [способы добычи]

    Спасибо за пояснения, основные идеи понятны. Далее я сосредоточусь на менее однозначных моментах. На определённом этапе игры основной интерес для игрока могут представлять только уран и алмазы, имеющие высокую плотность. Причём, алмазы чаще всего востребованы в мультиплеере как наиболее ценная валюта сервера. А уран как источник энергии востребован почти всегда и везде, а иногда и как валюта. В общем, "выковыривание изюма" может иметь смысл. Тогда даже многократное дальнее сканирование может окупиться экономией времени. А так как количество найденных узлов не велико, то может окупиться даже алгоритм более сложный чем "идти к ближайшему блоку". Как видишь, везде своя специфика. Что накрутит админ, это проблема игроков, адаптирующих свои алгоритмы. Тут не всё однозначно. С одной стороны, некоторые правки конфигов затрудняют внедрение роботов, что становится проблемой. А другие же правки конфигов вынуждают программистов искать новые алгоритмы, что повышает их интерес к игре. При разработке более-менее универсальной копалки полезно иметь в виду весь спектр сценариев. Идеальную копалку на все случаи жизни вряд ли удастся создать, зато можно оговорить граничные условия её применения. Бывает и так, тут наши интересы не сошлись. Упаковщик оказался для меня наименее интересным аспектом твоей копалки, и я, по правде говоря, читал про него очень быстро и невнимательно. Меня больше интересуют алгоритмы сканирования и оптимальной копки. Попробую почитать внимательнее, но хороших идей не обещаю.
  6. eu_tomat

    Робот с геосканером. Часть #7 [способы добычи]

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

    Робот с геосканером. Часть #5 [тонкий расчет]

    Если в инструкции написать, что робота всегда нужно ставить на блок и ни в коем случае не прилеплять его к потолку или стене, то будет работать, как и задумано. Иначе блока снизу может и не оказаться, и тогда энергозатраты на взмах киркой будут околонулевыми. Что нарушит всю точность.
  8. Библиотека robot и компонент robot несколько отличаются. При использовании компонента в вызове robot.swing(3) следует указывать сторону, как в коде @Doob
  9. eu_tomat

    Робот с геосканером. Часть #5 [тонкий расчет]

    Понятно, что потом всё учтётся. Но чтобы потом учесть, надо сначала измерить. При взмахах не только инструмент теряет заряд/прочность. Робот при взмахах тоже тратит некоторое количество своей энергии, но какое именно, на данном этапе неизвестно.
  10. eu_tomat

    Робот с геосканером. Часть #5 [тонкий расчет]

    Насколько я помню, не только для зачарованных. Робот изнашивает инструменты аккуратнее игрока, имея большой шанс не испортить даже ванильный инструмент. А ещё энергия тратится не только на перемещение, но и на повороты, а также на взмахи инструментом, что тоже можно учесть, если расчёт достаточно тонок.
  11. eu_tomat

    Робот с геосканером. Часть #4 [оптимизация компаса]

    Сейчас сканирования, конечно, экономятся, но при отсутствии блоков робот всё равно уходит в бесконечный цикл вращения.
  12. Возможно, речь идёт о нашем сервере EvilWorld. Если нет, то имеет смысл уточнить версию Minecraft и OpenComputers. По тому выводу на экран, что есть в программе, можно говорить лишь о значении переменной TimeOut в этом конкретном месте. И точно невозможно сказать, отличалось ли значение от нуля, например, перед этим участком: if (computer.uptime() - timestamp > TimeOut) and (TimeOut > 0) then ... ShowMenu(); А здесь переменная как раз и могла обнулиться. И почему исключается? Каким образом это проверяется? На отрисовку меню могли влиять ошибки в реализации GUI. Предлагаю на время отладки полностью отказаться от GUI и весь вывод переписать на print, или сигналить звуком, например, так: if TimeOut > 0 then computer.beep() end
  13. eu_tomat

    Робот с геосканером. Часть #0 [планы]

    Интересно будет взглянуть. Придумать концепцию универсальной копалки мне так и не удалось, т.к. каждый мод вносит свою уникальную специфику. Даже уровень шума геосканера сильно влияет на оптимальный стиль копки. А ещё могут внезапно обнаружиться неожиданные препятствия, например, в виде ульев Forestry, непроходимых с помощью бура IC2, как это было с @artem211. Или, например, сейчас на EvilWorld есть шанс запутаться в лабиринте из магического стекла, установленного другими игроками. Работа с инструментами тоже сильно отличается: ванильные, IC2, Tinkers Construct, ThaumCraft – все они производятся, ремонтируются или заряжаются специфическим образом. Я тоже думал про модульную копалку, но так и не смог систематизировать возможности модов. Поэтому с интересом буду следить за твоими успехами. Ограничения EEPROM обхожу следующим образом. Если копалка используется в единственном экземпляре, то, скорее всего, это универсальный, неспециализированный робот, предназначенный не только для копки, и потому имеющий монитор, клавиатуру и диск с системой. Если в копке задействованы одновременно несколько роботов, то для координации их работы в обязательном порядке используется радиоинтерфейс, по которому и загружается программа. Потеря программы при отключении роботов не страшна, т.к. их всё равно приходится будить по вайфайке. Будящему ничто не мешает заодно передать роботам и программу, хоть модулями, хоть одним куском.
  14. Это сложнее. Тут появляется множество вариантов, эффективных в своих условиях и при этом неэффективных в других. И какие условия возникли конкретно у тебя, я не знаю. но я попробую объяснить суть проблемы. В случае генератора булыжника есть только один непрерывно добываемый малоценный ресурс. Если сундук находится над или под роботом, то оптимизация сводится к тому, чтобы перемещать ресурсы полными стаками. Робот перемещает хоть один предмет из слота, хоть полный стак за одинаковое время. А это значит, что выгодно перемещать наиболее полный стак. Заполнение слота легко отслеживается. Если сундук находится в стороне, и робот вынужден совершать поворот, то накладные расходы на освобождение инвентаря возрастают, и появляется смысл выгружать полностью заполненный инвентарь. Его заполнение тоже легко отследить. Гораздо больше вопросов вызывает перелопачивание руды киркой. С точки зрения оптимизации действий робота он должен выгружать свой инвентарь, когда хоть-что появится в последнем слоте. А если речь идёт о рудах GT, где может выпасть вторичный ресурс, то сигналом для выгрузки будет появление предмета в предпоследнем слоте. Если заранее знать, какая руда будет ломаться следующей, то в некоторых случаях можно ждать почти полного заполнения слотов с учётом максимального дропа с руды, но в данной схеме это возможно только в случае, если роботы будут обмениваться информацией по сети. Вообще говоря, для этой задачи использование двух роботов неоптимально, т.к. робот обычно ставит блок быстрее, чем его ломает второй, и если хочется повысить производительность, то лучше установить два однотипных робота на одну задачу, где каждый из них как устанавливает блок, так и ломает его. Так робот сам сможет знать, какой дроп ожидать при следующем взмахе киркой, и сможет лучше оптимизировать свою работу. Но тут возникает новый подводный камень. Эта схема удобна в случае огромного количества руды. У неё есть большой потенциал на поздних стадиях уже упомянутого GT. Но в начале игры, когда ресурсов мало, робот будет ждать полного заполнения своего инвентаря, долго не отдавая переработанные ресурсы, что неудобно. Есть компромиссный и при этом довольно эффективный вариант: робот берёт из верхнего сундука стаки руды, начиная от более полных к менее полным. Загрузив стак руды в свой инвентарь, робот устанавливает её перед собой и ломает, повторяя эти действия до полного исчерпания руды. После этого полностью освобождает инвентарь в сундук. некоторые из слотов могут оказаться недостаточно заполненными, и такая выгрузка будет не очень эффективной, но зато ценные ресурсы не будут надолго задерживаться в инвентаре робота и мешать получению других. Выработав стак руды, робот берёт следующий, один из наиболее полных, и продолжает работу, постепенно забирая и слабо заполненные стаки тоже. За время работы робота ресурсы в слотах входного инвентаря могут пополниться, поэтому имеет смысл отложить их использование до поры, пока не появится лучший выбор. Этот вариант тоже можно оптимизировать. В конечном итоге всё зависит от целей. На что должна быть ориентирована твоя программа? На максимальную скорость при быстрой подаче руд? На переработку руд в начале игры, чтобы ресурсы не задерживались в инвентаре робота? Или надо сделать хоть что-то, лишь бы оно работало с помощью максимально примитивного кода? От ответов на эти вопросы будет зависеть алгоритм работы.
×