eu_tomat

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

 

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

 

Кроме того, не до конца понятно взаимодействие с миром. Во времена RedPower2 с кораблей можно было выпускать черепашек на добычу ресурсов и перерабатывать ресурсы прямо на борту. Потом был неплохой мод Redstone in Motion, сделавший кораблестроение даже более удобным. Сейчас вроде бы есть Remain in Motion, но я его не тестировал. Да, все эти моды позволяют строить только корабли, перемещающиеся исключительно вдоль кубической сетки. Физика скучная, но зато роботы без проблем загружаются на борт корабля и выгружаются.

 

Valkyrien Warfare имеет физику на порядок более интересную, но без компов этот интерес не раскрыть. Иногда вспоминать про этот мод будет полезным. Так что, пусть пока полежит в копилочке.

@@Appo, я не уверен, что мой подход удобен для всех, но попробую описать его.

 

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

 

Если мысль мне кажется сложной, всегда начинаю набор в обычном текстовом редакторе. Форматирую там же, теги расставляю руками. Благо, много их не требуется. Если форматирование сложное, использую LibreOffice Writer и форматирую текст в нём для оценки внешнего вида. А потом к выделенному каким-то стилем тексту вручную добавляю нужные теги и переношу в форму сайта как простой текст.

 

Затем в форме редактирования или создания поста выбираю предпросмотр и перечитываю пост, оцениваю вид. Если обнаруживаются ошибки, исправляю в том же текстовом редакторе, снова вставляю текст в форму и выбираю предпросмотр. И так до полного удовлетворения статьёй.

 

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

 

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

 

Если говорить в общем, то большое разнообразие шрифтов, их стилей, размеров скорее порит внешний вид статьи, нежели улучшает его.

 

Редактировать основное оформление я не буду. Я вообще не знаю, будет ли эта тема популярной и читаемой. Мне она кажется полезной, @@Fingercomp особого смыла не видит, а другие пока молчат. Пусть пока тема остаётся в текущем виде. Исправлю только самое начало, удалив нестандартные шрифты. Оно, конечно, будет диссонировать с дальнейшим текстом, но и не все захотят читать тему дальше.

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

А двигателями переворачивающийся корабль можно выровнять? И ломаются ли его блоки при столкновениях с кораблём противника или со скалой, например?

Так что вот. Знайте, что есть такой крутой мод. Но он сырой пока и с компами не дружит. А когда начнёт дружить представляете как будет круто?

Да, было бы интересно посмотреть именно с компами. Интересно было бы управлять каждым двигателем независимо, программно следя за устойчивостью корабля и его курсом. Интересно было бы получать повреждения от столкновений с другими блоками. Будет чем-то похоже на Space Engineers.

Еще 4 игры которые подталкивают вас программировать

Полезная тема.

 

А можно оформить её чуть иначе? Было бы удобно видеть в начале темы список названий игр и языков программирования для них. А то сейчас с крупным шрифтом и обилием картинок приходится долго скроллить, что рассеивает внимание.

Почему мы берём именно сечение цилиндра? Осевое сечение конуса можно брать для решения задач с ним?

...

Всё никак не пойму общего вида решения для любой фигуры.

Интуиция мне говорит, что площадь осевого сечения конуса можно использовать для оценки его объема. Но для подтвеждения этого надо всё-таки вывести формулу, желательно для случая проивзольного профиля осевого сечения. Для конуса формула выводится по тому же алгоритму, что и для цилиндра, но я пока не занимался этим вопросом. Меня сейчас больше занимает поиск решения для произвольного профиля. Если тебе интересен случай конуса, то посчитай сам, не ленись.

 

а кажись я понял что я не вщитал ) нужно просто принять S или V как константу и дальше все зведется к 2R = H если не принять константу то у формулях всегда размер будет стремится к Бексончености

Да, многие допускают эту ошибку. И чтобы расставить точки над Ё, приведу аналогию, понятную майнкрафтерам.

 

Вот, есть у нас кубик. Он имеет объём одного куба и площадь в шесть квадратов.

 

