Disc2

@eu_tomat Зачем вы в роботов вставили квантовые процессоры с эффектом наблюдателя? 

@Wolframoviy Так а чего на ОБТ не гонять сразу моды которые будут использоваться? Кстати, сразу делайте таблицу с модами, ссылками на них, и зависимости, и добавляйте комменты - вроде багов, баланса, и неожиданных особенностей. Экономит тонну времени, это как 101 для сборок.

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

LagGoggles (но это клиентский мод, наличия на сервере емнип не требует).
Tiquality

По ссылкам на 1.7.10 их нет.

Вроде чаще всего видел на серверах Opis 

@prop А теперь можно цитату где именно я предлагал проводить занятия, заниматься обучением игроков напрямую? Где было бы что-то что подразумевало, что игрок не будет взаимодействовать с каким-либо контентом именно так, как он и взаимодействует с ним на форуме? Т.е. САМ.

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

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

Комфортный вкат,бест практис,бут камп - что? Где ты это все берешь? 

@ProgramCrafter Континуации допилить в майнкрафт  

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

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

 

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

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

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

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

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

Играть AFK и не играть, а уходить AFK пока игра грузиться разные вещи -

"О,щас зайду по бырику в игру, проверю идею"

или

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

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

Фризы и фпс это графика - мы же не шейдеры с текстур-паками обсуждаем? Какая разница роботу какой у игрока ФПС? Нас волнует функциональный контент, и рендер происходит отдельно от просчета мира. К тому же это сервер, а не сингл, просчет мира происходит не у игроков. Т.е. для клиента от модов скорее будет зависеть требование по ОЗУ, и чтобы утечек памяти не было.

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

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

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

Реши задачу - получи кирку на удачу. Или что-то в этом роде.

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

Хотя в другой теме мне сказали, что я вообще не правильно понял предназначение сервера. Но тогда зачем нужен IC2 и т.д.?

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

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

 

 

  Показать содержимое

Тут не школа или буткэмп, а скорее песочница или какерспейс а-ля старая лаба ии в эмайти под руководством М.Мински. 

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

 

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

 

Так вот, несколько советов чего можно посмотреть(список неполный и неупорядоченный):

1) Что такое алгоритмическая сложность и почему нам не все равно.

2) Преждевременная оптимизация.

3) Абстракция.

4) Что такое Computer/Computing Science?

5) Зачем создаются новые языки программирования?

 

И самое главное не стоит загонять себя в рамки, "теория" и "практика" полезны одинаково. см. EWD1095.

 

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

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

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

Проблема с большими сборками не только в том потянет ли железо игроков, а еще в длительности загрузки - одно дело сидеть ждать 2 минуты пока клиент загрузится, другое - 5 минут, а больше 10 так это вообще мазохизм какой-то. Имхо, длительность загрузки один из самых главных показателей производительности сборки. Возможность быстренько заскочить на сервер очень важна, например - у кого-то появился вопрос и кто-то заинтересовался помочь - даже разница в 1 минуту может сыграть роль, решит ли человек зайти на сервер, или будет отвечать только в чате\на форуме. В теории если загрузка клиента была бы менее секунды, то на серв заглядывали бы даже самые занятые местные старожилы, даже при условии, что майн им уже приелся.

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

TL;DR: Я к тому, что размер контролировать нужно, но и интерес у пользователей вызывать надо.

Может поискать какие-то существующие квест-румы для OC? А еще, обязательно ли ограничиваться ОС, может и СС с адоннами тоже добавить?

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

Капчу на входе с решением задачек на уровне дошкольного Lua.

Пусть изобретают локальные сети и свою BBS.

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

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

@eu_tomat Тогда надо какую-то систему голосований устроить. Причем для всего - автоматом голосовалку за добавление в вайт лист, среди проверенных игроков, за модераторов и т.д.

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

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

Под вещами я имел ввиду рабочие конструкции, а то заходит человек на сервере - а МЕ сети у него уже нет.

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

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

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

Чтобы самому тратить меньше времени - то конечно лучше всего изначально правильно делегировать задачи, но это часто приводит к банальным конфликтам между админами.

Конечно опять таки, если за онлайном цели гнаться нет совсем, и использовать вайтлист - то большинства проблем вообще возникать не должно.

С плагинами на приваты постоянно были какие-то проблемы, вроде отсутствия проверки флагов. Думаю даже с вайтлистом, был бы неплохой вариант предоставить игрокам какое-то безопасное пространство вне основного мира, где можно хранить особо ценные вещи,или даже строить заводы - если это будут специальные выделенные измерения, тогда по идее в случае лагодромов их будет проще обнаруживать по загрузке конкретного измерения. Не знаю правда как это изначально скажется на нагрузке на сервер и о конкретной реализации. В том же АЕ2 есть пространственные ячейки создающие отдельные измерения, а в Galacticraft есть космические станции. Есть еще Compact Machines .

@eu_tomat Обычно сервера перезагружают раз в 3 часа. Подробностей не знаю.

Так все-таки под какие цели серв собирается? Ориентация  в основном на вайтлист+компы или паблик + играбельные моды + привлечение онлайна?

На всякий случай вот списки модов для оптимизаций. Еще есть FPS Reducer - ограничивает фпс и снижает нагрузку когда афк или свернуто окно игры, имхо может быть весьма полезно для сборки с компами. AI Improvements  для 1.7.10 есть старый и без стабильной сборки,но пригодиться может.

Galacticraft разве чем-то интересен на 1.7.10? И за нагрузку на него и правда всегда жаловались.

Насчет Forestry и генетики есть Genetics из Binnie's Mods(в нем же Extra Bees,Extra Trees, Botany) и есть Gendustry требует BdLib .

