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

Fingercomp

Гуру
 Профиль  Активность

  • Публикации

    1 629

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

  • Посещение

  • Победитель дней

    283

Записи блога, опубликованные пользователем Fingercomp

  1. Fingercomp
    Приветствую Вас в очередной записи. Решившись, что отвечать на вопросы типа "как скопировать программу на дискету" каждому проходящему — непозволительная роскошь, я и пишу это здесь. Цель: описать процесс постигания магии бессменных белых букв на чёрном фоне, да так, чтобы это было непонятно всем. Эта часть будет необычной в цикле, так как именно сюда я буду выливать прогресс и делать обновления.
    Что же, запаситесь терпением и приготовьтесь скучать, да так, как Вы ещё не скучали, ибо именно в этой Башне лежат все скучные вещи.


    Сложность: просто 25%
    Скучность: средне 65%
    Баланс дубовости: для начинающих 20%

    Опустим такую невероятно сложную вещь, как установка системы, о которой уже было рассказано на нашем форуме. Вы вытащили дискету, нажали [y] и затем [Enter], готовите уже свою мышку к кликательным пыткам, надеясь, что эти буковки на чёрном фоне до установки — всего лишь результат лени разработчиков, дожидаетесь загрузки и... "О, святые криперы, что это?! Они меня замучать хотят этими буковками непонятными?!"
    Что же, приветствуем Вас на борту этой замечательнейшей операционки, работающая на чистом Луа. Основные принципы: Вы можете выкинуть свою мышку (чего, к слову, мы делать не советуем). Всё управление идёт через клавиатуру, как минимум, в стандартных программах. Эта штука чрезвычайно похожа на ОС типа *nix. Если эти 4 знака Вам знакомы, понятны и не вызывают страха — поздравляю! Вы уже на 90% владеете инструментом. Вся система — это такой большой Проводник. Можно путешествовать по разным папками и смотреть их содержимое.



    Первым делом сразу советую выучить английский, хотя бы немного. Всё потому, что русского языка вы просто так не увидите. Документация на английском, подсказки на английском, команды на английском, в общем — всё на иностранном языке. Выучили? Тогда приступим.

    И вот, прочитав истинно скучную штуку (или пропустив, но это не по-крутому, знай), мы трём носик об этот квадрат Малевича, исписанный в лучших традициях русского народа надписями типа "здесь был Вася" "RAM", "OpenOS" и какого-то магического заклинания. И всё — в белой рамочке. А ниже нарисовано решето. Мигает штука, похожая на детальку из "Лего". В общем, непонятно даже, как можно пользоваться такой штукой.  


    ФАЙЛОВАЯ СИСТЕМА
    CWD и ls
    Итак, представьте, что Вы открыли проводник. И сейчас Вы находитесь в папке "/", о чём говорит (-ят) символ (-ы) слева от решётки. То, что там написано, называется текущей директорией. По-английски — CWD (Current Working Directory). Проверить, что находится в текущей директории, поможет команда ls. Введите команду и нажмите [Enter]. Отобразится список файлов, причём, если у Вас монитор второго и третьего уровней, то синим будут обозначены директории, жёлтым — ссылки, а зелёным — программы. Иначе ­же всё будет белым цветом.  

    cd
    Сложно? Это ещё только начало. Допустим, что список файлов в текущей директории Вас не удолевтворил, и Вы хотите большего. Что насчёт перехода в другую папку? В Проводнике вы кликали 2 раза по ней — здесь же придётся вводить имя папки вручную. Команда: cd <имя папки>. Обращаю внимание, что угловые скобки писать не нужно. Они показывают, что аргумент программе обязателен. Впрочем, об этом в другой раз. Допустим, нам вдруг страстно захотелось в папку /bin/. Пишем: cd /bin/. Вуаля! Слева от решётки появляется надпись /bin, и Вы оказываетесь в другой папке.
     

    Пути
    Итак, мы в /bin/. Думаю, нужно ознакомиться с файловой системой ОС. Для каждой папки есть:
    содержимое родитель корень путь

    Содержимое папки мы узнавать умеем — командой ls. А что такое родитель, корень и путь?
    Допустим, есть папка "Файлы". В ней — ещё 2 папки, "Документы" и "Программы". В папке "Документы" будут файлы "отчёт001", "отчёт002" и "отчёт003". В папке "Программы" — "Программы2" и "Игры". Итого, структура нашей системы такова (структура — это описание всего содержимого папки. Называется часто деревом):
    + Файлы | + Программы | | | + Программы2 | | | + Игры | + Документы | + отчёт001 + отчёт002 + отчёт003
    Как видно, файл "отчёт003" находится в папке "Документы". Поэтому, для файла "отчёт003" родителем будет папка "Документы". В общем, это папка, в котором лежит файл или папка. Для "Документы" родитель — "Файлы", для "Игры" — "Программы", для программы — снова "Файлы". Вот так всё запутанно.
    Далее. Взгляните на дерево ещё раз. Как видно, у папки "Файлы" нет родителя. Эта папка называется корнем файловой системы. Все остальные папки так или иначе находятся в корне.
    Путь — это последовательная запись вложенных структур до нужного файла. Сначала папка "Файлы", в ней — папка "Документы", в "Документах" — "отчёт001". Следовательно, у файла "отчёт001" путь следующий: Файлы/Документы/отчёт001.
    В OpenComputers корнем является папка /, с которой всё и начинается. Следовательно, если папку "Файлы" поместить в "/", то для перехода в папку с файлом "отчёт002" можно прописать команду cd /Файлы/Документы/
     

    Абсолютные и относительные пути. ./ и ../
    Если путь начинается с корневой директории, то он абсолютен. Но есть пути относительные данной директории. Например, путь к папке "Игры" относительно "Программы2" таков: ../Игры/. Заметили ../? Этот путь есть в каждой папке и обозначает родительскую директорию (для корня ведёт на саму себя). То есть cd ../ переходит на директорию выше. Если прописать эту команду, находясь в папке "Игры", то Вы окажетесь в папке "Программы". Далее — в "Файлах", а так как это корень, то продолжение ввода не будет менять рабочую директорию.
    Кроме того, папка ./ ведёт на саму себя. То есть Файлы/ равен, например, Файлы/./././././././.
     
    И, напоследок, чтобы просмотреть список файлов без перемещения в нужную директорию, пропишите ls [путь до папки]


    Изначально, я продолжил запись описанием реальной файловой системы на ОС, но решил сократить объём повествования. Потому в следующей части — редактор, справочная система, объяснение структуры папок на ОС. В конце я привожу список новых слов и терминов: текущая директория — папка, в которой Вы находитесь. Известна как CWD (Current Working Directory) ls — просмотр содержимого текущей директории cd <путь> — перемещение по файловой системе структура — описание содержимого директории. Также известна как дерево родитель — предыдущая по вложенности папка. Директория, в которой расположен текущий каталог корень файловой системы — папка, не имющая родителя. Первая по вложенности. В OpenComputers — / путь — последовательная запись вложенных структур до нужного файла абсолютный путь — путь от корня до нужного файла/каталога относительный путь — путь от текущей директории до нужного файла/каталога ../ — ссылка на родительскую директорию ./ — указывающая на саму себя папка ls [путь до папки] — просмотр содержимого заданного каталога



    Повествование запутанное, сумбурное и непонятное, в лучших традициях Башни. Специально писал ночью для такого эффекта. Но, к сожалению, следующая часть будет веселее и активнее, с картинками и красотой. Жду оценок 1/5, игнорирования и злостных комментариев из-за этого.  


    →

  2. Fingercomp

    OC [Lua] [OC] Lamp-o-mat

    Автор: Fingercomp,

    Lamp-o-mat! Это небольшая программулька, которая снова из категории "украшения" (предыдщую программу, часики, смотреть тут). В общем, это гирлянда такая. Для лампочек цветных из Computronics.
    Проста прога как дуб, но выглядит прикольно. В частности, это первая прога с принципом ООП.
    Писалась ночями двумя по заказу @Alex, итог меня радует.
     
    Скачивание в репозитории.
    Паста.
    Гист.
     
    Скриншот:

     
     
    Конфигурация:

     
  3. Fingercomp

    OpenComputers 1.6.1

    Автор: Fingercomp,

    Новая версия!
    Новое: Можно теперь отключать некоторые стороны адаптера с помощью ключа. Очень нужная фича, если требуется контроль в огромном лагодроме. От Vexatos. robot.compare умеет теперь сравнивать предметы, игнорируя метаданные. Например, сравнивать инструменты можно. Достаточно указать опцию. От Vexatos. Очень хорошая фича заключается в том, что теперь апгрейды табличек не игнорят приват просто, а посылают ивенты! От хорошего человека makkarpov. Можно указать белый список владельцев дебаг-карт. От makkarpov. В кубаче 1.8.9 и выше теперь взаимодействовать можно с инвентарями, имплементирующие интерфейс IItemHandler. Кастомные инвентари, то есть. От Vexatos. В кубаче 1.10 ещё можно менять теперь значения в scoreboard с помощью дебаг-карты. От RusselLong. В кубаче 1.10 вернулась интеграция с EnderIO и добавлена продвинутая поддержка проводочков редстоуновых из того же мода.
    [*]Изменения:
    Очень большое обновление OpenOS! От payonel, как ни странно. Перевод на русский усовершенствован был. От @Totoro.
    [*]Починено:
    Можно теперь всасывать полные текущие блоки жидкости. Функции обратной совместимости bit32.lrotate и bit32.rrotate тоже починены были (они очень некорректно работали при некоторых значениях). Это моё. Опции %c и %e для os.date() теперь возвращают более адекватные значения. От gamax92. Перед удалением дрона проверять, происходит ли это на сервере или на клиенте. От joserobjr. Теперь нельзя удалить файлы из devfs. От payonel. Апгрейд опыта не потребляет зачарованные предметы, если он уже наполнен опытом. Несовместимости со Sponge. От Vexatos. Именование ядер (какой-то фикс для LuaJ). От gamax92. Machine.signal теперь не настолько вредный по поводу типов списков. От Vexatos. NPE, наконец-то, который возникает, если какой-либо другой мод требует тултипы до загрузки рендерера шрифтов. os.time и os.date, как ни странно, зависели от часового пояса сервера. От gamax92. Теперь серверные стойки могут быть запитаны, если к ним подведён кабель, вне зависимости от подключения сервера. Очень прикольный баг был, когда кабель запитывал только компоненты, подключённые к этой стороне. Баг с чтением данных с проводов RedLogic. Патч от Vexatos. Теперь адреса файловых систем, хранящихся в NBT, проверяются. Раньше можно было выйти за пределы папки opencomputers выше по дереву. Очень весёлый баг, да. Фикс от gamax92. В кубаче 1.8.9 и выше только что поставленные сисблоки имели буфер энергии размером в 0 единиц. То есть, не имели совсем. В 1.6.1-hotfix.1: после апгрейда все стороны адаптеров в прежнем мире становились отключенными.



    Ссылки на скачивание.
  4. Fingercomp
    Перед тем, как я начну, хочу сразу обратиться к забугорным ребятам, читающим эту запись.
     
    Hey! If you are reading this, please tell Vexatos to document the sound card. The in-game manual page is a meaningless piece of text that explains nothing.
    Documentation is written to help others to get an idea of how something works. The sound card is a complex thing that definitely needs a how-to guide to be used in programs.
    So if he wants the sound card to be used in programs, he should write the proper documentation with the detailed description of each concept, feature, and component method.
    The following is the result of efforts put to understand how the sound card works. It took me several months until I realized how to make a simple beep. How am I supposed to create more complex waves? >_>
     
    Ну да ладно.
     

    Хей! Разбирался я недавно, как работает звуковая карта из CX, и поэтому хочу предоставить результаты своих трудов.
    Как и написано сверху, доков нет, автор мода бездействует, везде уныние и отчаяние, поэтому пришлось действовать по-хардкорному. То есть чтением исходников и научнейшим тыком.
     
    Итак, есть компьютер со звуковой картой. Нужен звук. Звучит просто, м?
     
     
    Звуковая карта даёт нам замечательные функции вроде установки ADSR-огибающей, типа волны, шума простого или из LFSR, амплитудной и частотной модуляции. Но мы тут решили заняться простым звуком, поэтому всякие LFSR, AM, FM безжалостно выкидываем. Получаем такой план:
    Открыть канал. Поставить тип волны. Задать частоту волны. Установить громкость. Обработать.  
    1. Открыть канал
    Э, извините, а что за каналы?
    ...
    В звуковой карте звук генерируется с помощью инструкций, которые выполняются друг за другом. Почти все работают с определённым каналом. Если бы канал был один, мы бы смогли играть в один момент времени только одну, условно, ноту. Чтобы параллельно шло сразу несколько звуковых волн, нужно использовать несколько каналов. На каждом можно задать свои тип и частоту волны, громкость, ADSR-огибающую. По умолчанию таких каналов в звуковой карте 8 штук.
     
    С каналами всё довольно просто: открытый канал генерирует звук, закрытый канал не генерирует звук (правда, нужно будет здесь кое-что поправить, когда будет изучать ADSR).
     
    Открыть канал можно с помощью функции sound.open(channel: number). Закрыть: sound.close(channel: number).
     
    2. Поставить тип волны
    Всего типов звуковая карта поддерживает пять: шум (noise), меандр (square), синусоида (sine), треугольная (triangle) и пилообразная (sawtooth).
     
     

    Waveforms ru [CC BY-SA 3.0 (http://creativecommons.org/licenses/by-sa/3.0) или GFDL (http://www.gnu.org/copyleft/fdl.html)], автор Omegatron (original work)
    Kirill Borisenko (Russian translation; see File:Waveforms for Cyrillic Segment.png)
    Incnis Mrsi (ultimate work), с Викисклада
    Очевидно, что разные типы волн звучат по-разному.
     
    Установить тип волны можно с помощью функции sound.setWave(channel: number, type: number). Видно, что тип волны должен быть числом. Соответствующее типу волны число можно получить с помощью таблицы sound.modes. Например, sound.modes.sine или sound.modes.noise.
     
    3. Задать частоту волны
    Чем больше частота, тем выше звук. Частота 440 Hz соответствует ноте ля в первой октаве. Другие частоты можно найти по табличке на Википедии.
     
    Используем функцию sound.setFrequency(channel: number, freq: number).
     
    4. Установить громкость
    Громкость может быть в пределах от 0 до 1 включительно. Половина максимальной громкости - 0.5. И так далее.
     
    Функция: sound.setVolume(channel: number, volume: number).
     
    5. Обработать
    Чтобы обработать все инструкции, нужно вызвать sound.process(). Но если вы просто возьмёте и вызовете функцию, то ничего не услышите. Дело в том, что, достигнув конца инструкций, звуковая карта прекращает генерировать звук.
     
    Поэтому нужно выставить некоторую задержку в конце всех других инструкций, чтобы звуковая карта подождала перед прекращением воспроизведения звука. Для этого служит sound.delay(delay: number). Задержка указывается в миллисекундах. Например, sound.delay(2500). При этом эта функция тоже является инструкцией, поэтому её можно выставить несколько раз. Однако если задержка превышает 5000 (5 секунд), то звуковая карта выдаст ошибку.
     
     
    Проиграв несколько типов волн, мы всё равно останемся неудовлетворёнными. Ну где это видано, что звук мгновенно нарастает и затухает?
    Чтобы как-то это контроллировать, мы воспользуемся ADSR-огибающей. На Википедии довольно хорошо написано, в чём смысл этого.
     
    Скопируем сюда оттуда пикчу:

    И вкратце распишем суть.
    Если вы хоть когда-либо слышали музыкальные инструменты, вы могли заметить, что громкость звука со временем меняется. У гитары громкость мгновенно нарастает и постепенно затухает, а у флейты нарастает не сразу, например.
    Чтобы очень-очень грубо моделировать эти инструменты, мы используем ADSR.
    Attack - это время нарастания громкости звука до максимальной (последняя устанавливается через sound.volume).
    Decay - время затухания сигнала сразу после достижения максимальной отметки до следующего параметра.
    Sustain - отметка громкости, к которой стремится Decay. Значение 1 - это максимальная громкость звука на канале (установленная с помощью sound.setVolume), 0 - отсутствие звука вовсе.
    При достижении отметки Sustain звук остаётся на этом уровне до "отпускания клавиши" (т.е. закрытия канала).
    Release - время затухания сигнала после закрытия канала, от отметки Sustain до нуля.
     
    Время везде в миллисекундах.
     
    Попробуем? Вызываем функцию sound.setADSR(channel: number, attack: number, decay: number, sustain: number, release: number) до пятого шага. Например sound.setADSR(1, 1000, 500, 0.33, 1000).
    И замечаем, что громкость меняется со временем. Yay!
     
     
    На этом счастливом моменте повествование обрывается. Итоговый код, который можно запустить и послушать примитивный бип:
    local sound = require("component").sound sound.close(1) sound.close(2) sound.open(1) sound.setWave(1, sound.modes.sine) sound.setFrequency(1, 440) sound.setVolume(1, 1) sound.setADSR(1, 1000, 500, 0.33, 1000) sound.delay(1000) sound.open(2) sound.setWave(2, sound.modes.noise) sound.setFrequency(2, 440) sound.setVolume(2, 0.6) sound.setADSR(2, 1, 250, 0, 1) sound.delay(1500) sound.process()
    К остальному, надеюсь, я ещё вернусь в другой записи. Сначала нужно самому понять, как оно работает в версии для CX.
    Поэтому наслаждаться пока приходится только бибикалкой.
  5. Fingercomp
    Он вышел раньше, чем я предполагал — ниже список нового.
    Сила овец и оцелотов в их пушистости. Теперь пушистость можно приложить к делу и питать компы — с помощью ковровых конденсаторов. От обычных конденсаторов они толком не отличаются, но могут генерировать энергию, если по ним ходят минимум 2 пушистых животных: овцы или оцелоты, которые генерируют больше энергии. Все новые процессоры, которые будут скрафчены, будут с Lua 5.3 по умолчанию. Сменить можно так же — шифт-пкм. К беспроводной карточке, которую мы все знали, теперь добавили урезанную версию T1, тоже беспроводную. Она может открывать только 1 порт и стрелять сигналом на 16 блоков, а не 400. Креативная компонентная шина (штука, пихабельная в серверы), которая добавляет 1024 компонента. Логичное дополнение. Роботов можно подключать к компьютерам как компоненты. И менять имя роботов: то, что раньше делалось в наковальне, теперь можно через setName и getName. Робот должен быть выключен, чтобы функции работали. Починены всякие проблемки с рендерингом всяких символов. Блоки-инвентари иногда не сохраняли содержимое при сохранении мира. Дроны с чанклодырями не всегда грузили чанки. Пофикшена интеграция с AE2. computer.addUser неправильно отдавал ошибку как-то. Хитбоксы у кабелей теперь обтягивают их форму. Раньше кабели-пересечения были с хитбоксом на весь блок. Апгрейд крафта не всегда крафтил, когда должен был. Апгрейд крафта крафтил один предмет и ломал рецепт — для всех, в том числе игроков. Весело. Датчик движения как-то коряво работал. Пофикшена работа роботов с предметами-инвентарями вроде жидкостных ячеек IC2. Устранена возможная утечка памяти в сетевом коде. В MC 1.10+: пофикшена getMetadata у дебаг-карты. В MC 1.10+: добавлена getBlockstate для дебаг-карты. В MC 1.12: нельзя было заменить EEPROM дрону. В MC 1.7.10: добавлены getAllStacks и inventoryName для транспозеров с инвентарных апгрейдов. Обновлён французский перевод. В OpenOS: Обновлён install.lua, чтобы работал более предсказуемо. uuid.lua возвращает правильные UUID 4 версии, как в RFC написано. Фиксы всякие поддержки vt100. Утечка памяти при загрузке процессов (есть и такая, даже в Луа). Более конкретные комбинации клавиш: Ctrl+Alt+Delete не будет считаться за Ctrl+Delete, например.



    Вайтлиста измерений для чанклоадера... ну, их пока нет.
     
    Скачать.
  6. Fingercomp
    Многие игроки здесь видели или хотя бы слышали про огромный дронодом, который построил @Asior в былые времена на сервере RoboCraft. С тем чтобы прояснить происхождение этой хаты и оставить о ней заметку в этом клубе, специально для «Новостей подполья» @Fingercomp обратился к создателю постройки и попросил рассказать про неё. Редакция представляет обработанную версию истории.
     
    История начинается в начале мая 2016 года, когда запустился сервер RoboCraft, на который сразу же хлынули толпы игроков, хотевшие «поскорее стать топовыми игроками, обладателями гор ресурсов и, конечно же, новых идей и программ». Туда попал и герой нашего рассказа. Развитие было довольно сложным. Поначалу он «хотел, как обычно, отстроить бункер и спокойно, потихоньку наращивать силы», но этому воспрепятствовал случай: система автоматического расселения игроков закинула Asior невесть куда — в середину заражённого биома. Очевидно, что герой этому не обрадовался. Ему потому пришлось бегать в поисках нового места.
     
     
    Конечно, Asior таки организовал себе временное убежище и начал стремительное развитие в игре. Но в чате игроки часто оставляли ссылочки на скриншоты своих невероятно красивых палат с невероятно крутых ракурсов.
     
     
    Он перерыл огромное число чертежей домов, замков, статуй — и решил построить дрона. Дрона из OpenComputers. Ведь сервер специально разрабатывался для этого мода. Asior зашёл в сингл и долго, упорно воздвигал новые варианты постройки и безжалостно крушил старые. Наконец, он определился с тем, как именно должно будет выглядеть его будущее жилище. Оставалось лишь воспроизвести это всё на сервере. Но здесь и возникла основная проблема: как добыть такое огромное количество ресурсов для строительства? Разрешена она была путём не самым чистым:
     
     
    Впрочем, и того, что он раздобыл, сполна хватило на постройку основного корпуса дрона. Это потребовало огромного числа строительных лесов и невероятных акробатических способностей и дополнительно осложнялось тем фактом, что полученные вечные блоки не перемещались из хотбара. Но стиснув зубы и получая подкормку от щедрых игроков Asior таки построил дрона.
     

     
     
    Потому пришлось придумать, как расширить жилище. Некоторые предлагали соорудить какое-нибудь здание, к которому был бы «привязан» дрон, но, увы, это не вписывалось в местность.
     
     
    Далее настала очередь внутренней отделки: ставились перегородки, размещалось оборудование. А монументальное сооружение, памятник роботу и дрону, стал пользовался большой популярностью, чему создатель не противился: «я был не против, чтобы все желающие посмотрели, как я живу, уточнили какие-то вопросы или помогли чем-нибудь».
     
    С тех пор сервер RoboCraft давно закрыт, но память о роботе и дроне жива до сих пор. Редакция присоединяется к пожеланию героя остроить то, что поражало бы воображение и отпечаталось в приятных воспоминаниях десятков игроков.
     
    И мы всё так же мы призываем вас оформить подписку на «Новости подполья». Годноты здесь много было, есть — а то ли ещё будет.
  7. Fingercomp
    ОБНОВЛЕНИЕ OPENCOMPUTERS ДО ВЕРСИИ 1.5.8!


    Дата релиза: 21-04-2015
    Версия: 1.5.8
    Приветствую Вас, господа и дамы, перед Вами новая версия 1.5.8, о котором я спешу Вас оповестить!
    Взглянем на список изменений:
    Добавлено: Теперь, если бедный робот пытается стукнуться со стеной (он что, в коллайдере живёт?), появляются частицы! Дабы избежать спама частицами, поставлена небольшая задержка... Так что robot.detect() теперь куда нужнее.
    Если Вы игрете в мирном режиме, то наверняка замечали, что та же интерпаутина (а не интерсеть, кстати) требует эндержемчуг. Но где ж его достать-то в мирном режиме? О_о В общем, данное недоразумение поправлено: добавлен файл рецептов для мирного режима.
    Спасибо, Кибер! Ведь у нас русский перевод мануала для чайников в Инглише!

    [*]Изменено:
    Как и было заказано на багтрекере ОС, голограммы отрисовываются куда быстрее. Также на очереди метод для помещения сырого набора инфы (data) для быстрой изменении картинки.

    [*]Пофикшено:
    Опять-таки с багтрекера: теперь дроны умеет ходить сквозь Порталы и не выключаться. Доставщик пиццы между измерениями дождался своего часа!
    Пути теперь в мануале абсолютные. Немцы теперь тоже смогут вполне пользоваться мануалом.
    OpenOS был продублирован в НЕИ (на что я обратил внимание, кстати).
    Дроны! Отставить кушать! Что? Память! Потенциальные утечки при использовании дронов.
    Чуждое мне состояние гонки. Великий Рандом был недоволен этим и отрубал иногда компы.
    Память кушается меньше при таймауте __gc (то бишь __сборщикамусора).
    В OpenOS стандартные потоки I/O были способны закрываться. THNX TO: mpmxyz.
    При фоллбэке в LuaJ компы, которые отрубались при отгрузке чанка, не стартовали снова.
    1.8:
    Цветной текст на мониторе красил другие цветные блоки. А также много всякой рендерной ерунды.
    Поршневой апгрейд. Фиксед.



    На этом всё!
    Следите за багтрекером ОС, там ОЧЕНЬ много интересного! https://github.com/MightyPirates/OpenComputers/issues
    Следите за целями в ОС 1.6! https://github.com/MightyPirates/OpenComputers/milestones/v1.6.0
    Следите за релизами ОС! https://github.com/MightyPirates/OpenComputers/releases/
    Заходите на форум ОС! http://oc.cil.li/index.php?/index
    Предлагайте, о чём мне ещё написать, оставляйте комментарии, оценки — этому всему я буду рад :P
    А также прямые ссылки на ОС 1.5.8:
    1.7.10: https://github.com/MightyPirates/OpenComputers/releases/download/v1.5.8/OpenComputers-MC1.7.10-1.5.8.17-universal.jar
    1.8: https://github.com/MightyPirates/OpenComputers/releases/download/v1.5.8/OpenComputers-MC1.8-1.5.8.19-universal.jar
  8. Fingercomp
    Выключен
    Хост XMPP-сервера был отключён, ищу другой по возможности для настройки.
     
    Итак, хост, на котором был XMPP-сервер, окончательно ушёл куда-то, а вернуться так и не пообещал. Так что пока сервер, который популярностью и не пользовался, будет отключён до нахождения другого бесплатного хоста (буду рад помощи). Планирую запилить на него IRC, плюс ещё парочку других серверов при необходимости. Тем не менее, зарегистрировалось там 8 человек, сообщений написало (вместе с ЛС): 42, а продержался он 3.5 месяца.
     
    Старая запись:

     
  9. Fingercomp
    Ей! Мы дождались, наконец, действительно интересного и полезного обновления OpenComputers — 1.5.18!! Ну, и это ещё четвёртая запись за сегодня))
    Сегодня в выпуске:
    Добавлено: Наномашинки!! Новая система баффов/дебаффов и эффектов. См. 'video. Добавлена функция вращения голограмм. Голограммный проектор, очевидно, второго уровня. Транспозер может быть использован как апгрейд.
    [*]Изменено:
    Благодаря payonel, улучшен механизм автодополнения по [Tab]. Дроны теперь должны сниматься исключительно ключом. Шифт-клик без ключа теперь ведёт к включению дрона, как роботов или компьютеров.
    [*]Пофикшено:
    Потенциальный дюп жидкостей при использовании бочек из ExtraUtilities. Поведение os.date()/os.time(). Несколько других мелких багов. Потеециальный NullPointerException, если робот использует анализатор. Проблемы с рендером определённый предметов, которые держат роботы. 1.8: проблемы рендера при наведении на кнопки в GUI.




  10. Fingercomp

    OpenComputers 1.7.0

    Автор: Fingercomp,

    Окей, новую версию ждать не пришлось год в этот раз. 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. Думаю скоро выложить. Посмотрим, как оно пойдёт.
  11. Fingercomp

    Автокрафт OpenComputers

    Автор: Fingercomp,

    Первая публичная реализация автокрафта на OpenComputers.
    Исполнительным элементом является робот, командующим же — компьютер. Хранилищем предметов здесь выступает МЭ-сеть, с интерфейсом в роли передатчика предметов в обе стороны.
    Для начала использования автокрафта Вам потребуется:

    Компьютер.
    Это главная часть системы, хранящая базу данных рецептов и экспортирующая предметы из дерева крафта в нужном порядке.
    Требования:
    Графическая карта второго уровня. Беспроводная сетевая карта. Процессор второго уровня и выше. Планки памяти уровня 2 и выше (зависит от размеров базы данных). Жёсткий диск уровня 1 и выше (зависит от размера базы данных). Интернет-карта (для скачивания программы). EEPROM. OpenOS Робот.
    Это исполняющая часть системы. По сигналу с модема "craft" она крафтит предметы и складирует полученное в МЭ.
    Требования:
    Апгрейд крафта. Контроллер инвентаря. Инвентарь. Клавиатура. Экран Т1. Дисковод. Интернет-карта (для скачивания программы). Беспроводная сетевая карта. Процессор уровня Т2 и выше. Планки памяти уровня Т2 и выше (возможная комбинация: Т2 и Т1.5). EEPROM. OpenOS. Жёсткий диск первого уровня. МЭ-сеть.

    Это хранящая часть системы, из которой достаются айтемы и в которую кладутся результаты крафтов.
    Требования:
    ME Drive и ячейки. Терминал для доступа к сети (может быть исключён). Интерфейс. После крафта всех необходимых вещей можно приступать к установке. Поставьте робота лицом в интерфейс. Убедитесь, что интерфейс готов к работе. Теперь соберите компьютер. Установите на робота и компьютер OpenOS. Скачайте программы, используя команды ниже, для робота и компьютера соответственно:
    Компьютер:
    pastebin get pXunJUE2 /usr/bin/craft.lua
    pastebin get ixwtEUr6 /usr/bin/recipes.lua
    pastebin get V2Zrnp6F /usr/share/db
    Робот:
    pastebin get tiwidCYt /autorun.lua
    pastebin get S1J5Y7mb /scan.lua
    Теперь запишите адреса сетевых карт на компьютере и роботе (components modem). Откройте файл /usr/bin/craft.lua на компьютере.
    В строке ROBOT замените значение на адрес сетевой карты робота.
    В строке DIR замените значение на сторону экспорта (сторона света, где находится робот относительно интерфейса). "north", "south", "east", "west", "up", "down".
    В строке TECH_SLOTS замените значение на количество слотов внизу робота (инструмент, дискета, контейнеры).

    После этого откройте файл /scan.lua на роботе и замените значение переменной COMP на адрес сетевой карты компьютера.


    Если всё сделано правильно, можно запустить файл /autorun на роботе и recipes на компьютере. Интерфейс у данных программ понятен без моих комментариев. Программа recipes предназначена для управления базой данных: удаление, изменение, добавление, просмотр рецептов. Программа craft на компьютере предназначена для самого процесса крафта. Напоследок, для сканирования рецептов нажмите 7 в recipes, выложите рецепт в роботе и в выделенный слот положите результат крафта. Затем запустите программу scan на роботе и выполните инструкции на компьютере.

    Скриншоты.
     
    Все вопросы, замеченные баги оставляйте в комментариях.
  12. Fingercomp
    Третья часть мануала по OpenOS, где я расскажу об идее монтирования файловых систем, а затем разбавлю повестью о пайпинге.


    Сложность: средне 60%
    Скучность: средне 55%
    Дубовость: для продвинутых 50%
     


    ФАЙЛОВЫЕ СИСТЕМЫ, ЗАКЛЮЧЕНИЕ. УСТРОЙСТВА И МОНТИРОВАНИЕ
    Приступаем к самой сложной штуке в OpenOS — это монтирование файловых систем. Итак, начнём.  

    Логика работы
    Итак, начнём с того, что каждый накопитель — это устройство. У устройства есть свой адрес, который показывается при наведении мышкой. Устройство имеет определённую вместимость. Имеет количество свободной и занятой области. И, наконец, характеризуется наличием метки "Read-Only".


    Допустим, это устройство У имеет адрес Address, вместимость 2 МБ и занято 0.5 МБ.
    Другое устройство Д имеет адрес sserddA и такие же характеристики.
    В OpenOS выбирается одно основное устройство, которое становится корнем. У нас / = У. Оно имеет все стандартные файлы и папки. Но как перейти на устройство Д? Оказывается, в папке /mnt/ собраны ссылки на все устройства. Именами ссылок являются первые 3 буквы адреса устройства. Что интересно, даже если У — корень, ссылка на устройство всё равно будет в /mnt. Вот так: / Устройство У|│┅│+ mnt | |+ Add Устройство У |+ sse Устройство Д |┅
    Монтирование
    Но что, если если у нас таких устройств — 5, например? Помнить все 5 адресов, пусть даже трёх первых букв, писать длинные пути — не-у-доб-но. Согласитесь? Поэтому в ОС есть возможность ручного монтирования. То есть, проще говоря, можно создать ссылку на устройство в любом желаемом месте. Вот только ln здесь не поможет — это ведь не файл, а совершенно другой раздел. Для этих целей служит команда mount. У неё два варианта работы:
    mount -a <адрес> <место назначения> — создаёт ссылку на устройство, адрес которого начинается с <адрес>, в заданной директории <место назначения>. При этом указаннной папки не должно быть до этого на диске. После этого в выбранной директории будут все файлы с устройства. Для устройства Д — mount -a sse /devD/. mount <путь /mnt/адрес> <место назначения> — также создаёт ссылку на устройство в месте назначения, только вместо адреса используется путь типа /mnt/адрес. Для устройства Д это — mount /mnt/sse /devD/.

    Директория, которая является ссылкой на устройство, наызвается точкой монтирования.
     

    df
    Эта команда отобразит все подключённые в данный момент хранилища данных, укажет точку монтирования и состояние. Для нашего компьютера было бы показано следующее:
    Filesystem Used Available Use% Mounted onAddress 512k 2M 25% /Address 512k 2M 25% /mnt/addsserddA 512k 2M 25% /mnt/sse
    Как видите, если у файловой системы несколько точек монтирования, то будет показана информация о каждой из них.
     

    label
    Это у нас названия простые и запоминающиеся. В реальности вместо них были бы эти ужасные длинные непонятные адреса. И чтобы сделать их понятными, можно повесить метку. Что проще: "835f48a-5df9-eb6a-36cb-6ab452d8f16a" или "Programs"? Думаю, всё же второе.
    Чтобы поставить такую метку, воспользуемся командой label, у которой опять два варианта работы:
    label -a <метка или часть адреса> <метка> — устанавливает данному диску метку. label <точка монтирования> <метка> — устанавливает диску по данной точке монтирования метку.

    Кстати, если не указывать метку, то выведется информация о текущей.
    И ещё, установочная дискета имеет метку "openos", а жёсткий диск с ОС — "OpenOS" по умолчанию.

    Информация
    При монтировании первым способом можно вместо части адреса ввести метку.
     
     
     

    ПАЙПИНГ
    Файлы
    Простейший пример — перенаправление вывода echo в файл. Для этого используется >. Смотрите: echo "Hello all!" > hi.all. Содержимое hi.all очищается (или создаётся чистый файл, если его не было), и весь вывод идёт туда. Таким образом, в файле будет следующее: Hello all!
    Если же необходимо из файла содержимое вывести в команду, используется команда <. Вот только примеров такому мне найти не удалось.
     

    Между командами
    Другой простейший пример — команда cat. Если Вы помните, она печатала содержимое всё подряд, и если его больше высоты экрана, то просто обрезается. Так вот, чтобы не случалось такого, используется команда more и пайпинг.
    Сразу скажу, как это сделать. more | cat <файл>. Обратите внимание на |. Этот символ обозначает, что весь вывод из правой команды надо перенаправлять в левую.
    Скажу по секрету — тут можно было обойтись даже без пайпинга. more умеет сама открывать и читать файлы. Но есть нам нужен не файл, а, например, какой-нибудь df — вот тут и потребуется пайпинг.
     
    В любом случае, эта штука является невостребованной, так как она недоделана. Вероятно, в будущем этот недостаток будет устранён, а пока просто запомним три оператора.


    Список терминов: монтирование — процесс создания ссылки на устройство точка монтирования — название ссылки на устройство метка — пользовательское имя для накопителя



    Что же, всё обещанное сделано. В следующей части я расскажу об остальных программах, которые так или иначе помогают в программировании. Жду пожеланий и вопросов.


    ← →

  13. Fingercomp
    Что-то особо нового в последнее время не виднеется, а программы не пишутся. На первый взгляд.
    Но, как известно, перед революцией обычно образуется что-то вроде застоя. Предлагаю окунуться в это болото и глянуть, что интересного происходит с OpenComputers и аддонами.
     
    OpenComputers
    Сэнгар немного прихворал, так что коммитов в последнее время немного. Идёт работа над портом 1.6 под версии MC1.8, делают OpenOS 1.6 (псст, эта игрушка обешает быть очень крутой; больше POSIX и пр.). Низкая активность на баг-трекере, в основном, всякие фич-реквесты.
    В скором будущем расскажу, что именно изменилось в 1.6.
    А пока что здесь можно загрузить на поиграться последнюю версию OC. GitHub.
     
    Computronics
    MOAR FEATURES
    Кхм. Ну, значит, бип-карту на прокачку взяли.
    1 tier: простая beep card; 2 tier: возможность указать одну из четырёх волн (синусоидную, квадратную, треугольную или пилообразную); 3 tier: в разработке, в финальном виде должна позволить создавать собственную волну. В общем, ADSR. Вот это обещает быть бомбочкой.

    GitHub. Dev-версии.
     

    OpenSecurity
    Починены турельки, очередь кейпадов. Добавлены небольшие (7 символов) экранчики на них и возможность менять символы на кнопочках.
    GitHub.
     
    Форумы
    Очень интересная программа: ServerFS. Вкратце: сетевые диски. Подробнее: имеем серв, подключаем к нему RAID и ставим tunnel/modem. На другом же компе свободно подключаемся к серверу. В /srv будут примонтированы все эти диски.
  14. Fingercomp

    Автозапуск программ

    Автор: Fingercomp,

    Если до версии 1.6 все использовали файл /autorun.lua и были довольны, то теперь ситуация несколько изменилась. Поэтому я опишу все варианты автозапуска программ в этой небольшой заметке.
     
    С версии OpenOS 1.6 файл autorun.lua больше не запускается на rootfs (то есть на файловой системе работающей операционной системы). Вот все пять способов, которые можно использовать для автозапуска программ.
    Модифицировать /init.lua.
    Это самый плохой и ужасный вариант из всех. Во-первых, программа будет запускаться до запуска шелла и инициализации библиотек, поэтому возможны краши системы. Во-вторых, если сделать ошибку в файле, то придётся переустанавливать этот файл, что не очень удобно.
    Добавить скрипт в /boot.
    Это не такой плохой вариант, но здесь также возможны ошибки при использовании стандартных библиотек, так как бутскрипты запускаются не в самом конце загрузки.
    Модифицировать /etc/profile.
    Это файл, каждая строка которого последовательно исполнаяется при запуске программ. Проблема в том, что при переустановке системы этот файл будет перезаписываться. Поэтому не вариант.
    Модифицировать /home/.shrc.
    Это самый оптимальный вариант. Но программа будет запускаться при каждом запуске шелла. Если прописать exit в шелле, то программа запустится ещё раз. Если для графических всяких программ это самый лучший вариант, то для одноразовых демонов, которые регистрируют листнеры на ивенты и выходят, вариант не очень хороший, так как тогда листнеры зарегистрируются дважды.
    Использовать систему rc.
    Подробно о ней рассказывал @LeshaInc: http://computercraft.ru/topic/1679-rc-chto-za-zver-takoi/
    Это система, которая позволяет писать своих "демонов" — программ, исполняемых в фоне — и контролировать их из шелла с помощью команд. Графические утилиты так запускать проблематично, потому что возможны всякие артефакты отображения.

    Поэтому используйте варианты 4 или 5 в зависимости от программы, которую требуется запустить.
  15. Fingercomp
    В прошлой части:

    Вы-то прогу скопировать/разархировать и сами можете, вот только если программа зависит от другой, а та — от двух других, и т. д., вам это надоест. Людям надоело. Создали пакетные менеджеры.  
     
     

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

    Итак, у нас есть простая функция, которая составляет список пакетов для последовательной установки без ломаний....
    ...Но время шло, и появилось такое явление как версии. Вот о них мы сегодня и побеседуем.  

    Зачем нужны версии? Нуууу, наверное, чтобы отмечать разные варианты кода.
    Зачем ПМ нужны версии? Хм, чтобы быть уверенным, что при установке пакета, зависимости будут именно такие, которые были при написании кода.
     
    Ну, то есть. Вчера у нас была одна функция сделатьХорошо() и попала в релиз 1.0.0, а сегодня она переименована в сделатьПлохо(), сменили код этой функции, да ещё впридачу накинули ничегоНеСделать(). Всё это в релизе 2.0.0. Но если новый код будет использовать ничегоНеСделать(), то его версия 1.0.0 не устроит — там ведь функции нет. А если нужно будет сделатьХорошо(), то в версии 2.0.0 её уже не будет.
     
    Люди — существа чертовски изобретательные, так что форматы версий у нас тоже всяко-разно изобретательны. Начиная от даты релиза (20161023) и номером билда (1243, она ещё ревизией зовётся), заканчивая полноценным семантическим версионированием. Первые потуги нас интересовать будут не сильно, а вот про SemVer можно поговорить.
     
    Спецификация SemVer прямо говорит: версия задаётся тремя числами, разделённые точкой. Первое число — мажорная версия, увеличивается, когда происходят "ломающие" изменения типа удаления старых функций, второе — минорная версия, которая на новых фичах обычно увеличивается, а третье — патчи, это всякие багфиксы.
     
    Вот сферическая версия в вакууме: 1.2.3.
     
    На самом деле, в описании semver задано несколько правил, например, место пререлиза (например, 1.2.3-dev), метаданных (например, 1.2.3+build-15+20161023+amd64), ну и т.д. Если интересно — можете почитать, ссылочка в конце.
     
    Так вот, здесь попробуем организовать разрешение зависимостей с версиями. Не будем брать пока очень мудрёную систему конфликтов.
     
    Начнём с манифеста. Дополним его указанием версий:
    { "name": "pkg1", "versions": [ { "number": "1.0.0" , "files": [ { "url": "http://example.com/pkg1/1.0.0/file1", "path": "/opt/pkg1/file1" } , { "url": "http://example.com/pkg1/1.0.0file2", "path": "/opt/pkg1/file2" } ] , "depends": [ { "name": "pkg11", "version": "^1" } , { "name": "pkg12", "version": "1.6.2" } ] } ]}
    Ну и по аналогии с другими пакетами. Вот такое чудо у нас должно получиться.



     

    Напомню, чем у нас закончилась прошлая часть:
    def resolveDeps(name, resolved=None, unresolved=None): resolved = resolved or [] unresolved = unresolved or [] if name in unresolved: raise ValueError("circular dependencies detected") if name in resolved: return resolved unresolved.append(name) if not isInstalled(name): manifest = getManifest(name) for dep in manifest["deps"]: resolveDeps(dep, resolved, unresolved) resolved.append(name) del unresolved[unresoved.index(name)] return resolved
    Давайте перепишем эту функцию так, чтобы она работала после наших изменений в манифесты:
    def resolveDeps(name, resolved=None, unresolved=None): resolved = resolved or [] unresolved = unresolved or [] if name in unresolved: raise ValueError("circular dependencies detected") if name in resolved: return resolved unresolved.append(name) if not isInstalled(name): manifest = getManifest(name) version, data = getLatestVersion(manifest) # получаем последнюю версию for dep in latest["deps"]: resolveDeps(dep["name"], resolved, unresolved) resolved.append({"name": name, "version": version) del unresolved[unresoved.index(name)] return resolved
    Всё хорошо и замечательно, вот только толку от того, что мы ввели версии, как-то нет совсем.
     

    А вот далее нам потребуется очень серьёзная либа-парсер семверов. На Python есть semantic_version, которую я ещё портировал на MoonScript — очень доволен. Но это так, будем пока плавать на более высоком уровне абстракции.
     
    Итак, версии. Тот самый граф, ещё раз:



     

    Около стрелочек висят какие-то штуки, ^1, например. Эти штуки, которые мы ещё вписываем в манифесты пакетов, ограничивают варианты версий пакетов, которые можно поставить. ^1 говорит, что можно брать любую версию не менее 1.0.0 и не более следующего мажорного релиза (2.0.0). * говорит, что пофигу абсолютно, какая версия встанет. А точное указание версии, как, например, в случае с 1.6.2, не даёт установиться какой-либо другой версии.
     
    Ну а так как они ограничивают, то и называются они ограничениями (или constriants). Пакетный менеджер — скажем так, классическая задача о соблюдении ограничений. Отнюдь не простая.
     
    Раз есть версии, есть ограничения, нужно эти ограничения, значит, включить в функцию разрешателя. Например, дополнительным аргументом. Давайте так и поступим:
    def resolveDeps(name, vconstraint="*" resolved=None, unresolved=None): resolved = resolved or [] unresolved = unresolved or [] if name in unresolved: raise ValueError("circular dependencies detected") if name in resolved: return resolved unresolved.append(name) # Создаём объект ограничения из строки vconstraint = createSemVerConstraint(vconstraint) if not isInstalled(name): manifest = getManifest(name) version, data = vconstraint.match(manifest) # получаем версию, соответствующую ограничению for dep in data["deps"]: resolveDeps(dep["name"], dep["version"], resolved, unresolved) # и не забываем передавать версию требуемую resolved.append({"name": name, "version": version) del unresolved[unresoved.index(name)] return resolved
    При запуске resolveDeps("pkg1") мы теперь получим
    [ { "name": "pkg1-1-1" , "version": "1.0.1" }, { "name": "pkg1-1" , "version": "1.2.4" }, { "name": "pkg1-2" , "version": "1.6.2" }, { "name": "pkg1" , "version": "1.2.3" }]
    Вот как это на графе будет:



     

    Давайте теперь приспособим функцию install к установке:
    def install(name): depList = resolveDeps(name) for pkg in depList: manifest = getManifest(pkg["name"]) data = getVersion(manifest, pkg["version"]) for file in data["files"]: download(file["url"], file["path"]
    В общем-то, это всё. У нас есть вполне рабочая функция установки пакетов с учётом версии по Semantic Versioning. Однако у неё есть некоторые проблемы.
     

    Ну, во-первых, мы ошибочно считаем, что если пакет установлен, то у него нужная версия. Если у нас уже будет пакет версии 1.12.53, а мы потребуем ^2, то новая версия не поставится. Рискуем попасть на глюки, баги. Кажется, надо просто обновить пакет!..
     
    Но при таком решении невозможно организовать обновление пакетов.
    Вообще. Никак. А почему?
     
    У нас зависимости задаются в версиях. Каждая версия может сменить зависимости. При этом каждая новая версия может не соблюдать ограничения, которые дают зависимые от данного пакеты.
     
    А вот вам адская ситуация:



    Так вот, чтобы обновить выделенный пакет без нарушения всех зависимостей, потребовалось разрешать конфликты версий. Это достаточно сложный алгоритм, и о нём мы поговорим как-нибудь потом. Тем более, мне только предстоит ввести в свой ПМ резолвер конфликтов.
     

    А пока можете почитать спецификацию SemVer.
     
    .
  16. Fingercomp
    Каждый метод компонента в OpenComputers характеризуется его прямотой: есть прямые методы, а есть непрямые. Не раз в ирке разъяснял разницу. Сейчас расскажу и вам.
     
    Предположения:
    Текущая версия мода — 1.7.5. Вы собирали опенкомпьютер. Вы знаете, кто такой компонент, что у него за методы и как их вызвать.  
    С непрямыми вызовами всё просто. Они уводят компьютер в сон на тик. Всегда, при любом условии, даже в случае ошибки, после вызова непрямого метода компьютер до следующего тика работать не будет.
     
    Прямые вызовы такого ограничения не имеют. Один такой вызов может занимать произвольное количество времени. Зависит это от бюджета вызовов.
     
    У компьютеров OC есть бюджет вызовов. Это скрытая безразмерная величина. Каждый тик она сбрасывается до определённого значения. Определено оно так:
    Сначала смотрим на процессор в компьютере. Точнее, на уровень: T1 соответствует 0.5, T2 — 1.0, T3 — 1.5. Затем на каждую из планок памяти. T1 или T1.5 — это 0.5, T2 или T2.5 — 1.0, T3 или T3.5 — 1.5. Получаем несколько чисел. Суммируем, делим на количество — находим тем самым среднее арифметическое, которое и будет максимальным бюджетом вызовов.  
    Практикум:

    T2 процессор → 1.0 Планка T2.5 → 1.0 Планка T3.5 → 1.5 Бюджет вызовов: (1.0 + 1.0 + 1.5) / 3 ≈ 1.167.  
    Пример второй:

    Т3 процессор → 1.5 Планки T3.5 → 1.5, 1.5, 1.5 Планка T2.5 → 1.0 Бюджет вызовов: (1.5 + 1.5 + 1.5 + 1.5 + 1.0) / 5 = 1.4. Достаточно.
     
    Каждый прямой вызов расходует этот бюджет. По умолчанию — ровно одну тысячную его. Самые последние дев-билды мода делают прямые вызовы по умолчанию абсолютно бесплатными. Когда бюджет уходит в минус, компьютер принудительно спит до следующего тика.
     
    Определяет прямоту метода разработчик. Для создания метода в коде мода используется аннотация li.cil.oc.api.machine.Callback. Примерно так (метод hologram.get):
    @Callback(direct = true, doc = """function(x:number, y:number, z:number):number -- Returns the value for the specified voxel.""") def get(context: Context, args: Arguments): Array[AnyRef] = this.synchronized { ... } Если мы видим здесь direct = true, то это абсолютно точно прямой вызов. Если direct = false или отсутствует, то вызов непрямой.
     
    У метода может быть кастомная стоимость вызова. Не 0.001. У дата-карточки такое особенно. Пример (data.inflate):
    @Callback(direct = true, limit = 4, doc = """function(data:string):string -- Applies inflate decompression to the data.""") def inflate(context: Context, args: Arguments): Array[AnyRef] = { ... } limit = 4 читать как "потребляю 1/4 бюджета при вызове". Для сервера выше это 5 вызовов в тик. Недурно.
     
    У видеокарты всё сложно. Вообще, она тоже ограничивает ярость использования через бюджет вызовов. Потому на Т3-комплекте работать будет быстрее. Но количество потребляемого бюджета также зависит и от уровня видеокарточки. Для OC 1.7.5 распределение такое:
     
    Операция Стоимость  T1 GPU   T2 GPU  T3 GPU setBackground 1/32 1/64 1/128 setForeground 1/32 1/64 1/128 setPaletteColor 1/2 1/8 1/16 set 1/64 1/128 1/256 copy 1/16 1/32 1/64 fill 1/32 1/64 1/128  
     
    Поэтому максимально можно вызвать 384 сета в тик.
     
    Чтобы программно определить прямоту методов, есть функция component.methods(addr). Отдаём ей полный адрес компонента, получаем таблицу. В ключах имена методов, в значениях их прямота.
    Или же можно воспользоваться этой таблицей. Она включает все методы всех компонентов, которые есть в OpenComputers.
     
    И наконец, размер бюджета можно сменить в конфиге. Опция budgetCosts занимается именно этим.
  17. Fingercomp
    В прошлый раз я патчил OpenComputers, чтобы пробрасывать нативную либу debug. Пойдём дальше.
    Добавим нативных либ package и os. Прокинем дефолтное окружение внутрь песочницы. Пропатчим мод, чтобы можно было загружать си-модули. Загрузим профилятор и посмотрим, что из этого вышло.  
    На винде ничего не заработает. Гарантирую. Если надо профилировать, ставьте нормальные оси или мучайтесь.
     
    0. Сырцы мода
    Так как мы будем патчить мод, надо сначала подготовить исходники.
    $ git clone https://github.com/MightyPirates/OpenComputers.git $ cd OpenComputers $ git checkout master-MC1.12 $ ./gradlew setupDecompWorkspace На третьей строке версию выбираем по вкусу и выпекаем всё необходимое для компиляции.
     
    1. Нативные либы
    Здесь всё просто. Открываем файл src/main/scala/li/cil/oc/server/machine/luac/LuaStateFactory.scala. Творим следующее:

    Вуаля. Теперь в machine.lua будут глобальные переменные package и _os. Отмечу отдельно, что меняем мы только архитектуру Lua 5.3.
    Уже на этом этапе у нас может сломаться персистентность. Это не страшно: она и должна сломаться.
     
    2. Прокидываем окружение
    Поступаем аналогично тому, что делали в прошлой записи: меняем src/main/resources/assets/opencomputers/lua/machine.lua:

    Внутри песочницы в глобальной переменной env запечатлено будет всё окружение machine.lua.
     
    3. C-модули
    Уже сейчас можно загрузить OpenOS и прописать env.require("libname"). Проблема в том, что C-модули так подключить не получится. Связано это с особенностью Lua. Абстрактно задача заключается в том, чтобы загрузить библиотку Lua с dlopen(..., RTLD_GLOBAL). System.loadLibrary в жаве флаг этот упускает по очевидным причинам, а нам он нужен. Значит, пришло время костылей.
     
    3.1. Подключаем JNA: build.gradle

    Первый ханк нужен, чтобы можно было потом компилировать мод. Почему-то у курсов мавен не работает, а разбираться мне лень.
     
    3.2. Патчим ещё раз src/main/scala/li/cil/oc/server/machine/luac/LuaStateFactory.scala

    Во-первых, подключаем хэшмапу. Потребуется.
    Во-вторых, импортируем JNA. Вернее, его часть.
    В-третьих, патчим код, чтобы он загружал Lua 5.3 через JNA. Магическая константа 0x101 — это значение RTLD_LAZY | RTLD_GLOBAL на моей системе. На фряхе, маке оно может отличаться.
     
    На этом этапе Lua 5.2 не будет работать. Включаться будет только Lua 5.3 из-за конфликта имён.
    Кроме того, JNA — это, вообще, огромная либа. Ради одной функции её подключать — это оверкилл. Но я в тонкостях JVM и JNI не силён. Как уже сказал, разбираться мне лень.
     
    3.3. Компилируем
    $ ./gradlew assemble Выхлоп в build/libs. Берём жарник без суффиксов вроде -javadoc, -api, -sources.
     
    4. Настраиваем профилятор
    Профилятор я написал сам на Rust. Вот ссылка: https://github.com/Fingercomp/lprofile-rs
    Очевидно, нам надо его скомпилировать.
     
    4.1. Компилируем профилятор
    Ставим cargo (мультитул раста такой) любым удобным способом. Собираем:
    $ cd .. $ git clone --recurse-submodules https://github.com/Fingercomp/lprofile-rs.git $ cd lprofile-rs $ cargo build --release В target/release будет лежать liblprofile.so. Тырим его.
     
    4.2. Определяем pwd
    Кидаем пропатченный OC в моды и запускаем игру. Пишем в опенкомпе env._os.getenv("PWD"), чтобы определить текущую директорию. Кидаем либу-профилятор в неё.
     
    4.3. Профилируем
    Наконец, можно заняться мясом.
    local profiler = env.require("lprofile").Profiler() local result = profiler(function() local v = 0 for i = 1, 10e6, 1 do v = v + i end end) table.sort(result, function(lhs, rhs) return lhs.totalTime < rhs.totalTime end) print("Name", "# of calls", "Total time", "Total time, excluding inner calls") for _, v in ipairs(result) do print(("%s\t%d\t%.6f s\t%.6f s"):format(v.name, v.calls, v.totalTime, v.totalSelfTime)) end print("total time:", result.totalTime)
     
    5. Зачем
    Мы получили наполовину сломанную версию OpenComputers: без Lua 5.3, без персистентности. Зато можем профилировать программы.
     
    Этот пост я написал, чтобы не забыть самому. Сомневаюсь, что кому-то интересно заниматься такой норкомагией.
  18. Fingercomp
    Продолжаю рассказывать про Computronics и, в частности, про офигенную звуковую карточку из этого мода. На очереди модуляция: частотная и амплитудная. Помимо этого восполняю долг по основам.
     
    Юзать будем мою прогу synth, которую я недавно зарелизил. Она здесь невероятно поможет.
     
    Звуковая волна
    Вы же знаете, как выглядит звуковая волна?
     




     

    Вот, например, синусоида. Как видно, здесь есть некоторый фрагмент, который повторяется несколько раз. Частота показывает, сколько раз в секунду этот фрагмент повторяется, и измеряется в герцах (Гц или Hz). Чем выше частота, тем больше волна "сжата", скажем так, с боков. Вот как выглядят три синусоиды с разными частотами: 110 Гц, 220 Гц, 440 Гц - на одинаковом масштабе.
     




     

    Кроме частоты, звуковая волна характеризуется таким параметром, как амплитудой. Это, скажем так, расстояние от нуля до самого большого по модулю значения волны. Чем больше амплитуда, тем громче звук. Мы примем за единицу амплитуду сигнала на звуковой карте при максимальной громкости.
    При нулевой амплитуде на графике будет прямая линия вдоль горизонтальной оси.
     




     

    При максимальной громкости у простой синусоиды пиковые значения будут в точках +1 и -1. Они плавно сменяются. Прикольно, да.
     
    Синусоиды - это офигенные штуки, но на них клин светом не сошёлся. Из основных типов волн, помимо синусоид, есть меандр, треугольная волна и пилообразная. Они в таком же порядке изображены на рисунках ниже.
     





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


     

    На самом деле, их можно представить в виде набора бесконечного числа синусоид, о чём когда-то поведал Фурье, но мы с этим заморачиваться не будем: раскладывать на синусоиды в звуковой карте не принято. Поведали об этом для красного словца - и то хорошо.
     
    Теперь, когда рассказал про основы, можно переходить к более весёлым и сложным вещам. То бишь к модуляции.
     
    Модуляция
    Модуляция - это изменение одного сигнала (несущего) другим (модулятором). Изменять можно по-разному - мы будем говорить об амплитудной модуляции и частотной модуляции.
    С модуляцией у нас появляется уникальнейший шанс получить офигенные и красивые звуки, поэтому не будем ждать и сразу перепрыгнем к мясу.
     
    Амплитудная модуляция
    Как я сказал, для модуляции нужны два сигнала: несущий и сам модулятор. Поэтому здесь и далее я привожу на рисунках сразу три графика: несущий сигнал, модулирующий сигнал и результат модуляции.
    Например, выставим две синусоиды с частотой 440 Гц.
     




     

    Итак, амплитудная модуляция - это умножение одного сигнала на другой.
     


    A(t) = C(t) × M(t),


     

    где t - время, C - функция, возвращающая значение несущей волны на моменте времени t, M - то же, но для модулятора.
    Однако не всё так просто. Перед умножением к значениям с модулятора прибавляется единица. Получается, что самая верхняя точка будет на +2, а самая нижняя - на 0. Иными словами, волна перенесена вверх.
     
    На низких частотах - до 20-30 Гц, откуда начинается граница слышимого человеком звука, - графики будут выглядеть как-то так, медленно увеличивая амплитуду от 0 до 4 и обратно.
     




     

    И звучать оно будет как увеличение и уменьшение громкости (количество таких увеличений и уменьшений равно частоте модулятора).
     
    Однако когда частота модулятора становится больше, наблюдаем вот такую картину (частота модулятора равна здесь 330 Гц).
     




     

    Если прислушаться, то станет заметно, что одновременно будто бы проигрываются три звуковых волны. Одна волна имеет такую же амплитуду и частоту, как и несущая. Две другие частоты, задающие боковую полосу частот (диапазон частот, сконцентрированных рядом с какой-либо), находятся так:
     


    f1 = |c - m|,



    f2 = c + m,


     

    где c - частота несущей волны, а m - частота модулятора. Возникающие звуковые волны около этих частот вдвое тише, чем несущая.
     
    В звуковой карте можно поставить амплитудный модулятор следующим образом: sound.setAM(carrierChan: number, modulatorChan: number).
     
    Амплитудная модуляция - забавная вещь, и в то же время тут очень трудно подобрать что-то интересное и красивое. Поэтому переходим к частотной модуляции - там веселья дофига.
     
    Частотная модуляция
    В частотной модуляции модулятор изменяет частоту несущей волны. Как ни странно.
    Почему частотная модуляция уделывает амплитудную? Здесь может быть гораздо больше боковых частот. И потому звучать оно может гораздо круче.
     
    При когда значение на модуляторе увеличивается, повышается и частота на несущей волне.
     
    Звуковая карта поддерживает индекс модуляции. Он задаёт максимальное изменение частоты несущей волны. При индексе, равном 100, частота несущей волны может меняться на 100 Гц вверх и на 100 Гц вниз. Если индекс равен 1000, то частота меняться может на 1000 Гц вверх и на 1000 Гц вниз. Ну и так далее.
    Иными словами, индекс задаёт силу модуляции.
     
    Если частота модулятора будет очень низкой (например, 4 Гц), то получим что-то вроде сирены.
     





    c = 440 Гц; m = 4 Гц; i = 200


     

    С повышением частоты получим вибрирующий звук. И потом услышим дополнительные частоты.
     





    c = 220 Гц; m = 880 Гц; i = 660


     

    Как видно, получившаяся волна получилась довольно сложной.
     
    Установить модулятор в звуковой карте можно с помощью функции sound.setFM(carrierChan: number, modulatorChan: number, index: number).
     
    И не забывайте про ADSR-огибающую: из однообразного тона можно получить довольно интересный звук. Как работает эта штука, я рассказывал.
     

     
    На этом всё. Из всех фич остался неразобранным лишь шум LFSR, но там штука очень и очень странная и непонятная.
     
    Наверняка всё равно остались некоторые вопросы по поводу модуляции. Поэтому за дополнительной информацией я предлагаю обратиться к другим сайтам. Вот несколько очень полезных ссылочек, где есть примеры звука и детальное описание:
    FM Synthesis - The Synthesizer Academy Frequency modulation synthesis - Wikipedia FM Synthesis - Music and Computers Modulation synthesis - Wikibooks (здесь рассказывается про амплитудную модуляцию в том числе).

    Ну и используйте прогу synth, чтобы удобно было изучать звуковую карту.
  19. Fingercomp
    ПОЛНЫЙ ОБЗОР



    Computronics версии 1.5.5



    Часть третья: Карточки


    Приветствую Вас, уважаемый читатель! Думаю, самое подходящее время, для того, чтобы написать новую часть обзора CX. В данной части я расскажу всё о карточках, которых тут как раз четыре вида:
    Beep Card (бипающая карта) Spoofing Card (карта-маскировщик) Particle Card (карта частиц) И, конечно же, Self-Destruct Card (карточка самоуничтожения).


     


    I. Beep Card.
    a.k.a. "Бипающая карта"
    Данная карта предоставляет продвинутый аналог системного динамика, который позволяет проигрывать сразу несколько звуков. Принимает таблицу следующего типа:


    Функции: beep.beep(freqLength:table):Boolean — запускает "аккорд" из таблицы freqLength, в которой записаны для каждой пары частота и длительность. beep.getBeepCount():Number — возвращает текущее количество проигрываемых нот.


    Предмет:
     
     


    II. Spoofing Card.
    a.k.a. "Карта-маскировщик"
    Данная карта позволяет отправлять сообщения с возможностью указывания адреса отправителя! Уже начали думать над взломом Банка? Тут-то и придёт конец вашей идее. Данная карта работает только для проводных сетей, но не для беспроводных, к сожалению.  
     
     

    Функции.
    Те же, что и у обычной сетевой карты, но к функциям отправки сообщений в качестве необязательного первого аргумента можно передать желаемый адрес отправителя.  
     
     

    Предмет:
     
     
     
     
     

    III. Particle Card.
    a.k.a "Карточка частиц"
    Данная карточка позволяет спаунить частицы в зоне 16х16х16 блоков с центром в блоке, где она находится. Полная таблица частиц доступна здесь: http://minecraft.gamepedia.com/Particles  
     
     

    Функции: particle.spawn(particle_name:String, x:Number, y:Number, z:Number[, speed:Number]):Boolean || particle.spawn(particle_name:String, x:Number, y:Number, z:Number[, x_speed:Number, y_speed:Number, z_speed:Number]):Boolean — заспаунить частицу particle_name по определённым относительным координатам с определённой скоростью.


    Блок:
     
     
     
     
     

    IV. Self-Destruct Card.
    a.k.a "Карточка самоуничтожения"
    "Каждый нормальный цивилизованный житель нуждается в данной штуке", — гласит тултип к этой карточке. И он, знаете, прав!
    Я думаю, объяснять, что эта карточка делает, мне не нужно. Просто приведу список функций.  
     
     

    Функции: self_destruct.start([timer:Number]):Number — устанавливает таймер на самоуничтожение. Если не указано, равно пяти секундам. Таймер самоуничтожения остановить или отредактировать невозможно! Трижды подумайте, прежде чем запускать отсчёт! self_destruct.time():Number — возвращает оставшееся время до самоуничтожения.


    Предмет:


     

    Вот я и закончил рассказывать о карточках в данном моде. Остались только апгрейды и предметы интеграции с другими модами, но о них я уже вряд ли буду рассказывать. А пока Вы можете оставить комментарий, подписаться на запись и поставить оценку)
  20. Fingercomp
    Приветствую Вас, уважаемый читатель! Рад сообщить о том, что, спустя целых 24 дня, наконец, отрелизилась версия 1.5.15. Изменений маловато, но перечислить, думаю, не помешает.
    Добавлено: Режим доступа к накопителям низкого уровня. То есть, это является, по сути, одним "файлом", в который можно писать и из которого можно читать. Может быть полезным. Что? Мало карт данных? Не проблема. Теперь они различаются по уровням (бесполезная и даже неприятная фича ) Фича из разряда "НАКОНЕЦ-ТО!!!" Две функции для контроллера инвентаря: isEquivalentTo() и areStacksEquivalent(). Они позволяют определять, есть ли общие категории OreDict у обоих предметов. Всё больше мы переезжаем на Луа 5.3. "Новая"-старая либа bit32 для обратной совместимости. Перехватывание и возврат значений чисел различных типов в сигналах. Срочно бежим дизассемблировать кольчужную броню! Ибо добавлен чёрный список для него, и кольчуга там по умолчанию. Что? Только в 1.8 редактирвоание NBT? Да? Уже нет. Для дебаги добавлена функция управления NBT (спасибо gamax92).
    [*]Изменено:
    Использование правильного дефолтного шаблонного премета в лутогенераторе, для помощи работе другим модам.
    [*]Пофикшено:
    Сообщение computer.stopped. При отключении компьюетра, например, не закрывались сокеты. Переборщили с правкой времени копания. Как, что — не указывается. Если компьютеры остановились неожиданно, крашилось всё (бежим крашить сервер, пока не поздно!) Дедлок потенциальный на работающих компьютерах. Нестабильный мануал: деление на нуль. В интеграции с АЕ2 была небольшая проблема. Наконец-то. Утечки памяти в серверных стойках (кажется, именно это и происходило) были устранены. Состояние гонки возникало между ServerThread и ClientShutdownThread. Всякие очепятки и опечатки в мануале (спасибо Shuudoushi).



  21. Fingercomp
    ДВАДЦАТЬ! Новая версия, 1.5.20, готова к скачиванию. Рассмотрим изменения:
    Добавлено: Функция compareStackToDatabase для контроллера инвентаря и транспозера. Конвертер для обработки информации о зачарованиях. Французский перевод в мануалах. От Pyeroh. Перевод на немецкий язык в мануалах. Подготовлен Shadow1Raven. Можно отключить излучение света для голографических проекторов.
    [*]Изменено:
    Обновлено API для Forestry.
    [*]Исправлено:
    Скорость ломания кабелей с мультиблоками FMP. Нанотапки дают эффект замедления, если они разряжены. Несовместимость с Чизелем, которая позволяла делать из обычных сундуков эндер-сундуки. O_o Отсутвие проверки NBT-данных при объединении предметов, полученных от агентов, при ломании блока. Наниты не работли в других измерениях. Вероятный краш при использовании команд OpenComputers. Продолжение эпопеи о зарядниках: вероятный краш при нескольких таковых. Переполнение, когда кто-то особо тупой устанавливает фигалионные размеры дисков. Завышенная задержка в релеях.



  22. Fingercomp

    OpenComputers 1.6. #1

    Автор: Fingercomp,

    Прогулка с экскурсоводом по обновлённой части парка "OpenComputers". Глянем на новые вещи и попытаемся разобраться.
     
    Начнём с самого значительного изменения. Серверные Стойки.

    Ну тут всё интересно. Пугающая штука теперь — интерфейс стойки.


    А на хотбаре у меня лежат орудия пыток.  

    Думаю, предпоследний предмет опознали — это сервер T3. По нажатию ПКМ этим предметом всё так же открывается интерфейс подобный компьютерному, куда можно вставить компоненты. Заменил я его на креативный, так как я играю в креативе, но уровень не так важен.  

    Кладём три предпоследних предмета в стойку. Видим эту страшную картину.


    Но у нас же вроде гайд, поэтому добавим стрелочек.


    (2) — это сервер креативного уровня. В нём стандартный набор компонентов + инет- и беспроводная сетевая карты.
    (1) — это Server Terminal. Об его функции я расскажу позже.
    (3) — специальный дисководик для серверов. Вместо отдельного чукчёмного блока. Функции абсолютно те же.  

    Сразу скажу, что (6) — это та же кнопка, что и [internal/External] в прошлых версиях, а так как её практическое использование нулевое, я промолчу про её функцию.  

    Справа от слотов для серверов и модулей есть 6 линий разноцветных (7). Под каждой линией есть изображение стороны игральной кости (4), символически обозначающее эту линию. Их расшифровка — (5). Получается, для каждой из пяти сторон стойки (передняя не считается) в интерфейсе отдельная линия.  

    Напротив слотов с предметами на линиях образуются точки (9), (10), .... Они требуются для соединения компонентов для серверов . То есть, подключив сервер (2) и компоненты к нижней стороне в интерфейсе, кликнув по большим точкам на линиях, для сервера (2) становятся доступны Server Terminal (1), Rack Disk Drive (3) и компоненты с нижней стороны. Неожиданно просто.  

    А что же за маленькая точечка (8) напротив сервера? Оказывается, она служит для подключения сетевой карты в сервере к какой-либо стороне. Действует так же, как и в прошлых версиях.  

    Теперь про (1), как и обещал. Если раньше всё было очень просто — берём Remote Terminal, подключаем и просто работаем, то теперь всё плохо.
    Эта штука позволяет подключённому к этой же стороне сервер у работать с удалёнными терминалами. Для этого берём Remote Terminal и делаем им ПКМ по компоненту в серверной стойке. Думаю, опознаете. Если загорится лампочка на компоненте в стойке — всё ОК.
    Если же тратить ресурсы на эту штуку не хочется, достаточно просто от указанной стороны компонентов провести кабель к монитору и клавиатуре.  

    "Эм, а как включить сервер?" Теперь всё управление ими ведётся через ПКМ по серверу в стойке. Щёлкаем и можем включить сервер, потушить его и даже сменить компоненты во время работы!  

    Кстати, о дисководах. В него и в дисковод обычный можно вставлять и изымать дискеты через Шифт-ПКМ. Очень удобно.  
     
    Теперь сходим к роботу, так как в OpenComputers появился новый апгрейд: торговый.

    Торговый апгрейд для робота — апгрейд второго уровня, при подключении предоставляет компонент "trading" .
    У него всего одна функция — trading.getTrades() , возвращающая таблицу предложений жителей в радиусе 8 блоков от робота. Каждый элемент представляет собою одну сделку одного из жителей. Структура: {getInput = function():table, table, getOutput = function():table, isEnabled = function():boolean, trade = function():boolean[, string]}

    Функция getInput() возвращает таблицы с описанием необходимых предметов. По сути, это то же описание, что возвращает контроллер инвентаря — метаданные, имеет ли нбт-теги, имя предмета, его айдишник, максимальное повреждение, размер стэка и количество предметов, необходимых для торговли. Если второй предмет не требуется для торговли — вторая таблица будет равняться nil .
     

    Функция getOutput() действует по схожему с предыдущим принципу, только возвращает таблицу с описанием выходного предмета.
     

    Функция isEnabled() возвращает, интересна ли эта сделка на текущий момент жителю. Как известно, после 7 сделок она блокируется. Для разблокирования надо совершить другую сделку с этим же торговцем.
     

    Функция trade() , наконец, совершает сделку. Её условия: в инвентаре робота должно быть достаточное количество предметов для сделки, а предложение должно быть активно. Если всё верно, предметы обмениваются в инвентарь робота.
    Ошибки:
    false, "not enough items to trade" — в инвентаре робота недостаточно предметов для торговли.
    false, "trade is disabled" — житель более не заинтересован в этом предложении (было совершено 7 сделок).
     
    Кроме того, ещё одно мелкое изменение — для дисковода появился собственный компонент "disk_drive". Он есть только у Rack Disk Drive и Disk Drive, но не во встроенных в компьютер.

    Функция isEmpty() возвратит статус дисковода — есть ли в нём диск.  

    Функция eject([velocity]) выплюнет диск из дисковода. Если дать как аргумент число (числа более 1 смысла не имеют, так как эффект тот же), диску передастся определённая скорость.
    Вот пример для максимальной скорости:
     
    Ещё из изменений — интернет-карта.

    Функция request() принимает третьим опциональным аргументом таблицу хедеров. Например, {["Accept-Encoding"] = "application/json"} . Это очень крутое изменение — так, для работы с чатом форума с OpenComputers теперь нет никаких технических преград. А ещё можно наконец-то запилить логин на сайты... Ах, применений много.  
    Для модняков. Если дронотапки совместить с красителями, как кожанку, то неон на них покрасится.


    Для смытия краски достаточно кинуть тапки в ванильный котёл с водой, как кожаную броню.


    Если у меня хватит духу написать вторую часть, то, скорее всего, я начну рассказывать об изменениях в OpenOS 1.6. Ибо материала там тонны.
    Пока что не забудьте проголосовать в опросике сверху. Порадуйте диванных аналитиков.
  23. Fingercomp

    Парсер CSV

    Автор: Fingercomp,

    CSV идёт от Comma-Separated Values, что, в общем, довольно точно описывает этот формат хранения таблиц. Вот типичная таблица:
    aaa,bbb,ccc,dddeee,fff,ggg,hhh
    Как видно, строки отделяются \n, а ячейки ­— запятой. Последняя строка может иметь или не иметь \n.
     
    Формат очень простой. Описывается он в RFC 4180. Там всего 7 пунктов. Ну а раз простой, давайте соорудим парсер.
     
    Вот у нас есть строка aaa,bbb,ccc,ddd\neee,fff,ggg,hhh. Задача: сделать из неё
    [ [ "aaa", "bbb", "ccc", "ddd" ], [ "eee", "fff", "ggg", "hhh" ]]
     
    Так как позже я немного усложню парсер, очевидный вариант со split, которая делит строку, опустим. Сделаем так:
    def parse_csv(s): # Сюда идёт результат result = [] # Текущая строка row = [] # Текущая ячейка cell = "" # Проходимся по строке for i in range(len(s)): # Текущий символ c = s[i] if c == ",": # Если символ — запятая, закрываем ячейку row.append(cell) cell = "" elif c == "\n": # Если это перевод строки, то закрываем ячейку и строку row.append(cell) cell = "" result.append(row) row = [] else: # Любой другой символ добавляем в ячейку cell += c # Возвращаем результат return result
    Запускаем:
    >>> parse_csv("aaa,bbb,ccc,ddd\neee,fff,ggg,hhh\n")[['aaa', 'bbb', 'ccc', 'ddd'], ['eee', 'fff', 'ggg', 'hhh']] >>> parse_csv("aaa,bbb,ccc,ddd\neee,fff,ggg,hhh")[['aaa', 'bbb', 'ccc', 'ddd']]
     
    Действительно, в конце может и не быть \n. Давайте поправим:
    def parse_csv(s): result = [] row = [] cell = "" for i in range(len(s)): c = s[i] if c == ",": row.append(cell) cell = "" elif c == "\n": row.append(cell) cell = "" result.append(row) row = [] else: cell += c # Если ячейка не пуста if cell: # Закрываем ячейку и строку row.append(cell) result.append(row) return result
    Проверяем:
    >>> parse_csv("aaa,bbb,ccc,ddd\neee,fff,ggg,hhh\n")[['aaa', 'bbb', 'ccc', 'ddd'], ['eee', 'fff', 'ggg', 'hhh']] >>> parse_csv("aaa,bbb,ccc,ddd\neee,fff,ggg,hhh")[['aaa', 'bbb', 'ccc', 'ddd'], ['eee', 'fff', 'ggg', 'hhh']]
    Замечательно.
     
    Почему я проверяю только ячейку, а не строку ещё? Просто пустая ячейка и непустая строка может быть только тогда, когда на конце строки висит запятая. aaa,bbb,. А это явно запрещено по RFC.
     

    В текущем виде в ячейке у нас не получится хранить \n и ,. Если первый символ ещё кое-как, то без запятой как-то совсем не весело, верно?
    На наше счастье, в спецификации есть и это. Ячейку можно поместить в двойные кавычки (", кто не понял), тогда до следующей кавычки обрабатываться \n и , не будут.
     
    Давайте улучшим наш парсер, добавив поддержку этих самых кавычек. Так как у нас посимвольный парсинг, сделать это гораздо проще. Вот так:
    def parse_csv(s): result = [] row = [] cell = "" # Начиналась ли текущая ячейка с кавычки quoted = False for i in range(len(s)): c = s[i] if quoted: if c == '"': # Закрывающая кавычка quoted = False else: cell += c else: if c == '"': if not cell: # Открывающая кавычка в начале ячейки quoted = True else: # Кавычка в середине строки: запрещено return False elif c == ",": row.append(cell) cell = "" elif c == "\n": row.append(cell) cell = "" result.append(row) row = [] else: cell += c if cell: if quoted: # Где-то не закрыли кавычки return False row.append(cell) result.append(row) return result
     
    Проверяем:

     
     
    Всё верно, кроме последнего. В середине строки в закавыченных строках эти самые кавычки должны быть экранированы вот так: "". Например: "aaa""bbb,ccc",ddd,eee. Давайте починим и это.

    def parse_csv(s): result = [] row = [] cell = "" quoted = False # Является ли предыдущий символ кавычкой prevQuote = False for i in range(len(s)): c = s[i] if quoted: if c == '"': # Помечаем, что у нас есть кавычка в середине строки. # Она может быть экранированной. prevQuote = True quoted = False else: cell += c else: if c == '"': if not cell: quoted = True else: if prevQuote: # Если у нас прошлый символ был кавычкой, # то получаем экранированную кавычку. cell += '"' quoted = True prevQuote = False else: return False elif c == ",": row.append(cell) cell = "" # Кавычка была закрывающей prevQuote = False elif c == "\n": row.append(cell) cell = "" result.append(row) row = [] # Кавычка была закрывающей prevQuote = False else: if prevQuote: # Мы ждали кавычку или закрытие ячейки. return False cell += c if cell: if quoted: return False row.append(cell) result.append(row) return result
     
    Опять тестируем:

     
     
    Вот и всё. 44 строки кода на Python — и мы можем парсить CSV.
    Я также переписал парсер на Lua, опубликовал его в OPPM под libcsv. Можете качать и радоваться. Вот сырцы.
     
    Ну и надеюсь, это было менее сложно, чем мои записи про пакетные менеджеры до этого, и вы смогли прочитать это .
  24. Fingercomp

    Advanced Term [OpenOS 1.6]

    Автор: Fingercomp,

    Тут полгода назад я описывал изменения в OpenOS 1.6 и среди прочего я упомянул какие-то окна в либе term. Пришло время описать всю либу term.
     
    Прежде всего, рассмотрим понятие окна. Окно — это таблица типа такой:
     

    {x = 1, y = 1, fullscreen = true, dx = 0, dy = 0, w = 0, h = 0, blink = true} По порядку.
    x, y — это позиция курсора. Ну тут всё предельно ясно. fullscreen — тоже достаточно очевидно. Находится ли окно в фулл-скрине или нет. dx, dy — это смещение окна отновительно левого верхнего края видеокарты. w, h — это всё ширина и высота окна. blink — опция, с помощью которой можно отрубить (и потом вернуть) мерцание курсора.
    Ещё одно понятие, которое нужно обязательно ввести, — это viewport (далее обзывать буду это как вьюпорт). Переводится как "окно просмотра", применительно к нашему контексту это слово означает пространство, в котором можно рисовать всякие символы.
     

    Вот есть монитор из OC. Какой у него вьюпорт? Вроде как очевидно, прямоугольник от левого верхнего символа с шириной и высотой, равный разрешению. Говоря проще, это то, что вы видите в интерфейсе монитора, когда по нему кликнете.
     
    Это было так до версии 1.6. В новой версии появилась функция setViewport, которая позволяет уменьшить видимую часть экрана, оставляя разрешение прежним.
    То есть, если вы на мониторе 3 уровня пропишете gpu.setViewport(80, 25), то всё, что было в пределах прямоугольника шириной в 80 и высотой в 25 символов, останется видимым. Остальное пропадёт. А для вас это будет выглядеть, будто просто сменили разрешение.
    Но при этом вы можете продолжать использовать оставшуюся, невидимую часть экрана. Сетить символы, рисовать квадраты. Как прежде. Только вот юзеры это не увидят.
    А потом можно будет скопировать область из невидимой части в видимую, чтобы показать готовую картинку.
     
    Вернёмся к либе term. Вот то самое "окно", о котором я говорил чуть ранее, — это же и есть самый что ни на есть вьюпорт. Поэтому, когда в либе будут функции с умонинанием window или viewport, нужно понимать, что речь там идёт именно про окно, описанное нами ранее.
     
    Итак, это всё была теория. Теперь будем, наконец, изучать функции либы term.
     
    Первая функция, которую изучим, — это term.internal.open([dx: number[, dy: number[, w: number[, h: number]]]]). Принимает 4, как видно, аргумента, которыми можно задать параметры окна. По умолчанию равны 0.
    Возвращает простую таблицу с установленными параметрами. Её я указывал выше. Ничего особенного.
     
    Этому окну следует присвоить gpu с прокси видеокарты для данного окна и keyboard с адресом клавиатуры для данного окна, опять же.
    Можно просто вызвать term.keyboard(window) — тогда автоматически выберется главный компонент.
    А ещё нужно к выбранной видеокарте прицепить нужный монитор.
     
    Как-то так:
     

    local com = require("component")local term = require("term")local screenAddr = "7d0180fd-541c-dacc-579f-683a3a3e2b67"local gpu = com.proxy("58fa8c35-60f9-d49a-5e14-4a57f3769463")local window = term.internal.open()window.gpu = gpugpu.bind(screenAddr)term.keyboard(window) Есть функция term.setViewport([w: number[, h: number[, dx: number[, dy: number[, x: number[, y: number[, window: table]]]]]]]). Если последним аргументом передать наше окно инициализированное, то значения для остальных аргументов подберутся автоматически, используя параметры видеокарты окна. Этой командой мы завершаем подготовку окна для работы.
     

    Но есть вариант попроще. term.bind([gpu: table[, window: table]]) — привязывает видеокарту к окну и вызывает функцию выше для установки стандартных значений. Очень удобно.
     
    Вот итоговый код:
     

    local com = require("component")local term = require("term")local screenAddr = "7d0180fd-541c-dacc-579f-683a3a3e2b67"local gpu = com.proxy("58fa8c35-60f9-d49a-5e14-4a57f3769463")local window = term.internal.open()gpu.bind(screenAddr)term.bind(gpu, window)term.keyboard(window) Давайте теперь использовать это окно во всю мощь. Чтобы потом не отвлекаться, сначала перечислю список скучных функций.
    term.gpu([window: table]) — возвращает прокси видеокарты для данного окна. term.isAvailable([window: table]) — говорит, готово ли окно к работе. term.keyboard([window: table]) — возвращает адрес клавиатуры для данного окна. term.screen([window: table]) — возвращает адрес монитора для данного окна. term.getGlobalArea([window: table]) — возвращает значения dx + 1, dy + 1, w и h для данного окна. term.getViewport([window: table]) — возвращает значения w, h, dx, dy, x, y для данного окна.
    А теперь настало время кое-чего поинтереснее. Например, term.drawText(text: string[, wrap: boolean[, window: table]]). Рисует текст, как io.write, но, во-первых, позволяет задать вторым аргументом true, а тогда текст будет переноситься на новую строку, если он длиннее ширины окна; во-вторых, можно задать окно для рисования — и писать текст, например, на другом мониторе, имея в распоряжении при этом обработку \t, \n.
     
    А ещё есть term.scroll(n: number[, window: table]). Он копирует область внутри окна и вставляет её — ниже на n строк, если n > 0, или выше на -n строк, если n < 0. Остальное очищается.
     
    Можно очистить строку, на которой находится в данный момент курсор, с помощью term.clearLine([window: table]). К слову, в прошлой версии первым аргументом был номер строки, которую нужно очистить. Теперь этого нет.
     
    Как видно, во всех функциях аргумент window опционален. Если его не указывать, возьмётся стандартное окно, которое используется системой. Ничего особенного.
     
    Собственно, это всё по окнам. В функциях, которые я перечислю ниже, нет возможности, к сожалению, указать окно аргументом — будет использоваться стандартное. Вот эти функции:
    term.read([options: table]) — функция, с помощью которой можно получить значение от пользователя. Создаёт строку ввода, её обрабатывает и возвращает результат. Можно передать таблицу с опциями: dobreak — если равен false, то после нажатия Enter курсор не переместится на новую строку. hintHandler — функция (принимает текущее значение поля ввода и номер подсказки, переключаемый Tab/Shift-Tab, и возвращает строку с подсказкой) или таблица с подсказками, которые будут предлагаться юзеру по нажатию Tab (или Shift-Tab для возврата назад). pwchar ­— символ, который будет показываться вместо введённых пользователем. Этим можно воспользоваться, чтобы, например, писать пароль. filter — функция, которая принимает значение поля ввода и возвращает true при валидном вводе и false при невалидном, или строка с паттерном Lua, с помощью которых будет проверяться валидность введённых данных. Например, можно разрешить вводить только цифры. Если попытаться ввести невалидные данные, то комьютер радостно пропищит. nowrap — если не задан или равен false, то при достижении конца строки, последующие символы переходят на следующую строку. Иначе будет вести себя, как в версиях до 1.6 — скроллить горизонтально. И, наконец, под числовыми индексами ([1], [2], [3], ...) история ввода — строки, между которыми можно переключаться с помощью стрелочек вверх и вниз.
    [*]term.clear() — вообще 0 идей, с чего вдруг здесь нельзя задавать окно, но тем не менее. Очищает экран. [*]term.pull() — ожидает ивентов, рисуя мерцающий курсор. [*]term.write(value: string[, wrap: boolean]) — то же, что и io.write. [*]term.getCursor() — возвращает позицию курсора. [*]term.setCursor(x: number, y: number) — устанавливает позицию курсора. [*]term.setCursorBlink(enabled: boolean) — включает/выключает мерцание курсора. [*]term.getCursorBlink() — проверяет, включено ли мерцание курсора.

    И вот здесь я предлагаю закончить, наконец, этот туториал. Я описал все функции публичного API этой интересной либы, которая пополнилась очень забавными и прикольными фичами. Теперь думайте сами, что будете делать со всем этим добром :P
  25. Fingercomp

    Палитры OpenComputers

    Автор: Fingercomp,

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

    Первый уровень
    Палитра состоит из двух цветов: чёрного и заданного в конфиге (по умолчанию белого). Конвертация цвета в индекс палитры тривиальна:
    цвет нулевой — и индекс нулевой (чёрный цвет); цвет ненулевой — индекс единичный. Цвет в индекс (deflate) и обратно (inflate) превращать — одно удовольствие:
    local palette = { 0x000000, CONFIG.monochromeColor } local function t1deflate(index) if index == 0 then return 0 else return 1 end end local function t1inflate(index) return palette[index + 1] end Как и говорил.

    Второй уровень
    В палитре второго уровня имеется 16 закреплённых цветов:
    local palette = {0xFFFFFF, 0xFFCC33, 0xCC66CC, 0x6699FF, 0xFFFF33, 0x33CC33, 0xFF6699, 0x333333, 0xCCCCCC, 0x336699, 0x9933CC, 0x333399, 0x663300, 0x336600, 0xFF3333, 0x000000}
    При конвертации цвета в индекс палитры вернётся ближайший к данному цвет из палитры. Насколько цвета друг к другу близки, рассчитывается по специальной формуле, которая учитывает, что человеческий глаз лучше воспринимает зелёный, нежели красный и синий. В коде этим занимается функция delta. Вот как она выглядит (вместе с функций extract, выделяющей из числа вида 0xABCDEF числа 0xAB, 0xCD, 0xEF):
    local function extract(color) color = color % 0x1000000 local r = math.floor(color / 0x10000) local g = math.floor((color - r * 0x10000) / 0x100) local b = color - r * 0x10000 - g * 0x100 return r, g, b end local function delta(color1, color2) local r1, g1, b1 = extract(color1) local r2, g2, b2 = extract(color2) local dr = r1 - r2 local dg = g1 - g2 local db = b1 - b2 return (0.2126 * dr^2 + 0.7152 * dg^2 + 0.0722 * db^2) end   Теперь можно конвертировать цвет в индекс палитры. Суть такова: выбираем из двух цветов ближайший и возвращаем его.
    local function t2deflate(color) -- Сначала проверяем, совпадает ли данный цвет -- с каким-либо из палитры for idx, v in pairs(palette) do if v == color then return idx end end -- Составляем таблицу разниц между цветами local deltas = {} for idx, v in pairs(palette) do table.append(deltas, {idx, delta(v, color)}) end -- Сортируем по увеличению разницы table.sort(deltas, function(a, b) return a[2] < b[2] end) -- Первый элемент будет с наименьшей разницей, -- то есть искомый. Возвращаем индекс. return deltas[1][1] - 1 end  
    Обратная же процедура — превращение индекса палитры в цвет — неизменна.
    local t2inflate = t1inflate
    Третий уровень
    Палитра третьего уровня содержит уже 256 цветов: первые 16 цветов изменяются, а остальные соответствуют цветам палитры RGB-6-8-5. Это означает, что можно смешивать 6 оттенков красного, 8 оттенков зелёного и 5 оттенков синего. В общем-то, довольно очевидна причина такого выбора: человеческий глаз лучше всего различает оттенки зелёного и хуже всего — оттенки синего.

    В любом случае, здесь алгоритмец будет посложнее. Сначала нужно сгенерировать палитру.
    Начнём с первых 16 цветов. Они не включаются в палитру RGB-6-8-5, поэтому их заполнять нужно отдельно. В OpenComputers по умолчанию они содержат оттенки серого. Так как чёрный и белый уже включены в основную, зафиксированную палитру, то заново их дублировать смысла нет.
    local palette = {} -- grayscale for i = 1, 16, 1 do palette[i] = 0xFF * i / (16 + 1) * 0x10101 end
    Таким образом в таблице получаются следующие оттенки серого:
    0x0F, 0x1E, 0x2D, 0x3C, 0x4B, 0x5A, 0x69, 0x78, 0x87, 0x96, 0xA5, 0xB4, 0xC3, 0xD2, 0xE1, 0xF0 Эти цвета мы записываем в индексы от 0 до 15. Теперь нужно сгенерировать остальные цвета — они не изменяются. Здесь будет посложнее.
    Посмотрим на картинку с палитрой:

    В OpenComputers левая верхняя ячейка палитры (0x000000) имеет индекс 16, а правая нижняя (0xFFFFFF) имеет индекс 255. Индексы распределяются слева направо, сверху вниз. То есть правая верхняя ячейка (0x00FFFF) имеет индекс 55, а вторая сверху и левая (0x330000) — это номер 56. Отсюда вытекает следующий алгоритм нахождения цвета: сначала найти индексы отдельно по R, G, B, затем для каждого из этих трёх индексов найти соответствующий ему оттенок цвета, а затем всё сложить.
    for idx = 16, 255, 1 do local i = idx - 16 local iB = i % 5 local iG = (i / 5) % 8 local iR = (i / 5 / 8) % 6 local r = math.floor(iR * 0xFF / (6 - 1) + 0.5) local g = math.floor(iG * 0xFF / (8 - 1) + 0.5) local b = math.floor(iB * 0xFF / (5 - 1) + 0.5) palette[idx + 1] = r * 0x10000 + g * 0x100 + b end Идея следующая. Каждый из трёх каналов принимает значение от 0 до 255 (0xFF). Разбиваем их на определённое число ступеней (по-умному — квантуем): 6 для красного, 8 для зелёного и 5 для синего. Например, синий канал мы разобьём так:
    0/4 · 255 = 0 1/4 · 255 = 63.75 2/4 · 255 = 127.5 3/4 · 255 = 191.25 4/4 · 255 = 255 В знаменателе тут 4, а не 5, потому что считаем с нуля. Затем округляем до ближайшего целого конструкцией math.floor(x + 0.5). Перебрав все комбинации, мы получим все 6 × 5 × 8 = 240 цветов неизменяемой части палитры.
     
    Всё. Палитра есть, теперь можно, наконец-то, конвертировать индексы между цветами.
    Из индексов получить цвет довольно просто. Достаточно использовать ту же функцию, что и для предыдущих уровней:
    t3inflate = t2inflate
    С обратной же конвертацией всё несколько сложнее. Функция, используемая в OC, подбирает ближайший цвет хитрым алгоритмом, который я привожу ниже.
    local function t3deflate(color) local paletteIndex = t2deflate(color) -- Если цвет из палитры, то используем значение выше for k, v in pairs(palette) do if v == color then return paletteIndex end end -- Иначе используем хитромудрый код local r, g, b = extract(color) local idxR = math.floor(r * (6 - 1) / 0xFF + 0.5) local idxG = math.floor(g * (8 - 1) / 0xFF + 0.5) local idxB = math.floor(b * (5 - 1) / 0xFF + 0.5) local deflated = 16 + idxR * 8 * 5 + idxG * 5 + idxB if (delta(t3inflate(deflated % 0x100), color) < delta(t3inflate(paletteIndex & 0x100), color)) then return deflated else return paletteIndex end end Хитромудрость здесь не сильно сложная, на самом деле. Мы сначала находим индекс самого близкого цвета из изменяемой части палитры (paletteIndex). Дальше высчитываем индекс цвета из неизменяемой части (deflated), для чего в каждом канале отдельно ищем номер ближайшей ступени, на которые ранее квантовали. Последний if сравнивает 2 варианта и возвращает самый похожий (с точки зрения человека) на исходный.   В общем-то, это всё. Показал портированный со Scala на Lua код, который используется в OpenComputers. С помощью этого можно оптимизировать операции с экраном, выбирая поддерживаемые монитором цвета. И заодно избавиться от таблиц цветов, которые некоторые буквально берут и копипастят в файл, даже не задумываясь об изменяемых цветах палитры.
    Особенно это важно, когда берётся значение цвета через gpu.get, потому что следующий код всегда вернёт false:
    local gpu = require("component").gpu gpu.setForeground(0x20AFFF) gpu.setBackground(0x20AFFF) gpu.set(1, 1, "HI") return select(2, gpu.get(1, 1)) == 0x20AFFF И всё потому, что gpu.get возвращает уже приведённый к индексу из палитры цвет. А 0x20AFFF в палитре, если не менять первые 16 цветов, не имеется.

    Enjoy :P
×
×
  • Создать...