ECS

))) https://computercraft.ru/topic/4340-tapfat-faylovaya-sistema-dlya-kasset/?tab=comments#comment-49345

Даже в случае с хеш-таблицей держать все индексы БД в памяти - такая себе затея, т.к. оператива не резиновая, а скрафтить RAID на 12 мбайт не составит особого труда. Основной проблемой при работе с индексами, хранящимися на диске, у тебя будет скорость чтения и реиндексации при записи, т.к. опенкомповские диски прям сильно лимитированы по I/O операциям. Даже если прикрутить к хеш-таблице бинарный поиск, то это слабо поможет жирным БД, исчисляемых мегабайтами, т.к. глубина рекурсии при поиске может достигать нескольких тысяч. К сожалению, чем жирнее БД, тем более заковыристый алгоритм требуется для ее поддержки, и заюзать древовидную структуру для хранения индексов будет оптимально, т.к. для чтения с диска нужно минимизировать число узлов, которые обходит поисковая система. Ну а про удаление/вставку со сдвигом индексов и говорить нечего

Это особо и не важно, т.к. отсылающий код взят у топикстартера, а запись в сокет, судя по всему, у него работает. Либо это кастомная интернет-либа, либо код выложен не полностью, пофигу. Главное - дать наводку на листенер internet_ready

Сокет-сервак работает параллельно с твоим клиентом, пишущим MOTD и ждущим ответа. Клиентские данные могли не успеть обработаться серваком во второй раз, могли проинтерпретироваться в виде сдублированной строки "MOTDMOTD", а могли и вовсе быть поглощены ZOGом во имя вселенского благополучия. Ты же делаешь :read() в слепой надежде на успех. Непорядок! Подписывайся на ивент internet_ready, делай небольшую задержку между отправкой запросов на MOTD, разбивай сообщения через символ переноса строки, правильно обрабатывай их на сервере, а затем уже читай данные: local soc = require("internet") local event = require("event") event.listen("internet_ready", function() local motd = soc:read(100) ... end) soc.open("localhost", 2888) soc:write("MOTD\r\n") os.sleep(1) soc:write("MOTD\r\n") os.sleep(1) ... Либо, если оч сложна, юзай костыль со слипом. Но тут тоже никаких гарантий, то данные пришли и обработались корректно: local soc = require("internet") soc.open("localhost", 2888) soc:write("MOTD") os.sleep(1) motd = soc:read(100) soc:write("MOTD") os.sleep(1) motd = soc:read(100) ...

Оптимизированы наиболее часто используемые методы библиотеки Screen, работающей с экранными буферами: если ранее для каждого рисуемого пикселя выполнялась проверка вхождение в регион отрисовки, то теперь все прямоугольные команды автоматически рекомпонуются, чтобы уместиться в этот регион. Странно, что это не было сделано изначально, но тем не менее скорость перемещения сложных оконных приложений с кучей мелких прямоугольников и картинок (типа местного Finder) ощутимо подросла Ну и забавы ради добавлен метод screen.blur(), применяющий эффект размытия к указанному региону и, опционально, накладывающий цветовой фильтр, а также виджет GUI.blurredPanel, чтобы создавать окна с заливкой в стиле AcrylicBrush из UWP Вообще изначально было реализовано полноценное размытие по Гауссу, но, учитывая мизерные размеры экранов, оказалось, что простого box blur будет более чем достаточно, и визуальной разницы нет. Вопрос прожорливости остается за кадром:

Callback-функции типа onTouch/onResize существуют только для отдельно взятых элементов, а не для каждого GUI.object. Поэтому проще всего "заоверрайдить" метод :close() для закрытия окна, как это сделано в приложениях типа 3D Print. По итогу что в случае callback-функций нужно создавать лишнюю функцию, что в случае "оверрайда", поэтому тут дилемма скорее эстетического характера local baseWindowClose = window.close window.close = function(...) -- Профит baseWindowClose(...) end

Ой, всё, короче, добавил ваш вАнючий глобальный принт, сдаюсь

Добавлена глобальная функция print() и консольная приложуха для простенького I/O в текстовом формате. Заодно добавлена фича фокусировки виджетов в либе GUI, дабы ввод информации производился только в окнах, с которыми юзер "хочет" работать, а не во всех сразу

Он скромничает, хе-хе. В маркете с каждым обновлением публикации происходит автоинкремент версии с шагом 0.01, и вручную мажорку не выставишь. Но вообще это всё он виноват, честно-честно. Вините его

Угу, согласен. Изначально так и сделал - но толково работать педальками и играть с комфортом не вышло. Пробовал также экспериментировать с разбиением ноты по тикам, составляя её из "кусочков" и множества вызовов .process: в этом случае приходится имитировать ADSR-огибающую вместо штатной и смириться с артефактами на "стыках" одной ноты, проявляющиеся даже в локалке, не говоря уже о внешнем серваке Вообще заманчивая идея. Насколько помню, кроме твоего Synth никто не озаботился реализацией DAW в кубаче, всё через внешний софт. В целом да, тут проблем с вводом не возникнет, т.к. сам ввод не столь приоритетен, как конечный результат. А вот бесшовно воспроизвести сложный трек с ограничением в 8 каналов будет всё так же проблематично В любом случае спасибо за уточнение. Видимо, придётся делать комбинированный вариант с опциональным подключением нескольких карт с каким-нибудь хитрым алгоритмом распределения задач

