Лидеры

"сomponent" - библиотека, существующая вне OpenOS (как и "computer"). Насколько я помню - оська только расширяет функционал. Но базовые функции "зашиты" в компьютер и вполне спокойно дергаются при выполнении кода в голой системе. Вот например данная демка при запуске из EEPROM спокойно выплевывает на экран (в сыром виде) собственное содержимое и зависает в цикле (дабы пк не отключался сразу после вывода). local eeprom = component.proxy(component.list("eeprom")()) local gpu = component.proxy(component.list("gpu")()) local firm = eeprom.get() gpu.set(1, 1, firm) while true do computer.pullSignal() end

Утилита сбора урожая Назначением предлагаемой утилиты является сбор урожая с ic2 жёрдочек, либо любого аналогично собираемого урожая. Разработано для автоматизации в условиях отключеного Crop Harvester. Так же может собирать урожай ванильных и прочих культур при наличии мода автопосадки культур после их сбора, в частности Harvestcraft. Рекомендуемая комплектация робота: Улучшение инвентарь (один или несколько) Улучшение контроллер инвентаря Жёсткий диск (если используется версия не для eeprom) Монитор, клавиатура, видеокарта/процессор с гпу для запуска программы.(если используется версия не для eeprom) Начало работы: Стартовая позиция робота располагается на 1 ниже левого нижнего угла поля, стартовое направление движения вперёд по z, условные координаты старта z=-1,x=0. Сундук для сдачи собранного урожая расположить сзади робота. Размер поля и пауза между сборами указаны в цикле в последних строках. Для eeprom-версии возможность задать паузу извне не используется, так же не используются проверки размера поля. Сам размер поля для eeprom-версии может быть задан в цикле внизу тела утилиты. Содержащиеся в утилите функции: doit(s,t) - принимает размер поля и время ожидания после сбора, если они переданы. Выполняет основную работу обхода поля принятых размеров. Для вызова из вне следует закомментировать вечный цикл в конце утилиты. drop - выгружает инвентарь. forward (fw для eeprom варианта) - осуществляет движение вперёд с проверкой успеха. Адрес в интернете: https://pastebin.com/dq5NNtEb Загрузка в робота/компьютер: pastebin get dq5NNtEb harvest.lua (имя файла можно выбрать на своё усмотрение) Запуск без установки: patebin run dq5NNtEb Версия для eeprom: https://pastebin.com/duXuFb9n Установка в eeprom: pastebin get duXuFb9n biosH flash -q biosH biosH Перекрафтить в верстаке робота и eeprom. 2022.01.25. Версия для Биос обновлена. Теперь занимает 777 символов: Убраны комментарии, изменено обращение к component.robot при присвоении ссылки на него локальной переменной. Исправлено определение размера инвентаря, используемое вместо паузы - были забыты () при обращении к функции. Изменено название внутренней функции forward на fw для уменьшения тела утилиты. Добавлена маленькая пауза после встречи с препятствием перед повторной попыткой движения, так же через обращение к внутреннему инвентарю.

loadfile и dofile отличаются тем, что первая загружает код из указанного файла и (с помощью вшитой в Lua-машину функции load) возвращает его в виде функции, которую мы можем выполнить, когда захотим. А вторая через loadfile загружает файл и сразу же его выполняет, возвращая пользователю результат функции. Обе функции реализованы программно https://github.com/MightyPirates/OpenComputers/blob/master-MC1.7.10/src/main/resources/assets/opencomputers/loot/openos/boot/00_base.lua#L1-L30 Про require уже было сказано тут. Она ищет библиотеку либо в своей кеш-таблице (если ее уже загружали), либо ищет по стандартным путям и если находит, через loadfile загружает ее, сохраняет в кеш-таблицу и отдает пользователю.

Вот, именно про это расширение я и говорил. Поскольку это уже программная фича, реализованная на уровне OpenOS. require? Она хоть с виду и является самостоятельной функцией, но на самом деле входит в вышеупомянутую либу package: https://github.com/MightyPirates/OpenComputers/blob/master-MC1.7.10/src/main/resources/assets/opencomputers/loot/openos/lib/package.lua#L45-L70 Я не в курсе почему ее вынесли отдельно, но значит так надо.

В дополнение к инфе от @Bs0Dd поясню, что если ты кодишь под биос, то работаешь на самом низком уровне, доступном в моде. Следовательно, фича component.имяКомпонента.метод(...) из OpenOS доступна не будет, т.к. она добавляется на более позднем этапе во время инициализации самой ОС: https://github.com/MightyPirates/OpenComputers/blob/af2db43c53b9690fceabfb813987572bf2258db5/src/main/resources/assets/opencomputers/loot/openos/boot/04_component.lua#L10-L32 Поэтому для обращения к компоненту из-под биоса есть 2 варианта: -- Чтобы обратиться к компоненту, нам нужно знать его уникальный адрес -- Список адресов всех доступных компонентов с указанным типом можно получить через метод component.list("имя") -- В одном компьтере может быть установлено несколько компонентов одного типа, поэтому метод list -- возвращает функцию-итератор, при каждом вызове которой возвращается адрес следующего компонента local gpuIterator = component.list("gpu") local gpu1Address = gpuIterator() local gpu2Address = gpuIterator() -- Конструкцию выше можно скомпоновать в цикл for address in component.list("gpu") do -- Делаем что угодно с каждой имеющейся GPU end -- В случае EEPROM все несколько проще. Поскольку в 1-ом компьютере может быть только 1 EEPROM, то нам -- следует вызвать функцию-итератор хотя бы 1 раз, чтобы получить адрес 1-го (и единственного) EEPROM local eepromAddress = component.list("eeprom")() -- Раз адрес компонента EEPROM нам известен, теперь мы можем обратиться к нему и вызвать -- какой-нибудь метод. Сделать это можно двумя путями. Первый более линейный, его следует -- использовать для каких-то разовых операций "в лоб": local data = component.invoke(eepromAddress, "getData") component.invoke(eepromAddress, "setData", "sample text") -- Второй более универсальный, и позволяет создать так называемый прокси компонента, то есть -- таблицу в памяти, содержащую все доступные методы компонента. Разумеется, он расходует больше ОЗУ, -- однако работать с ним в разы удобнее: local eepromProxy = component.proxy(eepromAddress) local data = eepromProxy.getData() eepromProxy.setData("sample text") Кроме того, "чистые" компьютеры без ОС имеют глобальные переменные component, computer и unicode, которые всегда доступны в биосе, и в случае OpenOS "вырезаются", становясь частью глобальной библиотеки package: https://github.com/MightyPirates/OpenComputers/blob/af2db43c53b9690fceabfb813987572bf2258db5/src/main/resources/assets/opencomputers/loot/openos/lib/core/boot.lua#L94-L112 По этой причине в биосе ты должен обращаться к глобальной библиотеке component, а в OpenOS для этого уже требуется конструкция require("component"). Почему авторы так поступили? Да хрен знает, их ОС - их правила. Но путаницу это вносит знатную

@ItsMakar Думаю, использованы беспроводные платы, и сигнал доходит два раза: по воздуху и через кабель. Сравни два дублирующихся события. Чем они отличаются друг от друга? Расстоянием?

В своём магазе я сделал всё на голых вызовах и обращениях к gpu. На прямую.