eu_tomat

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

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

Даже в реальном мире иногда включается режим отображения границ чанков. Подробности тут.

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

Сдаюсь. Этот этап игры в наводящие вопросы я провалил. Вот решение: Читаем таблицу значений энергии и тепла, выделяемыми топливными ячейками в различных условиях, и для каждой пары значений вычисляем новые показатели. Таблицу можно посмотреть здесь: https://minecraft-ru.gamepedia.com/IndustrialCraft_2/Ядерный_реактор Я продемонстрирую вычисления на примере счетверённого ТВЭЛ'а: Счетверённый ТВЭЛ, не имеющий активных соседей, генерирует 60 eu/t и 96 hu/s. Для охлаждения используются разогнанные теплоотводы производительностью 20 hu/s. Для рассеяния тепла одной топливной ячейки требуется 96/20 = 4.8 слотов, занятых теплоотводами. Сама топливная ячейка также занимает один слот. Итого, имеем 5.8 слотов, необходимых для генерации 96 eu/t. Средняя производительность одного слота реактора: 60 / 5.8 = 10.345 eu/t. Средняя производительность целого реактора с шестью дополнительными камерами: 60 / 5.8 * 54 = 558.62 eu/t. Среднее количество топливных ячеек в реакторе: 54 / 5.8 = 9.3 слота, занятых ТВЭЛ'ами. Для сравнения топливных ячеек друг с другом требуется знать только среднюю производительность слота реактора: E / (1 + H / 20). Вот и вся математика. Осталось лишь выбрать лучшие ТВЭЛ'ы с лучшими соседями, оптимально расположить их по слотам реактора, а оставшееся пространство заполнить теплоотводами. И тогда будет смысл приступать к кодингу.

Есть разные критерии оптимизации реакторных схем. Можно максимизировать экономию топлива. Можно максимизировать производительность реактора. Схема от @serafim нацелена на максимальную производительность. В этом контексте эффективность сжигания топлива второстепенна. Первостепенной же является эффективность использования слота реактора топливными ячейками и теплоотводами. Не все теплоотводы и не все топливные ячейки одинаково хорошо выполняют поставленную задачу, поэтому нужно выбрать лучший вариант. Выбор теплоотвода прост: разогнанный теплоотвод рассеивает тепло быстрее других. Выбор подходящего ТВЭЛ'а выглядит сложным, но и его можно вычислить. Возьмём текущий пример, и попробуем использовать в схеме ТВЭЛ'ы лишь какой-то одной из имеющихся групп. Средняя производительность реактора изменится: сдвоенные ТВЭЛ'ы, имеющие 1 активного соседа – 476.47 eu/t сдвоенные ТВЭЛ'ы, имеющие 2 активных соседей – 432.00 eu/t сдвоенные ТВЭЛ'ы, имеющие 3 активных соседей – 385.71 eu/t Сейчас лучшие подтягивают отстающих, и в среднем получается 412 eu/t. Выбросив худших и средних, получим 476 eu/t с реактора. Но это не предел. Возможны варианты и лучше этого, но они не были представлены в этой схеме. Поэтому возникает вопрос: какая из топливных ячеек обеспечит большую производительность, нежели сдвоенный ТВЭЛ, имеющий одного активного соседа?

Предлагаю вернуться к схеме от @serafim Как я уже говорил ранее, использованные в ней ТВЭЛ'ы работают неэффективно, и предлагал заменить схему их расположения. Изначально автор схемы использовал второй реактор для охлаждения теплоотводов, но этого было недостаточно, теплоотводы перегревались. Основной реактор приходилось отключать. Я предложил вместо отключения реактора заменять все ТВЭЛ'ы предварительно нагретыми теплоотводами. @Doob предлагает уменьшить количество ТВЭЛ'ов. Но как бы то ни было, оптимальную схему расположения ТВЭЛ'ов всё равно придётся найти. И чтобы не выбирать из всего многообразия схем, я предлагаю упростить задачу. Любая, сколь угодно хитро выложенная схема из ТВЭЛ'ов раскладывается до суммы составляющих. Например, текущая схема состоит из: 4 сдвоенных ТВЭЛ'ов, имеющих одного активного соседа; 18 сдвоенных ТВЭЛ'ов, имеющих двух активных соседей: 14 сдвоенных ТВЭЛ'ов, имеющих трёх активных соседей. Все эти ТВЭЛ'ы генерируют разное количество энергии и тепла. Энергия является полезным продуктом, а тепло вредным (по крайней мере, в этой схеме). Вопрос: ТВЭЛ'ы какой из этих групп приносят минимальную пользу, а какие максимальную?

