eu_tomat

Вопрос был не о свинье, а об автоматизации. И не о роли воображения, а о смысле виртуализации в и без того уже виртуальном мире.

А разве передатчик никогда не выдает единицу? Хотя, нет. Спрошу иначе. Почему твой передатчик никогда не выдает единицу?

Синтаксис Lua не вызывает вопросов. Главный вопрос - зачем. Кстати, в коде присутствует еще один странный момент. Приведу краткую выдержку и добавлю свою комментарии. Предполагаю, что дело здесь в неправильном использовании числового типа, но я хочу понять, как ты пришел к такому решению, т.к. есть в этом коде что-то очень неправильное. -- в цикле передатчика: l = l - 10^(n-1) -- в цикле приемника: l = l +10^ (r.getInput(s.left)-1) if r.getInput(s.left)==1 then l=l+1-0.1 -- зачем ты что-то добавляешь к результату? -- вывод результата приемника print((l-l%10)/10) -- зачем делишь его на 10?Upd: Погуглил числовой тип в Lua. Четырнадцать девяток вообще не должны вызывать какого-либо переполнения. Так что, я не понимаю происходящее в коде. Присутствуют как минимум три странности:1) Какое-то деление результата на 10; 2) Добавление к результату 0.9 в тех циклах, когда уже было добавлено 1.0, т.е. 9 раз; 3) Добавление к результату 0.1 во всех циклах, т.е. в твоем случае 14*9 раз. Quant, ты хотя бы проверял работу своего кода? Что выводил приемник?

Хороший результат, ты близок к успеху, но есть возможность передать твое число в 20 раз быстрее. Почему ты не захотел разложить число в пятнадцатеричный ряд и вместо синхронизирующего нуля передать что-нибудь более ценное? И еще проясни смысл вот этой строки в конце принимающей части print((l-l%10)/10)

О, как! Сошлись две противоборствующие стихии: одна удушает нас клубком труб из AE, а другая не оставляет нам ничего кроме чистого космоса и единственной дебаг-карты. Ты правильно сделал, взяв фразу "побыть инженером" в кавычки, потому что будучи настоящим инженером ты бы не городил сложных и запутанных схем на основе работающего на магии AE, а собрал бы простую и эффективную на основе прозрачно работающих компьютеров. Кстати, AE2 был усложнен специально, т. к. первый оказался слишком скучным. Но похожая на реальную сложность логистики была заменена надуманной сложностью ограничения каналов в кабеле. Но не следует говорить, что это сложный мод, т.к. все его сложности преодолимы чтением вики и аккуратной расстановкой блоков, выливающейся в конечном итоге в сложные и запутанные схемы. Doob, похоже, понял, что подобные схемы автоматизации являются тупиком, но ушел в другую крайность, где инженерия становится бессмысленной. Злобный движок форума не дает добавлять цитаты даже следующим сообщением. Напишу иначе. Doob: Автокрафт у меня есть, рецепты забивать лень. Если тебе лень забивать рецепты, то о каком автокрафте ты говоришь? Doob: Я, к примеру, специализируюсь на селекции, если кто-нибудь может мне сказать, как робот будет анализировать семена, то можно сделать автоматическую ферму селекции. А мне интересно, почему на сервере, где во главу угла поставлена автоматизация, ты выбрал для себя принципиально неавтоматизируемую специализацию? Кстати, способ автоматизации есть, но не на этом сервере. Doob: почему все думают, что это виртуализация? … Представьте, что предметы отправляются в какое-то реальное хранилище, реальные устройства при помощи Ender технологий, просто к ним нет физического доступа, т.к. они находятся в другом мире. Если единственным способом увидеть хранилище является включение воображения, то такое хранилище виртуально. А для того, чтобы просто не видеть реальное хранилище, достаточно в него не заходить и не строить его. Твой робот сам построит комнату для склада, разместит в ней сундуки, и по мере необходимости будет увеличивать их количество и выполнять их апргейды. Ты не видишь склад, а он есть. Но при желании ты всегда можешь его увидеть в отличие от виртуального. А так ты начал с виртуального склада, добавил виртуальный крафт, для которого тебе пока еще лень забивать рецепты, потом добавишь виртуальные печки, которые сами переплавят руду, добавишь виртуальную селекцию, окончания которой нужно просто подождать, добавишь виртуальных шахтеров, которым не требуется куда-либо ехать за рудой. Но всё это уже есть! В креативе. Просто, когда будешь брать нужную машину из NEI, представь, что в другом измерении трудится реальный шахтер, он добыл руду, кинул ее в дробилку-очищалку-плавилку, скрафтил для тебя машинку, и теперь ты держишь ее в руках. Хотя, постой! Зачем тебе эта машинка, когда у тебя давно уже есть целый завод в другом измерении? И зачем тебе броня, если тебе даже из дома выходить не требуется? Зачем тебе майнкрафт, если можно играть в своем воображении? Просто представь, что у тебя уже всё есть.

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

