eu_tomat

С библиотеками для роботов вообще беда. Именно взаимодействие с миром наиболее затратно по времени, а каждый алгоритм оптимален в рамках ограниченного круга задач. Библиотека, работающая в широком диапазоне условий, как правило, громоздка и сложна в управлении. Вот, взять, к примеру, даже список функций твоей библиотеки. Он уже сейчас выглядит сложным, и программист предпочтёт отказаться от использования библиотеки и написать свой вариант кэширования, оптимально встроенный в его программу. Да это происходит сплошь и рядом даже с простенькими библиотеками типа программной навигации. Это касательно сложности использования библиотеки. Громоздкость библиотек тоже имеет значение. Многие стремятся удешевить роботов, выкинув лишние планки памяти и даже диски, используя загрузку по сети. А универсальные библиотеки почти всегда громоздки. Рассмотрю различия условий оптимизации на примере уже упомянутой навигации. Простой робот-шахтёр обычно движется по кратчайшему маршруту лицом вперед, прорубая себе дорогу. В редких случаях роботу нужен дополнительный алгоритм обхода препятствий или даже выхода из лабиринта, если робот закопался в породу, слишком прочную для его инструмента. Для шахтёра, копающего по данным геосканера, требуется алгоритм построения оптимального маршрута для добычи всех руд. Его алгоритм обхода препятствий отличается тем, что часть препятствий известна до начала движения. А для робота, разносящего ресурсы по обрабатывающим машинкам, требуется минимизировать количество поворотов, при случае использовать движение задом, ни в коем случае не ломать обнаруженные препятствия и даже не пытаться обходить их. Вроде бы все алгоритмы решают задачу навигации, но мне кажется бессмысленным оформлять их в виде единой библиотеки. Аналогично, для робота, добывающего руду, фармящего скелетов в подвале, или стоящего под воронкой, нужен один алгоритм кэширования инвентаря. Робот, сортирующий ресурсы в системе сундуков или снабжающий перерабатывающие машинки, вообще может изначально всё учитывать в памяти. А для робота, с инвентарем которого взаимодействует игрок, кэширование поможет гарантированно различать лишь типы предметов, да максимальный размер их стака. Я пришёл к выводу, что на computercraft.ru из библиотек для роботов наиболее полезны те, что содержат минимум кода без избыточных структур данных и интерфейсов, и демонстрируют какой-то интересный подход в решении привычных для роботов задач. Надежда на то, что кто-то использует библиотеку в своей программе, не велика. Зато при описанном выше подходе многие из читателей смогут разобраться в коде и оценить красоту алгоритма, что повысит шансы на обсуждение и генерацию новых идей. Предлагаю рассмотреть именно это направление. Но это IMHO, конечно. Если бы я всё-таки решился писать полноценную библиотеку кэширования инвентаря, то в первую очередь свёл бы к минимуму количество публичных методов, чтобы не смущать пользователя. В идеале хотелось бы один раз задать режим работы инвентаря, а дальше только выдавать пользователю информацию. В любом случае тема даже с бесполезной библиотекой, но полезной идеей поможет некоторым задуматься об оптимизации действий роботов, что уже само по себе замечательно.

Точно. Сам не знаю, куда смотрел.

Хеллоу all, читающий этот comment. В русском языке too few слов для раскрытия этой темы, поэтому приходится заимствовать английские words. Возникли some вопросы: if compt.inventory_controller == nil then error("inventory_controller not found") endА разве component позволяет такой способ проверки? Насколько я помню, ошибка случится ещё на первой строке этого фрагмента. Для этого даже component.isAvailable придумали. Можешь пояснить, что обрабатывается в перехваченных proxy.dropIntoSlot и proxy.suckFromSlot? proxy.dropIntoSlot = function(facing, slot, count) if count == nil and self.isPotential(slot) then self.removePotentialSlot(slot) item.setSlot(slot, nil) else local item = self.getSlot(slot) if item.size == count then self.setSlot(slot, nil) else item.size = item.size - count end end return nativeDropIntoSlot(facing, slot, count) endКакой инвентарь анализируется в этом участке кода? Вряд ли инвентарь робота, т.к. номер слота в данном случае не имеет к нему отношения. И вряд ли какой-либо внешний инвентарь, т.к. не учитывается сторона, с которой находится инвентарь. А ещё интересно узнать, почему ты отказался от проверки count==nil и результатов, возвращаемых оригинальными proxy.dropIntoSlot и proxy.suckFromSlot. Разве такой отказ не может привести к рассинхронизации кэша?

