Почему package.lua не видит модуль?

[WheatComp 3]

Всем привет! Пытаюсь сделать так, чтобы программа использовала функции в модуле из папки вне корневой папки Майнкрафт-а, а из папки, допустим, D:/23 Вот код основной, вызывающей модуль программы:

local printermodule = require("printermodule")
printermodule.pr()

Вот модуль:

printermodule = {}

function printermodule.pr()
  print("hello")
end
return printermodule

В package.lua, что в папке lib папки жесткого диска робота, добавил конце строку "/D:/23/?.lua". Пытался и без слеша "D:/23/?.lua", но в этом случае ищет в "home/D:/23/?.lua":

package.path = "/lib/?.lua;/usr/lib/?.lua;/home/lib/?.lua;./?.lua;/lib/?/init.lua;/usr/lib/?/init.lua;/home/lib/?/init.lua;./?/init.lua;/D:/23/?.lua"

Скрин ошибки прикрепил.

[ECS 1 903]

1 час назад, WheatComp сказал:

В package.lua, что в папке lib папки жесткого диска робота, добавил конце строку "/D:/23/?.lua"

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

Вероятно, package задумывалась как полный аналог одноименной библиотеки в "реальной" версии Lua - отсюда и путаница

[eu_tomat 2 154]

1 час назад, WheatComp сказал:

Пытаюсь сделать так, чтобы программа использовала функции в модуле из папки вне корневой папки Майнкрафт-а, а из папки

А какова цель этого трюка? Как выше уже ответил @ECS , получить доступ к файлу за пределами каталога сохранения с помощью package  невозможно. Но можно сделать что-то похожее на это.

[WheatComp Автор вопроса 3]

@eu_tomat Подскажите, пожалуйста, что можно сделать. Цель моя простая - сделать так, чтобы 20 роботов обращались к одной функции, допустим, SeedWeat, расположенной в одном месте, хоть в пределах каталога OpenComputers, хоть вне пределов. Главное, чтобы в одной папке, в одном файле, чтобы можно было в любой момент редактировать эту функцию по неоходимости. А не вносить изменение (или изменения) во все 20 файлов в отдельных папках жестких дисков роботов. Честно сказать, утомился это делать.

[ECS 1 903]

@WheatComp Если по-читерски, то можно сдюпнуть жёсткий диск одного робота, вставить его в остальные и работать в одной общей папке

 

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

 

1) Крафтим 20 чистых EEPROM и беспроводных модемов

2) Прошиваем их скриптом-ресивером:

 

Скрытый текст

-- Получаем компонент модема, вставленный в робота, и
-- открываем любой порт по вкусу
local modem = component.proxy(component.list("modem")())
local port = 123
modem.open(port)

-- Задаём адрес модема, вставленного в компьютер-хост
-- Вообще это опциональная штука, необходимая для защиты от
-- атак на роботов на публичных серверах. В локальной игре
-- это не имеет особого смысла
local serverModemAddress = "eafaff-fae-faefaefa-fafe"

-- Анализируем сигналы в бесконечном цикле
while true do
  local data = {computer.pullSignal()}

  -- Если пришло сообщение по модему, и адрес модема отправителя 
  -- совпадает с адресом хоста, т.е. если мы можем доверять
  -- содержимому сообщения
  if data[1] == "modem_message" and data[3] == serverModemAddress then
    
    -- Анализируем содержимое сообщения. В этом примере мы
    -- будем выполнять код, присланный хостом, и отсылать ему
    -- обратно информацию в случае неудачи
    if data[6] == "execute" and data[7] then

      -- Пытаемся загрузить присланную строку в виде Lua-кода
      local result, reason = load(data[7])

      -- Если код загружен - выполняем его
      if result then
        result, reason = xpcall(result, debug.traceback)
      end

      -- Если загрузка/выполнение не удались - отсылаем
      -- причину хосту. В принципе это тоже необязательный
      -- шаг, но при контроле большого кол-ва дронов/роботов
      -- будет разумно визуализировать все проблемы на хосте
      if not result and reason then
        modem.send(serverModemAddress, port, "executeFailed", tostring(reason))
      end
    end
  end
end

 

 

3) Вставляем прошитые EEPROM с модемами в роботов

