Fingercomp

Смысл всё это иметь будет только при нескольких компах, потому что задержка уходит на процессор, а не видяху. Но нужен способ передачи данных. Модемы, например, работают с задержкой в 1 тик.

Гм, разве? Настройки же кумулятивны... в смысле, не сбрасываются сами по себе. Как минимум, когда я писал synth (2017-05), они такими были.

Спустя этой просьбы прошёл почти год, когда я написал свой гайд по этой штуке в трёх частях с подробным объяснением. Больше мне не нужно ничего в этом топике, естественно. Ну и по коду: указание волны и процессинг нужно вынести из цикла, а ещё лучше будет заюзать треугольный FM-модулятор.

Критика принимается? Вот и отлично, пора бы мне набивать количество постов здесь. Итак, что мне не нравится. Хотя нет, сначала отмечу, что эта утилита является велосипедом с tape.lua (см. tape wipe). А теперь отбросим этот факт в сторону и проедемся уже по коду. Стиль кода необычный. Обычно люди так ифы делают: -- Вариант 1 if condition then doCode() end -- Вариант 2 if condition then doCode() end Хотя я второй вариант не люблю и так не делаю. Ещё по стилю: всякие операторы типа ==, ~= и т. д. лучше отбивать пробелами. Дальше буду проходиться по порядку строк в пасте. Сначала будет номер строки, потом комментарий, затем под спойлером оригинальный код, а потом как надо. L3. Я сомневаюсь, что "Event" будет работать. Замени на "event" local event = require("event") L11-12. Переменные size и label объявлены без указания local, поэтому они стали глобальными. Глобальные переменные редко когда требуются, а чаще они просто мешают и творят лишние баги. Поэтому когда без них можно обойтись, делайте переменные локальные. local size = tape.getSize() local label = tape.getLabel() L14-19. Ветки отличаются лишь тем, что при not label пишется "N/A". Дальше нигде отсутствие значения не используется, поэтому код можно сократить, просто присвоив "N/A", если соблюдается not label. Для таких ситуаций офигенно подходит оператор or (подробнее). Кроме того, print уже и так ставит \n, поэтому лучше разделить на два принта. label = label or "N/A" print("Tape label: " .. label) print("Size: " .. size .. " bytes") Кроме того, зачем просить пользователя самому отмотать кассету в начало, если то же самое делается одной строчкой кода? tape.seek(-math.huge) L28. Для повторения одного символа несколько раз используется функция string.rep. Переменная опять не локальна. И что значит "x"? local blockSize = 256 local block = string.rep("\0", blockSize) L30-31. Используем вместо 256 переменную blockSize. И устанавливаем её в качестве шага цикла (0, 256, 512, 768, 1024, ...), потому что так логичнее. И мы не цикл итерируем, поэтому имя у переменной i не соответствует цели использования. for pos = 0, size, blockSize do L32-33. Используем переменную block. tape.write сама уже отматывает кассету на позицию, следующую за последним записанным байтом, зачем ещё раз отматывать? tape.write(block) L34. Нет, конечно, можно дать ему заспамить всю консольку прогрессом, но я бы предпочёл немного украсить: заставить его прогресс писать на одной и той же строке. Для этого можно использовать функцию term.clearLine (библиотека term) для очистки строки и io.write вместо print, чтобы не переносился курсор на следующую строку. Первый кусок, который с require, надо поместить в начало файла, где остальные реквайры. local term = require("term") term.clearLine() io.write(pos .. "/" .. size) L37. С ней проблем нет в оригинальном коде. Однако мы изменили вывод прогресса, так что после выхода из цикла на строке, где стоит курсор, будет находиться ещё какой-то текст с прогрессом. Поэтому надо очистить её перед принтом. term.clearLine() print("Tape has been wiped.") Конец. Итого мы получаем вот такой код мечты: local component = require("component") local event = require("event") local term = require("term") local tape = component.tape_drive if tape.getSize() == 0 then print("Tape drive is empty!") os.exit(1) end local size = tape.getSize() local label = tape.getLabel() label = label or "N/A" print("Tape label: " .. label) print("Size: " .. size .. " bytes") print("Press [Y] to wipe the tape. It may take a while.") local _, _, keyCode = event.pull("key_down") if keyCode ~= 121 then os.exit(1) end tape.seek(-math.huge) local blockSize = 256 local block = string.rep("\0", blockSize) for pos = 0, size, blockSize do tape.write(block) term.clearLine() io.write(pos .. "/" .. size) end term.clearLine() print("Tape has been wiped.")

