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

ECS

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

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

  • Посещение

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

    203

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

  1. Заметил, что дефолтный EEPROM (который Lua BIOS) выставлен в режим ReadOnly. В игровых опенкомпах он доступен для перезаписи
  2. Ой, как мило:3 Забирай себе, если хочется, не жалко ж
  3. @Totoro Да, было такое, он в 3D-технодемке рендерился, т.к. движок назывался MeowEngine. А так логотипа нет, так же как и фантазии(
  4. Да, такая приложуха существовала, но она выдавала не столь подробную информацию, как твое творение. То есть без данных о "производителе" компонентов, без цветовых палитр и прочих вкусностей, лишь базовую инфу
  5. @Kolya Нет его уже давно. API обновились, инсталлеры сдохли. Если инфопанели нет в маркете - то её считай нет совсем
  6. @Ivanuza В самой майноське из штатных средств существует только передача файлов по модемам. Да и что значит "зря делаю"? Если тебе это интересно и доставляет удовольствие, то ничто не зря
  7. Пардон, мой косяк. Не указал, что в регулярке нужно юзать шестнадцатеричную систему: str:gsub("\\u([a-fA-F%d]+)", function(code) return unicode.char(tonumber(code, 16)) end) Проверил в кубаче, всё пашет:
  8. Проверил raw-ответ через сокет. API дискорда отдаёт сразу экранированные символы, либы опенкомпов тут ни при чём. Видимо, постман (как и ARC, кстати) сам их декодирует в русский эквивалент, из-за чего возникло подозрение на опенкомпы: Значит, решение с регуляркой остаётся верным. Или нужно модифицировать JSON-либу соответственным образом, но всё равно используя ручной декодинг
  9. С чем? Судя по скринам, парсинг абсолютно корректен
  10. О, это уже интересно. Наверняка json-либа при конвертации в луа-таблицу автоматом эскейпит символы, либо как-то по-своему обрезает экранированный результат от API. Если дело в ней, то сменить либу не будет проблемой. К примеру, с этой проблем не возникало
  11. В том и проблема. Обычно подобные вещи экранируются редко встречающимися в повседневном общении комбинациями символов (по типу эмодзи 😀 у ВК). Тут вообще жесть какая-то. Мб у дискорда есть иные опции по экранированию юникода - эт уже вопрос к топикстартеру, ибо у него по ТЗ идет только uКод. Ну и ответ я дал соответственный
  12. Вот уроды, а. Никакой стандартизации(
  13. Так а чо, пройдись регуляркой по этой стринге, и всё: str = "Meow u0422u0435" str = str:gsub("u(%d+)", function(code) return utf8.char(tonumber(code, 16)) end) -- Meow Te Если дискордыч всегда выдаёт 4 знака после "u", то разумнее будет воспользоваться паттерном "u(%d%d%d%d)" для более корректного декодирования ситуаций, когда после экранируемой последовательности следует обычная цифра, не входящая в неё. Например, "Meow u042215" (где 15 - просто текст)
  14. ECS

    Filesystem & MineOS

    О, забавно. Видимо, этой копией была локальная папка с именем в виде адреса дискеты на загрузочном диске в папке Mounts. И, видимо, поэтому система её как-то неадекватно обрабатывала
  15. ECS

    Filesystem & MineOS

    Вполне возможно, что проявился бажок оськи. Хотя я без проблем записал файл на дискету по адресу следующим образом: local fs = require("Filesystem") for proxy, path in fs.mounts() do -- В моем случае адрес компонента дискеты стартует с "1c5e3" if proxy.address:sub(1, 5) == "1c5e3" then fs.write(path .. "test.lua", "Hehe") break end end -- Либо если известен полный адрес компонента, то local paths = require("Paths") fs.write(paths.system.mounts .. address .. "test.lua", "Hehe") При этом никаких дубликатов компонента в проводнике при копипастинге этого же файла, при удалении и редактировании не наблюдаю. Можно лишь гадать на кофейной гуще, что идёт не так. Может быть, дискета была сдублирована в креативе?
  16. @FireAid если всё так, как заметил @hohserg, то это вряд ли осуществимо: майноська имеет свой набор тараканов в API, хоть и схожих, но всё же отличных от опеносовских. Само терминальное приложение сделать проблем не составит, накидать набор базовых шелл-скриптов по типу ls/rm/mkdir тоже. Однако запускать опеносовские скрипты, использующие специфичные либы по типу term/tty/thread это не позволит, ибо майноська банально имеет иную архитектуру. Я, если честно, вообще бы не парился и юзал дальше опеносевские либы в качестве "первоосновы" для графической оболочки, как это было изначально, - но дико задолбался пилить "обходные пути" для изменений, вносимых в каждую новую версию мода. Вот тут-то и разошлись тернистые пути двух осей, когда стало проще написать основу самому, чем работать с чужой
  17. Хех, не забудь ещё заменить все иконки на гендерно-нейтральные - чтобы, к примеру, розовый фон файлов локализаций не вызывал сексистских ассоциаций с женским полом
  18. Эх, вот бы сюда сочный protected для подклассов... И костыляешь что хочешь, и либа целёхонькая
  19. Я не про do ... end, а про __. Дело привычки, видимо. Крайне сложно принять факт наличия публичных полей, которые "эстетически" помечены приватными в ООП-системе. Я бы их тогда в сам объект вовсе не вносил, оставляя реализацию в виде локальных функций в начале скрипта. Впрочем, либа твоя, хозяин-барин, мяу
  20. А, понятно, это имеет смысл. Переписывать никто не требует, олдфаги всё поймут, а нубасы пусть курят основы хв Ну почему же? Возьмем элементарный код: local function meow(self) print(self.abc) end local function newObject() return { abc = 123, meow = meow } end local function meowOverriden(self) if self.condition then meow(self) else print("Not condition") end end local function newObjectExtended() local self = newObject() self.condition = true self.meow = meowOverriden return self end Объекты? Есть. Наследование? Есть. Переопределение методов? Есть. Метатаблицы? Да на фиг не нужны. Этот код - такая же отсебятина и дело уже моей привычки. Я хотел обратить внимание не на метод реализации ООП (ибо все пишут как привыкли), а на его избыточную сложность для гайда: если уж делаешь библиотеку, использующую "железный занавес" для приватных членов через метатаблицы, то, как мне кажется, они должны быть полностью приватны для отдельно взятого класса. Чтобы, к примеру, нельзя было творить вот такую грязь: local client = stem.newClient(...) client.__opcodes[0] = "hehe" client.__craftPacket(...) Это же в корне ломает концепцию приватности, позволяя потрошить либу как душе угодно. Пофиг ли на это? Конечно пофиг. Но зачем тогда усложнять изящную либу и делать приватные члены? А если усложняешь, то почему не используешь полное экранирование с внутренним использованием rawget?
  21. Гайд по самой плате более чем достойный, однако начиная с пункта 4 он будет полностью понятен лишь человеку, уже знакомому с луа/опенкомпами и работавшему с платой. Новичков отпугнёт. Поясню претензию: Во-первых, какое, блин, ООП? В чтении/записи в сокет функционала кот наплакал, и реализовать его процедурным подходом можно в разы проще и доступнее для понимания. Ты гайд пишешь или состязаешься с читателем? Со стороны это выглядит так: а давайте-ка, детишки, напишем объектную систему для мульти-соединений с сервером по всем канонам. А потом... будем использовать лишь ОДНО во фронтенде! *ba dum tss* Во-вторых, "привычно" для кого, для Fingercomp'а? В луа не имеется общепринятых конвенций по реализации объектов. Метатаблицы и приватные члены - это, безусловно, интересный подход, однако тут я бы задал себе несколько вопросов в порядке убывания приоритетности: Будет ли он быстрее работать и расходовать меньше ресурсов? Нужен ли он для клиента, использующего только 1 соединение с сервером? Будет ли он проще в реализации? Будет ли он понятнее в виде гайда для людей, впервые работающих с интернет-платой и луа в целом? Имхо, ответом на каждый из них будет "нет". Вытекающий вопрос "зачем, господи?" висит мёртвым грузом...
  22. Отлично пашет, за полчаса ковыряния нашёл всего лишь два явных бага: Нет реакции на скроллинг мышью. В списке ивентов через dmesg не высвечивается Некорректно работает computer.maxEnergy(), возвращая math.huge вместо фикисированного числа. В нативных опенкомпах при отключенном поглощении энергии в конфиге (или при отсутствии энерго-модов) функция всегда возвращала 500 Еще было бы крайне приятно, если бы окошечки экранов можно было ресайзить, т.к. более 2х виртуальных экранов даже на WQHD-монитор не влезет. В идеале - вообще группировать их с изменением масштаба в автоматическом режиме плитками а-ля Snap Assist. Но это жир
  23. О, тогда уважение. Терпению хардвейщиков поём мы песню
  24. @LeshaInc, а на чём реализована гуя? Что является основной для кастомных виджетов? Жабафх/скалафх, опенгл или мяу?
  25. Забавно, тут уж бох в помощь. Интересно, на опеноси та же ерунда или же они замутили принудительное экранирование для "некорректных" символов в составных частях путей?
×
×
  • Создать...