4) Пишем управляющий скрипт для компьютера-хоста. Предполагаю, что на нём будет использоваться OpenOS:

 

Скрытый текст

-- Подключаем библиотеки
local component = require("component")
local filesystem = require("filesystem")
local shell = require("shell")
local io = require("io")
local event = require("event")

-- Получаем и анализируем входные аргументы
local args = {...}

if #args < 1 then
  print("Usage: send <filename>")
  return
end

local path = shell.resolve(args[1])

-- Проверяем, существует ли файл, содержимое которого
-- мы будем отсылать по сети
if not filesystem.exists(path) then
  print("Specified file doesn't exist")
  return

-- Проверяем, не директория ли это
elseif filesystem.isDirectory(path) then
  print("It's a directory, not file")
  return
end

-- Читаем содержимое файла
local file = assert(io.open(args[1], "rb"))
local data = file:read("*a")
file:close()

-- Получаем компонент модема, вставленный в хост, и
-- открываем любой порт. Он обязан быть таким же, что и у
-- всех подконтрольных роботов
local modem = component.modem
local port = 123
modem.open(port)

-- Отсылаем прочтённое содержимое всем роботам на выполнение
-- Если файл будет слишком большим, чтобы уместиться
-- в пакет модема - нужно будет писать отдельную
-- систему для разбивки на пакеты. Но это уже выходит за
-- рамки текущего примера
modem.broadcast(port, "execute", data)

-- Далее можно реализовать приёмку сообщений об ошибках,
-- визуализировать их, логировать и т.п.

 

 

5) Запускаем всех роботов и отсылаешь им любой файл с жёсткого диска на исполнение командой send robots/example.lua

 

Единственный нюанс - работоспособность кода выше чекнуть не могу, т.к. майна под рукой нет, но общий концепт, думаю, понятен

[Anon 25]

Цитата

-- Получаем компонент модема, вставленный в робота
local modem = component.proxy(component.list("modem")())

Цитата

-- Получаем компонент модема, вставленный в робота, и
-- открываем любой порт по вкусу
local modem = component.modem

@ECS, не опечатка ли это? В предложенном тобою коде дважды получается инстанс модема, причём, в первом случае это работать будет, а во втором, поскольку голый апи компонента не умеет возвращать прокси через точку, нет. Скорее всего, в modem запишется nil

Изменено 17 мая, 2023 пользователем Anon

[ECS 1 903]

2 минуты назад, Anon сказал:

не опечатка ли это

Ага, опечатка, поправил, спсибо

[WheatComp Автор вопроса 3]

8 часов назад, ECS сказал:

5) Запускаем всех роботов и отсылаешь им любой файл с жёсткого диска на исполнение командой send robots/example.lua

@ECS Спасибо! Попытался запустить и так и сяк, не получилось (прикрепил фото). Хостовый файл назвал master.lua, тестовый ресивер - delete.lua Из интерпретатора еще хуже - ругается на send. Пытался послать тестовую программку на поднятие робота:

local ro = require("robot")

robot.up()

Кстати про require("robot"). Без него же робот не поднимется, т.к. у него нет OpenOS? С eeprom-ом он как бы микроконтроллер становится? А мне нужно бы, чтобы робот летал и другие функции выполнял. И еще в скрипте-ресивере, заметил, есть компонент "computer":

while true do
  local data = {computer.pullSignal()}

  

а в начале файла-ресивера нет запроса библиотеки "computer". Сработает ли скрипт? Если делать как в микроконтроллерах через proxy, то это возможно ли? Я, помнится, безуспешно пытался через прокси запросить "computer" в микроконтроллер.

В целом, если все это заработает, будет отлично для робот-крестьян. Но у меня еще есть 9 роботов на сборке компьютерных компонентов и еще планируются для обработки руды. Вот для них прямо необходима общая папка, поскольку внутри них будут всякие улучшения (верстаки, контроллеры инвентаря и емкости, а они же требуют OpenOS). И для всех них, включая крестьян, было бы очень удобно написать функции, общие для всех. Например, для слежения за уровнем зарядки.

[eu_tomat 2 154]

@WheatComp Ты говоришь о выживании в игре или о тестовой среде?

[WheatComp Автор вопроса 3]

@eu_tomat Выживании.

[WheatComp Автор вопроса 3]

