eu_tomat

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

1) В цикле while not bedrock do scan() miner() end есть движения между найденными блоками руды, но нет возврата к центру столба. Полагаю, робот будет смещаться от центра столба, что приведет к недостаточно чистой копке.

2) Также мне видится довольно вероятной возможность нарваться на пустую площадку 7x7 в зоне бедрока. При текущей реализации выхода из нее к следующему столбу очень велик риск застрять в бедроке. Не вижу в коде обхода таких сюрпризов.

 

3) Этого и других крокодилов можно заметно укоротить:

    if d == 0 and dT == 1 or d == 1 and dT == 2 or d == 2 and dT == 3 or d == 3 and dT == 0 then
      turn(true)
    else
      turn()
    end

Например, так: turn((dT-d)%4==1)

Готово, дяденьки. Отступы

Просто чтобы обновить, надо еще доработать, простых отступов и двух переменных недостаточно, чтобы считать это обновлением. Надо копку оптимизировать, чтобы не застревал он.

Еще один замечательный алгоритм от danshat:

1) Выложи какаху и попроси не кидаться тапками;

2) Поешь жуков;

3) Объяви, что у тебя что-то готово, но результат не показывай;

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

А что не так? Ты считаешь это неправильным? Решение было найдено, оно должно быть наверху, а решил проблему я сам, потому и решение мое.

Проблема в порочном алгоритме:

1) Задай вопрос;

2) Получи ответ;

3) Упрости решение, подстроив его под свой алгоритм;

4) Назови своё решение лучшим.

И что ты хочешь доказать? Что навигатор не нужен?

Всё нужно: и аппаратный навигатор и программный. Выбор решения зависит от условий задачи.

забудьте вы за эти координаты и не считайте их

Помните и считайте, если требуется.

 

Во-первых, ты сам не раз говорил о нехватке слотов под апргрейды, а программная навигация немного ослабит остроту твоей проблемы.

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

Только почему-то у вас роботы в лаву улетают или в бедрок,если движение пропустят и прочее.

Трудности новичков вроде застревания робота в бедроке, остановки в лаве или ухода за пределы карты мало зависят от способа навигации, если та реализована правильно. А что, собственно, там реализовывать? Строк 20 несложного кода.

не представляешь возможностей навигатора и по сути получения реальных координат мира и универсальных спавнпоитов и точек каких-то у робота, баз зарядки, разгрузки и прочего в радиусе 2048 блоков на максимальной мапе в навигаторе. Катайся дальше и плюсуй по единичке  x и z , а переставив робота в майнерсе или в домике, сиди и на бумажке вычисляй относительный сдвиг стационарных локаций или вводи их как-то в память роботу=)

1) Координаты навигатора тоже относительные в радиусе 2048;

2) Программное плюсование координат необременительно даже по единичке;

3) Координаты стационарных локаций в память робота тоже нужно как-то вводить;

4) Относительный сдвиг до нужной позиции робот может вычислить самостоятельно и без бумажки.

Достаточным будет лишь задать роботу стартовые координаты. Но он их забудет при выключении – это единственный недостаток программной навигации.

Я тут подумал, а может вместо геосканера просто сравнивать стоящий блок под роботом с блоком в инвентаре?

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

Господь с вами, забудьте вы за эти координаты и не считайте их, как в древних черепадликах. Юзайте навигатор человеческий, который Санги просто с небес дал и благо пока нечего не отрезал и не понерфил там, не дошла туда еще его ручища-нерфилка

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

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

Добывать их все-равно приходится, поэтому, контроллером инвентаря можно их на финише отсеивать.

Лучше вообще лишнее не добывать. Экономится и время и энергия и ресурс инструмента. И серверу легче.

 

А про код не буду писать, поберегу тапки

Когда лоханулся добавив стандартную библиотеку

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

local math = require("math")

но лучше так:

local math = math

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

Небольшое дополнение к сказанному @Zer0Galaxy

output1,output2,output3 = table.unpack(output)

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

Если в конфигурации OpenComputers включена возможность чтения NBT-тегов, то возможно. Тогда для их получения рекомендую воспользоваться библиотекой libitem: https://github.com/O.../master/libitem

Работает. Это бомба! Про теги давно уже думал и по разным поводам, но нагуглить так и не смог.