@Fingercomp На днях перечитал сей замечательный гайд, и захотелось ретранслировать по TCP сигналы с MIDI-клавы прямо в кубач, т.к. звуковая плата в теории подходит для игры монотонных мелодий типа "кузнечика". Система вроде простая, но либо я дурак, либо плата не позволяет асинхронно воспроизводить новые звуки до тех пор, пока предыдущий sound.process() не завершён. То есть бесполезно пытаться ставить в очередь новые инструкции типа sound.setFrequency(), sound.delay() на любом из 8 каналов, т.к. они будут игнорироваться вплоть до завершения предыдущих инструкций. Вопрос: а чо делать-то? Есть ли какой-то легальный способ воспроизвести ноту длительностью в 500 мс, а затем ещё одну, но с задержкой в 100 мс после начала предыдущей, позволяя играть на инструменте в реальном времени? В голову приходит только установка нескольких звуковых плат, но это звучит костыльновато. Для чего тогда нужна система 8 каналов, если sound.process() ждёт завершения очереди инструкций на каждом из них? Только для воспроизведения заранее известной последовательности нот?

@BrightYC Фига скилловая софтина, уважаю

Спасибо, фиксану

Жиза, тоже с ними изрядно намучился. В 1.10 зарядники ик2/меканизма почему-то игнорировали действия робота, не воспринимая его как игрока, а в 1.12 всё само починилось. Магия! Пришлось написать несколько вариантов зарядки: первый через контроллер инвентаря и getStackInSlot с проверкой прочности, а второй просто на хопперах и таймере ожидания, который конфигурируется с приложения на компе

Да хоть 5000 строк и Т3 хард в требованиях, всё равно юзабельных аналогов нет, и на данный момент приходится пилить свои велосипеды на базе дубокопа, если нужен кастомный функционал. Лично мне пару лет назад катастрофически не хватало поддержки зарядников инструментов и возможности удаленного управления роботом для возврата на базу, а также сохранения последней позиции раскопок для последующего продолжения работы. Приплюсуй сюда RAM-кеш инвентаря, упаковку ресурсов в стаки, настраиваемый по сети черный список блоков (мало ли булыга на базе кончилась, пусть копается), поддержку апгрейда генераторов и экстренную зарядку на солнечных батареях, анализ прочности и переключение имеющихся инструментов в инвентаре робота, а также "лакшери-опции" по типу вывода карты раскопок на голопроектор/OpenGlasses - и всё, задница. У меня оно не впихивалось в еепром даже с LZ78 и минификацией декомпрессора, поэтому проще было плюнуть и заюзать жесткие диски. В качестве бонуса это позволило декомпозировать кодовую базу на несколько модулей, и сам процесс разработки стал в разы удобнее Я понимаю, что в чужой монастырь со своим уставом не ходят, однако, имхо, тут появляется выбор между дешевизной компонентов и функционалом софта - и на практике, если у игрока уже есть остальные компоненты для робота, скрафтить хард не составит проблем

Во магия, а! У меня даже инсталлер вылетал при инициализации event-либы из-за постоянных конфликтов с местными "потоками", которые дергают pullSignal почём зря. Хотя это было на старых версиях опеноси, возможно, сейчас что-то фиксанули. Ну и мелочи типа отсутствия глобальных component/computer/unicode, которые опеноська зачем-то скрывает из _G, тоже изрядно напрягали

Кек, зашибенски. А как ты решил проблемы вылетов подмененного опеносевского computer.pullSignal в песочнице?

Нет, т.к. оська уже установлена. Тут полная аналогия с реальными компами: ставишь несколько осей на несколько загрузочных томов, а потом через биос выбираешь приоритетный том для загрузки. А биос можно использовать либо штатный, либо сторонний - в зависимости от предпочтений

Да, так и есть. MineOS можно ставить на чистый диск, и командной строки OpenOS не будет, т.к. отсутствует сама OpenOS. Но никто, в принципе, не мешает поставить сразу 2 ОСи на компьютер, и в биосе MineOS (или альтернативном) через Alt выбирать загрузочный диск

Испанский стыд, так вон оно как реализовано... чувствую себя дикарём, шарахавшемся от каждого звука и спешно заменявшего очки на шлем хд

Мяу, это не шифрование, а кодирование. Любой человек, перехвативший сообщение, сможет его декодировать и прочесть, т.к. Base64 не подразумевает наличие какого-либо ключа для дешифровки, обеспечивающего секретность данных. Кроме того, размер закодированных сообщений в среднем на 35% больше оригинала, т.к. это избыточный алгоритм Если тебе требуется именно шифрование, причем такое, чтобы сообщения мог декодировать лишь ограниченный круг лиц, знающих кодовое слово, то потребуется как минимум симметричный алгоритм типа Salsa/RC/AES. А в идеале - с поддержкой "соли" или ассиметричный с парой ключей. Тут уж самописные велосипеды, дата карта или сторонние либы в помощь

Вот это просто офигенно. Ставить оськи с графическими либами для кодовых дверей - нонсенс

А вот это зашибись, да. Даже с картиночками! Прости за резкость, мяу