Doob

В 13.04.2025 в 01:16, Subss6 сказал:

Сейчас не сезон, тут всегда так тихо или все что можно уже написали?

Старые игроки выросли из майнкрафта, а свежее мяско не прибывает.

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

К тому же мод не очень популярный и не развивается.

Кто-то в дискорде ссылку кидал, уже есть сервер, моды в процессе допиливания.

Не помню, как у транспозера, но у контроллера тег просто gzip'ом пожат.

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

local l_x, l_y, l_z = 1427, 44, 816 -- координаты центральной точки
local setblock, block = 'setblock ', ' minecraft:redstone_block'

local run = require('component').debug.runCommand
local sqrt = math.sqrt

local collision = {
  [16] = true,
  [18] = true,
  [22] = true,
  [24] = true,
  [30.757112998459] = true,
  [32] = true,
  [32.326459750489] = true,
  [33] = true,
  [36] = true,
  [36.837480912788] = true,
  [44] = true,
  [48] = true
}

for x = 0, 32 do
  for z = 0, x do
    for y = 0, x do
      if collision[sqrt(x^2 + y^2 + z^2)] then
        for xm = -1, 1, 2 do
          for ym = -1, 1, 2 do
            for zm = -1, 1, 2 do
              run(setblock .. l_x + x*xm .. ' ' .. l_y + y*ym .. ' ' .. l_z + z*zm .. block)
              run(setblock .. l_x + z*xm .. ' ' .. l_y + y*ym .. ' ' .. l_z + x*zm .. block)
              run(setblock .. l_x + y*xm .. ' ' .. l_y + x*ym .. ' ' .. l_z + z*zm .. block)
            end
          end
        end
      end
    end
  end
end

Для разных расстояний разные вероятности, в среднем при однократном сканировании бывает около 30% ошибок от общего числа, это ~216 блоков на весь объем.

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

Чтобы узнать плотность всех блоков на 100% требуется затратить примерно на 30% больше энергии и времени из-за дополнительных сканирований. (19% если немного усложнить алгоритм)

Если надеяться на удачу и повторно сканировать блоки только с явной коллизией, то в худшем случае, будет потрачено в 2.4 раза больше энергии и времени.

Вот списки расстояний с коллизиями руды и окружающей породы:

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

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

Поэтому лучше потратить энергию на сканирование и тогда абсолютная точность будет достигнута для объема 65x65x63.

local robot = require('robot')
local component = require('component')
local tunnel = component.tunnel

local function send()
  local qty = 0
  for i = 1, 12 do
    qty = qty + robot.count(i)
  end
  tunnel.send(qty)
end

local event = require('event')
local term = require('term')

while true do
  local e = {event.pull()}
  if e[1] == 'modem_message' then
    term.clear()
    term.write(e[6])
  end
end

Да, обучал на питоне, модель конвертировал в Lua-табличку.

Свертки "в лоб" работают очень плохо O(n^2) против O(n*log(n)) на нормальных алгоритмах.

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

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

Нейронка или дерево? Я как-то сделал сверточную нейронку для MNIST'a, распознавание числа занимало около 1600 тиков.

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

local component = require('component')

local function get_tickets(item, min_qty, side) -- получаем имя предмета, количество и куда перемещать
  if not component.isAvailable('chest') then -- проверяем наличие сундука
    return nil, 'нет сундука'
  end
  local chest = component.chest -- линкуем сундук
  local stacks = chest.getAllStacks() -- получаем инвентарь
  local counter, slots, c_item, moved = 0, {} -- создаем счетчик, список слотов и текущий предмет
  for k, v in pairs(stacks) do -- пробегаем по слотам
    c_item = v.basic() -- линкуем основную информацию о предмете
    if c_item.id == item then -- если имя совпадает
      table.insert(slots, k) -- добавляем слот в список
      counter = counter + c_item.qty -- обновляем счетчик
    end
  end
  if counter >= min_qty then -- условие допилить под свои нужды
    moved = true
    for i = 1, #slots do -- бежим по слотам
      chest.pushItem(side, slots[i]) -- выгружаем предметы
    end
  end
  return moved, counter -- возвращаем количество
end

local status, tickets = get_tickets('minecraft:stone', 3, 'DOWN')
if status then
  print('получено ' .. tickets .. ' билетов') -- обрабатываем удачную ситуацию
else
  -- обрабатываем исключение
end

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

Да, рабочая штука. Еще MIPS и DCPU-16 попадались, но один удалили, другой не собирается.

Дебага вроде не работала с плагинами без специального аддона. Или то вообще была кастомная дебага, короче встроенная не работала.

