Перейти к публикации

В ближайшее время постараюсь разобраться с картой сервера/ЛК/бб кодами

Внимание, с 14 февраля до 20 февраля могут проходить работы на сервере, где также находится лаунчсервер. В связи с этим авторизация в лаунчере может не работать

ECS

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

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

  • Посещение

  • Дней в лидерах

    99

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

  1. Раз уж на форуме появился специализированный раздел, посвященный операционным системам, то грех не выложить свою. Сама система является графической оболочкой к дефолтной OpenOS со множеством собственных библиотек, основной упор при ее написании делался на визуальную составляющую и общее быстродействие. Ключевые особенности: Многозадачность Оконный интерфейс с двойной буферизацией графики Поддержка анимаций, обоев, заставок и цветовых схем Поддержка языковых пакетов и локализации ПО Поддержка авторизации пользователя по паролю и биометрике Поддержка обмена файлами по локальной сети через модемы Поддержка клиентского подключения к реальным FTP-серверам Система отчетов об ошибках с возможностью отправки информации разработчикам Магазин приложений с возможностью публикации собственных творений и системой пользовательских рейтингов Интегрированная IDE с отладчиком и значительное количество разнообразного прикладного ПО Открытое системное API и подробная иллюстрированная документация к библиотекам Собственная прошивка EEPROM с возможностью выбора/форматирования загрузочного тома и восстановлением через интернет Полная совместимость с OpenOS-софтом Установка: Для запуска инсталлера введите следующую команду: pastebin run 0nm5b1juПеред вами появится симпатичный интерфейс, где вы сможете выбрать параметры установки: к примеру, загружать ли все имеющиеся приложения, либо оставить только системные, а также загружать ли обои рабочего стола. Лицензионное соглашение шуточное, всерьез можно не воспринимать. Исходники: https://github.com/IgorTimofeev/MineOS Люди, прямо или косвенно участвовавшие в разработке: Тимофеев Игорь - рефакторинг, оптимизация и вылизывание кода Трифонов Глеб - разработчик формата изображений OCIF и методов цветовой обработки Веревкин Яков - консультант по вопросам векторно-матричных преобразований Шестаков Тимофей - специалист по UI/UX-дилеммам Смирнов Алексей - тестировщик ПО Богушевич Виктория - синтаксический корректировщик и отвлекающий фактор Витвицкая Яна - позитивистский мотиватор и не менее отвлекающий фактор Какой-то Андрей - эксперт в области оценки красоты кода Ярычев Никита - компаньон в обсуждениях философских нюансов Пакин Максим - автор нескольких приложений Тиунов Дмитрий - консультант по нюансам веб-запросов Маяковский Константин - товарищ со уникальным духовно-пофигистическим характером Сазонов Слава - автор пары оптимизационных моментов и любитель кратких диалогов Омелаенко Максим - анализатор рынка ПО и конкурентных решений Просин Михаил - генератор мотивации по генерации идей по улучшению ПО Чернышева Дарья - моральная поддержка команды Палиев Егор - очень хотел в этот список
  2. ECS

    MineOS

    @redknowy, насчет туторов хз, а вот вики есть. Даже ссылка на нее в README репозитория валяется. Там тебе и интерфейс, и интеграция окон, и ваще все: https://github.com/IgorTimofeev/MineOS/wiki
  3. ECS

    MineOS

    Тут на днях обновленная софтина Multiscreen в маркет затесалась - добавлена группировка по цветам для гораздо более быстрой отрисовки жирных пикч. Правда, чем жирнее пикча, тем дольше будет обрабатываться каждый моник, но и это уже заметный прогресс:
  4. ECS

    MineOS

    @BrightYC Спасибо, золотце.
  5. ECS

    MineOS

    @BrightYC Ну блин, теперь опять иссуи кидать будут. Хоть бы кто кисика прислал :((9
  6. Вообще, если вкратце - то нет, почти что нельзя. Это плюсы комбинятся с луа-машиной посредством C-API/LuaBridge, а не наоборот. Опенкомпы, конечно, позволяют создавать собственные архитектуры в виде аддонов, и тому даже имеется несколько примеров, но вряд ли кто-то озаботится плюсами, мяу
  7. ECS

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

    Еще мой дед говаривал, что каждый кодер на ОС просто обязан начать писать собственный эмуль для самоутверждения. Не желая изменять семейным ценностям, я тоже окунулся с головой в эту клоаку. Вообще в существующих эмуляторах лично меня люто бесит возня с ручной компиляцией, докачиванием всяческих либ по типу openssl, а также отсутствие возможности запуска нескольких виртуальных компиков в едином пространстве с масштабированием экранов, не говоря уже про пересылку данных между ними посредством не менее виртуальных модемов. Поэтому почесав репу, собрав JavaFX + LuaJ, накатав несколько компонентов, на данный момент я заимел следующие зачатки проекта: Библиотеки computer, component, unicode Компоненты computer, eeprom, filesystem, gpu, modem, screen, keyboard Имитация системных сигналов по типу touch/drag/drop/key_down/key_up/scroll/modem_message с поддержкой pullSignal/pushSignal Пересылка сетевых пакетов между имеющимися машинами в рабочем пространстве через modem.send/broadcast BSOD для "unrecoverable error" Звуковая система а-ля "комп в мире кубача", имитирующая звуки доступа к диску, и прикольно шумящая на фоне для антуража Создание/сохранение/загрузка виртуальных машин с сериализацией данных имеющихся компонентов. Ну, всяких там адресов, разрешений видях, размеров, координат и т.п. Кнопочка включения (!) Разумеется, компоненты имеют далеко не все методы, их написание - дело долгосрочное. Но поскольку этот раздел называется блогом, то, кажется, никто не мешает мне писать о запланированном. В идеале хочу замутить компоненты internet, tunnel и data, позволить юзерам выбирать пути к прошивке виртуального EEPROM и содержимому жесткого диска. Также остается открытым вопрос о лимитировании памяти: я понятия не имею, как это реализовать на LuaJ и ублюдочной Яве без обожаемого sizeof(). Городить костыли в виде JavaAgent + Instrumentation.getObjectSize не хочется, но, видимо, придется. Ну, и если у кого-то имеются занятные предложения по функционалу софтины - буду рад. Сырцы: https://github.com/IgorTimofeev/OpenComputersVM Скриншотик:
  8. ECS

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

    @Kimapr, ограничений по скорости работы на данный момент нет, но если нужен реализм по сравнению с опенкомпами - то добавлю, говно вопрос. А повтор клавиш прямо сейчас запилил, пасебо за наводочку @Asior, угу, сокетовый код сыроват. Но вообще гоу инфу по используемой ирке - опеносовская или какая? Специально даже затестил и (вроде бы) без проблем зашел:
  9. ECS

    MineOS

    @Totoro зараза! Ну что ж... вряд ли автор объявится, так что пусть она будет Тоторина, ибо так велит мой бог, нашептывая на ушко. Касаемо оси: кардинально переработана система полноэкранных приложений. При активации режима полного экрана для каждого окна полностью отключается весь интерфейс, за исключением верхней менюхи. Таким образом в полноэкранном режиме приложения пашут с той же скоростью, как если бы они были не зависимы от ОСи. А еще добавлена клевая анимация изменения размеров окон:
  10. Угу, угу. Если на вход load подать строку, в которой нет синтаксических ошибок, эта строка скомпилится и вернется в виде функции, которую можно вызвать когда пожелаешь. Если были ошибки, возвращается nil и инфа об этих ошибках. С load еще связано множество приколюх, но для данной задачи достаточно простой загрузки кода
  11. ECS

    MineOS

    Ну что ж. Буквально на днях майнось наконец релизнулась в виде полностью самостоятельной и независимой от OpenOS операционки с собственным набором библиотек и вики. Все родное, отечественное (звучит как диагноз). Большинство методов библиотек по типу filesystem или keyboard крайне схожи с таковыми в опеноси по поведению, так что особых проблем с переходом возникать не должно. Также существенно снизился расход оперативной памяти - примерно на 7% от 4 планок 3 уровня. Осталось, конечно, регулярно выискивать мелкие недочеты и допиливать их, а также более подробно наполнять инфу на вики, но в целом результатом я доволен. Среди ключевых нововведений стоит отметить следующие: Полностью переписанный инсталлер, запускающийся даже с EEPROM, имеющий возможность выбора тома для установки и его форматирования, а также систему конфигурации пользовательского профиля. Добавлено несколько системных языков, а заодно возможность установки лишь выбранного языкового пакета вместо всех сразу для экономии места на диске: Система профилей пользователей с сегрегацией рабочих директорий. По сути каждый пользователь имеет собственный рабочий стол, собственные приложения, документы, настройки и так далее, а также возможность защиты паролем. Конечно, любая защита на опенкомпах не имеет смысла по определению, но она есть!111 Полная двойная буферизация графики, все приложения переписаны под библиотеку GUI. Кстати, местный картинко-редактор заимел оконный режим, а также Ёлочка @Totoro стала отлично работать в фоне и украшать хату (в моем случае - жалкий клочок земли в воздухе): Крайне полезный режим Internet Recovery, позволяющий мгновенно переустановить систему напрямую из EEPROM в случае возникновения каких-либо проблем: Возможность заливки файлов напрямую на Pastebin буквально парой кликов: Фича создания ассоциаций расширений файлов с возможностью назначения приложения для открытия того или иного расширения:
  12. ECS

    Защитник таблиц: tprotect

    Здесь ключ - это не число, а таблица с уникальным адресом. По факту для подобного даже рандом не нужен, можно было вообще возвращать пустую таблицу или функцию, служащую идентификатором для разблокировки. А поскольку debug в опенкомпах крайне лимитирован, и доступа к локальным переменным нет, то и выпотрошить весь стек оперативы в поисках ключа для брутфорса не получится.
  13. Если используется 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
  14. Хочу поделится с вами своей библиотекой, которую использую практически в каждой программе с графическим интерфейсом. С ее помощью можно генерировать любые "окна" на свой вкус, работать с ними, а затем получать результат работы в обычном массиве. Cкачать библиотеку: pastebin get wtWVFpKZ lib/windows.lua Подробное описание основной функции и ее аргументов: Примеры работы с библиотекой:
  15. Хочу поделиться с вами объектно-ориентированной библиотекой, которую я использую повсеместно для написания программ с графическим интерфейсом. Все приложения со скриншотов выше реализованы с ее использованием, и если вам вдруг захочется накодить нечто подобное - то милости прошу. Подробная иллюстрированная документация, способы установки и множество практических примеров доступны по ссылке: https://github.com/IgorTimofeev/GUI
  16. @SkinnerDE, пардон, я на ходу писал, myImage можно в расчет не брать. Главное принцип, дыа. MyImage в данном случае - это ссылка на объект изображения, передаваемая в обработчик событий для удобства, называть переменные можно как угодно. Для ясности код приведу: local function myEventHandler(application, objectPointer, e1, e2, e3, ...) -- Ох уж эти события end -- Переменная object и objectPointer из обработчика событий - это один тот же объект object.eventHandler = myEventHandler Аналогичный функционал, кстати, можно запилить и средствами event.timer, однако так куда проще, да и отменять таймеры впоследствии не придется.
  17. @SkinnerDE, юзай eventHandler для пикчи: -- Загружаем все пикчи из папки в единую таблицу local path = "/Pictures/" local currentPicture = 1 local pictures = {} for file in filesystem.list(path) do table.insert(pictures, image.load(path .. file)) end -- Добавляем объект изображения в контейнер или куда-то еще local GUIImage = application:addChild(GUI.image(1, 1, pictures[currentPicture])) -- Как часто пикча будет меняться local interval = 5 -- Время, когда условие ниже сработает в следующий раз local deadline = computer.uptime() + interval -- Обработчик событий вызывается каждый пуллящийся ивент (даже если его не было при нулевом интервале) kartinka.eventHandler = function(application, myImage) if computer.uptime() > deadline then -- Отображаем следующую пикчу currentPicture = currentPicture + 1 if currentPicture > #pictures then currentPicture = 1 end GUIImage.image = pictures[currentPicture] application:draw() -- Обновляем время следующего срабатывания условия deadline = computer.uptime() + interval end end -- Обязательно с ноликом, чтоб ивенты пуллились с минимальным интервалом application:start(0)
  18. ECS

    Рыбалка #1 Оптимизация постройки

    @BrightYC, на некоторых серверах (и кк.ру в частности) в совокупности с модами Spice of Life и Pam's Harvestcraft рыбка дает нехилое пищевое разнообразие, без которого жизнь усложняется. Также некоторые магические и ролевые моды требуют рыбеху в качестве алхимических ингредиентов, а еще вокруг роботизированных ферм дропается экспа в малых количествах, что приятно. Но по факту да, картоха - мать всея жратвы.
  19. По этой теме уже существует отлаженный софт, успешно используемый многими игроками. Однако на днях я заметил забавную особенность местных видеокарт, позволяющую выставлять разрешение большее, нежели получаемое через gpu.maxResolution(). К примеру, если maxResolution для видеокарты третьего уровня вернет числа 160 и 50, то никто не мешает установить разрешение, скажем, в 20x158 пикселей. При этом при проверке валидности устанавливаемого разрешения соблюдается два правила: Результирующее разрешение по числу пикселей не должно превышать результат умножения чисел, возвращаемых maxResolution. То есть для T3 GPU не более 160 * 50 = 8000. Каждый параметр разрешения, будь то ширина или высота, не должен численно превышать значение возвращаемой ширины. То есть для T3 GPU не более 160. Не знаю, баг это или фича, однако подобное грех не использовать в своих целях. К примеру, старая версия программы при вертикально-удлиненном расположении мониторов позволяла выставить разрешение лишь в 30х50 (1500 пикселей в итоге), заполняя тем самым "черные полосы". В то же время обновленная софтина, учитывающая описанные выше особенности, выдает 69x114 (7866 пикселей), максимально приближаясь к предельной отметке в 8000: Согласитесь, лишние пиксели на дороге не валяются, и, думаю, кому-то будет интересно узнать про реализацию подобного софта. Прежде всего нам требуется определить точную пропорцию мультиблочного монитора: то, как относится его ширина к высоте. Взглянем на текстуру блока: она явно состоит из мелких "квадратиков" в количестве 16 штук, причем лицевая часть монитора имеет рамку толщиной в 2 "квадратика" с каждой стороны: Эти "квадратики" мы и будем использовать для расчета пропорции, так как они позволяют идеально точно получить размеры отображающей части монитора в игровом мире. А размеры "в квадратиках" можно посчитать по формуле: число_блоков_монитора * 16 - 4 Следовательно, пропорция монитора будет считается следующим образом: local gpu = component.gpu local screen = component.proxy(gpu.getScreen()) local blockCountByWidth, blockCountByHeight = component.screen.getAspectRatio() local proportion = (blockCountByWidth * 16 - 4) / (blockCountByHeight * 16 - 4) Также не забываем, что высота каждого псевдографического пикселя при отображении в 2 раза больше его ширины, поэтому формула пропорции слегка меняется. Заодно произведем некоторые сокращения, чтобы избавиться от лишних математических операций. Все три варианта эквивалентны: local proportion = 2 * (blockCountByWidth * 16 - 4) / (blockCountByHeight * 16 - 4) local proportion = (blockCountByWidth * 16 - 4) / (blockCountByHeight * 8 - 2) local proportion = (blockCountByWidth * 2 - 0.5) / (blockCountByHeight - 0.25) После вычисления пропорции монитора можно приступить к написанию программной логики. Для начала получим максимальное разрешение видеокарты: local maxWidth, maxHeight = gpu.maxResolution() Обладая этими данными, а также взглянув на условия, описанные в начале поста, мы можем составить систему неравенств для получения итогового идеального разрешения: Помним также, что ширину мы вполне можем выразить через высоту и пропорцию монитора: width = proportion * height Подставим этот вариант в систему: Оставим высоту в левой части неравенств: Подставляем имеющиеся переменные в каждое неравенство, рисуем числовую прямую и выбираем высоту, удовлетворяющую условиям неравенства для конкретного случая. Разумеется, в программировании никаких числовых прямых нет, зато есть любимые math.min() и math.max(): local height = math.min( maxWidth / proportion, maxWidth, math.sqrt(maxWidth * maxHeight / proportion) ) -- Выражаем ширину через пропорцию local width = height * proportion Все. Разумеется, полученные значения ширины и высоты нужно округлить в меньшую сторону, дабы не кормить видеокарту дробями. Заодно добавим поддержку масштабирования, чтобы выставлять половинное или, скажем, четвертичное от идеального разрешение. Сократив код, избавившись от лишних переменных, мы получаем следующее: local component = require("component") -- Получаем масштаб в качестве первого аргумента скрипта и корректируем его значение local scale = tonumber(select(1, ...) or 1) if not scale or scale > 1 then scale = 1 elseif scale < 0.1 then scale = 0.1 end local gpu = component.gpu local blockCountByWidth, blockCountByHeight = component.proxy(gpu.getScreen()).getAspectRatio() local maxWidth, maxHeight = gpu.maxResolution() local proportion = (blockCountByWidth * 2 - 0.5) / (blockCountByHeight - 0.25) local height = scale * math.min( maxWidth / proportion, maxWidth, math.sqrt(maxWidth * maxHeight / proportion) ) -- Выставляем полученное разрешение gpu.setResolution(math.floor(height * proportion), math.floor(height)) Надеюсь, это микро-знание кому-то было полезно. Лично я очень доволен, что могу наконец запилить графонистый интерфейс для контроля реакторов на вертикальных мониках без осваивания профессии "глиномес", да и соответствующая либа для автопобора разрешения в оське пригодится.
  20. Мяу, не надо каждый файл, надо одну единственную документацию. Если возникают вопросы или желания по реализации каких-то фич, то пиши в тему либы или мне в личку ВК. Если лень изучать конкретно эту либу или же она по каким-то причинам не устраивает, то есть аналоги, например, forms.
  21. ECS

    MineOS

    @MisterFunny01, 8х4 псевдо-пикселя
  22. @HeroBrine1st, /tmp/ - это монтированный путь виртуальной файловой системы tmpfs, жестко ограниченной по размеру в конфиге мода: # The size of the /tmp filesystem that each computer gets for free. If # set to a non-positive value the tmp file system will not be created. tmpSize=64 Записывай напрямую на загрузочный хард - и все будет шоколадно. А еще для предотвращения TLWY проще использовать computer.pullSignal(0), что гарантирует разовое прерывание, т.к. OS.sleep() иногда умудряется вызвать pullSignal дважды. А прога клевая, мяу
  23. Чтобы не изобретать велосипедов, проще всего будет хранить конфиг в виде луа-таблицы: { player = "MisterSosister", age = 1488 } Затем загружай его в проге и используй эти данные как угодно. Вчера же писал тебе в чат аналогичный вариант: local serialization = require("serialization") local event = require("event") local file = io.open("/config.txt", "r") local config = serialization.unserialize(file:read("*a")) file:close() while true do local eventData = {event.pull("touch")} if eventData[6] == config.name then --Ник валиден end end
  24. ECS

    ExOS

    Мне кажется, я выразился предельно ясно: если, по-твоему мнению, я общался с тобой ВК невежливо/бескультурно/грубо/по-хамски/токсично/феерично/фантастично - значит, по моему мнению, ты это заслужил. В любом случае, твои неоправданные ожидания от общения - это твои личные проблемы, не имеющие к данному разговору совершенно никакого отношения, ровно как и к форуму, и нефиг их сюда экстраполировать.
  25. ECS

    ExOS

    То есть получится. Модулей, отвечающих за графику, всего три из нескольких десятков, при этом каждый модуль самостоятелен и не зависит от системы. За графическую оболочку оси отвечает главный исполняемый файл оси, но никак не модули, ее реализующие. Кто мешает тебе загрузить мою событийную библиотеку? Или, скажем, переписанный файлосистемный враппер? Бери и подключай, хватит придираться к словам. Если тебя не не устраивает богатая графика - это это твой личный субъективизм и предпочтение, к рассматриваемому вопросу о модулях отношения не имеющий. Если не хочется повышенных требований к железу, то специально для таких случаев предусмотрена тонна опций по кастомизации интерфейса: от отключения прожорливых обоин, анимаций и прозрачности до рендеринга превью иконок. В итоге ось "на минималках" с уменьшенным разрешением экрана до 80х25 пикселей вполне себе запускается на паре дешманских планок, стоящих сущие копейки в плане крафта. Это вполне приемлемая цена для графического интерфейса. О том называть ли технически не-ось осью, разве нет? Если спор об этом, к чему был бесконечный поток придирок и оффтопа с твоей стороны о расходе оперативной памяти, отсутствии документации к экспериментальному проекту, о личных предпочтениях в графических интерфейсах, о системном программировании, о нужности и ненужности гуя? Я вынужден отвечать на подобное из элементарной вежливости (которая все более улетучивается), однако не горю желанием продолжать разговор на темы, которые я не открывал, и которые мне не интересны. Интересно девки пляшут: сначала наклеветал на меня фразой, которую я не высказывал. А теперь заявляешь, будто бы я сам вложил в другую фразу скрытый смысл, являющийся предпосылкой для твоей клеветы. Обожаю подобный перевод стрелок и перекладывание ответственности, итпедия бы гордился. Нужно быть величайшим гением, чтобы придраться к этой аналогии. Впрочем, не удивительно: когда угасает аргументация, форумчане всегда цепляются к каждому второму слову, чтобы не упасть в грязь лицом. О чем ты споришь? Ты не согласен, что опенкомповский робот банально не обладает достаточным количеством памяти? Если согласен, то почему ты тратишь мое время на разбор подобной ерунды? А что мне мешает их сравнивать? Существуют какие-то нормативы, кроме придуманных тобой, препятствующие данному сравнению? Почему я не могу этого делать? За время переписки с тобой я не узрел фактических причин. Функционал один, концепция одна, результат работы один. Беру и сравниваю, в чем проблема-то? И не надо мне сказки рассказывать про надежность опеноси. Как и любой программный продукт, как и майнось в частности, у него имеется тонна багов, к счастью, оперативно фиксящихся в обновлениях мода. Буквально сегодня обнаружил в версии 1.7.3, что метод filesystem.rename перестал корректно работать для монтированных файловых систем. Подобные баги критичны, и нечего тут оффтоп разводить, приукрашивая действительность. Для меня этот критерий не является сколь-либо значимым. Когда кончится терпение из-за конфликтов с опеносью наподобие описанного выше - тогда и займусь. Но пока оно еще имеется в крошечном запаснике Любое дело, связанное с личным выбором, всегда субъективное. Я бы поспорил на тему невозможности существования объективной действительности, но, боюсь, сам перестану соответствовать своим же требованиям к ведению диалога. Не уловил. Если корчишь из себя софиста, придираясь к каждому слову, то не удивляйся ответному критицизму. "Почти стандартной" io-либы не существует, есть лишь опеносовская, названная таким же образом. И никакого, цитирую, "огораживания огорода" тебе делать не придется ни в каком из случаев. Поэтому я до сих пор не понимаю, к чему ты вообще стал развивать данную ветвь дискуссии.
×