ECS

В каком приложении или при каких условиях? Клиент на винде, линуксе? Поставил оську с юзером "Тест", добавил ещё одного "Мяу-мяу", и всё в порядке:

Для некоммерческого проекта, имхо, овчинка не стоит выделки. В сурвайвале на сервере я обычно упираюсь в потребность в репрезентативных гуишных приложениях для мониторинга/управления реакторами/фабриками, либо удалённого управления роботами-шахтёрами с отображением графической статистики на экране, и даже не припомню, чтобы пользовался какой-либо консольно-ориентированной программой (разве что на старте игры или для быстрого просмотра возможностей компонентов). Всё так или иначе упиралось в GPU'шный мазохизм с графикой и тоннами setBackground/setForeground: поэтому, собственно, я и стал писать майнось как более-менее удобный конструктор для гуишных приложений с возможностью запуска приложух за пару кликов. Лично для себя я не вижу ни удобства, ни выгоды в написании приложения-враппера, имитирующего опеносовские либы tty/term/shell/thread, которым даже пользоваться не буду. Ну серьёзно, какие конкретно опеносовские скрипты настолько жизненно важны и настолько сложны в написании, что их нельзя реализовать в майноське и выложить в маркет? Уже в третий раз спрашиваю, а ответа всё нет...

Увы, это всё же разные ОС, и имеют хоть и схожие, но различные API. Простые скрипты по типу установки уровня редстоун-сигнала от I/O-блока вряд ли будут отличаться, а вот отображение или чтение пользовательских данных уже могут сильно разниться, т.к. опенось имеет консольную систему ввода-вывода, а майнось - графическую. Я всё же повторю свой вопрос, ибо ответа не узрел: какого функционала опеноси тебе не хватает в майноси? Какого рода программы/API ты считаешь нужным перенести? И в чем заключается сложность изучения API майноси?

А какого функционала либ из опеноси (помимо сериализации) по твоему мнению не хватает? Сериализация/десериализация и так доступна из коробки, на вики вся инфа: https://github.com/IgorTimofeev/MineOS/wiki/Text-API

Useradd не снимается и работает параллельно с доп. защитой в виде строкового пароля. Просто как плюха для желающих защищать комп и так, и эдак. Обе вариации конфигурируются в приложении Settings

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

Если нужно прям самому и с нуля написать, то в качестве вспомогательного материала можешь чекнуть исходник майносевского упаковщика файлов, он крайне прост. Там используются некоторые специфичные методы filesystem типа writeBytes/readBytes, но реализовать ихи или стыбзить не составит труда: https://github.com/IgorTimofeev/MineOS/blob/master/Libraries/Compressor.lua https://github.com/IgorTimofeev/MineOS/blob/master/Libraries/Filesystem.lua А если нужно сжатие данных, то поверх этой конструкции придется прикрутить какой-нибудь deflate

Поправьте меня, если я ошибаюсь, но, насколько я помню, компонент интернет-платы не позволяет провернуть операцию, аналогичную seek - поэтому приходится загружать контент целиком, "скипая" содержимое до интересующего места. А логи в примерах довольно жирные для опенкомпов, файлы > 500 кб всегда грузятся ощутимо долго. Если есть доступ к директории сервака, то можно накатать простенький php-скрипт, выдающий содержимое файла с конца: https://stackoverflow.com/questions/2961618/how-to-read-only-5-last-line-of-the-text-file-in-php Или же при наличии сокет-сервера пушить в него каждую отправляемую в лог строку, а затем читать на опенкомпах через internet.connect. Если же доступа к хосту нет, но есть собственная VPS'ка - можно накатать аналогичный скрипт с небольшими модификациями для файлов по удалёнке.

О, сколько ж лет в обед этой теме! Спасибо, ссылку поправил на старый коммит, хоть проблемы с зависимостями всё равно останутся - в той же ветке гита можно найти и их, если надо. Легаси, что ж поделать. Однако общий принцип работы понять не составит труда