Да, независимо. Корпус реактора охлаждается одинаково что холодным, что нагретым теплоотводом. Разогнанный теплоотвод рассеивает тепло со скоростью 20 hu/s независимо от поступления тепла с корпуса реактора. Но может рассеивать и меньше 20 hu/s, если теплоотвод не содержит в себе достаточного количества тепла. И наоборот, если корпус реактора содержит в себе достаточно тепла, разогнанный теплоотвод будет принимать его тепло со скоростью 36 hu/s независимо от своей способности рассеивать это тепло. Поэтому так трудно применять разогнанные теплоотводы для работы с MOX: они сплошь и рядом то излишне переохлаждают реактор, то сами перегреваются. Уточню формулировку: нагретый теплоотвод в горячем реакторе рассеивает то же количество тепла, что и в холодном. Но остывает он быстрее в холодном реакторе. В горячем же реакторе теплоотвод вообще будет нагреваться.

Торопишься как @serafim . Он сначала бросился писать код, не оценив схему, а потом, посчитав её безнадёжной, поспешил закончить разработку. Если ты сильно спешишь, сразу кидай более удачную схему. У меня-то схема уже есть, но я не спешу. Если читатели настаивают, я тоже могу сразу выложить. Но мне кажется, что полезнее будет пойти по пути диалога. Во-первых, в диалоге я надеюсь обнаружить какую-то идею, которую упустил сам. Во-вторых, читатели лучше понимают, что хорошие схемы не появляются сразу из ничего, и что хорошую схему можно получить из плохой эволюционным путём, постепенно исправляя недостатки. А вот и свежая для меня идея, добытая благодаря обсуждению: Не скажу, что этот подход сильно уменьшит лагодромы, но чуть уменьшить должен. И компьютер будет управлять сразу двумя реакторами, требуя от программиста большей аккуратности, что тоже ценно. До лагодромов мы тоже доберёмся и минимизируем. Но сначала надо понять максимальный потенциал схемы. Сможем ли мы использовать этот потенциал в реальных схемах, это следующий вопрос. По-моему опыту, это не всегда возможно. Иногда я предпочитаю остановиться на менее лагодромных схемах, чуть снижая производительность. Но это тоже не значит, что проблема принципиально нерешаема. Возможно, это я не осилил. По предложенным оптимазациям: Всё верно. Сейчас можно оптимизировать схему и в этом направлении тоже. А на последующих этапах эта оптимизация станет обязательной. Я же опасаюсь, что пока мы не найдём оптимальные ТВЭЛ'ы и их расположение относительно друг друга, все предшествующие оптимизации придётся повторить. Я пытаюсь провести читателя от плохой схемы к хорошей за минимальное количество итераций. Но так как именно ты активно поддерживаешь обсуждение, то я готов нарушить план. Похоже, история опять повторится: мы с тобой быстро обменяемся опытом, почти никто ничего не поймёт, а тема снова заглохнет на несколько месяцев. Друзья, если вам что-то непонятно, берите инициативу в свои руки, задавайте вопросы. Иначе я буду ориентироваться на уровень понимания @Doob , а диалоги у нас с ним получаются специфические.

