eu_tomat

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

В чём проявляется аналогичность? В чём отличия? Какие преимущества имеет этот загрузчик пред другими?

Мне не совсем понятен вопрос, отвечу как понял. Вывод информации об игроках может выглядеть, например, так: entity = require("component").os_entdetector local e = entity.scanPlayers(10) for i=1,#e do print( e[i].name, e[i].range, e[i].x, e[i].y, e[i].z ) end

С роботом тоже не всё просто. Робот не умеет менять батарейки сам себе. Для доступа в слоты апргейдов роботу нужен второй робот или транспозер. В этом, кстати, есть свой смысл, хотя и спорный: контроллер инвентаря даёт роботу доступ к слоту инструмента, а доступа к слотам апргейдов как не было, так и нет. А дрон, хотя и не имеет слотов сменных апгрейдов, по крайней мере, может эти апгрейды транспортировать потребителям энергии в слотах своего инвентаря.

Да, эта схема переноса заряда несовершенна. Но она рабочая. Перенести энергию во внутренние батареи робота из сменных пока невозможно. Поэтому внутренние батареи почти всегда будут пустыми в этой схеме. Но чтобы робот не выключился во время замены батареи, нужно иметь как минимум два слота для внешних апгрейдов. Можно использовать, например, такую последовательность: ставим заряженный временный апгрейд с небольшой ёмкостью, затем заменяем основной апгрейд, и в завершение вынимаем временный. Исследование приоритетов расхода энергии апгрейдов могло бы позволить использовать ёмкость и дополнительного апгрейда тоже. Старые версии OpenComputers я сейчас не проверял. Но мне почему-то помнится, что раньше батареи высасывались равномерно. Сейчас я поверил на OpenComputers-MC1.7.10-1.7.5.1290-universal.jar: сначала высасывается батарея из апргейда, вставленного в робота первым. Но не факт, что я правильно интерпретировал результаты наблюдения. Надо придумать адекватный тест. Сейчас индикатор заряда на апргрейде обновляется редко, и более-менее точно проверить текущий заряд конкретного апргрейда можно лишь его перемещением в контрольного робота. А такие перемещения снижают чистоту эксперимента. Через computer.getDeviceInfo() мне удалось вытащить только ёмкость батареи, текущий же уровень заряда неизвестен. А сколько может быть запасено энергии в апргейде опыта, вообще приходится вычислять через его уровень. Кстати, можно попробовать для начала сформулировать эту задачу. Например, добавить всем компонентам, хранящим энергию, следующие методы: Получить максимальную ёмкость; Получить текущий запас энергии; Задать/получить приоритет заряда (например, числом 0..15); Задать/получить приоритет разряда. Задать/получить скорость заряда внешних объектов этим компонентом. Это позволило бы роботам подзаряжать внутренние батареи за счёт сменных и наоборот, а также превратить роботов или дронов в источники энергии для других дронов и роботов. Особенным шиком будет суммирование скоростей заряда отдельными компонентами. Так мы получим новый класс роботов и дронов, специализирующихся на хранении и транспортировке энергии.

Вряд ли существует механизм, позволяющий дрону отдавать накопленную энергию непосредственно. Но дрон может передавать энергию в предметах: будь то всевозможные батарейки из модов, или даже апргейды OpenComputers. При желании энергию роботов можно поддерживать заменой батарейных апргейдов или апргрейдов опыта. А сами апргрейды можно переносить в инвентарях дронов. Так что, в каком-то смысле дрон может отдавать энергию.

Да, неожиданно вышло. Уроки из этого вопроса можно извлечь такие: Для того, чтобы программа заработала, её нужно запустить. А перед этим сохранить. Кстати, об этом было сказано в инструкции. Чтобы программа заработала правильно, тоже нужно следовать инструкции. В нашем случае потребовалось изменить адреса. Пожалуй, дам теме более адекватное название.

Скорее всего, не изменены адреса номеронабирателей или изменены на несуществующие.

Значит, набираем key и нажимаем кнопку Enter на клавиатуре.

А под каким именем сохранил?

Ctrl+W закрывает редактор. Перед этим код надо было сохранить. А после выхода из редактора программу надо запустить.

Что пишет программа при запуске?

