eu_tomat

Найти файл с объявленной функцией можно, например, так: $ grep -lr 'function require' . ./lib/package.lua

В какой версии так происходит?

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

Если задаваться вопросами о смысле, то какой смысл и в функции __index, если наличие элемента в таблице легко проверяется обычным обращением к самому элементу? Чем это удобнее уже обсуждённой конструкции if tbl[idx] then?

@man_cubus И что доказывает этот код?

Сомнение в том, что __index вызывается только при отсутствии элемента в таблице.

Кхе. Я ожидал увидеть кривую работу компонента, а ошибка возникла в своей же таблице. Ларчик просто открывался. Кстати, выше @ECS предложил более удобный вариант поиска элемента по id в качестве ключа, что избавляет от цикла:

Компонент crystal, это прозрачный сундук из мода ironchest, подключается модом OpenPeripheral. Нумерация начинается с единицы, cry.getStackInSlot(i) возвращает таблицу с описанием содержимого слота или nil, если слот пустой. Код из стартового поста выглядит работоспособным, и я пока не вижу проблему. @Teen_Romance можешь выложить код не скриношотом, чтобы я его запустил у себя? А ещё нужны версии ironchest и OpenPeripheral.

Идеи есть, но я пока не добрался до компа с Майнкрафтом, чтобы проверить. Можешь показать значения cry.getStackInSlot(i) для пустых и заполненных слотов?

Что значит "не может дать индекс"? Как выглядит ошибка? Какая версия OpenComputers?

Скорее всего, cry.getStackInSlot(j) для пустого слота возвращает пустую таблицу. Избежать исключения можно, проверив наличие поля cry.getStackInSlot(j).id.

Например: https://minecraft-ru.gamepedia.com/OpenComputers/GPU_API https://minecraft-ru.gamepedia.com/OpenComputers/Event_API

По какой ссылке качал? По этой? https://github.com/Jeija/spheretest/releases/download/release/spheretest_release.zip Я повторил эксперимент на другом компе. Первый раз запускал под Win7, второй раз под WinXP. Результат одинаков, мир плоский.

Хорошо, попробую разобраться. По ссылке под видео скачал архив: https://github.com/Jeija/spheretest/releases/download/release/spheretest_release.zip Распаковал архив и запустил в нём файл minetest.exe, он там один. Выбрал и запустил мир spheredemo, он там тоже один. Вышел из домика и поднялся над планетой: Ничего похожего на сферу не наблюдается. Что я делаю не так?

Что значит "не могу заставить"? Какие были совершены попытки заставить робота ломать блоки?

Когда поверхность велика, и дальняя часть карты скрыта горизонтом или туманом, то в любой точке поверхность как тора, так и сферы можно считать условно плоской. Тут вопросов нет. Вопросы возникают на поверхностях с явной кривизной, которую невозможно не заметить. Рыбий глаз это искажение только напоминает. Различие в том, что фотку с эффектом рыбьего глаза всегда можно трансформировать в нормальный вид, а с этой картинкой такой фокус не пройдёт, перспектива иная. Тут сами блоки меняют ориентацию в пространстве, а не просто меняется точка зрения. Мне хотелось посмотреть, как выглядят крупные и высокие объекты с обратной стороны планеты, и я даже скачал демку. Но карта почему-то плоская, а запущенные спутники тупо уходят в землю. Карта интересна только своей зацикленностью в тороидальных координатах. В геймплей эта штука ничего пока не добавляет. Ну, зациклена карта, и что с того? Иллюзия сферичности тоже не добавит длительного интереса. Но посмотреть, как эта иллюзия достигается, будет интересно. Информативность видео недостаточна, я бы поставил свои эксперименты в этом мире. Кому-нибудь удалось запустить эту демку так, чтобы планета выглядела сферичной, как на видео?

А разве алгоритм Дейкстры предусматривает обход всех узлов?

