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

Блоги

Популярные записи

  • Quant

    Аналоговый рэдстоун-передатчик файлов

    Автор: Quant

    Аналоговый передатчик
    Файлов по рэдстоуну
    Возвращение легенды)
    Некоторые помнят мою передавалку чисел по рэдстоуну...
    Но чисел мало...
    Но теперь скорость настолько большая,что можно передавать даже файлы!
    Конструкция осталась такой,какой была и раньше:

    Зато изменились протокол передачи и программа)
    Краткая характеристика:
    Поддержка юникода +
    Скорсть передачи байта от 0,1 до 0,3 секунд

    Посмотреть код:
     
    • 9 комментариев
    • 1 850 просмотров
  • Totoro

    Запускаем дронов!

    Автор: Totoro

    Дроны - как керосин. Они есть везде. Еще года два назад это было просто еще одно интересное видео на Ютубе. Год назад они вдруг оказались в интернет магазинах. Затем просочились в рекламу на ТВ, и вот теперь - они есть и в OpenComputers! Пришла пора с ними разобраться.   1. Матчасть Дрон, в данном случае - квадрокоптер, это беспилотный летающий аппарат, приводимый в движение двумя парами горизонтальных винтов. Приостановливая вращение винтов с одного боку, дрон двигается в сторону (стрейф). Эти винты вращаются в разном направлении (два - по часовой срелке и два - против), за счет чего дрон не нуждается в стабилизирующем хвостовом пропеллере (как вертолет). За счет этого же он и разворачивается в воздухе, замедлив вращение однонаправленной пары винтов. Дрон обладает небольшой массой, для экономии энергии, которой у него не много (на 10-30 минут полета в среднем). (с) Википедия   2. Дроны и OpenComputers Приблизительное изображение дрона в OpenComputers =): В мире Майнкрафта дрон представляет из себя "сущность" (Entity). Это значит, что он обладает возможностями мобов Майнкрафта. (В то время как робот - это блок.) Его можно сдвинуть с места толкая. Он умеет пролетать сквозь двери и калитки (в отличии от робота). Он движется не последовательно, из блока в блок, а из точки в точку. Причем маршрут может лежать по диагонали.   Конечно, движется он по кратчайшей линии, и если на пути окажется стена - дрон столкнется с нею.   Программирование дрона как две капли воды похоже на программирование микроконтроллера. Вы точно так же записываете программу на EEPROM, и при необходимости меняете ее на верстаке. Только в отличии от контроллера, вам становится доступен новый компонент: drone.   Подробнее об командах дрона можно узнать здесь: OpenComputers/Дрон. (Или здесь: ocdoc.wiki (англ.))   3. План Нужна какая-нибудь несложная задача, для целей эксперимента. Используем программку send из предыдущего поста, для удаленного управления. Зальем ее на планшет. А дрон пусть... носит свиней. Будем оригинальными и непоследовательными.     1. Команда 'add X Y Z Name From'. Добавляем точку Name к маршруту, цепляя ее к точке From. Зададим дрону последовательность точек, которые образуют граф - безопасные маршруты. 2. Команда 'catch' - дрон ловит свинью. 3. Команда 'drop' - дрон выпускает свинью. 4. Команда 'to X' - дрон летит в точку Х.   Для начала не будем особо заморачиваться с графом маршрутов. Это будет простое неориентированное дерево. Примерно такое:   4. Строим полигон Построим что-нибудь подходящее для тестов. Отметим ключевые точки будущего графа красными блоками. А синий блок - будет стартовой площадкой дрона.           Поскольку я играю без модов на энергию, мой планшет и дрон будут работать вечно. И я не заморачиваюсь станцией подзарядки.   Иначе, к схеме выше было бы необходимо добавить станцию, где дрон мог бы зарядить аккумулятор.     5. Пишем программу Скрипт для удаленного управления скопипастим из прошлого поста, подправим, чтобы умела отправлять несколько переменных и зальем на планшетик, для удобства. (Для этого, соберите планшет - не забудьте клавиатуру и видеокарту! - положите его в зарядник и запустите с подключенного компа команду install. Укажите адрес винчестера планшета - и все, что было у вас на компе автоматически загрузится в планшет, включая даже ваши собственные программы.) local com = require('component')local modem = com.modemlocal args = {...}modem.broadcast(27, table.unpack(args))io.write("Message: ")print(table.unpack(args)) Далее - более сложная часть. Программа дрона. Программа предназначена для EEPROM. Значит соблюдаем те же правила: используем computer, component и API имеющихся у дрона компонентов. Включая его родной компонент drone. В нашем случае, дрон вооружен апргейдом-лассо (leash) и беспроводной сетевой картой (modem) для связи.   Стоит отметить, что процесс отладки программы (по крайней мере в текущем билде мода) достаточно неудобен. В случае ошибки дрон отказывается включиться, издав тонкий писк, и не выводя никакой информации. Получить отчет об ошибке при помощи анализатора не выйдет - ведь Shift+ПКМ просто снимает дрона. Автор обещал в скором времени это исправить. Ну а пока - помучаемся.   Отредактировать чип в стороннем редакторе, не вынимая его из дрона тоже не выйдет. В отличии от файловых систем, которые имеют удобную папку вида /saves/World/opencomputers/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/, чипы EEPROM хранят свой код в NBT тегах предмета. Этим же обусловлено и ограничение размера кода в 4 килобайта.   5.1. Основная часть Это цикл который ждет указаний, а затем запускает соответствующую функцию. drone = component.proxy(component.list("drone")())modem = component.proxy(component.list("modem")())leash = component.proxy(component.list("leash")())modem.open(27)route = {}path = {}current = ""while true do name, _, sender, _, _, message, x, y, z, point, from = computer.pullSignal(1) if name == "modem_message" then if message == 'add' then add(tonumber(x), tonumber(y), tonumber(z), point, from) if current == "" then current = point end elseif message == 'to' then to(x) elseif message == 'catch' then catch() elseif message == 'drop' then drop() end end if #path > 0 and drone.getOffset() < 1 then drone.move(route[path[#path]].x-route[current].x, route[path[#path]].y-route[current].y, route[path[#path]].z-route[current].z) current = path[#path] path[#path] = nil endendmodem.close() Чтобы облегчить себе жизнь (и тестирование bios), вы можете сделать так: напишите заглушку для компонента drone (и других, если надо), вроде этой: http://pastebin.com/EVYzN5Bj Просто скопируйте в папку на компьютере, где вы пишете программу для дрона. Затем измените первые строки программы следующим образом: component = require('component')computer = require('computer')drone = require('drone')modem = component.modem-- leash = component.proxy(component.list("leash")()) Затем добавьте в цикл условие выхода по нажатию кнопки: if name == 'key_down' then break end И вы можете просто запустить вашу программу для дрона на компьютере. Разумеется полноценной эмуляцией дрона тут и не пахнет, зато очень удобно отслеживать глупые синтаксические и логические ошибки.     Как устроен код основного цикла? Переменная route - хранит таблицу "вейпоинтов" (waypoints). Это вершины графа и информация о связях между ними. Переменная path - хранит путь от текущей вершины до цели. Переменная current - отмечает текущее местоположение дрона в графе.   В цикле мы читаем получаемые сообщения и вызываем соответствующие функции. Первая переданная вершина считается дроном текущей.   Во второй части цикла происходит проверка. Если путь до цели - не пуст (это значит, что дрону надо куда-то лететь) и дрон уже долетел до текущей вершины (getOffset()), то программа берет следующую вершину из path, отправляет дрона к ней и объявляет ее текущей.   5.2. Функции-команды Теперь последовательно добавим функции для каждой команды. function add(x, y, z, name, from) route[name] = {x=x, y=y, z=z, link = {}} if from ~= nil then if route[name] == nil or route[from] == nil then drone.setStatusText("Error!") else table.insert(route[name].link, from) table.insert(route[from].link, name) end endend Тут все просто. Пишем вершину в список. Если он связана с другой вершиной (from ~= nil), то в специальную табличку link заносим две связи: из name в from, и из from в name. function search(target, point, prev) for key, name in pairs(route[point].link) do if name == target then table.insert(path, point) return true end end for key, name in pairs(route[point].link) do if name ~= prev then if search(target, name, point) then table.insert(path, point) return true end end end return falseendfunction to(name) path = {} table.insert(path, name) search(name, current)end Функция to обнуляет старый путь (на всякий случай), затем вставляет в него цель пути (name) и запускает функцию search, которая рекурсивно ищет и записывает остальные промежуточные вершины на маршруте от name до current (текущей локации). Функция search сделана достаточно примитивно (возможно вы предложите более эффективный способ?). Поскольку мы договорились, в целях упрощения использовать граф-дерево (не содержаший петель), от любой точки к другой существует один и только один маршрут, который функция и находит перебором связанных вершин. function catch() for c = 2, 5 do if leash.leash(c) then return true end end return falseendfunction drop() leash.unleash()end Тут все элементарно.   6. Подготовка Пишем программу на дрона, заряжаем планшет и выдвигаемся в зону действий. Дрона ставим на синий куб (стартовая площадка) и включаем.     После уточнения на местности, составляем карту вейпоинтов и строим на бумажке будущий граф:   Для каждого загона добавлены две точки - name и name_up. Основные "трассы" дрона лежат на высоте в 6 блоков. А в каждом загоне спускаются к земле. (Чтобы заарканить животное, выстреливая лассо вбок, дрону желательно находиться на одном уровне с жертвой).   С планшета вносим координаты в память дрона. Примерно так:     Главное - не ошибиться. Т.к. в код не была добавлена защита "от дурака" =) Алгоритм позволяет добавлять вершину "на лету". В любой момент вы можете добавить еще одну ветку к схеме.   Теперь все готово к тесту.   7. Запуск Все готово. Проверим, как он двигается. Введем send to sheeps в консоль планшета. Дрон уверенно поднимается в воздух и опускается в загоне в овцами.   Теперь введем send to pigs. Функция search снова вычислит путь и робот переместится в указанную вершину:     Функции catch и drop тоже работают штатно =)     Хотя и не лишены некоторых глюков (ведь физика веревки не просчитывается):     8. Итоги а) Дрон - любопытная штуковина. б) Полный код прошивки. использованный в этом посте - здесь: http://pastebin.com/Cy1UR6vy в) Навигация по вейпоинтам - интересный и очень распространенный способ организации сложного движения. Схему можно усложнить - опционально добавлять только одну связь в таблицу link - тогда получатся ребра с односторонним движением. Добавить петли, оптимизировать поиск кратчайшего пути. Еще можно облегчить правление дроном - хранить все команды для конкретной задачи в виде файла-скрипта, который запускать одной командой и т.д.   Enjoy!
    • 19 комментариев
    • 14 452 просмотра
  • Zer0Galaxy

    Создаем собственный сайт в сети OpenNet (часть 0x00)

    Автор: Zer0Galaxy

    И так, Вы попали в белый список, построили дом, добыли ресурсов, собрали свой первый компьютер, написали первую программу. Настало время поведать о своих успехах миру. Лучший способ сделать это - создать OpenNet-сайт с изложением всех своих достижений. Для этого Вам понадобится WEB-сервер. Это может быть обычный ОС компьютер. Желательно обеспечить его бесперебойным питанием и разместить в постоянно прогруженном чанке. В противном случае Ваш сервер может оказаться временно недоступным. Вопрос питания и прогрузки чанка я оставляю на усмотрение владельца и расскажу о требованиях к аппаратному и программному обеспечению сервера. Сервер должен содержать беспроводную сетевую плату, а это значит, что системный блок сервера должен быть не ниже 2-го уровня. Требования к остальным компонентам самые минимальные. Если же Вы собираетесь использовать этот компьютер не только как сервер, но и создавать и просматривать на нем же свои страницы, комплектация должна быть получше. Вот, что бы я рекомендовал: - Системный блок - 3-го уровня; - Процессор 2-го уровня; - Видеокарта 2-го уровня; - беспроводная сетевая карта; - две линейки ОЗУ 2-го уровня; - жесткий диск 2-го уровня; - Lua BIOS; - монитор 2-го уровня; - клавиатура.   Установку программного обеспечения начинаем с операционной системы. Надеюсь, Вы знаете как это делается. После установки OpenOS пытаемся подключиться к сети OpenNet. Для этого заходим в интерпретатор Lua, копируем в буфер обмена следующую строку: on=component.modem;e=event;on.open(1)on.broadcast(1,"","","getip")function m()r={e.pull(10,"modem_message")}end;m()ud="update"ip=r[6]function sv()on.send(r[3],1,ud,ip,ud,"getFile","client/"..p)m()filesystem.makeDirectory(filesystem.path(p))f=io.open(p,"w")f:write(r[8])f:close()end p="lib/opennet.lua"sv()p="on/update.lua"sv()loadfile(p)("install") вставляем ее в редактор Lua кнопочкой Ins и запускаем на выполнение. В результате выполнения из Сети будут скачаны все необходимые для подключения файлы и разложены по нужным папкам. Если же чудо не произошло, скорее всего Вы находитесь вне зоны покрытия OpenNet. Обратитесь ко мне и я постараюсь помочь. Если установка прошла успешно, перегружаем компьютер и создаем папку /web mkdir webcd web В этой папке будут храниться страницы нашего будущего сайта. Почему отдельная папка а не корень? Да потому, что к ней будет осуществляться удаленный доступ, причем и на чтение и возможно на запись. И если бы это был корень диска, то каждый хакер при желании смог бы почистить на нашем сервере весь диск. Имена файлов, содержащих страницы сайта могут быть любыми, но непременно должны присутствовать два файла: "index" и "404". Файл index должен содержать главную страницу сайта, а 404 - текст, который будет возвращаться при попытке открыть несуществующую страницу. Создадим файл index, содержащий текст: Главная страница моего сайта И файл 404 с текстом: Извините, запрашиваемая страница не найдена. Для начала попытаемся открыть файл index браузером прямо с сервера: onBrowser /web/index Вот что мы должны увидеть: Поскольку мы указали путь к файлу, начинающийся с косой черты, файл будет открываться браузером не по сети, а с локального компьютера. (продолжение следует)
    • 2 комментария
    • 2 214 просмотра
  • SDV

    Основы защиты построек от робогрифа

    Автор: SDV

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

    На изображении указаны самые основные уязвимые места, которые используют гриферы для осуществления робогрифа.
    Обо всех этих местах и способах защиты я расскажу ниже.       Ветрогенератор
    Наверное самый ненадежный и уязвимый механизм (после солн.панели), которого можно лишиться в один счет.
    Уязвимость связана с тем, что данный блок невозможно никак скрыть от робота.
    При попытке обложить его любыми блоками, ветрогенератор автоматически отказывается работать с ошибкой "Нет места для ротора".
    То есть даже если вы полностью его закроете блоками он работать не будет, для него самое главное это лицевая часть где ротор, а она как известно самое открытое и уязвимое место.
    Робот без труда может подлететь к нему и ключом из IC2 спокойно снять. При желании гриферы также снимают с проводов и кинетические генераторы к ним.
    Способы защиты от грифа: к сожалению нет ничего. как вариант использовать альтернативу в виде солн.панели. Под это же правило входит и гидрогенератор и другие механизмы, которые можно снять ключом из IC2.       Солнечная панель
    Более защищенный генератор энергии, чем ветрогенератор. Но при условии того, что солн.панель должна быть прикрыта сверху (и с других сторон тоже каким-нибудь блоком) стеклом.
    Напомню механику ванильного майнкрафта: стекло является прозрачным блоком, а следовательно при установке его поверх солн.панели он пропускает через себя весь свет, как если бы солн.панель просто стояла неприкрытой к небу.
    А следовательно солн.панель будет получать полный уровень освещенности, не теряя ни 1 единицы с блоком стекла наверху.
    А для робота уже будет проблематично снять такую солн.панель, т.к. для него является препятствием блок стекла и политикой плагина привата робот, как и человек не может сломать в чужом привате никакие блоки.
    Способы защиты от грифа: установка поверх панели блока стекла (любого цвета можно даже), а также солн.панель не должна иметь с сбоков (или снизу) пустого пространства (пустых блоков), в который может переместиться робот и спокойно снять панель.       Дырки в оконных проемах
    Самая распространенная ошибка при строительстве у игроков. т.к. если даже оставить в стене даже одну дырку (1 блок), то робот может беспрепятственно в нее уместиться и посетить ваше жилище.
    А это чревато тем, что робот может "обчистить" ваши сундуки, а также открыть дверь и впустить внутрь грифера, чтобы ему было удобнее управлять роботом.
    Способы защиты от грифа: ВСЕГДА закрывать дырки и проходы, если нет на данный момент нужного материала (стекла,прутья и т.п.), то нужно хотя бы эти дырки залатать обычными плитами (деревянными, из булыжника, камня и т.п.).
    Тем самым дырка будет уже не равна 1 блоку, а 0,5, а это уже мало для прохода роботу.       Ванильные двери
    Как я уже сказал ранее, если в постройке есть дырки, то робот может спокойно заехать в жилище и открыть дверь.
    НО, если будет установлена дверь не из ванильного майнкрафта (не деревянная ID 324 и не железная ID 330), а например дверь из мода OpenSecurity.
    То обычным сигналом редстоуна ее не открыть (необходим контроллер двери), а как известно роботы не могут взаимодействовать с внешними компонентами, поэтому "подключиться" к контроллеру двери он не сможет никаким образом.
    Но если у вас нет пока ресурсов на такую дверь и контроллер, то не переживайте, просто робот не сможет проехать в проем двери, даже если стоит 2 двери. Т.к. двери (предмет) даже открытыми являются 1 блоком, то в этот блок робот не может пройти.
    Способы защиты от грифа: желательно не ставить ванильные двери (дверь из IC2 тоже открывается на редстоун сигнал), по возможности использовать дверь из мода OpenSecurity.
    Но даже если и стоит обычная дверь, то ничего страшного не будет. Игрок конечно сможет пройти в нее, но это лишь дает ему больший обзор пространства и ничего больше (сам снять что-то или "пошариться" по сундукам он не сможет).       Прочие открытые проемы и спуски
    Тоже одна из главных ошибок игроков, когда они делают возле своего дома различные спуски в шахту и т.п.
    А если этот спуск каким-то образом взаимосвязан с входом в дом (например из подвала в дом), то возможен вход через них робота.
    Способы защиты от грифа: не делать различные спуски и проходы возле своего дома, а если и делаете, то не соединяйте их с проходами, подъемами в дом.       Сундуки на территории привата
    Очередная больная тема по поводу сундуков. Многие игроки (в основном начинающие) оставляют сундуки прямо на территории привата, при этом они находятся в открытом доступе для робота.
    В результате чего сундуки могут быть опустошены, а отследить кто это сделал невозможно.
    Способы защиты от грифа: не оставляйте сундуки на открытом пространстве, по возможности располагайте их в недоступном для робота месте.
    Самые ценные ресурсы (алмазы, изумруды, иридий и т.п.) храните не в обычных сундуках, а в эндер-сундуках.
    В отличии от обычных сундуков, роботы не смогут вытащить предметы из эндер-сундука.
    Причина тому, что эндер-сундуки индивидуальны для всех, то есть если для вас эндер-сундук виден вам с вашим содержимым и вашим ником, то для робота эндер-сундук уже свой, со своим именем (робота) и своим инвентарем.
    В общем думаю Вы поняли про что я имею ввиду. Просто запомните, что эндер-сундуки недоступны для роботов.  
    UPD от 19 марта: @Fingercomp подсказал мне, что в якорный сундук из мода Ganys Mod робот также может проникнуть и извлечь все вещи.
    Стоит об этом тоже позаботиться и не ставить в самое видное и удобное место для робота.   Вот на этом я закончу статью.
    Думаю я расписал самые возможные уязвимости и места в постройках игроков.
    Не совершайте подобных ошибок, стройтесь правильно с умом и не будьте жертвами робогрифа.   Если я что-то пропустил или у Вас есть еще варианты того, что может быть объектом для грифа - оставляйте в комментариях эти предложения.
    • 1 комментарий
    • 269 просмотров
  • Krutoy

    Пишу браузер-арбузер

    Автор: Krutoy

    Новости! Теперь мой браузер будет называться "Арбузер", и будет выполнен в зеленоватых тонах.
    Zer0Galaxy мне помогает, и уже набросал парсинг и поиск по самым простым селекторам в CSS. Думаю, ему для полной работы с CSS нужно будет написать еще разов в 6 больше кода.
    Готовы первые наброски самого браузера без страниц. Закладки, навигация, строка пути.
    Кстати, вы можете посмотреть эмулятор экрана компьютера из OC, который можно открыть в браузере и даже посмотреть исходный код.     Ядро написано примерно на 15% пока что. В следующий раз буду отрисовывать элементы страниц, подгружая их стили.
    • 18 комментариев
    • 3 369 просмотров
 

