Поиск по сайту

Мой вопрос может показаться глупым, но всё же. Почему все используют OpenComputers, а не CC: Tweaked? Мои аргументы: В пользу ComputerCraft: Он более... "Ванильный"? Он НАМНОГО Проще Он активно обновляется(Если мы говорим о Tweaked версии) У него нету сильных недостатков перед OC Конечно, у CC есть и свои минусы, и я буду рад, если вы поделитесь своим мнением(если конечно вы аргументируете свою точку зрения). Также, заради справедливости скажу, что у OC тоже есть плюсы, и главный - Это большие экраны, память(неизвестно сколько в CC Tweaked), разные дискетки блоки и т.п. (Не бросайтесь говном пожалуйста, просто я действительно не вижу весомых причин, чтобы сидеть только на OC)

Интересные изменения: Добавили поддержку Lua 5.4.4. Он не сильно отличается от Lua 5.3, но у него есть атрибуты локальных переменных (<const>, <close>). Последний выглядит очень полезным. Архитектура пока экспериментальна, нужно явно включать в конфиге мода. С остальными либами Lua тоже капитальная переделка. Наконец-то пофиксили инты в методах компонентов (если вам вызов когда-либо говорил invalid key to 'next', это оно). Сами либы обновили до последних версий (например, 5.3.6) и пересобрали с оптимизациями. В том числе под 64-битные армы (линукс, мак). Чтобы не путаться, на текстуре блока redstone i/o точками, как у игральной кости, показывается, какая это сторона: . Теперь рисуются юникод-символы выше U+FFFF. Там, например, всякие емоджи запиханы. Лишь бы в шрифте глифы под них имелись. Патчить шрифт можно ресурс-паками. Причём необязательно собирать глифы для всех символов: если в ресурс-паке глиф не указан, то он берётся из шрифта мода. Интернет-карту переписали на другую HTTP-библиотеку, чтобы она умела слать PATCH-запросы. Ссылка: 1.7.10 / 1.12.2.

Решил значит я сделать мод для OpenOS, да не обычный, а такой что бы пользователь мог его сам собрать. Что то вроде Arch Linux: можешь поставить только базу командой pacstrap -K /mnt base linux linux-firmware А можешь сразу и DE накатить да и пару приколов заодно: pacstrap -K /mnt base linux linux-firmware neofetch nano gcc make xfce4 ... Итак, к чему я. Какие пункты OpenOS вы бы хотели модифицировать? И каким образом? Текущий список идей: Замена цветовой темы (openos-mod colorscheme [FG] [BG]) [ГОТОВО] Свой менеджер пакетов поддерживающий oppm и hpm (pacman) Замена загрузчика /init.lua (Полный вывод действий, вывод только стадий, анимация загрузки, ... - openos-mod bootloader [путь/к/пакету/загрузчика.bld]) Ссылка на репозиторий: https://github.com/Def-Try/OpenArch/tree/main Буду очень рад вашему вкладу в проект

Итак, я решил написать свою оболочку для OpenOS, но мне показалось неудобным прямая рисовка и обработка ивентов. Поэтому я написал что-то на подобии XServer-а из Linux(ну, вообще, там от линуксоидной версии только название и идея) Он предоставляет возможность создать две функции, которые будут управлять всем - loop, draw и handle Функции: loop(string; eventName) -> bool: skiprender вызывается *перед* отрисовкой. должен вернуть одно bool значение - true отменит отрисовку и сразу перескочит к обработке ивента, draw() -> nil вызывается для отрисовки экрана. handle(eventName, eventArguments...) -. string: action вызыватся после отрисовки, для обработки ивента. должен вернуть одну строку - действие. которое должен выполнить "икс-сервер"(см. Действия X сервера). Действия X сервера: exit - завершить X сервер и вернуться в консоль draw - повторить отрисовку экрана next - сразу же получить следующий ивент Использованные материалы: MineOS Screen API MineOS Color Library MineOS Image Library MineOS OCIF Image Format Гитхаб: https://github.com/Def-Try/X2-Server

Автором идеи является 1Ridav. Как-то давным давно, в Мамбле, он предложил создать на основе геосканера карту сервера для спавна. Чтобы игроки могли побродить по уменьшенной копии сервера, и поглазеть на ландшафт/постройки. Суть такова: Берется большой зал (спавн или отдельная постройка, не суть), с темным полом (чтобы голограмму было хорошо видно). Под полом располагается сетка проекторов, компьютер и геосканер. Программа сканирует сервер (загруженные чанки) и формирует на основе этих данных карту высот. Карта режется на прямоугольные фрагменты и выводится на проекторы. На скриншоте сверху, я сделал тестовый рендер для одного проектора. За основу взят мой мир-полигон для программ. Предлагаю довести программу до ума, и как вариант сделать где-нибудь такую карту на IT 1.7.10. Возле спавна, чтобы те, кто заходит на сервер, могли побродить и посмотреть. Что надо обдумать: 1) Как красить? Проекторы имеют три цвета. Я думаю один будет - синий. Им надо покрасить все плоскости на высоте y=64 - уровень моря. Оставшиеся два цвета надо как-то распределить по террайну, чтобы вид карты не вызывал эпилептических припадков. =) 2) Делать ли пустоты по высоте? На скриншоте сверху я сделал простую карту высот. Т.е. она состоит как бы из столбиков разной высоты. Можно сделать ее более сложной, отобразив пустоты. 3) Сжимать ли масштаб? Сервер имеет размеры примерно 4000 на 4000. Проектор - 48 на 48. Т.е. чтобы отобразить всю карту в полный размер понадобится около 7056 проекторов и зал аналогичной площади. Надо либо отобразить на карте фрагмент мира, разумного размера, либо уменьшить масштаб карты, усреднив карту высот.

