Totoro

Это понятно. Просто удивило несоответствие зверской внешности и флегматичного характера монстра. Что касается цен - я представил себе постапокалиптический мир, где одной из главный ценностей является энергия. Представил богатый клан, который желая облегчить жизнь своим членам, устанавливает телепорт-станцию на территории. Поддерживает энергию и т.д. Логично, что перемещение через него не будет дешевым для посторонных лиц. С другой стороны - сеть транспортных телепортов - основное средство передвижения по материку, между городами. Их поддерживает правительство в лице админа и они бесплатны (или дешевы) =)

[OFFTOP]Построил на сервере ферму дерева - крытый стеклянный ангар (чтобы не свистнули робота), AE сеть для продукта и TE кабель для подзарядки. Потом принялся писать программу для робота дровосека. После того как я научил его сносно перемещаться, начался экшн Сначала он пробил стекло и попытался скрыться от меня в глубинах космоса. Я его поймал, прикрутил рекурсивный алгоритм от копателя, чтобы он не трогал стекло и гранит и рубил дерево и листья. Тогда робот предпринял попытку подрыться снизу. Раскопал оросительную канавку, залил все водой и под прикрытием уже почти докопал тоннель до центра ближайшего холма, когда я его обнаружил. Спустя день вся "оранжерея" заросла деревьями так, что листва заполнила все свободное пространство внутри. Оказалось - у робота кончилась энергия в процессе борьбы с буйной растительностью и он просто "увяз" в кроне дерева. Последний раз когда я зашел на ферму - робот просто исчез. Я вручную выпилил все деревья, и осмотрел каждый куб. Стены целые, робота нет. Я теперь понятия не имею, куда он пропал. Может у него произошел коллапс внутренней логики и он просто сам себя дезинтегрировал? Или от безысходности решил покончить с собой? Или положил сам себя вместо дерева в ME сеть? Черт его знает. [/OFFTOP]

Программа для ComputerCraft, да? Насколько я вижу, использует только две специфичные функции - fs.list() и fs.isDir() Если поменять на функцию с итератором fs.list(), а вторую переименовать в fs.isDirectory(), должно заработать и под OC.

Интересно. А телепорты могут иметь различную стоимость? P.S. Почему "триффиды" в метро такие беспомощные? =)

Ок, я согласен, телепортами скорее всего никто пользоваться не будет, как не пользовались и CraftNet'ом. Пофигу. Пока человек шесть всего что-то пишут. Новые люди подтягиваются, понемногу. Да и пользователи программам тоже нужны Когда я нашел этот проект, я плохо знал Lua и моды, до программирования сетей вообще далеко было. Пока я курил мануалы - сеть закрыли, и теперь фиг уже чего напишешь. Обидно. Надо разобраться с загрузчиками чанков и воскресить ее. Тех. обслуживания сеть не требует? Нет. Пусть работает в фоновом режиме, она никому не мешает. Я что-нибудь напишу, на сеть повешу. Lism напишет свою программу, тоже к сети подрубит. Еще кто-нибудь подключится и т.д. P.S. Еще русифицировать ее - будет вообще прекрасно.

Сеть нужна. Если не на старом сервере, то на новом. Чтобы не писать свои костыли для каждого проекта площадью больше чанка (как я написал для телепортов). Нужна одна глобальная сеть, чтобы не создавать отдельную сеть для каждой программы.

Муа-ха-ха-ха-ха! Тоже собрал сборочку. Прикольно, если добавить в крафт планшета солнечную батарею - он будет как китайский калькулятор, заряжаться днем. P.S. Можно не только с Дженкинса скачать билд. Билды всех версий удобно лежат тут: на GitHub.

На форуме идут вялые споры о чанклодерах, карьерах и донате, а тем временем... Новая версия OpenComputers 1.3.5! Что нового: Добавлено: Жидкости в роботах! Апгрейд-цистерна! Апгрейд-контроллер цистерн! Добавлено: Планшетный компьютер официально доступен! Добавлено: Голограммы теперь можно двигать. Немного. Добавлено: Геосканер теперь можно использовать как апгрейд. Добавлено: Апгрейд-крафт теперь возвращает размер полученного стека предметов. Добавлено: Апгрейд-поршень. Теперь робот умеет толкать блоки! [MC1.7] Добавлено: Поддержка AE2-энергии. Изменено: Используемые библиотеки были переименованы таким образом, чтобы избежать ЛЮБЫХ конфликтов с другими модами. Это означает, что они были перекомпилированы. Дайте знать автору мода, если появились какие-либо проблемы. Пофикшено: Потенциальные проблемы с загрузкой мультиблочных экранов. Пофикшено: Некоторые разрешения мониторов не сохранялись после загрузки. Пофикшено: Некоторые предметы после использования и замены роботом - уничтожались (например - ведро -> ведро с молоком). Пофикшено: Освещение и другие потенциальные проблемы с загрузчиками чанков. Пофикшено: N-ое количество других проблем и багов. P.S. Я могу также выложить перевод API новых функций, если кому интересно.

