eu_tomat

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

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

Теперь нет буквы "Ё" так как была путаница.

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

Неужели кто-то опять спрятал в бедроке мину с бесконечными циклами, рекурсией и потоками?

А за что был отключен Inventory Binder? Поиск по форуму выдает только эту тему.

Zer0Galaxy, великолепно. Когда прямого решения нет, на помощь приходит статистика.

Как видно во втором случае при округлении захватывается одна единичка мантиссы, которая и приводит к кардинально другому результату.   Результат: 180.000007 d -> 180.0 f 180.000008 d -> 180.00002 f   Т.е. числа становятся по разную сторону от значения 180. Ну а алгоритм турели в OpenSecurity таков, что не дает ей проходить отметку 180 градусов. Об этов вроде где-то выше qwertyMAN писал. =)

Про 180 градусов всё было понятно, сам игрался с турелью. Неожиданным было такое округление. А округление оказалось приведением. Теперь понятен фокус, спасибо.

 

Прав qwertyMAN, дурацкое ограничение на проход через 180 градусов, так еще и реализовано криво.

У кого-нибудь есть объяснение такой математике? Турель делает почти полный оборот при перемещении между этими координатами:

os_energyturret.moveTo(180.000007,0)

os_energyturret.moveTo(180.000008,0)

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

Krutoy в своем репертуаре. Сервер еще от крутых черепашек как следует не оправился. А теперь еще и крутые турели будут. Но мои мысли тоже идут к этому. 1) Каждой турели свой сектор; 2) Стрелять на опережение с учетом скорости игрока и заряда; 3) Даже если турель не успела довернуться, но уже успела остыть, может иметь смысл неприцельная стрельба для деморализации противника. Пущай попляшет. Может, на нервах сам под огонь попадет.

И не забудь, что кроме r.forward() у тебя еще есть r.up() и r.down(). С ними надо работать аналогично, чтобы робот не сбивался с пути.

Я провел эксперимент. Внес в код счетчик, сколько раз робот будет "врезаться" во что-то, а потом пытаться убрать это с пути. Итог получился забавный: за всю шахту он "споткнулся" только один раз и то об меня, когда я свалился к нему.

Одно из двух: либо робот бродил в пустоте (повторно в той же шахте, или в пещере), либо счетчик что-то не то считает. Ищи ошибку.

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

Сейчас перепроверил на свежей версии мода: при копке массива земли голой рукой ускорение в 1.5 раза, и в два – иридиевым буром. При проходе пустоты замедление на 10%.

Не знаю, правильно ли вызывать функцию в этой же функции, но всё работает и теперь проверяется.

Функцию из той же функции вызывать очень даже можно, и прием этот называется рекурсией. Иногда незаменимый и крайне эффективный, но в данном случае он дает только лишнее потребление памяти. А у тебя одна планка T-1.5. Код, конечно, рабочий, но он монструозный и тяжело воспринимается даже с комментариями, да и требует много места в памяти, а тут еще и рекурсия. Поэтому настоятельно советую: избавляйся от рекурсии. Готовое решение давать не буду, простые циклы ты освоил, а большего и не требуется.

1) Результат проверяется в until r.detect() == false. Здесь он вызывается, а ниже проверяется. Или я чего-то не так понял?

2) Если я заменю, можно убрать "r.detect() -- проверяет остался ли объект"?

3) Логично. Надо подумать, как красиво исправить.

3) В смысле 4) Функция forward() служит исключительно для движения вперед, т.к. не всегда нужно копать перед собой. Если нужно что-то вскопать, это прописывается перед ее вызовом. Но раз там тратится столько времени, r.detect() действительно будет эффективнее.

1) r.detect() вызывается и в том и в другом случае, но результат проверяется лишь во втором, поэтому первый вызов бесполезен.

2) r.detect() внутри цикла не нужен в любом случае, а предложенная мною замена при проверке -- всего лишь более короткая форма записи, не влияющая на алгоритм работы.

4) Тут вопрос стоит так. Что будет быстрее? Сначала попытаться двигаться, а при неудаче сломать блок и еще раз попытаться, либо сначала не глядя сломать, а потом двигаться. В большинстве случаев путь робота-шахтера преграждают блоки. Поэтому даже если тратится время на неудачную добычу блока, в среднем по шахте это все равно будет быстрее, чем тратить время на неудачную попытку движения.

 

P.S.: Поправлю свое сообщение, чтобы не путаться в двух пунктах с номером 3.