Мониторы в OpenComputers поддерживают только текстовый режим, но интерфейс можно сделать круче с помощью символов из Юникода. До недавних пор символы приходилось выбирать из таблицы (https://computercraft.ru/topic/1962-shrift-v-oc/) и вручную проверять на то, подойдут ли они в интерфейс или иконку. Но сейчас я представляю вам IconPaint - программу, позволяющую интерактивно менять символы внутри иконки и сразу видеть результат! Как скачать: wget -fq https://raw.githubusercontent.com/ProgramCrafter/lua-utils/main/paint/paint.lua Управление такое: стрелки на клавиатуре выбирают редактируемый символ (справа подсвечивается синим), backspace, цифры и буквы a-f служат для редактирования шестнадцатеричного кода символа, клик левой кнопкой мыши по палитре задаст редактируемому символу такой же цвет текста, клик правой - цвет фона, выход по Ctrl-C; проделанная работа сохраняется в файл paint.dat. Пример paint.dat (осторожно, это валидный код на Lua, и при загрузке IconPaint запускает его, хоть и в ограниченном окружении): data = { {0x0020, 0x2580, 0x2580, 0x2580, 0x2580, 0x2580, 0x2580, 0x0020}, {0x0020, 0x0020, 0xE18B, 0xE146, 0xE147, 0xE18C, 0x0020, 0x0020}, {0x0020, 0x0020, 0xE18E, 0xE149, 0xE148, 0xE18D, 0x0020, 0x0020}, {0x0020, 0x2584, 0x2584, 0x2584, 0x2584, 0x2584, 0x2584, 0x0020} } overlay = {["2 3"]={16777215,2960685,2,3},["3 3"]={6684927,0,3,3},["4 3"]={16777215,6684927,4,3},["5 3"]={16777215,6684927,5,3},["7 2"]={16777215,2960685,7,2},["7 3"]={0,2960685,7,3},["3 4"]={0,2960685,3,4},["2 4"]={0,2960685,2,4},["5 4"]={0,2960685,5,4},["4 4"]={0,2960685,4,4},["7 4"]={0,2960685,7,4},["6 4"]={0,2960685,6,4},["6 1"]={0,2960685,6,1},["5 1"]={0,2960685,5,1},["4 1"]={0,2960685,4,1},["3 1"]={0,2960685,3,1},["2 1"]={0,2960685,2,1},["5 2"]={16777215,6684927,5,2},["6 2"]={6684927,0,6,2},["3 2"]={6684927,0,3,2},["4 2"]={16777215,6684927,4,2},["2 2"]={16777215,2960685,2,2},["6 3"]={6684927,0,6,3},["7 1"]={0,2960685,7,1}} Что в планах: расширить зону для редактирования иконки (сейчас 8x4 символа), добавить вставку символов из буфера обмена. Скриншот под спойлером:

Раз уж все знают чем я занимаюсь то выкладываю свой вирус. Правда это не тот вирус который был на дискетах. этот менее читабельный c: как это работает: --заражение-- 0. есть дискета с какой то прогой и вирусом в файле .autorun. 1. когда игрок запускает прогу с дискеты, она включается авторан и перезапускает компьютер. 2. после перезапуска компьютера запускается .autorun. с вирусом. 3. вирус переписывает код биоса. 4. после ещё одного перезапуска биос заражает init.lua 5. init.lua заражает почти все файлы на диске. 6. вирус из файлов заражает биос если поставили новый eeprom. --последствия-- 1. удаление все пользователей из привата компьютера каждые 5 секунд. 2. плавающий текст c: код вируса: тыц внимание! не пытайтесь понять код. в психушке нет мест. ps1 лучше чем у ecs c: ps2 вирусу уже больше 3 месяцев c: ps3 на старом IT все стадали от этого вируса c:

В моде OpenComputers есть интересное устройство, которое позволяет определить плотность блока на расстоянии. Но вот беда, данные он выдает довольно шумные и чем больше расстояние, тем больше шума. Чтобы определить подлинную плотность блока, можно просканировать его несколько раз, а результат усреднить. Шум, мешающий сканированию, имеет вероятностную природу. И после нескольких сканирований можно статистически найти, какая вероятней всего плотность у блока. За один тик мы можем просканировать 64 блока. Чтобы проанализировать всю доступную область (65 x 65 x 64) сотней итераций, нам понадобится 422500 тиков, что равно 21125 секунд или 352 минуты, то есть без малого 6 часов. Но сколько раз надо сканировать? Сто? Тысячу? Нам открыто тайное знание и есть точный ответ. Один. Всего за одно сканирование мы можем найти руду среди любых других блоков. Если хочется абсолютной уверенности, придется сделать пару магических пассов и просканировать повторно. Начнем с теории. Для начала откроем код мода и найдем функцию geolyzer.scan, она располагается [здесь] src/main/scala/li/cil/oc/integration/vanilla/EventHandlerVanilla.scala и называется onGeolyzerScan() Просмотрев код, мы можем понять, что функция принимает параметры, по этим параметрам сканирует блоки в мире. Делает разные проверки вроде world.blockExists(x, y, z) && !world.isAirBlock(x, y, z), чтобы убедится, что блок есть. Потом получает информацию о блоке по координатам, делает еще несколько проверок (опять проверить, что блок все-таки есть block != null, проверяет дополнительные параметры: includeReplaceable, isFluid(block), block.isReplaceable(world, blockPos.x, blockPos.y, blockPos.z)) Потом происходит измерение расстояния до блока. И в конце берется плотность, смешивается с шумом и расстоянием. Результат добавляется к таблице блоков и отправляется игроку. Вроде-бы ничего необычного. Шум, расстояние, плотность. Нам и так известна зависимость силы шума от расстояния. И вот тут начинается волшебство. Рассмотрим поподробнее код вычисления итоговой плотности блока. e.data(index) = e.data(index) * distance * Settings.get.geolyzerNoise + block.getBlockHardness(world, x, y, z) Коротко можно это записать в виде формулы: R = G * D * N + H G - это сгенерированный шум. D - расстояние до блока. N - множитель шума из конфига (стандартно - 2). H - настоящая плотность. R - результат работы геосканера. Если мы попробуем в качестве эксперимента отнять от результата предполагаемую плотность, то ничего нового не узнаем. Если обратим все операции с известными значениями, то получим только шум. А можем ли мы так же разобрать формулу шума? Давайте попробуем. Несколькими строками выше [ссылка]. Можно наблюдать получение массива случайных байт. val noise = new Array[Byte](e.data.length) world.rand.nextBytes(noise) Далее следует нормализация значений. noise.map(_ / 128f / 33f).copyToArray(e.data) Хм. Так-так-так. Если мы это все обьеденим с предыдущей формулой, то получится что-то вроде такого: R = G(RANDOM_BYTE / 128 / 33) * D * N + H И что это нам дает? А то, что исходное псевдослучайное число имеет жесткую дискретность. ГПСЧ дает случайные числа типа byte, а это только 256 значений (-128, +127). Нам известны все значения, кроме H и RANDOM_BYTE, что нам это дает? Мы можем предположить значение H и обратить всю формулу. (R - H) / D / N * 128 * 33 Для стандартного конфига можно сократить до: 2112 * (R - H) / D А теперь тайное знание для тех, кто не понял самостоятельно. Мы взяли желаемую плотность блока (например 3 для руды). Подставили вместо H. Получили случайное значение. Можем легко определить, угадали ли плотность или нет. Из-за дискретности случайных значений генератора, распределение вероятностей для блоков с разной плотностью не одинаковое. Перейдем к практике. Вот код простого скрипта, который в заданном радиусе ищет блоки с нужной плотностью. Результат выводится на голопроектор. local sqrt = math.sqrt local component = require('component') local geolyzer = component.geolyzer local hologram = component.hologram local function distance(x, y, z) return sqrt(x^2 + y^2 + z^2) end local function magic(R, H, D) return 2112 * (R - H) / D % 1 end local function visualize(hardness, elevation, size) hologram.clear() hologram.setScale(9) local blocks, result for x = -size, size do for z = -size, size do blocks = geolyzer.scan(x, z, elevation, 1, 1, 32) for i_y = 1, 32 do result = magic(blocks[i_y], hardness, distance(x, i_y+elevation-1, z)) if blocks[i_y] ~= 0 and (result > 0.9998 or result < 0.00005) then hologram.set(x+24, i_y, z+24, true) end end end end end local hrd, ele, siz = table.unpack({...}) hrd = hrd or 3 ele = ele or -32 siz = siz or 16 visualize(hrd, ele, siz) А вот результат: При сканировании заметны артефакты. Когда разные плотности близки на целочисленных расстояниях, позникают коллизии. Это можно частично компенсировать, если есть блок кандидат на ошибку. На любом расстоянии можно рассчитать абсолютный минимальный и максимальный уровень шума. С расстоянием, у близких плотностей пересечение значений увеличивается, но если плотность блока не в области пересечений, то можно точно определить к какой области он относится. Пересечение плотностей руды (3) и камня (1.5), точками обозначены три сканирования блока руды. Результаты обратного вычисления для разных плотностей хорошо это демонстрируют. Для компенсации артефактов надо ввести дополнительное условие: полученный RANDOM_BYTE должен быть в диапазоне -128:127. Вот финальный скрипт и результат. local sqrt = math.sqrt local component = require('component') local geolyzer = component.geolyzer local hologram = component.hologram local function distance(x, y, z) return sqrt(x^2 + y^2 + z^2) end local function magic(R, H, D) return 2112 * (R - H) / D end local function visualize(hardness, elevation, size) hologram.clear() hologram.setScale(9) local blocks, result for x = -size, size do for z = -size, size do blocks = geolyzer.scan(x, z, elevation, 1, 1, 32) for i_y = 1, 32 do result = magic(blocks[i_y], hardness, distance(x, i_y+elevation-1, z)) if blocks[i_y] ~= 0 and result > -128 and result < 127 and (result%1 > 0.9998 or result%1 < 0.0002) then hologram.set(x+24, i_y, z+24, true) end end end end end local hrd, ele, siz = table.unpack({...}) hrd = hrd or 3 ele = ele or -32 siz = siz or 16 visualize(hrd, ele, siz) Для более точного определения плотности можно сделать два сканирования. Одно сместить относительно другого так, чтобы расстояния с артефактами не совпадали. Чтобы не выполнять тяжелую операцию sqrt, можно создать словарь, где [x^2 + y^2 + z^2] = sqrt(x^2 + y^2 + z^2), всего понадобится 1742 уникальных значений. P.S. Пост является компиляцией знаний из [этой] темы. Собрал, чтобы перевести и опубликовать на официальном форуме. Автор идеи хакнуть геосканер - @eu_tomat

Сидел читал форум, наткнулся на тему "Управление роботом с планшета" и сразу понял что моего ума хватит на создание программы которая позволит управлять роботом с НАСТОЯЩЕГО ТЕЛЕФОНА на системе android. И так, представляю вам - RRCM - Robot Remote Controll Mobile Что вам понадибится? 1. Телефон на android 2. Робот с минимальными компонентами и open os 3. Интернет карта на роботе Установка: 1. На робота ставим программу RRCM (pastebin get y2Twekz8 RRCM) 2. Ставим серверный скрипт на сервер/свой пк(если порт 5000 открыт): -- 1. Ставим python -- 2. После установки python3 вводим в терминал/cmd команды: "pip install flask" "pip install flask-restful", также если в четвёртом шаге у вас возникнет ошибка, пробуйте "pip3 вместо "pip" -- 3. Скачиваем скрипт - *тык* -- 4. Запускайте скрипт(windows: двойной клик по скрипту, linux: "python3 название_скрипта" 3. Ставим приложение на android - *тык* 4. Запускаем приложение, вводим только домен/ip:port нажимаем connect - если появляются кнопки управления - работает, если приложение виснет - какая-та проблема(скорее всего приложение не видит сервер 5. В скрипте RRCM на роботе изменяем локальный ip:port на ваш домен/ip:port 6. Запускаем RRCM на роботе. 7. Всё должно работать. Если у многих будут проблемы, запишу видео. В будущем планирую сделать скрипт на EFI что-бы не тратится на диск. Не удивляйтесь малому функционалу, проект был заброшен 2 раза, скоро сделаю обнову. (возможно) UPD: Забыл сказать! Для остановки скрипта надо перезагружать робота, но в скором времени сделаю кнопку в приложении для остановки скрипта Если будут ошибки - пишите, разберусь. UPD2: Если вы боитесь за безопасность устройства то вот вам исходник приложения - *тык* Приложение билдить на андроид в unity

В общем есть чат бокс из Computronics И надо сделать добавление юзера в вайт-лист командой из чата допустим $$adduser НИК Как считать ник? Допустим отправляем в чат $$adduser Koteyk0o и получаем сообщение "$$adduser Koteyk0o" Как из этого сообщения считать ник?

Привет мир! При использовании компонента 'chat_box' из аддона 'computronics', меняю имя чат бокса в чате методом setName("Name") Хочется сделать полноценную имитацию локального чата, чтобы форматирование выглядело красиво. Вот код с форматированием которое я сделал. При выводе сообщения чат боксом в начале и в конце установленного имени появляется квадратная скобка " [ ] " Возможно ли это как-то исправить без изминения файлов клиента и сервера?

Всем привет. Смотря видосик на ютубе, наткнулся на фрагмент, где хранилище из драконика имеет монитор и красивый интерфейс на нем. На самом деле программа достаточно бесполезная, но я повторил... Что она умеет: Планируется: 1.Оптимизировать код(кхм...) 2.Дописать программу для взаимодейтсвия с реактором дракона а именно: 2.1. Авто-повышение мощности 2.2.Поддержание работы реактора в саммом эффективном состоянии 2.3.Выключение реактора при заполненном хранилище 2.4.Включение реактора при опустошении ядра более чем на 50% На этом пока все.. Может кому и пригодится... Установка: 1.Для работы программы нужна библиотека "graffiti": Ссылка на тему с библиотекой pastebin get 1WmfjNfU lib/graffiti.lua 2.Установить программу: pastebin get nV9e234N dsm.lua 3.Подключить Энергетический пилон к адаптеру, а его к компьютеру: 4.Запустить программу dsm.lua 5.Пользоваться...

Оказывается, Сангар на днях работал над новой версией ОС https://github.com/fnuecke/oc2 O_o

Всем привет! Я написал программу для дистанционного управления дроном (например, с планшета). Плюсы программы: Плюсы При запуске дрона требуется ввести случайный код (т.е. дрона никто не угонит). Можно изменять цвет подсветки дрона, надпись на его экране, скорость дрона. Доступен ввод своих комманд (например, для работы с лассо) Относительно нормальное управление дроном Скрины и мини инструкция для работы с программой Установка прог: Для пульта: pastebin get JTY87AiR control Для дрона: На компьютер скачиваем прошивку для дрона: pastebin get up53MtPM drone Вставляем в системник чистый EEPROM Вводим flash drone eeprom Пихаем в дрона полученную прошивку (eeprom) Включаем дрона!

Всем привет! Увидел я у одного человека очки, которые показывали кол-во EU/t в молекулярке и другие данные, решил повторить. НЕ много перестарался, добавил бесполезные функции(они отключаются, путём отключения компонента :D) В итоге что может эта программа: Настройка программы: Возможность отключать не нужные функции, по типу отображения игроков около МЭ, для этого достаточно отключить компонент, которые за это отвечает: Кол-во предметов в МЭ = МЭ контроллер, Чат-бокс, Список игроков - Радар, Кол-во ЕУ/т - Cчётчик Так-же подключить компонент можно и во время работы программы, компонент подключится автоматически и информация будет обновленна. Сама программа: https://pastebin.com/uey3RdbF pastebin get uey3RdbF glasses.lua За код строго не судите, написал минут за 20-ть, да и первая адекватная программа.

Новая версия OpenComputers. Неожиданно. Из наиболее интересного: Видеобуферы у графической карточки. Помимо основного, нулевого буфера, который отображается на экране, теперь можно аллоцировать дополнительные буферы — 2D-массивы символов с заданным разрешением, с которыми можно проводить те же операции, что и раньше: set, fill, copy и т. д., — но без потребления бюджета вызовов (то бишь халявно). Добавлена операция bitblt (bit blit), которая копирует кусок одного буфера на другой. Копирование на основной буфер потребляет бюджет вызовов пропорционально разрешению исходного буфера (не размеру области копирования). Может занять несколько тиков. Если верить @ECS, последнее преимущества в производительности практически убивает. Впрочем, за несколько лет, пока буферы висели в дев-билдах, люди уже их заиспользовали для игрушек: вот платформер, например. Прямые вызовы методов компонентов (любых, не только GPU), не имеющих явных лимитов или использования бюджета вызовов, теперь абсолютно бесплатны с этой точки зрения. Раньше они потребляли одну тысячную единицы бюджета вызовов. Подробнее о них — в моей статье. Обновлён шрифт: покрытие значительно расширилось путём забития недостающих символов глифами из Unifont. Заблокирован диапазон 0.0.0.0/8 для интернет-карты. Запросы туда делают примерно то же, что запросы на localhost. Примечательно, что эту уязвимость использовали на CTF для обхода файрволла. Советую почитать. Метод media добавили и для дисководов в серверной стойке. Досадное упущение. Пофиксили отключение компов при перезагрузке чанка: в определённых случаях стейт компьютеров вовсе не сохранялся, из-за чего они рестартились при выгрузке и подгрузке чанка. Починили debug.sendToDebugCard (весьма полезная функция). Разобрались в ориентации редстоун-карт. В 1.7.3 карточки в компах и серверах почему-то использовали абсолютные направления (север/юг/запад/восток) вместо относительных. Беспроводные модемы первого уровня снова могут получать сообщения. А раньше не могли. Это была бага. Ретрансляторы потеряли возможность ретранслировать на неограниченно большие расстояния. В коде мода запутались в min и max. В результатах поиска вейпоинтов навигационным апгрейдом теперь пишутся их адреса. Остальные изменения и ссылка на скачивание — на GitHub.

Здрассьте, господа, у нас тут превесёлая вещь случилась: спустя полгода разработки (причём круглым числом; 28 мая стартанули) у нас отрелизился репозиторий! Обозвали мы его Hel. В репозитории мы собрали и воплотили в жизнь все хорошие идеи и концепции, которые обсуждались здесь, чтобы получился максимально кавайный способ дистрибуции пакетов. Пользоваться репозиторием не сложнее, чем ставить программы с Pastebin. Для этого нужно знать только название пакета. Одна команда: $ hpm install <нужный пакет> И вуаля! Он уже установлен в нужную папку, все нужные библиотеки загружены и распиханы по системе. Можно запускать и работать. Но по сравнению с OPPM или Pastebin, hel несравненно удобнее. Он легковесный. Простой. Не требует регистрации. И СМС. Чем мы гордимся, безусловно. Установка программ производится с помощью одного легкого клиента (как у Pastebin), но в то же самое время, вам не нужно волноваться о библиотеках или версиях программы. Вы всегда можете найти и установить самую свежую версию (и даже не самую свежую), зная только название пакета (как в OPPM). Кстати, раз уж мы заговорили про OPPM. У нас клиент получился настолько охренительным, что вы можете теперь выкинуть oppm в помойку, наконец-то! В стандартный комплект поставки включён oppm-модуль с кэшированием (иными словами, вам не нужно будет ждать пару минут, пока пробрутфорсятся репозитории, сразу всё качается). Всё быстро, чётко, ясно. Юзается оно так: $ hpm oppm:install <имя пакета> Об остальных фичах читайте уже в мануале hpm, там всё есть.

OpenFTP Иногда нужно скачать большое количество файлов с FTP сервера. Это затруднительно, когда дело доходит до OpenComputers, потому что FTP клиента попросту нет. Приходится изощряться, заливать файлы на HTTP сервер, pastebin или вовсе вставлять их из буфера обмена. И все было бы хорошо, если бы были эти способы удобными. Потому написал я FTP клиент для OpenComputers. Название ему — OpenFTP. Он поддерживает большинство функций, как и старшие братья OpenFTP, такие как FileZilla и bsd FTP. Интерфейс схож с таковым из bsd FTP. Приятная командная строка, команды похожи на *NIX команды, например rm, ls, rename, mkdir. Скорость для OpenComputers бомбезная. Почти 50 кб в секунду на чтение, и в 10 раз больше на запись. Учитывая вместимость дисков, это очень хорошие показатели. Скачать: pastebin get UPcwLA9ep /bin/ftp.lua Для подключения к серверу набираем ftp <хост сервера> [порт сервера (по умолчанию 21)]. После этого OpenFTP попросит имя пользователя и пароль. Увидели ftp> — соединение успешно налажено. Теперь мы можем писать команды для общения с сервером. Команды cd <путь> — перейти в директорию по указанному пути. Работает аналогично таковой в OpenOS оболочке. .. — перейти в директорию-родитель. Результат будет таким же, как в cd ... Например, если мы были в директории /home/peter/programs, после применения команды мы окажемся в директории /home/peter. pwd — указывает директорию в которой мы находимся. ls [-s] [путь] — указывает список файлов в указанной директории (по умолчанию — текущая директория). Флаг -s применяется в том случае, если мы хотим неполный вывод, без полезной информации вроде даты изменения и автора. rm [-d] <путь> — удаляет файл или папку. Если мы хотим удалить папку, добавляем ключик -d. mkdir <путь> — создать новую директорию по указанному пути. rename <было> <стало> — переименовать файл или директорию. После выполнения команды, если все пройдет успешно, было сменится на стало. Алиас: rn. ascii — переходит в ASCII режим передачи файлов. Использовать не рекомендуется, т.к. возможны последующие искажения файлов. binary — переходит в бинарный режим передачи файлов. Рекомендуется использовать именно его, таким образом абсолютно все символы передадутся без потерь. По умолчанию, к слову, используется именно он. Ох, и самое главное: get <путь до файла на сервере> [путь до файла на клиенте] — скачивает указанный файл с сервера. put <путь до файла на клиенте> [путь до файла на сервере] — загружает указанный файл на сервер. nop — команда которая ничего не сделает. (не шучу, в FTP протоколе правда есть команда такая, правда называется она NOOP = No Operation) У каждой команды есть также флаг --help, который показывает помощь (на английском) Хочу также сказать спасибо @Fingercomp за предоставленный прогресс-бар. Без него жизнь малиной не казалась бы =). Также спасибо ему за доступ на свой FTP сервер, где я мог спокойно тестировать программу. Enjoy! PS:

В последних версиях OpenComputers обрастает всякими загадочными вещами. Игроки, которые только только освоились с предыдущей версией вдруг понимают, что надо изучать все заново. "А пошло оно все!" - думают игроки, и уходят на версию 1.3.6, или переучиваются на ComputerCraft, который проще, и не требует непонятного. А одна из самых загадочных - неведомый EEPROM. Это такая мелкая хрень, без которой не работает ни один компьютер, или даже робот. Хорошо еще, что есть стандартный EEPROM который называется Lua BIOS. Он легко крафтится и заставляет работать компьютеры как и раньше. Но найдем задачку посложнее, где Lua BIOS не поможет. Попробуем собрать микроконтроллер, который будет управлять входными дверями. 1. План Представим, как оно должно работать. Слева от двери (если входить) - микроконтроллер. Ради понтов, возьмем Микроконтроллер 2-ого уровня и поставим в него беспроводную сетевую плату. Кроме того добавим красную плату, чтобы управлять дверью. 1. Если контроллер принимает сигнал "open" - он открывает дверь. 2. Если примет сигнал "close" - он закрывает дверь. 3. Если примет посторонний сигнал - взрывает динамит. Дабы сокровища не достались хакерам. Для управления задействуем любой комп, у которого тоже будет беспроводная плата (или точка доступа). 2. Крафтим контроллер С этим проблем не возникнет. Потому, что я играю в креативе :P . Открываем NEI и берем нужные детали. В последний слот положим пока пустой EEPROM. Потом поставим на него прошивку, а пока - не важно. Нажимаем кнопку "Старт" и достаем готовый блок. 3. Готовим прошивку Теперь, когда все готово, мы построили сокровищницу и скрафтили контроллер - осталось самое главное. Программирование EEPROM'а отличается от программирования обычной программы. Потому, что обычно, наши программы выполняются в OpenOS, которая заботливо загружает нужные библиотеки, предоставляет всякие удобные фичи и прочее. Тем не менее писать мы будем именно в OpenOS. Запустим компьютер, напишем edit bios и введем следующие строки: red = component.proxy(component.list("redstone")()) while true do red.setOutput(5, 0) computer.pullSignal(1) red.setOutput(5, 15) computer.pullSignal(1) end Дело в том, что большая часть библиотек, которые мы использовали - это библиотеки OpenOS. А значит мы не можем ими пользоваться в BIOS. Однако кое-что нам доступно. Это библиотеки computer и component, и соответственно все установленные в целевом агрегате (микроконтроллер) компоненты. Более чем достаточно для наших задач. Вышеприведенный код делает следующее: * ищет компонент с названием "redstone" и возвращает его прокси * в вечном цикле посылает нулевой редстоун-импульс направо (side = 5), т.е. гасит сигнал * ждет секунду (на самом деле - ожидает эвентов, то есть сигналов) * посылает редстоун сигнал с силой 15 направо * опять ждет секунду Преследуем двоякую цель: во-первых проверить, что EEPROM вообще работает так про него написано на Вики. Кто его знает? А во-вторых: убедиться, что сторона 5 это именно та сторона, где дверь. А не какая-нибудь другая. Нажмем Ctrl+S, чтобы сохраниться и Ctrl+W, чтобы закрыть редактор. Вставим пустой EEPROM (еще один) в слот нашего компьютера, вместо лежащего там Lua BIOS. И напишем в консоль такую команду: flash -q bios MCBios Программа flash предназначена для прошивки чипов. Флаг -q говорит ей, чтобы не задавала лишних вопросов, затем идет имя файла с нашим кодом (bios) и метка, которую программа шлепнет на чип (MCBios). Все. Доставайте. Lua BIOS на место класть не обязательно, ибо этот слот нам еще потребуется. (Но не забудьте его вернуть, если будете перезагружать компьютер) Чтобы заменить пустой EEPROM в контроллере на наш MCBios, надо положить контроллер и MCBios на верстак. При этом пустой чип вылетит, а новый встанет на его место. Поставим контроллер на пол и протестируем. После клика ПКМ на контроллере - замигала правая лампа. Значит все работает как нужно. 4. Теперь - серьезно Извлеките чип с MCBios обратно (так же как и вставляли, только наоборот). Или приготовьте новый пустой чип. Главное - не запутайтесь в них. Пишем клиент для контроллера. У меня он выглядит примерно так: red = component.proxy(component.list("redstone")()) modem = component.proxy(component.list('modem')()) modem.open(27) red.setOutput(5, 0) red.setOutput(2, 0) -- no explosions yet =) while true do name, _, sender, _, _, message = computer.pullSignal(2) if name == 'modem_message' then if message == 'open' then red.setOutput(5, 15) elseif message == 'close' then red.setOutput(5, 0) else -- hacker tries to get in? red.setOutput(2, 15) -- fire in the hole!!! end end end modem.close() Все согласно плану. Прошиваем чип, вставляем в контроллер, а контроллер ставим слева от дверей. Сзади к контроллеру осторожно прилаживаем запал. ПКМ! Теперь открываем новый файл на компьютере: edit send И пишем в него такой код: local com = require('component') local modem = com.modem local args = {...} modem.broadcast(27, args[1]) print("Message '"..args[1].."' sent!") Сохраняем, и закрываем. Это будет программка для тестирования контроллера. 5. Тест! Пишем в консоль send open. Дверь открылась! Пишем send close. Дверь закрылась! Пишем send opeh Упс! Опечатка. О_О

