eu_tomat

А это, пожалуй, самый важный вопрос в теме времени. Хорошо было бы взять, да и получить такой список. У меня его нет. Есть какие-то смутные критерии для классификации разных видов точности, но это вообще не список. Попробуем составить его вместе, если получится. Базовый уровень: время исполнения вызова. При стандартном конфиге мода вызов robot.place() всегда требовал 8 тактов времени, а при наличии лагов и больше. Это то, что мы можем легко протестировать без особого напряжения мозга. 4 такта на установку? Нет, я ошибся. Требуется 8 тактов (0.4 сек). Измерено тем же способом, который в примере по ссылке. Скоростной уровень: время гарантированного исполнения запрошенного действия. Робот или транспозер сразу же выполняет запрошенное действие, и, выдержав паузу, возвращает управление в программу. Это значит, что уже в следующем такте результат этого действия можно будет однозначно отследить. Я думаю, что ранее я сильно завысил тайминги. На каждое действие можно смело выделять по одному такту времени: установка реактора, установка камер, заполнение реактора. На этом уровне я ещё могу говорить о какой-то понятной точности, выражая её в игровых тактах. И это время можно косвенно измерить. Бешеный уровень: время фактического исполнения запрошенного действия. На предыдущем уровне требовалось выждать один такт, чтобы однозначно отследить результат выполненного действия. Но это, строго говоря, не обязательно. Поставим себе простую задачу: пересобрать реактор с одной дополнительной камерой за один такт времени. Это возможно при условии, если роботы строго в обозначенном порядке выполнят действия: Первый робот снимает блок реактора. Дополнительная камера снимается автоматически. Робот уходит в ожидание на 2 такта. Второй робот устанавливает блок реактора и уходит в ожидание на 8 тактов. Успех этого робота полностью зависит от успеха первого. Третий робот устанавливает дополнительную камеру и также уходит в ожидание 8 тактов. Аналогично, его успех полностью зависит от действий предыдущих двух исполнителей. Возникают вопросы: Какой из роботов будет выполнять действие первым? Как управлять порядком исполнения команд внутри одного игрового такта? Не ответив на эти вопросы, мы не сможем быть уверены в успешности выполнения всей цепочки действий. Пока я не знаю, как это гарантировать. Но я, например, могу ранжировать роботов по скорости их реакции, чтобы каждого назначить на соответствующий участок последовательности. Скорее всего, в такой конфигурации они смогут успешно работать до следующей перезагрузки чанка, потом потребуется переназначить их роли. Это максимум, которого мне удавалось достичь. Но он пока неустойчив даже в лабораторных условиях. Синхронизация таких цепочек не гарантирована при загрузке сохранённого мира. Итог: Более-менее о точности можно говорить, если не пытаться выполнять кучу действий за один такт. Внутри одного такта также протекают какие-то процессы. Ориентируясь по конечному результату, иногда можно уверенно говорить, что то или иное действие было выполнено раньше другого. Возможно, существует способ однозначно управлять последовательностью действий компьютерной периферии в рамках одного такта, и было бы интересно этот способ найти. За один такт и в определённой последовательности? Получается, что, при некоторых условиях можем. Бешеный транспозер уже выполняет сотню действий за такт, но для его работы не требуется соблюдать последовательность. Какие у тебя есть идеи для точного управления последовательностью действий?

А в какой именно точности ты хочешь измерить тайминги?

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

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

Да, трудна жизнь простого игрока. Но нам это не повод для печали. Разработали же мы когда-то предельную схему на конденсаторах. Разработаем и схему на теплоотводах. Или будем топить реактор оловом. Олово же не реже лазурита встречается?

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