Итак, тотальная творческая переработка, с учетом полученных отзывов. Встречайте! Новый, ослепительный, потрясающий возможностями https://lh3.googleusercontent.com/XgSiLi-8zYrO6XaP1IjTDg0m9TdnHM_wOOJZWTOuRoU=w895-h513 SmartLock 0.3 by Totoro 1) Для тех, кто не хочет ждатьСсылка на установку: http://pastebin.com/nQHbskwP Если у вас есть интернет-плата, откройте каталог, доступный для записи и наберите: "pastebin get nQHbskwP lock". Теперь программу можно запустить простой командой "lock". 2) Что оно умеет? Итак, список основных фич: Централизованное управление множеством замков (в лице компьютера из OC) Управление правами доступа (черный/белый список), независимое от привата территории Настройка уровней доступа Лог на жестком диске (вам не нужно присутствовать на сервере, чтобы знать все обо всех) Управление через очки "Google Glass" или встроенный терминал Управление по сети Веселые смайлики 3) Как оно устроено?По сравнению с первой версией, все стало намного проще и дешевле. Основа - компьютер из мода OpenComputers. На нем запущена программа SmartLock. Дверные замки - это пары сенсорный монитор + красный контроллер. Все соединяются вместе кабелями и присоединяются к центральному компьютеру. Железо - это корпус (третьего уровня), две видеокарты (можно второго уровня), винчестер, процессор и память (любые). Замки - это мониторы второго или третьего уровня и красные контроллеры, расположенные так, чтобы сигнал редстоуна от блока открывал дверь. По желанию можно добавить Terminal Glasses Bridge и модем. 4) Как этим управлять? Управление осуществляется командами из консоли. Вот они: door <адрес монитора замка> <адрес красного контроллера> <название без пробелов> <уровень доступа> - записывает новый замок в таблицу door <адрес монитора> <название/уровень> - изменяет уже существующую запись list doors - выводит список всех дверей в системе get <адрес монитора> - выводит данные одного конкресного замка remove <адрес монитора замка> - удаляет запись из системы open [адрес монитора замка] - отпирает указанный замок. Если адрес не указан, отпирает последний активный замок. Например тот, в который только что позвонил гость. user <ник> <уровень доступа> - создает или изменяет пользователя list [users] - выводит список всех зарегистрированных пользователей get <ник игрока> - показывает уровень доступа конкретного игрока remove <ник игрока> - удаляет пользователя из таблицы log - показывает последние непрочитанные события log all - покасывает весь список лога с самого начала log clear - очищает лог в терминале (при этом все данные на жестком диске сохраняются) exit или quit или просто q - выход из программы Примечание: Важно! Адреса не нужно указывать полностью. Достаточно первых четырех-пяти символов. 4) Настройка программы В исходном коде, в самом начале расположены несколько констант, изменив которые вы можете настроить программу под себя. OWNER - ник владельца. Поменяйте на свой. DEFAULT_USER - ник пользователя по умолчанию. DEFAULT_LEVEL - уровень по умолчанию. Присваивается новым пользователям, если не указан другой. DEFAULT_DOOR - дефолтное название для новой двери OPEN_TIME - время на которое открывается дверь, в секундах RED_STRENGTH - сила редстоун-сигнала из красного контроллера PORT - порт для взаимодействия по сети ALLOW = "｡◕‿◕｡" WAIT = "(⊙_◎)" - набор смайликов для различных состояний замка DENY = "(¬_¬)" GLASSX - горизонтальная координата для интерфейса GoogleGlass GLASSY - вертикальная координата GLASS_TIME - время на которое появляются сообщения на очках GoogleGlass, в секундах 5) Сетевой интерфейсОн пока очень простой. (Если надо что-то расширить - пишите) Программа передает инфопакет, когда кто-то стучит в дверь. Это сериализованная таблица вида: {date, player, doorname, address} Дата/время события, ник игрока который вошел (или пытался), название двери и ее адрес. Программа принимает только один управляющий пакет - сериализованную таблицу вида: {command = 'open', address} Где command равно 'open', т.е. - открыть дверь, а address - необязательный параметр. Если адрес не указан, программа откроет последнюю активную дверь. 6) Возможные конфликты Компьютер оказывается подключен сразу к N-ому количеству мониторов - и естественно может забиндить не тот монитор в качестве основного. Добавьте в корень своего диска файл autorun такого содержания: require('component').setPrimary('screen', 'XXXX')Где XXXX - это адрес вашего главного монитора. Вы можете также объединить сеть дверных замков с сетью сенсоров движения SpiderEye. Зачем опутывать дом проводами дважды? В это случае вам будет необходимо создать такой же файл autorun на жестком диске компьютера SpiderEye. И проставить в нем адрес основного монитора SpiderEye соответственно. Если вы используете редстоун сигнал сети слежения - укажите аналогично главный компонент для рестоун сигнала - адрес красной карты или красного контроллера. Совет: если вы используете сетевой интерфейс программы, вы можете подключить свой компьютер через свитч OC. Это позволит пропускать беспрепятственно сетевые пакеты, и при этом не создавать путаницы компонентов.

