eu_tomat

Со взрослыми языками та же история. После Си, начав программировать на Питоне, тоже бывает сложно не получить костылями от питонистов. Меня от изучения чисто игровых языков останавливают три вещи: Недостаточна мотивация для изучения малоприменимого языка. Мало информации по редкому языку. Дизайн языка, скорее всего, хуже его взрослых аналогов.

Почему бы и нет. Какие у тебя есть идеи по созданию быстрого и при этом оптимального алгоритма поиска пути при большом количестве целей?

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

Что-то не обрадовал меня этот фикс. Он принёс только вред. А пользы ноль. Перехват TLWY в pcall/xpcall являлся необязательным костылём, гриферский эксплоит продолжит работать и на новой версии. Зато теперь пострадают игроки, которые время от времени получают случайные TLWY по причинам, мало зависящим не только от их скриптов, но и вообще Майнкрафта.

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

Метка "tmpfs" не обязательно указывает на временную файловую систему. Верное решение: local tmpfs = component.proxy(computer.tmpAddress())

При условии, если кто-то не указал носителю метку "tmpfs". К слову, ничто не мешает это сделать. Действительно, только для OpenOS. Заглянув в недра системы, я пришёл к такому решению: local tmpfs = component.proxy(computer.tmpAddress()) Так должно работать гарантированно верно.

Насколько я понимаю, дело не в наличии OpenOS, а в наличии других носителей с файловыми системами.

Ещё способ: filesystem.fsnode.name

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

Вполне безопасно, если проверять наличие посторонних игроков в кабинке. А наилучший способ передачи предметов зачастую определяется не теорией, а конкретным игровым сервером: где-то транспозер не работает с интерфейсом игрока, где-то админы запретили PIM. Что тогда остаётся использовать кроме робота? Правда, возможности гарантированно обнаружить постороннего игрока тоже может не быть. Существует ли что-то кроме сенсора из OpenPeripheral, способное обнаружить неподвижных игроков?

А в чём небезопасность роботов?

@BrightYC Почему в названии темы присутствует термин "вирус"? Что вирусного в этой программе?

А зачем вообще было их раскрывать? Теперь придётся спешить. Теперь кто-то тоже хочет "другое с VR очками". А кто-то не только хочет, но и уже делает.

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

Задача стоит играть именно на 1.6.4? Потому как для 1.7.10 есть SGCraft, хорошо интегрированный с OpenComputers.

А как можно "запороть" файл?

Для начала надо понять, почему компьютер выключается, и попробовать устранить причину отключений. Если избежать отключений не удаётся, то компьютер можно "разбудить" с помощью либо сетевой, либо красной платы. При каких обстоятельствах происходит выключение компьютера?

Да, у меня тоже есть ощущение, что NodeMCU оказался не лучшим выбором. Проект нужно либо упростить, либо выбирать другую платформу. Но какой-то простой фановой задачи я не вижу. Возможны задачи практические, но NodeMCU для них оверкилл. Из того, что сейчас интересно мне, это машинка для увеселения котов и людей. Изначально я смотрел в сторону Arduino Nano. Но будет ли этот проект интересен на форуме кому-то кроме меня, я не знаю. Отталкиваться от препятствий мне скучновато. Хочу какого-то планирования действий в ближайшие секунды, препятствия должны обходиться заранее. Для начала хочется добиться постоянной скорости движения, пусть и небольшой. Потом интересно поднять скорость до максимума, насколько мне хватит умения, терпения и возможностей датчиков. Мне интересно упороться оптимизациями и скоростями. И как максимум, интересно научить машинку ненавязчиво троллить котов. Тоже интересно узнать, насколько мне это удастся. Я в ближайшее время вряд ли смогу осилить распознавание геометрии пространства по изображениям с камер. Хочу начать с более простых задач. Но да, это уже не для всех проще. Можно, наверное, какой-то готовый софт использовать, но я не в курсе этих решений. И хватит ли для них RPi? А подключение к этой задаче ещё и стационарного компа тоже дополнительно усложнит проект. Ещё я могу попытаться всё-таки выжать, что возможно, из решения на NodeMCU, чем бы это ни кончилось. Если не получится, вернусь к начальному решению на Arduino Nano, или буду как-то иначе корректировать решение. Ещё есть идея. Можно вынести в отдельный проект создание интерпретатора Lua-кода через web-интерфейс. Это почти как с дронами из OpenComputers: непосредственная отладка при работе с периферией дрона затруднена, поэтому приходится использовать планшеты и стационарные компы для опосредованной отладки. Так и тут, чтобы не заливать каждый раз программу в контроллер, можно короткие скрипты выполнять через web-интерфейс и выводить какую-то информацию. Такая программа позволила бы быстрее и удобнее уточнять нюансы при работе с периферией. Но с этой задачей ты и без меня справишься. Возможно даже, до того, как я приобрету NodeMCU.