Поддерживаю. Также желательно разместить код на каком-нибудь соответствующем сервисе вроде github/gitlab. А то, с одной стороны, есть просьба помочь А с другой, отсылка в дальний путь: Для чтения документации требуется пройти по ссылке на гуглодиск, скачать архив, распаковать его, найти там что-то где-то. Слишком сложно для 2022 года. Всё это можно было бы решить переходом по единственной ссылке, ведущей прямиком к файлу документации в репозитории. И если документация что-то прояснит и как-то заинтересует, можно будет почитать коммиты и попытаться оценить проделанную работу. И если будет очень интересно, то можно будет даже что-то скачать и запустить. Но для этого потребуется максимальная мотивация. Пока это максимум, что я могу посоветовать.

А какие задачи решает этот патч? Что интересного он привносит в сравнении с OpenOS?

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

До какого уровня удалось докачать робота? Есть заметное ускорение?

А зачем объяснять это десятым способом, если я каждый раз говорю, что конкретно с этим утверждением я согласен? Я предлагаю сосредоточиться на сути противоречия. Именно так. Магия математики, упрощающая понимание взаимосвязей в определённых случаях. Вопрос лишь в том, уместно ли это упрощение в каждом конкретном случае. Мы выбираем расположение компонентов, не только оценивая теоретическую эффективность схемы, но также исходя из текущей ценности охлаждающих или топливных компонентов. Если производственные мощности не позволяют произвести достаточного количества охлаждающих компонентов, то некоторые схемы становится невозможно использовать в непрерывном режиме. Независимо от того, насколько они выгодны в теории. Что ты предлагаешь делать в случае нехватки охлаждающих стержней? Переводить реактор в циклический режим? Я же считаю более выгодным переход на другую схему. И в этом случае высказанная ранее идея выглядит вполне уместно: Наше с тобой недопонимание началось именно с этого момента. Давай разберём, что здесь происходит. Переведя три реактора на новую схему, мы освобождаем охлаждающие стержни для четвёртого реактора, который из-за нехватки охлаждения был вынужден простаивать. И благодаря этому возникает не падение итоговой мощности группы реакторов а её повышение: на 100% - 3*3.6% = 89%. Но чем дешевле нам обходится производство охлаждающих стержней, и чем выше скорость их производства, тем выгоднее нам уплотнять размещение ТВЭЛ'ов. Но это тоже не абсолютное правило. Если нет ограничений на количество реакторов, то надо уже считать выгоду, что дешевле: новый реактор или же новое производство охлаждающих стержней.

Время в Майнкрафте подобно песку. На больших масштабах возникает иллюзия равномерности его течения, но на микроуровне можно заметить уникальные песчинки и их практически не повторяющиеся комбинации. Тут нет ничего случайного. Есть практически непредсказуемое, и потому подходящее на роль источника энтропии для инициализации зерна ГПСЧ. В среде OpenComputers очень трудно прогнозировать затраты времени на выполнение любой операции. Даже на больших масштабах имеется заметный разброс. А время выполнения коротких операций может от раза к разу отличаться на порядки. Чем не источник энтропии? Какой именно момент времени измеряет функция os.clock, я не знаю, и в данном случае это не важно. По сути, я предлагаю измерить время выполнения самой функции os.clock в текущий конкретный момент времени. Можно было бы измерять время выполнения любого другого кода, но os.clock всё равно бы потребовалось вызвать два раза. Так зачем усложнять?

Да, но не всеми сразу. Выложу как-нибудь гайдик. Вообще, я испытываю двоякие чувства относительно публикации придуманных трюков. С одной стороны, хочется как можно быстрее продемонстрировать их. А с другой, я не хочу лишить других участников удовольствия от решения задачи. Я чаще даю комментарии по улучшению, нежели сам выкладываю решения. Вот и живой пример: Отлично! Я и и надеялся как раз на то, что это обсуждение подтолкнёт участников обсуждения к самостоятельному поиску новых схем. Хорошее решение. Если принять во внимание точное значение теплового баланса, то окажется, что при шахматном заполнении некоторые ТВЭЛ'ы в схеме лишние. Поиск же самых лишних с точки зрения минимизации микроконтроля тоже является увлекательной задачей. Да, Горячий MOX полезнее урана. Какой смысл это повторять? Да, полезнее в 4.9996 раз. Но при указанных выше вычислениях этот коэффициент сокращается. Не MOX относительно урана, а двух разных схем на MOX. Хорошо, я продолжу свой пример: Два счетверённых ТВЭЛ'а на MOX в смежных клетках генерируют 160*4.4 eu/t при перегреве 320 hu/s. Два счетверённых ТВЭЛ'а на MOX в несвязанных клетках генерируют 120*4.4 eu/t при перегреве 192 hu/s. Вторая схема производит энергии на 25% меньше, при этом уменьшая нагрузку на охлаждающую систему на 40%. Можно видеть, что в результате получены те же самые проценты.