Поиск пути

Когда я узнал о JPS, у меня возникла идея упростить A*. Можно выкинуть волновую рекурсию, которая используется во всех алгоритмах поиска пути. Для этого, берем все узлы, которые являются препятствиями, помечаем соседние свободные узлы и строим путь. Из самого описания выходит, что данный алгоритм подойдет не для всех типов графов, но ботам на регулярной сетке в самый раз. Проблема данного алгоритма в том, что препятствий может быть очень много, а на пути между стартом и финишем очень мало. Фактически это алгоритм Дейкстры без рекурсии, прямой переход в самое последнее возможное состояние. Потребление памяти меньше чем у Дейкстры и А*, т. к. отмечается только финальный фронт. Чтобы оптимизировать, будем отмечать только те граничные узлы, которые находятся ближе к стартовой и финишной точке. Получаем JPS, только избыточней, но лучше чем A* по потреблению памяти. Остается построить путь поиском в ширину из доступных оптимальных путей.   Вот сравнение по потреблению памяти при обходе препятствий:   A* хранит данные о свободных клетках, полученных на данной эвристике. В эти данные входят координаты точки, расстояние до цели, количество предыдущих шагов.     Jump Point Search хранит точки перехода на пути от старта к финишу, хранятся только координаты точек и по выбору: координаты соседних переходов или расстояние до финиша.     При удалении рекурсии надо хранить координаты граничных точек, а все вычисления производить только при построении пути.     Если найти способ не хранить все доступные граничные точки, то алгоритм без рекурсии вполне годится для практического применения. JPS в большинстве применений превосходит A*, он быстрее, потребляет меньше памяти. Но не годится для открытых пространств, если регион поиска искусственно не ограничить, он будет вечно искать оптимальный путь, т. к. его преимущество оборачивается недостатком. Возможно эту проблему уже решили, но никакой информации об этом я не нашел.