tl;dr: https://gist.github.com/Fingercomp/0773bb0714296c0cb00d70a696d39bb3 Понятия не имею, зачем я сюда об этом пишу, ведь если вы можете этот текст понять, и в оригинале можно прочитать. В любом случае, получил намёк, что три моих статейки про звуковую карту удовлетворительны в какой-то степени, но они на русском. Видите ли, ситуация с документацией спустя полгода после первого поста не улучшилась никак, так что единственный туториал для неё недоступен для понимания тех, кто не говорит по-русски. Поэтому я потратил выходные на перевод постов на английский язык. Заняло это отчего-то дольше, чем я ожидал. Результат на гисте. Все три поста в одном месте. Я там подбросил ещё чутка инфы и терминов и подправил фактические неточности. Мне лень было несколько раз перечитывать один и тот же текст, так что где-то могут остаться очепятки и всякие извороты языковые не к месту. Но если понимаете английский, то всё равно должно быть удобнее, чем бегать по трём статьям здесь, в блоге. Ну а мне редактировать проще. В общем, ссылку я оставил, больше мне сказать нечего.

На обновление это не тянет, да и обновлять тоже нечего. Но раз условие было раз в 2 недели, то это будет текущий прогресс, в общем. Карта более-менее есть. Созданы репозитории для всех частей софта. Пилим библиотечки, которые будем использовать, потихоньку. Тем не менее, я не думаю, что мы весь софт за 2 недели успеем сделать, поэтому ивент может сдвинуться ещё. Я думаю перетащить дедлайн на него куда-то после новых годов. Прогресса почти нет, но в могилах мы не крутимся.