Было бы глупо что? Трогать функции? Так они же сами себя не напишут. Сам микроконтроллер не имеет аппаратной поддержки чисел с плавающей точкой даже для базовых операций, не говоря уже о тригонометрии. Я тут узнал, что для NodeMCU есть альтернативная прошивка, поддерживающая лишь целочисленную арифметику. По умолчанию вроде бы используется арифметика с плавающей точкой. Это, конечно сказывается на быстродействии, но зато снижает порог вхождения в программирование этих микроконтроллеров.

А loadstring принимает строку lua-кода? У меня вот ещё какой вопрос. Как у NodeMCU дела с математическими функциями? Синусы с косинусами придётся самому вычислять? Как там вообще осуществляются вычисления с плавающей точкой? Какова максимальная разрядность при работе с целыми числами? Я тут подумал, что в принципе приводу поворота головы не обязательно знать начальный угол. Привод можно откалибровать при старте программы за два сканирования. Между сканированиями надо выполнить одно движение вперёд или назад. Причём, движение не обязательно откалиброванное. Главное, чтобы во время калибровки на пути робота ничего не стояло. Ещё думаю, алгоритм может запутаться при сканировании решетчатых структур, но тут должно помочь сглаживание. Правда, тригонометрия нужна в любом случае. Без синусов я пока не смог придумать калибровку.

Лучше для какой задачи? Немного изучив тему, я тоже склонился к лидарам. Потребление энергии лидаром на фоне приводов меня не беспокоит. Но с лидарами мне пока не всё понятно. Есть, например GY-530 VL53L0X с получением данных по шине I2C, там в характеристиках указано время <30ms. Что это значит? В течение некоторого времени сенсор должен оставаться неподвижным? А есть, например GY-53-L1X VL53L1X, там про время ничего не сказано, а ещё у него есть выход ШИМ. Даёт ли ШИМ возможность непрерывного сканирования без необходимости останавливать движение?

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

Погрешность будет, это понятно. Мне не понятно, может ли сместиться оптимум при работе в других условиях: просело напряжение на батарее, износился сервопривод и т.д. Машинка, кстати, не радиоуправляемая. Вайфай мне нужен в основном для отладки. Кстати, об отладке. Платформа NodeMCU поддерживает выполнение произвольного Lua-кода? Требуются функции load и pcall. Камеру поставить, конечно, весело, но что делать с картинкой, я пока не придумал. Я не знаю, как по картинкам распознать преграды, и реально ли выполнить эту задачу силами самого контроллера. Может, при развитии проекта вместе что-нибудь придумаем. Это было бы интересно. А пока что с вычислительной точки зрения я способен овладеть лишь дальномером. У них вроде бы и так есть два крайних положения: ноль и один, управляется скважностью через PWM. Тут проблем в том, что скорость работы этих сервоприводов неизвестна. Почти как неопределённость Гейзенберга: либо в режиме реального времени известен относительный угол, либо известен абсолютный, но с некоторой задержкой. Поэтому я не знаю, как применить эту идею.

Понятно, что любую. Вопрос в том, как определить, что задержка достаточна и не избыточна? Не изменится ли оптимум при изменении напряжения питающей батареи? Ну, а как принудительно установить на нужный угол? Шаговый двигатель не имеет такой возможности. Можно лишь сместить на нужный угол относительно исходного. И снова встаёт вопрос, как определить угол? Исходный или конечный, без разницы. Я тут, кстати, нагуглил, что есть сервоприводы, способные вращаться на 360 градусов. Но у них та же проблема, что и у шаговых двигателей: есть возможность задать скорость вращения, но абсолютный угол определить или задать невозможно.