eu_tomat

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

Ты меня так скоро запутаешь, и я перестану понимать, кто из них Дуб, а что – дюп. Дуб говорил про дюп чанка: Я же говорил про дюп роботов, а также исчезновение роботов, которые могут произойти при откате чанка. Механизм представляется мне таким: чанк по какой-то причине не сохранился, и при очередной попытке загрузить чанк восстанавливается его предыдущее состояние до изменений в чанке. Это я называю откатом. А произойдёт ли там дюп, это уже дело десятое. Например, ты сломал в чанке робота, но при следующей загрузке чанка робот остался стоять на месте, и теперь у тебя два робота, у которых компоненты имеют одинаковые адреса. Это можно назвать дюпом. А может и не быть никакого дюпа, если ты поставил робота, но при следующей загрузке чанка робот пропал. И в связи с этим я задался вопросом: может ли возникнуть ситуация, когда ничего ни дюпалось, ничего не пропадало, но робот успел сменить свою позицию, запомнить её, но из-за отката чанка эта позиция перестала соответствовать действительности? Вычисления же OC происходят в отдельном потоке. И состояния компов хранятся отдельно от чанков. Вот, в чём трагизм, Нео – Матрица скрывает от нас правду. А я в этой теме хочу научиться обнаруживать сбои в Матрице, чтобы быть готовым к неожиданностям. Но продолжим исследование: А как это сделать? Какой-такой командой? Да, я помню эту тему. Жаль, её автор не проявил настойчивости в поисках причин проблемы. Я тоже не понимаю, как такое возможно даже с учётом отката чанка. Зато могу представить, как может при откате чанка сбиться программная навигация.

@Xytabich Расскажи, откуда и как ты выковырял эту информацию.

Вдохновившись иллюстрацией, я отодвинул тестовую установку более чем на 50 чанков от точки спавна – с большим запасом, как мне казалось. Но это всё равно не помогло. Включенный чанклодер всё равно случайным образом загружает чанки за пределами области 3x3 чанка с собою в центре – будто то чанклодер робота, или же мировой якорь RailCraft. Грузить чанк с управляемым чанклодером оказалось лучше всего самим игроком. На данный момент это самая прозрачная схема. Можно было бы и с промежуточными роботами нагородить схему, но тогда было бы непонятно, какой из роботов первым загрузил целевой чанк – последний в цепочке, или какие-то из предыдущих. В общем, как измерять задержку, непонятно. С другой стороны, а нужно ли нам знать задержку при загруке чанка, учитывая, что время его выгрузки нами всё равно неуправляемо? Я около 10 раз включил чанклодер и выключил его следующим же тиком. При этом целевой чанк мог проработать от 11 до 45 секунд. На каком тике произошла выгрузка, и что в чанке успело произойти, а что не успело, точно неизвестно, связь с выгруженным чанком пропала. По косвенным признакам мы, конечно, можем моделировать более-менее точные предположения. Но какое количество тиков будет пропущено при следующей загрузке чанка, какие действия будут пропущены, можно сказать только после экспериментов. Например, я опытным путём установил, что при каждой выгрузке-загрузке чанка MFSU недополучает энергию за один тик. Является ли причиной потери энергии откат чанка – совсем не факт. Скорее всего, это вообще не так. И смогу ли я воспроизвести откат чанка, как это делает @Doob, пока не знаю. Вот ещё интересный момент вспомнился. Во время моих перемещений по варпам на сервере у меня не только пропадали свежеустановленные роботы. Ещё и клиент часто отлетал от сервера из-за каких-то ошибок. А это случалось заметно чаще пропажи роботов. И причиной откатов могли оказаться как раз те самые ошибки, а не банальные выгрузки-загрузки чанков. И это может означать, что отката чанка я этими манипуляциями не добьюсь, и никаких сбоев в программной навигации не обнаружу. И, наверное, лучшее, что я могу придумать: построить домик где-нибудь не очень далеко от спавна, и не очень близко к нему, чтобы пробегающие мимо игроки загружали мои чанки и выгружали. А в домике поставить детектор, регистрирующий возникающие артефакты времени. А ещё могу поставить такой же детектор где-нибудь на своём варпе в шахтёрском мире. И наиболее тщательно проверять логи этого детектора после потерь связи с сервером, если такие потери случатся. А в сингле мне остаётся, пожалуй, провести ещё один эксперимент, но на его успех нет никакой надежды. Предчувствую, снова получится, что программная навигация абсолютно надёжна при аккуратной реализации. @Doob Ты что-то говорил про гарантированный способ добиться отката чанка. Что при этом у тебя происходит с программной навигацией? Состояние памяти компьютеров тоже синхронно откатывается?

Что такое Чокола?

