eu_tomat

У кого-нибудь есть объяснение такой математике? Турель делает почти полный оборот при перемещении между этими координатами: os_energyturret.moveTo(180.000007,0) os_energyturret.moveTo(180.000008,0)

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

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

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

1) r.detect() вызывается и в том и в другом случае, но результат проверяется лишь во втором, поэтому первый вызов бесполезен. 2) r.detect() внутри цикла не нужен в любом случае, а предложенная мною замена при проверке -- всего лишь более короткая форма записи, не влияющая на алгоритм работы. 4) Тут вопрос стоит так. Что будет быстрее? Сначала попытаться двигаться, а при неудаче сломать блок и еще раз попытаться, либо сначала не глядя сломать, а потом двигаться. В большинстве случаев путь робота-шахтера преграждают блоки. Поэтому даже если тратится время на неудачную добычу блока, в среднем по шахте это все равно будет быстрее, чем тратить время на неудачную попытку движения. P.S.: Поправлю свое сообщение, чтобы не путаться в двух пунктах с номером 3.

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

Первое, за что глаз зацепился: function forward() --Движение робота на 1 блок вперед if r.forward() then -- Если робот может сделать шаг return true -- то хорошо :-) else -- Иначе... repeat r.swing() -- бъет по объекту впереди r.detect() -- проверяет остался ли объект until r.detect() == false -- Если нет.. r.forward() -- то шаг вперед end end1) r.detect() внутри repeat/until совершенно бесполезен. Зачем его вызывать, если результат не проверяется?2) Конструция r.detect() == false заменяется более компактной not r.detect() 3) Ошибка: r.forward() сразу за repeat/until не проверяется на успешное действие, поэтому могут быть сбои в движении. Конечно, перед этим была проверка, но между проверкой и действием могли произойти изменения: гравий осыпался, новый моб появился и т.д. 4) r.forward() в самом начале функции работает крайне неэффективно. Полгода назад я рассказывал об этом Артему (artem211), когда он писал свой геокопатель. Тогда, наверное, во всех найденных мною на этом форуме копалках имелась такая неэффективность. Безуспешная попытка r.forward() занимает столько же времени на выполнение, как и успешное движение. Поэтому продвижение сквозь сплошной массив породы по такому алгоритму замедляет робота почти в два раза. Есть два выхода. Самый простой и выбранный Артемом – делать взмах киркой до попытки движения. Почему-то на неудачный взмах кирки время не тратилось. Сейчас может быть иначе, или потом может измениться. Второй вариант более надежный в будущем, но и сложный – анализировать второй параметр, возвращаемый r.detect().