Возьмём ещё один кубик. Суммарно их объём составлит два куба, а площадь 12 квадратов. И если мы поставим эти кубики один на другой, то суммарный объём не изменится, зато площадь уменьшится на два квадрата. В принципе, эти два кубика можно было бы соединитдь любыми сторонами, площадь всегда уменьшится на два квадрата. Но пока оставим фигуру из двух поставленных друг на друга кубов.

 

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

 

В следующей итерации объединения фигур можно будет уменьшить суммарную площадь поверхности на 4 или на 8 блоков. Эффективность фируры при росте её объема возрастёт в любом случае, но максимума она достигнет только при соотношении сторон, приближающем форму готовой фигуры к кубической.

 

Понятно, что мы не можем просто так склеить два цилиндра боковыми поверхностями, но аналогия сохраняется при выборе увеличить ли высоту цилиндра или его радиус. Как уже говорилось выше, оптимальное соотношение радиуса и высоты даёт квадрат в осевом сечении цилиндра.

И кстати, я уже не вижу кнопки "объявить ответ и закрыть тему". Кажется раньше такая была или мне это всё приснилось. Ну и ладно, тогда пусть открыта тема будет.

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

 

справедливо ли утверждение, что приравнивая площадь сечения можно получить истинно-верный ответ? Или это просто совпадение?

И да и нет. Смотря как сечь фигуру. К примеру, в сечении цилиндра можно увидеть круг, который никак не покажет нам результаты оптимизации. Опытные математики знают правильное сечение, что упрощает им жизнь. Зато площадь поверхности фигуры является более универсальным мерилом, формулы усложняются, но возможность ошибки при аккуратном преобразовании формул исключена.

 

нужна именно площадь или объём? (площадь умноженная на бесконечно малую единицу)

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

 

Наш пример: Находим полезный объём цилиндра, объём с добавлением толстых стенок, и объём самой стенки. Затем получаем площадь делением объёма стенки на её толщину и находим её предел при стремлении толщины к нулю.

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

Лайки этим постам:

Первоначально, n можно не учитывать. Бери просто, площадь поверхности цилиндра.

Нужно вспомнить, что производная в точке экстремума равна нулю

Если абстрагироваться от толщины стенки, то есть считать ее бесконечно тонкой, то задача решается поиском минимальной площади поверхности цилиндра при заданном объеме. Если просто нужен ответ, то ответ 2, то есть H/R = 2 (осевое сечение цилиндра - квадрат).

Это походу частный пример, когда Vцил.=const. А иначе - мы будем иметь ряд точек.

И далее подробнее с этого места:

Вот только я смутно понимаю, что такое производная. И особенно на трёхмерном графике. Это где вообще?

К чёрту трёхмерные графики. Они тут нам вообще не нужны.

 

Для начала вспоминаем, что производная — это скорость роста функции в каждой её точке. Попробую пояснить её применение на этой задаче.

 

Объем цилиндра зависит от его радиуса и высоты. И площадь тоже зависит от радиуса и высоты, но по другой формуле.

 

Нам нужно минизировать площать при заданном объеме. Или наоборот, но это совсем не принципиально, т.к все формулы обратимы. Я считаю, что формулы имеют более простой вид при выводе площади из объема. Попробуйте сделать наоборот, и мой выбор станет понятным.

 

Сначала выведем формулу зависимости площади от радиуса или высоты при постоянном объёме. На каком-то участке функции будет наблюдаться уменьшение площади, а на каком-то её увеличение. То есть, функция сначала будет падать, а затем, пройдя точку минимума, начнёт подниматься. В точке минимума функции её производная обратитится в ноль. Соответственно, приравняв к нулю производную, мы сможем найти точку, в которой площадь минимальна.

 

В формулах это будет выглядеть таким образом:

 

Формула объёма цилиндра, формула зависимости высоты от объема и радиуса:

Площадь цилиндра, подставлена высота из предыдущей формулы:

Объём цилиндра принимаем за константу, а площадь дифференцируем по радиусу и приравниваем производную к нулю:

Это зависимость объема от радиуса при условии, что поверхность цилиндра минимальна.

Подставляем в изначальную формулу объема и получаем соотношение высоты и радиуса:

При этом соотношении площадь цилиндра минимальна при заданном объеме. Справедливо и обратное: при заданной площади объём цилиндра максимален. Задача для случая бесконечно тонкой стенки цилиндра решена.

 

Аналогичным образом можно задать толщину стенки произвольного размера. В этом случае используем постоянный полезный объём, и ищем минимум для объёма, к которому добавляется толщина стенок. Я упоролся и таки вывел формулы и для этого случая тоже. Результат совпал с предыдущим, но формулы получились многократно сложнее. Поэтому публиковать я их не буду. Алгоритм их получения тот же самый, с той лишь разницей, что придётся написать больше символов, и будет больше шансов допустить ошибку. Тут помогут только аккуратность и терпение.

Это как зубная щётка в общаге. Тебе важнее чтобы ею никто не пользовался и держать её грязной? Хотя она скорее всего никому и так не нужна. Или тебе больше нравится чистая щётка?

Прекрасное сравнение.

 

Работа над любым проектом рано или поздно приостанавливается, а иногда приходится возвращаться к старому коду через полгода-год. И если бы не удобное оформление кода и комментарии, мне иногда было бы проще переписать код заново, чем разбираться в уже написанном. Через полгода для меня собственный код выглядит чужим. Но удобный для меня стиль, а также комментарии всякий раз экономят моё время. Очень рекомендую.

можно пример простенькой программы ,де издаётся любая нота ?

Нота Ля первой октавы:

local computer=require"computer"
computer.beep(440,1)

Если никто не сможет прочитать код-никто не сможет его критиковать если не сможет его понять

Почему же никто не сможет? Настойчивый критик обычно открывает ссылку в меню форума: Сервисы > Lua > Форматтер Lua, вставляет код, клацает на «Beautify» и критикует в своё удовольствие. Кто же остановит настойчивого критика?

 

Менее настойчивые, конечно же, просто игнорируют темы с плохо оформленным кодом. Имеют право.

Наоборот,если его понять не могут-это же хорошо))

Любопытный подход. И в чём же польза непонятного кода?

сейчас делать красивым уже написанный код не хочется.

Не обязательно делать код красивым. Сделай его хотя бы понятным. Если, конечно, хочешь, чтобы кто-то читал его.

Покажите как в порядок привести отступы.Я не понимаю,покажите и объясните как должен выглядеть хороший код(Желательно объяснить,а не кинуть просто красивый код)

Отступы, как и другие правила форматирования кода, не влияют на его работоспособность, но сильно влияют на его чтение. Любое оформление кода: отступы, разделение кода на строки, дополнительные пробелы, комментарии – должно подчёркивать мысль программиста. Отступы, например, помогают при беглом осмотре понять блочную структуру кода, что в какой оператор вложено.

 

Попробую разобрать имеющийся код:

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

 

* Первым я вижу ключевое слово function, отмечаю точкой начало оператора и ожидаю его завершения ключевым словом end.

* Но дальше встречаю оператор for, начало которого я токже отмечаю точкой и снова просматриваю код в ожидании end.

* следующие после for две команды оформлены с отступами, но потом отступ уменьшается, что создаёт иллюзию того, что эти команды в цикл не вложены, что не соответствует действительности. Но продолжаем искать end, завершающий for.

* Дальше встречается ключевое слово if, содержащиеся с нём команды, правильно оформленные отступом, а также закрывающее ключеове слово end. Тут сразу можно нарисовать линию, выделяющую этот блок команд.

* Дальше снова встречается if, закрываемый end. Отступ для команд выбран верный, а отступ для end следует уменьшить.

* потом встречается end. Смотрим, какая последняя точка ещё не превратилась в линию и видим, что этот end закрывает for. Да, он находится на одной линии с ним, так и должно быть. Но он находится и на одной линии с предыдущим if, и создаётся иллюзия, что закрывается именно if. Такие отступы дезориентируют и мешают поиску ошибок в коде.