Это пока лишнее. Задачу можно решить, оперируя лишь математикой и логикой школьного уровня. Предлагаю пока разобраться с ураном. MOX требует других подходов. Верно. Если реактор выключен, то слоты, занятые стержнями, бесполезны. В фазе охлаждения пользу приносят лишь слоты, занятые теплоотводами. Причём, нагретыми теплоотводами. Холодные теплоотводы также не работают и не приносят пользы. Теперь схема из двух реакторов генерирует 1540 eu/t, создавая избыточное тепло со скоростью 3312 – 8*9*20 = 3312 – 1440 = 1872 hu/s. В фазе охлаждения энергия не генерируется, а компоненты охлаждаются со скоростью 6*9*2*20 = 2160. Для приведения теплового баланса к нулю доля времени, занимаемого фазой генерации, должна составлять 0.536, а фаза охлаждения – 0.464, и таким образом, средний выход энергии с одного реактора составит 0.536*1540/2 = 412 eu/t. До этой оптимизации было всего 334 eu/t. Проведённая оптимизация помогает сделать явной ещё одну особенность. Несколькими постами ранее я намекал, что увеличение количества реакторов не увеличивает среднюю производительность в пересчёте на один реактор. Но никто не захотел проверить эту гипотезу. Так вот, в изначальной схеме эта гипотеза была неверна. А всё потому, что в фазе охлаждения основной реактор был неэффективным. При добавлении в схему второго, более эффективного реактора средняя эффективность поднималась. Но теперь благодаря оптимизации основной реактор стал столь же эффективным в фазе охлаждения, как и второй. Приведу расчёты для схемы с одним реактором. Схема та же самая за исключением того, что второй реактор отсутствует, а перегретые теплоотводы охлаждаются исключительно силами основного реактора. В фазе генерации реактор генерирует 1540 eu/t, создавая избыточное тепло со скоростью 3312 – 2*9*20 = 3312 – 360 = 2952 hu/s. В фазе охлаждения энергия не генерируется, но компоненты охлаждаются со скоростью 6*9*20 = 1080 hu/s. Для приведения теплового баланса к нулю доля времени, затрачиваемого на генерацию энергии, должна составлять 0.268, а фаза охлаждения – 0.732, и таким образом, средний выход энергии с одного реактора составит 0.268*1540 = 412 eu/t. Что и требовалось доказать. Второй реактор никак не влияет на увеличение средней производительности реактора. Для реакторов, максимизирующих выход энергии, есть правило №2: каждый слот должен приносить максимальную пользу. Исходя из этого, пустых слотов в реакторе быть не должно. Элемент каждого слота должен либо рассеивать максимум тепла, либо производить максимум энергии. С охлаждающими элементами всё понятно: ничто другое не сравнится с разогнанным теплоотводом, рассеивающим 20 hu/s. Теперь следует оптимизировать схему размещения ТВЭЛ. Кто догадался, в чём недостаток использованной схемы размещения ТВЭЛ? И как вычислить удачную схему?

Я ошибся в расчёте теплового баланса. В фазе генерации энергии компоненты схемы нагреваются на 3312 – 1440 = 1872 hu/s, а в фазе отдыха охлаждаются на 1440 hu/s. Средняя производительность реактора составит 334 eu/t, что более оптимистично. Но потенциал для оптимизации всё равно сохраняется. Кому удалось ответить на вопрос и обнаружить неэффективность работы одного из реакторов в фазе охлаждения? Даю ещё одну подсказку: Основной реактор охлаждает компоненты со скоростью 2*9*20 = 360 hu/s, а дополнительный (в идеале): 6*9*20 = 1080 hu/s. В чём причина неэффективности основного реактора? И как её устранить?

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

Потому-то я и предлагаю не заниматься микроконтролем микроконтроллеров. Например, если требуется быстро перегнать сотню стаков, то даём всей цепочке микроконтроллеров макрозадачу: перегнать 100 стаков. И пусть они пытаются перемещать, пока каждый из них не насчитает 100 успешных перемещений, или не истечёт таймаут в случае неполадок. В случае одной операции накладные расходы удваиваются. А в случае 100 операций они составляют всего один процент. Если цепочки перемещений длинные, то имеет смысл вспомнить о роботах. Они способны перемещать 8 стак*блок/тик. Транспозеры же перемещают всего 2 стак*блок/тик. Транспозеры в 4 раза медленее, при этом они требуют в 8 раз больше операций на единицу времени и в 32 раза на единичное перемещение стака. Поэтому роботы более предпочтительны для транспортировки на дальние дистанции. Минус роботов лишь в ожидании погрузки и разгрузки, но на длинных дистанциях это не критично.

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

Кольцо реакторов решает задачу ускорения сжигания топлива. А @serafim своей схемой пытается поднять производительность отдельного реактора. Цели он пока не достиг, но скоро достигнет. При желании обе задачи можно объединить, прогоняя десять урановых сборок через десять реакторов, если сервер справится с нагрузкой. Для начала требуется математическое обоснование решения. Если оно даже в идеальных условиях выдаёт 200 eu/t, то в реальных будет ещё меньше. Поэтому сначала требуется найти математически идеальное решение, и если оно выглядит достойным, искать способы его реализации. Начинать надо с математики, а код потом допишется, если схема возможна. Но сначала трубуется уйти на максимальные уровни абстракции в рамках задачи. Когда-то я писал в своём блоге про сизифов код. Это наш случай: плохой алгоритм невозможно спасти хорошим кодом. Реактор может работать непрерывно, если не требовать от него невозможного. Спрошу иначе. Какой из двух реакторов в твоей схеме более эффективен в фазе охлаждения? И что мешает другому реактору быть таким же эффективным?