Не нравится AE? AlexCC давно уже показал альтернативу: сундуки + робот. Сердцем системы будет таблица крафтов, но она потребуется в любом случае. Еще нужно будет помнить, что и в каком сундуке лежит, но для робота это не будет проблемой. Покупать и продавать предметы, не прыгая до банка — читерство. Любая виртуализация логистики — зло для игрока. Система транспортировки в AE — тоже скучная. Делать свою AE на дебаг-карте — еще большее зло. В чем тогда будет прелесть игры? Обмен товарами "как в реальном мире" — интересная идея, но при чем тут дебаг-карта? И, кстати, на чем на таком "своем" может специализироваться игрок? Выращивание картошки? Так едой любой игрок сам себя обеспечивает. Давно уже написаны шахтеры, лесорубы и фермеры. Качай программу, устанавливай на робота и забудь о любой зависимости от любого товара. Сельхозпродукция в майнкрафте почти сразу становится мусором. Как только ты построишь приличного робота-шахтера, мусором становятся и руды тоже. Тебе скучно быть фермером? Есть решение — нескучный робот-фермер. Тебе скучно строить помещение под ферму? Есть решение — нескучный робот-строитель. Все равно скучно? Напиши веселого робота-кладовщика.

Какая интересная и живая тема, а у меня как раз инета не было. Попробую ответить сразу на все соображения по решению этой задачи. В каких единицах измеряется скорость? 1000 чего? Алгоритм кодирования очень странный: передатчик разделяет число на слагаемые, а приемник суммирует. О какой производительности тут можно говорить? Тут уже предлагали разделить число на пятнадцатеричные разряды, такой подход значительно сократит длину передачи. Скорость можно дополнительно увеличить в два раза, избавившись от бессмысленной передачи нуля. Зачем передавать ноль, когда можно передать полезную информацию? Использовать два и более сигнальных провода — тупиковый путь. При таком подходе проводов всегда будет мало. Использование дополнительных проводов оправдано только в случае полного использования пропускной способности одного. Рассказ про шину на компараторах тут интересен только в контексте двоичного кодирования, но в данном случае более оптимальным будет использование пятнадцатеричного. Код Грея вообще не приносит пользы в решении этой задачи, он полезен только в реальном мире и только для двоичных кодов. Кстати, не следует идеализировать реальный мир. В майнкрафте есть лаги, зато в реальном мире к лагам добавляются шумы и потери сигнала. И без коррекции ошибок там никак не обходится кроме простейших случаев. Предложение реализовать UART мне нравится, но не следует делать утверждений о том, что все способы цифровой передачи сводятся к отсутствию или наличию сигнала. Для понимания этого достаточно ознакомиться со способами кодирования сигнала в модемах. Не погружаясь в детали, скажу, что сигнал имеет несколько состояний, и их количество значительно больше двух. Не принимать их во внимание — значит неэффективно использовать особенности среды передачи данных Резюмирую. Передача по связке кабелей банальна, UART тоже скучноват, передача данных по одному редстоун-каналу с его 16-ю состояниями выглядит весьма интереной, и в текущем решении потенциал редстоуна совсем не раскрыт. А его раскрытие мне кажется увлекательным. Конечно, для начала и UART сойдет. Но 16 уровней сигнала против двух — это совсем другие возможности.

Просто интересно: А зачем копалкам нужен командный блок?

Хороший подход. Перед сном по чайной ложке знаний каждый день.

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

Я в замешательстве. С одной стороны, надо поощрить активность новичков. А с другой, хороший раздел превращается в свалку HelloWorld'ов, написанных для попадания в вайтлист. Может быть, стоит вынести такие явно учебные программы в другой раздел? Тогда и старания новичков сохранятся в истории, и раздел не будет замусорен.