Первое что робот спрашивает - это какая у шахты будет ширина. Т.е. это размер второстепенных тоннелей. Мин. значение - 2. Если ввести некорректное значение (<2) или не ввести вовсе, то робот примет значение по умолчанию равное 2.

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

Первое, за что глаз зацепился:

function forward() --Движение робота на 1 блок вперед
  if r.forward() then -- Если робот может сделать шаг
    return true -- то хорошо :-)
  else  -- Иначе...
    repeat
      r.swing() -- бъет по объекту впереди
      r.detect() -- проверяет остался ли объект
    until r.detect() == false -- Если нет..
    r.forward() -- то шаг вперед
  end
end

1) r.detect() внутри repeat/until совершенно бесполезен. Зачем его вызывать, если результат не проверяется?

2) Конструция r.detect() == false заменяется более компактной not r.detect()

3) Ошибка: r.forward() сразу за repeat/until не проверяется на успешное действие, поэтому могут быть сбои в движении. Конечно, перед этим была проверка, но между проверкой и действием могли произойти изменения: гравий осыпался, новый моб появился и т.д.

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

Есть два выхода. Самый простой и выбранный Артемом – делать взмах киркой до попытки движения. Почему-то на неудачный взмах кирки время не тратилось. Сейчас может быть иначе, или потом может измениться. Второй вариант более надежный в будущем, но и сложный – анализировать второй параметр, возвращаемый r.detect().

Буду кртк.

 

newbie: а что не так со спойлерами и скриншотами? Проверил, всё на месте.

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

 

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

 

Вообще всем: Мне кажется, многих напрягло ощущение, сформулированное newbie:

но тема называется не "Как построить ферму в пару блоков которая будет суперэфективной", а просто "Робот рыбак"

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

 

Украду. Asior, спасибо за идею! Остальным спасибо за критику критика.

А я наоборот считаю, что реализация отличная, а большинство текста — просто придирки мелкие. Некоторые даже не особо нужные или невозможные для выполнения. Ну и корректировку делаем на первую публичную программу =))

Для первого раза реализацию можно назвать отличной. Но придирался я не для того, чтобы отобрать у автора Байт. Чисто объективно программа далека от идеала. И пишу я так много текста обычно в двух случаях, либо с желанием разгромить автора, либо с желанием помочь ему, и мне казалось, я ясно выразил свою доброжелательность. Если нет, извините граждане, постараюсь быть осторожнее. И зря ты говоришь, что придирки составляют большинство текста. Но придирки есть, не буду скрывать. Раз уж я начал писать, то написал обо всем, чего ожидал бы от отличной программы. Да и не хочу я размазывать все свои пожелания по куче постов. Было дело, Quant писал свой передатчик, а мне была интересна его тема, я был увлечен ею, но выдавал информацию постепенно. Теперь он что-то там улучшил, но что я тогда хотел сказать, уже смутно помню, и интереса к схеме уже нет. Ну, не печально ли?

 

Я вот сам не пишу в проги обрабатывание ошибок, например, как и какую-то пеленастость для юзера, если не графический интерфейс. Всё-таки ничего не поломается на экране от этого, а лишние 5 строчек стэктрейса никому не вредили. А мне особенно — не люблю, когда в программах, которые мне иногда надо дебажить, ошибка короткая, непонятная или отсутствует совсем (в открытом логе). Благо ещё, есть дебаггеры. Ну и ещё от автокрафта, который постоянно баговал, тоже такое мнение сложилось.

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

Нашел, чем гордиться. Разработчики MS тоже, видимо, так считали – несколько BSOD'ов не повредят пользователю.

А ты, быстро ответил, Asior. У меня все эти вопросы несколько дней нарабатывались, еще до того, как я включился в проект. На некоторые из них ты ответил излишне поспешно, о них-то я хочу поговорить подробнее. И текста будет еще больше.

 

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

 

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

 

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

 

Вот, например, зачем нам проверять, удочку ли дал игрок роботу или другой инструмент? Игрок может по запарке не тот инструмент в слот кинуть. И что делает робот? Ловит рыбу киркой. Ну, не дурак ли он? Можно сказать, что дураком является игрок. Но игрок просто ошибся, а робот сообщает радостное «УРА» без реальных причин, исключительно по истечению таймаута в своем примитивном мозгу. Я не зря так много говорил о работе датчика: в первую очередь от него зависит «интеллект» твоего робота. Правильное использование датчика позволит тебе не ловить рыбу на кусок урана часами напролет, а довольно быстро сообщить об этом игроку всё тем же писком.

 

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

 

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

 

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

 

