eu_tomat

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

Поддержка на этом форуме лучше чем у платных поддержек разного софта))

Большое спасибо, это правда хороший ответ, который помимо рыбы даёт ещё и удочку.

Спасибо за высокую оценку. Я тоже рад нашему общению.

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

Я вижу три направления оптимизации:

Оптимизация процесса взаимодействия с системой.

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

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

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

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

Оптимизация взаимодействия с периферией

Количество запросов к периферии в этой программе не велико, но сами запросы обрабатываются крайне медленно. Поэтом они вносят значительный вклад в общее время выполнения программы. Главное правило работы с периферией — ограничить количество запросов к ней.

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

Оптимизация обработки данных

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

В этой программе я вижу циклический перебор всех предметов во всех инвентарях и  полный перебор общий таблицы для каждого из предметов. Очевидно, такой алгоритм обработки неэффективен:

local this = false
for g,allItm in pairs(allItems) do
  if  ((this==false) and (allItm.name == thisItm.name) and (allItm.label == thisItm.label)) then 
    this = true
    allItm.count = allItm.count+thisItm.size
  end
end
if this == false then
  table.insert(allItems, {name = thisItm.name, count = thisItm.size, label = thisItm.label})
end

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

for g,allItm in pairs(allItems) do
  if  allItm.name==thisItm.name and allItm.label==thisItm.label then 
    this = true
    allItm.count = allItm.count+thisItm.size
    break
  end
end

Но и этот цикл также работает слишком медленно. Полностью избавиться от цикла помогут ассоциативные свойства таблиц Lua. Для этого потребуется изменить структуру таблиц и обращаться к их элементам не по индексам, а по строковым идентификаторам. Учитывая, что в программе поиск осуществляется по строкам thisItm.name и thisItm.label, ключом к элементам таблиц может быть объединённая строка thisItm.name..thisItm.label. В этом случае код упростится:

local key = thisItm.name .. thisItm.label
if allItems[key] then
  allItems[key].count = allItems[key].count + thisItm.size
else
  allItems[key] = {name = thisItm.name, count = thisItm.size, label = thisItm.label}
end

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

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

Да это же MineOS!

Как интересно. Я уже не раз видел на форуме мутные вопросы о трудностях скачивания или установки чего-либо, когда в конечном итоге выяснялось, что вопрос был про MineOS. Где пользователи вообще берут эти кривые ссылки?

@CsGONoN Файл удалён, и по этому адресу скачать его невозможно. Но, возможно, это не единственное место, откуда его можно скачать.

А что за системные файлы? Какой результат ожидается в конечном итоге? Откуда вообще взята ссылка на этот файл?

Хороший подход. Сам заказал и сам же выполнил.

26 минут назад, num_pi сказал:

А попробовав разные варианты, с топикастером, пришли к выводу об не рентабельности любых схем, кроме как на лазурите, увы...

Что значит "нерентабельности"? Производство энергии ядерными реакторами полностью теряет смысл? Тогда какой источник энергии рентабелен?

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

Ну на сколько мне известно, асинхронности в компах нету

...

Ага, и всё это в одном потоке выполняется

Скорее, наоборот, синхронности нет. В лучшем случае есть что-то близкое к ней.

@rootmaster Правильно ли я понял, что эта система автокрафта состоит из единственного робота даже без вспомогательных сундуков, а все необходимые для крафта материалы должны находиться во внутреннем инвентаре робота?

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

openperipheral вот где ответ, ну если этот мод конечно есть в сборке, с его помощью можно у не стандартных предметов узнать nbt_hash и уже по нему ориентироваться, но можно ли его api использовать для робота в автокрафте, это вопрос, это да, можно проверить

Не совсем так. В примере @Taoshi для "minecraft:planks" мы получим одинаково пустое поле nbt_hash для разных видов досок. А отличатся они будут полем damage, которое можно получить и без OpenPeripheral. Кстати, информацию о тегах можно получить и иными путями:

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

id базы данных автокрафта ~= id игрового клиента. В этом вся суть.

Термин "id предмета" в Майнкрафте имеет устойчивый смысл. Поэтому при его использовании в других смыслах предлагаю сразу делать уточнение, а ещё лучше изначально использовать другой термин.

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

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

Это не редкость. Большинство предметов OpenComputers не описываются одним лишь id или именем предмета.

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

Поэтому желательно использовать не только внутреннюю нумерацию предметов и блоков, но и документировать внешнюю.

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

38 минут назад, Asior сказал:

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

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

Но идея не лишена смысла. Замена строк на числа даже без привязки к id позволит уменьшить размер ядра БД и снизить вычислительную нагрузку при анализе крафтов с длинными и разветвлёнными цепочками.

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

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

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

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

Хранение такое конечно же интересное, но как по мне, лучше рецепты хранить в стандартном формате типа...

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

26 минут назад, Taoshi сказал:

IMHO компактнее хранить данные о крафтах в виде id зарегистрированных в базе данных автокрафта предметов. Иначе памяти не напасешься хранить вот это всё

Что-то не помню: а разве контроллеры инвентаря по умолчанию имеют доступ к id предметов?

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

автокрафт на роботе который круче ME машины

Недостаточно просто сказать "круче". Таким заявлениям почти никто уже не верит. Нужны аргументы. Чем именно круче? В чём основные достоинства именно этого автокрафта? Какие имеются недостатки?

20 минут назад, pavel1992x сказал:

