Лидеры

Проверяй наличие файлов и корректность вводимых путей. Интереса ради загрузил майн, проверил - всё сработало, как и задумано: Управляющий скрипт /home/send.lua: Микропрограмма-ресивер для робота /home/eeprom.lua: Исполняемый код, отсылаемый роботам по сети /home/robot.lua: Команда для отсылки: send robot.lua Результат: Движение робота реализуется самим роботом, а не OpenOS. Как правило, любая ОС в OpenComputers - это софтверная оболочка, функционирующая поверх аппаратной части, и предоставляющая набор библиотек, упрощающих разработку софта. Например, в случае с роботами OpenOS оборачивает компонент robot в библиотеку robot, предоставляющую набор шорткатов. То же самое и с глобальной функцией require - её попросту нет в "голых" роботах, управляемых из-под EEPROM Использовать ОС крайне удобно, когда речь идет об одном роботе, хранящем пользовательские скрипты и управляемом напрямую через экран/клавиатуру. Однако в случае с роем такое решение контр-продуктивно, т. к. любая ОС потребляет ресурсы и требует крафта более дорогостоящих компонентов - в частности, планок памяти и жёстких дисков. Это всё равно что ставить Debian на сеть устройств для капельного полива домашних растений - ну то есть да, это возможно, а зачем? Разумнее прибегнуть к концепции микропрограмм на EEPROM, которые относительно дёшевы в плане крафта, а профит в виде освободившихся слотов под компоненты существенный. Заодно можно получить интересный опыт по "низкоуровневой" разработке под опенкомпы: -- Робот с OpenOS local robot = require("robot") robot.moveUp() robot.turnRight() robot.swing() -- Робот с EEPROM local robot = component.proxy(component.list("robot")()) robot.move(1) robot.turn(true) robot.swing(3) Таблицы component/computer/robot/unicode/bit32 являются суперглобальными и доступны сразу при запуске микропрограммы EEPROM, однако во время инициализации OpenOS они маскируются из соображений консистентности кода. Поэтому при работе из-под EEPROM вызов require не требуется, а из-под OpenOS уже требуется Верстаки, контроллеры инвентаря и ёмкости - это аппаратные компоненты, функционирующие самостоятельно и не требующие OpenOS. Любая ОС - это просто средство доступа к компонентам, причём одно из многих: -- Робот с OpenOS local component = require("component") local sides = require("sides") local crafting = component.crafting local inventoryController = component.inventory_controller local tankController = component.tank_controller crafting.craft(10) inventoryController.dropIntoSlot(sides.front, 10) tankController.drain() -- Робот с EEPROM local crafting = component.proxy(component.list("crafting")()) local inventoryController = component.proxy(component.list("inventory_controller")()) local tankController = component.proxy(component.list("tank_controller")()) crafting.craft(10) inventoryController.dropIntoSlot(3, 10) tankController.drain() Как видно, разница в коде несущественна, отличие лишь в способе получения доступа к ним и в наличии упрощающих библиотек типа sides Чтобы прояснить ситуацию: никто не призывает тебя использовать голый EEPROM вместо классического подхода с HDD/OpenOS. Разрабатывай так, как считаешь комфортным и оптимальным для себя - я лишь указал один из способов решения поставленной задачи, который использовал при выживании, и который сам считаю оптимальным Если тебе требуется весь богатый функционал, поставляемый OpenOS для роботов, ничто не мешает модифицировать скрипт-ресивер таким образом, чтобы он работал из-под OpenOS:

cloudflared tunnel (нужен домен, 6-символьный домен из цифр вроде 000001 на TLD .XYZ стоит копейки), tailscale funnel из бесплатных решений. cloudflared в принципе пробивает любой CGNAT. Если говорить про хостинг TCP/UDP приложений — из бесплатных решений особо ничего нет, но можно попробовать использовать ipv6 брокера — tunnelbroker.net. Дают бесплатный ипв6 который, вроде как, должен пробивать CGNAT в том числе. Так же существует клиент https://playit.gg/, опенсорсный клиент, позволяет пробрасывать tcp/udp порты (4 штуки). дают и домен, и айпишник (не меняется). Бесплатно. Из платных решений можно взять впн и пробросить через него порт firstbyte.ru (не реклама) предлагает хостинг за 70 рублей.