@ECS В дополнение. По-моему, пропущены end-ы после return в скрипте для хоста?:

-- Проверяем, есть ли вообще входные аргумнты
if not args[1] then
  print("Usage: send <path_to_script>")
  return

-- Проверяем, существует ли файл, содержимое которого
-- мы будем отсылать по сети
elseif not filesystem.exists(args[1]) then
  print("Specified file doesn't exist")
  return

 

[ECS 1 903]

11 час назад, WheatComp сказал:

Попытался запустить и так и сяк, не получилось (прикрепил фото)

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

 

Управляющий скрипт /home/send.lua:

Скрытый текст

-- Подключаем библиотеки
local component = require("component")
local filesystem = require("filesystem")
local shell = require("shell")
local io = require("io")
local event = require("event")

-- Получаем и анализируем входные аргументы
local args = {...}

if #args < 1 then
  print("Usage: send <filename>")
  return
end

local path = shell.resolve(args[1])

-- Проверяем, существует ли файл, содержимое которого
-- мы будем отсылать по сети
if not filesystem.exists(path) then
  print("Specified file doesn't exist")
  return

-- Проверяем, не директория ли это
elseif filesystem.isDirectory(path) then
  print("It's a directory, not file")
  return
end

-- Читаем содержимое файла
local file = assert(io.open(args[1], "rb"))
local data = file:read("*a")
file:close()

-- Получаем компонент модема, вставленный в хост, и
-- открываем любой порт. Он обязан быть таким же, что и у
-- всех подконтрольных роботов
local modem = component.modem
local port = 123
modem.open(port)

-- Отсылаем прочтённое содержимое всем роботам на выполнение
-- Если файл будет слишком большим, чтобы уместиться
-- в пакет модема - нужно будет писать отдельную
-- систему для разбивки на пакеты. Но это уже выходит за
-- рамки текущего примера
modem.broadcast(port, "execute", data)

-- Далее можно реализовать приёмку сообщений об ошибках,
-- визуализировать их, логировать и т.п.

 

 

Микропрограмма-ресивер для робота /home/eeprom.lua:

Скрытый текст

-- Получаем компонент модема, вставленный в робота, и
-- открываем любой порт по вкусу
local modem = component.proxy(component.list("modem")())
local port = 123
modem.open(port)


-- Анализируем сигналы в бесконечном цикле
while true do
  local data = {computer.pullSignal()}

  -- Если пришло сообщение по модему, и адрес модема отправителя 
  -- совпадает с адресом хоста, т.е. если мы можем доверять
  -- содержимому сообщения
  if data[1] == "modem_message" then
    
    -- Анализируем содержимое сообщения. В этом примере мы
    -- будем выполнять код, присланный хостом, и отсылать ему
    -- обратно информацию в случае неудачи
    if data[6] == "execute" and data[7] then

      -- Пытаемся загрузить присланную строку в виде Lua-кода
      local result, reason = load(data[7])

      -- Если код загружен - выполняем его
      if result then
        result, reason = xpcall(result, debug.traceback)
      end

      -- Если загрузка/выполнение не удались - отсылаем
      -- причину хосту. В принципе это тоже необязательный
      -- шаг, но при контроле большого кол-ва дронов/роботов
      -- будет разумно визуализировать все проблемы на хосте
      if not result and reason then
        modem.send(serverModemAddress, port, "executeFailed", tostring(reason))
      end
    end
  end
end

 

 

Исполняемый код, отсылаемый роботам по сети /home/robot.lua:

Скрытый текст

local robot = component.proxy(component.list("robot")())

for i = 1, 4 do
  robot.turn(true)
end

 

 

Команда для отсылки:

send robot.lua

Результат:

 

 

11 час назад, WheatComp сказал:

Кстати про require("robot"). Без него же робот не поднимется, т.к. у него нет OpenOS

Движение робота реализуется самим роботом, а не 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)

 

11 час назад, WheatComp сказал:

а в начале файла-ресивера нет запроса библиотеки "computer". Сработает ли скрипт

Таблицы component/computer/robot/unicode/bit32 являются суперглобальными и доступны сразу при запуске микропрограммы EEPROM, однако во время инициализации OpenOS они маскируются из соображений консистентности кода. Поэтому при работе из-под EEPROM вызов require не требуется, а из-под OpenOS уже требуется

 

