eu_tomat

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

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

Я провёл эксперимент. На одной линии уставил 4 компьютера. Первый компьютер непрерывно рассылает широковещательные пакеты на первый порт. Через десяток чанков второй компьютер также рассылает пакеты, но на второй порт. Ещё чанков через 10 установлен третий компьютер. Он отображает все пойманные широковещательные пакеты. В норме он не слышит никаких пакетов, если не загрузить чанки, содержащие первый или второй компьютер. Для теста ставим чанклодеры сначала к первому компьютеру, затем ко второму. На третьем компьютере следим за поступлением пакетов. В чанк с первым компьютером ставим чанклодер, а на сетевой карте открываем порт с номером, например, 4. В чанк с третьим компьютером ставим четвёртый компьютер и с него непрерывно рассылаем пакеты в 4 порт. Что в результате я ожидал увидеть? Линия передачи от четвёртого компьютера к первому лежит через чанк со вторым компьютером. Рано или поздно будет запрошена плотность блока из этого чанка. И если чанк загрузится, второй компьютер возобновит рассылку пакетов на второй порт. И это можно будет увидеть на третьем компьютере. Но на нём я увидел лишь передачу с первого компьютера. Вывод: Либо чанк со вторым компьютером не загрузился, либо такая загрузка чанка не приводит к возобновлению работы компьютера, либо эксперимент поставлен неверно.

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

То есть, мы задаём цвета и координаты каких-то определённых точек, а нейронка подстраивает свои параметры так, чтобы добиться соответствия цвета в этих конкретных точках?

Действительно, есть помеха от блоков. Физика интересная. Сигнал распространяется по прямой линии в канале сечением 3x3. Суммарная помеха вычисляется из плотностей нескольких случайно выбранных блоков в этом канале. Может, например, оказаться, что всё это блоки воздуха. Или наоборот, самые плотные блоки. Любой из блоков может быть выбран повторно, что ещё сильнее увеличивает разброс средней плотности. Ошибки в моём эксперименте: Я выполнил единственную передачу и она оказалась успешной. Последующие могли быть и не столь удачными. Я заложил камнями отрезок от компьютера до компьютера, но это не весь канал а лишь одна девятая его часть. Это снизило вероятность неудачи. Я использовал обычный камень. Думаю, алмазная руда смогла бы внести более серьёзную помеху.

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

Ручная работа времён Античности. Растровое изображение вырезано из цельного куска мрамора. Были же раньше мастера!

Эта тема является продолжением решения вопроса о трудностях обмена пакетами в беспроводной сети OpenComputers. Здесь обсуждается влияние на дальность доставки пакетов не только силы сигнала и препятствий в виде блоков, но и других факторов. Откуда такие сведения? Вроде нет такой физики в OpenComputers.

А может, и не придётся, если играть с ComputerCraft в сингле. На серверах же сейчас найти ComputerCraft весьма не просто. В лучшем случае есть OpenComputers. @Duoh Если не трудно, кинь ссылку на ту версию GregTech, с которой сейчас играешь. Хочу ещё раз пощупать термоядерные реакторы. Последний раз я их строил в 2013-2014 году и вроде бы тоже в 1.4.7. Строил башни из рейлкрафтовских конденсаторов влаги, электролизёры и ряды центрифуг. Но на 1.7.10 эти реакторы у меня не заработали. Не помню уже, почему.

В обычном Lua os.time возвращает время на компьютере. В Lua на OpenComputers os.time точно также возвращает время на компьютере. Но не на реальном, а игровом компьютере, где в норме время идёт в 72 раза быстрее времени на сервере. В общем, логика в таком выборе присутствует. На автора грех жаловаться: любой желающий может сделать форк с нужными ему возможностями.

@Syabro А какие критерии обучения этой сети? Как она понимает, что очередная картинка получилась лучше или хуже?

Можно было бы сказать проще: "жезл не заряжается". Судя по коду, процесс зарядки отслеживается по изменению NBT предмета. А почему NBT не меняется? Может быть жезл до конца заряжен. Может быть, зарядить его нечем. А может, это и не жезл вовсе. Может, что-то сломалось. А ещё хотелось бы видеть в этой теме скриншоты установки и GUI программы.

@Duoh Это скрипт управления термоядерным реактором GregTech что ли? И, кстати, разве версия GT для 1.7.10 поддерживает эти реакторы? Помню, что-то неладное было с ними при переходе на новую версию. Вроде бы их вообще удалили из мода. И если термоядерные реакторы в 1.7.10 работают, то скрипт переписать можно. Но переписывать GUI придётся очень муторно.

Ой! Пример-то для майноси я пролистал не глядя. Я эту OS даже не запускал ни разу, не то что программы для неё изучать. Штука, конечно, прикольная, но я так и не смог придумать, зачем лично мне нужна MineOS. Прошу понять и простить.

Для иллюстрации предыдущего поста написал короткую демонстрацию: local event = require"event" local uptime = require"computer".uptime local t, t_ local function onTimer() t_ = t t = uptime() print( (t-t_+0.025)//0.05 ) end t = uptime() event.timer( 1, onTimer ) os.sleep( 1.1 ) t = uptime() event.timer( 1, onTimer ) for i=1,2e8 do end os.sleep( 1.1 ) Результаты: 20.0 52.0 Как можно видеть, нет гарантии выполнения события таймера строго в назначенное время. В первом случае таймер сработал строго через 20 тактов. А во втором случае потребовалось 52 такта, хотя предполагалось именно 20.

Этот код работает более-менее правильно при условии, если таймер не блокируертся основным кодом. Например, если сразу за кодом таймера запустить os.sleep достаточной продолжительности. Но если вместо os.sleep будет что-то вроде этого for i=1,1e8 do end, то TPS окажется сильно заниженным. Проблему можно решить, если в расчётах использовать не значение interval, а разницу между computer.uptime в моменты запроса getRealTimestamp().

А что именно там блокирует? Обычно же паузу ставят. Вот, вместо паузы делай что-нибудь полезное, а не просто жди.

Что значит убрал? Его и не было никогда в OpenComputers. И в ComputerCraft тоже никогда не было. И в документации об этом везде сказано.

Что значит "1-ой" и "2-ю"? Имеется в виду уровень плат? Как уже говорилось выше, платы первого уровня не могут принять сетевой пакет из-за бага. Отправить пакет они могут, но не далее 16 блоков.

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

Очень хорошо. Давай проведём эксперимент. Для этого потребуется: В одиночной игре создать новый мир в творческом режиме на плоской карте. Командой /oc_sc создать два компьютера через одну клетку друг от друга. В каждый компьютер вставить по одной беспроводной сетевой плате второго уровня. Запустить интерпретатор Lua на обоих компьютерах. В консоль одного компьютера вставить и запустить код component.modem.open(1)for i=1,10 do print(event.pull())end В консоль другого — component.modem.broadcast(1,"test") Посмотреть в консоль первого компьютера, принято ли наше сообщение. Там должно появиться что-то вроде "modem_message ... test" Сообщить о результатах.

Какой именно интерфейс? Этот?

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

В OpenComputers нет черепах. Есть роботы, их более функциональные аналоги. API роботов: https://ocdoc.cil.li/api:robot Также добавлю, что функционал роботов не ограничивается, собственно, API самих роботов. Поэтому имеет смысл ознакомиться с возможностями апргейдов: https://ocdoc.cil.li/component