Doob

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

В фазе охлаждения энергия не генерируется

Значит схема в мусорку. Я ведь говорю, что реактор с адаптивным алгоритмом ни одной секунды не будет простаивать, эффективность всегда 7, просто в фазе охлаждения на 1-2 стержня меньше, следовательно, и энергии немного меньше.

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

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

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

И получаем лагодром. В семи корпусах слишком много слотов, на 2-3 такое сгодится, если схема действительно эффективная.

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

Задачу можно решить, оперируя лишь математикой и логикой школьного уровня.

Да, но зачем? Вкл/выкл это не эффективно. А нормальный алгоритм на ~700 шагов писать ручкамии это как-то фу. Динамическое программирование избавляет от лишней писанины, алгоритм просто решает поставленную задачу любыми доступными средствами.

Попробовал в оптимизацию руками, цель - максимальная эффективность и выхлоп энергии.

Получается, что алгоритм будет сначала разгонять реактор с максимум EU/t, потом выкидывает стержни и охлаждает корпус, затем опять докидывает стержней. Выходит, что с ураном эффективность будет на одном уровне, а энергия пилообразно скакать от 140 EU/t до максимума. А вот с MOX наоборот, эффективность сильно прыгает, при слабом колебании напряжения.

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

Можно не страдать над алгоритмом. Если переложить задачу на язык машинного обучения, то она сразу решится (т. к. цикл реактора статический). Только тут надо писать эмулятор, либо его подобие, чтобы удобно было зарешать.

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

без OC оно не буде работать от слова совсем, теплоотводы израсходываются примерно за 3 секунды

Чтойта? 3 секунды это прорва времени, воронка с фильтром не осилит поменять теплоотвод?

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

Если же пускать стержень по кольцу из реакторов, то тепловыделение можно свести в ноль, а энергию из стержня выжимать в 10 раз быстрей (в пределе)

Делал хранилище на умных трубах, всяко умнее "умных воронок".

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

Зато не требуется постоянно стучать по сундукам, не надо ставить по компу на транспозер, система включается, отрабатывает команду и выключается моментально (максимально возможная цепочка занимает 12 тиков)

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

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

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

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

Получается, что ограничение в 8192 eu/t проявляет себя не всегда.

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

@yura0138 реактор может выдать максимум 8192 EU/t.

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

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

Потом можно приступить к писанине.

Делаем скрин поля "Лвл", сохраняем картинку.

При запуске программы надо найти расположение ключевой точки.

import pyautogui

key_point = pyautogui.locateOnScreen('Лвл.png')

Координаты левого верхнего пикселя хранятся в key_point.left и key_point.top

От них надо считать отступ до чисел (координаты рамки, ширина, высота), которые сохранены в картинках.

Далее, вырезаем прямоугольник

img = pyautogui.screenshot(region=(X, Y, W, H))

Где X,Y это координаты, а W и H - размеры рамки.

Потом можно просто получить строковое представление этого кропа и проверить по ключу в словаре.

images[img.tobytes()] >= const

Собственно, словарь сначала так и заполняем - открываем картинки и кидаем в словарь.

from PIL import Image

images = {}

images[Image.open('50.png').tobytes()] = 50

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

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

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

Я представляю алгоритм так:

• Найти на скрине "Лвл".
• Вырезать прямоугольник 35x15 на 45 пикселей ниже.
• Вычислить хеш этого изображения.
• Сравнить с сохраненными.
• По результату сравнения, кликнуть на нужную кнопку.

Если сляпать нейронку, то и разбивать ничего не надо, тупо обучить и написать скрипт в три строчки: скрин > предикт > клик

Без контекста не очень понятно, в чем состоит задача.

На питоне всякую автоматизацию легко стряпать, в PyAutoGUI из коробки есть поиск изображений, мышеводство, клавиатура. Правда там какие-то траблы с виндой, а вот OpenCV + mouse точно работает на любой системе.

Я не спорю, но пароль больше 4 символов не влезает. Если есть возможность включить комп, то на подбор пароля уйдет 20-30 минут, а с учетом артефактов сжатия, можно и за 5.

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

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

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

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

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

На память не смотрел, компы работают как и работали. Хотя, может и падали иногда, не помню уже.

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

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

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

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

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

Не знаю, где читал про механику нулевых чанков, нашел только это https://minecraft.gamepedia.com/Spawn_chunk

Тут написано, что и как тикает https://minecraft.gamepedia.com/Chunk#start_ticket

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

Есть ведь механизмы, которые удаленно грузят чанки, вроде звездных врат, с ними никуда ездить не надо.

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

Есть 100% способ дюпать чанк на любой сборке модов или ванили, но я этот способ не дам, у вас документов нету. Способ гениально прост, до него может допереть кто угодно.

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

54 минуты назад, Pengoid сказал:

Какие блоки имеют плотности 30, 22.5 и 1.25?

Древние обломки, эндерсундук, обожженная глина/базальт.

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

Я поленился такое проделать. Надеялся, что есть способ попроще.

Если мод есть на гитхабе, то можно посмотреть там. Иначе - ставим комблоком/дебагой блок на геосканер, проверяем и удаляем, выходит по 3 тика на блок.

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

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

Вопрос: существует ли возможность сравнительно простыми манипуляциями вытащить таблицу плотностей всех имеющихся блоков в конкретной сборке модов?

Встречный вопрос: зачем?

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

Вот возможные плотности для последнего майна:

50 30 22.5 10 5 4 3 2.8 2.5 2 1.8 1.5 1.4 1.25 1 0.8 0.75 0.6 0.5 0.4 0.3 0.2 0.1

Нестандартные видел только в Galacticraft:

6 2.2 0.9

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

Тут штука в том, что при обратной операции восстанавливается дискретность 256 значений, а мы их по модулю 1 грохаем в ноль.

Взять пример @eu_tomat,  (1.295 - 3) / 30 / 2 * 128 * 33 = -120, как раз одно из возможных значений.

Если подставим плотность 1.5, то получим -14.4, что совсем не годится.

Все оказалось очень просто, впрочем, как и все гениальное.

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

Вот как легко и без лишней памяти классифицировать блок:

Берем результат работы геосканера R, известную твердость блока H, расстояние до блока D, множитель шума из конфига N, подставляем это в следующую формулу:

(R - H) / D / N * 128 * 33 % 1

Если результат не равен нулю, то это искомый блок.

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

Остается сократить половину формулы, чтобы делать меньше вычислений и получаем функцию, которая отсекает шум примерно на 99.31%

Ура, товарищи!

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

я перестал понимать твои визуализации в двух последних постах. Я на них ничего не вижу.

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

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

Если добавить точно известную руду по максимуму камня (math.max(3 - R * 0.606, 1.5 + R * 0.06013)), тогда получаем вот такое:

Вероятность попадания по руде вырастает до 70.695%

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

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

И теперь посмотри, чем эти значения друг от друга отличаются. Конкретно в моей задаче. А потом задайся вопросом, почему одно из них сильно вероятнее другого.

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

Область пересечения занимает 7377 точек, при том, что реально пересекаются только 492. Итого, надо хранить 6845 точек.

Точность получаем таким образом: имеем 444210 возможных значений для руды или камня, из них уникальных - 8224, следовательно 6845/8224 = 83.232%, если бы мы гадали по чему-то одному. Если же просто исключать камень по таблице, то точность будет 99.89%

Пока поищу способ, разделить с такой же точностью, но без таблицы.

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

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

Есть такая штука, называется уровень инструмента, но могут быть еще дополнительные условия в коде игры/мода.

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

EEPROM прошитый?