Да, роботы поршнями не выталкиваются. Остаётся только взлом по сети. Кабели тоже не заталкиваются поршнями. А плата из computronix, поддерживающая подмену адреса, не работает по воздуху. И даже если бы подмена адреса была возможна, достаточно отказаться от использования широковещательной передачи данных, да ввести простейшую верификацию пакетов. Ответ на поставленный вопрос: Да, взлом возможен. Но каждый конкретный случай требует индивидуального исследования, готовый алгоритм взлома отсутствует. Нужно искать уязвимости в системе, проверять ошибки, которые мог допустить владелец, а для начала надо просто понаблюдать за периодичностью действий робота, послушать эфир. В давние времена на форуме была тема о проникновении через лазейку, оставленную хозяином привата для своего робота. История была увлекательной и поучительной, но сейчас я её не нашёл. Либо я плохо искал, либо тема лежит где-то в скрытых разделах форума, как подающая плохой пример. Напомните, если кто-то хорошо помнит эту историю. На той сборке содержимое сундуков даже в привате можно было высосать роботом. Какой-то игрок всё самое ценное хранил дома, но на улице у него была ферма то ли дерева, то ли пшеницы, то ли ещё что-то росло. В доме время от времени открывался лаз, через него проходил робот, собирал урожай и возвращался в дом. Но потом пришли неспокойные ребята, и то ли они просто пропихнули своего робота в открывшийся лаз, то ли перехватили сообщения и взяли контроль над роботом, я уже не помню. Но в дом они всё-таки проникли и в сундуках тоже покопались от души.

А роботы разве выталкиваются поршнями?

Чанклодер нужен не просто для получения времени, а для того, чтобы комп вообще мог что-либо получить. Работать она обязательно будет, но ключевое слово здесь "как-то". Работать скрипт может лишь в то время, когда чанк с компьютером загружен. Если у владельца магазина есть чанклодер, работающий независимо от олнайна хозяина, то и скрипт сможет всегда выдавать адекватное время с контролируемой погрешностью. Если же чанк с компьютером загружают посетители магазина или случайные гости привата, то определить точное время присутствия игрока в онлайне невозможно. Именно такого скрипта я не встречал, но можно немного доработать программу "Мониторинг онлайна", прикрутив к ней получение и вывод времени.

А кто-нибудь знаком с этой штукой? GitHub Flavored Markdown support for CKEditor Судя по демке, позволяет набирать текст только в онлайн, от чего теряет основной смысл. Мои попытки скопировать в форму готовый текст не привели к нужному результату, форматирование не было воспринято. Или я просто не осилил?