* дальше отступы правильные, и хорошо видно, что end закрывает function.

 

Как привести отступы в порядок? Первые символы строк кода должны постоянно образовывать фигуры, напоминающие закрывающую квадратную скобку:

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

сделал

Судя по коду, программа рабочая.

 

Советы по улучшению кода интересуют? Если да, то рекомендую начать с приведения в порядок отступов. Правильные отступы сильно облегчают обнаружение шероховатостей кода.

Короче, если вопрос еще актуален, код чуть ниже предоставляет 2 функции включить и выключить, никаких модификаций в библиотеках он не требует, т.е. достаточно вставить его куда-нибудь поближе к началу. Работает за счёт переопределения computer.pullSignal блокируя все ошибки изнутри.

Вопрос ещё как актуален, он регулярно всплывает. И ознакомиться с таким решением очень полезно. Наилучший ответ.

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

Выбрасываем костыль:

function onChatMessage(...)
  for n,arg in ipairs({...}) do
    print(arg)
  end
end

Правильный ответ: никак. payonel отрубил это давным-давно из-за костылизма решения. Обратно что-то заменяющее, однако, введено не было.

О, печаль.

Писать прогу без системы - и все под полнейшем контролем.

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

Предполагаю, что нужно удалить какой-то файл из openos

Не скачивал свежую версию OpenComputers, но если имеющиеся у меня файлы не устарели, то должно помочь удаление из файла /lib/event.lua следующих строк:

  local interrupting = current_time - lastInterrupt > 1 and keyboard.isControlDown() and keyboard.isKeyDown(keyboard.keys.c)
  if interrupting then
    lastInterrupt = current_time
    if keyboard.isAltDown() then
      error("interrupted", 0)
    end
    event.push("interrupted", current_time)
  end

А можно вырезать только эту часть:

    if keyboard.isAltDown() then
      error("interrupted", 0)
    end

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

Поиск по форуму приводит к следующему решению:

http://computercraft.ru/topic/1870-kak-predotvratit-prinuditelnyi-ostanov-prog/

 

 

скорее всего как-то так (вставить функцию куда-то в тело программки):

function event.shouldInterrupt()
    return false
end

 

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

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

1) безопасно выполнить принятый код и отослать результат на пульт;

2) добавить принятый код как постоянную команду с назначенным номером;

3) удалить команду с определенным номером или сразу все для очистки памяти;

4) безопасно выполнить команду с определенным номером (что отчасти реализовано) и отослать результат выполнения на пульт.

 

А можно вообще обойтись только первым пунктом.

Помнится, форумчане даже соревновались в написании наикомпактнейшего загрузчика кода:

http://computercraft.ru/topic/833-bios-net-dlia-tcentralizovannogo-upravleniia-setiu-kont/

Он, конечно, не в фоне работал, но тут важен принцип функционирования.

Мои впечатления от кода:

 

Отступы расставлены как попало, что затрудняет чтение кода и поиск ошибок.

 

Функции drop(), dropUp() и dropDown() вряд ли работают так как это было задумано:

local function drop()
    for i = 1, size do
        robot.drop()
        robot.select(i)
    end
robot.select(i)
robot.drop()
robot.select(1)
end

Бессмысленно пищать динамиком о недостатке энергии при удаленном управлении:

    if energy <= 1500 then
    computer.beep()
end

Нужно сообщать эту информацию на планшет, а уже он сможет издавать звук или сигнализировать о проблеме иным путём.

 

Не ясно, что делает эта одиноко стоящая конструкция: math.floor(energy)

 

П.с пока не умею пользоваться таблицами,но кажется уже понял как избавиться от куча if и elseif

Длинная конструкция типа этой:

    if code == 17 then
robot.forward()
    elseif code == 30 then
robot.turnLeft()
    elseif code == 32 then
robot.turnRight()
...

перемещается в таблицу примерно таким образом:

local cmd = {
	[17] = robot.forward,
	[32] = robot.turnRight,
...
}
...
if cmd[code] then
  cmd[code]()
