Вероятно, в моде openperephiral не реализована поддержка анализатора. Поэтому анализатор не выводит информацию о компонентах, но сами компоненты подключаются. Информацию о подключенных компонентах можно получить через команду components. Анализатор будет работать, если подключить компоненты мода openperephiral через адаптер (кликать по адаптеру).

37 минут назад, Disc2 сказал:

Т.е.  для лучшей связи нужно двигать роботов к границе чанка?

Прокопать туннель 3x3 до границы загруженной области.

50 минут назад, Disc2 сказал:

Получается в теории, это можно использовать как Nocom чтобы искать активные чанки с игроками?

 

Наверное, да.

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

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

Никакие чанки не загружаются при отправке сообщения. В isUnobstructed перед получением блока вызывается функция blockExists, которая проверяет загружен ли чанк по указанным координатам.

Вот код функции World::blockExists:
 

/**
 * Returns whether a block exists at world coordinates x, y, z
 */
public boolean blockExists(int p_72899_1_, int p_72899_2_, int p_72899_3_)
{
  return p_72899_2_ >= 0 && p_72899_2_ < 256 ? this.chunkExists(p_72899_1_ >> 4, p_72899_3_ >> 4) : false;
}

World::chunkExists:

/**
 * Returns whether a chunk exists at chunk coordinates x, y
 */
protected boolean chunkExists(int p_72916_1_, int p_72916_2_)
{
  return this.chunkProvider.chunkExists(p_72916_1_, p_72916_2_);
}

вот реализация chunkExists в классе ChunkProviderServer (экземпляр именно этого класса хранится в поле chunkProvider класса WorldServer, который и представляет мир на сервере):

/**
 * Checks to see if a chunk exists at x, y
 */
public boolean chunkExists(int p_73149_1_, int p_73149_2_)
{
  return this.loadedChunkHashMap.containsItem(ChunkCoordIntPair.chunkXZ2Int(p_73149_1_, p_73149_2_));
}

Так что при отправке сообщения помехи добавляются только от блоков в загруженных чанках. Блоки в незагруженных чанках просто игнорируются.

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

Тут надо прояснить термины. Какой чанк можно считать загруженным?

 

Игрок считает загруженным тот чанк, в котором протекают какие-то игровые процессы. Требуется ли загрузка чанка именно в этом смысле, для того чтобы прочитать плотность блока? Скорее всего, нет. Тогда и выгрузка не требуется. А иначе можно было бы с помощью двух чанклодеров поддерживать активными не 18 чанков, а 38.

 

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

 

Или как оно работает в Майнкрафте?

ЕМНИП, world.blockExists проверяет загружен ли чанк. Так что проверка плотности осуществляется только для блоков в загруженных чанках.

 Уточню, достаточно просто сменить рабочий каталог на / перед запуском. Исполняемый файл программы может быть расположен в любом каталоге. Предположим, что программа установлена в /home:

cd /
/home/<здесь подставить название программы>

Но лучшим решением, конечно, является модификация программы:

6 часов назад, eu_tomat сказал:

Проблему можно решить радикально, дописав в коде shell.resolve при вызове fs.exists

Надеюсь, @Totoro сделает это.

В 10.01.2021 в 13:10, ecyc сказал:

привет. я вот тоже новичок во всем этом моде, но программа классная, и я установил её к себе. Но проблема в том, что при каждом запуске программа перезаписывает все три файла (doorlist, userlist и alarlist) и потом говорит, что нет таких файлов, создаются пустые списки. И действительно, заменяет те файлы, которые были заполнены, на пустые, и все приходится каждый раз настраивать. Особенно неудобно, если комп выключился, и приходится опять все настраивать. Надеюсь на поддержку) 

Программа работает правильно только когда запускается из корневого каталога. То есть нужно перейти в корневой каталог и запустить программу оттуда.

ps

проблема похоже в том, что fs.exists ничего не знает про рабочий каталог шелла

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

// This shouldn't really happen due to delays being enforced, but just to

// be on the safe side...

Что-то с сервером накрутили.

На серверах эта ошибка очень часто встречается.

Так для этого и нужна обёртка, проверять на ошибку "already moving" в одном месте. Как-то так:

function robotMove(side)
  --здесь вызываем component.robot.move()
  -- повторяем в случае ошибки "already moving"
end

function robotForward()
  return robotMove(sides.front)
end

...

А goTo? там проверок нет. В коде есть обёртки для методов поворота. Так что добавление обёртки для методов перемещения напрашивается само собой.

3 минуты назад, serafim сказал:

При получении ошибки "already moving" обнуляем счётчик попыток движения

Это решит проблему возврата робота, но останется:

20 часов назад, van2614 сказал:

И еще заметил, что по пустоте он передвигается гораздо медленнее, если рядом нет никого. Копает примерно одинаково.

7 минут назад, eu_tomat сказал:

стало понятно, что надо не swing() выполнять, а повторить forward().

9 часов назад, eu_tomat сказал:

причина возврата: already moving (уже движется) ,занятно

Нужна обёртка вокруг функции component.robot.move, которая будет перехватывать эту ошибку и повторять перемещение.

Можно использовать потоки. Обработчики событий и таймеры будут удалены при завершении потока.