Багофиксы, в основном только они. Вот из того, что добавилось: У планшетов можно получать полноценное направление взгляда игрока. Количество максимальных частей пакета добавлено в информацию об устройстве (та, что computer.getDeviceInfo(). [1.10.2] Интеграция с ExtraCells и Mekanism. [1.12.2] Интеграция с ComputerCraft. Остальное: Изменили рецепт алмазных кусков по умолчанию. Пофиксили область видимости датчика движения. Планшетам разрешили отрубать экран. Дроны адекватно заставили воспринимать чанклодырное улучшение. Item conduits из EnderIO чего-то из микроконтроллеров доставали ненужного. Несовместимость с IC2 Classic устранена. В IRC-клиенте с дискеты пофиксили CTCP. [1.11.2] Какая-то бага с добавлением предметов в улучшение-БД. [1.11.2] И ещё бага с доступом к компонентам вроде дисковода в планшетах. Обновления в OpenOS: Нет необходимости теперь, в кои-то веки, писать = в начале строк в интерпретаторе Lua. Оно автоматически возвращает. Можно в error пихать таблицы, и крашиться не должно. Наконец-то разрешили монтировать системы файловые в существующие директории. Ещё можно примонтировать директорию в другое место. Если вы напишете одну команду и 10 раз другую, то в истории последняя будет только один раз. Не придётся 10 раз тыкать "вверх", чтобы первую команду получить. Фиксили проблемы с загрузкой OpenOS на медленных хостах. Я думаю, это ошибка TLWY, которая при старте кидалась. .shrc может принимать ввод. Пофиксили поиск названия клавиши по коду в либе keyboard. Фикс event.cancel и event.ignore какой-то. Интерпретатор теперь здраво воспринимает ошибки переполнения памяти в сериализаторе. Какой-то TLWY в /bin/tree.lua. Улучшения в vt100 всякие. Код стал ещё уродливее ради уменьшения потребления памяти. Вот такие улучшения. Вот как-то так. Отсюда качабельно.

Ну так в луа и не регулярные выражения! Здесь гораздо более простой аналог — шаблоны. Ещё раз: это не регулярные выражения, ни в коем случае, — шаблоны. Никаких повторений, именованных групп и прочего нет. Обходи повторением элементов шаблона. Инфа по шаблонам: гайд, рецепт.

Я не знаю, почему эту либу считают объектом поклонения, чем-то высоким и совершенным. Да, это полезно, чтобы не думать, а сразу брать готовое. Но это же ведь просто обёртка. Это же ведь просто поэтапная обработка ошибок. Это же ведь 100 строчек — и вся либа. Если кто-то вообще когда-либо читал что-то с сокета в OC, он бы сделал то же самое; он обязан сделать то же самое, иначе бы ничего не работало, ну или бы крашилось всё через раз. Но 10 лайков стоят, тем не менее: либа полезна, да, доки расписаны адекватно, согласен, — немногие осиливают форматирование (или же всё красным жирным шрифтом пишут, чтобы внимание привлечь) и могут писать на техническом русском языке без путания мысли; ничего против автора не имею, ценю труды и очень уважаю за офигенные и сложные либы, которые он выкладывал сюда, — но это уже какой-то культ строится. Но спасибо за некостыльный враппер.

Обновление от 2017-12-02. Движение началось. После нытья я внезапно понял, что мы на тот момент до сих пор даже не представляли, что должны делать и когда. Поэтому на прошлой неделе (2017-11-22 и 2017-11-25) мы провели два совещания в нашем совещательном канале #cc.ru-meetings, первое из которых длилось 3 часа, а второе — 4 часа. Я подождал недельку, чтобы посмотреть, как всё пойдёт — и ведь на самом деле работа началась какая-то. Отсюда и обновление. Сейчас расскажу, что мы нарешали. Планирование Этапы подготовки Во-первых, я разделил всю подготовку к ивента на 4 части, чтобы облегчить планирование: Нулевой этап (0) — это тот, на котором мы сейчас находимся. Участники не могут пока нормально писать свои программы. Как минимум потому, что ни арены, ни софта дано не было. Альфа (α) — у участников есть карта арены и софт. Сервер пока открыт только для организаторов и программистов. Длится месяц. Бета (β) — сервер открывается для участников. Длится пару недель. Релиз (X) — открывается для всех. Мы пока решили, что нулевой этап должен длиться до 2017-12-31. То есть будет очень плохо, если к этому времени мы не осилим написать софт первой необходимости и выложить карту со сборкой. Тогда релиз поставили пока что на 2018-02-23 – 2018-02-25. Карта Её пилю в основном я. И должен закончить по плану 2017-12-03. Это не значит, что после этого ни один блок нельзя будет сменить: просто надо проложить к этой дате все кабели, расставить все компоненты, используемые софтом (например, мониторы). Сейчас у нас есть вот такое: PR-кампания Решено, что каждую пятницу в нашей группе VK будет публиковаться пост про UT#3, начиная с этой недели. Первый пост уже написан. Постараемся выдержать сроки хотя бы до альфы. Кроме того, не реже, чем каждые 2 недели, здесь будет появляться обновление с текущим прогрессом. Чтобы не думали, что мы все померли давно и крутимся в могилах. Софт В UT#3 мы придумали восемь различных софтверных проектов, которые в совокупности затрагивают большинство сфер разработки OC: сеть, интернет-сокеты, очки, GUI, звук, дроны, BIOS, кастомные окружения, лампы, микроконтроллеры и прочее. В команде программистов у нас 5 человек: @Fingercomp, @Totoro, @LeshaInc, @FluttyProger, @MeXaN1cK. Однако если вам тоже захочется помогать пилить что-то, пишите нам в ирку. Будем рады. Всё начинаем пилить с 2017-12-03. Гейм менеджер Сокращённо называться будет "гм". На прошлых этапах мы эту штуку называли игровым сервером, но ведь это очень запутанная терминология: вдруг я не про софт для OC говорю, а про сервер кубача? Поэтому теперь называться будет гейм менеджером это штука. Самое большое отличие этого гм от старых состоит в том, что теперь он будет выполнять роль сетевого маршрутизатора, связывая все компоненты между собою и передавая куда нужно сообщения. Мы постарались отделить от него функции, которые не связаны с бэкэндом, чтобы не допустить тормозов в программе, как на UT#2, где перерисовывался интерфейс, обновлялись очки, выполнялись команды и генерировалось поле, из-за чего счётчик в полтора раза медленнее был. Например, очками теперь управляет отдельный компьютер. Большинство же функций не требуют получения текущего состояния игры, верно? Если игрок нажал на кнопку скрытия панели, зачем это на гм отсылать? В любом случае, теперь гм выполняет следующее: стартует и завершает раунды; хранит текущий счёт и обновляет его периодически; пингует дронов и хранит количество живых; управляет компонентами (включает и выключает их); маршрутизирует сообщения между компонентами. То есть остались только чисто игровые функции. Общение между компонентами будет происходить посредством дебаг-карты. У неё есть замечательная функция debug.sendToDebugCard(address, ...). Общим останется с прошлыми гм то, что юзать будем ту же event-driven архитектуру (то есть коммуникация между частями программы посредством не функций, а ивентов) — а значит, будем юзать libaevent, проверенное решение. Вызвались пилить: @LeshaInc, @Fingercomp, @Totoro. Дедлайн: 2017-12-31. Информационные панели Я до конца был уверен, что экраны по бокам арены не просто так. Оказалось они не рабочие. [member=qwertyMAN] На первом этапе мы их не осилили (это те самые "экраны по бокам арены"), поэтому надо осилить в этом. Они будут показывать карту арены с контрольными точками и их статусами, таймер, счёт и количество живых дронов. Может, ещё что-нибудь. Каждый компьютер с этой программой будет обрабатывать 4 монитора, а всего их 16. Юзать будем либу для больших шрифтов от @LeshaInc. UI рисовать или дабл-бафферингом, натравленным на vgpu, который выполняет одинаковую команду на 4 реальных gpu для параллельного отображения; или без него, если графика окажется несложной. Вызвались пилить: @Fingercomp, @Totoro. Дедлайн: 2018-02-04. Прошивка для дронов Как мы уже писали, программа участников будет запускаться в кастомном окружении, предоставляемом прошивкой, чтобы предоставлять дополнительные удобные функции (обрабатывать сигналы с гм типа пинга, старта и пр.) и блокировать некоторые функции вроде отключения. Дроны будут эмулировать зарядку. Потому что мы не нашли другого способа, при котором бы после разрядки дрон мог бы включиться и уехать на базу. Ну и да, после разрядки дрон отлетает на базу, как я и сказал, и на сервер говорит, что он мёртв. Вызвались пилить: @Fingercomp, @FluttyProger. Дедлайн: 2017-12-31. Прошивка для контрольных точек Все функции мы уже описывали ранее (шлёт коды, ловит сообщения, консультируется с гм). Вызвались пилить: @Fingercomp, @Totoro. Дедлайн: 2017-12-31. Терминалы участников Это гуишные программы, через которые участники смогут записывать на дронов удалённо код и отлаживать свои программы. То есть ошибки в исполнении будут возвращаться на терминал, там же ещё будут видны характеристики дрона. Либу гуишную, похоже, использовать будем от @ECS. Более продвинутой и удобной я не видел пока. Вызвались пилить: @Fingercomp, @Totoro. Дедлайн: 2017-12-31. Сервер OpenGlasses (очкосерв) Как я уже сказал, мы отделили управление очками от гм. Так как очки в OpenGlasses 3 стали субарашительными, у нас в том числе есть персональный вывод. Поэтому: зрители видят: радио (текущий играемый трек, исполнитель, альбом); счёт (точнее, я везде имею в виду под счётом количество захваченных точек); количество живых дронов; ники участников; таймер; лого; карту арены, при клике на которую игрока телепортирует в соответствующую позицию; участники видят:список со всеми их дронами и статусами, а также кнопку суицида на всякий; админы видят: список со всеми дронами всех команд (естественно, он будет как-то разделён); кнопки старта и стопа радио; кнопки старта, старта с отсчётом и стопа игры; поле для изменения продолжительности игры; поля для изменения участников. Помимо этого, при фокусировании в игре на контрольной точке, будет показан её статус. Очкосерв будет обрабатывать как можно больше функций без обращения к гм. Вызвались пилить: @Fingercomp. Дедлайн: 2017-12-31. Рипрадио Тот самый сайд-проект, над которым мы работали. В этот компонент включаются 3 программы, из которых только одна будет в игре. Конвертер аудиофайлов в формат .rip. Это наш выдуманный формат контейнера для DFPWM. По сути, я напилил конвертер любых аудиофайлов (поддерживаемых ffmpeg) в DFPWM с хедерами. Уже сделан @Fingercomp, написан на Rust. Стриминговый сервер. Берёт папку с файлами .rip и стримит их по сокету со специальным протоколом. Сделан на C @LeshaInc. Клиент рипрадио для OC. Читает данные со стримингового сервера и играет музыку через кассетный плеер. Всю метадату отсылает на гм — а тот на очки. Клиент минимальный уже есть (то есть мы уже смогли просто играть с сокета музыку). Осталось её вынести в библиотеку и написать саму программу, которая бы отсылала мету и контролировала всё. Вызвались пилить: @Fingercomp, @Totoro, @LeshaInc. Дедлайн: 2018-02-04. Контроллер ламп Ламп цветных из CX слишком много, чтобы можно было их подключить к гм напрямую. Вместо этого мы их подцепим к отдельному компьютеру, который будет слушать команды и переключать лампы как сказано. Вызвались пилить: @Fingercomp, @Totoro, @MeXaN1cK. Дедлайн: 2018-02-04. Я уже говорил, что вся эта инфа была в ирке. Причём неделю назад. Мы UT#3 пилим только через неё, поэтому если вы хотите присоединиться, то условие частого пребывания в ирке обязательно. В любом случае, мы начали, в кои-то веки, с нормальным темпом пилить ивент. Есть вероятность, что он будет проведён даже до открытия местного сервера, учитывая все обстоятельства.

Ну всё равно. Бывают, опечатываются, когда предлог "для" пишут. Слово — мат, но наказывать-то за него тупо, да?

Лучше пусть мат человек фильтрует. А то будешь потом за "наносабля" и "оскорблять" банить невинных, как на IT было.

Ну тут не грусть, что так медленно, а опасение, что UT#3 закончится, не начавшись. В любом случае, вчера мы 3 часа посовещались о том, как вообще делать мы будем, а в субботу софт обсудим. Определили дату старта приблизительную, к слову: 23-25 февраля. Надеюсь, плясать с нею не придётся.

Обновление от 2017-11-21. У нас всё медленно и печально. А то давно их не писал. Начнём с того, как мы строим карту: 2017-10-31: в первый раз зашли на сервер. 2017-11-02: построили первый вариант карты (спасибо @Xytabich). 2017-11-03 — 2017-11-04: переделывали постройку. 2017-11-20: сделали дорожки и построили крышу. Я ни одного дня не упустил. Я ни в одной дате не ошибся. Интерпретируя, мы получаем вот такие забавные вещи. Арены пока нет, как она выглядеть будет, никто не знает. Софт для ивента писать никто и не думал пока даже (ну так-то как можно его пилить без карты?). Зато сайд-проекты начали. Я, конечно, знал, что к декабрю ни у меня, ни у Тоторы времени особо не будет, но как-то на такой медленный прогресс не рассчитывал. Значит, что же хочу сказать в связи с этим: в январе ивент пройти может если только чудом, то есть к 2 декабря сможем запилить и софт, и карту, и сюда выложить всё. Сейчас я не знаю, смогу ли карту даже сделать к этому времени, а про софт и говорить не стоит. И поэтому мы можем сплыть по сроку на выходные февраля-марта. Это не означает, что мы оттачиваем битьё шароваров вместо работы на ивентом. Есть один сайд-проект, который так или иначе нужно будет сделать для этого UT#3. Им ща занимаемся. К слову, когда пишу "мы", я имею в виду команду, а она сейчас такая: @Fingercomp, который занят или ленится. В редкие дни даже пилит UT#3. @Totoro, который на выходных даёт балы (иначе я не могу найти причину, почему во все выходные у него гости), в будни лопатит легаси, а в остальные дни работает над своим ботом. Как можно догадаться, ничего толком на UT#3 не сделал, а на сайте даже не зарегался. @Fiender, который тоже , хотя и только в ирке. Хостер, гентушник, а про остальные увлечения правила запрещают говорить. Каждый день пишет "rip ut", чем всегда поддерживает разговор или начинает новый.* @LeshaInc, который кодит. Несмотря на репутацию бросающего проекты на полпути, он запилил компонент сайд-проекта полностью, что поразительно. Детали о том, что именно мы пилим, какой прогресс и задачи, ну и прочие вещи про ивент — всё в ирке. На форуме мы спойлерить особо не будем. * Справедливости ради надо отметить, что слово "rip" на нашем канале стало невероятно универсальным, и рипаем мы не только людей и не только в прямом смысле. Антоним, к слову, — unrip.

Ну так стороны-то up и не существует. Если бы поизучал этот вопрос в английском языке, то понял бы, что up — это "вверх", направление, а side — это сторона. Верхняя (top) сторона бывает, да, а вот о стороне вверх не слышал.

Я могу, конечно, написать эту программульку, но лучше и правда нарисовать блок-схему — или иным образом представить алгоритм графически. Lua — язык императивный, поэтому код будет примерно соответствовать нарисованному. Если никак не получится — смотри спойлер. А, и да. В одно сообщение влезали несколько цитат (год назад точно, как минимум), так что мультипостить необязательно. И их ещё можно изменить. Но это мелочи и к топику отношения не имеет.

Переменная со... странным именем не используется — зачем она в коде? В каком магическом ритуале она участвует? Отступов нет — ну хоть не в однострочник код записан, спасибо. У тебя жесточайше криво построена логика программы. Посмотри-то на алгоритм свой (блок-схему нарисуй, если непонятно). На строке 9 ты принимаешь любой ивент — однако дальше код пойдёт, только если ты нажал на клавишу с кодом 28 (иначе первый if завершится, и снова выполнение вернётся к началу цикла). Однако в ифе break. Он, вообще-то, прерывает цикл и выкидывает выполнение на инструкцию сразу после него. Код внутри цикла после break выполняться не будет. Иными словами, у тебя получилось сделать невероятно нерациональную программу, которая ждёт ивента и выходит по нажатию Enter.

Решил больше не ждать с этим. Где-то пару месяцев назад решил начать пилить одну штуку — кукбук, или книгу "рецептов". Изначально задумывалось как сборник просто именно рецептов как в кулинарной книге: тонна кода и немного объяснений; получилось наоборот, естественно, — до того, что в некоторых "рецептах" кода нет, — ну это, наверное, потому что я не умею толком через код объяснять. В любом случае, теперь это сборник полезных туториалов по практическому применению. Он разделён на 3 раздела. Lua — статьи, непосредственно затрагивающие код и написание программ. Сниппеты кода, гайды по функциям. OpenOS — статьи абстракции уровня выше немного. Здесь всё об использовании шелла, стандартных программ и прочих фичах дефолтной оси OC. OC — статьи, не относящиеся непосредственно к разработке программ или фичам OpenOS. Наверное, это in-world штуки всякие, по большей части. Например, инфа о том, как собрать идеальный хрякокоптер или правильно тестировать нанытов. Потом могут быть статьи о всяких блоках, да и прочих фичах самого мода. Когда я сейчас пишу эту запись, в кукбуке есть уже 13 рецептов. Ссылочка на книжку. Заходите, почитайте. Есть слухи, что на гитбуксе можно отсылать пулл реквесты... Они здесь называются чендж-реквестами, но разницы никакой. Если есть идея для ещё одного рецепта и желание написать статью — присывайте эти реквесты; если желания нет — можно написать идею в комментариях. Я пока не особо понимаю, чего ещё бы добавить в кукбук.

Не то имя . Библиотеки, а не методов.

Не way, а path. Это разные слова со схожим, но разным смыслом. Да и не настолько библиотека великая, чтобы об имени спорить. Там ляпы похуже есть.

Обновление от 2017-10-23. Финализация правил. Я поймал Тотору, Тотора поймал меня, ещё и с Файном встретились — в общем, на выходных мы, в кои-то веки, смогли финализировать правила. Ключевые изменения: Контрольные точки будут микроконтроллерами. Находиться они будут в фиксированных местах на карте, поэтому искать их даже не придётся. Мы будем использовать MC 1.12 (1.12.2, если получится). Соответственно, поэтому можно ставить форкнутую версию OpenGlasses версии 3.3.2 — и она, код побери, невероятно охрененная. Решены четыре из семи проблемных вопросов. Смотрите раздел Q&A, где на них даны подробные ответы. Подробнее — в первом посте. Ну а так как теперь правила финализированы, можно, наконец, приступать к основной части — это сервер, карта, арена.

https://fingercomp.gitbooks.io/oc-cookbook/content/openos/autorun.html

Я извиняюсь за честность и мой тон. Нахрена слать ЛС, когда есть топик? Будешь каждому отдельно создавать, да? А если вот как я сейчас, только подключился и хотел бы чем-то помочь, мне телепатом сначала нужно стать, чтобы угадать содержание ЛС? Хватит, ради святого кода, три подряд поста писать с дельтой в пару минут. Поразительно, но в одном сообщении можно ответить сразу на несколько сообщений! Если ты хочешь каждые 5 минут по сообщению отсылать — лучше в ирке вопрос задавать: там как раз нам делать нечего. Когда говорят установить libforms — надо устанавливать. Или командой, как у Дуба, или oppm install libforms, или hpm install libforms, в зависимости от того, что имеется. Почитай гайды по OpenOS. У меня вот есть "От дуба до Мастера" — оно скучновато, скомкано, но всё расписал. Блин, хватит на недопомойки кидать картинки! puu.sh, imgur.com? Почему я должен врубать жабокрипт на сомнительном сайте, чтобы различить буковки на скриншоте?

Окей, новую версию ждать не пришлось год в этот раз. 1.7.0! В наличии много всяких улучшений в OpenOS, баги фиксятся, а не создаются, но каких-либо особых изменений в самом моде нет. Начнём с новых штучек в моде. Версия для 1.11.2 и 1.12.1. Поддержка Forge Energy, интеграция с CC, Project:R3D, WR-CBE, IC2, Hwyla, AE2. Датчик движений можно пихать свободно как апгрейд для роботов. Китайский перевод. Пофикшены фризы монитора у роботов. С 1.12 юзаются ванильные железные наггетсы. Рефакторинг API и кода в целом. Методы getAllStacks и getInventoryName для контроллера инвентаря и транспозера. Наконец-то! Ивент drop посылается и при простом клике (раньше только при таскании). Улучшенная поддержка многожидкостных контейнеров. Вернее, многоконтейнерных блоков. Как-то так. Отсутствующие глифы стали шириною в 1 символ. Бесконечный цикл в мануале. Отличная фича была. Правда, это только со сломанными страницами проявлялось. Роботы не все инструменты адекватно использовали. Теперь все, наверное. Обломали способ загрузить процессор на хостовом компе из игры. Ну, мне обманывать смысла не было, да: в осном фиксы всякие. Зато в OpenOS тонны всякого. Новая библиотека в OpenOS: thread. Туториал попробую когда-нибудь сообразить. Рефакторинг, чистка и прочие такого рода мероприятия. Фиксы всяких прог и либ (ls, lib/event, lib/keyboard). Вряд ли это интересно. loadfile теперь работает с относительными путями. tty вынесен из lib/term; поддержка кодов vt100. Фиксы окружений в load, bin/lua и шелле. Прога pastebin теперь работает через https. Улучшение производительности всего и вся. Здесь же и либа сериализации. ls использует цвета из переменной окружения LS_COLORS, которая теперь содержит коды vt100. @LeshaInc хотел немного славы, поэтому отдельно упоминаю его — он посоветовал. Лэшань же написал bin/tree, которая включается в стандартную поставку. И, конечно же. Запускается быстрее! Жрёт меньше памяти (140 кБ)! Крутой номер версии! Поэтому обновляйтесь. Тем более, что этот релиз имеет наибольшее число поддерживаемых версий. 1.7.10, 1.8.9, 1.9.4, 1.10.2, 1.11.2, 1.12.1. Выбирайте по вкусу на странице релиза. P. S. Оказывается, я давно не писал сюда что-либо. Тогда тизерну в качестве компенсации. Готовлю потихоньку небольшой кукбук с рецептами по OC, OpenOS и Lua. Думаю скоро выложить. Посмотрим, как оно пойдёт.

И, да, ты же в курсе, что у робота максимум 64 слота инвентаря может быть (= 4 апгрейда)?