eu_tomat

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

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

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

@Joe Числа из одной последовательности и должны быть разными, как правило. Выше речь шла не о совпадении чисел внутри последовательности, а о совпадении самих последовательностей с момента запуска Lua.

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

Важно не кто тратит время, а в каком количестве. И в конечном итоге важна будет не средняя мощность работы реактора, а финальная мощность с учётом простоя во время пересборки. 29.70 секунд для 54 слотов реактора, если нет лагов. А в какой версии OpenComputers апгрейд опыта способен ускорять передвижения робота?

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

Я погорячился. Именно такого мне не удавалось. Удавалось лишь прогнать около 15 счетверённых ТВЭЛов в секунду на одноблочном реакторе. Пиковая мощность составляла 2160 eu/t. Но средняя мощность получится ниже раз в 5, т.к. реактор демонтируется до того, как успевает отдать всю энергию. Поэтому такая схема годится лишь для быстрой наработки плутония. И то, похоже, не везде будет работать:

Правда? А как это проверить? Потому что у меня геосканер считает пустоту блоком воздуха с нулевой плотностью. Впрочем, переместиться в этот блок он не может. Поэтому я не уверен на счёт пустоты. Зато, когда я игрался с копалками, запомнил, что необычную плотность имеет бедрок. Как раз, -1. А когда я смотрел код помех, обнаружил что плотности блоков складываются. И значит, блоки с отрицательной плотностью вроде бедрока способны улучшать прохождение сигнала. Дальше я не стал вчитываться в код, а провёл эксперимент: В плоском мире установил два компьютера на расстоянии 1 блока друг от друга, воткнул в каждый по беспроводной плате и запустил интерпретатор Lua. Убрал все блоки земли вокруг системных блоков, чтобы те не создавали помех. На одном компьютере запустил component.modem.open(1)while true do print(event.pull())end На другом я последовательно запускал код s=2 component.modem.setStrength(s)for i=1,10 do component.modem.broadcast(1,s,i)end, варьируя силу сигнала. И следил за поступлением пакетов на первый компьютер. При s=1 ни один пакет не доходит. При s=2 доходят все пакеты. Это стандартное поведение. Но если заполнить 9 блоков между системными блоками бедроком, то доходят все пакеты даже при s=1. Из этого я и сделал вывод, что бедрок способен не только улучшать прохождение пакетов, но и увеличивать дальность связи. Возможно, что это увеличение не превышает одного блока. А возможно, и не во всех случаях, завися от погрешности вычислений. Но в любом случае роботы, спрятанные в глубине складок бедрока, имеют лучшие условия для связи, чем другие их собратья-шахтёры.

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

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

Да, безумненько, но возможно. С таким охлаждением мне удавалось получить около 2000 eu/t с реактора в среднем. И это далеко не максимум. Законно ли применять подобное на серверах, и будет ли оно там работать, не знаю. При низком TPS, скорее всего, не удастся полностью заполнить реактор топливом за один такт Майнкрафта, что проявится в снижении мощности.

А какая плотность у пустоты? Кхмм... надо перепроверить. Дальность точно может быть больше силы сигнала. Может, всего на единицу?

