eu_tomat

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

Т.е. если я правильно понял - то даже "в лабораторных условиях" вы тики действий определяете косвенно и не обязательно со 100% точностью, а за счет среднего значения из выборки?

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

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

комментарий с серва где запретили крафт лазуритовых конденсаторов (

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

Или будем топить реактор оловом. Олово же не реже лазурита встречается?

8 минут назад, Disc2 сказал:

Лучше хотя бы линкнули на описание того, как вы четко определяете тики совершенных действий, т.к. это ключевой элемент в вашем обсуждении о схемах с реконструированием реакторов.

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

Об измерениях тактов Майнкрафта я как-то рассказывал в этой здесь.

24 минуты назад, hohserg сказал:

Наверное, стоило бы использовать систему контроля версий, чтобы показать разницу с оригинальной openos

Поддерживаю. Также желательно разместить код на каком-нибудь соответствующем сервисе вроде github/gitlab.

А то, с одной стороны, есть просьба помочь

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

помогите поишете, найдете сообшите

А с другой, отсылка в дальний путь:

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

еше так есть документация в хоме ее почитай

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

Пока это максимум, что я могу посоветовать.

11 минуту назад, rootmaster сказал:

есть большой довольно патч/мод для openOS

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

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

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

...

2.ставим реактор. 

3.ставим 2 реакторных камеры.

4. Закидывает пластины.

5.ставим 3 реакторных камеры.

6. Закидывает стержни.

А все реакторные камеры ты планируешь устанавливать одним роботом, или дополнительными роботами для максимального ускорения?

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

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

В 13.01.2022 в 18:20, Taoshi сказал:

Я, конечно, запустил после этого прокачку апдейта опыта на сервере (старый апдейт улучшающий робота до алмазного отдан год назад),но это дня на три.

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

15 минут назад, Disc2 сказал:

Вот,по этому я и сказал "стоп". Я пытаюсь одно и тоже объяснить уже десятым способом - первое твое сообщение про ТВЭЛы в смежных слотах я прочитал и прекрасно понял. Потом просто добавил к этому, что для МОХ приоритеты будут другие.

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

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

если у нас был бы третий тип ТВЭЛов, который выдавал бы в 10,000 раз больше еу, но с таким же тепловыделением как у МОХ и урана - твои проценты были бы тоже 25%\40% для такого топлива.

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

11 минуту назад, Disc2 сказал:

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

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

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

В 14.01.2022 в 18:24, eu_tomat сказал:

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

Наше с тобой недопонимание началось именно с этого момента. Давай разберём, что здесь происходит. Переведя три реактора на новую схему, мы освобождаем охлаждающие стержни для четвёртого реактора, который из-за нехватки охлаждения был вынужден простаивать. И благодаря этому возникает не падение итоговой мощности группы реакторов а её повышение: на 100% - 3*3.6% = 89%.

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

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

13 минуты назад, hohserg сказал:

Какие значения тут случайны?

Тут нет ничего случайного. Есть практически непредсказуемое, и потому подходящее на роль источника энтропии для инициализации зерна ГПСЧ.

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

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

6 часов назад, Disc2 сказал:

Можешь поделиться наработками из этих сообщений,пжлста? По возможности самим сохраненными мирами?

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

Вот и живой пример:

6 часов назад, Disc2 сказал:

Но! Теперь возникла куча новых идей в связи с поднятием дополнительных аргументов.

Отлично! Я и и надеялся как раз на то, что это обсуждение подтолкнёт участников обсуждения к самостоятельному поиску новых схем.

6 часов назад, Disc2 сказал:

Самое первое и простое - если теперь мы добавим цель размножения плутония, то используя двойные стержни вместо счетверенных - мы можем ускорить производство плутония на 32% с того же самого реакторного места, теряя всего 13.8% энергии.

1+4.8 слотов \ 4 урана=1.45 слотов\уран, против 1+3.6 слотов \ 6 урана =1.1слотов\уран.

При этом используя схему где ТВЭЛы\теплоотводы в шахматном порядке - мы сократим активность микроконтроля в 11 раз (теплоотводы медленнее перегреваются). 11 секунд до замены на счетверенных, против 124 секунд  на сдвоенных. Плюс проще увеличить стабильность и выделить дополнительный резерв времени на случай лагов

Хорошее решение. Если принять во внимание точное значение теплового баланса, то окажется, что при шахматном заполнении некоторые ТВЭЛ'ы в схеме лишние. Поиск же самых лишних с точки зрения минимизации микроконтроля тоже является  увлекательной задачей.

6 часов назад, Disc2 сказал:

Вывод - соединять МОХ полезнее чем соединять уран. Полезнее в те самые 4.4 раза, и этот коэффициент никуда не сокращается. (3520\800)

Да, Горячий MOX полезнее урана. Какой смысл это повторять? Да, полезнее в 4.9996 раз. Но при указанных выше вычислениях этот коэффициент сокращается. Не MOX относительно урана, а двух разных схем на MOX.

Хорошо, я продолжу свой пример:

19 часов назад, eu_tomat сказал:

Объясню на понятном тебе примере.

Два счетверённых ТВЭЛ'а на уране в смежных клетках генерируют 160 eu/t при перегреве 320 hu/s.

Два счетверённых ТВЭЛ'а на уране в несвязанных клетках генерируют 120 eu/t при перегреве 192 hu/s.

Вторая схема производит энергии на 25% меньше, при этом уменьшая нагрузку на охлаждающую систему на 40%.

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

 

Температура реактора на эти расчёты никакого влияния не окажет. Предположим, есть повышающий коэффициент 4.4 для 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.

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

Так,стоп,нет.

Да, продолжаем.

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

Т.е. соотношения другие, и в случае с МОХом,в горячем реакторе, ставить стержни в смежные клетки полезнее чем в случае с ураном.

Тут ты говоришь про другие соотношения, а не те, о которых говорил я. Ясное дело, выгоднее расходовать холод на горячий MOX, нежели уран.

Объясню на понятном тебе примере.

Два счетверённых ТВЭЛ'а на уране в смежных клетках генерируют 160 eu/t при перегреве 320 hu/s.

Два счетверённых ТВЭЛ'а на уране в несвязанных клетках генерируют 120 eu/t при перегреве 192 hu/s.

Вторая схема производит энергии на 25% меньше, при этом уменьшая нагрузку на охлаждающую систему на 40%.

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

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

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

Идея с clock хорошая, но будет работать только в рамках мода из-за хука на вызовы функций в machine.lua.

А разве нам требуется что-то кроме этого? Во взрослых средах имеются более адекватные источники энтропии. А в среде OpenComputers приходится импровизировать.

7 часов назад, ECS сказал:

 А как ты выбрал магическую константу? Это явно не math.mininteger/maxinteger, а что-то чернокнижное

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

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

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

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

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

Была предоставлена схема для МОХ, не требующая особого внимания и затрат. С хорошим коэффициентом топлива в энергию. Практически не теряющая нагрев при автоматической замене ТВЭЛ'ов. Возможность разместить 6-7счетверённых стержней действительно существует, но есть нюанс - работать будет только с обычным топливом, но не с МОХ, поскольку разогнанные теплообменники активно обмениваются теплом в том числе с обшивкой реактора и принимают до 36 единиц тепла, а поглощают только 20. Что приводит к их перегреву и разрушению при нагреве реактора. Но вполне можно использовать чуть менее эффективную, но более мощную по вырабатываемой энергии схему на 5ти счетверённых ТВЭЛ'ах и разогнанных теплоотводах. В обоих случаях во все пустые слоты добавляются пластины теплоёмкости. Потому схема с 7ю ТВЭЛ'ами используется исключительно для отработки топлива с целью получения драгоценных шариков плутония.

Опять промежуточная и компромиссная схема. Если в ней важен коэффициент использования топлива, то с этим трудно спорить, пусть так и будет. Если есть желание увеличить мощность реактора, то можно безболезненно впихнуть 6 счетверённых ТВЭЛ, получится также метастабильная схема. Впихивание седьмого ТВЭЛ уже потребует микроконтроля. Но я пока не нашёл варианта, который бы меня удовлетворил.

Скриншота схемы на 6 счетверённых MOX ТВЭЛ у меня нет, но при наличии такого запроса могу сделать, я её обычно прямо в работающем реакторе выкладывал, чтобы сразу видеть ошибки. Схема допускает около десятка вариаций, поэтому каноничного вида не имеет.

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

Но всё же считал задачу для реальных условий.

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

Кстати, я порылся в своих сохранённых мирах и всё-таки нашёл вариант в 2000 eu/t на реакторе без дополнительных камер и без охлаждения. В те времена я ещё не додумался до идеи бешеного траснпозера, поэтому выкладывал схему из одних лишь ТВЭЛ, без реакторных пластин. Но тоже за один тик, просто вбрасывая нужное количество ТВЭЛ'ов. Сейчас думаю, эту схему можно разогнать и до 2800 eu/t средней мощности.

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

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

Пока робот(в?) поставит блоки реактора обратно, компоненты как мне кажется успеют перекочевать в хранилище присоединённое к транспозеру.

Успеют. На установку блока требуется 4 такта.

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

Кстати, после рестарта роботы/компы не отключаются? То было такое кое-где пяток лет тому.

Это, во-первых, было с черепашками и компьютерами из мода ComputerCraft. Роботы и компьютеры из OpenCOmputers могли выключиться только если во время рестарта они что-то активно считали. В этом случае они падают с ошибкой TLWY. Ну, значит, противопоказано нашим компьютерам задумываться. Будет у авторов мотивация оптимизировать свои программы.

7 часов назад, Disc2 сказал:

А нельзя заранее отправить пакеты мол процесс демонтажа реактора пошел, и sleep(0.05) [action] на роботов которые собирать реактор будут,а на компы которые загружать должны  sleep(0.1) [action] ? Для синхронизации.

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

7 часов назад, Disc2 сказал:

Так а смысл МОХа без повышения нагрева реактора?

Видимо, я непонятно объяснил:

9 часов назад, eu_tomat сказал:

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

Тут вернее было бы написать "Если, конечно в результате этих перестановок не меняется температура корпуса реактора". А так-то, понятное дело, горячий MOX полезнее. Но процентных отношений это никак не меняет.

12 часа назад, Disc2 сказал:

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

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

И я согласен с @Taoshi:

10 часов назад, Taoshi сказал:

Не рекомендую гибридные схемы.

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

22 минуты назад, Disc2 сказал:

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

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

28 минут назад, Disc2 сказал:

Кстати, вопрос - я вроде видел как 1 транспозер работал сразу от сигналов с нескольких компов с огромной скоростью, и как я понял у самого транспозера лимита скорости работы нет(или он не так важен),а есть лимит в частоте обращений 1-го компьютера к транспозеру, это так?

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

35 минут назад, Disc2 сказал:

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

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

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

И насчет сжигания охлад.стержней все тоже не так однозначно - если смотреть на это как на конвертацию излишка запасов олова и лазурита в материю(для иридиума например)

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

43 минуты назад, Disc2 сказал:

по итогу понял что только слепил все до кучи - ... непойми как считать

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

19 минут назад, Joe сказал:

Получается как я понял, если использовать несколько раз команду print(math.random()) в компьютере из opencomputers, то получится один и тот же ответ? Или как?

Нет. В этом случае получатся разные числа, хоть в цикле их запросишь, хоть без цикла, это не имеет значения. Об этом можно не волноваться.

Мои примеры должны были лишь продемонстрировать, что последовательности не случайны. И для этого я использовал стерильные условия. В OpenComputers же этой стерильности нет. Предсказуемость может возникнуть разве что по ошибке программиста, инициализирующего ГПСЧ при каждом запуске программы одинаковым значением. Разумеется, так делать не надо.

Но даже если инициализировать ГПСЧ текущим временем, то хакер, зная код программы, имеет шанс вычислить последовательность якобы случайных чисел, что позволит ему, например, выигрывать в неаккуратно написанных казино.

О, я совсем забыл поделиться своей радостью! Как хорошо, что эта тема, спустя два года, поднялась вновь.

С момента прошлого обсуждения я нашёл идеальный для OpenComputers источник энтропии. Вряд ли удастся найти лучший. Работает быстро и крайне непредсказуемо.

math.randomseed( -1e18*(os.clock()-os.clock()) )

Что ещё может быть более случайным в OpenComputers? Предлагайте свои варианты.

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

Вместо math.floor для ускорения процесса можно использовать операцию целочисленного деления // 1.0

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

В 22.11.2019 в 18:35, eu_tomat сказал:

math.random(lower, upper) генерирует целое число в диапазоне [lower..upper].

В 13.01.2022 в 18:20, Taoshi сказал:

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

Транспозер работает в 11 раз  быстрее. Но тут уже потребуется синхронизировать работу робота и компьютера.

Кстати, ты какую задачу решаешь? Реалистичную для игровых условий, или лабораторную? Потому что в лабораторных условиях, например, одноблочный реактор можно полностью пересобрать за 17 майнкрафтовских тактов:

• 2 такта на демонтаж реактора
• 4 такта на его установку
• 1 такт на выкладывание схемы
• 10 тактов в среднем на ожидание очередного реакторного такта.

Сборку схемы с дополнительными 5 камерами надо дополнительно проанализировать: потребуется дополнительный 1 такт или же 4 в зависимости от механики.

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

7 часов назад, num_pi сказал:

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

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

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

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

Короткий сопроводительный текст к скриншоту или идее очень поможет коллективной работе над улучшением схемы.

Например:

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

Я использовал для мох такую схему:

Насколько я понимаю, это метастабильная схема. То есть, микрокроконтроль реактора требуется лишь на этапе его разогрева или замены ТВЭЛ'ов.

Но я не знаю параметров оптимизации этой схемы.

Если целью было получение максимальной мощности реактора без применения постоянного микроконтроля, то схема не оптимальна. Существует возможность разместить 6 счетверённых ТВЭЛ'ов с увеличением базовой мощности с 260 до 360 eu/t.

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

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

Главное что работает, и делает именно то что просил человек.

Человек получил простое решение в первом же сообщении. Разумеется, можно придумать ещё сотню вариантов различной степени сложности. Но зачем?

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

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

В чём преимущество этого решения?

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

В том что оно работает =) Что конкретно тут сложно? Попробуй убрать string.char, посмотри что из этого получится. 

Конкретно тут math.random вызывается 8 раз. Разве не достаточно одного раза?

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

function rand() local res = "" for i = 1, 8 do res = res .. string.char(math.random(48, 57)) end return tonumber(res) end

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