Я всё-таки собрал метастабильную схему для MOX на 1800 eu/t. Реактор требует внимания лишь на этапе замены топлива. В этой схеме пустуют 3 слота. Также использованы два обычных теплоотвода, не самых производительных. Этот резерв можно задействовать с помощью микроконтроля, доведя среднюю мощность реактора до 2074 eu/t.

Да, продолжаем. Тут ты говоришь про другие соотношения, а не те, о которых говорил я. Ясное дело, выгоднее расходовать холод на горячий MOX, нежели уран. Объясню на понятном тебе примере. Два счетверённых ТВЭЛ'а на уране в смежных клетках генерируют 160 eu/t при перегреве 320 hu/s. Два счетверённых ТВЭЛ'а на уране в несвязанных клетках генерируют 120 eu/t при перегреве 192 hu/s. Вторая схема производит энергии на 25% меньше, при этом уменьшая нагрузку на охлаждающую систему на 40%. То есть она оказывается более выгодной с точки зрения использования охлаждающих элементов, хотя и снижает мощность этого реактора. Температура реактора на эти расчёты никакого влияния не окажет. Предположим, есть повышающий коэффициент 4.4 для MOX. Но он присутствует в расчётах как первой схемы, так и второй. Поэтому при расчёте процентов этот коэффициент сократится.

А разве нам требуется что-то кроме этого? Во взрослых средах имеются более адекватные источники энтропии. А в среде OpenComputers приходится импровизировать. Это значение выбрано на глаз. На шаманский глаз. Достаточно было бы и math.pow(2,52), чтобы перевести в целую часть все разряды мантиссы.

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

Опять промежуточная и компромиссная схема. Если в ней важен коэффициент использования топлива, то с этим трудно спорить, пусть так и будет. Если есть желание увеличить мощность реактора, то можно безболезненно впихнуть 6 счетверённых ТВЭЛ, получится также метастабильная схема. Впихивание седьмого ТВЭЛ уже потребует микроконтроля. Но я пока не нашёл варианта, который бы меня удовлетворил. Скриншота схемы на 6 счетверённых MOX ТВЭЛ у меня нет, но при наличии такого запроса могу сделать, я её обычно прямо в работающем реакторе выкладывал, чтобы сразу видеть ошибки. Схема допускает около десятка вариаций, поэтому каноничного вида не имеет. В принципе-то это реалистично. Тут вопрос, сколько роботов смогут выделить игроки на обслуживание одного реактора. Кстати, я порылся в своих сохранённых мирах и всё-таки нашёл вариант в 2000 eu/t на реакторе без дополнительных камер и без охлаждения. В те времена я ещё не додумался до идеи бешеного траснпозера, поэтому выкладывал схему из одних лишь ТВЭЛ, без реакторных пластин. Но тоже за один тик, просто вбрасывая нужное количество ТВЭЛ'ов. Сейчас думаю, эту схему можно разогнать и до 2800 eu/t средней мощности. Я думаю, где-то тут и возникает серьёзная развилка. Либо мы находим оптимальную схему из топливных ячеек и реакторных пластин и, например, аккуратно выкладываем пластины и потом одной командой вбрасываем недостающие стержни, либо также скопом вбрасываем сначала пластины, а потом топливо, не тратя время на мелкую работу. Успеют. На установку блока требуется 4 такта. Это, во-первых, было с черепашками и компьютерами из мода ComputerCraft. Роботы и компьютеры из OpenCOmputers могли выключиться только если во время рестарта они что-то активно считали. В этом случае они падают с ошибкой TLWY. Ну, значит, противопоказано нашим компьютерам задумываться. Будет у авторов мотивация оптимизировать свои программы.