Это сделали из-за банального отсутствия стандартного текстового вывода, т.к., как уже сказали выше, ось заточена под графическое отображение данных, а не текстовое. При потребности отображения текста я обычно добавляю в оконное приложение элемент интерфейса GUI.text(), а затем меняю его параметр .text в процессе. Если требуется непрерывный вывод информации с историей, то альтернативой может послужить GUI.textBox(). Если всё же требуется вывести отладочную инфу "по-быстрому", то имеется функция GUI.alert(...), принимающая аргументы любого типа по аналогии с print(...) и вызывающая диалоговое окно с переданными данными. А смысл использовать эту IDE всегда лишь один - отсутствие более комфортных средств разработки (к примеру, во время игры на удалённом сервере без доступа к файловой системе). Да и банальную подсветку синтаксиса никто не отменял, эта IDE существует чисто для удобства по той же причине, по которой существует edit.lua в OpenOS.

О, время тырить формулу, спасибо. *потираю ручки*

proga.lua lol kek local args = {...} print(args[1]) print(args[2]) > lol > kek

@BrightYC угу, но лень-матушка в приоритете

Она была на старом API написана, а на новую версию никому не захотелось переделывать. Поэтому просто не добавили

Не-не-не, все так и должно быть: read тупо пытается прочесть по кускам контент веб-страницы с сокета. Если сервак пока еще не кинул ошибку соединения, и контент отсутствует - в сокете ничего свеженького не будет, и read выдаст пустую строку. Если соединение говеное, то сокет закрывается, и read выдает nil с причиной. А если URL валидная, то и содержимое будет выдано практически мгновенно, поэтому никаких пустых строк замечено не бывает - либо бывает, но крайне редко. Потому что sleep в опеноси работает через цикл: function os.sleep(timeout) checkArg(1, timeout, "number", "nil") local deadline = computer.uptime() + (timeout or 0) repeat event.pull(deadline - computer.uptime()) until computer.uptime() >= deadline end В твоем случае достаточно спокойно ждать, пока содержимое соединения прочтется - и забить болт на всякие пустые строки. Всяко будет быстрее, чем статичный sleep в каждом запросе

Деление ноля на ноль не сгенерирует ошибку, это NaN. Но вообще - вот так local specialError() -- b не существует local a = b + 10 end local success, reason = xpcall(specialError, debug.traceback, аргументы...) if not success then print("Ошибка", reason) end

@MisterFunny01, так бы и сказал сразу. Ну чо, берешь либо готовую либу для отрисовки пикч, либо пишешь собственную. Далее создаешь пикчи либо в готовом пикчредакторе, либо в самописном, либо вообще по пиксельному массиву, создаваемому напрямую в коде. Далее получаешь список файлов из директории, фильтруешь расширения, и рисуешь пикчи. В чем проблема-то? Данный пример для готовой либы. Как обстоят дела конкретно в твоем случае - я хз. local filesystem = require("filesystem") local image = require("image") local gpu = require("component").gpu local directoryImage = image.load("/Papka.pic") local screenWidth, screenHeight = gpu.getResolution() -- Чистишь вилочкой экран gpu.setBackground(0x0) gpu.fill(1, 1, 160, 50, " ") local path, x, y = "/", 1, 1 -- Пробегаешься по списку дочерених файлов в указанной директории for file in filesystem.list(path) do -- Рисуешь иконку, если это директория if filesystem.isDirectory(path .. file) then image.draw(x, y, directoryImage) end -- Рисуешь текст с именем файла под иконкой gpu.setForeground(0xFFFFFF) gpu.set(x, y + 5, file) -- Определяешь координаты следующей иконки на экране x = x + 10 -- Смещаешься ниже, если иконка зашла слишком "вправо" if x + 10 >= screenWidth then x, y = 1, y + 5 end end

@FelixBanan Дык это, а папки-то у него в каком виде вообще отображаются? Опеносовский ls? Или он хочет софтину для листинга с нуля написать? НиПаНЯяяТна

