eu_tomat

По моим расчётам за минуту поменьше вышло: 25,677. Вообще, рекомендую запомнить схему "ход конём", она часто выручает в Майнкрафте. При таком расположении один рабочий блок контактирует с четырьмя обрабатываемыми. Лучшего результата не достичь на плоскости. А дальше я такое заполнение двигал по слотам вверх-вниз, существует всего пять вариантов. А дальше уже вручную заполнял пустые слоты, там всё очевидно и легко. Знание эффективных способов заполнения полей помогает экономить время. Upd: Вспомнил свои попытки применить эту схему на сборке RoboCraft2, была у нас такая. Так у меня оптоволокно взрывалось от напряжения. И, если верно помню, то и MFSU тоже взрывался. Так что, нужен ещё и энергохранитель, способный безопасно усвоить энергию.

Я нашёл схему. Производительность 4280 eu/t на урановых сборках или 21398.288 eu/t на MOX при разогреве до 0.9999.

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

Максимум выработки энергии, которого мне удавалось достичь за счёт микроконтроля компонентов ЯР — 21398 EU/t в непрерывном режиме. Конечно же, это MOX при разогреве до 99.99%, плюс отражатели. Скорее всего, это абсолютный рекорд выработки энергии на одном реакторе. Если интересно, схему найду, но полной рабочей программы у меня никогда не было, т.к. я использовал несколько тестовых скриптов, запускаемых в интерпретаторе Lua для проверки работоспособности идей микроконтроля. Один скрипт грел реактор до 99.99%. Второй синхронизировался с тиками реактора, длящимися 1 секунду. А третий заменял подгоревшие конденсаторы и сломанные отражатели без останова реактора. Схема тестировалась без восстановления конденсаторов, просто с сундуком, забитым свежими конденсаторами и отражателями. Не знаю, может ли моя схема работать на сервере при снижении TPS, но в сингле она работала чётко и стержни выжигала полностью. Реактор обсчитывает своё состояние один раз в секунду, и что происходит между моментами этих вычислений, совершенно не важно для реактора. Поэтому компоненты могут отсутствовать в реакторе большую часть времени. Но сильно рисковать я не пытался, менял не более одного компонента в секунду, такой скорости более чем достаточно, а лишняя суета может повредить. Также я заметил, что даже в сингле и при достаточности ресурсов компьютера тики изменения состояния реактора иногда смещаются на один тик относительно синхронно работающего скрипта. Абсолютной синхронизации нет, реактор меняет своё состояние каждый 19-21 тик. Но для работы скрипта этого временного зазора всё равно хватает. Вообще, микроконтроль реакторов позволяет строить и другие, казалось бы, невероятные схемы. Не обязательно ограничивать себя одной лишь подзарядкой конденсаторов. Например, для меня основной целью была замена менее полезных компонентов реактора более полезными, что позволило выжать из классического реактора на уране 558 eu/t. Также появляется почти читерская возможность с одной и той же сборки ТВЭЛ утилизировать как электрическую энергию в классическом ЯР, так и тепловую в ЖЯР, что заметно снижает потребность игрока в уране. Так что, у ядерных экстремалов ещё есть способы развлечься на связке IC-OC.

@Doob, где ты берёшь информацию о Майнкрафте? У меня не хватает времени, чтобы всё это отслеживать. Может, где-то есть удобный структурированный источник?

Верно. Надо считать. И подобрать баланс таким, чтобы новый геосканер был дорогим, но в то же время более удобным и даже более выгодным по энергии на небольших расстояниях. Но на больших расстояниях игрок должен делать выбор: выбросить гигаджоули энергии на сканирование или же, рискнув, подойти поближе и энергию сэкономить. В одних случаях безопасным будет сканировать вражескую базу за километр, питаясь от нескольких стационарных ядерных реакторов. В других выгодным окажется ставить зарядник и, подзаряжаясь от него, сканировать области среднего размера. А в третьих выгодным будет в постоянном движении сканировать относительно малые области. Впрочем, эти малые области будут крупнее, нежели сканирует твой дубокоп на ванильном геосканере. Это позволит задействовать весь спектр тактик и сделает игру интереснее. Твои планы я всецело поддерживаю. Пусть будут эти прекрасные аддоны, имбалансные по отношению к другим модам. Главное, не нарушать баланс внтури OC. Пусть новые тактики не закрывают использования старых. Ясное дело, на поздних стадиях развития часть ванильных тактик исчерпает себя, но на ранних они останутся востребованными. Отлично. Я предлагаю на ранних стадиях развития играть дефолтными роботами, плавно наращивая мощности и на протяжении всей игры фармя ресурсы на новые апгрейды. В идеале линейка возможных апргейдов должна быть очень длинной и трудно достижимой. Апгрейды от уровня к уровню должны плавно наращивать некоторую характеристику при экспоненциальном росте цены апгрейда. На этом поле можно много чего придумать, начиная от апргейдов генерации и хранения энергии. Желательно расходовать какое-то топливо, те же урановые стержни, к примеру. Также можно придумать какие-нибудь ускорители роботов, с плавным ускорением со стандартных восьми (можно даже с начальных двадцати) тиков на одно движение вплоть до одного тика на шаг робота. Но с экспоненциальным ростом энергозатрат. Главное, чтобы вся эта имба достигалось с трудом, постепенно, а ванильные слабенькие роботы были доступны почти на старте. При таком раскладе я не вижу опасностей, и если и буду что-то критиковать, то уже менее значительные детали баланса.

Так от усложнения программы стоимость дрона тоже не изменится.

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

Видимо, командой control, если всё сделано по инструкции:

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

Чтобы не было имбой, пусть энергопотребление растёт пропорционально четвёртой степени расстояния. И вообще, можно настраивать в конфиге множитель и степень, чтобы считать по формуле energy = k*distance^exp.

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

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

Фанаты Forestry то же самое говорят о дроноферме=)

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

Судя по всему, система загружена с дискеты. Надо установить систему на жёсткий диск командой install и загрузиться с него. После этого уже можно скачивать прошивку.

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

Не магия. Просто у воронки есть права на высасывание предметов из робота. А роботу прав не дали.

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

Работает. Но теперь время сломано:

Похоже на автоколебания около целевой точки. Если я верно понял этот код, дрон не остановится никогда:

А как применить PID регулятор в условиях, когда есть возможность получить лишь длины векторов смещения и скорости? Направления же векторов скорости и ускорения могут и не совпадать. Кроме того в формулах присутствует нелинейность из-за ограничения максимального значения скорости. Можно повторить физику движений дрона на Lua. Это позволит на каждом тике знать вектор скорости и точное положение дрона.

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

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

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