Допиливание программы для схемы реакторов

[serafim 271]

Можете потестить установщик схемы в реактор IC2 https://pastebin.com/xWhYcrgM

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

 

схемы для реактора которые здесь использовались

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

 

 

 

 

Есть ещё планы по оптимизации и добавления функционала

например: показывать недостающие компоненты на русском, принимать атрибуты

 

Прога  как то не адекватно реагирует на событие inventory_changed

хотя должна реагировать только если в инвентарь что-то добавили а не забрали

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

local function wait()
  while true do
    local e, slot = event.pull("inventory_changed")     
    if slot then 
      print("ожидаю компоненты")
      os.sleep(5)
      freeslot()
      scan()
      break
    end
  end
end

 

 

Изменено 4 декабря, 2020 пользователем serafim

[eu_tomat 2 148]

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

Прога  как то не адекватно реагирует на событие inventory_changed

хотя должна реагировать только если в инвентарь что-то добавили а не забрали

Сигнал inventory_changed генерируется в случаях изменения предмета в инвентаре: в пустом слоте появился предмет; предмет исчез из слота; предмет в слоте был заменён другим. Оно не возникает лишь при изменении количества предмета в слоте.

 

Логично, что программа должна уметь обрабатывать все три ситуации. Даже если мы в какой-то таблице хранили количество предметов в слотах инвентаря робота, то без дополнительных вычислений однозначно идентифицировать мы сможем только ситуацию появления предмета в слоте. А отличить исчезновение предмета в слоте от его замены можно, например, анализируя значение robot.count() при получении сигнала.

 

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

 

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

[serafim 271]

2 минуты назад, eu_tomat сказал:

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

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

 

обнова

теперь прога принимает атрибуты, вводить так:  название проги пробел схема   test 1320

при недостающем компоненте теперь пишет его название на русском

[eu_tomat 2 148]

1 минуту назад, serafim сказал:

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

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

[serafim 271]

обновил

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

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

время кстати не изменилось 33-34 сек при 54 компонентах в инвентаре робота

Изменено 4 декабря, 2020 пользователем serafim

[eu_tomat 2 148]

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

Можете потестить установщик схемы в реактор IC2 https://pastebin.com/xWhYcrgM

До тестирования я не добрался, но почитал код. Есть замечания и вопросы:

• Функцию сканирования инвентаря можно немного ускорить, отказавшись от выполнения getStackInInternalSlot(slot) для заведомо пустых ячеек. Наличие предмета в слоте помогает определить функция robot.count(slot), и работает она очень быстро. И только уже зная, что слот не пуст, появляется смысл запрашивать getStackInInternalSlot(slot). В остальных случаях получаем экономию в один тик на каждый пустой слот.
• robot.inventorySize() вызывается больше одного раза, каждый раз тратя на это один тик времени. Такое решение полезно для случая съёмных апргейдов инвентаря. Но удобнее всё же сделать несъемные. Тем более, автор заказа не ограничен в материалах. Ему под силу сразу скрафтить нужного робота.
• При поступлении сигнала inventory_changed программа заново сканирует инвентарь, тратя на это 3.2 сек при 64 слотах в инвентаре робота, хотя достаточно обработать лишь те слоты, для которых поступил сигнал изменения.
• При обнаружении отсутствующего компонента в инвентаре робота необязательно тратить время только лишь на ожидание его появления. Достаточно сообщить игроку список отсутствующих компонентов и продолжать заполнение, возвращаясь к пропущенным слотам позже. У на же есть контроллер инвентаря, поэтому вместо robot.drop() можно использовать component.inventory_controller.dropIntoSlot(side,slot,count), помещая предмет строго в нужный слот. Или на сервере какие-то особенности приватов не позволяют так обращаться с внешними инвентарями?
• Если использовать dropIntoSlot допустимо, то заранее сканировать инвентарь робота имеет смысл только для того, чтобы сообщить об отсутствующих игроку компонентах. А если сообщение игроку поступает ровно в момент попытки поместить компонент в реактор, то и сканировать слот инвентаря можно непосредственно перед этим.
• Обнаружение изменения инвентаря сейчас реализовано проверкой на 0 значения robot.count(slot). Это работает только для случая извлечения предмета из слота. Но игрок может произвести замену предмета. В этом случае программа рискует поместить в реактор не тот компонент.
• Зачем функция set сделана рекурсивной? В чём удобство именно рекурсивной функции?

