Farlang

А, все, теперь понял о чем ты. Но это не нужно, потому что readonly диски ничего не ломают. Выводится на секунду сообщение об ошибке и дискета выплевывается. Раньше сообщение, правда, висело и портило интерфейс, но после "фикса" term.clear()-ом вообще проблем нет. Про спам readonly дисками я написал, потому что они пройдут фильтр дискетника и сумеют забить конвейер с обоих сторон. А еще в filesystem api вроде была функтсия для проверки, readonly ли фс. Так что если бы была необходимость - то можно было бы и сделать фильтр. Но ее нет.

Именно так оно сейчас и работает. Если ты не против вручную диски вставлять-вытаскивать то можешь хоть сейчас их писать. А я говорил про робота, который будет делать это за тебя. component.filesystem.slot - хорошая идея. Передать это значение роботу и о рейде можно окончательно забыть. Что? Я и не собирался переименовывать диски/дискеты. А вот фичу лейблинга можно за пять секунд прикрутить.

Очевидно, это все отголоски системы тегов хабра. Это когда теги служат не для поиска, но для краткого отображения сути поста. Передачи некоего дополнительного смысла, быть может. Этакий tl;dr - прочитал теги и все сразу ясно. 2Doob: проблема с дисками в том, что нет особого блока, куда могут быть вставлены только они. Есть RAID, но диски форматируются при извлечении из него. Значит, простой системой конвейеров не отделаешься, нужен робот. Распознавание по name не поможет, т.к. name у всех OC блоков и предметов один и тот же (недавно точно так было). Можно задать забор предмета из определенных ячеек инвентаря системного блока, но тогда придется использовать один фиксированный тип этого самого блока (алмазный, скорее всего), так как различить робот их не может. Хотя комп может оповещать робота - редстоуном с разной силой, например, чтобы без дорогих вайфаев. Но как робот поймет, где диск на которого записывали, а где диск, с которого записывали? Тут на помощь придет RAID. Вынеся системный диск наружу системного блока, робот, не трогающий RAID, сможет извлечь исключительно тот диск, который и нужен. Как вариант - вместо рейда дисковод с дискеткой. Правда, тогда на всех дисках будут копии проги-автомата, потому что две оси на одну дискету вряд ли влезет, и придется писать корень. Так что лучше RAID. Ну или можно просто использовать для системного диска определенную ячейку, но такой вариант мне не нравится. Все равно перепутаются как-нибудь. Коротко: может и сделаю когда-нибудь. Ну как я фермера на улучшенный алгоритм движения собрался перевести и до сих пор не перевел.

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