Про определение размера инвентаря тебе уже Fingercomp ответил, а про съемные компоненты ответил он же в другой теме

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

 

Здесь я процитирую сам себя: Почему при поломке инструмента в случае отсутствия контроллера инвентаря происходит выход из программы, зато при отсутствии удочек в сундуке робот пищит, но настойчиво пытается вытащить удочку еще раз?

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

 

Сейчас заглянул в свежую редакцию программы. В ней робот без контроллера инвентаря тупо ждет 10 секунд, хотя можно было бы показывать обратный отсчет, и завершать ожидание досрочно. Более того, к моменту включения программы в руке робота уже могла быть вложена удочка (или кирка), тогда зачем ждать?

 

Впервые слышишь, что робот скидывает удочку вниз? Правильно делаешь. Каюсь. Это я уже упоролся в кактус. Тупо не обратил внимания на переменную err, и весь бессмысленный ритуал протекал в моем разыгравшемся воображении. Слаб я пока в чтении чужих программ, буду перепроверять в игре прежде, чем делать такие заявления.

Кстати, название переменной err совершенно не отражает ее назначения. И вообще, было бы лучше избавиться от нее, и просто присваивать nil переменной incontrol. Заодно и немного памяти робота сэкономится.

 

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

 

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

 

Тут, конечно, проблема не только программы, но и общей схемы. Как по мне, так воронки вовсе не нужны, лучше поставить сундук впритык к роботу. Если есть время и желание, сравни схемы с воронками и без них. Или я потом сам проверю. У меня все-таки есть впечатление, что воронки работают не тогда, когда «рыба с крючка срывается», а когда инвентарь робота переполнен. Но в твоей схеме такая ситуация не должна возникать.

 

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

 

И еще раз повторюсь: я вообще не вижу смысла в двух сундуках. Достаточно одного и для удочек и для дропа. Робот без контроллера все равно не умеет менять удочку, а робот с контроллером может достать любой нужный ему предмет из сундука.

 

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

 

А-а-а-а! Не покажу. Я не умею картинки вставлять. Сейчас погуглю.

 

Upd:

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

 

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

 

 

 

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

 

 

 

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

Asior, классная идея! Я и не знал до твоего поста, что положение поплавка можно детектировать. Теперь весь сервер рыбой завалим. Но сейчас вопросики, как червячки полезут.

 

Для начала про роботов:

* Не раскрыто, зачем нужны улучшения первому роботу. Я, конечно, догадался, но не сразу. Зачем этот квест?

* Конфигурация второго робота – вообще дичь дичайшая. Какое отношение к теме имеют геолайзер, апгрейд полета, вай-фай и отсылки к программе Артема/Дуба?. Зачем этот мусор? Ты еще сенсорный замок Totoro припомни. И этот, как его там, OpenCloud, будь он прекрасен.

 

Вопросы по постройке и схеме работы:

* Зачем нити натянуты аж в три ряда?

* Зачем вообще такой огромный водоем? Нельзя ли ловить рыбу из одного блока воды, с одной натянутой нитью и с гораздо более скромным размером всей конструкции?

* Работают ли воронки, как заявлено, и нужны ли они вообще? У меня рыба не сорвалась ни разу. Я заставил робота складывать дроп в верхний сундук. Нижний остался пустым после нескольких сотен забросов.

* Что не так с проводами из RedLogic? Я их использовал, глюков нет. Бывает, при погружении поплавка не срабатывает сам датчик, но это не проблема проводов, т. к. датчик даже не щелкает. Изредка бывает наоборот, датчик щелкает без погружения поплавка. Но дело опять же, не в проводах. С красной пылью все аналогично. Возможно, это проблема проявляется именно в твоей конструкции.

* Ты рассматривал другие направления заброса удочки? Вот, у меня оказалось, что если бросать сверху вниз, то датчик не срабатывает. А если бросать снизу вверх (рыбак-подводник), то датчик срабатывает гораздо быстрее, чем при броске вперед. Профит? Только требуется редстоун вниз от датчика дотянуть. При броске вперед редстоун тянуть вообще не надо, в этом свой плюс.

* Зачем нужны два сундука? Если на старте игры робот не имеет контроллера инвентаря, то он не может и сломанную удочку заменить. А если уже имеет и может, то сможет и достать удочку из сундука, содержащего любые другие предметы.

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

