ECS

@TurboPointbus300 боюсь, она умерла.............. 💀⚰️⚱️

Прости, мы сочли священным долгом отпентестить сей шедевр. Уязвимостей не обнаружено, комиссия ставит 10/10 на кончиках пальцев

Да, пару лет назад снесли аккаунт. Исходников инсталлера нет, библиотека забыта, саппорта не будет, репозиторий в архиве, писать заново лень. Так что придётся самому

Новогодний интерфейсный марафет: Осовременена большая часть системных иконок, заимев мягкие оттенки и скругления Добавлен предпросмотр небольших изображений, что упрощает работу с ассетами Добавлен общий элемент верхнего меню, позволяющий быстро выключить/перезагрузить/обновить систему. Как и в, кхм, прародителе майноськи, он всегда остаётся видим при переключении между приложениями Уменьшен размер нижнего дока, дабы экономить вертикальное пространство Добавлена поддержка иконок для контекстных меню, которые к тому же стали крупнее и читабельнее Добавлена поддержка "живых обоев", позволяющая нативно ренедрить графику любой сложности. Они неплохо сочетаются со слабыми ПК, т.к. не расходуют ОЗУ на хранение пиксельных данных и выглядят вполне симпатично

Коллекция штатных приложений пополнилась аудиофильской репликой Pioneer CDJ-2000 nexus с функционалом, близким к оригиналу - насколько позволяет мод, разумеется: Поддержка нескольких кассет, играющих параллельно Cue и Loop-метки с банком памяти и горячими вызовами Навигация по треку через джог, needle search bar или кнопки fov/rew Регулировка темпа и громкости фейдерами и кнобами Подстройка чувствительности элементов управления Визуализация длительности трека, текущей позиции или остатка Запись композиций на кассету с HDD и URL Скевоморфный UI с подсветкой и имитацией питания от сети В обозримом будущем хотелось бы заиметь анализ трека с построением пиков, определением "бочек" и квантованием меток, однако это потребует специфичных скиллов, нудного гугления всяких PCM, IFT, DFPWM и т.п., поэтому пока что и так сойдёт)0

@ZKoshak увы, нет, т.к. на Wayback Machine оно не трекнулось, а исходников в истории коммитов на гитхабе от 02.05.18 тоже не нашлось. Видимо, я их вообще не заливал никуда, кроме пастбина

Ну, тогда смерть. Можешь попробовать "ПКМ - создать приложение", система сгенерит шаблонный .app, где как раз реализована поддержка меню. Если оно там будет работать - то ищи ошибку у себя, а если нет - надо думать дальше. Без фулл сырцов трудно что-то сказать

В нормальных условиях меню может не вернуться в двух случаях: 1) Когда окно форсированно игнорирует добавление в док и меню, т.е. system.addWindow(window, [addToDockAndMenu = false]). Обычно этот параметр используется для утилитарных окон, например, при ПКМ на файле -> Properties. Но, судя по всему, это не твой случай 2) Когда ты добавляешь окно в воркспейс системы не из Name.app/Main.lua, а из внешнего скрипта, загруженного через loadfile/dofile/readfile - это захардкожено вот тут. Система пытается получить путь к директории приложения, чтобы адекватно визуализировать иконку и имя в доке и в меню, но не может т.к. внешние файлы не считаются приложениями. Поэтому добавление в меню и док скипается Собственно, выход один: добавлять окно в основном скрипте приложения. Ещё было бы разумно доработать анализ пути исполняемого скрипта, чтобы искать последнее вхождение .app/ и не создавать анальных ограничений. Ну или хотя бы кидать ошибку, мол, "ай-ай-ай, так нельзя". Но лень хд

Ну дык склей эти 2 байта через byte1 << 8 | byte2 Ту же самую - никак, библиотека unicode не имеет функции codepoint. Поэтому приходится довольствоваться string.char/string.byte и комбинировать их с unicode.char

Из символа в байты: local char = unicode.char(128) local bytes = {char:byte(1, #char)} print(table.unpack(bytes)) > 194 128 Из байтов в символ: local bytes = {194, 128} local char = string.char(table.unpack(bytes)) print(char) > ┬А -- unicode.char(128)

Чтобы что-то закрыть, нужно сперва это что-то открыть. Компонентный вызов open() возвращает дескриптор файла, а APIшный - буферизированный поток, и работа с ними отличается: local filesystemAPI = require("filesystem") local filesystemComponent = require("component").filesystem -- API local stream = filesystemAPI.open("/test.lua", "w") stream:write("Hello world") stream:close() -- Компонент local handle = filesystemComponent.open("/test.lua", "w") filesystemComponent.write(handle, "Hello world") filesystemComponent.close(handle) И вообще не по каждой же строчке кода пинговать форумчан, давай сам думай. Наверняка там ошибка наподобие attempt to call a nil value (field 'close'), означающая, что в filesystem API не существует метода close()

Рекомендую следовать инструкциям не из комментов, а из официальной вики или готового софта - так будет существенно меньше проблем При работе с дисками напрямую из директории игрового сейва пересчёт spaceUsed не производится. Для быстрого пересчёта необходимо вызвать filesystem.close(), т.к. это единственный метод, который его инициирует напрямую. Вероятно, пересчёт также должен осуществиться, если вытащить и вставить диск в ПК, но это не точная инфа, надо курить поведение мода и принципы реинициализации компонентов Если интересны подробности, то причина такого поведения в дороговизне вычисления размера директории, к которой привязан диск - оно выполняется рекурсивно, суммируя размеры всех файлов во всех дочерних директориях. Мод частично решает эту проблему, кешируя значение spaceUsed однократно при инициализации компонента. Затем при любой операции над файлом, когда его размер предсказуем, кешированное значение изменяется без потребности в пересчёте с нуля Уточню, что при "естественном" обращении к диску эта проблема вообще никогда не возникнет, т.к. мод выполняет всю работу по пересчёту самостоятельно

Я одного не пойму: почему тебя так зацепило это явление, неужели оно создаёт настолько серьёзные проблемы? Ведь и в повседневной жизни, и в разговорной речи встречаются омонимы - ключ/лук/мат/лист/коса/каток и прочие. К ним у тебя такое же радикальное отношение или, может быть, это всё же дело привычки? Если взять пример из области кодинга, то в большинстве языков программирования имеется концепция пространств имён, разграничивающих доступ к классам с одинаковыми названиями: в том же .NET имеются System.Windows.Media.Color и System.Drawing.Color. Какой using укажешь - такой класс и будет использован. Схожая путаница возникает между java.nio.file и java.io.file. Эт норма))0

Аналогичная история с компонентами internet/computer/robot и одноимёнными библиотеками. Это скорее систематика и фича, нежели однократная проблема нейминга Вообще с одной стороны ты прав, и путаница имеет место быть. А с другой - наверняка нашлись бы недовольные альтернативной реализацией, дескать, "А чо у вас компонент зовётся filesystem, а API disksystem? Дискеты - ето уже диски? Сложна!1"