Решил значит я сделать мод для OpenOS, да не обычный, а такой что бы пользователь мог его сам собрать. Что то вроде Arch Linux: можешь поставить только базу командой pacstrap -K /mnt base linux linux-firmware А можешь сразу и DE накатить да и пару приколов заодно: pacstrap -K /mnt base linux linux-firmware neofetch nano gcc make xfce4 ... Итак, к чему я. Какие пункты OpenOS вы бы хотели модифицировать? И каким образом? Текущий список идей: Замена цветовой темы (openos-mod colorscheme [FG] [BG]) [ГОТОВО] Свой менеджер пакетов поддерживающий oppm и hpm (pacman) Замена загрузчика /init.lua (Полный вывод действий, вывод только стадий, анимация загрузки, ... - openos-mod bootloader [путь/к/пакету/загрузчика.bld]) Ссылка на репозиторий: https://github.com/Def-Try/OpenArch/tree/main Буду очень рад вашему вкладу в проект

Библиотека filesystem абстрагируется от действий текущего юзера и рабочей директории, предоставляя более "сырой" доступ к файловой системе без высокоуровневых проверок. Для поддержки поиска по раб. директории следует обратиться к методу shell.resolve(path), который используется большинством штатных скриптов в /bin/. Посмотри на отправляющий код с пред. сообщения - там я как раз добавил эту фичу для удобства Всё верно. В десктопном Lua ты получил бы что-то наподобие: А в OpenComputers уже нет, т.к. глобальной переменной arg вовсе не существует: Все входные аргументы мы получаем вручную через args = {...}, создавая при этом самую обычную переменную. Она не какая-то магическая, не системная. Её и назвать можно как угодно, хоть someWeirdDots = {...}, тут уж воля фантазии Согласен, хотя это скорее дело привычки. Всегда можно скопировать таблицу направлений из исходников Sides API, и воспользоваться ей для движения робота в нужную сторону, если вводить непонятные цифры а-ля robot.move(1/2/3/4) дискомфортно Как раз по этой ссылке и перечислены все остальные "низкоуровневые" команды, других попросту не существует в компоненте robot. Пикча для наглядности: Например, back/up/down реализуются софтверно средствами OpenOS. При этом robot.back() из OpenOS эквивалентен компонентному вызову robot.move(2). Вообще крайне рекомендую чекнуть исходники по пред. ссылке - там много всего интересного, и на деле окажется, что работа с "чистым" роботом ничуть не сложнее, чем с библиотекой из OpenOS. Непривычно и неочевидно - да, есть такое

А Stem не подойдёт? Если планируется связываться только из OC.

@WheatComp Если по-читерски, то можно сдюпнуть жёсткий диск одного робота, вставить его в остальные и работать в одной общей папке Если по-честному, то имеет смысл дать возможность каждому роботу выполнять произвольный код, присылаемый компьютером-хостом по беспроводной сети. Это позволит избавиться от OpenOS, жёсткого диска и упростить сборку робота за счёт более дешёвых компонентов: 1) Крафтим 20 чистых EEPROM и беспроводных модемов 2) Прошиваем их скриптом-ресивером: 3) Вставляем прошитые EEPROM с модемами в роботов 4) Пишем управляющий скрипт для компьютера-хоста. Предполагаю, что на нём будет использоваться OpenOS: 5) Запускаем всех роботов и отсылаешь им любой файл с жёсткого диска на исполнение командой send robots/example.lua Единственный нюанс - работоспособность кода выше чекнуть не могу, т.к. майна под рукой нет, но общий концепт, думаю, понятен

Это не возымеет эффекта, т.к. библиотека package реализована средствами OpenOS, а не мода. То есть ей доступны те же данные, что и игровому жёсткому диску. А ему в свою очередь доступны только данные в рамках директории игрового сейва - это захардкожено из соображений серверной безопасности, и обойти не получится Вероятно, package задумывалась как полный аналог одноименной библиотеки в "реальной" версии Lua - отсюда и путаница

пст лжт н свлк

првт вс фнт мда дл openOS кк в знт мд дл openOS бльш не подержвтся... н я зню чт в ждт, и пэтм вктва втрую! улчшеню врcю мд дл openOS!!! утнвк на првтр на рбт не упрт