Я об этом и говорил. Писать код пока преждевременно. Но схему можно оптимизировать. Хочешь сразу увидеть оптимальный вариант твоей схемы, или попробуешь найти оптимальное решение через наводящие вопросы? Одно из правил уже почти сформулировано. Правило №1: Для оценки производительности многореакторных схем следует считать среднюю производительность на один реактор с учётом фаз нагрева и охлаждения компонентов реактора. Иначе есть риск впасть в заблуждение и посчитать производительность по максимуму, ориентируясь только на генерирующий реактор и на фазу максимальной выработки энергии. Кстати, в предложенной схеме неоптимальны обе фазы: и фаза охлаждения и фаза генерации энергии. Предлагаю начать с простых вещей. Какой из двух реакторов в этой схеме работает неэффективно в фазе охлаждения? И как это исправить?

Да, в конечном итоге выгорят все теплоотводы. Твоя схема генерирует 3312 hu/s, а рассеивает в идеале 9*8*20=1440 hu/s. Если регулярно останавливать реактор для охлаждения теплоотводов, то средняя выработка энергии снизится до 466 eu/t, а если учесть, что в схеме работают два реактора, то получаем жалкие 233 eu/t на реактор. Схема явно нуждается в оптимизации. Простой можно уменьшить, добавив для охлаждения третий и даже четвёртый реактор. Но увеличится ли от этого средняя выработка энергии в пересчёте на один реактор?

А что происходит во время простоев? Основной реактор просто отключается, ожидая, пока теплоотводы охладятся? А чем оправдан обмен теплоотводов между реакторами в этой схеме?

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

Засовываем транспозер в контроллер во время сборки. В EEPROM пишем код: -- EEPROM для микроконтроллера со встроенным транспозером: -- ладодром, переносящий предметы снизу вверх. local transfer = component.proxy(component.list"transposer"()).transferItem while true do transfer(0,1) end Работает, проверено на OC 1.7.5.

Для увеличения производительности требуется минимизировать коммуникацию. Поэтому и в задаче с конвейером надо уходить от идеи виртуальных компонентов. Тогда схема становится асинхронной, где каждый из узлов получает своё задание и выполняет его с максимально возможной скоростью, изредка общаясь с головным компьютером. С задачей увеличения производительности виртуальные компоненты пока справляются плохо. Но в этой идее есть рациональное зерно. Предлагаю расширить изначальную идею и считать виртуальным компонентом весь удалённый компьютер (микроконтороллер, робот, дрон) с любыми подключенными к нему реальными компонентами. А вместо синхронно управляемого конвейера я предлагаю систему умных воронок. Умная воронка это микроконтроллер со встроенным транспозером и простой программой в EEPROM, которая принимает к исполнению задачу от управляющего компьютера. Задачи могут быть любыми: перемещать все обнаруженные предметы с максимальной скоростью с запада на юг, или с востока и севера наверх; выбирать направление перемещений в зависимости от типов предметов или других условий; сообщать управляющему компьютеру об изменениях в инвентаре; и т.п. При этом далеко не всем микроконтроллерам требуется работать на пределе возможностей и порождать лагодромы. Зачастую требуется проверка инвентаря раз в минуту или реже. Производственная логистика в Майнкрафте легко поддаётся планированию, что позволяет избавиться от ежетиковых проверок. Управляющий компьютер может посылать умным воронкам новое задание, если предыдущее задание предусматривает возможность его отмены. Или может ставить текущий процесс на паузу. Или давать временные задания, прекращающиеся по таймеру или иному условию. Умные воронки время от времени посылают на управляющий компьютер короткий отчёт, чтобы тот знал, что воронки не зависли. Время отправки отчётов можно выбирать псевдослучайно, чтобы равномерно размазать передачу сообщений во времени. Управляющий компьютер может давать воронкам команду на отключение или будить их. Умную воронку можно считать виртуальным компонентом и управлять с одного компьютера огромным заводом, не только осуществляя большое количество операций за один тик, но и минимизируя затраты на коммуникацию.

Хочешь выжать из этой схемы больше? Я готов рассказать в двух вариантах: либо я быстро и коротко предлагаю оптимальный вариант (с учётом моих способностей к оптимизации), либо помогаю тебе выйти на оптимальный вариант путём наводящих вопросов. Второй вариант позволит тебе пойти в каком-то смысле своим путём и, возможно, найти схему лучше моей. Итак. Придумывая новую схему, о лагодромах я лагах думаю в последнюю очередь. В первую же очередь важна теоретическая работоспособность схемы. Предположим, у тебя уже есть идеальный механизм, мгновенно заменяющий топливо в реакторе. Также идеально происходит замена теплоотводов свежими из второго реактора. Вопрос: как долго сможет проработать предложенная тобой схема (якобы на 1540 eu/t)?

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

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

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