Перейти к содержимому

ECS

Гуру
  • Публикации

    290
  • Зарегистрирован

  • Посещение

  • Победитель дней

    109

Все публикации пользователя ECS

  1. Деление ноля на ноль не сгенерирует ошибку, это NaN. Но вообще - вот так local specialError() -- b не существует local a = b + 10 end local success, reason = xpcall(specialError, debug.traceback, аргументы...) if not success then print("Ошибка", reason) end
  2. @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
  3. @FelixBanan Дык это, а папки-то у него в каком виде вообще отображаются? Опеносовский ls? Или он хочет софтину для листинга с нуля написать? НиПаНЯяяТна
  4. Рили не понятно, о чем идет речь, прости. Что за папки, в какой софтине - в ls.lua или в какой-то иной? Что подразумевается под иконкой - однопиксельный значок или изображение?
  5. @Teen_Romance, замищательно! Держи тяночку. Она тоже искала идшники в таблицах, но что-то пошло не так...
  6. Ну как где? "pe4[stack.id]" - тут и сравнивает. Если таблица pe4 содержит элемент с ключом, эквивалентным значению поля id таблицы stack, то результатом будет значение элемента таблицы pe4 по требуемому ключу. Да, для того, чтобы ветвь if выполнилась, все условные элементы должны отличаться от nil. И нет, первая часть условия далеко не всегда будет истинна: если требуемый слот не содержит предметов, то переменная stack будет иметь значение nil. Для работы программы нужно банально пробежаться по всем слотам сундука, проверить, есть ли что-либо в слоте - и если есть, то проверить, является ли id предмета в слоте валидным (т.е. содержится ли он в таблице pe4). По крайней мере, я именно так понял условие задачи.
  7. Это просто более удобный и быстрый вариант проверки наличия id предмета из сундука в твоей таблице pe4. Можно, конечно, делать сие через цикл - но зачем? Ключом элемента таблицы может быть что угодно: хоть число, хоть строка, хоть функция, хоть таблица - это уж как тебе удобно. Просто если поле id у предмета - это "minecraft:cobblestone", то и таблица pe4 для корректного поиска должна выглядеть соответствующе: pe4 = { ["minecraft:cobblestone"] = true, ["minecraft:wood"] = true, } А конструкция "if stack and pe4[stack.id]" работает именно так, как ты и предположил - сначала проверяет наличие предмета в слоте, а затем уже сверяет id с твоей таблицей
  8. Мяу, ну написали же русским языком, что 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" - то тут уж ты сам виноват. ПоДуМоЙ
  9. @Teen_Romance, local stack for i = 1, 10 do stack = cry.getStackInSlot(i) if stack then -- Делай чо надобно end end
  10. @MisterFunny01, что значит "выделить только папки"? Ты же выше писал, что нужно отображение иконок вместе с именем файла, а теперь про выделение какое-то. Нипанятна! Но если что, папку от файла можно отличить через print(filesystem.isDirectory("/MyFile.lua")) > false А расширение файла можно получить через регулярку local name = "MyFile.lua" print(name:match("[^%/]+(%.[^%/]+)%/?$")) > .lua
  11. Приятное обновление для проводника: добавлен табличный режим отображения списка файлов со всеми вытекающими фичами. Как мне кажется, для небольших размеров окна этот вариант более практичен в плане удобства навигации
  12. @Sneeex Разве что отключить обои, это основная статья расходов оперативы: примерно под 200 Кбайт жрут в зависимости от графонистости. К примеру, у меня после их отключения оператива загружается лишь на 44%: Еще можно в настройках активировать выгрузку неиспользуемых библиотек и отключить отрисовку иконок приложений - тогда расход останется на ~30%. Ну, и еще можно поставить серверную стойку на 4 планки оперативы 3.5 уровня - тогда все уж точно будет в шоколаде
  13. @ProShow, спасибо, фиксанул. Увы, теперь это чисто майносовская прошивка с возможностью запуска опеноси - т.е. фича internet recovery будет ставить майнось вместо запуска скрипта по URL. Ну что ж... ¯\_(ツ)_/¯
  14. @MisterFunny01, если речь о майноси, то индивидуально для каждого файла - никак. Иконки можно кастомизировать у приложений, а потом уже назначать ассоциации расширений файлов для открытия выбранным приложением. Конкретнее - смотри содержимое приложухи MineCode IDE.app, там как раз добавлены кастомные иконки и контекстное меню для .cfg/.txt/.lua, да и вообще довольно очевидно все
  15. @redknowy, насчет туторов хз, а вот вики есть. Даже ссылка на нее в README репозитория валяется. Там тебе и интерфейс, и интеграция окон, и ваще все: https://github.com/IgorTimofeev/MineOS/wiki
  16. Тут на днях обновленная софтина Multiscreen в маркет затесалась - добавлена группировка по цветам для гораздо более быстрой отрисовки жирных пикч. Правда, чем жирнее пикча, тем дольше будет обрабатываться каждый моник, но и это уже заметный прогресс:
  17. @BrightYC Ну блин, теперь опять иссуи кидать будут. Хоть бы кто кисика прислал :((9
  18. Вообще, если вкратце - то нет, почти что нельзя. Это плюсы комбинятся с луа-машиной посредством C-API/LuaBridge, а не наоборот. Опенкомпы, конечно, позволяют создавать собственные архитектуры в виде аддонов, и тому даже имеется несколько примеров, но вряд ли кто-то озаботится плюсами, мяу
  19. ECS

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

    @Kimapr, ограничений по скорости работы на данный момент нет, но если нужен реализм по сравнению с опенкомпами - то добавлю, говно вопрос. А повтор клавиш прямо сейчас запилил, пасебо за наводочку @Asior, угу, сокетовый код сыроват. Но вообще гоу инфу по используемой ирке - опеносовская или какая? Специально даже затестил и (вроде бы) без проблем зашел:
  20. @Totoro зараза! Ну что ж... вряд ли автор объявится, так что пусть она будет Тоторина, ибо так велит мой бог, нашептывая на ушко. Касаемо оси: кардинально переработана система полноэкранных приложений. При активации режима полного экрана для каждого окна полностью отключается весь интерфейс, за исключением верхней менюхи. Таким образом в полноэкранном режиме приложения пашут с той же скоростью, как если бы они были не зависимы от ОСи. А еще добавлена клевая анимация изменения размеров окон:
  21. Угу, угу. Если на вход load подать строку, в которой нет синтаксических ошибок, эта строка скомпилится и вернется в виде функции, которую можно вызвать когда пожелаешь. Если были ошибки, возвращается nil и инфа об этих ошибках. С load еще связано множество приколюх, но для данной задачи достаточно простой загрузки кода
  22. Ну что ж. Буквально на днях майнось наконец релизнулась в виде полностью самостоятельной и независимой от OpenOS операционки с собственным набором библиотек и вики. Все родное, отечественное (звучит как диагноз). Большинство методов библиотек по типу filesystem или keyboard крайне схожи с таковыми в опеноси по поведению, так что особых проблем с переходом возникать не должно. Также существенно снизился расход оперативной памяти - примерно на 7% от 4 планок 3 уровня. Осталось, конечно, регулярно выискивать мелкие недочеты и допиливать их, а также более подробно наполнять инфу на вики, но в целом результатом я доволен. Среди ключевых нововведений стоит отметить следующие: Полностью переписанный инсталлер, запускающийся даже с EEPROM, имеющий возможность выбора тома для установки и его форматирования, а также систему конфигурации пользовательского профиля. Добавлено несколько системных языков, а заодно возможность установки лишь выбранного языкового пакета вместо всех сразу для экономии места на диске: Полная двойная буферизация графики, все приложения переписаны под библиотеку GUI. Кстати, местный картинко-редактор заимел оконный режим, а также Ёлочка @Totoro стала отлично работать в фоне и украшать хату (в моем случае - жалкий клочок земли в воздухе): Крайне полезный режим Internet Recovery, позволяющий мгновенно переустановить систему напрямую из EEPROM в случае возникновения каких-либо проблем: Возможность заливки файлов напрямую на Pastebin буквально парой кликов: Фича создания ассоциаций расширений файлов с возможностью назначения приложения для открытия того или иного расширения:
  23. Здесь ключ - это не число, а таблица с уникальным адресом. По факту для подобного даже рандом не нужен, можно было вообще возвращать пустую таблицу или функцию, служащую идентификатором для разблокировки. А поскольку debug в опенкомпах крайне лимитирован, и доступа к локальным переменным нет, то и выпотрошить весь стек оперативы в поисках ключа для брутфорса не получится.
  24. Если используется OpenOS. Все четыре варианта более-менее схожи: require("shell").execute("/Test.lua") os.execute("/Test.lua") dofile("/Test.lua") -- Более детальное решение с безопасным запуском файла и отлавливанием всех ошибок с подробной информацией local result, reason = loadfile("/Test.lua") if result then result, reason = xpcall(result, debug.traceback) if result then -- Все замищательно else print("Не удалось выполнить файл: ", reason) end else print("Не удалось загрузить файл: ", reason) end Если используются "чистые" опенкомпы на микроконтроллере или попросту с EEPROM: local filesystem = component.proxy(component.list("filesystem")()) -- Читаем файл напрямую с диска local handle = filesystem.open("/Test.lua", "rb") local data, chunk = "" repeat chunk = filesystem.read(handle, 4096) data = data .. (chunk or "") until not chunk filesystem.close(handle) -- Выполняем прочитанный исходный код local result, reason = load(data) if result then result, reason = xpcall(result, debug.traceback) if result then -- Усе в порядке, файл выполнен else -- Ошибка при выполнении загруженного скрипта end else -- Ошибка при загрузке текстовых данных в качестве кода end
  25. @SkinnerDE, пардон, я на ходу писал, myImage можно в расчет не брать. Главное принцип, дыа. MyImage в данном случае - это ссылка на объект изображения, передаваемая в обработчик событий для удобства, называть переменные можно как угодно. Для ясности код приведу: local function myEventHandler(application, objectPointer, e1, e2, e3, ...) -- Ох уж эти события end -- Переменная object и objectPointer из обработчика событий - это один тот же объект object.eventHandler = myEventHandler Аналогичный функционал, кстати, можно запилить и средствами event.timer, однако так куда проще, да и отменять таймеры впоследствии не придется.
×
×
  • Создать...