Doob

Doob

 

Робот с геосканером. Часть #10 [первая бета]

В процессе подгонки всех функций программа очень быстро разрослась. Дам краткий обзор всех новинок.   Минимальная и максимальная плотность были вынесены в начало программы к остальным переменным. + переменная port, для модема. + переменные steps и turns, вначале для отладки. steps пригодилась для подсчета шагов, чтобы каждые 32 шага проверять состояние инструмента и батареи. + функция arr2a_arr() - преобразование списков в ассоциативный массив для быстрого доступа к элементам. Массивы tails, fragments преобразуются этой функцией, функции работающие с ними, адаптированны соответствующим образом. + функция report(), позволяющая передавать пользователю статусные сообщения посредством модема или связанной карты. В данный момент еще пикает и выводит сообщения на экран. Также завершает работу программы, при получении соответствующего параметра. remove_point() отделилась от функций, удаляющих метки из таблицы. Функция check() отделилась от функции step(). Каждые 32 шага или по принуждению вычисляет расстояние до стартовой точки, сохраняет текущие координаты. Если уровень энергии или инструмента не хватает на дорогу до дома + 64 шага, совершается переход домой, потом возврат к работе. Если есть генератор, происходит попытка заправки. Каждый шаг проверяются точки вокруг робота и удаляются, если робот может их достать. Функция calibration() объединилась с калибровкой компаса. Происходит проверка компонентов: геосканер, контроллер инвентаря, инструмент и наличие блока под роботом, в случае не обнаружения - программа завершается. Настраиваются модем или связанная карта. sorter() упростилась и ускорилась. + функция home() перемещает робота на точку старта, запускает сортировку и упаковку предметов, ищет сундук (требует, в случае не обнаружения). Складывает добычу в сундук, в случае переполнения ждет,  когда освободится место. Достает из сундука неупакованные предметы и переупаковывает. Забирает из сундука стак с углем, при наличии генератора. Кроме перехода к точке старта, ищет в инвентаре эндерсундук из EnderStorage и сгружает ресурсы в него. Пытается найти более новый инструмент в сундуке, либо ищет зарядник и пробует засунуть в него и зарядить. На точке старта ждет, пока уровень энергии не достигнет 99% потом возвращается к работе. + функция main() - основной цикл сканирования и добычи. Робот сканирует весь чанк, в цикле перебирает все метки, выбирает ближайшую и перемещается к ней, пока не пройдет по всем. Ну и цикл перехода по спирали от чанка к чанку. Запускает функцию main(), по завершении вычисляет координаты следующего чанка, перемещает к нему, запускает main() и т. д., пока не дойдет до последнего, потом вызывает функуию home() и завершает работу.   Осталось добавить возвращение по хлебным крошкам при аварии. И правильную работу с инструментами, имеющими нестандартную механику износа - энергетические и магические кирки/буры из модов. Еще можно заставить робота таскать с собой генератор из какого-нибудь мода и зарядник, тогда ему не нужно будет возвращаться на точку старта для подзарядки (а с эндерсундуком вообще на надо будет возвращаться)   Бета-версию можно посмотреть и скачать тут - https://pastebin.com/hXWLDKre  

Doob

Doob

 

Прокачка стектрейса

Эта беспрецедентно короткая запись имеет начало своих ног в запросе @Laine_prikol, как-то спросивший в нашей ирке, можно ли стэктрейс сделать не таким тупым. Меня это заинтересовало, и спустя часик выросла очень короткая программка, которая рисует вот такие стэктрейсы: # 0: C field function yield(...) (defined in [C]) # 1: Lua local function f(f=function: 0x55bea5785ef0, a=42, b=24, ...):79 (defined in trace.lua at L78) # 2: Lua local function outer(f=function: 0x55bea608c900, g=function: 0x55bea5785ef0, a=42, b=24):75 (defined in trace.lua at L73) # 3: Lua function <anon>:83 (defined in trace.lua at L72) Заметили что-то необычное? Наконец-то пишется, какие аргументы имеются у функции, потому что это куда информативнее беглому взгляду, чем описание расположения и строки.   Код лежит на гисте: https://gist.github.com/Fingercomp/a688d221356cb371d940b947d0ca90a8. Использованы функции debug.getinfo и debug.getlocal. Аргументы должны писаться даже внутри OC, но уже без значений.

Fingercomp

Fingercomp

 

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

Эвристические функции: Давление - штраф на ход по вертикали. Нужен из-за того, что начало сканирования либо сверху, либо снизу, следовательно, заканчивать добычу надо ближе туда, где начнется следующее сканирование. Недоход - робот не заходит на позицию метки, чтобы сэкономить лишний шаг (не всегда оптимально, но суммарный эффект - положительный) Штраф на повороты - добавление шага, при оценке расстояния, если целевой блок находится дальше, чем в одном блоке от текущей оси.   Изначально идея была в том, чтобы собрать такое сочетание эвристик, при котором робот будет быстрее заканчивать добычу и выходить к точке старта. Важно, чтобы робот финишировал наверху, для быстрого перехода к следующему чанку.
Сначала добавил ограничение хода по вертикали. Если робот может достать блок, не доходя до него, то добывает и ищет следующий.
Потом добавил такую же функцию для всех осей. Прибавил еще мягкое давление по вертикали, чтобы нижние блоки имели приоритет над верхними. Но когда запустил пачку роботов, перепутал знак и получил давление вверх. Пришлось потом запускать еше, с правильной формулой.
Из всех решений выбрал лучший результат - штраф на повороты, недоход по всем осям и давление вниз. В тесте робот довольно много скакал по вертикали, я решил это исправить. Увеличил давление в два раза, но не заметил, что половина формулы поменяла знак. Робот стал настолько мало скакать по вертикали, что процесс превратился в послойную добычу, со слоем 2 блока. Перевернул формулу, чтобы добыча опять шла снизу вверх. Поменял обратно, получил не очень хороший результат - робот получает меньше свободы, делает больше лишних движений.   По факту, сейчас штрафы на повороты конкурируют с недоходом, т. к. при добыче больших залежей, у робота вокруг много блоков и ему без разницы, сделать шаг к следующему или повернуться к соседнему. Самый оптимальный вариант для таких случаев - змейкой, но у этих залежей бывают всякие аппендиксы. Это вызывает некоторую нагрузку на дальнейшие ходы - роботу приходится больше вертеться и ходить.
К тому же, недоход надо расширить: из-за того, что счет идет шагами, без точного учета поворотов - робот может не повернуться к соседнему блоку. Или зайти в блок, если он находится в соседнем блоке к текущей оси, хотя мог бы достать без последнего шага.
Осталось придумать, как это починить без лапши (хотя там лапша из одного бряка по флагу, но все-равно не приятно) и подобрать такие уровни штрафов/давления, чтобы робот красиво закольцовывал добычу с большим выигрышем по времени, чем сейчас.   Параметры: чанк со стандартной генерацией (IC2+AE2), без каверн, алмазная кирка без всяких заклятий и примочек, робот без бустеров. Время Шаги Повороты Сумма 1361 1094 430 1524 послойный 1189 982 358 1340 свободный без улучшений 1185 972 358 1330 недоход по y 1156 932 368 1300 недоход по y, давление вниз 1248 1076 360 1436 недоход по y, давление вверх 1254 1036 380 1416 недоход по xyz 1186 948 368 1316 недоход по xyz, давление вниз 1267 1064 374 1438 недоход по xyz, давление вверх 1210 996 302 1298 штраф на повороты, недоход по y 1141 928 326 1254 штраф на повороты, недоход по xyz, давление вниз 1291 1122 358 1480 штраф на повороты, недоход по xyz, давление вверх x2 1244 1032 368 1400 штраф на повороты, недоход по xyz, давление вниз x2 Итого, самый оптимальный получился - 1254 действия за 19 минут 1 секунду.   А вот прогон на тестовом стенде ничего не показал - слишком маленькое расстояние. Но все-таки, на 10 секунд раньше взял последний блок, чем в прошлом тесте.  