Вижу, одна ошибка исправлена. Все равно платформа строится неправильной формы.

Тут даже олдскул не помог внести ясность - вот, в чем проблема.

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

Еще раз взглянул на код. Программа НЕРАБОЧАЯ. Нечего ей делать в этом разделе. Есть как минимум две ошибки.

Для первого раза сойдет. Но чтобы программу приняли, хорошо бы выполнить простые требования: 1) Для лучшей читаемости кода делай отступы; 2) Сделай возможность задавать размер платформы через параметры; 3) Опиши условия, при которых твоя программа сохраняет работоспособность, а при каких нет. Скрины для такой программы, я думаю, необязательны, но рисунок из символов не вносит ясность, как именно двигается робот.

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

Последняя ссылка великолепна. Теперь понял, спасибо за разъяснение. Пожалуй, не буду называть эту конструкцию костылем. В конце концов, в Lua есть нога «if then else». Назову это прыжковыми ходулями. Они тоже расширяют возможности, но при определенных ограничениях. Вот, отсутствие оператора continue в Lua огорчает меня значительно больше. P.S.: Ты мало того, что Крутой, так еще и хитрый. Чтобы рассказать нам про замену тернарного оператора в Lua, сделал вброс про какие-то подводные камни, которые на самом деле были очевидными, заставил меня спорить с тобой. Но план сработал. Возьму на вооружение.

Есть название получше. Церковь Доброй Автоматизации (Eutomation Church)

Ликуйте, братья! По результатам обсуждения предыдущего поста мною было принято решение учредить Церковь Доброй Автоматизации (Eutomation Church). Я временно займу место ее пророка, а все, кто уже успел отметиться в предыдущем посте, объявляются ее апостолами. Случайно отметившиеся могут снять с себя полномочия без каких либо последствий, Добрая Автоматизация не станет преследовать вас. На оставшихся налагается обязанность писать код, делать это вдумчиво и максимально осмысленно, а также распространять по планете радость Доброй Автоматизации. В будущем, если потребуется, изберем пасторов и епископов путем открытого голосования. В комментариях к предыдущему посту наш Крутой брат предложил не забывать и сестер тоже. Но потенциальные сестры пока не спешат поддерживать нашу веру, хотя кое-кто уже сейчас исполняет некоторые из наших заповедей. Наша Церковь готова принять и их тоже. Добрая Автоматизация любит всех вас. Спасибо всем за поддержку. Радуйтесь братья, ибо Автоматизация добра к нам!

А вот здесь ты круто завернул. Зачем ты упомянул получение длины массива через #? Это штатная конструкция языка. А приведенная тобой является костылем, после использования которого ты же сам заявляешь, что он не работает, как настоящая нога. А разве должен был? И с каких пор хождение на штатных ногах стало считаться предубеждением? Согласен. Меня смутил твой код, который явно нарушал приоритет и при этом якобы подтверждал слова Крутого об аномалии. И я решил, что вы оба делаете одну ошибку. Извини, что опять сбиваю тему, я пытаюсь понять логику Крутого. Я сам люблю компактные конструкции, но у этой слишком неприятные побочки, чтобы на нее подсаживаться. По твоей теме не отвечу, нет полномочий.

С этим соглашусь полностью, но не стоило называть это аномалией. Lua не имеет полноценного тернарного оператора. А лучше назовем вещи своими именами. Эта конструкция является костылем, который не всегда помогает пациенту. Я сам пишу if(a) then x=b else x=c end. Выглядит не столь компактно, но работает безотказно. Твой же вариант тоже далек от изящества оригинала. Я бы избавился от такой конструкции, т.к. однажды замучаешься искать ошибку в коде.

О, теперь стало понятно, как Крутой устроил себе западню на ровном месте.

Перефразирую короче. Выражение (a and b or c) следует читать как ((a and b) or c) Очевидно, что в этом случае при b==false и b==nil всегда будет возвращаться c Еще как применяются. Первенство играет роль только для операций с одинаковым приоритетом. Твой же вариант раскрытия возможен, если отдать приоритет операции or над and: Я бы мог неверно истолковать твои слова, но ты подтвердил их кодом. А чем руководствовался Krutoy, раскрывая это выражение, я вообще не понял. О, понял! Он пытается использовать эту конструкцию как тернарную операцию. Но почему именно так, все равно не понял.