Конвертацию итемов в цифру и переводы? Какой именно плагин? Какая СУБД? Как сервер устроен, через локалхост конектиться надо?

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

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

Шта? Алмазная кирка всегда ломала паутину.

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

Алгоритм добычи дубокопа где-то на 50 строк влезет, а что-нибудь более совершенное и в 20 войдет.

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

У дронов такого слота нет, поэтому они могут имитировать только пустую руку.

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

Это ведь прикладная задача. Берешь код, вставляешь в свою прогу и пользуешься.

Вообще, это была отсылка к алхимическим трактатам, но да ладно.

Хотелось, чтобы была загадка, да и в теме по ссылке больше информации, хотя многое довольно расплывчато.

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

Я даже на этом шаге "завис" на минуту. Во что мы обращаем формулу? Что мы вычисляем в итоге, где знак равенства, черт побери?

Там вроде все ясно, нить рассуждений не прерывается, есть формула из кода, мы берем обратные функции и получаем формулу для извлечения неизвестного значения. Знак равенства пропал, т. к. это функция f(x) и мы не можем пока записать результат, иначе можно запутаться.

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

Что мне даёт этот срандомленный байт? Ну 15, ну 120, а что дальше? Какова именно логика определения, угадали мы плотность или нет?

Далее по тексту это проясняется.

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

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

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

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

Берем результат сканирования, вычисляем на его основе RANDOM_BYTE, берём от него дробную часть... А зачем? Откуда взялись магические константы 0.9998 и 0.00005? Что означает это сравнение? Пытаюсь перевести на человеческий: "если RANDOM_BYTE является целым или почти целым числом, то плотность блока валидна".

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

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

Да вроде не, нижняя точка графика в -300 и диапазон signed byte в [-127, 127) как бы намекают... или по какой-то причине график построен в ином масштабе.

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

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

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

Ха, у меня еще со школы проблемы с усвоением материала, так как он везде подается в этой манере. Да и у кого таких проблем нет? Разве кому-то нравится математический язык?

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

Достаточно добавить буфер для неотправленных сообщений, получится динамический A*. Эксперименты показывают, что прервать передачу можно только изолировав/отключив узел до того как он отправит сообщение, а против этого ни у какого протокола нет защиты.

Беда в том, что модемы работают крайне медленно, в реальных устройствах обмен данными идет очень быстро и два майнкрафт-тика, для настоящего сетевого интерфейса это бездна времени.

Остается только гонять динамический A*, других вариантов не вижу.

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

Если только соседей, то может не обнаружить потерю узла, стоящего за соседним.

Да, как раз это и надо как-то хитро обойти.

Для частной магистрали вполне годится и так, там администратор сети отвечает за узлы.

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

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

Насколько хорошо поддерживается изменение топологии сети?

По таймеру каждые 30 секунд пингуются соседние узлы, в это время происходит сброс всех маршрутов и восстановление из поступающих ответов. Из-за медлительности пинг-понга может потеряться сообщение. Хотел добавить очередь для неотправленных сообщений, но почему-то не сделал. Скорее всего проблема будет в том, что при изменении топологии, с условием, что узел держащий сообщение, потерял связь с целевым, перенаправит по новому маршруту (следовательно, сообщение может вернуться к отправителю и будет гулять туда-сюда 2-3 раза).

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

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

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

Что собой представляет адрес?

Как он генерируется?

Как узнать свой адрес?

Адрес это UUID сетевой карты, работает так же как обычный modem.send

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

А можно ли узнать адрес отправителя?

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

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

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

Если узел не успел получить новый маршрут, то да, потеряется.

Наверно стоит сделать пинг перед отправкой сообщения, а не по таймеру. Будем тестировать.

А если мне не надо все файлы качать? Зачем мне ридми, тесты, лицензия?

В свое время я это сделал проще - качается файл version.lua, в нем текущая версия программы и список файлов, если версии не совпадают, то программа качает файлы и перезапускается. Потом я это немного переосмыслил и сделал в виде бутлоадера.

Бутлоадер представляет собой замену Lua BIOS, с функционалом, позволяющим устанавливать и обновлять программы без операционки. Сам обновляется, обновляет нужные файлы, ставит вейкап сообщения на модем, связанную карту и редстоун.

1. В одиночной игре создать комп командой /oc_sc, пристыковать к нему геолайзер, поставить на него исследуемый блок и в lua запустить component.geolyzer.analyze(1).hardness

2. Если она не вынесена в конфиг (что вряд-ли), то только править код мода.