Doob

Doob

 

Робот с геосканером. Часть #8 [основа основ]

Для настройки работы программы, надо узнать плотность добываемых блоков и плотность мусора, чтобы сделать предварительный фильтр на этапе сканирования. Плотность одной руды в разных модах отличается, но она близка к ванильной т. к. механика работы инструментов одна. Сделал шпаргалку с информацией о плотностях из разных модов. Плотность, уровень инструмента, название. Minecraft 3 2 Алмазная руда 3 2 Изумрудная руда 3 2 Золотая руда 3 2 Красная руда 3 1 Железная руда 3 1 Лазуритовая руда 3 0 Угольная руда 3 0 Кварцевая руда 0.3 -1 Светокамень -1 -1 Бедрок 50 3 Обсидиан 3 -1 Эндерняк 2.5 0 Сундук 2 0 Булыжник 2 -1 Адский кирпич 2 0 Доски 1.5 0 Камень 1.5 -1 Каменный кирпич 1.25 -1 Терракота 0.8 0 Песчаник 0.6 0 Трава 0.6 0 Гравий 0.6 0 Глина 0.5 0 Земля 0.5 0 Песок 0.4 0 Адский камень 0.5 0 Песок душ -------------------------------------------- IC2 4 2 Урановая руда 3 1 Медная руда 3 1 Оловянная руда 2 1 Свинцовая руда -------------------------------------------- AE2 50 3 Небесный камень 50 0 Сундук из небесного камня 3 0 Кварцевая руда -------------------------------------------- Mekanism 3 -1 Осмиевая руда 3 -1 Медная руда 3 -1 Оловянная руда -------------------------------------------- Forestry 3 1 Апатитовая руда 3 1 Медная руда 3 1 Оловянная руда -------------------------------------------- TConstruct 10 4 Кобальтовая руда 10 4 Ардитовая руда -------------------------------------------- ThermalFoundation 3 1 Медная руда 3 1 Оловянная руда 3 2 Серебряная руда 3 2 Свинцовая руда 3 1 Алюминиевая руда 3 2 Никелевая руда 3 3 Платиновая руда 3 3 Иридиевая руда 3 3 Мифриловая руда -------------------------------------------- Galacticraft 6 1 Алюминиевая руда 5 1 Оловянная руда 5 1 Медная руда 3 2 Кремниевая руда Moon 5 1 Медная руда 5 1 Оловянная руда 5 -1 Сапфировая руда 3 1 Сырная руда 1.5 0 Лунный камень 0.5 0 Лунный грунт 0.5 -1 Лунный дерн Mars 2.2 3 Деш руда 2.2 1 Железная руда 2.2 1 Оловянная руда 2.2 1 Медная руда 2.2 0 Булыжник 2.2 0 Реголит Asteroids 3 2 Алюминиевая руда 3 3 Ильменитовая руда 3 2 Железная руда 3 0 Камень Venus 5 -1 Алюминиевая руда 5 -1 Медная руда 5 -1 Свинцовая руда 5 -1 Кварцевая руда 5 -1 Кремниевая руда 5 -1 Оловянная руда 5 -1 Солнечная пыль 2.2 1 Магма 2.2 1 Пемза 1.5 1 Твердый камень 0.9 1 Мягкий камень 0.9 -1 Выжженный камень  

Doob

Doob

 

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

Все-таки добывать руду слоями дольше, чем свободным обходом всех доступных блоков. На тестовом стенде свободный - 2 минуты 50 секунд, послойный - 3 минуты 9 секунд.       Тут очень сильно напрашивается дополнительная эвристика на сокращение поворотов и прямых одноблочных ходов. И упаковку запускать только при нужде.

Doob

Doob

 

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