[serafim 271]

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

отказавшись от выполнения getStackInInternalSlot(slot) для заведомо пустых ячеек. Наличие предмета в слоте помогает определить функция robot.count(slot), и работает она очень быстро

изначально поиск был по имени через string.find() в итоге от него отказался, так пользователю проще будет понят что за компонент в шаблоне от него хотят. Насчёт что через robot.count(slot) быстрее, как то не замечал, ок учту

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

robot.inventorySize() вызывается больше одного раза

ок, вынесу в начало

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

При поступлении сигнала inventory_changed программа заново сканирует инвентарь

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

перед повторный сканированием прога ждёт 5 секунд, за этот промежуток могут добавится ещё компоненты и в другие слоты, поэтому повторно делаем скан всего инвентаря

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

При обнаружении отсутствующего компонента в инвентаре робота необязательно тратить время только лишь на ожидание его появления поэтому вместо robot.drop() можно использовать component.inventory_controller.dropIntoSlot(side,slot,count), помещая предмет строго в нужный слот.

да так ещё лучше, может сделаю

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

Если использовать dropIntoSlot допустимо, то заранее сканировать инвентарь робота имеет смысл только для того, чтобы сообщить об отсутствующих игроку компонентах

такой метод в корне меняет логику проги, и да так удобней

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

Обнаружение изменения инвентаря сейчас реализовано проверкой на 0 значения robot.count(slot). Это работает только для случая извлечения предмета из слота. Но игрок может произвести замену предмета. В этом случае программа рискует поместить в реактор не тот компонент.

в таком случае придётся повторно запрашивать имя компонента тратя кучу времени

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

Зачем функция set сделана рекурсивной? В чём удобство именно рекурсивной функции?

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

также нужно передавать ряд параметров функции set (имя компонента, наличие компонента в инвентаре, также если инвентарь пуст то цикл в функции set не выполняется приходится ожидать пока компоненты добавят)

возможно можно избавится от рекурсии, но пока реализовал так как мне казалось проще 

Изменено 5 декабря, 2020 пользователем serafim

[serafim 271]

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

[serafim 271]

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

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

изваял обработчик событий

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

local event = require("event")

while true do
  local e = {event.pull("inventory_changed")}
  for i = 1, #e do
    if e[i] then
      print(i..": "..e[i])
    else
      print(i..": nil")
    end
  end
  print(" ")
end

 

событие inventory_changed возвращает только 2 параметра

1: inventory_changed -- событие изменения инвентаря
2: 7                 -- номер слота

обновил прогу на

  ...
local e, slot = event.pull("inventory_changed")     
if slot and r.count(slot) > 0 then
  ...

теперь событие inventory_changed отрабатывает адекватно

Изменено 5 декабря, 2020 пользователем serafim

[eu_tomat 2 148]

48 минут назад, serafim сказал:

Насчёт что через robot.count(slot) быстрее, как то не замечал, ок учту

Я рассказывал на днях о методике измерений. За время выполнения getStackInInternalSlot (один тик) можно 1000 раз выполнить robot.count. При одиночном выполнении это, конечно, заметить трудно. Но при сканировании 64 пустых слотов робота будет заметно даже на глаз.

 

54 минуты назад, serafim сказал:

да так ещё лучше, может сделаю

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

 

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

в таком случае придётся повторно запрашивать имя компонента тратя кучу времени

Тут вариантов не особо много: либо тратить время на дополнительные запросы, либо аккуратно обрабатывать сигнал изменения слота, либо в инструкции пользователя прописывать запрет на некоторые манипуляции в процессе работы.

 

[serafim 271]

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

Или на сервере какие-то особенности приватов не позволяют так обращаться с внешними инвентарями?

мене тоже смущает этот вопрос, очень часто робот в привате имеет ограничения и robot.drop() предпочтительней

7 минут назад, eu_tomat сказал:

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

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

[eu_tomat 2 148]

14 минуты назад, serafim сказал:

мене тоже смущает этот вопрос, очень часто робот в привате имеет ограничения и robot.drop() предпочтительней

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

[serafim 271]

10 минут назад, eu_tomat сказал:

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

можно, тем более что список известен

[serafim 271]

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

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

 

Изменено 5 декабря, 2020 пользователем serafim

[demongts1998 Автор темы 6]

В 04.12.2020 в 18:44, hohserg сказал:

