eu_tomat

Ну точно же! Я зациклился на перемещении игрока, а его же можно исключить из этой схемы. Наверное. Надо проверять. Но да, начинать лучше с простых схем. И если на то пошло, то и врата не нужны. Можно же робота с чанклодером в чанк закатывать и выкатывать. В сингле этот 100% способ работает? Способ можешь пока не давать. Но и сам я допереть пока тоже не могу, т.к. не знаю особенностей Майнкрафта. Если только по наводящим вопросам пойму. Куда смотреть? И что там происходит с программной навигацией при откате чанка? Сбивается? Для этого мне придётся ещё и Java изучить. Это потом как-нибудь. Или кто-нибудь более опытный решится провернуть. А компы разве работают не в отдельном потоке?

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

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

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

Да, интересная механика. С ней даже самим маньякам было бы интереснее играть. А что-то подобное в каких-то модах уже реализовано? На данный момент, наверное, единственный. А правильным мне видится другой. Есть моды, которые поддерживают стабильность TPS за счёт переноса части вычислений на следующий тик. Но я не знаю, существуют ли подобные инструменты, ограничивающие вычисления внутри приватов, и переносящие вычисления в разбивке по приватам, или хотя бы по чанкам. Это позволило бы администраторам вообще не думать о содержимом приватов. Игрок бы сам думал, что ему нужнее, установить в приват десяток дробилок, один реактор, 20 кур, 200 солярок или спавнер с зомбями. А дополнительную нагрузку на сервер можно продавать за донат. По сути, мощности сервера это единственный товар, который имеет ценность. Каждому игровому слоту можно выделить какой-то небольшой объём бесплатных вычислений. Всё что свыше можно продавать. Цену можно изменять динамически, уменьшая её при низком онлайне или увеличивая при большом. В зависимости от текущего онлайна можно менять и бесплатные лимиты. Вот это была бы справедливая и полностью понятная система.

Вот, взял, и весь пафос сломал. Ну какой же это карго-культ? Карго-культ побуждает людей слепо копировать непонятные им процессы для достижения понятных им целей. Если игроки будут ожидать от робота, распечатанного на 3D-принтере, что он начнёт сеять пшеницу, то это карго-культ. Или, например, игрок скрафтит робота, установит OpenOS, откроет редактор программы и начнёт писать какой-то случайный текст, перемежая его ключевыми словами Lua и надеясь, что этот текст как-то заставит робота рубить деревья в округе, то это тоже может быть разновидностью карго-культа. Грань может быть довольно тонкой. Можно даже писать хорошие, интересные программы для Майнкрафта, но если человек ставил целью прокормить свою семью программированием, то и это будет карго-культом. Правильно. Потому что жанр написания операционных систем отличается от жанра обсуждения настроек сервера. И как только ты начинаешь чхать на потребности части своих пользователей, они чхают в ответ, чхают на обсуждение настроек, чхают на этот сервер. Наиболее эмоциональные даже могут прекратить выкладывать свои программки. Тоже чхают. Чем тебе не анафема?

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

А каким плагином управляются такие ограничения?

У дрона даже слота под инструмент нет. Если только через place() может, но там мало что работает.

А разве роботы умеют торговать NPС?

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

Ты знаешь, что я люблю: сохранение имеющихся механик в игре, если это не угрожает стабильности сервера. И со словами о занесении материальной пушки в чёрный список ты обратился именно ко мне. И раз тебе важно знать именно моё мнение, то я его предоставлю: оно есть у меня. Видел и не раз. Ты слишком близко к сердцу принимаешь эти вопли, т.к. сам топишь за то, что у игрока должен быть один универсальный робот со всеми возможными апргейдами на все случаи жизни. Реакция владельцев на потерю единственного и дорогого робота будет предсказуемой: пропало всё, нажитое непосильным трудом. Игроки же нашего сервера имеют замечательную возможность копать ресурсы роботами, возможность выполнять сложные крафты роботами, и при этом дешёвый робот-шахтёр окупает свою цену за 15 минут работы. Не смотря на наличие такой прекрасной альтернативы, никто не мешает игрокам копать ресурсы вручную, никто не мешает вручную крафтить, и никто не запрещает крафтить самых дорогих роботов. И тут вдруг неожиданно выясняется, что нужно помешать игроку уничтожить своего робота с помощью материальной пушки. Что поменялось в этом месте цепочки жизненного цикла робота? Игрок имеет право стрелять себе в ногу, падать в лаву и терять роботов по неосторожности. Да, пушечка кривая, и в руках робота годится только для его самоаннигиляции. Так это же и прекрасно: есть недокументированная возможность уничтожить своего робота. Очень эффективный способ. Мне нравится. И чтобы не возвращаться к теме демагогии, напоминаю, что всё это моё личное мнение, которое ты сам хотел услышать, и которое я не навязываю.

Нет, не понимаю. Пушка никому не мешала. Игру не крашила, сервер не залагивала, предметы не дюпала. Да, пушка работала неочевидным образом. Ну и пусть бы игроки своих роботов аннигилировали. Жалко что ли? У нас этого гуталина... Ты собираешься запретить всё, чем игрок может прострелить себе ногу? А с помощью OC вообще можно вызвать лаги сервера. Это, я понимаю, опасность. Но мы же живём как-то.

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