Конечно, видел. Вопрос про аккуратный выход как раз соответствует уровню программы. Так мне кажется.

Так и тема не о перекладывании кубиков, а о программировании. Так что, смысл вполне объективный. А так это уже стало особой разновидностью местного спорта – рассказывать друг другу, насколько бессмысленна игра в Майнкрафт, как он уже всем надоел, и что программировать в Майнкрафте уже нечего, и всё уже написано.

Смысл может быть в получении опыта, например.

Так обработка Ctrl+Alt+C и реализована программно, но средствами операционной системы. Может быть, os.exit() комильфо?

Ctrl+ALt+C обычно помогает.

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

О чём здесь вообще идёт речь? Что за сервер не клиент-сервер? Что вообще этот сервер делает? Скриншоты чего? Каких экранов? Местоположения чего? Что еще за игровое качество? О каком тепловизоре идёт речь?

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

Кто мы-то? Мы ж не маги. Мы ж программисты.

Точно. Разнообразнее, азартнее, веселее. И охотники за головами будут чем-то полезным заняты. А вдохновившись обещанным Эль Хефе вознаграждением, охотники вообще могут начать жестко конкурировать друг с другом за голову несчастного Альфредо Гарсиа. В такой заварушке точно пригодится весь топовый шмот и системы электронной локации и оповещения.

1. Зачем приводить полную цитату при том, что сообщение к этой цитате никак не относится? 2. Ни у кого нет 100500 чанклодеров, чтобы за них переживать. 3. Сервера открываются и закрываются, а голосование остаётся. Голосование – неявная форма доната, и участник, приносящий пользу серверу, достоин вознаграждения. 4. Все голоса @newbie получены на его единственный аккаунт форума. Дополнительные аккаунты в VK находятся вне юрисдикции computercraft.ru.

Точно. Иметь какой-то предмет в Майнкрафте гораздо интереснее, чем циферки на счету. К тому же, роботов можно нагрузить дополнительными обязанностями по размену банкнот, что радует еще больше. Про несколько варпов я позабыл. И если овер будет огромным, то несколько варпов обеспечат серьезные шансы на уклонение от бандитов. А если еще и жизни будут продаваться за UU недорого, тогда преследователь скорее сам утомится погоней, нежели ощутимо осложнит жизнь своей жертве. В общем, годная идея: роботы становятся более востребованными, UU без особого напряжения тратятся – всё это на пользу серверу. Ограничение количества жизней поддерживаю.

Стоп! В этой теме обсуждается один из способов обмена товарами, а не условия для возникновения глобальной экономики на сервере. Вопрос возможности экономики обсуждается в теме Экономика в Minecraft: миф или реальность? Там же обсуждаются условия, при которых экономика становится возможной. Пожалуй, самая важная мысль из всей темы:

Довольно интересная идея, способная обогатить игру. И роль робототехники заметно возрастает. Но мне не ясен один момент: А будет ли у игроков на Эвиле возможность отключить PvP в других мирах кроме улья? Новичок со временем может приспособиться даже к самым суровым формам PvE, пусть, и потеряв половину из доступных жизней. А вот, против развитых игроков, которые целенаправленно охотятся за другими игроками, новичку противопоставить обычно нечего. Отключение PvP сильно облегчило бы жизнь слабому игроку. Понятно, что есть множество других способов убийства, но они требуют более творческого подхода, чем вырубание жертвы с нескольких ударов, и вносят разнообразие в игру.

Чеки в торговом моде NEO – прекрасная штука, но деньги, которые можно перекрафтить в требуемый номинал – удобнее, как по мне. С точки зрения экономики деньга, основанная на алмазе, от этого самого алмаза не отличается. Просто добавляется удобство масштабирования. Хочешь, копеечный тростник покупай, а хочешь – дорогущую квантовую панель. Далее. Сервера загибались не по причинам затрудненного обмена ресурсами между пользователями. Проблему обмена не решит ни введение валют, ни добавление торгового мода, т.к. сам Майн не способствует специализации игроков. И, как ты сам говорил, игроки не любят покупать товар, но зато любят его продавать и копить циферки на своих счетах. А если вспомнить, что при ограниченной эмиссии деньги дорожают просто по мере развития сервера, и их выгоднее хранить в сундуке, чем пускать в оборот, то склонные к накоплению игроки и подавно ничего не купят за эти деньги. С алмазной (и любой натуральной) валютой эти трудности будут компенсироваться. Ну, будет алмаз сильно переоцененным. Но, во-первых, алмазы постоянно добываются в постоянной пропорции с другими ресурсами. А во-вторых, любой владелец UU сможет приобрести алмазы в админшопе, а затем по выгодному курсу обменять их на любые нужные ему ресурсы у других игроков. По мере развития сервера это будет выгоднее покупки ресурсов непосредственно за UU. Такой перекос в покупке алмазов за UU тоже отчасти скомпенсирует их переоцененность. И, кстати, таким образом появляется гибкая привязка игровой валюты к UU. Что продажа самих денег за UU, что алмазов – существенной разницы это не имеет.

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