Опытным путем выяснил - радиус действия около 8 блоков (в области прямой видимости). В конфигах вроде нет этого параметра.

Датчики передают относительные координаты движения.В принципе, если повести некоторую калибровку, чтобы можно было соотнести координатные системы датчиков и роботов, можно сделать роботов, которые будут стоять на пусковых площадках с подзарядкой и вылетать по сигналу. Вооружить луками (такое вполне возможно) или лазерами/бластерами. Проблема я думаю в маленькой скорости и маневренности роботов. Если их много, они могут организовать что-то вроде "сетки огня", на опережение. Это уже не тривиальный алгоритм , но интересный. Кроме того сигнал датчика дискретен. Передает движения не постоянно а фрагментами, насколько я понял, пока писал систему. Есть шанс упустить жертву.

Ред убирать не буду - удобно чтобы локально включить сирену, или красные лампы зажечь.Добавлю отправку тревожного пакета broadcast'ом по заданному порту. К слову, обдумывал еще такую мысль - удаленное подключение датчиков движения к SpiderEye. Например через связную плату, или через существующую глобальную сеть. Например - качаешь лаву в аду. Привата нет, как отследить возможного вандала? Можно часть лавы отвести на двиг, поставить компьютер и датчик. Пусть посылает данные. Если ограбят - знаешь кто.

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

Да, именно такая структура. Сетью можно (и для этого не надо переписывать программу) управлять с переносного ПК. Они должны появиться в следующем апдейте OpenComputers. Единственное - для этого придется посетить все станции телепортов лично, с КПК. Для того, чтобы телепорты могли связаться через более глобальную сеть - надо чтобы она существовала. И это тоже будет сеть подгруженных точек в радиусе досягаемости сигнала. Либо изготовить большое количество связных плат (по числу телепортов) и их пары собрать в большом серверном центре. Тогда будет нужна незначительная модификация программы (другой компонент будет использоваться). Или есть еще варианты? Я сделал самый простой способ централизации управления. Пинга нет. Пакеты уходят в одну сторону. Передаются менеджерами по цепочке, пока не дойдут до каждого телепорта и не обновят его таблицу. Менеджер может пингануть непосредственного "клиента", чтобы определить, что он еще "живой". P.S. Я буду в РК сегодня. Но без периферии я все равно только в чате писать.

Quantum Link Alpha by Totoro Итак, готова альфа версия программного обеспечения для квантовой телепортации Quantum Link =)Пакет состоит из трех частей. 1) QL Terminal http://pastebin.com/jNbXzm43 Это программа для компьютера - телепорта. Обладает простым интерфейсом (список станций, кнопка [Teleport]). В списке могут быть платные и бесплатные станции. 2) QL Manager http://pastebin.com/hRQxXD0b Это - управляющая программа. Управление строится по древовидной схеме. Несколько станций телепортов в радиусе доступности для связи подключаются к компьютеру-менеджеру. Далее, если необходимо, компьютер-менеджер (и другие в окрестностях) подключаются к другому менеджеру, становясь таким образом "ретрансляторами" от него к телепортам. В свою очередь этот последний менеджер может подключаться к следующему и т.д. Пока все "нити управления" не окажутся у одного - администраторского - менеджера. Администраторский менеджер сможет контролировать таблицу станций на всех своих подчиненных "клиентах", и - вниз по цепочке - на всех телепортах сети. При этом программа для всех звеньев одинакова (по ссылке выше). 3) QLinker http://pastebin.com/p0nE5z9r Вспомогательная утилита. Служит для составления таблицы "клиентов" (телепортов, или менеджеров уровнем ниже). Устанавливается на дискету. Файл должен называться autorun. Дискета поочередно вставляется в компьютеры-"клиенты" и подается команда get. Затем дискета вставляется в компьютер-менеджер и дается команда set. В процессе составляется таблица адресов, которая в конце устанавливается как таблица клиентов для менеджера. Благодаря этому, нет необходимости запоминать и переписывать вручную длинные адреса.