end

Погоди,а если игрок в оффлайне-робот разве может ломать в привате?От одного человека узнал что не могут.

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

Ну, хорошо. Критики рассказали о том, что останется невостребованным. Но есть и уникальная особенность брони:

Возможность программного управления персонажем

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

 

Пробежать по нужным нодам, восстановить заряд палочки, не истощая ноды, теперь не будет проблемой. Изучить тумометром всякие новые предметы тоже можно автоматически. Синтезировать сложные аспекты из простых при исследованиях, сложить оптимальную комбинацию из аспектов, да и вообще исследовать весь таумономикон можно будет автоматически. Запуск наполнения на алтаре тоже можно будет автоматизировать. Теперь хорошо экипированный АФКашник может отбиться от случайных атак слабых игроков, вовремя съесть нужную еду или выпить зелье.

 

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

 

Что должен уметь автопилот? В первую очередь он должен "видеть" всё, что видит игрок: различать блоки, игроков, мобов, знать свои координаты и положение в пространстве, читать любые характеристики предметов в инвентаре и различать элементы интерфейсов. Также автопилот должен обеспечить полную возможность управления персонажем: перемещаться, переключать режимы брони и оружия, перемещать предметы в инвентарях, крафтить на обычном столике, зачаровывать вещи на столе зачарований и наковальне, переименовывать их, ставить блоки и ломать их, бить мобов, пользоваться зельями и т.д. Короче, нужна возможность полной автоматизации любых действий игрока.

 

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

 

Голосую "за" в надежде на то, что броня будет воплощать именно эти идеи.

не знал куда написать тему

Во флудилке ей самое место.

ssd на 120 гигаметров

Тут, наверное, ошибка. Я не слышал о существовании таких длинных SSD в обозримом нами секторе Вселенной. Даже расстояние от Солнца до Венеры немного меньше. К тому же более важным показателем для SSD является не его длина, а объём. А объём измеряется в метрах кубических.

Из какого-то канала Telegram. Подтвердить инфу не могу, увы(

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

 

Лишним не будет - выполняется моментально.

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

 

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

 

Любая локальная переменная доступна исключитлельно в области своей видимости. Соответственно, локальная переменная psk доступна только в предалах блока do ... end, внутри которого она была объявлена, а по окончанию его работы занимаемаемая ею память становится доступной для освобождения сборщиком мусора. Но и на этом этапе содержимое переменной не будет удалено. Оно будет затёрто лишь при инициализации новых переменных, если они, конечно, будут созданы на этом участке памяти. Операция psk = nil тоже не удаляет строку, а лишь указывает, что теперь значение переменной пустое, а ранее занятая переменной память может быть освобождена сборщиком мусора. И даже psk = string.random(psk:len()) не перезаписывает пароль в ОЗУ, а лишь создаёт новую строку, и присваивает ссылку на неё переменной psk, а сама же строка остаётся в неизименном виде до тех пор, пока до неё не доберётся сборщик мусора. Но и он, как говорилось выше, переменную не очищает.

 

Что мы имеем в итоге? 35 раз создаётся новая строка, а ссылка не неё присваивается переменной psk, каждый раз затирая предыдущую ссылку (не строку!). Потом ссылка (не строка!) очищается при выполнении psk = nil. А по окончании выполнения блока do ... end теряется доступ к самой переменной psk. Значение имеет только последнее действие: доступ к переменной потерян. Сам ключ и 35 экземпляров случайных строк продолжают висеть в памяти. Со временем сборщик мусора освободит память из-под этих переменных, а их значения так и останутся в памяти, пока на их месте не будут созданы и инициализированы новые переменные.

 

Конечно, интенсивное создание случайных строк ускорит использование сборщика мусора и в конечном итоге даже перезапись того участка памяти, где когда-то был ключ. Но возникают два вопроса. Почему 35 итераций достаточно для гарантированного удаления ключа? И какая в этом польза, если доступ к ключу внутри Lua всё равно уже потерян, а другого доступа в OpenComputers нет и не предвидится?