eu_tomat

Сканер вместо координат выводит шаблон форматирования: Robot detected: x=%s y=%s z=%s Радар на все запросы выдаёт пустую таблицу =component.radar.getEntities(999) {n=0} =component.radar.getItems(999) {n=0} =component.radar.getMobs(999) {n=0} =component.radar.getPlayers(999) {n=0}Тестировалось в сингле на текущей сборке EvilWorld.

Интересно, область какого размера ты планируешь покрыть 30 проекторами? Спавн + 8 ближайших к нему приватов? Это точно не "все текущие домики".

А я вставлю ещё копейку. Не знаю, как в текущей версии OpenComputers, но около года назад я проводил замеры, и не обнаружил разницы во времени исполнения разной арифметики типа + - * / % & | >> << Зато обращение к переменным, адресация в таблице, а особенно вызов функций обходились заметно дороже, подтверждаю. Очень спорно. Главная проблема текущей реализации в том, что простых чисел в имеющейся таблице мало, от чего криптоустойчивость ключей очень низкая. Диапазон чисел требуется сильно расширить и либо как-то хранить заранее вычисленные числа, тратя дисковое пространство, либо в нужный момент вычислять, тратя процессорное время. А вычисляться они будут долго. Особенно на Luа. Особенно, когда большие числа потребуют длинной арифметики. А они потребуют. На практике же мало кто вычисляет простые числа для целей криптографии. Обычно генерируется случайное число, и к нему применяются алгоритмы проверки простоты числа с определённой вероятностью, достаточной для наших целей. Но это очень поверхностные сведения. На практике криптография имеет множество нюансов, и устойчивость алгоритма к взлому сильно зависит от выбора ключей. И, повторюсь, при отсутствии хороших знаний в области криптографии генерацию ключей лучше поручить стандартному ПО. А само шифрование-дешифрование уже реализовать в библиотеке OC. Похоже на выход за пределы целых чисел. Арифметика с плавающими числами имеет ограниченнную точность и совершенно не подходит для шифрования RSA. Выход в использовании длинной арифметики. Нужны три операции: умножение, возведение в квадрат и взятие остатка от деления.

Гифка впечатляет. Теперь скрытые под толщей обсидиана лабиринты доступны для осмотра любым желающим. Где теперь прятаться?

На практике RSA используется в основном для передачи временных ключей симметричного шифрования. То есть, длительное декодирование выполняется лишь в начале сеанса, а дальше используются более скоростные алгоритмы. В этом случае на длинне ключа не экономят. Минута на взлом это очень мало даже по меркам Майнкрафта. Замена ключей хотя бы раз в день выглядит интереснее. Хотя, для стационарных систем замена должна быть не чаще раза в месяц. Помня о трудностях генерации устойчивых к взлому ключей, я бы вообще избавился от генерации ключей своими силами. Наверное, проще будет воспользоваться стндартными генераторами, изучить формат файлов и вытащить из них ключи, а в OC сосредоточиться только на возведении в степень по модулю, и исключительно для передачи временных ключей более шустрых методов шифрования. Что же касается сети Zn, то главная её проблема даже не в перехвате сообщений, а в возможности легко обрушить всю сеть обычным спамом.

Что и неудивительно с такой реализацией: На помощь придут Алгоритмы быстрого возведения в степень

С некоторыми неудобствами, но черепахами тоже можно просто собирать лаву, но для этого программу надо переписывать, а это особая, ныне утраченная магия.

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

Возможно, как-то поможет эта оболочка: Файловый менеджер Midday Commander

Ничего в Майнкрафте не востребовано. Всё ради фана. Многие вообще без роботов обходятся. Вопрос же был об экстремальных задачах для OpenComputers, но чтобы без самой игры.

Одно время я увлёкся темой компрессора Lua-кода, но написал только SFX-модуль, да поиск сжимаемых участков, благодаря чему смог оценить степень сжатия, и на этом успокоился. Вполне экстремальная задача, когда весь код должен помещаться в 4096 байт и более-менее быстро распаковываться. Если интересно, Задачка (алгоритм: ASCII-компрессор)

@@Jakowlew Большинство из тех, кто пишет, не мучают себя поисками задачи. Играют, пишут какую-то автоматизацию для удобства. Если получается чем-то лучше, чем у других, выкладывают. А если не получается, так хотя бы в игре развлекаются.

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

@Krutoy, помнится, "Арбузер" писал.

Беспроводная карта T1 – нужнейшая вещь. Наконец-то она позволит выйти из замкнутого круга: для создания робо-фермы жемчуга требуются беспроводные карты, а для беспроводных карт нужен жемчуг. Да и вообще спектр начальной автоматизации благодаря этим картам немного расширится. Смена имени робота программным путём – одна из тех приятных возможностей, что была когда-то утеряна при переводе сервера с ComputerCraft на OpenComputers. Теперь причин для сожаления стало еще меньше. getAllStacks и getInventoryName – тоже долгожданные возможности. Использование овец в качестве вечного двигателя – весьма неожиданное решение. Интересно, означает ли появление ковровых конденсаторов то, что теперь OpenComputers обзавёлся собственным источником энергии, и энергия в роботах может быть конечной даже при игре без модов на энергию?