Именно так и делается в лабораторных установках, работающих на максимально возможной скорости. Задание высылается заранее, поэтому отдельные роботы и компьютеры не тратят время на дополнительные проверки, а работают строго в соответствии с заданным расписанием. Но такой подход не выдерживает даже малейших лагов. Зато таким образом можно практически оценить теоретический предел скорости. Видимо, я непонятно объяснил: Тут вернее было бы написать "Если, конечно в результате этих перестановок не меняется температура корпуса реактора". А так-то, понятное дело, горячий MOX полезнее. Но процентных отношений это никак не меняет. Этим как раз и характеризуются все промежуточные схемы. Одновременная максимизация всех параметров невозможна, поэтому приходится жертвовать "чем-то и в какой-то степени". Из-за этой неопределённости тяжело обсуждать подобные схемы. Каждой такой схеме, наверное, нужно посвящать отдельную тему, чтобы сосредоточиться только на ней. И я согласен с @Taoshi: При накоплении избытка олова я бы предпочёл перевести схему одного из реакторов на сжигание охлаждающих стержней в оптимальном на данный игровой этап режиме. Тебе, конечно, никто не запрещает поступать иначе, но вникать в это другим участникам тяжело, они выпадают из обсуждения. Я тоже теряюсь. Если очень хочется применить именно гибридную схему, можно сначала разработать две разных схемы, оценить их параметры, и уже потом скрещивать в разных соотношениях. Тогда можно будет уже оценивать именно качество скрещивания.

Можно, наверное. Теоретически, можно выиграть ещё один такт времени, если придерживаться условий задачи. А так-то мы можем параллельно пересобирать хоть сотню реакторов. Ух ты! А где видел? Я-то никому не показывал и даже скриншотов не делал. Я вообще сомневался, можно ли такие лагодромы показывать публично. Но раз это уже не секрет, то рассказываю: башня из 108 компьютеров способна одним транспозером переместить все 108 слотов алмазного сундука за один такт времени. Правда, есть нюанс: ещё один такт тратится на то, чтобы отдать команду. Но при наличии заранее известных таймингов никто не мешает послать команду заранее. Поэтому да, в лабораторных условиях реакторную схему можно выложить одним транспозером всего за один такт. Если, конечно, не будет серьёзных лагов. Это не имеет значения. При смене расположения компонентов, изменения энергии и тепла в процентном выражении что на уране, что на MOX, полностью идентичны. Если, конечно, при этом не меняется температура корпуса реактора. Всё верно. Оптимум зависит от текущих условий игры. В этом-то и сложность обсуждения всех промежуточных схем. Поэтому желательно сразу указывать критерии оптимизации, чтобы не возникало недопонимания. Задача упростится, когда ты точно сформулируешь, какую цель преследуешь. Но сложности всё равно будут. С первого раза ты вряд ли придумаешь хорошую схему. Мои схемы обычно проходят через десятки итераций усложнения и упрощения. Это готовые схемы выглядят просто и понятно. А промежуточные варианты могут быть похожими на твой. Это нормально. Экспериментируй, но помни о цели.

