eu_tomat

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

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

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

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

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

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

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

@eu_tomat она рисует немного иначе. Она обучается на точках, твоих точках.

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

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

надо изучать, как ведёт себя функция isUnobstructed.

Действительно, есть помеха от блоков.

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

Ошибки в моём эксперименте:

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

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

The hardness of blocks in the path is subtracted from the strength. Some randomness is applied to the strength.

А как это подтвердить экспериментально? В каких случаях этот эффект проявляется, и насколько сильно?

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

4 часа назад, ECS сказал:

4к строчек для одной проги, УВОЖАЮ

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

Были же раньше мастера!

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

В 27.12.2021 в 23:45, Disc2 сказал:

Помимо прочего у беспроводных карт есть просчет "препятсвий" при отправке сообщений - наличие каких-то блоков между отправителем и принимающим уменьшает рабочий радиус беспроводных сетевых карт.

Откуда такие сведения? Вроде нет такой физики в OpenComputers.

23 часа назад, eu_tomat сказал:

переписывать GUI придётся очень муторно.

А может, и не придётся, если играть с ComputerCraft в сингле. На серверах же сейчас найти ComputerCraft весьма не просто. В лучшем случае есть OpenComputers.

@Duoh Если не трудно, кинь ссылку на ту версию GregTech, с которой сейчас играешь. Хочу ещё раз пощупать термоядерные реакторы.

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

21 минуту назад, Belzebub сказал:

в lua то был.

В обычном Lua os.time возвращает время на компьютере.

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

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

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

17 часов назад, xOCAx сказал:

жезл успешно заряжен зарядка сошла с ума

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

А ещё хотелось бы видеть в этой теме скриншоты установки и GUI программы.

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

И если термоядерные реакторы в 1.7.10 работают, то скрипт переписать можно. Но переписывать GUI придётся очень муторно.

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

в майносевском примере я так и поступил

Ой! Пример-то для майноси я пролистал не глядя. Я эту 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.

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

event.timer( interval, function() -- Примерное значение TPS рассчитывается как расхождение между желаемым интервалом в 1 сек и фактическим, -- полученным через разницу в датах изменения временного файла local tps = interval / (getRealTimestamp() - lastModified) * 20000

Этот код работает более-менее правильно при условии, если таймер не блокируертся основным кодом. Например, если сразу за кодом таймера запустить os.sleep достаточной продолжительности.

Но если вместо os.sleep будет что-то вроде этого for i=1,1e8 do end, то TPS окажется сильно заниженным.

Проблему можно решить, если в расчётах использовать не значение interval, а разницу между computer.uptime в моменты запроса getRealTimestamp().

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

Хочу мерить tps-ы, не блокируя поток.

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

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

грёбанный разработчик опенкомпуктерс, зачем он убрал оригинальный os.time?(((

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

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

с 1-ой сетевой карты нельзя отправить на 2-ю и наоборот, но если использовать одинаковые то всё принимается, ето и была причина

Что значит "1-ой" и "2-ю"? Имеется в виду уровень плат?

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

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

Результаты:
Компьютера принимают и отправляют сообщение, даже робот, мир плоский, стоит только основной мод, странно идеально

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

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

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

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

4.Единственная модификация это увеличенный размер памяти на всех плашках, это мой сервер, мы играем с другом и я попутно делаю программу
5.В одиночной игре тоже самое

Очень хорошо. Давай проведём эксперимент. Для этого потребуется:

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

• Сообщить о результатах.

19 минут назад, Bumer_32 сказал:

Я так и не понял. интерфейс есть?

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

В 08.10.2021 в 13:25, tapelineyt сказал:

Нема API.

23 минуты назад, Oleshe сказал:

Я отсылаю на порт робота, возьмём 1, функцией broadcast, a робот не принимает с event.pull, оно не принимает ничего, почему? Но если с пк на пк, то получается. У робота есть сетевая карта, и пк тоже, так почему? Может из-за того что я на сервере?

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

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

В OpenComputers нет черепах. Есть роботы, их более функциональные аналоги.

API роботов: https://ocdoc.cil.li/api:robot

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

API компонента Filesystem: https://ocdoc.cil.li/component:filesystem

Не особо отличается от API файловой подсистемы OpenOS.

Главное отличие, пожалуй, в отсутствии монтирования. И работа с файлами ведётся через дескриптор, а не таблицу файлового потока.

У меня несколько замечаний по этому заказу.

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

Требования к ПО:  ... Наименьшая нагрузка на сервер minecraft, которая только возможна.

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

А можно взглянуть на код программы, которую забраковали админы? Может быть, её уже и не написать лучше. Так тоже бывает: ну, будет программа процентов на 10 менее прожорливой, админы её всё равно не разрешат использовать.

40 минут назад, num_pi сказал:

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

В этом месте сразу приходит идея: не надо каждый раз перепроверять все 500 вещей в базе, а все крафты выполнять централизованно на основе OC. Тогда OC будет знать о всех крафтах и актуальных остатках предметов. А если игрок вручную работает с МЭ-системой, то пусть по окончании операции нажимает плиту, например. Тогда не потребуется выполнять ежесекундно по 20 запросов и выполнять по 100500 сравнений. Это основа всех оптимизаций: выполнять вычисления только тогда, когда это необходимо.

54 минуты назад, num_pi сказал:

Писать без использования мета таблиц!

А что не так с метатаблицами кроме неявного вызова функций?

@Belzebub Какая у тебя версия OpenComputers?