Можно сделать и то - и то. Пусть хакеры развлекаются Теоретически - удачливый хакер получает доступ к командному блоку. Ого-го стимул. Согласен, я слегка увлекся =) С OC телепорты придется снабжать энергией. Получится, что содержать телепорт может позволить себе достаточно крупный клан/поселение, который может круглосуточно его поддерживать. Тогда часть оплаты может уходить на его поддержку, тем кто генерит энергию. Суровый реализм (капитализм, и частное предпринимательство =)) В принципе действительно достаточно трубы и гейта. А если поставить флаг в файле конфигурации OpenComponents, который позволит адаптеру работать с ID блоков в инвентарях - можно сократить все до воронки и пустотной трубы. Мне показалась интересной система, когда платные телепорты имеют разную стоимость. Телепортироваться на дачу к админу, или на соседнюю улицу - совсем разные вещи. Для этого нужен был более тонкий контроль. В принципе, можно (если поставить вышеупомянутый флаг) подсчитывать предметы прямо в воронке, а затем (после телепортации, пока идет cooldown) врубать сигнал редстоуна на деревянную трубу и редстоун-двиг из BuildCraft'а и вынимать предметы в ту же пустотную трубу. Однако может появиться проблема переполнения, когда злоумышленник вывалит over9000 булыжника в приемник. Это тоже придется отслеживать и включать процедуру очистки (телепорт будет уходить в cooldown). P.S. Насчет того, что снимается - я предположил =) У меня еще не снимали, а я сам не пробовал.

Спасибо Адреса длинные только, вводить долго. Зато безопасно. Уже делаю. Программа-менеджер телепортов пока будет консольной. Она будет слушать эфир и передавать команды подконтрольным телепортам. В новых версиях OpenComputers должен появиться компьютер-планшетник (будет собираться из запчастей в ассемблере). Тогда и офис строить не надо - ходи себе с планшетом и обновляй данные =) А во втором варианте мне особенно нравятся криптографические блоки от Immibis (на скриншоте сверху - похожие на стойки дата-центра).

Мой вариант на конкурс (OpenComputers и Applied Energistics): Quantum Link :cool:

У меня вопрос, по удаленному администрированию телепортов. А точнее по безопасности. Я придумал два варианта, обеспечивающих безопасность данный от перехвата и подделки: 1) Сделать таблицу адресов всех телепортов, и передавать не broadcast'ом, а точными сигналами по адресам. Тогда хакер просто не сможет получить данные. (Если конечно не будет пытать администратора, и вызнавать таблицу адресов. Перебором адреса получить нереально) Проблема: радиус беспроводной связи ограничен. Надо делать либо несколько "офисов" для управления, на локальную группу телепортов. И менять таблицы поочереди в каждом "офисе". Либо, сделать сеть ретрансляторов, каждый из которых будет знать только адреса ретрансляторов более низкого уровня. Тогда можно будет дать сигнал с "главного" ретраснлятора, и он разбежится по дереву передающих станций, и дойдет до каждого телепорта. Безопасно, но требует точной ручной настройки. 2) Шифровать передаваемые данные асинхронным шифрованием. Администратор посылает вызов, телепорт его принимает и высылает одноразовый ключ для шифрования. Администратор шифрует данные и посылает телепорту. Тот принимает данные и выполняет действия. Проблема: хакер может перехватить первоначальный вызов и начать "ДДОС-атаку" посылая вызов снова и снова. Формата необходимой команды он не знает, поэтому послать свои данные не сможет. Однако телепорт будет вынужден постоянно генерировать ключи и посылать их в ответ. Можно сделать ограничение и проверять сигнал только раз в секунду, к примеру. Но хакер все-равно может забить эфир и помешать настоящему администратору передать данные. И опять стоит вопрос централизации управления. Я склоняюсь к первому варианту. Что думаете по этому поводу? https://lh3.googleusercontent.com/WUtrSIdSnGOQ8oq2YjmABHOmrz6BjuNiPJZWFk1FUyE=w925-h530-no

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