Казалось бы, благоденствие наступило. Но нет же, что-то должно ему помешать: Удивил! А как у нас дюпали каменные и деревяные кирки? Как они баговались? В чём проявлялась кривизна их работы? Очень интересно узнать.

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

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

А кому мешает бессмертие?

Идея избавиться от всех длинных цепочек вычислений оказалась верной. Моя модификация расширенного алгоритма Евклида выдаёт два целочисленных коэффициента (слегка модифицированные коэффициенты Безу), и для получения результата остаётся лишь разделить длинный интервал на целое число. Дополнительная погрешность возникает только при однократной операции деления вещественного числа на целочисленное. Итог: благодаря поиску минимального интервала через НОД удалось достичь заметного ускорения вычислений. Теперь результат часто находится за три сканирования, и очень редко требуется больше 10 сканирований. А ещё я не уверен, можно ли применять термин НОД применительно к вещественным числам. С другой стороны, последовательность целых чисел с единичным шагом является частным случаем математической прогрессии, которая может иметь произвольный шаг. Вот, и вся разница по идее-то. Есть у нас на форуме кто-то хорошо владеющий математической терминологией? Как правильно называть то, что я назвал наибольшим общим делителем?

Да, именно так, находим минимальное расстояние через НОД. И уже это, найденное через НОД расстояние считаем за минимальное, и проверяем соотношение максимальной разницы уже с ним. Максимум разницы я пока продолжаю искать традиционным способом. Я не уверен, что там уместны подобные трюки, и пока не занимался этим. Сейчас я пытаюсь решить другую проблему. Поиск НОД хорошо работает только для целых чисел, а константа шума не обязана быть целым числом. Пока я считал в scalc, где есть хорошая точность вычислений, всё было просто, понятно и наглядно, даже для константы шума с тысячным долями. А в Lua поиск НОД для вещественного числа пока что выдаёт нестабильные результаты. Сейчас я заменил алгоритм Евклида на его расширенную версию, доработав с целью минимизации накопления погрешности. Пришлось увеличить количество операций в коде, чтобы уменьшить количество операций в отдельно взятой цепочке вычислений. То есть, длинные цепочки каждый раз пересчитываются заново с использованием сокращённой записи. Погрешности пока ещё велики, но и не все вычисления я успел привести к оптимальному виду. Буду рад любым идеям, как прикрутить поиск НОД применительно к расстояниям между случайными значениями математической прогрессии вещественных чисел.

В данном случае это как раз-таки деление. Я не давал подробных пояснений именно к этой задаче, надеясь на то, что внимательно читавшие методику и сопровождающей её код, и так все поймут. Следом за этим абзацем идёт код, реализующий описанный алгоритм. Если моё описание методики в чём-то непонятно, то критикуйте, пожалуйста. Например, я мог опустить очевидные для себя вещи, где-то совершив слишком резкий логический переход. А для читателей это может быть и вовсе неочевидным. Просто спросите, а почему из того следует это. Я дам свой ответ, а позже внесу правки в описание. Или не внесу, чтобы не раздувать описание. Но вернёмся к задачкам. Описанный алгоритм был для меня актуальным в момент написания методики. Теперь его надо расширить, чтоб решать менее очевидные случаи, не требуя от геосканера новых данных. Для начала я поясню свои примеры: Первый пример: Вычисляем расстояния между всеми парами значений: {abs(10-12), abs(10-280), abs(12-280)} {2, 270, 268} min(2, 270, 268)=2 max(2, 270, 268)=270 max/min = 270/2 = 135 > 128 Задача решена: geolyzerNoise = min = 2 Во втором примере: {abs(10-18), abs(10-280), abs(18-280)} {8, 270, 262} min(8, 270, 268)=8 max(8, 270, 268)=270 max/min = 270/8 = 33.75 < 128 Задача не решается описанным алгоритмом, но небольшое усложнение вычислений обеспечит решение и этого примера тоже. А теперь я дам намёк на решение: Значения шума геосканера не случайны. Их всего 256. Расстояния между значениями равны. Всегда повторяется один фиксированный интервал. И какие бы два значения шума мы ни выбрали, расстояние между ними всегда будет кратно этому интервалу.

Нужен минимум и максимум не самих значений, а разниц между ними:

Я нашёл ещё один способ оптимизации алгоритма чисто математическими средствами. До этого я говорил, будто бы для полной гарантии решения задачи требуется найти минимальную и максимальную разницу между всем значениями, полученными от геосканера, а задача считалась решённой при условии max/min > 128. Взглянув на эту задачу под новым углом, я считаю, что это условие достаточно, но не является необходимым для решения задачи. Существует подход, обеспечивающий ещё более быструю сходимость к результату. Желающим размять мозги предлагаю два примера: Имеем массив значений: {10, 12, 280}. Условие (max/min>128) соблюдено. Константа шума равна 2. Имеем массив значений: {10, 18, 280}. Условие (max/min>128) не соблюдено, но существует решение и для этого случая тоже. Вопрос: как решить задачу во втором примере? Для решения достаточно знаний школьного курса математики. Другое дело, что это не типовая задача, скорее всего.

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

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