Bs0Dd

Увы, инсталлер не проверяет наличие файлов на машине и при обновлении можно получить ахтунг в виде ругани и не обновившихся файлов Поэтому лучше все же добавить проверки, дабы избежать неприятностей fs = require('filesystem') if not fs.exists('/usr/bin') then fs.makeDirectory('/usr/bin') end if not fs.exists('/usr/lib') then fs.makeDirectory('/usr/lib') end if fs.exists('/usr/lib/lzss.lua') then fs.remove('/usr/lib/lzss.lua') end os.execute('wget https://raw.githubusercontent.com/BrightYC/Other/master/lzss.lua /usr/lib/lzss.lua') if fs.exists('/usr/bin/bpacker.lua') then fs.remove('/usr/bin/bpacker.lua') end os.execute('wget https://raw.githubusercontent.com/zgyr/bpacker/master/bpacker.lua /usr/bin/bpacker.lua') if fs.exists('/usr/bin/minify.lua') then fs.remove('/usr/bin/minify.lua') end os.execute('wget https://raw.githubusercontent.com/stravant/lua-minify/master/minify.lua /usr/bin/minify.lua') Ну и я бы все же дописал, что метод с LZSS требует перевести процессор в режим Lua 5.3, иначе, ахтунг с подгрузкой библиотеки

Вижу пытаетесь MineOS поставить, а идентификатор написан неверно, вот и ошибка Если написано 0nM5b1jU, то и писать надо именно так с соблюдением регистра (больших и маленьких букв) А у вас все, однако, маленькими

Ого, стоило мне подумать про возможность упаковки программы и распаковки перед запуском, как тут-же нашелся человек, который это сделал. Возможно так получится уместить мой кодовый замок, надо попробовать. ------ Да, с 15,2кб программу ужало до 3,4кб без использования минификации

Да, именно так. На работу вне оси и делался упор.

Не совсем. Да, ее можно в теории загрузить с еепром, но вес в 15кб этого не позволит, поэтому она загружается обычным Lua BIOS с носителя, как будто OpenOS Ужатием наверное, как уже говорил, все же стоит заняться, но я в минимизации кода не мастер, все же человек начинающий. Хорошо, приму к сведению, но такой способ будет иметь смысл только, если замок получится ужать до 4Кб

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

Из, непосредственно, системы то доступны только нативные библиотеки Lua, computer и component, или я что-то не так понял? А куда девать все остальное? Опять же, нужен какой-то носитель с емкостью хотя бы в килобайт У них разные рабочие разрешения, оттого рисуются разные версии кнопок, не используется "градиент" на плашке с паролем, другие координаты нажатий и т.д. Имхо, слишком много получается отличий, что совсем нехило раздует программу Не исключаю, это первая попытка написать что-то масштабное вне OpenOS, поэтому... если есть на что конкретно указать, подумаю-переработаю

Не получится , программа-клиент требует библиотеки из OpenOS Вообще я собирался сделать NetBIOS, в который прописываются данные сетевого диска и он грузится с него, но нужно переделывать моменты с этими проклятыми библиотеками и ужимать саму клиентскую систему (в удобном для чтении формате занимает 8кб) + нужно создать виртуальный компонент этого диска (в самой ОС этого то можно и не делать, но при загрузке будет необходимо) + загрузчик Lua и на все это 4Кб((( Если кто из "садо-мазо" может такое провернуть и хочет мне помочь, буду только рад. Вот то то и оно...

Я пытался это сделать еще на этапе написания кода, но увы, ужать все нужные функции (библиотек то у нас нету без OpenOS) + код самого замка до 4Кб не вышло. Может конкретный садо-мазо и смог бы Да и в любом случае, где-то нужно хранить настройки и список доверенных пользователей (которые могут войти по отпечатку), а области в 256 байт у биоса для этого будет маловато Вообще, если туго с жесткими дисками, никто не мешает записать кодовый замок на дискету и грузиться с нее. Но тогда при доступе к диску, дисковод, конечно же, будет жужжать.

component.get() нужен, дабы из сокращенного адреса получить полный Вот есть у меня, например, кассетный стример, и я помню первые три символа в адресе, например "205" И тогда component.get("205") вернет полный адрес, т.е. "2059288d-a4df-4acb-a033-2476ac7e2817" А рулить двумя редстоун картами (или блоками, не принципиально, ибо идентифицируются как один и тот же компонент) можно, например, загнав их прокси в таблицу с помощью итератора. local component = require("component") local all = component.list("redstone") local redstone = {} for redcard in all do table.insert(redstone, component.proxy(redcard)) end redstone[1].setOutput(...) redstone[2].setOutput(...) Но если вы знаете их адреса, можно вообще обойтись без него. local component = require('component') local firstRed = component.proxy(ID) local secondRed = component.proxy(ID2) firstRed.setOutput(...) secondRed.setOutput(...)

А нужно ли? Перед перенастройкой сначала спрашивается старый пароль (отпечаток в таком случае отключен) и если введеный пароль верен, можно задать новые настройки ------ Дописал в шапку про пароль

Наверняка многие помнят программку CodeDoors, некогда входящую в состав MineOS. И пару месяцев назад я с удивлением обнаружил, что ее нет ни в репозитории ГитХаба, ни в самой ОС. Ну и недолго думая, я решил написать свою версию, причем с одним небольшим НО. Кодовый замок должен работать без какой-либо ОС. Вот так и появился этот графический кодовый замок. Система отпечатков работает аналогично таковой в CodeDoors. Репозиторий на GitHub Естественно, выйти из программы не получится, поскольку выходить просто некуда, и в этом большой плюс. Установка довольно проста: При необходимости можно перенастроить программу, нажав на "(c)" в строке копирайта (а вы думали он тут просто так?) и введя старый пароль. Скриншоты: Цветная версия Монохромная Перед публикацией постарался отловить баги, но не исключено, что что-то могло быть упущено из виду.

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

Выгружать файлы целиком в ОЗУ очень нехорошая идея. Если все 14 клиентов пооткрывают файлов (размер которых может быть и немаленьким), сервер может закушать столько памяти, что и вовсе свалится от ее нехватки, а дорогие сервера с кучей ОЗУ под это выделять не всегда возможно. Да с количеством файлов надо что-то думать, но так, чтобы оно сильно не ело память.

Некоторое время назад возникла необходимость иметь доступ к файлам с разных компьютеров. Для такого уже есть программка от @Zer0Galaxy, но ей невозможно пользоваться, поскольку сервер падает при открытии файла (ибо модем заставляют переслать таблицу с функциями файла, а он в такое не умеет). В октябре я засел писать свою версию (еще не зная о программе "FTP"), писал с большими перерывами, а потому первая более-менее рабочая версия у меня получилась только сейчас. Данная система работает несколько иначе, она выделяет под сервер не определенную папку, а диск целиком, являясь, фактически, прокси-прослойкой между диском сервера и ОС клиента, также на стороне сервера есть два уровня логирования запросов (в текстовый файл). "Лэйбл" передается напрямую с реального удаленного диска, адрес тоже соответствует реальному, но без всех тире и с приставкой "-rfs". Посмотреть весь код можно на ГитХабе Как развернуть сеть: Про режимы работы и уровни логирования: Примите во внимание, что обмен сетевыми пакетами требует некоторого времени, поэтому чтение/запись данных (особенно малыми блоками) может занять продолжительное время. Возможно, в будущем, попробую снизить задержки. Еще, если кто-то нашел в программах баг или недоработку (а таких может быть много), просьба сразу сообщить об этом. А если вы еще и скажете, как решить эту проблему, то цены вам не будет))).

