Перейти к содержимому

eu_tomat

Модераторы
  • Публикации

    2 666
  • Зарегистрирован

  • Посещение

  • Победитель дней

    331

Сообщения, опубликованные пользователем eu_tomat


  1. Именно этим занимается стандартный Serialization API.

    Он превращает Lua табличку в текстовый Lua-код, и обратно.

    С тем отличием, что не дает сериализовывать функции.

    Плюс - невозможность инъкции. Минус - в конфиге нельзя ничего вычислять. В принципе, конфиг и не для этого.

    Хотел поспорить, что десериализация не воспринимает комментарии, которые гораздо важнее возможности вычислений в конфиге.

    Но проверка выявила, что комментарии тоже воспринимаются. А это не всякий обработчик JSON умеет.

     

    Upd: (текст про обнаружение ошибок перенес в следующее сообщение)


  2. В этой теме я предлагаю обсудить плюсы и минусы использования 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-кода в качестве файла конфигурации.

     

    Если решение где-то уже обсуждалось, прошу кинуть ссылку на него.


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

    Хочешь сказать, что отсутствие диагноза "мозг рака" еще не является поводом для радости?

     

    Говоришь что хотелось бы таум, а тебя с малоразвитыми сравнивают...видно, взрослые люди

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

  4. Понимаю, конечно, низкую вероятность того, что отлаживаемый код вдруг переназначит какой-нибудь 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

  5. Ну лично у меня всё включается, не знаю.

    Разобрался, не прошло и года. Поиск по англоязычным сайтам быстро выдал решение: Ability for Robots to turn on PC´s #1505

     

    ШПКМ рукой игрока включает любую технику. Робот успешно выполняет ШПКМ на любых компьютерах и роботах, но включается при этом лишь техника в обычных корпусах. Компьютеры и роботы в творческих (лиловых) корпусах не включается по ШПКМ роботом.


  6. Поздравляю. Вы убили PvP. Вы убили, по сути, большую часть смысла игры.

    ...

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

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

    • Нравится 6

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

     

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


  8. С одной стороны хорошо, а с другой - никакого экшена, да и моды 146% будут не в теме. Вдруг тесла или лазерная турель будут игнорить, тогда плагин и не нужен.

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

     

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

    • Нравится 2

  9. По поводу сыпучих блоков, только что все проверил (в сингле, т.к. на сервере нет возможности проверить) ни чего не тупит, робот работает исправно, проблем не замечено.

    В сингле робот успевает переместиться до осыпания гравия, на сервере – не всегда. Ну, а попавшийся на пути моб собьет его с пути в любом случае.

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

    Уже было много случаев, когда робот «понемногу» терялся в лавововом озере или за пределами карты.

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

    Ну, а кто мешает проверить изменившийся слот на мусорность?

    смысл программы работать на eeprom, при минимальной комплектации робота, таблица предметов может потенциально привести к переполнению памяти и просто не влесть в память eeprom, на 1 планке ОП 1 уровня, а "аналоговая" проверка блоков работает медленнее (это надо еще проверить), но позволяет сделать фильтр довольно таки большой (если стоит достаточно улучшений на инвентарь).

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

  10. А в шапке сайта сжималка не кошерная? К тому-же есть еще crunch и мой алгоритм, который закидали какашками крипера.

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

  11. Я когда - то думал над проблемой проверки инвентаря, можно вести учёт в памяти, хотя бы примерное представление что и где.

    Тут две подзадачи, требующие оптимизации: найти слоты – изменившийся и соответствующий ему мусорный.

    Первую я бы решил так:

    -- очистить очередь сигналов
    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
      ...
    При наличии контроллера инвентаря быстрее всего будет получить номер мусорного слота из таблицы по имени предмета.
    • Нравится 1

  12. Жалко шахтера. Заблудится он в сыпучих блоках и будет ждать своего владельца на дне лавового озера.

     

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

     

    И вот это издевательство над роботом желательно укоротить:

    while (deepM % 3) ~= 0 do
        deepM = deepM - 1
    end
    • Нравится 1

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

     

    Уже давно мы обсудили его в теме про турели, где обсуждение было удалено как оффтоп. Суть его в том, что проблема нехватки энергии или слотов в отдельном роботе несущественна, т.к. увеличение количества роботов увеличивает и суммарное количество слотов всей робо-системы.

     

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

     

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

    • Нравится 2

  14. руки оторвать за такой стиль, надо так:

    ...
    os.sleep(0.25) -- 1 секунда слишком долго
    ...
    я лично оторву

     

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

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

     

    neiintegration_inventory

    neiintegration_tileentity

    neiintegration_recipehandler

    neiintegration_oredict

    neiintegration_entity

    neiintegration_loadedmod

    neiintegration_fluidcontainer

    neiintegration_fluid

    neiintegration_dimension

    neiintegration_chestloot

    itempanel

    biome

    enchantment

    potion

    block

    item

    Рецепты не найдены ни в одном из них. Что я упустил?

    • Нравится 1

  16. Обнаружилась непонятная проблема на SkyTech

     

    Есть робот, добавленный в приват:

    /rg info

    Ownwes: name:eu_tomat

    Members: name:eu_tomat.robot,name:opencomputers

     

    Нормально выполняется robot.suck() и robot.drop(), но контроллер инвентаря сундук не видит:

    lua> print(require("component").inventory_controller.getInventorySize(0))
    nil     no inventory
    Аналогично для сторон 1, 3.

     

    У TraerTaer была аналогичная проблема.

    Заходил newbie, но проблему не вылечил.

     

    Куда копать и что сеять?


  17. С чего бы вдруг сейчас взять и считать по СИ внезапно?

    Для того, чтобы программисты смогли оставить споры и начали спокойно кодить.

     

    Но это невозможно, мы всё равно найдем тему для спора.

     

    К примеру: сколько бит в миллибайте?


    • Не понимаю, зачем тратятся ресурсы на обратные вызовы get/set, если вместо вызова get можно передать параметр в функцию execute, а вместо вызова set вернуть из execute нужное значение. Должно получиться что-то типа:

      speed = speed + loop:execute(0.1,r-c)
      c = c + speed
      с избавлением от лишнего кода.
    • Не понимаю из примера, как управлять реактором. Какие показатели из реактора считываются, а какими параметрами реактор управляется.
    • Не понимаю из описания, как подбирать коэффициенты. Без этого код бесполезен.
    • Также есть мелкие ошибки, например, в строке local get=get() или if value>0 then speed=speed+math.min(value,0.1) else speed=speed+math.max(value,-0.3) end
×
×
  • Создать...