Я уверен, что и с ванильным сундуком робот будет работать аналогично. Обновил программу для горизонтального копания: http://pastebin.com/NQe6P6NR Теперь формат вызова выглядит так: mine <length> [width] [return] Где return принимает значение true или false. Если true - робот после работы возвращается в исходную точку. По умолчнию - не возвращается.

Именно так. А один и тот же блок он не проверяет detect()'ом дважды. Если от пометил блок как false - пустая руда, то, когда он подойдет к нему с другой стороны, и начнет проверку сначала по массиву - блок, отмеченный false (пустая порода) или true (уже выкопан), отсеется сразу. Потому робот не будет тратить время и поворачиваться к блоку, который он уже обследовал. Он повернется к первому неизвестному (который в таблицу не занесен - nil). На обычном не пробовал, т.к. я обкатывал программу у нас на сервере. Он возит с собой сундук из Ender Storage, настроенный на одну цветовую комбинацию с другим сундуком, из которого выкачивает ресурсы ME Import Bus. Что касается лавы - он у меня сейчас остается в точке, пригодной для того, чтобы сразу продолжить копать. А если там (случайно) лавовое озеро, его это естественно не смущает. Локальные координаты от сохраняет (блок NAVIGATION). В принципе - можно сделать чтобы он проверял окрестности на жидкость. А если вокруг лава (или вода) - пятился бы назад до сухого места =) Каждый апгрейд на инвентарь - плюс 16 ячеек. Мой робот-дровосек имеет четыре апгрейда - инвентарь на 64 ячейки (хотя ему столько не нужно =)) В коде 24 я написал, чтобы оставить небольшой буфер, на случай, если проверку пройдет слишком поздно и часть добытого начнет высыпаться. Вообще у робота-шахтера - 32 ячейки.

Это очень просто. OpenComponents позволяет через адаптер обращаться к ME Controller'у. Я при запуске запрашиваю количество алмазов в сети и сохраняю его. Раз в секунду происходит обновление программы. Она проверяет количество алмазов в ME сети. Если значение изменилось - вычисляет разницу. Если разницы хватает на выбранный телепорт - хватает игрока и телепортирует.

У меня сделано очень похоже на это. Я делал так: 1) Завел переменную MAX, куда записал максимальный размер стороны куба, который может содержать жилу. У меня это 1024 блока. Размер просто нереальный, даже для черного гранита =) 2) При обнаружении чего-то интересного - вызывается функция go(). Она записывает, куда смотрел мордой робот, чтобы вернуть его в правильное положение, когда он закончит выкапывать жилу. Затем объявляется пустая таблица lode (жила). Элемент с любым индексом в новой таблице будет всегда nil. Этим и пользуюсь. Элемент nil означает, что этот блок робот еще не исследовал. И наконец - вызов рекурсивной функции mine. Ей передается сторона, с которой надо начать. 3) Первая часть mine: функция получила параметр - сторону, которую надо копать. Она ее копает (добавлены циклы, на случай гравия. И все равно ведь где-то сбивается :confused:) 4) Вторая часть: команда lode[loc.x*MAX*MAX + loc.y*MAX + loc.z] = true Чтобы не заморачиваться с 3D массивом, я генерирую на основе трех координат уникальный индекс. И делаю запись в таблице - true: значит текущий блок пройден. 5) Третья часть. Робот начинает проверять соседние блоки. Он вычисляет их координаты (прибавляет или отнимает от нужной оси по 1) и смотрит массив lode. Если в ячейке - nil, значит робот еще не был в этом блоке, и не проверял его. Если там пустая порода, робот записывает false в таблицу и проверяет следующий блок. Если там руда - вызывает функцию mine с параметром - стороной где обнаружена руда. Получается - функция mine вызывает сама себя. (Рекурсия. Откуда название программы =)) 6) Завершающая часть. Робот вспоминает, какую сторону ему передали в начале, и делает движение обратно. Если он копал вниз - он поднимается. Если копал вперед - разворачиваеся назад и делает шаг. Таким образом, вложенные вызовы mine завершаются поочереди, начиная с самого последнего, и получается, что робот возвращается точно по своим следам в исходную точку. Там к работе возвращается функция go(), которая поворачивает робот в исходное положение.