Если вопрос о принципе, то сейчас можно накидать много разных схем, даже самых безумных. Впрочем, выкапывание шахтёрских миров за несколько дней тоже граничит с безумием. Поэтому фантазию, наверное, можно не сдерживать. Первый безумный вариант: вместо конденсаторов сжигаем теплоотводы. Заменять их теперь надо в 20 раз чаще. Расход ресурсов будет стремительным. Но вариант возможный в принципе. О, почти классика. Эталон экономичной наработки плутония при охлаждении конденсаторами. В этой схеме 2052 hu/s избыточного тепла. Дополнительный реактор способен утилизировать 1080 hu/s. Значит, требуется 1.9 дополнительных реакторов. А всего 2.9 реакторов. В этом реакторе работают 27 ТВЭЛ'ов, или 9.3 ТВЭЛ на реактор. Да это же стандартное число! Почему число стандартное? Реактор имеет 54 слота. ТВЭЛ генерирует 96 hu/s, один теплоотвод рассеивает 20 hu/s. Максимальное количество ТВЭЛ на один реактор = 54 / ( 96 / 20 + 1 ) = 9.31. С точки зрения управления у этой схемы имеется существенный недостаток: часть теплоотводов подвергается максимальному перегреву, а другая часть максимальному переохлаждению. Из-за этого теплоотводы приходится часто перемещать между реакторами, тем самым бессмысленно нагружая сервер. Для исправления ситуации надо постараться распределить ТВЭЛ'ы максимально равномерно. Когда-то у меня получилась такая схема: В реакторе одновременно работают 9-10 ТВЭЛ'ов. Чтобы не простаивал слот, освободившийся из-под ТВЭЛ, в него надо поместить горячий теплоотвод. Да и вообще, во всех охлаждающих слотах теплоотводы должны быть достаточно тёплыми, чтобы слоты приносили максимальную пользу. Также для снижения нагрузки можно не заменять теплоотводы вокруг ТВЭЛ, а вынуть сам ТВЭЛ, тогда смогут отдохнуть сразу несколько теплоотводов. Так мы решим сразу несколько проблем. Во-первых, упрощается логистика. Один реактор всегда удобнее, чем три. И ладно бы, ровно три, так тут два целых, и девять десятых. То есть, одна десятая часть реактора простаивала бы. Во-вторых, управляющей программе требуется выполнять меньше операций в единицу времени, что делает её более устойчивой. Такая программа с лёгкостью может управлять и несколькими реакторами без риска взрыва. В-третьих, минимизация нагрузки на сервер даёт надежду на то, что админы не запретят и эту схему тоже.

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

А где она есть, и где можно посмотреть её?

Это в какой версии так работает? Я года два назад проверял под 1.7.10 в industrialcraft-2-2.2.827-experimental.jar. Именно нагретые стержни невозможно было поместить в ЖЯР. Но можно было поместить нагретые теплообменники. Правда, они имеют не столь высокую теплоёмкость, поэтому их приходилось чаще перемещать между реакторами. Кстати, какую цель решает эта идея? Повысить выход энергии с ТВЭЛ? Да, это будет работать. Но мы-то сейчас обсуждаем схемы с максимальной мощностью. Именно они пользуются спросом у игроков на публичных серверах. Или два таких реактора в паре смогу выдать мощность больше, чем два раздельных реактора?

В Майнкрафте очень много всего грузит и лагает. Разве игроков это останавливает? Наоборот, игроки упрашивают админов установить на сервер очередной лагучий мод.

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

Жаль терять интересную механику. Я же правильно понимаю, что игроки с тех серверов являются главными потребителями наших разработок? Но нас это не должно останавливать. Схема на конденсаторах уже улучшена до предела. Вряд ли уже удастся придумать что-то новое. Если только код полировать. Но другие реакторные схемы также можно разгонять микроконтролем. Жидкостный реактор, думаю, станет ближайшим кандидатом на разгон. Вот где игроки захотят обмазаться трубами. Хотя, и здесь всё можно решить одними лишь компьютерами. @serafim, как думаешь, есть запрос на такое решение? Насколько я помню, микроконтроль ядерных реакторов на практике мы впервые пропихнули в ответ на запрос реализации какой-то стандартной схемы на конденсаторах. Там был довольно логичный и понятный переход. А в случае с ЖЯР, наверное, сначала потребуется вбросить идею, чтобы сформировался спрос. Как думаешь?

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

Админы, похоже, считают иначе.

@serafim Так это из-за реакторов был такой низкий TPS?

Подсказка: Каждый, кто программировал роботов-шахтёров с геосканером, знает о существовании блоков с необычным значением плотности.

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