К сожалению, это видео лишь поясняет, как достичь красивого соотношения сторон вокселей. Объяснение хорошее, но про взаимосвязь тора и сферы не сказано ничего. Я не понял смысла видео с первого раза. Когда увидел растягивающийся куб, понял, что есть искажения на углах, на которые игроку маловероятно натолкнуться. Модель понятна. Но сказанное про тор я вообще не смог сопоставить со сферой, и потому решил, что оно не имеет отношения к выбранной модели. Посмотрел внимательнее. Оказалось имеет. Как растянуть прямоугольник в тор, понятно. Тороидальные координаты тоже не вызывают вопросов. Также понятен трюк с траншей внутри тора. Непонятно, почему тор выглядит как сфера, а сфера ведёт себя как тор. Такое преобразование невозможно топологически, тор и сфера не гомотопны. И обойти кольцевую траншею на поверхности сферы тоже невозможно. Скорее всего, использован какой-то трюк визуализации, пояснения которого в видео не прозвучало. Остаётся один вопрос. Какой трюк позволяет отобразить тор в виде сферы?

@Doob, а робот тогда будет перемещаться в каких координатах? Он будет двигаться вдоль поверхности шара или же по исходным, кубическим координатам? В первом случае вертикальная ось в кубических координатах будет меняться на 90 градусов при переходе с одной грани губа на другую. Во втором случае движения робота будут отвязаны от плоскости шара, и на обратной стороне шара робот будет располагаться вниз головой, а деревья для робота будут располагаться не только вертикально, но и горизонтально. Какой из вариантов ты предпочтёшь?

В любом случае эта идея не для ближайшей сборки. А потом её вряд ли кто-то найдёт, т.к. темы о будущих сборках по традиции перетекают в холивары и затем перемещаются в корзину. Идея с шарообразным миром любпытная, я бы её перенёс, например, в шкатулку, но только выбросив всё остальное. Хорошо. Для начала найди возможность вменяемой системы координат в шарообразном мире. Где здесь верх, восток, юг? Видео демонстрирует способ превращения куба в шар. Координаты используются кубические, но исходный куб растягивается до формы шара. Так вот, на шаре всегда можно обозначить горизонталь и определить верх-низ, даже когда мы стоим по по центу блока, лежащего на грани исходного куба. А в кубических же координатах окажется, что можно стоять на одной из двух сторон блока, и в этом случае направление верха и низа резко меняется. Аналогично и для блока, находящегося в вершине куба, там возможны аж целых три направления "вниз". А у нас тут роботы бегают, им нужна чёткая система координат. Как предлагаешь решать эту проблему? Перенёс тему во флудилку. Поболтаем хотя бы о геометрии.

Тут вопрос не в скорости, а в принципиальной возможности. Чтобы обучаться, нужно экспериментировать, сравнивать результаты со старыми. А как нейросеть поймёт, что текущий вариант действий лучше предыдушего, если ситуация каждый раз новая? Например, в прошлый раз было собрано 5 блоков руды за 5 секунд, а в этот 5 блоков за 7 секунд. На первый взгляд может показаться, что текущее решение хуже предыдущего, но на практике может оказаться, что прошлую задачу можно было выполнить за 4 секунды, а в этот раз 7 секунд являются наивысшим пределом. И как нам, не имея простого критерия правильности, обучить НС оптимальной копке? С нейросетями, играющими в простые игры, понятно: прошёл уровень, собрал все бонусы, сохранил жизни -- молодец; не прошёл уровень -- учись дальше. Но с Майном не так: каждый участок для добычи уникален, а поиск оптимума реализуется прожорливыми алгоритмами, для замены которых, собственно, и потребовались "быстрые" нейросети.

А за счёт чего он будет достигаться? Откуда робот узнает, что поступил не самым оптимальным образом? Сама по себе нейросеть в лучшем случае научится добывать хоть что-то и хоть как-то.

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

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

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