Добытые ресурсы надобно рассортировать. Для этого дела задействуем контроллер инвентаря. Надобно пройти по всем слотам, получить информацию о содержимом и сравнить название со списком ненужных предметов (который предварительно составим), при совпадении опустошать.   Но это не вся функция. У нас есть еще верстак, который может помочь, очень сильно ужать, некоторые ресурсы (уголь, редстоун, алмазы, изумруды, лазурит). Верстак занимает в инвентаре 9 слотов, еще 1 слот добавим на результат, если не все влезет в блок. Поэтому, пока робот ищет мусор, пусть считает пустые слоты, для верстака. В начале уберем блоки сверху и снизу, чтобы случайно не перемешать мусор с излишками добра. для удобоваримости сократил некоторые имена: inventory - размер инвентаря, получим в начале работы программы, controller - контроллер инвентаря, tails - список названий лишних предметов (без префикса "minecraft:", можно добавлять названия из любого мода) robot.swing(0) -- освободить место для мусора robot.swing(1) -- освободить место для буфера ------- сброс мусора ------- local empty = 0 -- создать счетчик пустых слотов for slot = 1, inventory do -- пройти по слотам инвентаря local item = controller.getStackInInternalSlot(slot) -- получить информацию о предмете if item then -- если есть предмет for name = 1, #tails do -- пройти по таблице хвостов if item.name:gsub('%g+:', '') == tails[name] then -- проверить на совпадение robot.select(slot) -- выбрать слот robot.drop(0) -- выбросить к отходам empty = empty + 1 -- обновить счетчик break -- прервать цикл сравнения end end else empty = empty + 1 -- обновить счетчик end end   Далее следует проверить и выкинуть наверх предметы, которые будут мешать при крафте. Подсчитанные пустые слоты отнимем от требуемого количества для крафта, пройдем по инвентарю уберем их. -- упаковка предметов в блоки -- if crafting then -- если есть верстак -- перенос лишних предметов в буфер -- if empty < 10 then -- если пустых слотов меньше 10 empty = 10-empty -- увеличить количество пустых слотов для обратного отсчета for slot = 1, inventory do -- просканировать инвентарь if robot.count(slot) > 0 then -- если слот не пуст robot.select(slot) -- выбрать слот robot.drop(1) -- выбросить в буфер empty = empty - 1 -- обновить счетчик end if empty == 0 then -- если место освободилось break -- прервать цикл end end end   Предварительно создадим таблицу fragments, в которой будут храниться названия предметов, которые можно сложить в блоки. Теперь создадим таблицу, в которой будут счетчики для каждого типа фрагментов. Пройдем по инвентарю, получим информацию о слоте, сравним, прибавим - все как в первом цикле, можно было бы даже их объединить, но на предыдущем шаге мы выкинули какие-то предметы. Чтобы узнать какие именно - придется городить еще один цикл, оставим как есть. -- подсчет предметов доступных для упаковки -- local available = {} -- создать таблицу счетчиков for slot = 1, inventory do -- пройти по слотам инвентаря local item = controller.getStackInInternalSlot(slot) -- получить информацию о предмете if item then -- если есть предмет for n = 1, #fragments do -- пройти по списку названий фрагментов if item.name:gsub('%g+:', '') == fragments[n] then -- сравнить по имени if available[n] then -- если есть подобные фрагменты available[n] = available[n] + item.size -- обновить else -- иначе available[n] = item.size -- создать end break end end end end   Наконец-то можно крафтить. Хотя, нет. Надо расчистить слоты верстака, чтобы в него сложить рецепт. Будем перебирать слоты от 1 до 9, но в роботе верстак занимает слоты с другими номерами, а именно 1 2 3 5 6 7 9 10 11, можно было бы составить условие от 1 до 11, с исключением целых по модулю 4. Сделаем проще - номера слотов занесем в таблицу "workbench", которая будет служить списком ссылок с системы 1-9 на 1-11. Вынесем ее подальше, чтобы она не создавалась при каждом запуске. В цикле проверяем количество предметов в слоте, если оно не нулевое - ищем в инвентаре пустой слот, исключая слоты верстака. Переносим предметы в найденный слот. Если перенести не удалось - что-то попало в верстак после крафта. Забираем предметы из буфера и завершаем функцию, возвращая true, что будет сообщать о перегрузе и времени выдвигаться домой. for c_slot = 1, 9 do -- цикл чистки зоны верстака if robot.count(workbench[c_slot]) > 0 then -- если слот не пуст robot.select(workbench[c_slot]) -- выбрать слот верстака for slot = 4, inventory do -- обойти весь инвентарь, кроме рабочей зоны if robot.count(slot) == 0 and (slot == 4 or slot == 8 or slot > 11) then -- если есть свободный robot.transferTo(slot) -- освободить слот break -- выйти из цикла end end if robot.count() > 0 then -- проверить на перегрузку robot.suck(1) -- забрать из буфера return true -- остановить упаковку end end end   Верстак расчищен, пора заняться упаковкой. Перебираем слоты инвентаря, исключая верстак, сравниваем названия со списком. При совпадении, делим содержимое на 9, заполняем верстак И крафтим блок. ------- основной цикл крафта ------- for slot = 4, inventory do -- цикл поиска фрагментов local item = controller.getStackInInternalSlot(slot) -- получить информацию о предмете if item and (slot == 4 or slot == 8 or slot > 11) then -- если есть предмет вне рабочей зоны if item.name:gsub('%g+:', '') == fragments[i] then -- сравнить по названию фрагмента robot.select(slot) -- при совпадении выбрать слот for n = 1, 9 do -- цикл заполнения рабочей зоны robot.transferTo(workbench[n], item.size/9) -- разделить текущий стак на 9 частей и перенести в верстак end if robot.count(1) == 64 then -- сброс при заполнении верстака break end end end end crafting.craft() -- создание блока Можно заметить fragments, откуда i? Об этом позже.   После крафта могли остаться какие-то остатки, если не все слоты поделились на 9. Проверяем содержимое в слотах, если предметов меньше 64 - перебираем слоты после текущего и сравниваем, при совпадении содержимого пробуем перенести. При опустошении текущего слота - прерываем перебор со сравнением. -- цикл сортировки остатков for A = 1, inventory do -- основной проход local size = robot.count(A) -- получить количество предметов if size > 0 and size < 64 then -- если слот не пуст и не полон robot.select(A) -- выбрать слот for B = A+1, inventory do -- проход сравнения if robot.compareTo(B) then -- если предметы одинаковые robot.transferTo(B, 64-robot.count(B)) -- перенести до заполнения end if robot.count() == 0 then -- если слот освободился break -- прервать сравнение end end end end   Последние три цикла заворачиваем в такую конструкцию: for i = 1, #fragments do -- перебор всех названий if available[i] then -- если в инвентаре такой есть for j = 1, math.ceil(available[i]/576) do -- разделить результат на стаки ... end end end Первый цикл перебирает названия фрагментов. Условный оператор проверяет наличие такого типа в инвентаре. Внутренний цикл повторяет чистку, крафт и сортировку, если в результате будет больше стака блоков.     Новые используемые переменные: local tails = {'cobblestone','dirt','gravel','sand','stained_hardened_clay','sandstone','stone','grass','end_stone','hardened_clay','mossy_cobblestone','planks','fence','torch','nether_brick','nether_brick_fence','nether_brick_stairs','netherrack','soul_sand'} local workbench = {1,2,3,5,6,7,9,10,11} local fragments = {'redstone','coal','dye','diamond','emerald'} local controller = add_component('inventory_controller') local crafting = add_component('crafting') local inventory = robot.inventorySize()   Полный текст функции, с более рациональным вызовом robot.count(): local function sorter() -- сортировка лута robot.swing(0) -- освободить место для мусора robot.swing(1) -- освободить место для буфера ------- сброс мусора ------- local empty = 0 -- создать счетчик пустых слотов for slot = 1, inventory do -- пройти по слотам инвентаря local item = controller.getStackInInternalSlot(slot) -- получить информацию о предмете if item then -- если есть предмет for name = 1, #tails do -- пройти по таблице хвостов if item.name:gsub('%g+:', '') == tails[name] then -- проверить на совпадение robot.select(slot) -- выбрать слот robot.drop(0) -- выбросить к отходам empty = empty + 1 -- обновить счетчик break -- прервать цикл сравнения end end else empty = empty + 1 -- обновить счетчик end end -- упаковка предметов в блоки -- if crafting and empty < 12 then -- если есть верстак и переполнение -- перенос лишних предметов в буфер -- if empty < 10 then -- если пустых слотов меньше 10 empty = 10-empty -- увеличить количество пустых слотов для обратного отсчета for slot = 1, inventory do -- просканировать инвентарь if robot.count(slot) > 0 then -- если слот не пуст robot.select(slot) -- выбрать слот robot.drop(1) -- выбросить в буфер empty = empty - 1 -- обновить счетчик end if empty == 0 then -- если место освободилось break -- прервать цикл end end end -- подсчет предметов доступных для упаковки -- local available = {} -- создать таблицу счетчиков for slot = 1, inventory do -- пройти по слотам инвентаря local item = controller.getStackInInternalSlot(slot) -- получить информацию о предмете if item then -- если есть предмет for n = 1, #fragments do -- пройти по списку названий фрагментов if item.name:gsub('%g+:', '') == fragments[n] then -- сравнить по имени if available[n] then -- если есть подобные фрагменты available[n] = available[n] + item.size -- обновить else -- иначе available[n] = item.size -- создать end break end end end end ------- основной цикл крафта ------- for i = 1, #fragments do -- перебор всех названий if available[i] then -- если в инвентаре такой есть for j = 1, math.ceil(available[i]/576) do -- разделить результат на стаки for c_slot = 1, 9 do -- цикл чистки зоны верстака if robot.count(workbench[c_slot]) > 0 then -- если слот не пуст for slot = 4, inventory do -- обойти весь инвентарь, кроме рабочей зоны if robot.count(slot) == 0 and (slot == 4 or slot == 8 or slot > 11) then -- если есть свободный robot.select(workbench[c_slot]) -- выбрать слот верстака robot.transferTo(slot) -- освободить слот break -- выйти из цикла end end if robot.count() > 0 then -- проверить на перегрузку robot.suck(1) -- забрать из буфера return true -- остановить упаковку end end end ------- основной цикл крафта ------- for slot = 4, inventory do -- цикл поиска фрагментов local item = controller.getStackInInternalSlot(slot) -- получить информацию о предмете if item and (slot == 4 or slot == 8 or slot > 11) then -- если есть предмет вне рабочей зоны if item.name:gsub('%g+:', '') == fragments[i] then -- сравнить по названию фрагмента robot.select(slot) -- при совпадении выбрать слот for n = 1, 9 do -- цикл заполнения рабочей зоны robot.transferTo(workbench[n], item.size/9) -- разделить текущий стак на 9 частей и перенести в верстак end if robot.count(1) == 64 then -- сброс при заполнении верстака break end end end end crafting.craft() -- создание блока -- цикл сортировки остатков for A = 1, inventory do -- основной проход local size = robot.count(A) -- получить количество предметов if size > 0 and size < 64 then -- если слот не пуст и не полон for B = A+1, inventory do -- проход сравнения if robot.compareTo(B) then -- если предметы одинаковые robot.select(A) -- выбрать слот robot.transferTo(B, 64-robot.count(B)) -- перенести до заполнения end if robot.count() == 0 then -- если слот освободился break -- прервать сравнение end end end end end end end end robot.suck(1) --- забрать предметы из буфера end  

Doob

Doob

 

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

При запуске программы надо оценить возможности робота, чтобы в дальнейшем, можно было точно знать количество энергии для перехода на точку старта.
Робот должен измерить уровень энергии, сделать шаг, измерить еще раз и вычислить разницу. Эту разницу будет учитывать при измерении расстояния и принимать решение - идти домой или не идти.
Функция robot.durability() не показывает правильный износ для зачарованных инструментов.
Придется несколько раз ставить и разрушать блок, пока не обнаружится износ.
Вынесем пока это все в отдельную функцию calibration() local function calibration() -- калибровка при запуске local energy = computer.energy() -- получить уровень энергии step(0) -- сделать шаг E_C = math.ceil(energy-computer.energy()) -- записать уровень потребления energy = robot.durability() -- получить уровень износа/разряда инструмента while energy == robot.durability() do -- пока не обнаружена разница robot.place(1) -- установить блок robot.swing(1) -- разрушить блок end W_R = energy-robot.durability() -- записать результат step(1) -- вернуться на место end Переменные E_C и W_R выносим в обую область видимости. Во время работы, например, после четырех сканов, робот будет оценивать количество доступных шагов по этой формуле: math.min(robot.durability()/W_R, computer.energy()/E_C) и сравнивать с расстоянием до точки старта. Из-за магической механики, зачарованные инструменты (Unbreaking) изнашиваются неравномерно, но роботу это нисколько не мешает.

Doob

Doob

 

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

Геосканер потребляет много энергии, а функция compass() делает по 4 скана, пока не установит направление. Надо это исправить. Пусть робот сначала проверит наличие блока перед носом, сделает скан всех блоков вокруг себя, затем сломает блок и проверит разницу в полученных данных. Таким образом, будет производиться всего два сканирования, в прошлой версии их могло быть бесконечно много - если рядом нет блоков, робот бы крутился и молотил инструментом по воздуху, попутно делая по 4 сканирования. Улучшенная функция будет выглядеть так: local function compass() local sides = {2, 1, 3, 0} -- линки сторон света, для сырых данных D = nil -- обнуление направления while not D do -- пока не найдено направление if robot.detect(3) then -- проверить наличие блока перед носом local A = geolyzer.scan(-1, -1, 0, 3, 3, 1) -- сделать первый скан robot.swing(3) -- сломать блок local B = geolyzer.scan(-1, -1, 0, 3, 3, 1) -- сделать второй скан for n = 2, 8, 2 do -- обойти смежные блоки в таблице if math.ceil(B[n])-math.ceil(A[n])<0 then -- если блок исчез D = sides[n/2] -- установить новое направление break -- выйти из цикла end end else turn() -- задействовать простой поворот end end end  

Doob

Doob

 

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

Ядро копателя готово, теперь можно и пощупать. Напишем пробную функцию сканирования и добычи одного слоя. Сначала откалибруем компас и зададим таблицу с координатами сканируемых квадратов. Затем, отсканируем квадрат 16 на 16 блоков, выведем количество обнаруженных блоков. И в цикле обойдем все метки. Вроде бы все просто.   Ах, да... будем искать ближайший блок к текущей позиции, чтобы быстрее закончить работу. Есть много подходов к определению расстояний. Например квадрат гипотенузы равен сумме квадратов катетов, формула для нашего случая будет math.sqrt((X-x)^2+(Z-z)^2), где X,Z - координаты робота, x,z - координаты метки, можно выкинуть квадратный корень, в нашем случае бесполезный и даже вредный. Но тут есть одно "но", мы получили гипотенузу, а это наименьшее расстояние между точками, а роботы по диагонали не ходят.   Я буду вычислять дельту между точками, суммируя реальное расстояние, которое пройдет робот по формуле math.abs(X-x)+math.abs(Z-z) Эта операция в сферическом вакууме потребляет на 5% больше процессорного времени, чем предыдущая, но с лихвой окупается сэкономленными шагами.   В цикле будем обходить таблицу с метками, до каждой вычисляя расстояние, самый лучший результат с индексом будем хранить в отдельных переменных. По окончании работы цикла, будем посылать робота в ближайшую точку.   Код всей тестовой программы под спойлером.   А вот и видео с демонстрацией.     Можно добавить штрафы на повороты, тогда он будет меньше крутиться и собирать кучи линейкой, а не змейкой.

