Программа "Очень много электричества"

[ReiVanSTR 0]

Мне было бы самому интересно написать код. Но нужны примеры работы с комментариями к коду. К примеру я скопировал генератор укреп. камня с Вашего форума, он не работал по началу. Потом разобрался что к чему, не без косяков конечно - работает . Насколько сильно отличается ось 1.6 от 1.7+? И возможно ли будет переписать код под "старьё"? Буду рад любой помощи! 

 

 

P.s. Спасибо за ответы)

[serafim 271]

В программу контроля реактора добавил проверку на версию OC,

необходимые методы у транспозера появились только с версии мода opencomputers 1.7+

Увы но большинство серверов до сих пор сидят на 1.6.2 которому уже больше трёх лет,

в итоге прога вылетает в ошибку.

 

пример проверки на версию OC

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

local arr = {}
for w in string.gmatch(_OSVERSION, "%d+") do
  table.insert(arr, w)
end
if tonumber(table.concat(arr)) < 170 then
  print("обнаружен ".._OSVERSION.."\n".."требуется версия 1.7 +")
  os.exit()
end

 

 

[hohserg 195]

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

[serafim 271]

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

А на старом апи транспозера нельзя сделать тот же функционал?

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

По моим наблюдениям конденсатор за одну секунду может выгореть от 0 до 4 % в зависимости от схемы в реакторе.

Реактор обновляет данные 1 раз в секунду, сейчас прога опрашивает его каждые 0,7 секунд методом транспозера getAllStacks

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

расположение конденсаторов не перебирая всё содержимое камеры.

 

Возьмём к примеру эту эффективную схему  

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

Здесь 13 конденсаторов, и без метода getAllStacks придётся перебирать их по очереди делая 13 опросов реактора, и это нужно

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

 

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

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

Возможно это можно будет победить опросом размера инвентаря, но это не сильно надёжно и возможны ошибки,

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

 

Возможны ещё какие то проблемы вылезут в процессе.

 

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

Изменено 20 июля, 2020 пользователем serafim

[hohserg 195]

А за сколько примерно можно чекнуть 13 слотов со старым апи? Если это не слишком большая задержка, то можно просто офать реактор до проверки и врубать после проверки и замены конденсаторов.

[eu_tomat 2 148]

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

А за сколько примерно можно чекнуть 13 слотов со старым апи? Если это не слишком большая задержка, то можно просто офать реактор до проверки и врубать после проверки и замены конденсаторов.

13*0.05 = 0.65 секунд на проверку. Плюс 2*0.05 = 0.1 секунд на замену одного отражателя. Вполне реально. Но при сильном снижении TPS сервера можно и не успеть произвести замену. Особенно, если требуется заменить более одного отражателя за раз.

 

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

 

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

 

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

 

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

 

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

[serafim 271]

13 часа назад, eu_tomat сказал:

13*0.05 = 0.65 секунд на проверку

Информация подтвердилась, перебор 13 ячеек реактора занимает 0.65 секунд

Накидал кусок кода из доступного апи, можете сами потестить

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

local com = require("component")
local computer = require("computer")
local sideReac,sideInv
local slotReac = {}
local tr = com.transposer
local reactor = com.reactor_chamber

print("поиск реактора и сундука")
for i=0,5 do
  local vr = tr.getInventorySize(i)
  if vr then
    if vr >= 54 then
      print("реактор в стороне: "..i)
      sideReac = i
    end
    if vr == 27 then
      print("сундук в стороне:  "..i)
      sideInv = i
    end
  end
end
if not sideReac then
  print("\n".."камера реактора не найдена")
  os.exit()
end
if not sideInv then
  print("\n".."сундук не найден")
  os.exit()
end
local slotsReac = tr.getInventorySize(sideReac)
local slotsInv = tr.getInventorySize(sideInv)