Здравствуй, брат автоматизатор! Сегодня я расскажу тебе, как можно оптимизировать постройку рыбной фермы Asior'а. Если ты слишком слаб для чтения длинных текстов, ни в коем случае не открывай спойлер – для тебя есть несколько скриншотов с их кратким описанием. Но если ты хочешь узнать, как можно достичь такого результата, тебя ждет много текста с картинками, а в качестве бонуса — схема постройки сверхкомпактной масштабируемой фермы. Тема оптимизации сложна и обширна, но я не буду говорить о теории. Я покажу процесс оптимизации на практическом примере, как я делаю это сам. Сразу предупреждаю, что я не буду сильно вдаваться в объяснение механики игры, мода OpenComputers, или языка Lua. Всё это ты можешь узнать в блоке «Полезные ссылки» на главной странице проекта. Я скажу больше – без пользования этими ссылками, я бы даже этот текст не смог написать. Скажу еще больше – я дилетант и в MineCraft, и в Lua, и в OpenComputers. Но это не помешает мне оптимизировать схемы, постройки, алгоритмы и коды некоторых игроков. Итог В результате оптимизации получились две очень компактные и при этом красивые схемы, умещающиеся в объеме 3x5x3. Обе они радуют глаз, сохраняют место для прохода и строятся гораздо быстрее схем Asior'а. По моим тестам работают они не хуже исходных, а схема с нижним размещением робота теоретически может работать даже чуть быстрее, но для этого надо немного подправить задержку. Программу придется править в любом случае, т. к. изменилась сторона приема роботом сигнала и сброса дропа. Получение удочек из сундука следует выполнять контроллером инвентаря. [Схема №1] [Схема №2] Отличия построек незначительны. В первом не требуется тянуть редстоун, а робот может использовать для зарядки солнечную панель. Второй вариант может оказаться более быстрым, но для проверки этого придется переписать код, отвечающий за работу с датчиком. В остальном – одни недостатки: робот от солнечной панели не работает, редстоун дотягивается, но некрасиво, или же требуются провода RedLogic. И для компактного масштабирования потребуются цветные провода того же RedLogic. Кусок красного провода на правом столбе использован для симметрии блока воды, его можно заменить табличкой или стеклом. Место для зарядника имеется в обеих схемах, даже эстетика не сильно пострадает от его установки. Бонус Стать рыбным магнатом теперь стало проще. С незначительной доработкой схема легко масштабируется во всех измерениях, позволяя исключить смежные блоки и за счет этого в идеале получить ячейку с размером 1x4x3. Сколько их можно скрыть в одном чанке под землей, можешь сам посчитать. Но будь осторожен, брат: OKA следит за тобой и является органом, способным превратить твой приват в радиоактивный пепел. А теперь тесты! Устанавливай программу Asior'а, затем в зависимости от выбранной схемы настраивай в программе сторону, с которой расположен сигнал редстоуна, а также сундук для дропа. И получение удочек из того же сундука тоже придется написать. Главное, что интересовало в тестах меня: как часто происходят сбои заброса удочки, как часто вытягивается пустой крючок, и каков диапазон времени ожидания. Для этого придется добавить в программу соответствующие счетчики. Они помогут выявить неправильную работу либо программы, либо общей схемы. Может, крючок удочки за что-то цепляется. Может, дроп не доходит до инвентаря робота. Может, времени ожидания недостаточно. Что именно нужно изменить в программе, пока не скажу, и так уже много текста, но ты ж программист, брат! Может, и Asior что напишет, он шустрее меня. Не прощаюсь. Напоследок перефразирую Asior'а: Грызи знания, брат. В них сила.

Тебе ли не знать, познавший Матрицу. Желания – говорить ли об алгоритмах, или писать программы – не обязаны быть синфазными. Всему свое место и время.

Здравствуй, брат автоматизатор! Присаживайся на деревянный сундочок, да угощайся рыбкой жареной. И не забывай на поплавок поглядывать, он тебе многое расскажет о механике майнарафта и о том, как из этой механики извлечь выгоду для себя. Ты, конечно, знаешь уже, что Asior принес новую технологию в наш пустынный мир оверворлда. Да-да, пустынный – теперь ты в нем даже курицу не найдешь, намедни OKA отрапортовал об уничтожении последней фермы. Тяжело стало жить на сервере без белковой-то пищи. Мясо, конечно, можно и в магазине купить, но не каждый может себе позволить такую роскошь. А ходить в майно-миры на охоту тоже не всяк решится – и опасно и далеко. Можно, конечно, ловить рыбу прямо дома, в тазике, но ведь и удочку правильно держать – тоже не каждый умеет. Вот, и страдали мы, пока Asior не научил нас роботом рыбу ловить. Что тут скажешь: игрок спит, рыба ловится, а жизнь налаживается. Только вот, порыбачил я роботом Asior'а, восполнил недостаток фосфора в организме, и мне даже показалось, будто бы поумнел: стал я называть робота Asior'а глупым, а самому Asior'у начал советы давать. Даже чего-то лишнего сбрехнул, видимо, еще не наелся фосфору-то. Asior часть советов принял, но всё же где-то не удержался и сказал, что недостатки схемы – это проблемы игрока. Ну, и Fingercomp тоже поддержал его в этом. И другие тоже, насколько могли. А некоторые хуже того – текст не осилили, плакали горько. И решил я тогда на время отложить критику, да сам под критику встать и тексты писать покороче, если получится. А так как писать программы я не сильно хочу (разве только самую малость), то буду говорить о схемах и алгоритмах. Программы-то тут почти все пишут, но зачастую логика этих программ и общая схема работы меня весьма удивляют. Тексты буду складывать в этот блог, а вдохновляться – текстами форума, да простят меня их авторы. Вот, скажи мне, брат, в чем сила? В упоминании имени автора программы или его замалчивании?