* Почему бы не пускать в дело и выловленные палки и нити, учитывая, что в роботе второго уровня достаточно свободных слотов для апгрейда крафта? И тогда почему бы крафтом не ремонтировать поломанные удочки с халявным добавлением 5% прочности?.

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

* И зачем тогда вообще крафтить удочки и класть их в сундук, когда проще кинуть туда палки и нити, сэкономив и время на крафт и место в сундуке?

 

Вопросы по программе:

* Почему проверку правильности состояния датчика ты делаешь в конце, а не в начале функции ловли? Ты забрасываешь (или все-таки вытаскиваешь) удочку, ждешь три секунды в надежде, что датчик сработал правильно, потом ждешь еще 80 секунд до таймаута, вытаскиваешь (или забрасываешь) удочку, ждешь две секунды и в случае, если выясняется, что поплавок заброшен, вытягиваешь его. При этом в первом случае ты ждешь срабатывания датчика три секунды, а во втором – две. В чем разница?

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

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

* Не приводят ли эти небрежности кода к тому, что время от времени происходит вытягивание удочки вместо забрасывания и наоборот?

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

* Почему ты инициализацию переменной называешь инициализацией устройства? С каких пор проверка наличия устройства стала называться его инициализацией? И, кстати, учитывая то, что ты пихаешь апгрейды и карты в слоты расширения, то может оказаться, что в момент проверки они были на месте, а в следующий момент использования их уже не будет. Твоя программа будет удивлена.

* Зачем задаешь фиксированное количество слотов, в то время как его можно узнать программно, гибко подстраиваясь под возможности имеющегося робота? И почему наличие контроллера инвентаря ты проверяешь, но наличие апргейда самого инвентаря сомнению не подвергаешь?

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

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

* И что будет делать робот, когда переполнится сундук? Он остановит свою работу, впадет в пищащий цикл или все-таки продолжит закидывать и изнашивать удочку?

* Почему робот не сбрасывает злостный хлам типа нестакающихся пузырьков с водой? Он сначала сундук забьет хламом и поломанными удочками, а потом на холостом ходу сломает все найденные (скорее всего, новые) удочки. Хламом могут оказаться и другие вещи, желательно иметь настраиваемый список.

 

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

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

 

Напоследок вопрос ко всем: Как заставить робота собирать сферы опыта? Сферы разбросаны по округе, tractor_beam всасывает только предметы.

 

Upd: Если датчик не реагирует на заброс удочки, может оказаться, что проблема вовсе не в датчике, в том, что в руке робота лежит не удочка. Без апргейда инвентаря он может об этом и не знать, но почему-то не пытается определить, что возникла проблема. С апргейдом он проверяет, что именно смог взять из верхнего сундука, но почему-то не проверяет, что у него было в руке изначально. Я сейчас роботу-рыболову кирку в руки дал, и через 80 секунд он мне выдал: 'УРА! чего-то клюнуло ... или показалось...'.

Клюнуло! На кирку, Карл! Даже если и показалось. Как такое вообще могло показаться?

component.<имя компонента>.slot)

Спасибо, все работает.

1) Может ли робот получить доступ к component.openperipheral_sensor через адаптер или только через компьютеры и контроллеры?

2) Можно ли определить, как подключены внутренние компоненты, вставлены ли они при сборке, либо в слоты расширения?

Нужна подсказка, или сначала выложишь новую версию?

Тебе php код кинуть?

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

Эта тема мне напоминает, как на КК я сделал черепашку-архиватор. В общем, используя блок шерсти как пол байта черепаха строила столбы с закодированным сообщением, бессмысленно, но работает!

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

Обновил,используются все силы сигнала.

Хорошо, теперь должно работать. Но не всегда.

Если ты еще не утратил интерес к задаче, я постараюсь помочь сделать ее решение лучше. Будем продолжать?

Написал, написал. Я лично видел.

Видел сам, покажи другим.

Где код?

Статистику я собрал и понял, что любое сообщение приходит моментально, а сжатие и рендер отнимают непозволительно много времени, особенно когда изображение только начало отрисовываться, а уже понятно, что надо сменить ракурс.   Мой вывод - сжатие не необходимость, а понты, вроде шифрования, когда есть modem.send

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

Теперь другая проблема, стоит вообще сжимать?

Если главное торможение возникает при отрисовке сцены, изображение можно вообще не сжимать. Предлагаю схему: посылаем первый ряд символов, и пока они отрисовываются, пересылаем последующие. Компрессия-декомпрессия в этом случае только создаст лишнюю нагрузку на сервер.

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

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