Что? Данный автомат может принимать дискеты у пользователя, записывать на них что угодно (предоставляя пользователю выбор, что именно записывать) и возвращать их ему. Также автомат может и не предоставлять выбор пользователю, становясь таким образом полностью автоматизированным (хотя вряд ли его получится включить в АЕ систему, ведь и на входе, и на выходе дискеты). Зачем? Идея у меня появилась после чтения публикации в блоге Totoro "Как собрать шахтерского робота" (http://computercraft.ru/blog/11/entry-338-kak-sobrat-shakhterskogo-robota/) а именно следующих строк: Я подумал, что данную задачу (раздача дискет с определенными данными) можно легко автоматизировать. Так и вышло - программа занимает чуть более ста строк, но все-таки полезна. Так можно избавить новичков от необходимости крафтить еще один мануал - выданный в начале игры будет израсходован на Lua BIOS (кстати, их запись тоже можно автоматизировать), а для OpenOS пришлось бы скрафтить еще. Но не теперь. Как? Пользователь бросает дискету в воронку, откуда она, пройдя воронковый конвейер, попадает в дисковод. После этого пользователь нажимает на мониторе кнопку желаемой программы или кнопку извлечения дискеты (отключается). В полностью автоматизированном режиме компьютер каждые n (задается) секунд проверяет, не попала ли к нему дискета, и пишет на нее данные по предварительно заданному пути. Поиск файловой системы дискеты проверяется методом исключения - те файловые системы, что были на момент запуска программы, считаются не дискетами. Поэтому важно запускать программу лишь убедившись, что в дисководе пусто. Дискета форматируется и на нее пишутся новые данные. Далее компьютер отключает редстоун-сигнал от выходной воронки, которая подключена к дисководу, и она забирает дискету из него. По воронковому конвейеру дискета попадает к роботу, единственная задача которого - выкидывать все из инвентаря (код робота на EEPROM не приведен ввиду его очевидности) (про диспенсер вспомнил только пока эту тему писал). в диспенсер и попадает. Так дискета возвращается к пользователю. Предварительная настройка Можно настроить: Режим работы: спрашивать что писать или нет (переменная ASK). Адрес до директории с данными для записи (в режиме полной автоматизации) или с поддиректориями, список которых будет выведен для выбора пользователю (переменная DISKS). Период проверки наличия дискеты в полностью автоматизированном режиме (переменная SLEEP_TIME). Сторона, c которой проведен редстоун-кабель до выходной воронки (переменная HOPPER_SIDE). Включение/выключение подгонки разрешения экрана под количество кнопок в режиме частичной автоматизации (переменная CHANGE_RES). Возможность извлечения дискеты без её форматирования и записи новых данных в режиме частичной автоматизации. Для включения этой возможности создайте директорию _[EJECT] по адресу, который был задан переменной DISKS, т.е. DISKS/_[EJECT]. Названия кнопок. Они задаются названиями поддиректорий DISKS. В названиях нельзя использовать: звездочки, слеши, пробелы и прочие сомнительные символы, а также кириллицу. Подчеркивание _ будет удалено, если оно идет первым (как в _[EJECT]). Инструкция конечному пользователю В основном не нужна. Однако могут пригодиться значения мигания кнопок: Если кнопка мигнула очень быстро, то это значит, что дискета не найдена. Если вы уверены, что бросили ее, то нажмите кнопку снова - скорее всего она просто не успела дойти. Медленное мигание означает, что дискета была записана и возвращена пользователю. Если ее нет, то она потерялась (см. далее). Этого практически не происходит в правильно построенных автоматах. Возможные проблемы Злоумышленник может забить весь входной воронковый конвейер каким-нибудь мусором или readonly дискетами. Решение: не будьте злоумышленниками. Робот выбрасывает дискету куда-то не туда, и пользователь не может её забрать. Решение: минимизируйте количество полостей в автомате. Блоки с некубической геометрией (кабеля, например) и свободные для прохода блоки (факелы, таблички, тростник etc.) также являются полостями. Чем их меньше, тем меньше шанс на потерю дискеты. Или можно поставить диспенсер вместо робота, но я не уверен, решит ли это проблему. А редстоун-кабель подвести от воронки, только один-два репитера воткнуть. Лучше диспенсер, даже если не решит, то хоть серверу поменьше считать. И заряжать его не надо. Диспенсер проверен и рекомендуется для использования. К нему надо подвести редстоун-сигнал от воронки с одним репитером в режиме максимальной задержки. Какой-нибудь баг вылезает и все портит. Решение: пните меня. Cкриншоты http://i.imgur.com/JRYOZsc.png - как это может выглядеть для пользователя. http://i.imgur.com/3lBpWPX.png - без досок для большей наглядности. http://i.imgur.com/XI3rPbd.png - как выглядел сломанный интерфейс. Скачать http://pastebin.com/0A5S8SDJ Благодарности Totoro за идею. AlexCC за внесение в вайтлист (пришлось прогу написать, чтобы не получилось что зря вносил). UPD: Обнаружен и исправлен баг: попытка записи readonly дискеты приводила к неправильному отображению интерфейса (не влияя на функционал). Также подтверждена работоспособность программы с диспенсером.

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

Там проверка движений очень тупая на самом деле, просто рекурсивным вызовом. Этот способ: local function forward() while not r.forward() do os.sleep(1) end os.sleep(0) end гораздо легче для выполнения, а еще количество попыток движения не ограничено. Надо бы фермера на него перенести как-нибудь.

Данная программа позволяет осуществлять сбор любой ванильной и ваниллаподобной культуры (не проверялось на кактусах, у тростника рекомендуется собирать только верхнюю часть). Под ваниллаподобной культурой следует понимать культуру, сбор которой укладывается в алгоритм: [проверить блок] - (проверить метадату) - [если проверки пройдены, собрать культуру ЛКМ/ПКМ] - (высадить блок ПКМ), где [] - обязательный пункт, а () - необязательный. Жердочки из IC частично поддерживаются (все, кроме резинового тростника и веномилии). Одним роботом может обслуживаться неограниченное (вернее, ограниченное вместимостью инвентаря робота и его ОЗУ) количество полей разных культур. Системные требования: Процессор второго уровня (рекомендуется) Две планки ОЗУ второго уровня (рекомендуется) Жесткий диск первого уровня Геолайзер Улучшения "Инвентарь" и "Продвинутый контроллер инвентаря" Улучшение "Притягивающий луч" как выяснилось, не требуется Видеокарта, монитор, клавиатура (крайне рекомендуется) Пример робота: http://i.imgur.com/q027ast.png Как использовать робота: Первым делом надо определить место установки робота. Программу можно будет запускать только с этого места! Место установки включает в себя координаты по всем трем осям и ориентацию (posx, negx, posz, negz). Под этим местом необходимо разместить воронку для выгрузки собранных айтемов. Также, если робот будет заряжаться, зарядник следует разместить так, чтобы не мешать проходу робота, например, в стене. После этого следует убедиться, что между всеми полями существует свободный проход и что над растениями свободен минимум один блок. Робот не имеет алгоритма поиска пути и будет идти "напролом", а значит, ему нельзя преграждать путь. Крайне рекомендуется располагать все поля в прямоугольной области, а также на одной высоте. Затем следует открыть исходный код и отредактировать переменные c четвертой строки по тринадцатую. Назначение переменных прокомментировано в самом коде. Изменив значения переменных, не листайте дальше, чтобы не увидеть велосипеды на костылях. Далее следует создать текстовый файл по адресу /fields.txt, в котором описать все поля, предназначенные к сбору роботом. После этого робот готов к работе. Установите робота на его место установки и запускайте программу. Cтруктура файла fields.txt: Каждое поле описывается одной строкой, поля идут в порядке сбора. Строка поля должна быть вида: startPosX,startPosZ,anotherPosX,anotherPosZ,fieldY,blockToTake,itemToPlant,fullGrownState,isRight startPosX и startPosZ это координаты начальной точки поля. С этой точки робот будет начинать сбор. anotherPosX и anotherPosZ это координаты противоположной точки (как точки, выделяемые при привате территории). Это не точка, где сбор будет заканчиваться. fieldY это координата, на которой располагаются растения. Робот будет летать на блок выше этой координаты, так, чтобы находиться над растениями. Если растение многоблочное, следует указать координату самой верхней части. blockToTake это name блока, который требуется собирать. Например, minecraft:carrots для моркови или minecraft:melon_block для арбузов. itemToPlant это name айтема, который требуется высаживать. Если после сбора ничего высаживать не требуется, следует написать nil. Можно написать и другое несуществующее name, но тогда робот будет все время пытаться найти ваш айтем (и, следовательно, работать медленнее). fullGrownState это metadata созревшего растения. Если metadata проверять не требуется, следует написать -1. isRight это необязательный флаг, указывающий, что культуру следует собирать ПКМ. По умолчанию стоит в false. Пример файла fields.txt: http://pastebin.com/H10k6QkV Ферма, соответствующая этому файлу: http://i.imgur.com/wP5gAaa.png Скачать: http://pastebin.com/K4DU8d3n Дополнительно: Просьба к играющим на МТ проверить работу робота с тамошними ваниллаподобными культурами, если такие там есть. Автор выражает благодарности: Totoro, который ответил на несколько моих глупых вопросов. AlexCC, который запретил сборщик урожая и тем самым побудил меня написать данную программу. Fingercomp, который натолкнул меня на мысль добавить поддержку сбора культуры ПКМ. UPD: Добавлена поддержка сбора культуры ПКМ. Это открывает возможности для частичной поддержки жердочек из IC - их состояние невозможно узнать, но большинство из них собираются только на последней стадии, так что с ними все-таки можно работать.