11 час назад, WheatComp сказал:

Вот для них прямо необходима общая папка, поскольку внутри них будут всякие улучшения (верстаки, контроллеры инвентаря и емкости, а они же требуют 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

 

10 часов назад, WheatComp сказал:

В дополнение. По-моему, пропущены end-ы после return в скрипте для хоста?:

 

 

Чтобы прояснить ситуацию: никто не призывает тебя использовать голый EEPROM вместо классического подхода с HDD/OpenOS. Разрабатывай так, как считаешь комфортным и оптимальным для себя - я лишь указал один из способов решения поставленной задачи, который использовал при выживании, и который сам считаю оптимальным

 

Если тебе требуется весь богатый функционал, поставляемый OpenOS для роботов, ничто не мешает модифицировать скрипт-ресивер таким образом, чтобы он работал из-под OpenOS:

 

Скрытый текст

-- Подключаем библиотеки
local component = require("component")
local event = require("event")

-- Получаем компонент модема, вставленный в робота, и
-- открываем любой порт по вкусу
local modem = component.modem
local port = 123
modem.open(port)

-- Задаём адрес модема, вставленного в компьютер-хост
-- Вообще это опциональная штука, необходимая для защиты от
-- атак на роботов на публичных серверах. В локальной игре
-- это не имеет особого смысла
local serverModemAddress = "eafaff-fae-faefaefa-fafe"

-- Ждем сообщений по модему в бесконечном цикле
while true do
  local data = {event.pull("modem_message")}

  -- Если адрес модема отправителя совпадает с адресом хоста,
  -- т.е. если мы можем доверять содержимому сообщения
  if data[3] == serverModemAddress then
    
    -- Анализируем содержимое сообщения. В этом примере мы
    -- будем выполнять код, присланный хостом, и отсылать ему
    -- обратно информацию в случае неудачи
    if data[6] == "execute" and data[7] then

      -- Пытаемся загрузить присланную строку в виде Lua-кода
      local result, reason = load(data[7])

      -- Если код загружен - выполняем его
      if result then
        result, reason = xpcall(result, debug.traceback)
      end

      -- Если загрузка/выполнение не удались - отсылаем
      -- причину хосту. В принципе это тоже необязательный
      -- шаг, но при контроле большого кол-ва дронов/роботов
      -- будет разумно визуализировать все проблемы на хосте
      if not result and reason then
        modem.send(serverModemAddress, port, "executeFailed", tostring(reason))
      end
    end
  end
end

 

 

[WheatComp Автор вопроса 3]

@ECS Почитал про апи filesystem на сайте мода. Оказалось, filesystem.exists() смотрит в /, а не в директории, откуда запущена программа. Добавил в агрумент название папки - заработало. Но пришлось закомментить проверку на директорию, иначе выводит сообщение, что это папка. Это  странно, почему filesystem.exists() смотрит в /, а не в /home, где обычно стартует терминал при включении игрового компа. Некий диссонанс.

 

Почему-то arg[1] выводит send. Вчера, когда пытался разобраться с аргументами, читал, что в Lua-интерпретаторах обычно args[0] выводит имя файла. Попытался в игре - выводит nil. Видимо, интерпретатор OC отличается от других. Изменил на [2], стал правильно печатать аргумент, содержащий название файла:

elseif not filesystem.exists(args[2]) then
  print(args[2])
  print("Specified file doesn't exist")
  return

Робота удалось заставить шевелиться, но возникает некоторая путаница с командами. В ОpenOS же вперед - это forward(), а тут move(side). Придется изменить много кода и ошибки, чувствую, неизбежны. К тому же на сайте игры не написано, каковы же остальные "низкоуровневые" команды. Описаны move, turn, swing, а back, up, down не описаны. Я пытался "методом тыка" послать эти неописанные команды роботу, но он выключается. Где можно получить их список? А может, "низкоуровневые" команды для улучшений-компонентов для роботов также отличаются?

 

5 часов назад, ECS сказал:

Однако в случае с роем такое решение контр-продуктивно, т. к. любая ОС потребляет ресурсы и требует крафта более дорогостоящих компонентов - в частности, планок памяти и жёстких дисков.

Согласен. Придется переучиваться на новый способ управления роем. Это, конечно, непривычно, да и роботы придется разбирать-собирать, ну да ладно. Я почему так хотел, да и сейчас был бы непротив общей папки/функции. Раньше изучал основы Java, и там можно было импортировать функцию из файла. А когда разработчики ОС лишают такой возможности, испытываешь нечто вроде фантомной боли.

Командой elseif не пользовался, показалось, главное слово тут - if, а оказалось - else. Понятно.

Изменено 18 мая, 2023 пользователем WheatComp

[ECS 1 903]

2 часа назад, WheatComp сказал:

Это  странно, почему filesystem.exists() смотрит в /, а не в /home, где обычно стартует терминал при включении игрового компа

Библиотека filesystem абстрагируется от действий текущего юзера и рабочей директории, предоставляя более "сырой" доступ к файловой системе без высокоуровневых проверок. Для поддержки поиска по раб. директории следует обратиться к методу shell.resolve(path), который используется большинством штатных скриптов в /bin/. Посмотри на отправляющий код с пред. сообщения - там я как раз добавил эту фичу для удобства

 

2 часа назад, WheatComp сказал:

Почему-то arg[1] выводит send. Вчера, когда пытался разобраться с аргументами, читал, что в Lua-интерпретаторах обычно args[0] выводит имя файла. Попытался в игре - выводит nil

Всё верно. В десктопном Lua ты получил бы что-то наподобие:

 

 

А в OpenComputers уже нет, т.к. глобальной переменной arg вовсе не существует:

 

 

Все входные аргументы мы получаем вручную через args = {...}, создавая при этом самую обычную переменную. Она не какая-то магическая, не системная. Её и назвать можно как угодно, хоть someWeirdDots = {...}, тут уж воля фантазии

 

2 часа назад, WheatComp сказал:

Робота удалось заставить шевелиться, но возникает некоторая путаница с командами. В ОpenOS же вперед - это forward(), а тут move(side). Придется изменить много кода и ошибки, чувствую, неизбежны

Согласен, хотя это скорее дело привычки. Всегда можно скопировать таблицу направлений из исходников Sides API, и воспользоваться ей для движения робота в нужную сторону, если вводить непонятные цифры а-ля robot.move(1/2/3/4) дискомфортно

 

2 часа назад, WheatComp сказал:

К тому же на сайте игры не написано, каковы же остальные "низкоуровневые" команды. Описаны move, turn, swing, а back, up, down не описаны

Как раз по этой ссылке и перечислены все остальные "низкоуровневые" команды, других попросту не существует в компоненте robot. Пикча для наглядности:

 

 

Например, back/up/down реализуются софтверно средствами OpenOS. При этом robot.back() из OpenOS эквивалентен компонентному вызову robot.move(2). Вообще крайне рекомендую чекнуть исходники по пред. ссылке - там много всего интересного, и на деле окажется, что работа с "чистым" роботом ничуть не сложнее, чем с библиотекой из OpenOS. Непривычно и неочевидно - да, есть такое

[WheatComp Автор вопроса 3]

@ECS Пришлось повозиться, но вроде получается ошибки вылавливать от робота с eeprom.

В 18.05.2023 в 21:49, ECS сказал:

Непривычно и неочевидно - да, есть такое

Непривычно - не то слово. Может, эта возможность загружать в "маленькое программируемое хранилище для запуска компьютеров", как сказано в описании в игре, большие программы, которые по-хорошему требуют жесткого диска, выполнять программы без слотов памяти - это баг, которое в скором времени пофиксят? И тогда как бы не пришлось опять переписывать все программы.

В 17.05.2023 в 18:10, eu_tomat сказал:

Но можно сделать что-то похожее на это.

Вы тоже имели в виду роботы с eeprom? Или, может, UMFAL AtomicScience-а?

Изменено 19 мая, 2023 пользователем WheatComp

[eu_tomat 2 154]

40 минут назад, WheatComp сказал:

Вы тоже имели в виду роботы с eeprom? Или, может, UMFAL AtomicScience-а?

Не обязательно именно EEPROM. Эти идеи хорошо работают и в среде OpenOS, да и вообще универсальны.

 

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

 

Дюп дисков хотя и является читерским, но тоже позволяет решить задачу внутриигровым способом. Законность дюпа устанавливает администрация конкретного игрового сервера. Можно считать это серой игровой механикой.

 

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

[WheatComp Автор вопроса 3]

19 часов назад, eu_tomat сказал:

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

Не совсем понял эту фразу. Во время игры пользоваться внеигровыми символьными ссылками? Чтобы программа робота обращалась к папке вне корневой папки Майнкрафта? Так мне это и требовалось. И как можно это реализовать?

  

18 часов назад, eu_tomat сказал:

Дюп дисков хотя и является читерским, но тоже позволяет решить задачу внутриигровым способом. Законность дюпа устанавливает администрация конкретного игрового сервера. Можно считать это серой игровой механикой.

 

Ну раз игровая механика... Скажите, пожалуйста, как дюпать жесткий диск? Я за честную игру, но если припрет, может,  когда-нибудь воспользуюсь. Очевидно, просто скопировать папку диска не выйдет, файловый менеджер не допустит.

[WheatComp Автор вопроса 3]

В 18.05.2023 в 13:59, ECS сказал:

Таблицы component/computer/robot/unicode/bit32 являются суперглобальными и доступны сразу при запуске микропрограммы EEPROM, однако во время инициализации OpenOS они маскируются из соображений консистентности кода.

Следующий код (robot.lua) почему-то не работает:

local robot = component.proxy(component.list("robot")())
local computer = component.proxy(component.list("computer")())

computer.pullSignal(3)

for i = 1, 4 do
  robot.turn(true)
end

Пытался проверить, будет ли 3-х секундная задержка (computer.pullSignal(3)), нет задержки.

upd: оказалось, pullSignal() относится к api. Есть ли "компонентная" альтернатива?

Изменено 20 мая, 2023 пользователем WheatComp

[ECS 1 903]

16 часов назад, WheatComp сказал:

Пытался проверить, будет ли 3-х секундная задержка (computer.pullSignal(3)), нет задержки

Эта штука ждёт каких-либо сигналов в течение 3 секунд. Если сигнал получен - pullSignal вернёт информацию о нём досрочно. Если сигналов не было - pullSignal будет честно ждать 3 секунды, а затем вернет nil

 

Вообще, как я понял, тебе нужен некий аналог os.sleep(3) из OpenOS, который реализован как раз на чистом pullSignal. Можно скопировать его из исходников

 

16 часов назад, WheatComp сказал:

upd: оказалось, pullSignal() относится к api. Есть ли "компонентная" альтернатива?

На самом деле не относится, это на вики мешанина. Суперглобалки component/computer/robot/unicode/bit32, а также штатные библиотеки Lua доступны отовсюду. Все остальное - софтверные фичи OpenOS

[Anon 25]

11 час назад, WheatComp сказал:

Не совсем понял эту фразу. Во время игры пользоваться внеигровыми символьными ссылками? Чтобы программа робота обращалась к папке вне корневой папки Майнкрафта? Так мне это и требовалось. И как можно это реализовать?

Очень интересная идея. Да, из опенкомпов можно использовать симлинки, но простого ярлыка будет недостаточно - в игре он окажется обычным файлом с расширением .lnk. 

 

Чтобы (на windows) засунуть в игровой хдд симлинк директории, нужно в cmd.exe (именно в cmd.exe, PowerShell, почему-то, такой команды не знает) прописать:

mklink /D <название ссылки> <путь к целевой директории>

 

Например, засунем в папки /home двух компов ссылку на директорию "C:\Test". Вуяля:

[WheatComp Автор вопроса 3]

16 часов назад, ECS сказал:

Вообще, как я понял, тебе нужен некий аналог os.sleep(3) из OpenOS, который реализован как раз на чистом pullSignal. 

Оказалось, мой косяк:

local robot = component.proxy(component.list("robot")())
local computer = component.proxy(component.list("computer")())

computer.pullSignal(3)

for i = 1, 4 do
  robot.turn(true)
end

определил computer, хотя он и так есть, как Вы и объяснили. Без этой строчки pullSignal работает как и должен работать. Наверное, им и буду пользоваться.

12 часа назад, Anon сказал:

Да, из опенкомпов можно использовать симлинки, но простого ярлыка будет недостаточно - в игре он окажется обычным файлом с расширением .lnk. 

Спасибо, работает, в том числе и модули можно использовать.