Я не знаю, как интересно и как не интересно проводить время @demongts1998, но разве это не часть скучного гринда? Вроде бы это должен делать робот: кататься до стартового сундука и пополнять свой инвентарь. Или дрон, который бы заменил в этой скучной работе игрока

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

[hohserg 195]

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

Почему я об этом задумываюсь:

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

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

Это две истины, противоборствующие за выбор "автоматизировать или нет?"

Действительно хорошим решением мне кажется выход за рамки этих двух вариантов, но это вроде как не в компетенции игроков. Ведь нельзя заменить кучу реакторов существенно меньшим количеством? Для этого нужно, чтобы один реактор мог быть лучше чем сотня(чтобы вместо 324 реакторов строить всего 3). Существует ли схема для обычного реактора, которая бы позволяла тратить топливо и генерировать энергию в 100 раз быстрее?

Изменено 7 декабря, 2020 пользователем hohserg

[eu_tomat 2 148]

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

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

Судя по тому, что я узнал в темах этого заказа и заказа про переработку руды, администраторы обсуждаемого сервера склоняют игроков именно к гринду. Что мы имеем:

• Ценность материалов на строительство реакторов и их компонентов настолько мала, а ценность энергии настолько велика, что игроки готовы строить по 324 реактора и обслуживать их даже без особой автоматизации.
• Мы слышим заявление от информированного человека о том, что причиной низкого TPS на сервере  является большое количество реакторов. Но вместо снижения ценности энергии или дополнительно ограничения количества именно реакторов, администрация ввела крафт роботов за донат-валюту.

Другое дело, что считают интересным сами игроки этого сервера. Поэтому вопросы к @demongts1998:

• Ты получаешь удовольствие от расстановки 324 реакторов вручную?
• Интересно ли тебе использовать робота, который сам расставит реакторы, или всё-таки ручная расстановка более предпочтительна?
• Целесообразна ли на этом сервере полная автоматизация, в которой роботы сами строят реакторы и обслуживают их? Или такая программа будет работать до ближайшего вайпа, и весь процесс снова скатится в тупой гринд, а к тому же ещё и роботы будут снова понерфлены? Какой сценарий ты считаешь наиболее вероятным?

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

Существует ли схема для обычного реактора, которая бы позволяла тратить топливо и генерировать энергию в 100 раз быстрее?

При низкой ценности материалов выгодны схемы на конденсаторах. Только они обеспечивают максимально плотное заполнение реактора топливом. Но именно эти схемы требуют активного перемещения реакторных компонентов между инвентарями и постоянного ремонта конденсаторов, что, конечно же, тоже вносит свой вклад в снижение TPS. Такие схемы обсуждались в заказе Программа "Очень много электричества". Это, конечно, не в 100 раз выше, а раз в 10. Но дальше могут возникать и другие препятствия из-за ограничения мода и аддонов: при определённых их сочетаниях производство энергии из MOX-топлива одним реактором может превышать возможности самого мощного потребителя, MFSU и самые лучшие кабели могут взрываться, или реактор может просто не выдать энергию свыше 16384 eu/t.

[demongts1998 Автор темы 6]

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

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

автоматизация есть, удобная и простая, долго обьяснять

 

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

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

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

 

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

Ты получаешь удовольствие от расстановки 324 реакторов вручную?

are you seriously?

 

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

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

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

 

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

При низкой ценности материалов выгодны схемы на конденсаторах.

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

 

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

Существует ли схема для обычного реактора, которая бы позволяла тратить топливо и генерировать энергию в 100 раз быстрее?

если быстро сжигать топливо, но вырабатывать больше - нет, стабильных схем нет  

[serafim 271]

обнова https://pastebin.com/xWhYcrgM

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

добавил динамический список недостающих компонентов в инвентаре робота

перевёл прогу на gpu так как в консоли творилась каша

выход из проги кнопкой ctrl

 

[eu_tomat 2 148]

В 07.12.2020 в 19:57, serafim сказал:

добавил динамический список недостающих компонентов в инвентаре робота

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

 

@demongts1998 протестируй эту версию. Она не идеальна, но вполне годная. Можно было бы немного снизить нагрузку на сервер, но на скорости заполнения реактора это существенным образом не отразится. Можно было бы сделать алгоритм более устойчивым к кривым рукам пользователей, но это потребует существенных усилий от программиста, проще написать инструкцию. Тем более, в условиях заказа не сказано, до какого состояния следует допиливать. Я считаю, допилено хорошо.