Doob

Doob

 

Робот с геосканером. Часть #2 [сканирование]

Робот может двигаться, пора добавить функцию сканирования породы и калибровки компаса. (Пока тестировал, обнаружил баг работы с зачарованными инструментами, пришлось немного переделать функцию step() - теперь после неудачного свинга, робот дополнительно проверяет наличие блока. Можно будет оставить, даже когда разрабы это исправят)   Чтобы отфильтровать блоки по плотности, надо получить плотность нужных блоков с учетом шумов. На расстоянии x8 z8 y1 от геосканера, максимальная плотность бедрока равна -0.317, внесем в фильтр -0.31. Для руды 3.683, но это ванильная руда, в модах бывает и больше. Минимальная плотность обсидиана 49.312, значит, eсли он не нужен, установим для полезных блоков максимальную плотность 40. C минимальной плотностью не все так гладко. Свинцовая руда из индастриала имеет плотность 2.5 это как у деревянных предметов, разброс с учетом шума от 1.3 до 2.7, это пересекается с камнем, у которого 0.8 - 2.2. Вот таблица некоторых блоков с минимальной и максимальной плотностью: Руда 2.312 - 3.683 Стекло -0.388 - 0.983 Камень 0.812 - 2.183 Грязь -0.188 - 1.183 Сундук 1.312 - 2.683 Обсидиан 49.312 - 50.683 Видно, что плотность стекла пересекается с плотностью коренной породы, но у бедрока приоритет выше, поэтому лучше лишний раз обойти. Исходя из этих данных, полезные блоки будут отмечаться с минимальной плотностью 2.3 и максимальной 40   Теперь опишем функцию сканирования. Заглянем в подсказку. Чтобы получить сырые данные, зададим координаты и размеры квадрата, относительно сканера. geolyzer.scan(позиция_х, позиция_z, позиция_y, ширина, длина, высота)   Так как один раз можно отканировать только 64 блока, будем делать 4 подхода, получая координаты квадрата по горизонтали из вызывающей функции. Преобразовываем данные в координаты, попутно анализируя плотность условным оператором и устанавливаем метки. При обнаружении бедрока устанавливаем соответсвующий флаг во внешней для всех функций переменной. Получаем функцию scan(), выглядеть она будет примерно так: local function scan(xx, zz) -- сканирование квадрата x8 относительно робота local raw, index = geolyzer.scan(xx, zz, -1, 8, 8, 1), 1 -- получить сырые данные, установить индекс в начало таблицы for z = zz, zz+7 do -- развертка данных по z for x = xx, xx+7 do -- развертка данных по х if raw[index] >= 2.3 and raw[index] <= 40 then -- если обнаружен блок с плотностью от 2.3 до 40 table.insert(WORLD.x, X+x) --| записать метку в список table.insert(WORLD.y, Y-1) --| с коррекцией локальных table.insert(WORLD.z, Z+z) --| координат геосканера elseif raw[index] < -0.31 then -- если обнаружен блок с отрицательной плотностью border = true -- сделать отметку end index = index + 1 -- переход к следующему индексу сырых даннх end end end   Раз уже взялись за геосканер, напишем и компас. Чтобы определить стороны света, надо сломать блок перед носом, просканировать его, затем установить обратно и, если есть разница - выдать результат. Для большей надежности добавим вращение вокруг своей оси, т. к. блока перед носом может и не быть или быть, но не тот. Координаты блоков задаем в таблице, сбрасываем текущее направление, определяем заново, вот и вся функция. Назовем ее compass() local function compass() -- определение сторон света local sides = {{-1,0}, {0,-1}, {1,0}, [0]={0,1}} -- привязка значений сторон света к смежным блокам D = nil -- обнуление текущего направления while not D do -- пока направление не найдено for n = 0, 3 do -- перебор сторон света robot.swing(3) -- разрушение блока if geolyzer.scan(sides[n][1], sides[n][2], 0, 1, 1, 1)[1] == 0 and robot.place(3) then -- тестовое сканирование и установка блока if geolyzer.scan(sides[n][1], sides[n][2], 0, 1, 1, 1)[1] > 0 then -- если обнаружена разница в сканах D = n -- установить новое направление break -- выйти из цикла end end end turn() -- задействовать простой поворот end end   Самые важные функции готовы, можно приступить к тестированию.      

Doob

Doob

 

Робот с геосканером. Часть #1 [движения]

Чтобы программа могла контролировать движения робота, добавим систему координат и функционал связанный с ней. Так как робот будет шахтером, то все движения должны сопровождаться разрушением блоков, он будет ползать сквозь породу, попутно захватывая руду. Описание основной двигательной деятельности занимает всего четыре функции (можно и три, но в прошлой версии, в процессе борьбы за место, пришлось одну разделить) Приведу базовый код, затем опишу, что он делает. local component = require('component') -- подгрузить обертку из OpenOS local X, Y, Z, D = 0, 0, 0, 0 local WORLD = {x = {}, y = {}, z = {}} local function add_component(name) -- получение прокси компонента name = component.list(name)() -- получить адрес по имени if name then -- если есть адрес return component.proxy(name) -- вернуть прокси end end local robot = add_component('robot') -- загрузка компонента local function step(side) -- функция движения на 1 блок local state, type = robot.swing(side) -- тестовый свинг if not state and type == 'block' then -- если блок нельзя разрушить print('bedrock') os.exit() -- временная заглушка else while robot.swing(side) do end -- копать пока возможно end if robot.move(side) then -- если робот сдвинулся, обновить координаты if side == 0 then Y = Y-1 elseif side == 1 then Y = Y+1 elseif side == 3 then if D == 0 then Z = Z+1 elseif D == 1 then X = X-1 elseif D == 2 then Z = Z-1 else X = X+1 end end end if #WORLD.x ~= 0 then -- если таблица меток не пуста for i = 1, #WORLD.x do -- пройти по всем позициям if X == WORLD.x[i] and (Y-1 <= WORLD.y[i] and Y+1 >= WORLD.y[i]) and Z == WORLD.z[i] then if WORLD.y[i] == Y+1 then -- добыть блок сверху, если есть robot.swing(1) elseif WORLD.y[i] == Y-1 then -- добыть блок снизу robot.swing(0) end table.remove(WORLD.x, i) -- удалить метку из таблицы table.remove(WORLD.y, i) table.remove(WORLD.z, i) end end end end local function turn(side) -- поворот в сторону side = side or false if robot.turn(side) then -- если робот повернулся, обновить переменную направления if side then D = (D+1)%4 else D = (D-1)%4 end end end local function smart_turn(side) -- поворот в определенную сторону света while D ~= side do turn((side-D)%4==1) end end local function go(x, y, z) -- переход по указанным координатам while Y ~= y do if Y < y then step(1) elseif Y > y then step(0) end end if X < x then smart_turn(3) elseif X > x then smart_turn(1) end while X ~= x do step(3) end if Z < z then smart_turn(0) elseif Z > z then smart_turn(2) end while Z ~= z do step(3) end end Сначала создаются переменные для локальных координат робота. X, Y, Z - собственно, позиция робота, относительно стартовой точки.   D - направление, куда смотрит мордочка робота. при старте программы она относительная. Поэтому, чтобы привязать ее к сторонам света, надо будет произвести некоторое шаманство при помощи геосканера.   Таблица WORLD - это метки, которые будут устанавливаться в процессе сканирования. Таблица разделена на три, это смежные хранилища переменных для каждой координаты, например, сканер обнаружил блок с подходящей плотностью по координатам x15, y-10, z3, в таблицу они будут добавлены по одному индексу. Допустим, таблица была пустая, после добавления будет иметь вид WORLD.x[1] = 15, WORLD.y[1] = -10, WORLD.z[1] = 3 или WORLD = {x = {15}, y = {-10}, z = {3}}   Далее следует функция, упрощающая добавление компонентов. На вход получает имя нужного компонента и, если он есть, выдает прокси к нему.   Функция step() - основное движение робота. Учитывая, что программа используется исключительно для копания, копание будет в каждом шаге. Робот не тыкается носом в породу и не спрашивает какой блок перед ним. Махнул инструментом и смотрит результат. Если есть блок, но добыть его не получилось - следовательно, дальше делать нечего, там бедрок или еще чего похуже, потом добавим правильную обработку и эвакуацию по хлебным крошкам, а пока пусть будет заглушка. Если махнул удачно - пробуем еще раз и еще, до посинения. Это своеобразная защита от лагающего гравия/песка и назойливых сущностей (в виде гномиков). Далее, если функция движения была совершена удачно, то обновляем локальные координаты, учитывая направление движения. Ну и в конце функции сканируем таблицу меток, ищем метки с текущей позицией и удаляем, т. к. по нашим данным робот находится в блоке руды, следовательно, он его добыл. Еще есть дополнительная проверка по вертикали - если есть руда сверху или снизу, то захватываем, это позволит сократить общую сумму переходов между метками и ускорить добычу.   Функция turn() - основной поворотник (аналог robot.turn(), но с обновлением переменной направления) Робот поворачивается, записывая результат в переменную, добавляя/отнимая единицу по модулю 4 при каждом повороте.   Функция smart_turn() - поворот на желаемую сторону света, с минимумом действий. Вычисляет разницу между текущим и целевым направлением, запуская результат по модулю 4 через turn() Функции поворота можно будет объединить, но пока оставлю так.   Функция go() - великий ход конем до нужных координат. Принимает координаты целевого блока, двигается по вертикали, поворачивает на цель X, двигается до цели, поворачивает на цель Z, двигается до цели. Для поворота использует smart_turn(), т. к. оси x и z глобальные, это стороны света.    

Doob

Doob

 

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