Нет. В этом случае получатся разные числа, хоть в цикле их запросишь, хоть без цикла, это не имеет значения. Об этом можно не волноваться. Мои примеры должны были лишь продемонстрировать, что последовательности не случайны. И для этого я использовал стерильные условия. В OpenComputers же этой стерильности нет. Предсказуемость может возникнуть разве что по ошибке программиста, инициализирующего ГПСЧ при каждом запуске программы одинаковым значением. Разумеется, так делать не надо. Но даже если инициализировать ГПСЧ текущим временем, то хакер, зная код программы, имеет шанс вычислить последовательность якобы случайных чисел, что позволит ему, например, выигрывать в неаккуратно написанных казино. О, я совсем забыл поделиться своей радостью! Как хорошо, что эта тема, спустя два года, поднялась вновь. С момента прошлого обсуждения я нашёл идеальный для OpenComputers источник энтропии. Вряд ли удастся найти лучший. Работает быстро и крайне непредсказуемо. math.randomseed( -1e18*(os.clock()-os.clock()) ) Что ещё может быть более случайным в OpenComputers? Предлагайте свои варианты.

А зачем здесь требуется math.floor?

Транспозер работает в 11 раз быстрее. Но тут уже потребуется синхронизировать работу робота и компьютера. Кстати, ты какую задачу решаешь? Реалистичную для игровых условий, или лабораторную? Потому что в лабораторных условиях, например, одноблочный реактор можно полностью пересобрать за 17 майнкрафтовских тактов: 2 такта на демонтаж реактора 4 такта на его установку 1 такт на выкладывание схемы 10 тактов в среднем на ожидание очередного реакторного такта. Сборку схемы с дополнительными 5 камерами надо дополнительно проанализировать: потребуется дополнительный 1 такт или же 4 в зависимости от механики. Но такой результат достижим лишь при наличии громоздкой обвязки: 6 роботов и несколько десятков компьютеров. Такое и скрафтить не каждый сможет, и админы не разрешат. А ещё указанные тайминги не предусматривают проверок синхронности узлов системы, поэтому схема стабильна только на на слабонагруженных серверах.

Когда речь заходит об экономии охлаждающих компонентов, лучше не размещать ТВЭЛ'ы в соседних слотах. Чередование топливных и охлаждающих стержней в шахматном порядке снизит выработку энергии всего на 3.6% в сравнении с этой схемой, зато требование к охлаждению уменьшится на 32%. Но будет ли это выгодным в конкретных игровых условиях, уже другой вопрос.

Тема бурлит, каждый предлагает какие-то свои решения, и я уже плохо улавливаю отдельные нити рассуждений. И это при том, что я хорошо разбираюсь в теме. Менее опытные, наверное, давно уже запутались. Поэтому я прошу всех, кто предлагает какое-либо решение, сообщите, по каким параметрам вы оптимизируете свою схему. Раньше игроки предпочитали максимизировать удельную мощность реактора, тоннами сжигая лазурит. Сейчас игроки ищут новый баланс, и каждый из них руководствуется своими критериями. Кто-то использует греговские холодильники, кто-то готов сжигать олово или даже золото, кто-то строит схемы без использования постоянных расходников, у кого-то схемы полностью стабильные, у кого-то метастибильные, чьи-то схемы требуют микроконтроля. Во всём этом сложно ориентироваться. Короткий сопроводительный текст к скриншоту или идее очень поможет коллективной работе над улучшением схемы. Например: Насколько я понимаю, это метастабильная схема. То есть, микрокроконтроль реактора требуется лишь на этапе его разогрева или замены ТВЭЛ'ов. Но я не знаю параметров оптимизации этой схемы. Если целью было получение максимальной мощности реактора без применения постоянного микроконтроля, то схема не оптимальна. Существует возможность разместить 6 счетверённых ТВЭЛ'ов с увеличением базовой мощности с 260 до 360 eu/t. Но, возможно, целью этой схемы было эффективное использование ТВЭЛ'ов, когда топливо ещё не наработано в достаточном количестве. Одна из промежуточных схем, когда баланс плавно сдвигается от максимальной выработки энергии с единицы топлива к максимальной выработке с реактора. В этом случае обсуждение оптимальности схемы может не иметь смысла без уточнения дополнительных условий игры.