eu_tomat

Да тебя как ни упомянешь, а ник уже устарел. В следующий раз упомяну тебя как «Мистер – семь ников на неделе», станешь еще популярнее. JSON хорош своей универсальностью и поддержкой во многих ЯП – это точно. Но о какой универсальности и других ЯП можно говорить, находясь в рамках СС и OC? К тому же, за универсальность приходится платить потреблением памяти и дискового пространства. Ты смотрел на размер этого модуля? Теперь сравни с объемами памяти, предоставляемыми OpenComputers. Есть стимул сберечь память для данных поважнее этой либы. Поэтому в контексте Майнкрафта единственным достоинством JSON остается синтаксический контроль, которого можно достичь гораздо более эффективными методами Тянуть зависимости для исполнения Lua-кода тоже не требуется. Расплатой за контроль синтаксиса конфига является небольшое увеличение кода: -- формирование пустого окружения и сокрытие глобального окружения local cfg={} cfg._G=cfg -- получение конфигурации и возможных ошибок при ее обработке local ld,er = loadfile("./test-cfg.cfg","",cfg) if ld then ld,er = pcall(ld) end -- вывод ошибок, возникших как на этапе компиляции, так и исполнения кода if not ld then error("Ошибка в файле конфигурации:\n\t"..er,0) end -- таблица конфигурации готова к использованию! for k,v in pairs(cfg)do print(k,v)endПарсер @Fingercomp нужен лишь для логического контроля, хотя тоже полностью его не обеспечивает. А если логический контроль важен, то он будет использован в почти в неизменном виде как в случае исполнения конфига, как десериализации, так и JSON. Что касается Lua-инъекций, то с этим, похоже, нет особых проблем. Главное, не пихать load в окружение обработки конфига.

При десериализации конфига невозможно установить, в какой строке файла произошла ошибка. Это минус. При выполнении – легко. Правда, сейчас ни мой вариант, ни вариант @@Fingercomp не способны обнаруживать любые возможные ошибки. Для полной обработки ошибок их нужно ловить как на этапе компиляции (в load), так и выполнения (в pcall) кода.

Хотел поспорить, что десериализация не воспринимает комментарии, которые гораздо важнее возможности вычислений в конфиге. Но проверка выявила, что комментарии тоже воспринимаются. А это не всякий обработчик JSON умеет. Upd: (текст про обнаружение ошибок перенес в следующее сообщение)

В этой теме я предлагаю обсудить плюсы и минусы использования Lua-кода в качестве файла конфигурации. Побудила меня к этому недавняя тема, в которой один форумчанин предложил использовать библиотеку JSON, а другой счел такое решение избыточным. У меня есть свое решение, но оно спорное. И чтобы не мусорить в той теме, предлагаю обсудить его здесь. Надеюсь, раздел я выбрал подходящий. Есть два файла: test.cfg -- Файл конфигурации return{ a=1; b=2; c=3; --можно выполнять вычисления прямо в конфиге bufLen=1024*1024*4; --и даже задействовать стандартные или пользовательские функции, если они указаны в окружении hypotenuse=sqrt(3^2+4^2); --в тестовых целях можно спровоцировать ошибку обработки конфига: --z=z.z; } test.lua -- обычно достаточно указать пустое окружение local env={} env._G=env -- но если требуется произвести вычисления прямо в конфиге -- с привлечением методов или даже целых библиотек, -- то их следует добавить в окружение local env={sqrt=math.sqrt} env._G=env -- получение конфигурации и возможных ошибок при ее обработке local cfg={pcall(loadfile("test.cfg",nil,env))} -- проверка на наличие ошибок if not cfg[1] then error("Ошибка в файле конфигурации\n "..cfg[2],0) else -- получение самой конфигурации (без статуса ошкбки) cfg=cfg[2] end -- таблица конфигурации готова к использованию! for k,v in pairs(cfg)do print(k,v)end Достоинства подхода: обладает возможностями, идентичными JSON не требует дополнительных библиотек малый объем дополнительного кода возможность указания вычисляемых параметров даже с использованием функций Недостатки:Имеется возможность Lua-инъекцииТак как пользователь сам формирует конфигурационный файл, то опасность Lua-инъекции мне представляется незначительной, тем более в рамках OpenComputers, да и вообще внутри MineCraft. Считаю даже, что такое решение с определенными ограничениями годится и для реального использования. Тем не менее, интересно узнать мнение опытных программистов, какие сложности возникают при использовании lua-кода в качестве файла конфигурации. Если решение где-то уже обсуждалось, прошу кинуть ссылку на него.