Насколько я помню, геолайзер не возвращает NBT. Соотвественно, невозможно.

Геолайзер я привёл в пример. Может, есть иные способы? Тем же анализатором или еще чем-нибудь?

Если шифт-кликнуть компьютер, то он включится. Роботы тоже могут это делать. robot.use(nil, true)

И роботы умеют ШПКМ, и ШПКМ пустой рукой по компьютеру включает его, но ШПКМ именно роботом почему-то не включает компьютеры, хотя и возвращает «true, block_activated». А было бы здорово.

 

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

Проблема решилась доступом к NBT. Но твое предложение тоже интересно, я думал о нем в другом контексте. Но не смог поместить роботом плату в свой контейнер. Поделишься способом? У меня получилось засунуть плату только другим роботом, но это громоздко.

Думаю, нет смысла создавать новую тему. У меня набрались новые вопросы, связанные с периферией:

 

1. Можно ли узнать адреса компонент и блоков, просто лежащих в инвентаре робота?

В инвентаре игрока адреса компонент доступны для просмотра.

Для робота, лежащего в инвентаре робота, контролер инвентаря не выдает ни имени, ни адреса.

Аналогично и для сетевой карты: просто сетевая карта, и всё.

Реально ли вытащить адреса из тегов?

 

2. Может ли робот каким-либо образом узнать адрес соседнего блока?

Например, геолайзер может сказать, что это робот, но не сообщает ни его имя, ни адрес.

Анализатор при использовании игроком помещает сообщение в чат, но апргейд чата из Computronics его не ловит.

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

 

3. Может ли робот включать или выключать стоящие рядом компьютеры иным путем кроме как через wake-up по редстоун- или сетевой карте? Черепахи, насколько я помню, умели это делать. И компьютер легко включает роботов, а наоборот – не получается.

 

4. Можно ли как-то узнать адрес адаптера, через который подключено устройство, и сторону, с которой устройство находится относительно адаптера?

все в твоих руках, можно все, например.

Так-то всё можно, да не всё полезно.

Таблицу локальной делать не обязательно, но, как правило, желательно.

И оператор goto тоже можно использовать, да граблей там разбросано много.

Я думаю, функцию в "библиотеки" надо сделать локальной.

Зачем? Это метод локальной таблицы.

Камень мне нафиг не нужен, у него плотность = 1, у свинца = 2, через три сканирования я отсекаю все, что меньше 2 и добываю. Попадается камень? Никто не мешает выкинуть. Пропускаю свинец? Пфф.. Не велика потеря, что-то все-равно добывается.

... 

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

Спорт не в многократном сканировании, а в поиске алгоритма.

Я все это время полагал, что мы в качестве эталона подразумеваем изначальный алгоритм artem211 с ограничением высоты сканирования в +/-7 блоков (или сколько там было), и абсолютным определением плотности блоков. Поэтому и удивился использованию троекратного сканирования, в то время как недостаточно и 33-кратного.

Твой же подход оказался совсем иным, допуская потерю 50% свинца. Вопросов больше нет, спасибо.

@eu_tomat, чем писать тонны текста, лучше бы что-нибудь полезное продемонстрировал. Я лично все изучаю, поэтому уверен, что говорю об этом не с потолка. Я перепробовал кучу подходов к геокопалкам и с уверенностью могу заявить, что это просто трата времени и ресурсов, т. к. есть способы копать без геосканера намного эффективней, чем с ним.

На расстоянии 32 блока от сканера, через 3 сканирования, даже с грубым округлением можно найти и свинец и сундуки и все остальное (это стандартный конфиг)

Благодаря новым возможностям геосканера, сейчас можно пользоваться интересным алгоритмом - сканировать перед роботом квадрат 7x7, т. е. добывать слой за слоем (можно прямой линией, змейкой, спиралью, не важно), мне кажется, что это самый лучший подход, надо будет тщательно проработать, тут много плюсов - шумов мало, роботу меньше приходится бегать туда-сюда, лишней энергии не тратится и т. д.

Я не понял твою позицию из последнего поста: то ли открылись новые возможности геосканера, то ли он бесполезен, то ли полезен но с 3-х кратным сканированием.

Но мне наиболее интересен последний пункт.

 

И раз даже тонны текста тебя уже не убеждают, то вот тебе полезная демонстрация:

Этот код выполняет серию простых сканирований камня на высоте 32 от геосканера, а затем вычисляет минимум и максимум в серии усредненных значений для X-кратного сканирования.

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

Выводы:

1) Троекратное сканирование взято с потолка и его недостаточно для различения камня от свинца.

2) Более-менее удовлетворительный результат даёт 30-кратное сканирование, но он также ненадежен.

 

Upd: Ах, да! Забыл, что кроме усреднения можно пользоваться фильтрацией. Тогда количество сканирований можно уменьшить. Иногда достаточно одного сканирования, а иногда недостаточно и тридцати - это тоже вопрос вероятностей. Тоже нужна демонстрация?

Особо переписывать ничего не надо, чуть-чуть поправить алгоритм сканирования. Зато теперь будет очень удобно работать с самим сканером

Конечно, приятно, что сканер теперь позволяет не сканировать лишние блоки. Но и сканирование сразу нескольких чанков теперь тоже потеряло актуальность. С текущими настройками на IT максимальная площадь адекватного сканирования – 11x11 с геосканером в центре. С расстояния 5x5 еще возможно отличить свинец от камня, но уже на расстоянии 6x6 будут случаться сбои.

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

Усреднение результатов нескольких сканирований, не смотря на кратное увеличение энергозатрат, не обеспечит 100% гарантии точного определения плотности блока, переводя проблему в плоскость вероятностей. Это значит, что чисто выбрать руду всё равно не удастся. А тройное сканирование принципиально вообще ничего не изменит. Полезнее будет разбить весь участок на столбы 11x11 и менее. Заодно и требования к объему памяти снизятся.

IMHO, лучше перестроиться с С++ на Луа, и пользоваться всей мощью этого языка, чем вложить аналогичное (если не большее) количество усилий в освоение сего велосипеда, и последующей борьбы с его граблями.

Золотые слова, полностью согласен с Totoro.

 

Языки Lua и С++ слишком разные для сколь-нибудь эффективной трансляции кода из одного в другой. Пользование подобным транслятором убьет все преимущества Lua. Я тоже не сразу разглядел эти преимущества, а год назад синтаксис Lua меня вообще расстраивал, но совсем недавно, освободившись от диктата C++ я стал относиться к Lua уважительно. Этому, конечно, сильно способствовало изучение Python – мощного скриптового языка, но и Lua тоже очень неплох. Вывод, который я сделал для себя: если планируешь долго пользоваться языком – хорошенько изучи его синтаксис и овладей новыми приёмами – это станет отличным вложением времени.

О, Артём! Привет! Рад твоему появлению.

Особо переписывать ничего не надо, чуть-чуть поправить алгоритм сканирования.

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

Похоже для OC v1.6.0 эту копалку нужно будет переписывать:

Этот коммит в 1.6.0 меняет API гесканера. Сканировать можно будет прямоугольную область объёмом не более 64 блока. Точность сканирования геосканера будет зависеть от расстояния до сканируемого блока. Не только по вертикали как сейчас.

Переписать придется сильно. С точки зрения минимизации помех получается, что выгодно сканировать объем 4x4x4, а это уже практически в упор к жиле, алгоритм работы сильно изменится. Но изменение позитивное, мечтал об этом.

Вот прикрутить бы роботу функцию возврата на базу если заряд достиг 10% и по прибытию дозарядка до 100%, а потом дальше копать, то цены бы не было ему... Но к сожалению я почти не продвинулся в изучении языка программирования lua, и в этой ситуации беспомощен...

Этот камень без долгой тренировки не поднять.

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

Изучи копалку попроще, или напиши свою простую.

Постепенно добавляя функционал, достигнешь такого же результата и даже лучше.

Ну я как понял теперь все на ИТ сервер забили "болт".

10:20 МСК на сервере 1/40

Хотя раньше всегда 2-3 человека было онлайн в это время...

И как это мешает тебе играть на ИТ и не покупать новое железо?

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

А целом меджиг без ОС - НИЧЕГО.

Простите, но я пока ничего интересного для себя там не нашел. Иду обратно на ИТ.

Прямо-таки заставляет? Ну, и кровавая же администрация. Теперь все как один на последние деньги купим новое железо. А куда нам деваться? Это же единственный сервер без роботов.

И вообще долой роботов из обычного мира, только в майнере.