Интересная идея. Мне кажется, зарядка робота на небольшом расстоянии (может быть блоков 8? или даже меньше) с энергопотерями не будет читерной. Тем более приемник, будет занимать слот под апгрейды, которых всегда не хватает.

Умеет же зарядник OC заряжать наниты на расстоянии. И у зарядки робота на расстоянии применение найдётся.

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

@vx13  сейчас только проблемка осталась, что при component.inventory_controller.equip() инст из блэк-листа вылетает из робота и валяется подле него. Воронками и через гуи все норм, "запретка" блочится при попытке положить ее в слот.

Ага. Вот и проблема.

2 часа назад, NEO сказал:

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

При таком решении метод equip выбрасывает инструмент в мир. Что делать в этом случае? Метод equip выбросит инструмент в мир и вернёт true. Не выполнит перемещение и вернёт false. Не выполнит перемещение и вернёт true. Три варианта. Какой выбрать? Как отреагирует на такое программы-копалки?

Не знаю проверяет ли кто-нибудь возвращаемое значение метода equip (в OC у робота оно всегда true и я его никогда не проверял), но уверен что нормальные копалки проверяют успешность метода swing и не сломаются от неизвестного кода ошибки.

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

А фикс выключения компа присутствует?

добавили в апстрим

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

я например вижу решение запретить класть в робота вообще из листа

А если инструмент уже у робота в руке? Добавление его в блэклист не удалит его из руки. Но да, запрет на размещение инструмента не будет лишним.

Да, но только для предметов, которые реализуют ItemHandler Capability (mc1.12) или если для предмета реализован драйвер в OC (li.cil.oc.api.driver.InventoryProvider).

Для работы с инвентарём предмета нужно использовать контроллер инвентаря. Методы: getItemInventorySize, suckFromItemInventory, dropIntoItemInventory.

На 1.12 есть мод Common Capabilities, который добавляет ItemHandler Capability в ящики шалкера и в рюкзаки Thermal Expansion.

В моде OC реализованы драйверы для сервера и базы данных.

OMA-1.7.10-3.1.0.jar

v3.1.0

• Добавлено: Печной генератор. Генерирует OC энергию. Потребляет стандартное топливо для печи.
• Исправлено: Проблемы при использовании на солнечной панели жезлов с набалдашниками «Перемещение» (из ThaumicTinkerer) и «Червоточина» (из Thaumcraft). Эти жезлы теперь не работают на блоках солнечной панели.

v3.0.0

• Исправлено: Сетевая карта не связывается с солнечной панелью щелчком правой кнопки мыши.

v3.0.0-alpha.3

• Добавлено: В метод tesla.attack добавлен параметр range.
• Добавлено: Спавн частиц при выполнении tesla.attack.
• Добавлено: Солнечная панель принимает команды только с определённого адреса (задаётся командой setCommandSource или ПКМ сетевой картой по панели).
• Изменено: Обновлены текстуры.
• Исправлено: Ошибки в локализации.
• Исправлено: Ошибки в документации компонентов.
• Исправлено: Некорректное отображение блоков солнечной панели в подсказках Waila.
• Исправлено: Краш клиента во время воспроизведения звука сервомотора солнечной панели.

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

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

Может как-то сделать, чтобы сетевухой с адресом ПКМ прокликать по соляркам и чтобы они записали в нбт адрес этой карточки и получали команды только от нее?

Я думаю, что это вариант самый безопасный.

35 минут назад, NEO сказал:

Я сделаю защиту)))

38 минут назад, Alex сказал:

да, "перехват" прикольная штука 

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

А если периодически менять порт (и до первой команды setPort ограничить радиус приема). В этом случае подобрать порт будет сложно.

39 минут назад, Alex сказал:

а, кстати, и опционально радиус поражения тоже добавите в новой версии в этой которая будет когда-то, да?
типа tesla.Attack(3) например, как в вайфайке, но не более максимального в конфиге?

да

2 часа назад, Alex сказал:

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

Нет не фича.

Мне удалось воспроизвести проблему при слабом уровне сигнала только. При дефолтной мощности и компе рядом проблема не наблюдается.

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

А точка приема сигнала (центральный блок в нижнем слое) окружена со всех сторон (кроме нижней) блоками панели которые имеют прочность 3,5.

3 часа назад, Alex сказал:

Можно конечно и дублировать, и даже три раза для надежности пускать команды, но тогда многократно возрастает шанс перехвата бродкаст управления и "раскрытия" канала(порта).

В следующей версии панели будут принимать сигнал только с определённого адреса. А до его установки командой setCommandSource принимают сигнал только от ближайших источников. Это должно решить проблему с перехватом управления.

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

а что у тебя? У меня Waila-1.5.10_1.7.10.jar,  другие блоки из мода показывает в тултипе. Тайл солярочки нет

Да, в waila не показывает. Я через nei смотрел. Нужно разбираться.

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

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

Так и сделаем.

6 минут назад, Alex сказал:

а хотя бы нейм и картинку тайла в тултипе вавлы как-то прикрутить

Странно. Должно показывать.  https://imgur.com/a/42vsuXf

11 минуту назад, Alex сказал:

она так и должна только центральным "яблочком" видеть "небо". Все остальное у солярки - это просто бокс коллижн модели, он в расчет не берется

Сейчас проверяется только центральный блок. Но можно и все 9 проверять.