Это лучший вариант, на мой взгляд. За основу берётся один (и только один) ресурс, и обеспечивается его свободная конвертация в деньги и обратно. Будет ли это алмаз или железный слиток, уже не столь существенно. Такой способ эмиссии может приводить к скачкам цен в зависимости от того, предпочитают ли игроки в тот или иной период времени добывать ресурсы в шахте или просто стоять в AFK. Деньги, привязанные к ресурсу, гораздо более стабильны. Вроде бы хорошая идея, позволить игроку самому решать, что ему нужно для выживания. Но на вновь открывшемся сервере проблемой будет то, что даже при наличии «стартового капитала» приобрести товары будет попросту не у кого. Среди первых поселенцев преимущество получат имеющие запас UU, что в принципе справедливо, но китстарт им никак не поможет. Поэтому пусть, наверное, все получают стандартный набор, как раньше. Дефляция не лучше инфляции. По мере увеличения количества добытых ресурсов деньги будут дорожать, а товары на рынке станут мусором. Основанная на таких деньгах экономика остановится. Зато относительная цена, например, алмазов и золота более стабильна на протяжении игры, поэтому цена товаров, выраженная в деньгах, привязанных к конкретному ресурсу, ведёт себя более предсказуемо.

Это ни коим образом не влияет на работоспособность вирусов для OpenComputers. Просто кому-то хотелось поговорить, у кого какая система, от чего одиноко, и решает ли вайн проблему одиночества.

Пфхахаха! Действительно, а что это мы. Нам лишь бы про Lua, да OpenComputers флудить. Да еще и про ComputerCraft иногда. Для выставления времени в винде не нужен скрипт. Находишь в интернете какой-нибудь NTP-сервер, да прописываешь его в настройках. Да и наверняка какой-нибудь time.windows.com уже прописан, осталось только галочку поставить для синхронизации.

Представить сложно, но ТС хочет получить (цитата) "реальное московское время", не уточнив, правда, насколько оно должно быть близким к реальному. Одного игрока устроит погрешность и в одну-две минуты, а какой-то маньяк будет пытаться довести ее до хотя бы 200ms. Это первый нюанс, создающий почву для дискуссии о методах получения времени и создаваемой при этом нагрузки. Второй нюанс в том, что игровые сервера бывают разные, и на каких-то из них ход часов может быть пущен на самотек, вынуждая игроков обращаться к внешним серверам и писать своё подобие ntpd. Если при этом серверное время еще иногда и корректируется рывками, то тут остаётся лишь постоянно долбить внешние сервера, пока те не забанят. Или придется снизить требования точности. Вычисление времени через разницу computer.uptimeочень эффективно, но, к сожалению, чувствительно к рестартам игрового сервера и выгрузке чанков. Время от времени придётся сверяться с другими источниками. Интервал сверки определяется точностью, на которую игрок нацелен. Интересная информация. Надо будет как-нибудь стресс-тест прогнать. Согласен, трудно найти что-то лучше. Для логирования событий на сервере Майнкрафта этот способ вне конкуренции. А если на сервере уже есть вменяемая синхронизация времени, то и для остальных целей тоже – лучший способ. Но, как говорилось, дьявол кроется в деталях. Игроки и сервера бывают разные. Рядовой игрок Майнкрафта не знает, какой способ синхронизации часов сервера выбрал админ, как сильно часы будут отставать или убегать и какие рывки они совершат в будущем. Как и админ не знает заранее, насколько часто любителей точного времени будут дёргать файловую систему, и сколько их окажется на сервере в одном интервале времени.

OC-Minecarts – интересный модик. И после экспериментов с ним у меня возник вопрос. Редстоун-карта как первого, так и второго уровней без проблем помещается в компьютерную вагонетку – как при сборке, так и в контейнер для плат. Но компонент redstone почему-то отсутствует, игнорируя наличие красной платы в вагонетке. Это баг или фича?

А откуда взялся такой странный делитель? fs.lastModified("/tmp/.time") / 1002.7Разве не на 1000 нужно делить?