И так, наконец-то возвращаюсь к роботу-копателю. Да будут новые баги и новые фичи!   Краткий план внедряемых фич: Улучшенное сканирование руд.
    Робот сканирует под собой квадрат 16x16 блоков, опускаясь блок за блоком.
    При обнаружении бедрока запускается функция добычи.
    При добыче робот поднимается и в цикле ищет ближайшие по горизонтали блоки руды, захватывая три слоя - Y+1, Y, Y-1   Определение энергопотребления сборки при запуске. На старте, робот запоминает количество потребленной энергии на один шаг + прочность инструмента. Это будет служить константой при проверке статуса, чтобы была возможность гарантированно вернуться на точку старта.   Умная упаковка добычи. Перед обработкой рассыпухи, теперь будет точнее анализироваться свободное место, упаковка не будет происходить механическим перебором, из-за которого бывали внезапные сбои.   При наличии генератора, робот всегда будет с собой таскать уголь, при разгрузке на точке старта будет забирать стак угля или угольных блоков.   Текущие константа энергопотребления и координаты будут записываться в EEPROM. Следовательно, при наличии сетевой/связанной карты, робота можно будет будить и не бояться выгрузки чанков, лагов, космических лучей.   Скорее всего, добавлю функцию аварийного крафта кирок из булыги, в случае работы с ванильными инструментами.   Планируется утилита, собирающая программу по параметрам, заданным пользователем. ...Или не планируется, скорее всего все возможности копалки не получится впихнуть на EEPROM, поэтому на EEPROM будет загрузчик с main функцией, а дополнительные модули придется записывать на жесткий диск.   Планируется поддержка модов, например, возможность возить с собой и разворачивать заправочную станцию в виде генератора и зарядника. Или скидывать предметы в межпространственные сундуки. Тут надо будет смотреть, как будут развиваться моды.   В блоге буду описывать каждую функцию, чтобы отследить создание программы шаг за шагом, надеюсь, кому-то это поможет.

Doob

Doob

 

Обновление OpenComputers до версии 1.7.3

Эм, здрассьте. Предлагаю поглядеть на новое обновление мода. Очень толстого обновления. Отрегулировали частоту выполнения хука, который шлёт этот ненавистный "too long without yielding", так что теперь и скорость исполнения кода должна гораздо возрасти, и с ошибкой этой код падать реже. Мы проверяли: некая гуи-либа с 1.6 fps до 2.5 fps только благодаря этому работать стала. Оптимизировали производительность ещё и записи на диск. Пошустрее будет — обещают, что в 5–500 раз. Сетевой разделитель (сплиттер) стал компонентом. Можно программно теперь отключать куски сети. Жёсткие диски стало возможным делать Read-Only. Компьютеры CC могут читать сигналы бандлед-редстоуна OC. И наоборот. Функции [il]debug.getlocal[/il] и [il]debug.getupvalue[/il]: возвращают они лишь только имя переменной, но не значение её. И мне кажется, что это уже давно было завезено. Геолайзеры получили методы [il]isSunVisible[/il], [il]canSeeSky[/il] и [il]detect[/il]. Неплохо. В [il]computer.beep[/il] можно писать морзянку. [il]computer.beep("---.---")[/il]. [il]redstone.setOutput[/il] научился ставить значения больше 15. Клавиатуру можно цеплять к монитору, если ещё поставить к непередней стороне блока. Наконец-то. [1.12] Вернули поддержку Project Red. Через адаптер можно теперь работать с камерой реактора IC2. У серверных дисководов тоже есть теперь гуишка (пкм в мире или внутри интерфейса стойки). Торговый апгрейд обзавёлся методом [il]getMerchantId[/il]. Полезно, если жителей куча. [1.12] Вернули поддержку энергии AE2. В конце-то концов: дебаг-карте добавили [il]scanContentsAt[/il]. Больше инфы возвращается для предметов из Draconic Evolution. Вейпоинты стало можно ставить вверх или вниз. Это действительно было слишком контринтуитивным. Связанные карты можно скрафчивать вместе (повяжет на новый канал их). Плюс получать адрес канала при скане стэка. Можно теперь менять цветовой код сундуков Ender Storage. Связанные карты также научились будить компьютер по сигналу, как модемы. Белый и чёрный списки измерений для чанклоадера. Метод [il]disk_drive.media[/il], которым можно получить адрес дискеты внутри дисковода. Поддержка Forge Energy для зарядки предметов вроде батареек и планшетов. Анализатор показывать будет по клику на адаптер ещё и содержащийся в нём компонент. Событие [il]redstone_changed[/il] показывает, какой цвет поменялся на бандлед-кабеле. По шифт-клику компоненты закидываются в соответствии с их уровнями. Подрезали немного шум в логе от OC. Методы вроде [il]robot.suck[/il], [il]robot.suchFromSlot[/il] и [il]transpoer.transferItem[/il] теперь возвращают вместо [il]true[/il] число перемещённых предметов. Немного уменьшили назойливость частиц наномашинок. Жёсткий диск 3 уровня в режиме без ФС стал иметь по умолчанию не 6, а 8 пластин. Улучшили рендер кабелей как-то. Такие же "как-то" улучшения произошли с инвентарём роботов, апгрейдом крафта, методами [il]swing[/il] и [il]use[/il], взаимодействием с жидкостными баками. С модами получше работать должны. Чанклодыри можно ставить в микроконтроллер теперь. Расширили покрытие юникода шрифтом. Стандартный биос стал есть меньше памяти. Мониторы глючить должны поменьше. Пофиксили обнуление содержимого инвентарей блоков мода при крашах. Ещё некий краш при установке микроконтроллеров починили. Команду [il]/oc_nm[/il] вправили в место и заставили работать. Дюп роботов убран. Команды перемещения теперь говорят, успешно или безуспешно вызов завершился. Форсирование [il]LuaJ[/il] не форсировало эту архитектуру. [il]transferItem[/il] проверял не ту сторону. Починили Unknown error при попытке залить чего-то в некие машинки. Дюп дронов тоже починили. Выкорчевали возможную ошибку при запуске вместе с IC2. Роботы перестали потреблять ингредиенты при крафте, которые не потребляются. Апгрейд ангельский стал работать. Пофиксили торговый апгрейд. Его прямая задача исполнялась кривовато. Роботы не перемещались, когда нужно было. Дюп предметов дронами и роботами. Дискету network тоже можно ставить через install теперь. Дюп жидкостей, конечно, тоже был и тоже пофикшен. Дроны не реинициализировались после включения по сообщению модема. И вели себя очень странно. Всякие фиксы в интеграции с AE2. Опять некий дюп EEPROM. Удалён. Краши при загрузке с Applied Llamagistics. Краши при нетрадиионной установке компьютеров. Краши (но на клиенте), связанные как-то с кабелями и загрузкой чанков. [il]enableNanomachinePfx[/il] не имела эффекта. Роботы стали вызывать обработчики модов при получении опыта. Вводящие в заблуждение сообщения анализатора о выключенных компьютерах стали вводить в заблуждение в меньшей степени. Микроконтроллеры свою начинку теперь тоже выключают вместе с собою. Всякие ошибки кидал апгрейд поводка вместе с некоторыми модами. Фиксед. [1.10+] Починен рецепт крафта карточки с мировым датчиком. Экран планшетов теперь не зависает. Терминальные серверы ненормально цепляли удалённых терминалов на себя. Ошибки освещения с шейдерами. В OpenOS ещё отметить можно: Команда [il]reset[/il], которая ресетит разрешение. Ошибки сервисов пишутся в /tmp/event.log. Можно теперь ловить ошибки по Ctrl-Alt-C (жёсткие прерывания) путём переопределения функции в [il]process.info().data.signal[/il]. Копипаст в [il]edit[/il]: Ctrl-K — вырезать, Ctrl-U — вставить строку. Процессы закрывают файлы при завершении. Ссылочка на гитхаб, откуда можно скачать мод.

Fingercomp

Fingercomp

Upong

Меня тут попросили что-нибудь написать в блог. Например про мои заброшенные проекты. Честно перелопатил свои репозитории, но не нашел ничего интересного. Ни одного интересного заброшенного проекта. Просто беда какая-то. Даже на секунду померещился нимб над головой (такой наверняка есть у любого программиста, который всегда дописывает все свои проекты до единого). Но потом я пошел посмотрел в зеркало и морок пропал.   Поэтому вот скриншотик из пинг-понга, который я начал было писать, чтобы потренироваться в работе с сетью (хотел приделать туда мультиплеер). Но дальше фотошопа (точнее гимпа) меню у меня дело не ушло, писать одному было скучно, и быстро нашлись дела по-прикольнее.     Сохранился даже репозиторий: https://github.com/MoonlightOwl/Upong

Totoro

Totoro

Mastodon.Social

У нашего VK канала теперь есть зеркало на Mastodon.Social.   Mastodon - это свободный клон твиттера, который поднял довольно большой хайп где-то года два назад. Без модерации, без рекламы, без слежки за пользователями. Контент будет совпадать с VK каналом (зеркало есть зеркало), да и вряд ли там кто-то вообще сидит. Но если вдруг - заходите, подписывайтесь, читайте, комментируйте, репостите -  welcome. 😇 У Мастодона есть мобильные клиенты, можно сидеть с них.   Ссылка на канал: https://mastodon.social/@hashccru

Totoro

Totoro

История одного дронодома

