eu_tomat

26 минут назад, hohserg сказал:

Можно увеличивать силу сигнала при движении вверх(поводок растягивается), и уменьшать в неподвижном состоянии, так еще эффективнее будет

А по какой формуле растягивается поводок?

1 час назад, hohserg сказал:

А на сколько времени заряда без апгрейдов и с ними хватает?

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

8 минут назад, BrightYC сказал:

component.modem.broadcast(1, '')

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

А если широковещательная передача отсутствует в штатном режиме, то ничто не мешает использовать уже имеющийся список адресов в нештатной ситуации тоже.

1 час назад, BrightYC сказал:

А для чего вообще вейкапы нужны в штатной работе?

Кстати, злоумышленник может сделать нештатную ситуацию вполне себе штатной и прогнозируемой.

43 минуты назад, BrightYC сказал:

А для чего вообще вейкапы нужны в штатной работе? Выключать робота...

В основном приходится включать, а не выключать.

Например, есть свидетельства о самопроизвольном отключении роботов в незагруженных чанках. Да и при сильных лагах сервера робот может отключиться по TLWY. Ищи поэтом этих роботов в шахтах. А по свистку они сами проснутся и приползут в назначенную точку. Или, например, возобновят сбор кактусов. Тут не грех и дополнительную инфраструктуру нагородить.

А в гриферских задачах робота можно и отключить в ожидании удачного момента для действий.

16 минут назад, Fronun сказал:

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

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

Для одного-двух компьютеров сэкономленные усилия не окупают времени на скачивание и установку программы. Тем более, установщик требует сетевую карту.

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

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

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

14 часа назад, DevilPuppy сказал:

понравилась загрузка "MineOS" и решил заменить стандартные загрузчик "OpenOS" на аналог)

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

1 час назад, 6xadg сказал:

Как достать данные о игроках из таблицы EntityDetector? Пытался смотреть по индексам, но возвращает либо саму таблицу, либо nil

Вот сам код, собственно (простите за качество, пока просто пытаю понять, как это работает):

entity = require("component").os_entdetector

local e = entity.scanPlayers(10)
print(e)
print(e.name)
print(e[1])

 

Мне не совсем понятен вопрос, отвечу как понял. Вывод информации об игроках может выглядеть, например, так:

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

2 минуты назад, hohserg сказал:

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

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

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

5 часов назад, Asior сказал:

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

Да, эта схема переноса заряда несовершенна. Но она рабочая.

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

36 минут назад, Totoro сказал:

Я вроде, когда код OpenComputers листал, видел что он там как раз балансирует уровень энергии во всей сети.

Старые версии OpenComputers я сейчас не проверял. Но мне почему-то помнится, что раньше батареи высасывались равномерно. Сейчас я поверил на OpenComputers-MC1.7.10-1.7.5.1290-universal.jar: сначала высасывается батарея из апргейда, вставленного в робота первым. Но не факт, что я правильно интерпретировал результаты наблюдения.

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

Через computer.getDeviceInfo() мне удалось вытащить только ёмкость батареи, текущий же уровень заряда неизвестен. А сколько может быть запасено энергии в апргейде опыта, вообще приходится вычислять через его уровень.

5 часов назад, Asior сказал:

Не хватает роботам или модуля распределителя энергии или правок в коде по приоритетам использования батареек.

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

• Получить максимальную ёмкость;
• Получить текущий запас энергии;
• Задать/получить приоритет заряда (например, числом 0..15);
• Задать/получить приоритет разряда.
• Задать/получить скорость заряда внешних объектов этим компонентом.

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

9 минут назад, hohserg сказал:

Здравствуйте! У дрона есть возможность извлекать и помещать предметы и жидкости между своим инвентарем и внешними хранилищами. А может ли он отдавать энергию?(принимать может - через зарядник)

Вряд ли существует механизм, позволяющий дрону отдавать накопленную энергию непосредственно.

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

Да, неожиданно вышло. Уроки из этого вопроса можно извлечь такие:

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

Пожалуй, дам теме более адекватное название.

2 минуты назад, Kingdom сказал:

Выдаёт "bad argument #1"

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

Только что, Kingdom сказал:

key

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

1 минуту назад, Kingdom сказал:

Я сохранил. А как её запустить?

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

1 минуту назад, Kingdom сказал:

Не пишет ничего, я не особо разбираюсь в этом, код, что есть в оригинале, я его переписал, вот и всё. Свернул с Ctrl+W, так как автор говорит, что она работает в фоне, но как - не знаю.

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

5 часов назад, Kingdom сказал:

Keypad к адаптеру подключил, код програмки свернул, но ни интерфейс Keypad'а не поменялся, красный камень не реагирует. Требуется помощь, в общем.

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

5 минут назад, Fingercomp сказал:

А, кстати, точно, скорее всего, они ещё и не выталкиваются. Ну, тогда ответ ещё проще становится.

Да, роботы поршнями не выталкиваются. Остаётся только взлом по сети.

Кабели тоже не заталкиваются поршнями. А плата из computronix, поддерживающая подмену адреса, не работает по воздуху.

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

Ответ на поставленный вопрос:

В 08.12.2019 в 16:15, Kingdom сказал:

возможно ли взломать чужой робот? Допустим, стоит он на спавне и, с помощью компа или планшета перехватить контроль к нему?

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

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

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

В 08.12.2019 в 16:40, Fingercomp сказал:

Берём планшет с апгрейдом-поршнем, выталкиваем робота со спауна и ломаем киркой.

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

10 минут назад, Asior сказал:

А можно просто создать файл и глянуть на дату его создания. Тогда чанклодер не требуется, программа просто будет обновлять данные ну скажем раз в 20 сек, этого вполне достаточно чтобы игрок прогрузил обстановку, сообразил что где и куда глядеть

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

10 часов назад, lLoki сказал:

ну она както работает у игроков в магазинах 

Работать она обязательно будет, но ключевое слово здесь "как-то".

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

19 часов назад, lLoki сказал:

у каво есть такой скрипт чтоб там писало когда последний раз заходил в игру игрок 

Именно такого скрипта я не встречал, но можно немного доработать программу "Мониторинг онлайна", прикрутив к ней получение и вывод времени.

Поиск идеальных соотношений сторон монитора.

Задача: найти такие конфигурации мониторов, для которых существуют  разрешения, при которых ширина вертикальной и горизонтальной чёрной рамки одинакова.

Очевидно, что для квадратных мониторов существует множество разрешений, удовлетворяющих заданному условию. Достаточно, чтобы разрешение по горизонтали было вдвое больше разрешения по вертикали. Но количество возможных решений для мониторов с конфигурациями, отличающимися от квадрата, сильно ограничено. Более того, идеальное разрешение существует не для всех конфигураций мониторов.

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

-- Вычисление идеальных разрешений для мониторов разных размеров
-- Не проверяются квадратные мониторы с размерами 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, удивил. Один вопрос: как ты ухитрился разглядеть эту четверть пикселя? Или ты её чтением кода нашёл?

12 минуты назад, BrightYC сказал:

От неё можно избавится? Ну разве что чёрный фон 

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

8 часов назад, Totoro сказал:

Тебе надо в коде программы поиграться с числами вот в этих строках:

...

Чтобы чёрные полоски пропали - нужно чтобы соотношение ширины и высоты у разрешения, которое ты ставишь, было пропорционально ширине и высоте экрана (который многоблочный у тебя стоит), минус толщина рамок.

Добавлю к сказанному:

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