Рили не понятно, о чем идет речь, прости. Что за папки, в какой софтине - в ls.lua или в какой-то иной? Что подразумевается под иконкой - однопиксельный значок или изображение?

@Teen_Romance, замищательно! Держи тяночку. Она тоже искала идшники в таблицах, но что-то пошло не так...

Ну как где? "pe4[stack.id]" - тут и сравнивает. Если таблица pe4 содержит элемент с ключом, эквивалентным значению поля id таблицы stack, то результатом будет значение элемента таблицы pe4 по требуемому ключу. Да, для того, чтобы ветвь if выполнилась, все условные элементы должны отличаться от nil. И нет, первая часть условия далеко не всегда будет истинна: если требуемый слот не содержит предметов, то переменная stack будет иметь значение nil. Для работы программы нужно банально пробежаться по всем слотам сундука, проверить, есть ли что-либо в слоте - и если есть, то проверить, является ли id предмета в слоте валидным (т.е. содержится ли он в таблице pe4). По крайней мере, я именно так понял условие задачи.

Это просто более удобный и быстрый вариант проверки наличия id предмета из сундука в твоей таблице pe4. Можно, конечно, делать сие через цикл - но зачем? Ключом элемента таблицы может быть что угодно: хоть число, хоть строка, хоть функция, хоть таблица - это уж как тебе удобно. Просто если поле id у предмета - это "minecraft:cobblestone", то и таблица pe4 для корректного поиска должна выглядеть соответствующе: pe4 = { ["minecraft:cobblestone"] = true, ["minecraft:wood"] = true, } А конструкция "if stack and pe4[stack.id]" работает именно так, как ты и предположил - сначала проверяет наличие предмета в слоте, а затем уже сверяет id с твоей таблицей

Мяу, ну написали же русским языком, что getStackInSlot(номер слота) возвращает таблицу с информацией о предмете, если таковой имеется в слоте - либо nil в том случае, если слот пустой, для чего и нужна проверка на "пустотность". Шаг 1. Получил инфу о предмете в слоте stack = getStackInSlot(i) Шаг 2. Убедился, что в слоте есть предмет if stack then Шаг 3. Обработал информацию о предмете в слоте так, как требуется. НЕ НУЖНО вызывать getStackInSlot() еще раз. Переменная stack уже хранит результат вызова getStackInSlot() if stack.id == 8 then Конкретно в твоем случае ошибка происходит по той причине, что getStackInSlot возвращает nil, а ты пытаешься получить поле от возвращаемых данных по ключу id - вот и получаешь ошибку attempt to index a nil value. Слот пустой, id не существует. Делай проверку разово - и работай с переменной stack. Также я не совсем понимаю, почему ты используешь два цикла for i = 1, 10 / for j = 1, 10, когда число предметов в ME-сети явно может превышать 100. Наверняка там должен иметься метод getInventorySize, или getItemCount, или еще какой-то схожий - используй его. И еще: для сравнения id предметов с таблицей pe4 также придется делать отдельную логику. Что-то наподобие: local pe4 = { [1] = "камушек", [8] = "доски" } ... stack = cry.getStackInSlot(i) if stack and pe4[stack.id] then print("рассматривается валидный предмет") end Кроме того, как заметил @Asior, мы понятия не имеем, что это за компонент такой под названием "crystal". Так что если выяснится, что информация о его stack'ах вообще не содержит никаких id, либо его id является строковым наподобие "minecraft:stone" - то тут уж ты сам виноват. ПоДуМоЙ

@Teen_Romance, local stack for i = 1, 10 do stack = cry.getStackInSlot(i) if stack then -- Делай чо надобно end end

@MisterFunny01, что значит "выделить только папки"? Ты же выше писал, что нужно отображение иконок вместе с именем файла, а теперь про выделение какое-то. Нипанятна! Но если что, папку от файла можно отличить через print(filesystem.isDirectory("/MyFile.lua")) > false А расширение файла можно получить через регулярку local name = "MyFile.lua" print(name:match("[^%/]+(%.[^%/]+)%/?$")) > .lua