По стандарту Inventory Tweaks , Mouse Tweaks , NEI Integration , ArmorStatusHUD требует bspkrsCore , Damage Indicators 

К АЕ есть AE2 Stuff тоже требует BdLib , ExtraCells2

О как интересно совпало, только что решил сделать сборку для себя чтоб поиграться, хотел чтоб в ней был Create,так оказлось уже и на Curse лежит OpenComputers II под 1.18.1- два дня как. https://www.curseforge.com/minecraft/mc-mods/oc2

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

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

В смысле погрешность? Погрешность чего именно, вычислений в sleep() или  print(time()-t0)? Откуда она? Просто уж слишком странные погрешности, часто синхронны между роботами, но не всеми сразу.

Все равно не догоняю, как понять то какой сейчас год  такт исполняется - т.е. например такты идут 1\2\3\4\5\6.. во втором такте исполняем os.sleep(0.05) а замер времени выдал 0.050001 - в каком такте мы очутились? в 4 или 5?

..А на мониторе (в игре) вывод происходит в тот же самый момент когда код исполнился, или тоже с задержкой на такт?.. 

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

Количество тактов можно получить, умножив значение времени на 20.

 

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

У меня результат замера времени исполнения sleep(0.04) выдается то 0.049999 то 0.050001

Т.е. это два  тика,или один? Мы же округляем вверх?

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

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

 

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

 

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

 

Какие у тебя есть идеи для точного управления последовательностью действий?

Брутфорс   

Каждый раз при перезагрузке чанков. 

Т.е. поставил сейчас тест-эксперемент 7 роботов,1 для бродкаста сообщения,1 ставит реактор и 5 пытаются повесить на реактор камеры - все 6  работают "моментально" по приему сообщения.

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

Сломал робота ставящего реактор,поставил по новой - 1 реактор и 3 камеры  - при повторе бродкаста результат тот же.

Снова переустановил робота - 1 реактор и все 5 камер. Результат повторяется при бродкастах.

При этом на всех роботах 1 программа в ней 2 замера времени - замер в основном рабочем цикле, и замер длительности robot.place() после приема бродкаста. Из замеров стало понятно ровно ничего. 

После перезагрузки мира потребовалось 5 раз переставить робота с реактором чтобы вешались все камеры.

Т.е. по идее шансы 1к5 что этот робот будет выполнять команды раньше других. (В смысле 1 энтитя против 5 энтитей)

Если пытаться добавить заполнение реактора в этот же тик двумя (топливо и пластины) другими блоками (транспозерами,роботами или еще чем-то), то для каждого будет шанс 50% срабатывать раньше установки камеры с которой они будут взаимодействовать. 

Пока проверил только еще 2 роботами robot.drop(),но т.к. он дольше выполняется чем robot.place(),то проверка была исключительно относительно друг друга - реактор по вертикали ( О_о ) оказался разделен на половину со стержнями и половину с пластинами.Пару раз повторил результат,потом пытался проверить на сундуке вместо камеры - понял что затупил,вернул камеру,теперь стало делить по горизонтали.

Кстати os.sleep(0.05) или 0.04 - будет выполнятся 1 тик или 2?*

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

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

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

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

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

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

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

Почему 2 такта на демонтаж? Как именно измеренно?

Почему 4 на установку? Как измеренно?

Больше всего времени тратим на ожидание, 10 тактов в среднем (кстати это 1+19/2=10 или 1+20/2 или 0+20/2?),т.к. этот среднее время то значит что по факту мы можем "полностью пересобрать" реактор  за 7-8 тиков,если повезет,а если нет то за 26-27.

Кстати,а не можем ли мы в 1 такт выполнить сразу несколько действий в определенной последовательности?

Как я понимаю желаемый алгоритм действий -

Имеется 2 паралельных реакторных установки (rA и rB)

rA подходит к завершению рабочего цикла

rB зарание начинает установку

rA начинает демонтаж и заканчивает его

rB заканчивает установку

В rB выкладывается схема

Ждем внутреннего тика rB

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

(Это сообщение переписывал повторно,и не уверен что ничего не упустил)

А кстати, в последней версии ОС для МС 1.12.2 robot.place() вообще занимает 8-9 тиков, на 1.7.10 или более ранних версиях ОС роботы чтоли были быстрее?

Только что, eu_tomat сказал:

В том примере по ссылке мы ничего не знаем о факте установки блока роботом. Мы знаем только о времени, в течение которого вызов обрабатывался.

 

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

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

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

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

 

 

Я имею ввиду, совокупность действий и событий - не только то что происходит в исполняемой программе робота. Т.е. как мы знаем что 5 роботов поставили реакторные блоки одновременно в такой-то такт, транспозер переместил предметы в следующий такт, и реактор получил рэдстоун сигнал и запустился ровно череp n тактов?

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

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

 

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

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

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

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

 

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

 

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

 

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

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

 

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

 

 

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

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

расталкуй плиз понял только readonly

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

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

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

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

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

Так я спрашивал не про схему реактора,а про обвес роботами\транспозерами. Это не решение задачи,а изучение неизвестного материала, следовательно изучать с наглядного примера было бы хорошо. Как компы синхронизировать, как тики мерять - я с таким за неделю ничего не добьюсь. Ну ладно.

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

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

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

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

Можно видеть, что  в результате получены те же самые проценты.

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

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

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

Я всё-таки собрал метастабильную схему для MOX на 1800 eu/t. Реактор требует внимания лишь на этапе замены топлива.

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

Чуть домучал схему : 21p7esnxynk8npa96g5vr2bqx9383e3xeizviiwjjwe2coi03hkexs2znmkcgmwwjxphlqu94bhz4us

Скрин из игры поверх скрина планировщика.