print("сохранение расположения конденсаторов")
local start = computer.uptime()
for i = 1,slotsReac do -- количество ячеек
  local data = tr.getStackInSlot(sideReac,i)
  if data then
    if string.find(data.name,"ondensator") then
      per = math.ceil(100*data.damage/10000)
      print("слот: "..(i).."  износ: "..per.." %")
      slotReac[#slotReac+1] = i
    end
  end
end
print("времени затрачно на опрос реактора:  "..computer.uptime()-start)

 

На строке 35 поменяйте slotsReac на то значение ячеек реактора которое вас интересует от 1 до 54

Перебор всех 54 ячеек реактора занимает 2,9 секунды

Изменено 22 июля, 2020 пользователем serafim

[hohserg 195]

В 22.07.2020 в 10:12, eu_tomat сказал:

Но при сильном снижении TPS сервера можно и не успеть произвести замену. Особенно, если требуется заменить более одного отражателя за раз.

Реактор работает независимо от тиков?

 

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

 

  

15 часов назад, serafim сказал:

Перебор всех 54 ячеек реактора занимает 2,9 секунды

А ведь не все слоты заняты конденсаторами, можно чекать только слоты с расходниками, а не все подряд

Изменено 23 июля, 2020 пользователем hohserg

[serafim 271]

3 часа назад, hohserg сказал:

можно чекать только слоты с расходниками

Там так и делается, в таблицу slotReac сохраняется расположения конденсаторов а затем только их чекают.

Перебор всех слотов привёл как пример, На строке 35 можно поменять значение slotsReac например на 13 ячеек

Вести расчёт на сколько за тик меняются проценты без опроса реактора идея отличная, но требует много мороки с кодом

 

Изменено 23 июля, 2020 пользователем serafim

[eu_tomat 2 148]

11 минуту назад, hohserg сказал:

Реактор работает независимо от тиков?

Это вряд ли. Скорее всего, в полном соответствии с тиками. Я могу ошибаться, но склоняюсь к тому, что лагает исполнение кода Lua в OpenComputers. Причём, слово "лагает" я использую в изначальном его смысле, когда ожидаемое событие приходит с задержкой. Боюсь сейчас соврать, результатов экспериментов под рукой нет, но, насколько я помню, обращение к периферии вместо одного тика иногда требует двух тиков, а в моменты сильного снижения TPS задержка доходила и до 5 тиков. И это, возможно, не предел.

 

21 минуту назад, hohserg сказал:

А реактор вообще детерминированно работает? И без псевдорандома?

Все мои эксперименты подтверждали абсолютно детерминированную работу реакторов. Случайности возникают вокруг реактора: случайным образом поджигаются блоки или превращаются в лаву. Блоки обшивки ЖЯР тоже могут выгореть случайным образом. Но компоненты реактора взаимодействуют друг с другом абсолютно предсказуемым образом.

24 минуты назад, hohserg сказал:

Если совместить такой подход с независимой от тиков реализацией os.sleep, то это должно дать хороший результат

Я плохо понял о чём здесь идёт речь. Чем плоха реализация os.sleep, если не вешать на него тяжёлые обработчики событий? Работа os.sleep основана на вызовах computer.pullSignal, другого вменяемого способа для создания задержек нет.

 

Чтобы понять, насколько хорошим будет результат при фиксированных задержках, нужен ряд экспериментов и правильно интерпретация их результатов:

1. Надо всё-таки понять, в каком месте возникает джиттер: на этапе тиков реактора, или на этапе получения ответа от транспозера.
2. Надо как-то определить теоретически максимально возможный размер джиттера.
3. Надо проверить, нет ли дрейфа циклов ректора при выгрузке-загрузке чанков.

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

[NEO 541]

3 часа назад, eu_tomat сказал:

а в моменты сильного снижения TPS задержка доходила и до 5 тиков.

Видимо следствие того что потоки для компов низкоприоритетные.

[eu_tomat 2 148]

14 часа назад, NEO сказал:

Видимо следствие того что потоки для компов низкоприоритетные.

Да, подтвердилась гипотеза о лагах при получении ответа от периферии. Я провёл эксперимент, имитируя сильные и продолжительные лаги. Оказалось, что вызов transposer.getStackInSlot() может иногда длиться до 36 тиков. И это, я думаю, не предел. Реактор за время между двумя последовательными чтениями состояния одного слота иногда успевал отработать три своих такта.

 

Выводы:

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

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

[hohserg 195]

В 23.07.2020 в 15:22, eu_tomat сказал:

Я плохо понял о чём здесь идёт речь. Чем плоха реализация os.sleep, если не вешать на него тяжёлые обработчики событий?

Это было из предположения, что реактор работает независимо от тиков сервера.

Если он работает как обычный тайл, то все упирается в 

В 23.07.2020 в 15:22, eu_tomat сказал:

обращение к периферии вместо одного тика иногда требует двух тиков, а в моменты сильного снижения TPS задержка доходила и до 5 тиков

 

А что, если юзать несколько компов каждый со своим телепозером, чтобы каждый работал только с частью слотов(или даже с одним)?

Изменено 24 июля, 2020 пользователем hohserg

[eu_tomat 2 148]

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

А что, если юзать несколько компов каждый со своим телепозером, чтобы каждый работал только с частью слотов(или даже с одним)?

Зависит о цели.

 

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

 

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

[serafim 271]

Добавил замену отражателей

Исправил баг с заполненным сундуком и вылет в ошибку при перегреве

 

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

Тупо перебором делать лагульку не хочу, а вести расчёт из за рассинхрона при лагах ни к чему хорошему не приведёт

Изменено 25 июля, 2020 пользователем serafim

[yura0138 Автор темы 3]

Приветствую всех, Спасибо всем кто дальше пытается допилить или улучшить эту программу!

Где-то тут был вопрос о том, где достать много лазурита, ибо жрет схема от whiskas ~13 блоков ~ каждые полторы минуты, вижу 2 варианта,1-й - это просто робот с геоанализатором целенаправленно копающий лазурит, накопать побольше и стартануть реактор, 2-й - это с модом Advanced Solar Panels который добавляет молекулярный преобразователь, он из синей шерсти делает блок лазурита, вроде за 500к еу, в итоге 6.5 млн еу на производство лазурита для всех кондеров, но тут 2 проблемы, автоматизация стрижки овец - это или мод типа механизм, или программа на робота стригущего овец, а шерсть по трубам идет к преобразователю, и вторая проблема которая может быть и не проблема, надо тестить, но суть проблемы такая, как подать весь выход реактора на преобразователь, если стекловолокно имеет пропускную способность вроде всего 2048 еу, лазурит просто не будет успевать создаться, возможно получится просто напрямую запитать молекулярку, но я не знаю, имеет ли ограничение на кол-во отдачи еу реактор.... пойду тестить

Изменено 28 июля, 2020 пользователем yura0138

[Doob 2 748]

@yura0138 реактор может выдать максимум 8192 EU/t.

[yura0138 Автор темы 3]

@Doob надо считать, сможет ли реактор поддерживать сам себя при наличии шерсти.... хм, он же 8192 еу отдает со всей своей площади? или каждая сторона реакторной камеры отдает столько еу? если каждая, то можно несколько молекулярок поставить, при наличии горы ресов .... сложно все....

[yura0138 Автор темы 3]

мда, пришла проблема откуда не ждали, @serafim , опечатка в твоей проге, увидел как попытался использовать, в блоке поиска реактора и сундука в команде скана реактора не проставлена r в названии блока, в итоге ошибка, + в схему от Asior надо адаптер добавить, без него прога не работает

 

 

[yura0138 Автор темы 3]

хм, сейчас проверил, и с исправленной опечаткой не работает....

Хотя похоже это я чайник и ничего не понял ибо в проверке сундука в названии то же первой буквы не хватает....

Версия майна - тлаунчеровска 1.12.2 ОС - 1.7.5

Самое интересно, то что реактор запущен прога видит, но самого реактора не видит....

Изменено 28 июля, 2020 пользователем yura0138