Хочешь сказать, что отсутствие диагноза "мозг рака" еще не является поводом для радости? Скажу, как взрослый взрослому: речь шла не про любителей Таума, а про способности в OC.

Всё просто за исключением некоторых нюансов. Но и они со временем проясняются.

Понимаю, конечно, низкую вероятность того, что отлаживаемый код вдруг переназначит какой-нибудь table.insert, но устойчивость отладчика можно повысить, заранее скопировав все используемые глобальные методы в локальные переменные. Сам отладчик не запускал, но выглядеть это будет примерно так: > print(coroutine.yield) function: 0x41a600 > e={}for k,v in pairs(_G) do e[k]=v end > pcall(load("coroutine.yield=nil")) > print(coroutine.yield) nil

Если мозги не из рака.

Разобрался, не прошло и года. Поиск по англоязычным сайтам быстро выдал решение: Ability for Robots to turn on PC´s #1505 ШПКМ рукой игрока включает любую технику. Робот успешно выполняет ШПКМ на любых компьютерах и роботах, но включается при этом лишь техника в обычных корпусах. Компьютеры и роботы в творческих (лиловых) корпусах не включается по ШПКМ роботом.

Дрон с теслой не менее действенно решит проблемы без участия со стороны Администрации. К тому же, возводя веселье на новый уровень.

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

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

В сингле робот успевает переместиться до осыпания гравия, на сервере – не всегда. Ну, а попавшийся на пути моб собьет его с пути в любом случае. Уже было много случаев, когда робот «понемногу» терялся в лавововом озере или за пределами карты. Ну, а кто мешает проверить изменившийся слот на мусорность? Таблица для пяти мусорных предметов не займет много памяти. А периодическое стандартное сравнение слотов всяко быстрее проверки ВСЕХ мусорных слотов на КАЖДОЙ итерации. Делов-то: Изменился слот – сравниваем с мусором, и если требуется, чистим и новый слот и слот с образцом.

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

Тут две подзадачи, требующие оптимизации: найти слоты – изменившийся и соответствующий ему мусорный.Первую я бы решил так: -- очистить очередь сигналов while computer.pullSignal(0)do end -- добыть блок robot.swing(3) -- пропустить сигналы кроме нужного repeat ev,slot=computer.pullSignal(0) until not ev or ev=="inventory_changed" -- новый предмет в [slot]? if ev=="inventory_changed" then ...При наличии контроллера инвентаря быстрее всего будет получить номер мусорного слота из таблицы по имени предмета.

Жалко шахтера. Заблудится он в сыпучих блоках и будет ждать своего владельца на дне лавового озера. И карьер проходить он будет медленно, роясь в инвентаре на каждом шаге. И вот это издевательство над роботом желательно укоротить: while (deepM % 3) ~= 0 do deepM = deepM - 1 end

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

Я в прошлом году так ногу сломал. Стиль изменился до неузнаваемости, но я так и не понял, почему 1 секунда – слишком долго, а 0.25 – приемлемо.

Options > Tools > Data Dumps. Там список всех возможных дампов. Вывожу все и получаю список файлов: Рецепты не найдены ни в одном из них. Что я упустил?

А как получить дамп с рецептами?

local debug = computer.addUserЭта строчка сильнее других провоцирует у меня расстройство сознания.Ну, почему «debug»? И далее: prov=debug(name) ... computer.removeUser(name)И почему тогда не сделано что-то типа: local bug = computer.removeUserТо есть, сначала обезжучили пользователя, а потом снова его нажучили.

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

@@Alex, А как там будет с золотом? Как получить компы на ранних стадиях игры? Меня устроит за UU.

Точно, засада была в квадратных скобках.