eu_tomat

Измерить можно. Но эти тесты всегда сравнительные и выглядят примерно так: такой-то механизм в таком-то режиме создаёт нагрузку, эквивалентную N других механизмов в каком-то режиме. И с оговорками: на таком-то сервере и на такой-то сборке. Я пока не смог прийти к какому-то единому стандарту замеров. По грубым оценкам быстро тикающий таймер нагружает сервер на десятые доли процента, а приставленный к нему пустой выбрасыватель — на сотые.

@ProgramCrafter В использовании таймера из RedLogic меня в первую очередь смущает его непрерывная работа независимо от состояния программы. Мало того, он при этом пытается инициировать работу выбрасывателя, что ещё сильнее увеличивает нагрузку на сервер. Компьютер же даёт команду красной плате лишь тогда, когда это необходимо, а в остальное время схема пассивна. Также схема на красной плате не зависит от наличия мода RedLogic, да и установка может получиться чуть компактнее. Но твои аргументы я понял. В каких-то ситуациях они могут оказаться решающими. У меня возник ещё один вопрос. А сколько пчёл ты выдаёшь за один раз?

А в чём преимущество такого решения?

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

Я вижу три направления оптимизации: Оптимизация процесса взаимодействия с системой. Я не уверен, что это возможно в рамках имеющегося техзадания, но надо попытаться это сделать, т.к. именно оптимизация процесса даёт максимальный эффект. Оптимизировать работу с полный хаосом невозможно. Поэтому надо постараться максимально упорядочить работу своей системы, добавив какие-то правила взаимодействия с ней. Например, можно разрешить доступ игроков к единственному сундуку, а с остальными сундуками взаимодействовать исключительно через транспозеры. Такое решение снизит масштаб неопределённости. В общем, нужно упорядочить хаос. Оптимизация взаимодействия с периферией Количество запросов к периферии в этой программе не велико, но сами запросы обрабатываются крайне медленно. Поэтом они вносят значительный вклад в общее время выполнения программы. Главное правило работы с периферией — ограничить количество запросов к ней. В этой программе я вижу вызов 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 Пожалуй, я перечислил все основные способы оптимизации этой программы, дающие максимальный эффект и не снижающие читаемость кода.

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

@CsGONoN Файл удалён, и по этому адресу скачать его невозможно. Но, возможно, это не единственное место, откуда его можно скачать. А что за системные файлы? Какой результат ожидается в конечном итоге? Откуда вообще взята ссылка на этот файл?

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

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

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

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

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

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

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

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

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

Конкурент! Не прекращай борьбу! Публикуй свои оси Назло респонденту!

Чтение документации привело к функциям 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" Я пробовал и другие варианты, но общий смысл был одинаковым: первое двоеточие всегда интерпретировалось как разделитель имени и значения. Вопрос: В какой форме следует указывать имена тегов, содержащих двоеточие?

Не понимаю, о чём здесь идёт речь. Что придётся написать? Чтобы Какую программу запустить? Почему 1? Кто пишет, что /home ждёт команду? Что значит, указал код в edit 1? Я не работал конкретно с МЭ-сетью и не знаю всех нюансов. Поэтому предлагаю варианты, что с этим вообще можно сделать. Придётся ли удалить эту строку? Если она не нужна, то можно удалить. Если она нужна, то можно добавить условие на выполнение этой строки. А может, не только этой. Это возможные варианты. Или ты просишь выбрать лучший вариант? Можно убрать ошибку, которую выдаёт Lua, но это не значит, что программа после этого будет работать правильно. Выбор осуществляет автор программы, исходя из предпочитаемой им логики действий. А какова логика? Попробуем разобраться. Например, каков смысл строк 186 и 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 Вероятно, это поможет. Но, возможно, эта ошибка вылезет где-то ещё, и тогда потребуется основательно переписать логику работы программы.

B = 1000 mB.

Готово.