Проблема блуждающей загрузки чанков, похоже, не в OC. Мировой якорь из RailCraft ведёт себя точно также. Чанклодер периодически подгружает чанк, не смежный ему. Можно предположить, что границы чанков неверные, но я разместил целевой компьютер и чанклодер на расстоянии 47 блоков, если считать расстояние между их центрами. Их чанки никак не могут быть смежными. Похоже, такова механика самого Майнкрафта. Подскажите, знатоки Майнкрафта, верно ли моё предположение? Идея грузить некоторые чанки игроком выглядит не такой плохой после этого эксперимента. При манипуляциях игроком я не заметил артефактов течения времени, которые бы указывали на неожиданную выгрузку или загрузку чанка. Артефакты есть, но это обычные микролаги, которые не замечаются большинством игроков. Ещё у меня возник вопрос к знатокам Майкрафта. Я разместил свою экспериментальную установку на расстоянии 9 чанков от точки спавна. Также я знаю, что какое-то количество чанков в районе спавна остаётся всегда загруженным. Вопросы: Каков размер этой всегда загруженной области? Чем он задаётся, от чего зависит? Должны ли чанки, находящиеся рядом со спавном быть всегда загруженными или всегда выгруженными, или же там тоже возможны случайные загрузки и выгрузки даже при стоящем на месте игроке? С другой стороны, близость спавна вроде бы не должна влиять на этот эффект, т.к. при выключенных чанклодерах проблема блуждающей загрузки чанков у меня ни разу не проявилась. Или всё-таки может влиять?

У меня есть такая идея: игроком надо прогружать чанк, в котором находится робот с чанклоадером, но не соседний, где будет находиться тестовый робот. Тогда сигнал гарантированно будет доходить. Да, хорошая идея, и я уже воплотил её в немного ином виде. В момент написания того поста я считал, что чанклодер OC загружает область 1x1 чанк. Вроде бы так и было раньше. Не знаю, когда это изменилось. Но один из проведённых мной экспериментов показал, что чанклодер OC загружает область 3x3, чему я позже нашёл подтверждение и в коде OC. Поэтому озвученная мной проблема потеряла свою актуальность, и вместо игрока я стал использовать ещё одного неуправляемого робота с чанклодером, который постоянно держит загруженным чанк с управляемым роботом. А от загрузки чанков игроком я в своих экспериментах решил пока отказаться, чтобы не усложнять интерпретацию результатов, и без того неожиданных. Мой эксперимент выглядел так. На границе чанка установлен компьютер с целевым скриптом. В 16 блоках от него в другом чанке стоит робот с управляемым чанклодером, а 16 блоках от него (и в 32 блоках от целевого) стоит неуправляемый робот с постоянно включенным чанклодером, который служит для постоянной загрузи чанка с управляемым роботом. Это практически предложенная тобой схема, в которой вместо игрока задействован ещё один робот. Игроку остаётся лишь отбежать подальше и с планшета подавать сигналы управляемому роботу на включение и выключение чанклодера. Именно в ходе того эксперимента мной и был обнаружен эффект блуждающей загрузки чанка, который по моему разумению вообще не должен был входить в зону загрузки неуправляемого чанклодера. Я сначала думал, что виноват управляемый робот, который по каким-то причинам не хочет отключать чанклодер. В конечном итоге я вообще удалил его с карты, тогда и оказалось, что управляемый робот вообще не при чём. К эксперименту с двумя чакнлодерами я планирую вернуться позже с немного другой расстановкой роботов по чанкам. Но сначала хочу ещё немного поиграть с блуждающей загрузкой чанков.

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

Ещё один эксперимент с неожиданными результатами. Вплотную к границе чанка стоит компьютер с целевым скриптом. Скрипт детектирует странности течения времени в чанке и записывает их в файл. Также в файл периодически пишется текущее время, чтобы понимать, работает ли целевой скрипт в данный момент. Обновлённые данные файла отображаются в реальном времени средствами операционной системы хоста. На расстоянии 32 блока от целевого компа находится робот с включенным чанклодером. Между роботом и целевым компьютером есть свободный чанк. Границы чанков проверялись нажатием клавиши F9. При удалении игрока на достаточную дистанцию целевой скрипт должен полностью остановить свою работу. Но скрипт работу продолжает. Можно было бы предположить, чтобы я неправильно определил границы чанков. Теоретически, два блока на расстоянии друг от друга в 32 блока могут находиться в соседних чанках. В этом случае целевой чанк должен всегда оставаться загруженным. Но нет же, скрипт время от времени свою работу прерывает. Размер паузы похож на случайный от единиц до десятков секунд. Если откатить робота с чанклодером ещё на шаг назад, то целевой скрипт гарантированно прекращает свою работу. В этой позиции вопросов не возникает. Но что было до этого? Что это за чанк Шрёдингера, который то выгружается, то снова загружается с какой-то случайной задержкой?

Я тоже сделал подобное предположение, но для меня не очевидна логика, которой руководствовался автор. А ещё я не смог найти участок кода, который бы приводил к подобным результатам. Не подскажешь, как его найти? За счёт чего чанклодер загружает область 3x3 чанка, я вижу. А за счёт какого кода он загружает чанки заранее, до того как робот пересёк границу чанка?