Поиск идеальных соотношений сторон монитора. Задача: найти такие конфигурации мониторов, для которых существуют разрешения, при которых ширина вертикальной и горизонтальной чёрной рамки одинакова. Очевидно, что для квадратных мониторов существует множество разрешений, удовлетворяющих заданному условию. Достаточно, чтобы разрешение по горизонтали было вдвое больше разрешения по вертикали. Но количество возможных решений для мониторов с конфигурациями, отличающимися от квадрата, сильно ограничено. Более того, идеальное разрешение существует не для всех конфигураций мониторов. Для поиска решений я буду использовать перебор всевозможных разрешений, благо, их не так много. -- Вычисление идеальных разрешений для мониторов разных размеров -- Не проверяются квадратные мониторы с размерами 1x1, 2x2, 3x3 и т.д. -- максимальный размер монитора local msw,msh = 8,6 -- максимальное разрешение GPU local max_gpu_res, max_gpu_area = 160, 160*50 -- максимальная ошибка, допустимая при округлении разрешения по вертикали local max_error = 1e-3 -- перебор всех допустимых размеров мониторов кроме квадратных for sw = 1, msw do for sh = 1, msh do if sw~=sh then local ratio_wh = 2*(16*sw-4.5)/(16*sh-4.5) -- перебор всех разрешений монитора for gw = 1, max_gpu_res do local gh_float = gw / ratio_wh local gh = (gh_float+0.5)//1 -- печать допустимых разрешений с ошибкой в пределах погрешности if math.abs(gh_float-gh) <= max_error and gh <= max_gpu_res and gh*gw <= max_gpu_area then print( ("%dx%d: %dx%d=%d (%2.0f%%)\terror=%.0e"):format( sw,sh, gw,gh,gw*gh,gw*gh/max_gpu_area*100, gh_float-gh )) end end end end end Найденные решения: 1x2: 46x55=2530 (32%) error=7e-15 1x3: 46x87=4002 (50%) error=0e+00 1x4: 46x119=5474 (68%) error=0e+00 1x5: 46x151=6946 (87%) error=0e+00 2x1: 110x23=2530 (32%) error=0e+00 3x6: 58x61=3538 (44%) error=0e+00 6x3: 122x29=3538 (44%) error=0e+00 7x2: 86x11=946 (12%) error=0e+00 Как видно, выбор среди идеальных конфигураций невелик. Найдено 5 вертикальных конфигураций и 3 горизонтальные. При этом наиболее полное использование возможностей монитора (87% от максимального разрешения) имеет вертикальный монитор размером 1x5. А остальные и того меньше. Стоит ли жертвовать площадью экрана ради максимального уменьшения ширины рамки? Скорее всего, большинство пользователей не захочет микрометром выверять толщину рамки и воспользуется кодом от @ECS, максимизируя разрешение. Все остальные варианты будут разной степени компромиссом между максимальным разрешением и минимальными рамками. Например, @Fingercomp минимизировал ширину полос для монитора 8x3, и получил разрешение, близкое к максимально возможному для выбранной конфигурации. Для других конфигураций выбор может оказаться более сложным, что легко увидеть на примере монитора 1x2: 1x2: 46x55=2530 (32%) error=7e-15 1x2: 51x61=3111 (39%) error=-2e-02 1x2: 56x67=3752 (47%) error=-4e-02 1x2: 77x92=7084 (89%) error=7e-02 Итог: Существуют идеальные соотношения сторон монитора, обеспечивающие равную ширину вертикальных и горизонтальных чёрных полос по краям изображения. Но таких вариантов очень мало, а их практическая применимость маловероятна.

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

Чтобы потом долго не искать, я оставлю заметку в этой теме. Как нам поведал внимательный @Fingercomp, полная ширина рамки составляет не 2 px, а 2.25 px, поэтому идеальная пропорция разрешения экрана в символах будет составлять 2*(16w-4.5) / (16h-4.5). Чёрная рамка шириной 1/4 px сохраняется всегда, избавиться от неё невозможно. Также @Fingercomp очень подробно разобрал пример поиска оптимального разрешения экрана, минимизируя разницу в ширине вертикальной и горизонтальной полос. Код поиска оптимума выложен здесь.

@Fingercomp, удивил. Один вопрос: как ты ухитрился разглядеть эту четверть пикселя? Или ты её чтением кода нашёл?

Не всегда. Но можно попытаться подобрать разрешение, типы мониторов и их размер. Примерный алгоритм описан здесь.

Добавлю к сказанному: Если не хочется вникать во все эти сложные статьи, то в этой программе надо просто увеличить значение xresolution=60. Тогда рамки по бокам уменьшатся. Если появятся рамки сверху и снизу, то xresolution следует уменьшать. В конечном итоге всё равно может остаться очень тонкая рамка, от неё не всегда возможно полностью избавиться.

Селектор выдаёт на компьютер сигналы при нажатии его кнопок. Вид кнопок определяет сам игрок, размещая нужные ему блоки в интерфейсе селектора. Быстрый старт: Ставим селектор, по ПКМ заходим в его интерфейс, расставляем любые 9 блоков внутри. Эти 9 блоков будут 9 кнопками селектора на них можно нажимать ПКМ. Через адаптер подключаем селектор к компу. Теперь при нажатии на кнопки селектора компьютер будет принимать сигналы о нажатии. Внимание! Сигналы селектора имеют нестандартный формат вида "slot_click", slot_number, address. Также была тема о том, что событие выдаёт адрес не самого селектора, а чего-то другого. Это надо проверять.

@HixOff задал в чате вопрос об интеграции Advanced Rocketry с OpenComputers: Отвечаю: На данный момент возможна частичная интеграция этих модов. Максимум, чего удалось достичь мне, это получить доступ к инвентарям машин с помощью мода OpenPeripheral.

У меня этот трюк не проходит: $ lua5.2 -e 'math.randomseed()print(math.random())' lua5.2: (command line):1: bad argument #1 to 'randomseed' (number expected, got no value)