Для MC 1.7.10 в версии OC 1.7.2 контроллер инвентаря и транспозер наконец-то научились получать название инвентаря. Положение сундука теперь определяется однозначно.

Как много всего вкусного! Сразу захотелось запустить Майнкрафт.

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

Первую созданную тобой тему я читал внимательно. Обнаружив этот дисклеймер в конце, не удивился. Подумал, прекрасно, загляну сюда позже, когда тема придёт в полное соответствие с замыслом автора. Обнаружив вторую тему с тем же дисклеймером, я даже не стал вчитываться. Аналогично и с третьей темой, но тут мне захотелось внести ясность. Что в данном случае означает фраза «тема будет редактироваться»? Считать ли такую тему черновиком и подождать, когда автор доведёт её до ума и оповестит об этом дополнительным сообщением в теме? Или сам автор уже сделал, что мог, а тема будет редактироваться в соответствии с вопросами и уточнениями читателей? И еще один вопрос. Планируется ли впоследствии удалить формулировки про редактирование, про опечатки и коленки, и при каких условиях?

Ой! А зачем же так код упакован? И Lua beautifier не хочет приводить его в порядок. В общем, код я посмотреть пока не смог, а запускать не буду. В связи с этим возникает вопрос: не приводит ли интенсивное использование этой библиотеки к обратному эффекту, о котором рассказывал @ECS, когда сборщик мусора не успевает чистить интенсивно создаваемые и уничтожаемые объекты, от чего фактическое потребление памяти начинает расти?

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

Да кто же в здравом уме будет её использовать? Но обрати внимание на эволюцию: когда-то ретрансляция выполнялась встроенными средствами мода. Потом программными. Затем система Zn решила некоторые из проблем обмена. Через несколько месяцев, может, еще какая идея появится. Тема-то как раз для ищущих развлечений программистов. Ну, а что ты предлагаешь? Где-то же надо было рассказать про заторможенность вызова computer.pullSignal. Про ограничения очереди сигналов где-то, кажется, уже говорили. Радиообмен сообщениями – яркий пример, где заторможенность получения сигналов из очереди может привести к потере контроля над системой. Систему Zn в этом повествовании просто необходимо было бы упомянуть. Также стоило напомнить и о вреде широковещательной передачи. Про вред для сервера говорилось много, но о вреде для собственных систем почему-то забывают. Лишь один раз, помнится, произошла увлекательная история с проникновением в дом через лаз для робота, открывавшийся по WiFi. Песня партизан, сосны да туман...

Нет ни чьей вины. Особенности работы мода – данность, которую следует учитывать при создании систем. Или при их взломе. Работает это везде, а к сбоям приводит не всегда. Если меня не подводит мой калькулятор, то для переполнения очереди сигналов на мониторе должны плясать не менее 15 человек. Интересно было бы взглянуть на программу, где это оказалось бы критичным. Или возьмём, например, обработку сигналов от красного камня. Чтобы добиться пропуска сигналов, к компьютеру должны подползти не мене 4 вражеских роботов, а для полной гарантии – 5. Этим роботам еще потребуется равномерно распределиться со всех сторон компьютера или найти соответствующие адаптеры. Хотел бы я посмотреть, как эти партизаны гуськом вползают в дырявый домик и рыщут в поисках чувствительных мест компьютера. Что касается Zn, так это просто хороший пример того, что не всё работает, как было задумано, и всегда есть возможность напороться на неучтённые нюансы. Проблема-то существовала и без Zn, но архитектура Zn эту проблему усугубляет. Можно же было и просто пятью передатчиками заспамить очередь событий приёмника, но всегда приятнее напакостить врагу его же собственными ресурсами. Решение проблемы: * По возможности избегать использования широковещательных пакетов; * Если же систему иным образом не построить, следует отсылать пакеты как можно реже; * Мощность передатчиков должна быть снижена до минимума, при котором система сохраняет работоспособность; * Система должна быть готова к переходу на другие частоты и полной отстройке от зашумленных частот. Помни: враг подслушивает! Широковещательные пакеты доступны всем приемникам, настроенных на данную частоту и находящихся в зоне действия передатчика. Обнаружив активную частоту, враг может заспамить эфир, что приведёт в лучшем случае к оглушению приёмников, а в худшем – к перехвату управления твоими системами.

Идея подавления Zn: Предположим, поблизости есть 5 узлов вражеской сети. Каждый тик (чаще не получится) со своего передатчика посылаем широковещательный пакет в эту сеть. Все 5 узлов дружно ретранслируют пакет на другие узлы. Теперь каждый из них вынужден обработать событие от 4 других узлов и от нашего передатчика – 5 событий каждый тик. Даже простая проверка пустой очереди сигналов computer.pullSignal() занимает ¼ тика. Плюс тратится немного времени на обработку. Результатом атаки будет переполнение очереди событий и пропуск их части. P.S.: И еще будет лаг в 3 секунды на каждом узле.

Предлагая снести магазин, хорошо бы предложить и альтернативный способ мотивации игроков к голосованию в ТОП'ах.