До основного эксперимента я не дошёл. Зато я попытался проверить, на каком расстоянии будет действовать чанклодер из OC. Результаты меня удивили, объяснения им не вижу. Прошу помощи в интерпретации. Сразу выяснилось, что чанклодер OC загружает область 3x3 чанка. Это подтверждается и кодом OC. Но дальше начались странности. Я проверил, как далеко следует отвести робота с чанклодером, чтобы он перестал загружать целевой чанк. Робот был установлен рядом с границей чанка, поэтому ему было достаточно сделать один шаг назад, чтобы перестать подгружать чанк, находящийся перед ним. Но не тут-то было. Для полной гарантии потребовалось 16 шагов. То есть, робот перешёл не просто границу чанка, а подошёл к следующей границе. И пока я не могу объяснить такое поведение чанклодера. Затем я решил проверить момент включения тестового робота в целевом чанке при приближении к чанку робота с чанклодером. Оказалось, что робота можно приблизить всего на 8 шагов, чтобы целевой чанк загрузился. При этом робот даже не дошёл до границы чанка, а целевой чанк уже загрузился. Так можно было несколько раз двигать роботом туда и обратно на 8 шагов и каждый раз целевой чанк загружался и выгружался. Но так длилось не долго. Позже этого количества шагов оказалось недостаточно. Но оказалось достаточно 12 шагов. И после одного выбегания на 12 шагов снова оказалось возможным выбегать всего на 8 шагов. И целевой чанк загружался на короткое время. Правда, в какой-то момент оказалось, что недостаточно и 12 шагов. В общем, игрался я так, и в конечном итоге роботу с чанклодером пришлось проделать весь путь в 16 шагов, чтобы загрузить целевой чанк. С чем связано такое поведение чанклодера? По идее-то роботу с чанклодером достаточно было просто преодолеть границу чанков, чтобы целевой чанк встал в очередь на выгрузку или загрузку. Или, например, всегда бы требовалось 16 шагов назад для выгрузки и 16 шагов вперёд для загрузки чанка, это я бы тоже смог как-то понять. Но разному количеству шагов робота, необходимых для загрузки чанка, я не вижу объяснения.

Я не встречал полного описания. Для проверки наличия драйверов для того или иного мода я просто устанавливал адаптер рядом с интересующими меня блоками. В плане коллективного знания возможности этого мода почти не изучены. Например, я узнал о возможности получать информацию о жёрдочках IC2 с помощью OpenPeripheral ещё в 20015-ом. Подозреваю, что об этом я узнал не один я, но Гугл по фразе "ic2 tecrop" до сих пор не выводит ничего похожего на запрашиваемую информацию.

Через цикл без всяких getAllStacks, как в коде @Xytabich.

С OpenPeripheral даже полный перебор 108 слотов аламазного сундука если не моментален, то очень быстр, на весь цикл уходит менее тика. Точнее я не замерял.

Проблема в том, что я не знаю, какие моды и плагины имеют значение. Может, они наоборот нужны для провокации отката чанка. Хотя, @Doob говорит, что значения это вообще не имеет.

Опять 25. Может, и надо мне тоже погрузиться в жаву. Как там, трудно вникать? Думаю, за день я установлю какую-то среду, настрою, и под конец дня смогу даже что-то заговнокодить консольное. Синтаксис Java мне в целом понятен, а нюансы я могу и позже освоить. С этим я разберусь. Но там для программирования в Майнкрафте там нужна ещё куча всего, и вот тут для меня начнётся вообще тёмный лес. Можешь набросать какой-то гайдик, с чего начать и чем продолжать? Или ссылки какие-нибудь. Я не сомневаюсь, что в потрохах Майнкрафта тоже всё жутко интересно, но я пока не знаю с чего начинать, и сколько времени на это придётся потратить. Ты про какую проблему? То, что роботы на сервере пропадают? Да, подтверждаю. То, что роботы дюпаются, тоже есть свидетели. Примерная ситуация известна. И её надо научиться воспроизводить. Вон, @Doob говорит, что умеет. Далее надо зафиксировать рассинхронизацию программной навиагации с положением робота в чанке. Я тоже попробую поработать над этим. Как смогу, конечно.

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

Я уже начал терять цель, к которой ты пытаешься подвести. В чём твоё предложение?

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

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

Это идея @hohserg , он хочет управлять загрузкой чанка с точностью до тика. Я же пока не готов погружаться в Java.

Оперативку-то я не жрал же.

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

Да, адаптер работает через драйверы OpenPeripheral, и чтение произвольного слота происходит очень быстро. Транспозер же на каждое обращение тратит по одному тику. И для ускорения программы обычно используется метод, возвращающий сразу всю таблицу содержимого сундука: component.transposer.getAllStacks(side).

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