Среди всех компонентов в OC у интернет-платы самый ужасный API. Неудивительно, что правильно использовать его умеют немногие. Даже за Vexatos мне приходилось чинить tape.lua — программку для записи кассет. Плюс в ирке нередко спрашивают, как отправить HTTP-запрос на сервер. Значит, пришло время написать, как же всё-таки использовать интернет-плату. Гайд строится на следующих предположениях (сорри за педантизм): Вы умеете прогать на Lua, в том числе знаете о двух основных способах возвращать ошибку. Вы писали уже программы для OpenComputers, которые использовали API этого мода или OpenOS, особенно либу event. Вы как-то использовали (или пытались использовать) интернет-карточку в программах. Секции 1, 3: вы понимаете основные принципы HTTP. Секции 2, 4: вы понимаете, как пользоваться TCP-сокетами и зачем (не обязательно в Lua). Секция 4: вас не смущает setmetatable и вы понимаете, как делать ООП на прототипах. Секции 2, 4: у вас OC 1.6.0 или выше. Секции 1, 3, 5: у вас OC 1.7.5 или выше. Текущая версия мода — 1.7.5, а в новой ничего не изменилось. У инет-карты есть две разных фичи — HTTP-запросы и TCP-сокеты. Кратко пробежимся по API и затем разберём детальнее применение. Рассматривать я буду API компонента: часто используют require("internet") — это не компонент, а обёртка. 1. Отправка HTTP-запросов: component.internet.request У этого метода 4 параметра: URL, на который надо послать запрос. На всякий случай, URL начинается со схемы (http: или https:), после которого идёт адрес хоста (например: //localhost, //127.0.0.1, //[::1], //google.com:443), за которым следует путь (/my-file.html). Пример: https://computercraft.ru/blogs/entry/666-profiliruem-programmy-pod-oc/. Данные запроса. Оно же тело запроса. Если мы отправляем GET/HEAD-запрос, то этот аргумент надо установить в nil. Хедеры, которыми запрос сопровождать. Можно поставить nil, тогда там по минимуму дефолтные подтянутся. Иначе передавать надо таблицу. Её ключи — это названия хедеров. Например, {["Content-Type"] = "application/json"}. Метод запроса. Если же этот аргумент не передавать, то возьмётся по дефолту GET или POST: это зависит от того, пуст ли аргумент 2 или нет. Если возникла ошибка, метод вернёт nil и сообщение об ошибке. Если же всё нормально, то метод вернёт handle — табличку с функциями. Вот что это за функции: handle.finishConnect() — проверяет, подключены ли мы к серверу. Если да, то вернёт true. Если к серверу ещё не подключены, то вернёт false. Если же возникла ошибка (например, 404 вернул сервер или закрыл соединение), то вернёт nil и сообщение об ошибке. Например, nil, "connection lost". В доках написано, что функция ошибку пробрасывает. На самом деле нет: она вообще не бросает исключения. handle.response() — возвращает мета-данные ответа с сервера. Если соединение ещё не установлено, вернёт nil. Если возникла ошибка, вернёт nil и сообщение об ошибке. Например, nil, "connection lost". В противном случае возвращает 3 значения: Код ответа (например, 200). Статус (например, "OK"). Таблицу с хедерами, которые отправил сервер. Выглядит примерно так: {["Content-Type"] = {"application/json", n = 1}, ["X-My-Header"] = {"value 1", "value 2", n = 2}}. Выпишу отдельно, что значения таблицы — это не строки, а ещё одни таблицы. handle.read([n: number]) — читает n байт (если n не задано, то сколько сможет). Если компьютер ещё не успел получить данные, то отдаст "". Если возникла ошибка, то выдаст nil и сообщение об ошибке. Например, nil, "connection lost". Если сервер закрыл соединение, то вернёт nil. В противном случае отдаст строку с частью ответа. handle.close() — закрывает соединение. 2. TCP-сокеты: component.internet.connect У метода есть 2 параметра: Адрес хоста. Например, 127.0.0.1. Здесь также можно указать порт: google.com:80. Порт. Если в первом аргументе порта нет, то второй параметр обязателен. Если возникла ошибка, он также вернёт nil и сообщение. Иначе возвращает handle — табличку с функциями. Вот такими: handle.finishConnect() — то же, что и выше. handle.read([n: number]) — то же, что и выше. handle.write(data: string) — отправляет data по сокету на сервер. Возвращает число переданных байт. Если соединение не установлено, это число равно 0. handle.close() — то же, что и выше. handle.id() — возвращает id сокета. 3. Как правильно отправить HTTP-запрос на сервер и получить ответ Чтобы было интереснее, реальная задача: написать аналог pastebin, только вместо пастбина использовать https://clbin.com/. Особенности: Для взаимодействия с сайтом нужно отправлять HTTP-запросы: GET и POST. Это всё OC умеет. Чтобы скачать, достаточно простого GET по ссылке. Это можно сделать даже через wget. А вот чтобы отправить файл, надо использовать MIME-тип multipart/form-data. OC не умеет из коробки такие формы отправлять. Мы напишем минимальную реализацию, которая бы нас устроила. Не забываем, что этот MIME-тип нужно установить в хедер. При этом мы хотим красиво обработать все ошибки и не допустить ошибок сами. Таким образом, использовать будем практически все фичи. 3.1. multipart/form-data Порядок особенностей нам не важен, поэтому начинаем с самого скучного. Сделаем функцию, которая принимает данные и обрамляет их согласно формату multipart/form-data. local function generateBorder(str) local longestOccurence = nil for match in str:gmatch("%-*cldata") do if not longestOccurence or #match > #longestOccurence then longestOccurence = match end end return longestOccurence and ("-" .. longestOccurence) or "cldata" end local function asFormData(str, fieldName) local border = generateBorder(str) local contentType = "multipart/form-data; boundary=" .. border return ([[ --%s Content-Disposition: form-data; name="%s" %s --%s--]]):format( border, fieldName, str, border ), contentType end Так как это не туториал по интернет-стандартам, вдаваться в детали реализации не буду. С помощью asFormData можно содержимое файла превратить в тело HTTP-запроса. Мы будем вызывать asFormData(str, "clbin"), ибо этого требует сайт. Кроме того, эта функция нам передаст значение хедера Content-Type. Он нам понадобится. 3.2. Взаимодействие с сайтом Напишем теперь функцию — обёртку над component.internet.request. local function request(url, body, headers, timeout) local handle, err = inet.request(url, body, headers) -- ① if not handle then return nil, ("request failed: %s"):format(err or "unknown error") end local start = comp.uptime() -- ② while true do local status, err = handle.finishConnect() -- ③ if status then -- ④ break end if status == nil then -- ⑤ return nil, ("request failed: %s"):format(err or "unknown error") end if comp.uptime() >= start + timeout then -- ⑥ handle.close() return nil, "request failed: connection timed out" end os.sleep(0.05) -- ⑦ end return handle -- ⑧ end Эту функцию можно прямо брать и копипастить в свои программы. Что она делает: ① — отправляем запрос. Сразу обрабатываем ошибку. ② — запрос доходит до сервера не мгновенно. Нужно подождать. Чтобы не зависнуть слишком долго, мы засекаем время начала. ③ — вызываем finishConnect, чтобы узнать статус подключения. ④ — finishConnect вернул true. Значит, соединение установлено. Уходим из цикла. ⑤ — finishConnect вернул nil. Мы специально проверяем через status == nil, потому что не нужно путать его с false. nil — это ошибка. Поэтому оформляем его как ошибку. ⑥ — проверяем, висим ли в цикле мы слишком долго. Если да, то тоже возвращаем ошибку. Не забываем закрыть за собой соединение. ⑦ — нам не нужен бизи-луп. Спим. ⑧ — мы не читаем сразу всё в память, чтобы экономить память. Вместо этого отдаём наружу handle. Частая ошибка — отсутствие элементов ②–⑦. Они нужны. Если до установки соединения мы вызовем handle.read(), то получим nil. Многие программы в этом случае сразу отчаются получить ответ и вернут ошибку. А надо было просто подождать. 3.3. Отправка файла Функция для отправки файла должна сначала прочесть его содержимое, затем сделать запрос и прочесть ответ. В ответе будет находиться URL файла. local function sendFile(path) local f, err = io.open(path, "r") -- ① if not f then return nil, ("could not open file for reading: %s"):format(err or "unknown error") end local contents = f:read("*a") -- ② f:close() local data, contentType = asFormData(contents, "clbin") -- ③ local headers = {["Content-Type"] = contentType} local handle, err = request("https://clbin.com", data, headers, 10) -- ④ if not handle then return nil, err end local url = {} -- ⑤ local read = 0 local _, _, responseHeaders = handle.response() -- ⑥ local length for k, v in pairs(responseHeaders) do -- ⑦ if k:lower() == "content-length" then length = tonumber(v) end end while not length or read < length do -- ⑧ local chunk, err = handle.read() if not chunk then if length then -- ⑨ return nil, ("error occured while reading response: %s"):format(err or "unknown error") -- ⑩ end break -- ⑩ end read = read + #chunk -- ⑪ if length and read > length then chunk = chunk:sub(1, length - read - 1) -- ⑫ end table.insert(url, chunk) end handle.close() -- ⑬ return table.concat(url) -- ⑭ end ① — открываем файл для чтения. Обрабатываем ошибки. ② — считываем всё из файла. Не забываем закрыть его за собой. ③ — вызываем заранее написанную функцию asFormData. Мы получаем тело запроса и значение хедера Content-Type. Создаём таблицу хедеров. ④ — отправляем наш запрос. Обрабатываем ошибки. ⑤ — handle.read может не сразу вернуть весь ответ, а кусочками. Чтобы не забивать память кучей строк, кусочки мы будем класть в таблицу (получится что-то вроде {"htt", "p://", "clbi", "n.co", "m/ab", "cdef"}). Также мы храним число прочитанных байт. ⑥ — мы хотим сверять число прочитанных байт с ожидаемым размером ответа. Для этого нам потребуется получить хедеры, отправленными сервером. Вызываем handle.response. ⑦ — размер ответа обычно пишется в заголовок Content-Length. Однако сервер может поиграться с регистром. Например, писать content-length или CONTENT-LENGTH. OpenComputers не трогает эти хедеры. Поэтому придётся пройтись по всем ключам таблицы и найти хедер без учёта регистра. ⑧ — если length не nil, то это число. Тогда проверяем, что ещё столько байт мы не прочли, и заходим в цикл. Если же Content-Length не задан, то будем считать, что серверу не важно, сколько надо прочесть, и крутимся до упора. ⑨ — handle.read может ещё вернуть ошибку. Если нам известна длина, то в силу условия цикла мы прочли меньше, чем ожидали. Сигналим о неудаче. (Закрывать соединение в случае ошибки не требуется.) ⑩ — если же длина неизвестна, то считаем, что сервер отдал всё, что мог, ошибку игнорируем и покидаем цикл. ⑪ — не забываем обновлять read. ⑫ — если сервер случайно отослал нам больше данных, чем надо (а мы знаем, сколько надо: length определён), то излишки обрезаем. Код здесь отрежет с конца строки (read - length) байт. ⑬ — закрываем соединение за собой, когда оно больше не нужно. ⑭ — наконец, склеиваем таблицу в одну строку. 3.4. Скачивание файлов Код для скачивания похож на предыдущий. Только вот в память мы записывать ответ с сервера уже не будем. Вместо этого напрямую пишем в файл. local function getFile(url, path) local f, err = io.open(path, "w") -- ① if not f then return nil, ("could not open file for writing: %s"):format(err or "unknown error") end local handle, err = request(url, nil, nil, 10) -- ② if not handle then return nil, err end local read = 0 local _, _, responseHeaders = handle.response() local length for k, v in pairs(responseHeaders) do if k:lower() == "content-length" then length = tonumber(v) end end while not length or read < length do local chunk, err = handle.read() if not chunk then if length then f:close() -- ③ return nil, ("error occured while reading response: %s"):format(err or "unknown error") end break end read = read + #chunk if length and read > length then chunk = chunk:sub(1, length - read - 1) end f:write(chunk) end f:close() -- ④ handle.close() return true end ① — открываем файл, в этот раз для записи. Обрабатываем ошибки. ② — отправляем запрос без данных и с дефолтными хедерами. Обрабатываем ошибки. ③ — если мы сюда попали, то дальше сделаем ретурн. Поэтому не забываем закрывать за собой файл. (Сокет закрывать не нужно, так как при ошибке он это делает сам.) ④ — добропорядочно освобождаем ресурсы. Чтобы было удобнее копипастить, я оставил повторяющийся код в двух функциях. В своей программке можно sendFIle и getFile отрефакторить, выделить дублирующуюся часть в отдельную функцию. 3.5. UI Пришло время красивой каденции. Аккордом финальным в ней будет пользовательский интерфейс. Он к интернет-карте отношения уже не имеет, но для полноты приведу и его. local args, opts = shell.parse(...) local function printHelp() io.stderr:write([[ Usage: clbin { get [-f] <code> <path> | put <path> } clbin get [-f] <code> <path> Download a file from clbin to <path>. If the target file exists, -f overwrites it. clbin put <path> Upload a file to clbin. ]]) os.exit(1) end if args[1] == "get" then if #args < 3 then printHelp() end local code = args[2] local path = args[3] local url = ("https://clbin.com/%s"):format(code) path = fs.concat(shell.getWorkingDirectory(), path) if not (opts.f or opts.force) and fs.exists(path) then io.stderr:write("file already exists, pass -f to overwrite\n") os.exit(2) end local status, err = getFile(url, path) if status then print("Success! The file is written to " .. path) os.exit(0) else io.stderr:write(err .. "\n") os.exit(3) end elseif args[1] == "put" then if #args < 2 then printHelp() end local path = args[2] local url, err = sendFile(path) if url then url = url:gsub("[\r\n]", "") print("Success! The file is posted to " .. url) os.exit(0) else io.stderr:write(err .. "\n") os.exit(4) end else printHelp() end 3.6. Вуаля Осталось добавить реквайры, и мы получим полноценный клиент clbin. Результат — на гисте. 4. Как правильно установить соединение через TCP-сокет Прошлая секция была вроде интересной, поэтому здесь тоже запилим какую-нибудь программку. @Totoro вот сделал интернет-мост Stem. Напишем для него клиент. Правильно. Опять же, особенности: Работает через TCP-сокет. Протокол бинарный. И асинхронный. А ещё сессионный: у каждого TCP-соединения есть собственный стейт. Доки хранятся на вики. При разрыве соединения клиент должен переподключиться и восстановить стейт. Здесь снова придётся использовать все фичи интернет-карты. 4.1. Архитектура Мы разделим программу на 2 части — фронтенд и бэкенд. Фронт будет заниматься рисованием и приёмом данных от пользователя, и им займёмся в конце и без комментариев. Бэк — поддержанием соединения и коммуникации с сервером. Это куда больше имеет отношения к гайду, рассмотрим подробнее. Бэкенд реализуем через ООП. Создадим конструктор, напихаем методов, которые затем будет дёргать фронт. 4.2. Конструктор Привычно вбиваем ООП-шаблон в Lua. local newClient do local meta = { __index = {}, } function newClient(address, channels, connectionTimeout, readTimeout, maxReconnects) local obj = { __address = address, __channels = channels, __connectionTimeout = connectionTimeout, __readTimeout = readTimeout, __maxReconnects = maxReconnects; __socket = nil, __buffer = nil, __running = false, __reconnectCount = 0, } return setmetatable(obj, meta) end end Ну, тут всё мирно пока. Начнём боевые действия с протокола. 4.3. Протокол Для него наклепаем кучу методов, которые будут крафтить пакеты и писать их через write. Write сделаем позже. Также сразу сделаем персеры. local meta = { __index = { __opcodes = { message = 0, subscribe = 1, unsubscribe = 2, ping = 3, pong = 4, }, __craftPacket = function(self, opcode, data) return (">s2"):pack(string.char(opcode) .. data) end, __parsePacket = function(self, packet) local opcode, data = (">I1"):unpack(packet), packet:sub(2) return self.__parsers[opcode](data) end, send = function(self, channel, message) return self:write(self:__craftPacket(self.__opcodes.message, (">s1"):pack(channel) .. message)) end, subscribe = function(self, channel) return self:write(self:__craftPacket(self.__opcodes.subscribe, (">s1"):pack(channel))) end, unsubscribe = function(self, channel) return self:write(self:__craftPacket(self.__opcodes.unsubscribe, (">s1"):pack(channel))) end, ping = function(self, message) return self:write(self:__craftPacket(self.__opcodes.ping, message)) end, pong = function(self, message) return self:write(self:__craftPacket(self.__opcodes.pong, message)) end, }, } meta.__index.__parsers = { [meta.__index.__opcodes.message] = function(data) local channel, idx = (">s1"):unpack(data) return { type = "message", channel = channel, message = data:sub(idx), } end, [meta.__index.__opcodes.subscribe] = function(data) return { type = "subscribe", channel = (">s1"):unpack(data), } end, [meta.__index.__opcodes.unsubscribe] = function(data) return { type = "unsubscribe", channel = (">s1"):unpack(data), } end, [meta.__index.__opcodes.ping] = function(data) return { type = "ping", message = data, } end, [meta.__index.__opcodes.pong] = function(data) return { type = "pong", message = data, } end, } В коде я активно использую string.pack и string.unpack. Эти функции доступны только на Lua 5.3 и выше, но позволяют очень удобно работать с бинарными форматами. 4.4. Подключение к серверу Прежде чем реализуем write, нужно разобраться с подключением. Оно нетривиально. local meta = { __index = { ..., connect = function(self) local socketStream = assert(inet.socket(self.__address)) -- ① local socket = socketStream.socket -- ② local start = comp.uptime() -- ③ while true do local status, err = socket.finishConnect() if status then break end if status == nil then error(("connection failed: %s"):format(err or "unknown error")) -- ④ end if comp.uptime() >= start + self.__connectionTimeout then socket.close() error("connection failed: timed out") -- ④ end os.sleep(0.05) end self.__socket = socket -- ⑤ self.__buffer = buffer.new("rwb", socketStream) -- ⑥ self.__buffer:setTimeout(self.__readTimeout) -- ⑦ self.__buffer:setvbuf("no", 512) -- ⑧ for _, channel in ipairs(self.__channels) do -- ⑨ self:subscribe(channel) end end, }, } ① — я использую обёртку над component.internet. Она потом будет нужна, чтобы мы могли поместить сокет в буфер. Обращаю внимание, что вызов обёрнут в assert. Работает она так: если первое значение не nil и не false, то возвращает его, а иначе кидает ошибку, используя второе значение в качестве сообщения. Проще говоря, она превращает nil, "error message" в исключение. ② — а пока я вытягиваю из обёртки сокет... ③ — чтобы можно было проверить, установлено ли соединение. Код здесь аналогичен тому, что мы делали в прошлой секции. Не выдумываем. ④ — одно различие: вместо return nil, "error message" я сразу прокидываю исключение. Прежде всего потому, что ошибки мы прокидывать должны единообразно. Раз в ① кидаем исключение, и здесь делаем то же. Почему исключение, а не return nil, "error message"? Мы вызывать connect будем из всяких мест. Так как в случае ошибок бэкенд беспомощен, то лучше прокинуть ошибку до фронтенда и не усложнять код бэка проверками на nil. Кроме того, это громкая ошибка: если забыть где-то её обработать, она запринтится на экран, случайно пропустить её или подменить какой-нибудь непонятной "attempt to index a nil value" не получится. В конце концов, мне так проще. ⑤ — сокет я сохраняю в поле. socket.finishConnect нам ещё понадобится. ⑥ — пришло время обернуть сокет в буфер. Может показаться излишним, особенно учитывая ⑧. Причины станут ясны, когда будем делать чтение. rw — это буфер для чтения и записи. b — бинарный режим: buffer:read(2) вернёт 2 байта, а не 2 символа. Так как символы кодируются в UTF-8 и занимают 1 (латиница), 2 (кириллица, диакритика), 3 (BMP: куча письменностей, всякие графические символы, большая часть китайско-японско-корейских иероглифов) или 4 байта (всё, что не влезло в BMP, например emoji), то отсутствие этого режима может дать ощутимую разницу. В нашем случае протокол бинарный — ставим b. ⑦ — устанавливаем таймаут для чтения. Объясню подробнее, когда будем это чтение делать. ⑧ — отключаем буфер для записи. Он нам не нужен. ⑨ — здесь же подключаемся ко всем каналам. Итого мы получаем свойства __socket и __buffer. Сокет использовать будем, чтобы вызывать .finishConnect() и .id(). Буфер — для записи и чтения. 4.5. Запись Теперь, разобравшись с сокетами и буферами, мы можем запросто писать в сокет. Пилим write: local meta = { __index = { ..., write = function(self, data) return assert(self.__buffer:write(data)) end, }, } Здесь тоже оборачиваем write в assert, чтобы кидать исключения. Причины уже пояснял. 4.6. Чтение и обработка пакета Сначала делаем функцию readOne. Она будет пытаться читать ровно один пакет. Здесь требуется нестандартная обработка ошибок, поэтому код сложноват. local meta = { __index = { ..., readOne = function(self, callback) -- ⑥ self.__buffer:setTimeout(0) -- ① local status, head, err = pcall(self.__buffer.read, self.__buffer, 2) self.__buffer:setTimeout(self.__readTimeout) if not status and head:match("timeout$") then return end assert(status, head) -- ② local length = (">I2"):unpack(assert(head, err)) -- ③ local packet = self:__parsePacket(assert(self.__buffer:read(length))) -- ④ if packet.type == "ping" then -- ⑤ self:pong(packet.message) end callback(self, packet) -- ⑥ return true end, } } ① — рассмотрим эту мишуру по порядку: Любой пакет stem начинается с 2 байт, которыми кодируется длина остатка. Отсюда всплывает двойка. Автор buffer, к сожалению, не осилил реализовать адекватную обработку ошибок. Он использует и исключения, и тихие ошибки (nil, "error message"). В случае таймаута будет прокинуто исключение. Однако мы перед чтением поставили таймаут в 0. Если буфер не найдёт сразу 2 байта в сокете, то он сразу кинет ошибку. Мы хотим проверить, есть ли в сокете пакет, который бы можно было прочесть. Используем pcall. Сначала раскроем self.__buffer:read(2) как self.__buffer.read(self.__buffer, 2), а затем поместим функцию и её аргументы в pcall. pcall возвращать будет сразу 3 значения по следующему принципу: Если на сокете есть 2 непрочитанных байта, read вернёт их без ошибок. Тогда status будет равен true, в head сохранятся эти 2 байта, а в err запишется nil. Если на сокете этих байтов нет, то read прокинет исключение "timeout". status установится в false, head приравняется "/lib/buffer.lua:74: timeout", а err также будет nil. Если же при чтении с сокета возникла другая ошибка, то read вернёт её по-тихому: status будет true, head — nil, а сообщение об ошибке уйдёт в err. Не думаю, что этот случай возможен, однако read может кинуть исключение и не из-за таймаута. status установится в false, а ошибка сохранится в head. В if мы проверяем, был ли таймаут (ситуация 1.2). В таком случае мы не кидаем исключения, а тихо выходим. Наконец, не забываем вернуть прежнее значение таймаута. ② — обрабатываем случай 1.4. ③ — обрабатываем случай 1.3 с помощью assert. Последний оставшийся и единственный успешный случай (1.1) также покрывается: распаковываем 2 байта в целое беззнаковое число (uint16_t). ④ — в ③ мы получили длину оставшегося пакета. Очевидно, надо остаток дочитать, что и делаем. Здесь уже не надо отдельно обрабатывать таймаут, достаточно assert. Считанный пакет отдаём в __parsePacket. ⑤ — если сервер докопался до нас своим пингом, отправим ему понгу. ⑥ — функция readOne принимает коллбэк. Это функция, которая будет обрабатывать все пакеты. Коллбэк будет передавать фронтенд, а бэкенд займётся минимальной обработкой, чтобы в принципе работало. Как, например, ③. Отлично. Мы приготовили все примитивы, которые были нужны. Осталось собрать их воедино — в event loop. 4.7. Event loop и события Ивент луп — это цикл, который ждёт событий и что-то с ними делает. Пришло время разобраться, что за события есть в OC. Когда мы вызываем socket.read или socket.finishConnect, устанавливается "ловушка" (селектор). Она срабатывает, когда на сокет пришли новые байты. При этом компьютер получает событие internet_ready. После чего "ловушка" деактивируется до следующего вызова. internet_ready, таким образом, — это событие, извещающее нас о том, что на сокете валяются непрочитанные данные и пора вызвать socket.read, чтобы их собрать. У события два параметра. Первый — это адрес интернет-карты. Второй — id сокета. Тот id, который возвращает socket.id(). Поэтому мы сохранили сокет в поле __socket: сейчас будем использовать его. local meta = { __index = { ..., __run = function(self, callback) while self.__running do local e, _, id = event.pullMultiple(self.__readTimeout, "internet_ready", "stem%-client::stop") -- ① if e == "internet_ready" and id == self.__socket.id() then -- ② while self:readOne(callback) do self.__reconnectCount = 0 -- ③ end elseif e ~= "stem-client::stop" then self:ensureConnected() -- ④ end end end, stop = function(self) self.__running = false event.push("stem-client::stop") -- ⑤ end, } } ① — ждём события internet_ready или stem-client::stop. Так как в event.pullMultiple названия ивентов сверяются через string.match, дефис экранируем. Второй ивент нужен, чтобы принудительно прервать цикл из stop. ② — обрабатываем мы только internet_ready и только для нашего сокета. Проверяем. ③ — если поймался пакет или пакеты, то пытаемся обработать каждый в порядке прибытия. Когда мы закончили обрабатывать все пакеты, self:readOne вернёт nil, и цикл прервётся. Кстати говоря, если мы внутри цикла оказались, то соединение установилось. Не забываем отметить это. ④ — если же улов пуст, перепроверяем, подключены ли мы вообще. ⑤ — не забываем добавить метод, чтобы остановить наш цикл. Отсюда же отсылаем событие stem-client::stop. Отлично. Теперь пришло время ловить все наши прокидываемые исключения. 4.8. Обработка ошибок Последними 2 функциями, которые мы добавим, будут ensureConnected и run. С их помощью бэкенд будет автоматически переподключаться к серверу в случае проблем. local meta = { __index = { ..., ensureConnected = function(self) local status, err = self.__socket.finishConnect() -- ① if status == false then error("not yet connected") end return assert(status, err or "unknown error") end, run = function(self, callback) if self.__running then -- ② return end self:connect() -- ③ self.__running = true while self.__running do -- ④ local status, err = pcall(self.__run, self, callback) -- ⑤ if not status then if self.__reconnectCount == self.__maxReconnects then -- ⑥ return nil, ("connection lost: %s; reconnect limit is reached"):format(err or "unknown error") end self.__reconnectCount = self.__reconnectCount + 1 self.__buffer:close() -- ⑦ if not pcall(self.connect, self) then -- ⑧ if self.__socket then self.__socket:close() end if self.__buffer then self.__buffer:close() end os.sleep(1) end end end self.__buffer:close() end, }, } ① — ensureConnected просто прокинет ошибку, которую вернёт finishConnect(). ② — принимаем защитную позицию против дураков. Рекурсивно запускать циклы смысла нет. ③ — сначала подключаемся к серверу. Если всё отлично, то можно начинать. ④ — как и в __run, здесь мы оборачиваем код в цикл. Если вызван stop(), то сначала остановится self.__run, а затем и этот цикл. ⑤ — обработка исключений требует pcall. Потому что их надо словить. ⑥ — если мы старались-старались, но так и не смогли уложиться в self.__maxReconnects по реконнектам, кидаемся белым флагом. ⑦ — не забудем закрыть буфер. ⑧ — вспомним, что self.connect кидает исключение. Перехватываем. На всякий случае позакрываем то, что породил connect. 4.9. Фронтенд На этом наш бэкенд готов. Поздравляю. Остаётся лишь прицепить ввод-вывод. Опять же, даю готовый код без комментариев, ибо не об этом пост. local gpu = com.gpu local w, h = gpu.getResolution() local function writeLine(color, line) local oldFg if gpu.getForeground() ~= color then oldFg = gpu.setForeground(color) end local lines = 0 for line in text.wrappedLines(line, w + 1, w + 1) do lines = lines + 1 end gpu.copy(1, 1, w, h - 1, 0, -lines) local i = 0 for line in text.wrappedLines(line, w + 1, w + 1) do gpu.set(1, h - lines + i, (" "):rep(w)) gpu.set(1, h - lines + i, line) i = i + 1 end if oldFg then gpu.setForeground(oldFg) end end local channel = ... if not channel then io.stderr:write("Usage: stem <channel>\n") os.exit(1) end if #channel == 0 or #channel >= 256 then io.stderr:write("Invalid channel name\n") os.exit(2) end local client = newClient( "stem.fomalhaut.me:5733", {channel}, 10, 10, 5 ) require("thread").create(function() while true do term.setCursor(1, h) io.write("← ") local line = io.read() if not line then break end local status, err = pcall(client.send, client, channel, line) if not status then writeLine(0xff0000, ("Got error while sending: %s"):format(err or "unknown error")) break end end client:stop() end) client:run(function(client, evt) if evt.type == "message" then writeLine(0x66ff00, "→ " .. evt.message) elseif evt.type == "ping" or evt.type == "pong" then writeLine(0xa5a5a5, "Ping: " .. evt.message:gsub(".", function(c) return ("%02x"):format(c:byte()) end)) end end) os.exit(0) Здесь я упускаю одну вещь: обработку ошибок в client.send. Если мы попытаемся отправить сообщение, когда у нас потеряно соединение (или до того, как оно установлено), мы или словим ошибку, или потеряем сообщение. Починить это можно, добавив очередь отправляемых пакетов, но это в разы усложнит программу, поэтому оставим так. 4.10. Готово! Добавим реквайров... И у нас получился вполне рабочий клиент для Stem! Код программы — на гисте. 5. В чём различие между component.internet и require("internet") Первое — исходный компонент. Второе — обёртка над ним. У обёртки есть 3 функции: internet.request(url, data, headers, method) — обёртка над component.internet.request. Удобна тем, что все ошибки превращает в исключения за программиста. Кроме того, возвращаемое значение — итератор, и его можно поместить в цикл for. Тем не менее, код, который ждёт установки соединения, нужно писать самому. internet.socket(address, port) — промежуточная обёртка над component.internet.connect. Она используется для того, чтобы потом превратить её в буфер, как сделали мы. Сама по себе достаточно бесполезна. internet.open(address, port) — тоже обёртка над component.internet.connect. Она вызывает internet.socket(address, port) и сразу превращает результат в буфер. Проблема в том, что сам объект сокета использовать можно только через приватные свойства, которые могут ломаться между обновлениями OpenOS. Из-за этого функция исключительно ущербна. Для отправки HTTP-запросов я предпочитаю использовать API компонента. TCP-сокеты же проще создавать через обёртку (internet.socket), вручную проверять подключение и так же вручную укладывать обёртку в буфер, как показано выше. 6. Конец Самое сложное в использовании интернет-карты — это правильно обработать все ошибки. Они могут возникнуть на каждом шагу, при этом быть полноценными исключениями или тихими ошибками. Необработанные исключения крашат программу, из-за чего возникает желание весь код программы поместить в один большой pcall. Например, IRC-клиент, который на дискете поставляется, делает так. Тихие ошибки гораздо подлее. Необработанные, они тоже крашат программу, только вот сама ошибка теряется, подменяется другой (обычно "attempt to index a nil value"). В Lua обработать все ошибки — задача сложная, потому что механизм ошибок ужасен. В нормальных языках стэктрейс отделён от сообщения об ошибке, плюс каждая ошибка имеет свой тип, по которому можно безопасно определять вид ошибки. Lua этим не заморачивается: сообщение об ошибке включает позицию в коде, откуда ошибка прокинута. Есть или нет стэктрейс, зависит от выбора между pcall и xpcall. Если они находятся где-то в другой библиотеке, программист на выбор повлиять не может. В коде Stem-клиента единственный способ узнать, от таймаута ли ошибка прокинута, — матчить последние 7 символов на слово "timeout". Это эталонный костыль. Даже в JavaScript механизм лучше. Поэтому этот пост получился не столько про интернет-карту, сколько про обработку ошибок.

На забугорном домене лежит забугорный сайт, где находится забугорный форум, где обсуждают забугорные темы. В общем, просматривая в очередной разик форум @ oc.cil.li, заметил сразу два почти-подряд аддона к ОС. I. OpenFM. К аддонам под ОС причислить эту мурму можно с большой натяжкой, что я и сделал — за то, что этот автор делал тру-аддоны. В общем, эта помпесная штуковина "заменяет" любой нормальный мьюзик-плеер. Ага, с большой натяжкой А если точнее — позволяет прослушивать интернет-радио прямо в игре. И если среднестатистический Ноу-Модс Архканьюп Иванович, как обычно, начинает готовить тухлые яйца и помидорчики, то будет ошибаться. Штука работает по интересному принципу: блок, по сути, работает только как раздатчик ссылки потока. Клиент же, в свою очередь, подключается к потоку интернет-радио и начинает крутить пластинку. Собственно, сервер страдает от этой штуки не сильнее, чем от сундучка. Чистый и опрятный интерфейс, где всё (почти) интуитивно понятно: закрыть, посыпать редстоун-пылькой, потыкать, кажется, бесполезный индикатор (на самом деле — регулятор громкости, да). В центре фокуса у нас поле для ввода URL на поток. Снизу кнопки для очистки поля, вставки, сохранения и удаления. Снизу — незаметная реклама производителя и самая весёлая кнопка паузы-старта. Потоки принимаются в форматах MPEG 1..3 или в плейлистах pls/m3u с файлами опять-таки MPEG 1..3. Ну, и решим вопрос об интеграции с ОС. Под спойлером список функций. Ссылка на скачивание: http://minecraft.curseforge.com/projects/openfm Ссылка на топик: http://oc.cil.li/index.php?/topic/743-openfm-streaming-radio-with-oc-control/ Ссылка на исходники и баг-трекер: https://github.com/PC-Logix/OpenFM II. OC-Minecarts. Есть вагонетки — штуки, в которых можно сидеть и кататься по шахторельсам. Есть компы — в частности, перед оным Вы сейчас и находитесь. А есть энтузиасты. Так вот, эти чёртовы энтузиасты решили поместить льва в клетку компы в вагонетку. С этой целью была создана тема на баг-трекере в далёком четырнадцатом году. https://github.com/MightyPirates/OpenComputers/issues/465— вот историческая ссылка на сей артефакт. Было принято решение компы вынуть из вагонетки и отправить @LeshaInc кодить на них, а вагонетки — лагодромщику на его развлечения. Собственно, уже не так давно, а если точнее, то недавно, у нас снова всплыла эта тема. Только не на баг-трекере, а отдельно, и не просто идеей, а аддоном. Встречайте! OC-Minecarts готовы порабощать мир! О вопросах эксплутации проблема, казалось бы, не стоит. Вот только, как выяснилось, роботами и дронами всё это хозяйство делать проще. Но не суть. Этот мод добавляет: Вагонетки Специальный блок Ж/Д путей, заряжающий батарею компьютеров Пути общения со внешним миром через сообщения и контроллер Самое интересное, что вагонетка контролируется компьютером! Для чего предусмотрено несколько специальных команд, с которыми ознакомиться Вы можете здесь: https://github.com/feldim2425/OC-Minecarts/wiki/Computer-Cart-(Component) Ссылка на топик: http://oc.cil.li/index.php?/topic/737-mc-1710oc-15-oc-minecarts-alpha/ Ссылка на скачивание: http://minecraft.curseforge.com/projects/oc-minecarts Ссылка на исходники и вики с баг-трекером: https://github.com/feldim2425/OC-Minecarts/ В этой теме предлагаю оставлять свои варианты применения данных штуковин или программки =)

Что такое RemoteOS RemoteOS - это мост для связи OpenComputers с внешним миром, написанный на языке C# (.NET 6.0). В чём отличие RemoteOS от уже существующих решений Начнём с самого очевидного и главного - на сервере имеется (почти) точная копия API OpenComputers. Это позволяет не только использовать подсказки в коде при работе с мостом в IDE но и проверять данные подаваемые в методы ещё до отправки их на компьютер OpenComputers(далее машина). Так-же такой подход позволяет реализовать кэширование, которое даёт возможность в некоторых местах не дёргать постоянно машину для опроса актуальных значений... Из-за того что на сервере наклёпано столько архитектуры он не такой легковесный как остальные мосты... Мой мост работает не из под OpenOS а прямо с EEPROM'а, что позволяет значительно снизить минимальные системные требования для работы этого моста но при этом это же отличие значительно его ограничивает - будут недоступны все те удобненькие библиотеки из опенос, то-есть нельзя работать ни с чем кроме того что предоставляет lua и клиентская ос моста... Не нужно запрашивать сигналы с машины, она сама их шлёт серверу... Какие у RemoteOS системные требования Для машины - интернет карта и EEPROM прошитый на клиентскую ос RemoteOS Для сервера - 1 открытый сетевой порт чтобы иметь связь с машиной и достаточная вычислительная мощность чтобы суметь запуститься а затем отсылать пакеты машинам, получать от них ответ и обрабатывать этот ответ... Как же всё таки пользоваться RemoteOS Начнём с того что C# - не самый удачный выбор для связки с LUA ибо C# это строго типизированный яп а луа не очень...и подгонять сервер под все причуды луа кода было тем ещё приключением...но у меня вроде как вышло, так что посмотрим как всем этим добром пользоваться... Ловля подключений: Компоненты: Сигналы: Выполнение произвольного кода: Директивы предпроцессора: Какие у меня планы на RemoteOS [+] Планирую добавить документацию в код, чтобы можно было прямо в IDE зачитать что конкретный метод делает... Хочу сделать веб-интерфейс для управления машинами Хочу довести кэширование до ума, чтобы надо было дёргать машины ещё меньше)) Возможно сделаю свой LINQ провайдер, чтобы можно было цеплять несколько методов в один запрос без особых усилий...думаю это уменьшит время отклика машины в некоторых случаях... Возможно добавлю какое-то подобие adhoc или меш сети чтобы ещё больше занизить планку минимальных требований...эта сеть должна будет работать на обычных беспроводных карточках 1 уровня и машины смогут перекидывать по внутренней сети пакеты от машин с интернет картой их получателям и потом возвращать их обратно чтобы машина с интернет картой отправила ответ обратно на сервер...эта задача довольно трудная, не уверен смогу ли её реализовать и целесообразна ли она вообще так как это значительно увеличит время отклика и повысит траффик на входных\выходных точках сети что тоже может стать проблемой... Отбой, новая идея: если рестрансляторы это то, что я думаю то это идеальный вариант - не надо будет делать сложную прогу с автоперестройкой марштрутов сети и при этом они легко крафтятся, можно будет просто натыкать кучку ретрансляторов по всей необходмой площади покрытия и готово...останется только приспособить клиентскую ос под простой отсыл и приём пакетов с беспроводной карточки... Ссылки Репозиторий проекта: Тык (Github) Клиентская ОС: Тык (Github) Демо-видео: Тык (Яндекс диск)

Приветствую вас. Этот пост я пишу, чтобы рассказать вам о своей разработке для мода OpenComputers: BetterBIOS Это специальная прошивка BIOS для EEPROM, позволяющая выбирать любое из подключенных устройств для загрузки. Для этого используется пользовательский псевдографический интерфейс, который поддерживается на всех уровнях видеокарт и экранов. Так же, в этой прошивке есть своя система отображения ошибок, показывающая весь "traceback" за исключением не нужных пунктов внутри самой прошивки. Это будет очень полезно для разработчиков собственных операционных систем, ведь данная прошивка подскажет места, в которых возникла ошибка, в то время как стандартная прошивка молчит как партизан. UPD. Начиная с версии 4, код ошибок можно пролистывать: Если доступных для загрузки устройств больше, чем одно - то при включении компьютера, пользователю предлагается выбрать одно из них. Если такое устройство только одно - загрузка начнётся незамедлительно. Подключение устройств для загрузки происходит динамически, "на лету", прямо во время выбора устройства. Так же, данная прошивка имеет приоритеты на выбор экрана: первым делом она пытается подключить тот экран, у которого есть клавиатуры поблизости. Если таковых не имеется - использует любой другой. Видеокарту прошивка использует максимального уровня. Прошивка защищена от критических сбоев при резком извлечении устройств, пока программа работает с файлами на них. Это делает данную прошивку практически не убиваемой, и позволяет избегать любых несчастных случаев при работе с компьютером. Я просто параноик, иначе сделать не мог... Данная прошивка поддерживает большое количество разных операционных систем, использующих разные файлы для загрузки: OpenOS Plank9 MineOS Работает это за счёт списка файлов, которые ищет прошивка. Вы можете добавить свои файлы, вписав их в переменную в начале файла. Ну или можете оставить комментарий под этой темой, с просьбой, какой файл стоит ещё добавить. Забавный факт: Если таких файлов будет очень много, то посмотрев их список нажатием клавиши F8 при выборе устройства - вы можете пролистывать список. Так же, если вы хотите, чтобы прошивка при запуске не перезаписывала данные EEPROM (setData), и не мусорила в оперативной памяти рудиментарными функциями типа "computer.getBootAdress", которые нужны для OpenOS - вы можете отключить всё это дело в меню через клавиши. А если вам не хочется каждый раз их нажимать - то просто измените комментарий в конце кода с 11 на 10 или 00. Несмотря на весь этот функционал и продуманность, в минимизированном виде данная прошивка помещается на EEPROM, стандартная ёмкость которого - 4096 символов. К сожалению, код не очень хорошо читаемый, но это обусловлено тем, что я писал заранее с расчётом на то, что подробный код будет минимизирован, а для них нужно ещё и грамотно написать код, который, увы - сложно читается. Исходный код данной прошивки вы можете посмотреть здесь. Спасибо за внимание. Если у вас есть какие-то идеи, как можно улучшить или ухудшить данную прошивку - пишите здесь, или как-нибудь вычислите меня, постараюсь подумать, и может быть, даже обновлю код, сделав его лучше для вас.

Хотел заказать эту программу у других, но пришлось писать самому. Ничего, награду тоже выдам себе. Моя программа (https://github.com/ProgramCrafter/lua-utils/blob/a22e5e50ad46f130f6a7ec5959cd7282bb8a06df/beealyzer_v1oc.lua) служит компактным интерфейсом для сундука с пчёлами. Её возможности: 1. Сканирование сундука и вывод списка проанализированных пчёл с их характеристиками на экран (при запуске происходит автоматический скан); 2. Выдача любой пчелы кликом левой кнопкой по её описанию; 3. Принудительное обновление списка (если в сундуке что-либо появилось) правой кнопкой мыши; 4. Выход кликом по заголовку. Схема собирается таким образом: к компьютеру надо подключить транспозер, сверху на него поставить сундук с пчёлами, а с восточной стороны (правится в коде) выбрасыватель. Выбрасыватель требуется запитать от генератора импульсов (я использовал таймер из RedLogic из-за его компактности) - программа не подаёт самостоятельно импульс для выкидывания пчелы. Чтобы программа работала, не забудьте поменять в начале программы ник доверенного пользователя на свой. Программа воспринимает нажатия только от доверенного пользователя - то есть, по умолчанию, только от меня. Как выглядит интерфейс:

как пользоваться: для входа в меню bios нажмите alt при загрузке для установки пароля bios>password(текущий пароль)>set password вводите пароль два раза пароль можно выключить и он будет нужен только для входа в меню password он может блокировать меню или загрузку в цело пароль захеширован хоть и храниться в nbt, владельцы варпов могут быть спокойны также вы можете перезагрузить компьютер без появления надписи bios menu(computer.shutdown("fast")) или сразу в меню (computer.shutdown("bios")) если у вас стоит мод для openOS() то вы можете использовать reboot fast и reboot bios прямо в shell также из под функций присутствует: url boot (Internet>Url boot) возможность запуска openOS через интернет(Internet>openOSonline) так же биос умеет подгружать утилиты с github репозитория, которых в скором времени там будет много password возможность загрузки в разные файлы на одном диске например - openOS и mineOS что может быть непонятно: если вы вводите пароль а поле просто очищается значит вы ввели его неправильна если вы вводите в буквы не вводиться убедитесь что у вас включен английский язык если вы поставили пароль в он не подставился и не было окна pleas wait значит два пароля не совпадают примечания: поддерживаются все тиры железа обязательно установить архитектуру процессора в lua 5.3(начиная с новой версии биос меняет ее автоматически(как Cyan Bios)) начиная с новой версии загрузка в mineOS работать не будет, это проблема ос, так как она использует getData вместо getBootAddress, и я больше не собираюсь поддерживать этот костыль(поддержка mineOS была полностью удалена) команда для установки: wget https://raw.githubusercontent.com/igorkll/microBios/main/compressed.bin /tmp/bios.lua -f;echo "" > /dev/eeprom-data;flash /tmp/bios.lua microBios -q;echo "require('computer').setArchitecture('lua 5.3')" > "/tmp/architecture.lua" /tmp/architecture.lua;reboot