D-side

Идею я понял. Для её реализации, в сущности, нужно свести любую автоматизацию к программированию компа. А это значит, вопрос больше в наличии периферии для адаптации разных блоков. К сожалению, я не знаю, хватает ли для этого местного ассорти из периферии. Логистику если нерфить, то только при наличии подключаемого к компу блока, который умеет слать приходящие предметы в разные трубы в зависимости от программы; а также очень не помешает некий агрегат, умеющий взаимодействовать (по заданной на Lua программе) с инвентарём других блоков. Если будет это - будет всё. Но при этом подскочит (эдак до уровня орбиты) спрос на программные продукты, и если предложения будет недостаточно, сервер почти опустеет - останутся только разработчики-любители и те, кто с ними сумел скооперироваться. Собственно, мне такой исход вполне по душе, но... я это я. Я тут просто человек, принципы проекта и важные решения не за мной.

По-моему, прежде чем конструировать язык разметки, необходимо собрать "рендерер", делающий интерфейс пользователя из некоего дерева (или списка) элементов. А потом уже придумывать сериализацию этого дерева (или списка) в некий язык разметки и обратно. В любом случае, использование в качестве прототипа HTML мне видится неудачным выбором. Нам нужно скорее нечто вроде Markdown, похожий лёгкий по объёму и в обработке синтаксис.

Всегда срабатывает - подсчёт циклом. local count = 0 for k, v in pairs(tab) do count = count + 1 end Способа поумнее я не нашёл, и не уверен, что таковой вообще существует. Есть вариант поддержания длины таблицы в отдельном поле, но это не всегда годится.

Возможно, может помочь это, хотя это скорее ультракороткий обзор всего языка: http://learnxinyminutes.com/docs/lua/

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

Можно. Во-первых, определение user наверху достаточно свести к {}, строчку с __index перенести внутрь new (self.__index = self), а методы, описанные в user'е, для экономии памяти лучше реализовать на нотации с двоеточием. Она работает предельно просто: вызов X:m(args) превращается в X.m(X, args) Ну и user лучше написать с большой буквы, т. к. это класс, а из названия это не очевидно. User - гораздо лучше. Как-то так: function User:getPassword() return self.password end function User:setPassword(password) self.password = password end Обращаю внимание, что если методы getX и setX написаны с такой логикой, то они нафиг не нужны. Вот в этой шпаргалке есть неплохой раздел по "ООП". Рекомендую.

В синтаксисе определения таблиц слева от = не переменная, а строковый ключ, написание которого подчиняется тем же правилам, что и переменные - чтобы его можно было вызывать через точку. Это короткая запись чуть более длинной: {["filename"] = filename, <...>} Это зависит от программиста и определяется при создании объекта. Смысл можно заложить в само название переменной, куда он записан. Скажем, logfile.delete() - да, я однозначно пойму, что это, т. к. название переменной осмысленное. В символах может и нет. Но по смыслу - это короче. Удалить сущность "файл" мы можем только из файловой системы. Но тут у нас в языке такой сущности нет - она косвенно выводится из того факта, что строка (!) обрабатывается функциями для файловой системы (!), значит это файл. В этом отношении код с привязкой даже нагляднее - независимо от того, с какими файлами мы работаем (а мы можем о них ничего не знать), мы можем отвести в коде осмысленное имя. Справедливости ради стоит приложить аналогичный код на классе File, который я пока не написал, т. к. сегодня (буквально часа два назад) поставил свежий Linux Mint и накатил среду разработки в Lua.

В особо сложных программах бывает необходимость сократить вызов функции от некоторого числа аргументов, зафиксировав значение некоторых (или всех) из них, если другие значения в этом контексте использоваться будут редко. Подобные штуки есть в куче языков. В стандартную библиотеку C++0x для этого (в том числе) ввели std::function, в Haxe и Haskell это просто часть языка. Многие считают такой приём чертой функционального стиля программирования, который я ещё не освоил, но стараюсь. Работает это очень просто и код очень короткий. Берём функцию, указываем ей несколько первых аргументов - получаем функцию, которой надо указать только оставшиеся (если таковые есть): function bind(f, ...) local higherArg = arg return function(...) return f( unpack(higherArg), unpack(arg) ) end end Т. е. эта штука возвращает функцию, которая возвращает результат указанной вами функции, аргументами к которой выступает то, что вы указали при привязке (вызове bind), а затем то, что вы указали при вызове возвращённой из привязки функцией. Ещё ничего не закипело от обилия функций? Привожу пример. Можете посмотреть сразу в интерпретаторе Lua. Это не слишком практичный пример, поэтому вот кое-что поинтереснее. Допустим, вы хотите получить таблицу, содержащую путь к файлу и ряд команд, которые с ним можно выполнить без указания лишних данных. Примерно как у обычного объекта. Да, можно собрать класс "файл", но это не единственный способ, и у него свои недостатки. С биндом подобная штука записывается очень коротко: filename = "file" file = { filename = filename, run = bind(shell.run, filename), -- Можно смешивать функции из разных API delete = bind(fs.delete, filename) -- вообще без проблем } -- И эти операции можно вызывать без аргументов, забыв про API: file.run() -- Запускаем файл file.delete() -- Стираем файл Конечно, в случае больших задач "нормальный" класс (с вызовами методов через двоеточие) предпочтительнее, поскольку даёт больше контроля над возвращаемыми значениями и обработкой возможных ошибок. Но если это не требуется, можно сэкономить время с помощью привязки. Есть и другие способы применения, на которые вы, может быть, наткнётесь сами. Чаще всего это способ сэкономить на объёме кода, уложив повторяющийся аргумент. Компактнее, чем это делает вынесение в переменную, хотя потребляет несколько больше оперативной памяти, ведь такие "методы" будут создаваться каждый раз на каждую привязку. Осторожней с этим. Это часть более крупной библиотеки, которую я пишу вот тут, на гитхабе. Потом перейду к каркасику для приложений, состоящих из менюшек (что покрывает на удивление много случаев). Получить эту штуку на ComputerCraft'овский комп можно вот так: openp/github get D-side/luaCC/master/bind.lua bind Такие дела. Развлекайтесь! Надеюсь, скоро принесу ещё каких-нибудь плюшек.

Это вы меня не поняли =)Меня интересует конкретный способ получения данных компьютером. Функция в API, например. Формат данных. Устройство. Ссылка тоже сгодится, даже на английском. Меня интересует технический состав проблемы. А решение - это уже второй этап.

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

Это всё круто, но с какой аппаратуры эти показатели получать? Измерительные приборы соответствующие есть?

Эм, привет. Давай конкретнее - какое аппаратное обеспечение есть, под какой комп, за чем следить, что делать?