Буду кртк. newbie: а что не так со спойлерами и скриншотами? Проверил, всё на месте. Fingercomp: поясни, пожалуйста, какие из моих придирок невозможны для выполнения? Я готов защитить любую из них. Всем, кому многабукафф: текст предназначался в основном автору идеи и программы, а также тем, кому интересны возможности улучшения системы, они прочитают всё. Текст конкретен и полностью соответствует заявленной теме. Остальным он не нужен, в этом соль. Вообще всем: Мне кажется, многих напрягло ощущение, сформулированное newbie: А что тут можно сделать? Ничего не предлагать автору, вопросов ему не задавать, а просто создать свой топик с лучшим механизмом? Но бывало уже такое на форуме, некоторые персонажи потом плакали, что у них украли идею. Украду. Asior, спасибо за идею! Остальным спасибо за критику критика.

Для первого раза реализацию можно назвать отличной. Но придирался я не для того, чтобы отобрать у автора Байт. Чисто объективно программа далека от идеала. И пишу я так много текста обычно в двух случаях, либо с желанием разгромить автора, либо с желанием помочь ему, и мне казалось, я ясно выразил свою доброжелательность. Если нет, извините граждане, постараюсь быть осторожнее. И зря ты говоришь, что придирки составляют большинство текста. Но придирки есть, не буду скрывать. Раз уж я начал писать, то написал обо всем, чего ожидал бы от отличной программы. Да и не хочу я размазывать все свои пожелания по куче постов. Было дело, Quant писал свой передатчик, а мне была интересна его тема, я был увлечен ею, но выдавал информацию постепенно. Теперь он что-то там улучшил, но что я тогда хотел сказать, уже смутно помню, и интереса к схеме уже нет. Ну, не печально ли? Нашел, чем гордиться. Разработчики 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 секунд он мне выдал: 'УРА! чего-то клюнуло ... или показалось...'. Клюнуло! На кирку, Карл! Даже если и показалось. Как такое вообще могло показаться?

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

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

О, да! Хороший совет. P.S.:Встретимся на рыбалке. Сейчас мне этот проект наиболее интересен. Планируешь доработку своей схемы и программы?

Приветствую, вас, браться по автоматизации! Не прошло и полугода, как я вновь вернулся к вам. Не буду загадывать, долго ли и активно ли я смогу веселиться с вами, т. к. многое изменилось с тех пор. Последнее, что я помню, это то, как Quant нехотя писал свою аналоговую связь, как artem221 только еще начинал крошить майно-миры своим геороботом, и как лагофилы боролись за свои права на автоматизацию модом AE2. Помню внезапно оживившие форум веселье одних и печаль других от робогрифа, насаждаемого тогда Алексом. Остальное помню смутно, не все темы мне интересны. А потом я неудачно сходил погулять. Поскользнулся, упал... сломал лодыжку. Сидя с загипсованной ногой, я пытался играть на сервере и немного обсуждал с Артемом его копалку. Помню, народ пытался наградить Алекса, и был даже примерен орден на его аватарку. И еще помню очередной надвигающийся вайп, да не простой, а с переселением VIP'ов в новый, чистый и никогда не лагающий и неумирающий мир. И тогда я начал напрягаться отсутствием у меня статуса программиста, и возможности переселиться в этот славный программистский безвайпный мир, но выяснилось, что просто достаточно быть в вайт-листе. И, успокоившись, я взял перерыв на пару недель. А потом, не зайдя в игру, еще на пару. А потом стало совсем не до игры. Единственное, что я не бросил – голосование за проект в ТОПах. Тем временем лодыжка срослась, я вновь освоил искусство ходьбы ногами, потом взялся за накопившиеся дела, а про майнкрафт с его компами вспомнил лишь в долгие темные новогодние вечера. Артем, как выяснилось, дописал свою копалку, и она оказалась весьма хороша. Код, конечно, дикий. Особенно я бомбанул, когда разбирал реализацию Артемом моей идеи замены апгрейда-карты. Уже тогда у меня начало просыпаться желание переписать этот кусок кода. Но новогодняя атмосфера это желание во мне подавила. Потом меня увлекли размышления о системе хранения и автокрафта на роботах, затем почему-то увлекли ядерные реакторы, хотя на IT-сервере я ни разу их не использовал, а потом вдруг заинтересовала свежая тема автоматической рыбалки, и тогда я вновь потянулся за паролем от аккаунта. Сегодняшний просмотр свежих тем уже не позволил мне воздержаться. Тут полный комплект: и наказание за робогриф, и обсуждение возврата AE2 , и даже Quant доработал-таки свою систему связи. И я включился.

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

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

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

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

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

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