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

Лидеры


Популярный контент

Показан контент с высокой репутацией за 01.09.2022 во всех областях

  1. 7 баллов
    Симпатичные скриншотики. Синих символов на красном фоне нам очень не хватало в стандартном редакторе. ГЛАЗА!!!
  2. 6 баллов
    Обновление приехало! Даже сразу до 1.7.7. (Скачивать как обычно тут - ссылка не меняется.)
  3. 5 баллов
    Вот и второй алгоритм: Куда быстрее предыдущего, но имеет только черно-белые цвета -- ordered bayer dither -- local threshold_map = { {0, 8, 2, 10}, {12, 4, 14, 6}, {3, 11, 1, 9}, {15, 7, 13, 5} } function Dither.ordered_bayer_dither(matrix, bool_matrix, width, height) for y=1, height-1 do for x=2, width-1 do local grey = Dither.greyscale_pixel(colors.toRGB(matrix[y][x])) grey = grey / Dither.MAX_COLOR -- Dither.MAX_COLOR is 255 if grey < threshold_map[(y%4)+1][(x%4)+1] * (1/16) then matrix[y][x] = colors.black bool_matrix[CEIL(y/3)][CEIL(x/2)] = true else matrix[y][x] = colors.white bool_matrix[CEIL(y/3)][CEIL(x/2)] = true end end end return matrix, bool_matrix end
  4. 5 баллов
    Для теста видеобуферов набросал максимально упрощенный рендерер для майноськи. Без поддержки изображений, прозрачности и транзиций - оставил лишь суровые прямоугольники и цветной текст: Плюсы: расход RAM упал до 25% на полностью инициализированную систему с загруженными (но не отрисованными) иконками. Для слабых машин это очень хороший показатель, и освободившиеся ресурсы можно было бы направить на прикладной многозадачный софт. Минусы: оно лагает сильнее, чем софтверное решение с графоном!11 Но, будем честны, я натягиваю сову на глобус. Концептуально фича крайне сочная, API удобное и не ломает старые проекты, написанные под прямую работу с GPU. Думаю, она будет идеальным решением для узкозадачных юишных софтин типа мониторилок реакторов, кнопочных контроллеров для умного дома, текстовых чатов или рисовалок - иными словами, для всего, что могло слегка подлагивать из-за прямой отрисовки. И если раньше надо было извращаться с порядком операций, экономя каждый тик, то теперь можно кодить гораздо комфортнее. Хотя мне все равно чуточку обидно. Но лишь чуточку.
  5. 4 балла
    Впрочем, нет. Подтверждаю частично. После перезагрузки компьютера с поддельным ID повторить этот опыт не удалось. Во-первых, ID после перезагрузки сбросился. Это было ожидаемо. Но после подмены ID этот компьютер вообще перестал принимать сообщения как на свой настоящий ID, так и на поддельный. Он теперь даже на широковещательные сообщения не реагирует. upd: Всё-таки подтверждаю полностью. Чтобы трюк работал, сначала следует подменить ID, и лишь затем открывать модем. Тогда всё работает. А если сделать наоборот, то целевой компьютер вообще теряет возможность принимать сообщения. Адрес отправителя можно подменить точно так же.
  6. 4 балла
    Код: -- floyd steinberg dither -- function Dither.floyd_steinberg_dither(matrix, bool_matrix, width, height) for y=1, height-1 do for x=2, width-1 do local old_r,old_g,old_b = colors.toRGB(matrix[y][x]) --old_r,old_g,old_b = Dither.greyscale_pixel(old_r,old_g,old_b) local factor = 3 local new_r = CEIL(factor * old_r / 255) * (255 / factor) local new_g = CEIL(factor * old_g / 255) * (255 / factor) local new_b = CEIL(factor * old_b / 255) * (255 / factor) new_r,new_g,new_b = math.floor(new_r), math.floor(new_g), math.floor(new_b) matrix[y][x] = colors.fromRGB(new_r,new_g,new_b) bool_matrix[CEIL(y/3)][CEIL(x/2)] = true local err_r = old_r - new_r local err_g = old_g - new_g local err_b = old_b - new_b local index_x, index_y = x+1, y local c_r, c_g, c_b = colors.toRGB(matrix[index_y][index_x]) c_r = c_r + err_r * 7/16.0 c_g = c_g + err_g * 7/16.0 c_b = c_b + err_b * 7/16.0 matrix[index_y][index_x] = colors.fromRGB(c_r, c_g, c_b) bool_matrix[CEIL(index_y/3)][CEIL(index_x/2)] = true index_x, index_y = x-1, y+1 c_r, c_g, c_b = colors.toRGB(matrix[index_y][index_x]) c_r = c_r + err_r * 3/16.0 c_g = c_g + err_g * 3/16.0 c_b = c_b + err_b * 3/16.0 matrix[index_y][index_x] = colors.fromRGB(c_r, c_g, c_b) bool_matrix[CEIL(index_y/3)][CEIL(index_x/2)] = true index_x, index_y = x, y+1 c_r, c_g, c_b = colors.toRGB(matrix[index_y][index_x]) c_r = c_r + err_r * 5/16.0 c_g = c_g + err_g * 5/16.0 c_b = c_b + err_b * 5/16.0 matrix[index_y][index_x] = colors.fromRGB(c_r, c_g, c_b) bool_matrix[CEIL(index_y/3)][CEIL(index_x/2)] = true index_x, index_y = x+1, y+1 c_r, c_g, c_b = colors.toRGB(matrix[index_y][index_x]) c_r = c_r + err_r * 1/16.0 c_g = c_g + err_g * 1/16.0 c_b = c_b + err_b * 1/16.0 matrix[index_y][index_x] = colors.fromRGB(c_r, c_g, c_b) bool_matrix[CEIL(index_y/3)][CEIL(index_x/2)] = true --[[ [y+1][x ] [y+1][x+1] ]] end end return matrix, bool_matrix end colors взял отсюда: https://www.computercraft.info/forums2/index.php?/topic/23048-rgb-api-convert-rgb-colors-to-computercraft-colors-and-back/
  7. 4 балла
    Иногда удобно использовать встроенное средство редактирования файлов OpenOS. Однако мне никогда не нравился дефолтный чёрный цвет фона. Поэтому я немного модифицировал edit.lua так, чтобы цвета легко настраивались. Установка проще, чем заварить чай. Достаточно скопировать и запустить следующую команду (OpenOS должна быть установлена). wget -f https://raw.githubusercontent.com/Smok1e/oc-openos-colored-edit/main/edit.lua /bin/edit.lua Настроить цвета можно в стандартном файле конфигурации - /etc/edit.cfg В конце файла добавьте (или измените) следующее: colors = { background = [желаемый цвет фона], foreground = [желаемый цвет текста] } Например: Спасибо за внимание. Кстати если кто-нибудь знает, каким образом можно изменить цвета стандартной оболочки OpenOS, буду признателен, если расскажете.
  8. 3 балла
    В этом и заключается вопрос топикстартера: в чем смысл такой защиты, фича ради фичи? Если у дурака имеется доступ к eeprom, то не всё ли равно, вызывать eeprom.makeReadonly() или eeprom.makeReadonly(eeprom.getChecksum())?
  9. 3 балла
    Это баг конкретно в новой версии OC. Фингер его отрепортил создателям мода, посмотрим когда они его исправят.
  10. 2 балла
    Спасибо, исправил. Постараюсь внимательнее проверять фичи перед пушем. Или на Тотору спихну, пусть ревьювит))0
  11. 2 балла
    Копаясь среди компонентов и функций, я остановился на eeprom: Функция makeReadonly зачем-то требует хэш данных, записанных на eeprom. Причем параметр обязательный, и обязательно должен соответствовать хэшу данных на eeprom. Самое смешное, что этот хэш можно получить другой функцией eeprom - getChecksum. Судя по исходникам, ни для чего, кроме проверки в функции makeReadonly этот хэш не используется, но вот если он будет неправильный, то вернётся ошибка. Зачем это вообще было сделано?
  12. 2 балла
    Я нашел метод подмены ID. Пишу одну либу, под свои нужды так сказать. Я просто задумался о самом простом и минимально затратном способе подмены ID и родил это: _G.backup = {} _G.backup.os = {} _G.backup.os.getComputerID = _G.os.getComputerID -- spoof computer id -- self.spoof_computer_id = function(id) if id then _G.os.getComputerID = function() return id end end sleep(1) end self.restore_computer_id = function() _G.os.getComputerID = _G.backup.os.getComputerID end
  13. 2 балла
    https://github.com/MightyPirates/OpenComputers/issues/792 > eeprom.protected // Boolean data value. Prevents changes to the eeprom, think blowing protection fuses. >Boolean eeprom.protect(string chkSum) // returns true on success, requires the chksum of the eeprom in order to prevent idiots from fusing everything. https://en.wikipedia.org/wiki/EFuse https://scribe.rip/hackernoon/how-the-nintendo-switch-prevents-downgrades-by-irreparably-blowing-its-own-fuses-884bd3b7a8ba#:~:text=Blowing a fuse is irreversible— once it’s been set it can never be undone.
  14. 2 балла
    Ок, вот мои наработки по теме: https://gist.githubusercontent.com/Krutoy242/1f18eaf6b262fb7ffb83c4666a93cbcc Документацию напишу позже. Пока, как я и говорил, робот (или дрон!) умеет выполнять свое имя как Луа-код. Но к тому же, он может всё сокращать до 1-2 символов. Например, вот такая строка сторгует всё что есть у жителя: ~:Tg(){?!v{tr}} А вот мега программа в 54 символ для дрона, который носит предметы из одного вейпоинта к другому: Dm(tb.u(Nf(300)[a++%2+1].p))s(3)~#{Dsel(i)Dd(0)Dsu(0)} В этом примере есть такие сокращения: a++ это продвинутая версия a=a+1, только она работает даже если а==nil s(3) расшифруется как sleep(3) ~#{BODY} получится for i=1, (R or D).inventorySize() do BODY end Еще, я добавил крутые фичи связанные с "трубами" - как в лямбда программировании, когда мы можем скомпоновать функцию, которая будет передавать результат своей работы в другую функцию. Но пока не придумал как ими пользоваться. Главная фишка это утилизировать битовые операции. Я сделал такое: a|b превращается в function(c) return b(a(c)) end. Но оказалось, что это почти бессмысленно, если мы не можем получить ключ\значение из цикла. В итоге, я уже могу написать вот такую функцию: _4|(Dsel|Dd&0) Получится вот так (примерно): for k,v in pairs{1,2,3,4} do (function() return D.drop(0) end)(D.select(v,k)) end Но как то криво всё равно. Не элегантно. Но уже можно пользоваться. javaw_0VdCQylZec.mp4
  15. 2 балла
    Честно говоря, не очень понял, что имеется в виду. Поэтому на всякий случай проясню, что имел в виду я. Если замена in-Lua буферов на VRAM привнесла задержки на порядок, то виноват, скорее всего, некто из следующих элементов: Lua. Нативные либы собраны с -O0.... и заметно тормозны. Сюда же пойдёт хук для TLWY. Оверхед из-за интерфейса Lua ↔ Scala (об этом ниже). Бюджет вызовов, который могут потреблять прямые вызовы get на ненулевой буфер. Каждый прямой вызов, даже если он бесплатный (а он должен быть практически бесплатным, если активен ненулевой буфер), проходит через слой Lua ↔ Scala. Это значит запаковать аргументы, проверить их, передать в сишную функцию от JNLua, которая для каждого аргумента создаст жвм-объект, найти колбэк по адресу компонента и имени метода, сожрать 2-32 единиц бюджета, произвести диспатч в колбэк, внутри него обработать вызов, потом принять результаты, их нормализовать в поддерживаемые JNLua, отдать в нативную сишную функцию от JNLua, которая каждый принятый жвм-объект преобразует обратно в луа-значения и вернёт их, потом полученные значения запаковать, проверить, распаковать и вернуть. Я надеюсь, что даже при таком длинном описании на деле это займёт не особо длительное время (думаю, порядка сотни микросекунд; источник оценки — потолок), однако если произвести 16 тысяч таких вызовов, то оверхед может стать достаточно существенным. Именно про этот оверхед я и говорил. Я предполагаю, что софтверное склеивание тормозит из-за него. Если гадать ещё безбашеннее, то можно сказать, что хук для TLWY вообще практически бесплатен на фоне него. Аргумент против этой гипотезы: ожидаемая задержка (0.5–1.5 секунд) от полученной (3 секунды) отличается разительно. А bitblt действительно пожирает очень много единиц бюджета вызовов. Если точнее, то для копирования из буфера 160×50 на основной гпу третьего уровня сожрёт 1.5 единиц бюджета (то есть практически точно положит комп на тик). Если копировать из буфера, площадь которого больше максимального основного разрешения соответствующего уровня, комп вообще будет спать несколько тиков. P. S. В довольно древней версии оцелота есть гпу-буферы в том виде, в каком они оказались в OC 1.7.6, и график бюджета вызовов. Можно протестить прогу там.
  16. 2 балла
    Идея занятная, но тормозит люто. Подправил либу, после склейки дело дошло до рендеринга лишь спустя ~5 сек, то есть комп фактически виснет на процессе поиска пикселей со схожими цветами на тоннах вызовов setActiveBuffer/get. У меня вообще зародилось смутное подозрение, что все операции над буферами ни разу не zero cost даже с поправкой на искусственный троттлинг хука вызовов в machine.lua. И ладно бы вывод на экран - сам процесс рисования в буфер через setBackground/setForeground/set явно кушает бюджет. Как говорится, численно доказать не могу, но эмпирически чувствую
  17. 2 балла
    я вижу вы человек высокой культуры. Полностью вас поддерживаю
  18. 2 балла
    Ну тогда это возможно тема для ещё одной issue.
  19. 2 балла
    Отнюдь. Оченьжданчик и долгожданчик.
  20. 1 балл
    Транспозеры прекрасно могут выкладывать рецепты, видел схемы где алтарь полностью автоматизирован, только заказываешь, а компьютер выстраивает рецепт, через установщики блоков выставляет банки, по окончании процесса возвращает банки на их анализ и доливку до полной. Автозапуск осуществляется роботом. Достаточно чтобы он заюзал перед этим том мироздания который обучит его. Как мне объяснял админ, этот том создает в оперативке типа игрока user.robot который может колдовать по матрице, но этот игрок не сохраняется на ЖД, поэтому робот теряет магические силы после рестарта.
  21. 1 балл
    Подтверждаю. Описанный автором трюк позволяет перехватывать сетевые сообщения, адресованные другим компьютерам. Сообщение, адресованное конкретному компьютеру, может быть получено любыми компьютерами: как имеющими настоящий ID, так и поддельные. Я тестировал с модом ComputerCraft1.75.jar для Minecraft 1.7.10.
  22. 1 балл
    Потратив более 8 часов беспрерывного кода. Я написал дизеринг для своей либы. К сожалению этот метод ОЧЕНЬ долгий. Я напишу другой метод, в итоге будет два метода, в теории второй метод должен быть быстрее. До: После(используется несколько значений факторов)
  23. 1 балл
    Ого виртуальная машина! слева сверху на скрине конеч попадос и да оперативе не будет хана?
  24. 1 балл
    Ну, в проге lua есть автоподстановка, поэтому случайно натабать makeReadonly() и тыкнуть энтер, не одумавшись вовремя, очень реально (похоже, но не с этим методом, косячил сам). А внутрь подставить вызов другого метода неосознанно несколько сложно. Поэтому некоторый смысл оно имеет.
  25. 1 балл
  26. 1 балл
    Переведу на русский: защита от дурака. О чём я и сделал предположение выше.
  27. 1 балл
  28. 1 балл
    Очень жду обновление до opencomputers 1.7.6
  29. 1 балл
    Новая версия OpenComputers. Неожиданно. Из наиболее интересного: Видеобуферы у графической карточки. Помимо основного, нулевого буфера, который отображается на экране, теперь можно аллоцировать дополнительные буферы — 2D-массивы символов с заданным разрешением, с которыми можно проводить те же операции, что и раньше: set, fill, copy и т. д., — но без потребления бюджета вызовов (то бишь халявно). Добавлена операция bitblt (bit blit), которая копирует кусок одного буфера на другой. Копирование на основной буфер потребляет бюджет вызовов пропорционально разрешению исходного буфера (не размеру области копирования). Может занять несколько тиков. Если верить @ECS, последнее преимущества в производительности практически убивает. Впрочем, за несколько лет, пока буферы висели в дев-билдах, люди уже их заиспользовали для игрушек: вот платформер, например. Прямые вызовы методов компонентов (любых, не только GPU), не имеющих явных лимитов или использования бюджета вызовов, теперь абсолютно бесплатны с этой точки зрения. Раньше они потребляли одну тысячную единицы бюджета вызовов. Подробнее о них — в моей статье. Обновлён шрифт: покрытие значительно расширилось путём забития недостающих символов глифами из Unifont. Заблокирован диапазон 0.0.0.0/8 для интернет-карты. Запросы туда делают примерно то же, что запросы на localhost. Примечательно, что эту уязвимость использовали на CTF для обхода файрволла. Советую почитать. Метод media добавили и для дисководов в серверной стойке. Досадное упущение. Пофиксили отключение компов при перезагрузке чанка: в определённых случаях стейт компьютеров вовсе не сохранялся, из-за чего они рестартились при выгрузке и подгрузке чанка. Починили debug.sendToDebugCard (весьма полезная функция). Разобрались в ориентации редстоун-карт. В 1.7.3 карточки в компах и серверах почему-то использовали абсолютные направления (север/юг/запад/восток) вместо относительных. Беспроводные модемы первого уровня снова могут получать сообщения. А раньше не могли. Это была бага. Ретрансляторы потеряли возможность ретранслировать на неограниченно большие расстояния. В коде мода запутались в min и max. В результатах поиска вейпоинтов навигационным апгрейдом теперь пишутся их адреса. Остальные изменения и ссылка на скачивание — на GitHub.
  30. 1 балл
    Размышления по поводу программы привели меня к еще более крутой идее: А что если я не буду придумывать никакого синтаксиса, а просто сделаю функцию сокращения путей и ключевых слов? Изменяя метатаблицы переменной _ENV я могу наворотить любые сокращения. Например, если назвать робота robot.use(3) - он будет юзать вперед. Но это можно укоротить до 5 символов. Заменим robot на R, сделаем поиск по полям, уберем ненужную точку, и вуаля, останется только Ru(3) Еще бы сократить вызовы функции с параметрами как то, и вообще шикарно. Еще можно упростить всякие циклы и пэирсы, например заменить for in pairs() на ~:t{pt(k,v)} Превратится в for k,v in pairs(t) do print(k,v) end Но тут уже начинаешь путаться. 🤔
  31. 1 балл
    Я и не утверждал обратного, это уже какая-то нездоровая полемика. Проясню: 1) Я продемонстрировал, что комп умирает на несколько сек при обращении к gpu.get, предположив, что обращение к ненулевому буферу ни разу не бесплатное 2) Ты сообщил, что доминирует некий оверхед, а расход бюджета при обращении к ненулевому буферу должен быть 2-31 3) Я ответил, что значение в 2-31 слишком мало, и бюджета после 16к вызовов должно оставаться с запасом, и проблема явно в другом месте 4) Ты пояснил, что имел в виду под оверхедом, упомянув нативные либы, интерфейс Lua <> Scala и сам бюджет вызовов 5) Я не согласился, приведя пример с 16к вызовами unicode и computer, имитирующими оверхед без расхода бюджета, и работающий незаметно с точки зрения производительности. Поскольку из примера был исключен лишь расход бюджета, а работа нативных либ и прокидывания данных через Lua <> Scala сохранены, я сделал вывод, что к тормозам приводит именно бюджет Разве это не подтверждает тезис о том, что gpu.get кушает сильно больше 2-31 бюджета? Может быть, каждый вызов прямого метода компонента расходует некое константное кол-во бюджета в дополнение к прописанному в @Callback значению?
  32. 1 балл
    unicode.sub и computer.uptime — это не методы компонентов, а функции, которые практически напрямую дёргают методы луа и потому несравнимо дешевле. Сравнение нечестное. Проверил в оцелоте: 16к вызовов gpu.get заняли 0.80 секунд (avg 50 μs / call), а столько же computer.uptime — 0.04 (avg 2.5 μs / call). Такое же число вызовов методов других компонентов также занимают около 0.8 секунд. Потребление бюджета вызовов при этом остаётся околонулевое.
  33. 1 балл
    Разве это не смехотворно малая величина? В таком случае от бюджета серверной стойки в полной комплектации в 1.4 единицы должно оставаться 1.4 - 160 pix * 50 pix * (2 setActiveBuffer + 2 get) * 2-31, то есть 1.3999850988387 Хорошо, предположим, остаток полностью съедают вызовы функций. Пишем для теста любую функцию-заглушку и вызываем её примерно такое же кол-во раз, что и при группировке схожих пикселей: local function throttle() local a = 123 local b = a + 456 local c = a + b ^ a end function screen.update() for i = 1, 160 * 50 * (2 + 2) do throttle() end componentInvoke(GPUAddress, "bitblc", 0) end И... оно работает с той же скоростью, что и в первом примере. То есть на глаз разница не видна, хотя технически она, конечно, есть. Поэтому, имхо, расход бюджета сильно-сильно больше, а хук на вызовы особой роли не играет. Жаль только, что нет фичи вывода значения бюджета через debug.getCallBudgetValue, чтобы знать наверняка Хорошая идея. Закодил, чекнул, скорость действительно чуть возросла, но осталась в пределах ~1 кадра в 3 сек. Вообще мы осознанно убрали bitblc в угоду самописному решению, которое явно проигрывает, так что копать дальше в этом направлении смысла мало. Плюс у нас происходит дублирование вызовов setBackground/setForeground: первый раз во время отрисовки основной графики в буфер, а затем второй раз, но уже в сгруппированном по цветам виде при выводе на экран. Бедная видяшечка, на тайваньских майнинг-фермах и то живется легче (9
  34. 1 балл
    Возможно, не бюджет расходуется дико (насколько я понял, каждый прямой вызов в побочный буфер потребляет 2-31 единиц бюджета), а оверхед просто от вызовов доминирует. Кроме того, там можно выделять не два буфера по 160×50, а один на 160×100, например: число вызовов setActiveBuffer вдвое станет меньше. Хотя с таким оверхедом, видимо, не особо это поможет...
  35. 1 балл
    всем привет, недавно я написал новую ос под названиям likeOS основными фишками которой являются: оболочка отдельно от ядра ос, вы можете поставить только ядро и добавить туда автозагрузочный скрипт, а можете поставить дистрибутив liked много поточность мульти мониторность(относиться скорее к дистрибутиву liked) очень малый расход оперативной памяти, зачёт того что многие функции операционной системе лежит на hdd и подгружаться только в момент использования оптимизированные функции getDeviceInfo и getKeyboards(потому что ос использует их очень часто) авто выгрузка некоторых библиотек начнём с дистрибутива liked сможет работать на планке t1,5 даже с двумя мониторами этот gui дистрибутив который использует api graphic ядра для работы с графикой в liked предусмотрен dev mode для создания собственных приложений, для его активации задержите стрелку вверх в магазине liked есть irc клиент! как работает мульти мониторность дистрибутив liked выводит рабочий стол только на мониторы начиная с уровня 2 на разным мониторах ос будет работать почти как разным компьютеры для работы не требуется несколько видео карт, хотя это желательно вы сможете запустить разные программы на разных мониторах ос сама разберётся какую gpu к какому монитору подключить, и когда подбиньдить отличия dev mode от user mode dev mode при переименовании файла расширения не переходит от пред идущего при создании текстового файла ему автоматически не присваивается расширения txt вы можете присвоить расширения папке вы можете указать расширения при переименовании файла вы получаете доступ к корню диска вы получаете возможность заходит внутрь пакетных приложений вы получаете возможность редактировать lua скрипты user mode вы не можете указывать расширения сами, оно везде присваивается автоматически при переименовании расширения переходит от старого имени установка ос: для начала необходимо создать установочную дискету, запустив команду wget https://raw.githubusercontent.com/igorkll/likeOS/main/installer/openOS.lua /tmp/asd -f && /tmp/asd в openOS затем необходимо загрузиться с дискеты на том устройстве на которое желаете поставить likeOS - liked так же вы можете загрузиться туда через улититу install обычный openOS, просто установить дискету как обычную, но вместо установки компьютер после выбора дискеты туда загрузиться выберите online mode/offline mode(первый загружает ос из интернета, второй с самой дискеты) выберите дистрибутив(liked это графический дистрибутив, core only это чистая likeOS которая нечего не выведет на монитор а просто крашнеться с ошибкой computer halted) выберите диск согласитесь подождите ос установлена предупреждения внимания подгруздка библиотеки thread может привести в увеличению расхода энергии! рекомендации liked на скорость рендера, очень сильно влеяет уровень процессора, и видеокарты, но не монитора, по этому по возможности лутще будет устоновить видеокарту t3 даже в планшет/компьютер с вторым монитором, и процессор t3 фишки дистрибутива liked возможность поставить иконку на любую папку(создайте картинку с именем icon) смена обоев рабочего стола смена цветовой палитры монитора показ реального времени в углу в планах сеть программа для перебрасывания файлов и папок между устройствами (частично реализовано в виде программы чат) магазин приложений (уже реализовано) утилита обновления ос (уже реализовано) возможность установить ос напрямую с диска openOS минуя создания установочной дискеты (уже реализовано) проверка на вмешательства в системные файлы возможность поставить обои отдельно для конкретной папки клиент для ocelot online структура файловой системы /init.lua - враппер на загрузчик системы /system - файлы дистрибутива /system/core - файлы ядра /system/autoruns - автозагрузка дистрибутива(для скриптов не требующих взаимодействия) /system/main.lua - тоже автозагрузка, но предназначена для программ выполняемых в бесконечном цикле /systen/bin - программы дистрибутива /system/lib - библиотеки дистрибутива /system/calls - hdd функции дистрибутива /system/core/boot,lua - загрузчик ос структура _ENV(может быть сложно для понимания новичкам, сложно для понимания новичкам, читать не обязательно) _ENV в большинстве ситуаций личная, а _G общая, исключения hdd функции в которых _ENV и _G это одна таблица, и так же исключениям является рабочий стол liked который делит _ENV между рабочими столами на разных мониторах соответственно глобалы созднанные таким образом (value = 2) будут личными, а таким (_G.value = 2) обшими api calls calls.call - вызов функции лежашей на hdd calls.load - погрузка функции лежачих на hdd calls.loaded - кеш функций, сам не заполняется, но может быть использован в некоторых случаях calls.paths - таблица с путями по которым идет погрузка api package _G.require - подключить библиотеку package.loaded - кеш библиотек package.paths - тиблица с путями по которым идет подгрузка библиотек api graphic graphic.findGpu(screen) - ишет gpu для нужного экрана и подкючает ее, искать gpu нужно заного после кажного прерывания, так как она может быть "украдена" graphic.createWindow(screen, x, y, sizeX, sizeY):windown- создает НЕ буферизированое окно на нужном экране window:clear(color) - залить окно нужным цветов window:write(str) - запись данных в окно window:read(x, y, sizeX, background, foreground, preStr, crypto) - стения данных из окна, если ввод был отменен вернет true window:uploadEvent(eventData:table):eventData:table - загружает event в окно и возврашает измененный ответ или nil window:set(x, y, background, foreground, data) - записать строку window:fill(x, y, sizeX, sizeY, background, foreground, char) - заливка window:copy(x, y, sizeX, sizeY, offsetX, offsetY) -- копирует участок окна window:setCursor/window:getCursor тоже есть, и управляют функцией write все цвета нужно брать из таблицы gui_container.colors иначе их поведения будет неправильным интерфейс liked
  36. 1 балл
    К слову, насколько сильно будет тормозить решение, которое перенесёт массивы-буферы из луа в vram, но склеивание операций и рендер будет проводить всё так же в луа, не используя bitblt?
  37. 1 балл
    Баги, которые появились в 1.7.6: сломаный брайль, сломаная опенось, сломанная версия — пофиксили в спешном темпе и выпустили 1.7.7.
  38. 1 балл
    никто не знает. Никто. Его не было на форуме уже миллиард лет. Остаётся надеяться на его возрождение, либо уже самому сервер делать, чем я и занялся
  39. 1 балл
  40. 1 балл
    Да, я вчера писал это в дискорде и в IRC. Фикс такой: добавить require('core/full_buffer') в какой-нибудь файл - например, /boot/95_robot_fix.lua.
  41. 1 балл
    Игооорь после обновы OC система сломалась! конкретно проблемы с символами браиля (или с double buffering) у меня лично сломались кнопки и на иконках в местах с символами браиля тоже проблемы
  42. 1 балл
    Программа умеет получать картинки по ссылке и отрисовывать их в OpenComputers. Поддерживается примитивный даунскейлинг. wget -fq https://raw.githubusercontent.com/ProgramCrafter/lua-utils/main/images-drawer/draw-random-img.lua Работа всё ещё в процессе. На данный момент: 1. Проверяю на работу только GIF. 2. Некоторые GIF некорректно парсятся по вине библиотеки. 3. К библиотеке GIF нужен патч, чтобы хоть какие-то гифки показывались. wget -fq https://gist.githubusercontent.com/ProgramCrafter/d1b279aec9e473794df115d1301dcb27/raw/8166f23ee3daba8ca8ec305589b3d9a258f6674f/gif.lua /usr/lib/gif.lua 4. Даунскейлинг примитивный: если картинку надо уменьшить, то из каждого квадрата 2x2 пикселя выбирается левый верхний. 5. Требования: тир3 GPU и монитор, интернет-карта, 6 планок тир3,5 памяти. Используемые библиотеки: Зато результат неплохой:
  43. 1 балл
    Отрисовка четырёх основных форматов картинок (PNG, JPG, BMP, GIF) работает! В частности, BMP и GIF отрисовываются без использования временных файлов и поэтому работают внутри контейнера. У всех форматов, кроме PNG, даунскейл происходит по одному алгоритму. JPEG: GIF: BMP: PNG:
  44. 1 балл
    $ diff -U 0 irc.lua irc.1.lua --- irc.lua 1970-01-01 00:00:00.000000000 +0000 +++ irc.1.lua 1970-01-01 00:00:00.000000000 +0000 @@ -1,3 +0,0 @@ --- A (very (very!)) simple IRC client. Reference: --- http://tools.ietf.org/html/rfc2812 - @@ -25 +22 @@ -local host = args[2] or "irc.esper.net:6667" +local host = args[2] or "irc.Esper.net:6667" @@ -374 +371 @@ - print("Welcome to OpenIRC!") + print("Welcome to UnionICE") @@ -455 +452 @@ - local channel = text.trim(line:sub(7)) + local channel = "#cc.ru" @@ -461 +458 @@ - line = "JOIN " .. channel + line = "JOIN " .. "#cc.ru" Ловко.
  45. 1 балл
    Поставляется в комплекте с OpenComputers на дискете IRC. https://github.com/MightyPirates/OpenComputers/blob/master-MC1.7.10/src/main/resources/assets/opencomputers/loot/irc/usr/bin/irc.lua
  46. 1 балл
    Ого, очередной опенкомпьютерный болгенос. Даже редактор нескучных обоев из коробки.
  47. 1 балл
    По мотивам Lua? ы серьёзно? Оно же будет запускаться любым компом, к которому будет подключено, то ли дело MovEMU Byte Code, запускаться будет только через виртуальную машину (на Lua, так уж и быть) или новую архитектуру OpenComputers (которая ещё не готова); там не будет TLWY, можно будет использовать sleep, не теряя события, и так далее...
  48. 1 балл
  49. 1 балл
  50. 1 балл
    Поясни, в чем конкретно состоит проблема. Что именно не получается реализовать? Я не могу понять из твоих постов, что именно вызывает трудности. Предположим - у тебя каждый раз при старте консоль системы оказывается на непредсказуемом мониторе, и не факт что на том, где клавиатура. В таком случае можно просто положить в корень диска файл autorun.lua, который будет жестко биндить нужный монитор к основной видеокарте. Адреса можно вписать вручную, используя первые четыре уникальных символа адреса, и далее автоматически получая полный адрес в программе через команду component.get("xxxx"). (Будет полезен этот сайт: http://ocdoc.cil.li/api:component) Эвенты от мониторов (события touch/drag) и клавиатур (key_down/key_up) вообще обрабатываются вне зависимости от наличия привязанной видеокарты. Адрес компонента, который отправлил эвент, всегда идет вторым параметром в этом самом эвенте (как ты несомненно знаешь). На этом принципе работает моя программа Smart Lock. Она использует всего две видеокарты - одна привязана к "консольному монитору", через который пользователь может вводить команды с клавиатуры. Вторая видеокарта в любой момент работы программы может быть привязана к любому из нескольких десятков мониторов-замков в системе. В тот момент, когда пользователь "звонит" в дверь, программа определяет адрес монитора, с которого пришел "звонок" и биндит в нему видеокарту номер 2. Далее уже идет отрисовка графики через эту видеокарту на нужный монитор. Соответственно, когда приходит следующий звонок, видеокарта "перепривязывается" опять.
Эта таблица лидеров рассчитана в Москва/GMT+03:00
×
×
  • Создать...