Обновил. Нужно, пожалуй, найти что-то получше gedit'а для редактирования программ вне OpenOS

Учел, добавил проверку на выгружаемость (проверяется также, выгружен ли слот полностью), иначе отдых Бонусом добавлено: -Опциональная возможность использования динамика в качестве индикатора проишествия -Проверка, не исчерпалась ли прочность/заряд инструмента (иначе снова спим) -Если есть возможность вставить в робота контроллер инвентаря, то можнр включить автозарядку инструмента (например Иридиевый бур). По достижению лимита робот прервет работу, повернется в сторону зарядника (кол-во поворотов до него задается в переменной), положит бур, уснет на время его зарядки (задается вручную), проснется, заберет, повернется обратно и продолжит работу Возможно, опять же, можно где-то сделать и лучше

Исправил и это упущение (надеюсь правильно).

Мда, наделал я тут блинов комом Сделал паузу по функции из ОС, проверял на роботе с дисплеем, теперь не спамит (вставлял перед слип-циклом принт) И на всякий добавил проверку и на то, поставился ли блок, ибо если поставить блок не вышло, программа уйдет в нулевую паузу пытаясь сломать воздух и после уладки проблемы нужно самому поставить блок перед роботом, дабы он его сломал и вышел из цикла. Возможно я наделал еще чего не так, честно говоря, в роботов полез впервые и не ожидал, что писать под них программы несколько сложнее, чем на обычные компьютеры (особенно если дело касается EEPROM-программ)

Пауза в конце тут стоит, сколь я понял, на тот случай, если в сундуке вдруг кончатся ресурсы. Тогда робот будет ждать 5 секунд перед следующей попыткой взять оттуда блок. И если уже есть ивенты и пауза не произойдет, то он опять попытается взять блоки, поймет, что их нет и снова пойдет в ожидание на 5 сек. Можно конечно, как в слипе, через цикл по времени аптайма дергать пуллСигнал, тогда такого не будет. Но вообще в такой конструкции, как я говорил, сбив паузы не критичен. Задержка в 5 сек все равно работает (ибо робот берет блоки не сразу после их закидывания в сундук), проверял перед правкой в паст

Ох, спасибо за замечание, скорая работа делает свое (и малый опыт работы с EEPROM программками). Совсем забыл, что в данном случае будет достаточно computer.pullSignal(), ибо если приостановка собьется ивентом, по идее, ничего страшного быть не должно Убрал нарезки из библиотеки в коде и заменил на него, вроде все работает.

Если нужно сэкономить на производстве роботов, то могу предложить немного переработанную версию (сделанную за пару минут на коленке) на основе той же программы от Asior'а: https://pastebin.com/gdk0by50 Разница (помимо большего размера) в том, что программа может исполняться прямо из EEPROM, что позволяет собирать крайне дешевых роботов (насколько уж это возможно): В данном случае не нужен даже дисплей и видеокарта, достаточно прошить каким-нибудь компьютером чип и собрать с ним робота