много яда и сарказма и это наводит меня на мысль, что данный респондент пытается заниматься жёстким маркетингом, а так-же попытками манипулирования народом на форуме. Возможно, что оси перестали публиковать, как раз из за того, что   ESC разгоняет конкурентов.

Конкурент!

Не прекращай борьбу!

Публикуй свои оси

Назло респонденту!

Чтение документации привело к функциям getTileNBT и setTileNBT, работающие не через строки, а таблицы.

Правда, возникла новая сложность: таблица, полученная через getTileNBT, не воспринималась корректно функцией setTileNBT.

@ProgramCrafter сообщил, что это известная проблема и проявляется на архитектуре Lua 5.3: Lua 5.3 Debug Card NBT-Editing Error #2448

Проблема решилась переводом программы на Lua 5.2.

Как ответил в дискорде @HeroBrine1st, в 1.12 достаточно взять имя тега в двойные кавычки. Подтверждаю.

В OpenComputers-MC1.12.2-1.7.5.192.jar я успешно создал в инвентаре EEPROM с нужной меткой с помощью такого кода:

insertItem( "OpenComputers:storage", 1, 0,[[{"oc:data":{"oc:label":"myBIOS"}}]], x,y,z,0 )

В OpenComputers-MC1.7.10-1.7.5.1290-universal.jar то же решение не позволяет создать тег с нужным именем.

Похоже на ошибку в моде. У кого-нибудь есть идеи, как обойти эту проблему?

С помощью отладочной платы я могу поместить в сундук с некоторыми координатами, например, переименованную палку:

debug.getWorld().insertItem( "minecraft:stick", 1, 0,'{display:{Name:"xyz"}}', x,y,z, 0 ))

В данном случае названия тегов не создают проблем.

Но названия тегов OpenComputers содержат двоеточие. Например, oc:data, oc:label. При этом двоеточие используется как разделитель имён и значений тегов. Поэтому при создании тегов OpenComputers у меня возникли затруднения.

Все мои идеи по экранированию двоеточия не привели к нужному результату. Примеры:

insertItem( "OpenComputers:eeprom", 1, 0,[[{oc:data:1}]], x,y,z, 0 )
-- тег: "oc" = "data:1"

insertItem( "OpenComputers:eeprom", 1, 0,[[{"oc:data":1}]], x,y,z, 0 )
-- ошибка: Unbalanced quotation: data":1

insertItem( "OpenComputers:eeprom", 1, 0,[[{'oc:data':1}]], x,y,z, 0 )
-- тег: "'oc" = "data':1"

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

Вопрос: В какой форме следует указывать имена тегов, содержащих двоеточие?

17 часов назад, Leo857 сказал:

@eu_tomat c этим кодом вообще не выдает ошибку но придется написать например 1 что бы запустить саму программу пишет так /home ждет команду(например я указал этот код в edit 1,ждет что бы я указал 1 что бы запустилась)как быть?

• if meItem and meItem[1] and not meItem[1].isCraftable then

Не понимаю, о чём здесь идёт речь. Что придётся написать? Чтобы Какую программу запустить? Почему 1? Кто пишет, что /home ждёт команду? Что значит, указал код в edit 1?

17 часов назад, Leo857 сказал:

@eu_tomat а то что указали со строкой 191 вообще не понятно придется удалит эту строку или как быть что бы вообще не было таких проблем с meltem

Я не работал конкретно с МЭ-сетью и не знаю всех нюансов. Поэтому предлагаю варианты, что с этим вообще можно сделать. Придётся ли удалить эту строку? Если она не нужна, то можно удалить. Если она нужна, то можно добавить условие на выполнение этой строки. А может, не только этой. Это возможные варианты. Или ты просишь выбрать лучший вариант?

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

А какова логика? Попробуем разобраться. Например, каков смысл строк 186 и 191, в которых проявилась проблема? Что они делают?

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

@eu_tomat после этого выдает ошибку на 191 строке

А в строке 191 у нас такой код: displayTable[itemIndex].currentValue = meItem[1].size

Значит, вероятнее всего, проблема, в meItem или meItem[1], и эта строка в случае несуществующей таблицы не имеет смысла.

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

@Leo857 

Скриншот сообщает о том, что в строке 186 произошла попытка обращения к полю несуществующей таблицы.
Код этой строки:
 

    if not meItem[1].isCraftable then

Я не имею опыта сопряжения компьютера с МЭ-сетью. Какая из таблиц может быть проблемной, я не знаю. Но вариантов не так много. Попробуй такие:

• if meItem and not meItem[1].isCraftable then
• if meItem[1] and not meItem[1].isCraftable then
• if meItem and meItem[1] and not meItem[1].isCraftable then

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

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

на вещи написано B материи, а нужно чтобы было  mB, что это значит?

B = 1000 mB.

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

Как вариант, можно в раздел "Графика" перенести.

Готово.

При наличии мода OpenPeripheral можно с помощью адаптера подключить жёрдочки IC2 к компьютеру. Это позволит получить доступ к множеству параметров грядки и выращиваемой культуры.

45 минут назад, men_epto сказал:

https://pastebin.com/UQyGV6vS

Пишет "Locked Paste".

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

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

Да, можно. Это будет удобнее отдельной кнопки. Зато вспомогательный компьютер обеспечивает компактность проводки при работе с несколькими мониторами. Он позволяет подключать мониторы единственным кабелем, без проводки красного сигнала.