Многие игроки здесь видели или хотя бы слышали про огромный дронодом, который построил @Asior в былые времена на сервере RoboCraft. С тем чтобы прояснить происхождение этой хаты и оставить о ней заметку в этом клубе, специально для «Новостей подполья» @Fingercomp обратился к создателю постройки и попросил рассказать про неё. Редакция представляет обработанную версию истории.   История начинается в начале мая 2016 года, когда запустился сервер RoboCraft, на который сразу же хлынули толпы игроков, хотевшие «поскорее стать топовыми игроками, обладателями гор ресурсов и, конечно же, новых идей и программ». Туда попал и герой нашего рассказа. Развитие было довольно сложным. «Поначалу я хотел, как обычно, отстроить бункер и спокойно, потихоньку наращивать силы», но этому воспрепятствовал случай: система автоматического расселения игроков закинула Asior невесть куда — в середину заражённого биома. Очевидно, что герой этому не обрадовался. Ему потому пришлось бегать в поисках нового места.     Конечно, Asior таки организовал себе временное убежище и начал стремительное развитие в игре. Но в чате игроки часто оставляли ссылочки на скриншоты своих невероятно красивых палат с невероятно крутых ракурсов.     Он перерыл огромное число чертежей домов, замков, статуй — и решил построить дрона. Дрона из OpenComputers. Ведь сервер специально разрабатывался для этого мода. Asior зашёл в сингл и долго, упорно воздвигал новые варианты постройки и безжалостно крушил старые. Наконец, он определился с тем, как именно должно будет выглядеть его будущее жилище. Оставалось лишь воспроизвести это всё на сервере. Но здесь и возникла основная проблема: как добыть такое огромное количество ресурсов для строительства? Разрешена она была путём не самым чистым:     Впрочем, и того, что он раздобыл, сполна хватило на постройку основного корпуса дрона. Это потребовало огромного числа строительных лесов и невероятных акробатических способностей и дополнительно осложнялось тем фактом, что полученные вечные блоки не перемещались из хотбара. Но стиснув зубы и получая подкормку от щедрых игроков Asior таки построил дрона.       Потому пришлось придумать, как расширить жилище. Некоторые предлагали соорудить какое-нибудь здание, к которому был бы «привязан» дрон, но, увы, это не вписывалось в местность.     Далее настала очередь внутренней отделки: ставились перегородки, размещалось оборудование. А монументальное сооружение, памятник роботу и дрону, стал пользовался большой популярностью, чему создатель не противился: «я был не против, чтобы все желающие посмотрели, как я живу, уточнили какие-то вопросы или помогли чем-нибудь».   С тех пор сервер RoboCraft давно закрыт, но память о роботе и дроне жива до сих пор. Редакция присоединяется к пожеланию героя остроить то, что поражало бы воображение и отпечаталось в приятных воспоминаниях десятков игроков.   И мы всё так же мы призываем вас оформить подписку на «Новости подполья». Годноты здесь много было, есть — а то ли ещё будет.

Fingercomp

Fingercomp

Meh, опять эмулятор OC

Еще мой дед говаривал, что каждый кодер на ОС просто обязан начать писать собственный эмуль для самоутверждения. Не желая изменять семейным ценностям, я тоже окунулся с головой в эту клоаку. Вообще в существующих эмуляторах лично меня люто бесит возня с ручной компиляцией, докачиванием всяческих либ по типу openssl, а также отсутствие возможности запуска нескольких виртуальных компиков в едином пространстве с масштабированием экранов, не говоря уже про пересылку данных между ними посредством не менее виртуальных модемов. Поэтому почесав репу, собрав JavaFX + LuaJ, накатав несколько компонентов, на данный момент я заимел следующие зачатки проекта:   Библиотеки computer, component, unicode Компоненты computer, eeprom, filesystem, gpu, modem, screen, keyboard Имитация системных сигналов по типу touch/drag/drop/key_down/key_up/scroll/modem_message с поддержкой pullSignal/pushSignal Пересылка сетевых пакетов между имеющимися машинами в рабочем пространстве через modem.send/broadcast BSOD для "unrecoverable error" Звуковая система а-ля "комп в мире кубача", имитирующая звуки доступа к диску, и прикольно шумящая на фоне для антуража Создание/сохранение/загрузка виртуальных машин с сериализацией данных имеющихся компонентов. Ну, всяких там адресов, разрешений видях, размеров, координат и т.п. Кнопочка включения (!)   Разумеется, компоненты имеют далеко не все методы, их написание - дело долгосрочное. Но поскольку этот раздел называется блогом, то, кажется, никто не мешает мне писать о запланированном. В идеале хочу замутить компоненты internet, tunnel и data, позволить юзерам выбирать пути к прошивке виртуального EEPROM и содержимому жесткого диска. Также остается открытым вопрос о лимитировании памяти: я понятия не имею, как это реализовать на LuaJ и ублюдочной Яве без обожаемого sizeof(). Городить костыли в виде JavaAgent + Instrumentation.getObjectSize не хочется, но, видимо, придется. Ну, и если у кого-то имеются занятные предложения по функционалу софтины - буду рад.   Сырцы: https://github.com/IgorTimofeev/OpenComputersVM   Скриншотик:      

ECS

ECS

Ethel

Мегапроекты, мегаобсуждения, огромная мотивация... Ну, конец истории вы уже поняли. В этом посте посетим могилу Ethel — моей игры, которой было суждено не быть. Начать надо с понятий. Ethel — это платформер. Естественно, 2D и скроллинговый. На скрине выше: Красные — это враги. При контакте с ними персонаж дохнет. Жёлтый прямоугольник — это персонаж. Голубенький квадратик — это точка спаун поинта. Серенький — это каменья. По ним можно ходить. А остальное — небо. Затея сделать игру приняла форму действия 30 мая 2017 года и (моими усилиями) стремительно нарастала фичами. Из реализованных фич: Самые тупейшие враги. Они идут в одну сторону — и в другую при коллизии о стену или своего товарища. Передвижение базовое. Можно прыгать и ходить. Дебаг-экран, отключаемый по F1. Загрузка всех ресурсов из файлов. Карта выше была загружена из файла с данными карты. И спрайты, и тайлы. Физика какая-то. Примитивная, конечно. Как-то коллизии умудряется определять и ускорение рассчитывать. Главное меню. Куда ж без него? 20 FPS на опенкомпе. Вроде бы. Хотя это, скорее, из-за того, что нереализованного дофига. 2D и скроллинг. Для адекватности в скорости использовалась либа doubleBuffering. Все компоненты соединяются посредством либы событий libaevent, которую я тогда достаточно любил, потому что довольно удобная штука она есть. Но тут параллельно мы поднимали свой сервачок MC, для которого, очевидно, нужен был свой сайт. Сисайт. Иначе несолидно. А так как 2 любительских проекта параллельно одновременно я вести не умею, выжить должен был один из них за счёт второго. И так получилось, что вторым стал ethel. Уже через 3 недели после начала энтузиазм куда-то иссяк — и 27 июня был запушен коммит, который оказался последним. С тех пор обновлений не было. Какую мораль я вытащил из этого потонувшего проекта? Я не умею делать нормальные архитектуры. Но это я и так знал. То же для физики. Казалось бы, что там сложного-то: радиус-вектор, вектор скорости и вектор ускорения. Но вот я и в них как-то запутался. Там самым запарным было из этих трёх векторов сообразить нормальный интерфейс программный. Во-первых, действующих на спрайты сил было несколько. Как минимум, там есть гравитация. В теории могли бы быть всякие пружинки. Во-вторых, движение врагов, на самом деле, задаваться должно не ускорением, а простой скоростью. Я там как-то накостылял, и оно даже работало, но удовольствия от этого я не получил. И коллизии. Просто так на них прочекать тоже не столь и сложно, но запары все возникали при использовании результата проверки в методах, задающих поведение спрайтов. Костыли — это плохо. Ну, то есть, всё как обычно. Посмотреть на останки можно здесь. Можно даже попробовать запустить это — но сначала сделайте git checkout HEAD^^ (в мастере там какие-то блохи). А, ещё надо будет откуда-то достать либу буферную. И lua-objects скопировать в /usr/lib/lua-objects/lua_objects.lua. Ethel — это лишь один из множества руин некогда поражавших воображение своей амбициозностью проектов. В этом элитном клубе мы намереваемся продолжить копаться в исторической пыли и вытаскивать на свет из-под неё и другие павшие проекты. Поэтому ненастойчиво убеждаем вас подписаться на сей чудесный блог, тыкнув на соответствующую кнопку — ту, что повыше. А можно нажать и на обе. 🍪

Fingercomp

Fingercomp

Дискорд

Всем ку! Наконец-то форум ожил и соответственно выползли мы из подполья 😃 Приглашаю всех желающих и участников форума в наш канал в Discord! Инвайт - ссылка в наш канал в Discord : https://discord.gg/tpjbgjG Заходите, общайтесь. Там (иногда) бывает мой бот, который мост между каналом в IRC и Discord, так что иногда появляется возможность переписываться с ирковчанами 😃

MeXaN1cK

MeXaN1cK

Что делать, если вы провалились под пол

Первым делом, сохраняйте панику. Так интереснее. У нас есть группа в ВК, которая, в отличие от параллельных — тупиковых веток эволюции — жива и даёт продукт в виде постов. Очень интересных. Не любите ВК? Я тоже. Имеем мы канал в IRC: зайти можно даже с телнета. Но лучше с помощью какого-то клиента: HexChat, WeeChat, Quassel. Контактные данные для них: Сервер: irc.esper.net Порт: 6697 TLSv1.2 Канал: #cc.ru Впрочем, присутствует и веб-клиент для обитателей двумерного денежно-временного мира. Надо сказать, у нас даже дискорд-клуб где-то был. Однако не только флуждением занимается Хэш cc.ru. Мы завели организации вот тут: На GitHub. На GitLab. В Trello. Под кроватью. А ещё подпольные мудрости тщательно и бережно схороняются на свалку нашего цитатника, так что башорг вам больше не нужен. Не забудьте, по пути куда-нибудь находясь, записаться в читателей этого элитного клуба. Потому что здесь мы будем писать. Что-то. Отлично. Наши цепкие объятия уже ждут-поджидают вас.

Fingercomp

Fingercomp

 

Цитадель №0

Читал я в очередной раз форум, и нашёл тему "Цитадель". Я давно хотел посмотреть, что да как в ОС, поэтому я создал новый мир на своей сборке (в конце кину), подстроил правила под себя, построил бункер... И ушёл писать копалку.



По правилам: Даны компоненты, а не целые компы/дроны/роботы; Внутри бункера можно делать что угодно (даже расширять, но только вниз); Под компом - креативная батарейка из thermal expansion; Энергию от креативной батарейки нельзя никуда подводить! Рядом с единственным зарядником - waypoint для нахождения пути к базе. Цель - сделать систем автоматического создания роботов для добычи большинства ресурсов.

Я не знаю, на сколько меня хватит, но я надеюсь на хотя-бы 7 записей.
Следующая запись будет, когда я допишу копалку, а пока всё!

mrlobaker

mrlobaker

×