artem211

Новости от Vexatos'a !

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

Оказалось, что ошибка появляется еще раньше чем в ход идут функции computronix. Во всём виноват Forge, который считает текст "test.test(6)[5]" ссылкой, но не может ее запарсить, так как она содержит квадратные скобки. Этот баг будет появляться во всех серверах на Кузнице.

 

Так что Артемка, хочешь что бы не выкидывало - проси удалить Forge.

 

Кстати, вышла новая версия CT.

Спасибо за информацию, буду руководствоваться.

Новое обновление вышло (система больше клонирует дизайн, чем его напоминает)С

Покажи товар лицом )) скрины фигач )

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

Значит, нужно подождать пока подобные ошибки будут появляться снова с более пордобными логами. Насколько я знаю, ошибки вызывают traceback - цепочку вызовов до ошибки. Это и нужно

Ждать нечего, просто заходишь на сервер и пишешь com.command(3)[32]

Интересно что будет если писать из консоли а не от лица игрока

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

К слову, это дерьмо опять началось, стоит написать в чат выражение типа geolyzer.scan(0,0)[32] ты вылетаешь с дисконнектом. Убираем квадратные скобки - все нормально. Осточертела эта хрень ей богу. Уберем мб чатбоксы к зеленым криперовым яйцам?

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

Нет врядли ) я жадный )

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

мб превентивно решить эту проблему? )

 

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

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

 

Есть код, который принимает системное имя предмета и если рецепт есть в списке - находит в сундуках ингредиенты и крафтит по рецепту. http://pastebin.com/E5yZVpUA

 

Надо, чтобы в рецептах можно было указывать метаданные предмета, например вот так:

REPICES = {
  --рецепт1
  [{"NAME", "META"}] = {
    {"NAME", "META"}, {"NAME", "META"}, {"NAME", "META"},
    {"NAME", "META"}, {"NAME", "META"}, {"NAME", "META"},
    {"NAME", "META"}, {"NAME", "META"}, {"NAME", "META"}
  },

  --рецепт2
  [{"NAME", "META"}] = {
    {"NAME", "META"}, {"NAME", "META"}, {"NAME", "META"},
    {"NAME", "META"}, {"NAME", "META"}, {"NAME", "META"},
    {"NAME", "META"}, {"NAME", "META"}, {"NAME", "META"}
  }
}
1-9 {"NAME", "META"} это список ингредиентов.
[{"NAME", "META"}] - результат крафта

Тебе в помощь апгрейд робота - база данных, там полный портрет предмета можно указать. Как в АЕ

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

 

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

 

Такой вот баг.

 

Нужно сходить с роботом в майнерс мир, подорвать крипера и потестить, что скажет робот при попытке прохождения через "невидимую стену" и как он её видит.

Очередной интеллектуал от программирования номер 2...

Опять кикает из клиента, когда пишешь в чат (старая песня, которая уже около года длится, на багтрекере 8 месяцев назад народ  писал про это )

http://puu.sh/iBoCv/45cc6b7ea1.png

http://puu.sh/iBon9/ab39668f65.jpg

 

Если за 3 дня не пофиксят, удаляю его к едрентевой бабке.

Сноси его к яйцам эндерменовским...поговорить не дает

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

очередной гениал, считающий что программа робота запускается и работает на клиенте, а не на сервере?

Монстрик. Вот эта хреновина

local robot = require("robot")

attempt = 0
while not robot.forward() do
	robot.swing()
  	attempt = attempt + 1

  	if attempt>15 then 
  		return false, 'имя блока впереди: инфа с геолайзера'
  	end
end

и так бьет 15 раз, но робот у него проехать не может все равно и возвращает воздух.  Это может быть только существо  (например, админ в инвизе  )

Если бы было существо - детект робота вернул бы не воздух, а энтити

Ты кроме geolyzer.analyze приставь robot.detect(). robot.detect() показывает всё,может это правда существо.

Асум ты слепой что ли?

Ищи баг. ЧЛ здесь не при чем. Он никак не влияет на то, что робот найдет блок или воздух. Тем более в радиусе 30 блоков от тебя ЧЛ нужен роботу, как рыбке зонтик. Ты грузишь 121 чанк сам.

 

Где-то ошибка в логике алгоритма.

Два раза без ЧЛ и два раза с ЧЛ не было ошибки, это еще ни о чем не говорит.

См выше запостил логику алгоритма. Мб я совсем дурак? или это особая "уличная магия" ?

Ищи баг в программе

Никаких препятствий там нет и быть не может. Скорее всего, твой робот уперся в задницу криперу. Ее он, кстати, может принять за воздух=)

 

Игрок грузит 10 чанков радиус, это раз. Второе. даже если робот выгрузится вместе с чанком, произойдет просто останов программы и при подгрузке чанка программа продолжит выполнение. Это же азы=)

Я специально 15 раз тестил в сингле поведение робота со всеми мобами встречающимеся в овере - все умирали а робот проезжал это раз. Препятствий нет это верно, но что то заставляет robot.forward(), robot.up(), robot.down() возвращать FALSE, причем в рандомных точках, а не точно в одних и тех же, 3 раза посылал без чл - ошибки, 2 раза с чл - ошибок нет, еще раз без чл - ошибки. Поясни что думаешь Алекс? Прога безотказна.

function APIS.mForw(action,arg)
--шаг вперед с действием или безБ сквозь породу, координатные отметки
 local r = require("robot")
 local event = require("event")
 local try = 1
 local sides = require("sides")
 if action ~= nil then 
  action(arg)
 end
 while not r.forward() do
  r.swing()
  try = try + 1
  if try >= 15 then
   print("Препятствие у точки: x="..lc.x.." z="..lc.z.." y="..lc.y.." Направление Dr="..lc.dr)
   local _, det = require("robot").detect()
   print(det.." спереди.")
   print(require("component").geolyzer.analyze(3).name)
   APIS.back_to_the_future()
   return false  
  end
 end
 if try < 15 then
  way = way + 1
 if lc.dr==2 then
  lc.x = lc.x - 1
 elseif lc.dr==3 then
  lc.x = lc.x + 1
 elseif lc.dr==4 then
  lc.z = lc.z + 1
 elseif lc.dr==5 then
  lc.z = lc.z - 1
 end  
 --APIS.printState()
 return true
 end
end

Как интересно получается. Робота начинает неконтролируемо глючить на расстоянии 1 чанка от игрока, мой начинал жаловаться, что ему не проехать, с 3-5 попытки ему удавалось пробить цифровую "паутину" и вернуться сообщить о проблемах. В первый раз в локальных координатах (25, -25, 26), второй раз на координатах(уже именно точечно туда посылал оставаясь на месте) (25, 0, 17), каждый раз проверяя все блоки с той стороны где ему "мерещится" преграда, сообщал что это воздух. Наша "матрица" оказывается глючит, видимо происки Нео.... Установка чанклоадера и его включение гарантированно решают проблему, видимо алекс сделал прогрузку чанков вокруг игрока, как вокруг ЧЛ - 9 чанков 3х3 с игроком в центральном. Будьте осторожны при написании прог для роботов, в остальном реализация "соседского алгоритма" для геокопалки себя оправдала на 1000%, реализовать не особо сложно, производительность огромная. Вот скрины, один про ошибки робота ,

второй - сколько накопано в зоне 32х32х64 за 1 раз 

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

 

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

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

 

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

уверен, сейчас вот пишу отсечку для него по бедроку

 

Интересное применение рекурсии.

 

Написание своей функции сортировки полезно, как минимум, для изучения применения рекурсии в алгоритмах сортировки. Но на практике, я предпочитаю встроенную table.sort

local arr={1,3,6,2,7,4,8,9,5}
print(table.unpack(arr))

--по возрастанию
table.sort(arr) 
print(table.unpack(arr))

--по убыванию, или по своему признаку
table.sort(arr,function(a,b) return a>b end)
print(table.unpack(arr))

а по какому алгоритму реализован стандартный сортер?

Томат не стоит сканировать все кластеры продвигаясь по вертикали. Вчера ночью с фингером проводили стресс-испытания уже реализованного алгоритма, при выборки 21к блоков(32х32х21 максимальный на данный момент охват(четверть макс охвата)) робот обрабатывает(т2 робот с т2 процем и 2 т2 планками) от минуты до двух. После обработки на уровне с 28 до 7, проходка заняла порядка 45-50 минут, при этом 1 возврат к сундуку, так как полезным лутом было занято более 80% инвентаря(всего 16 слотов). Бур используемый при этом(обычный ИК алмазный бур) разрядился едва на пару тысяч единиц, из 45к, пройденное расстояние я пока не вычислял, думаю стоит для статистики ввести калькуляцию найденных руд и суммарный пробег в блоках. Сегодня напишу отсечной алгоритм для бедрока и думаю дробление больших заданий(свыше 32х32) на более мелкие. Не уверен в целесообразности задействовать оставшиеся 3 четверти охвата геолайзера, время обработки резко возрастет, а объемы хранимых в памяти данных я не берусь исчислять.

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

Суть - сканируем заданный объем, по горизонтали границы мануальны, границы по вертикали во избежание критических помех - 10 вниз от робота и 10 вверх - 21 блок. Блоки руды фильтруются из массива данных и переносятся в таблицу с координатами для системы перемещений робота, далее спецсортировка массива с блоками руд - алгоритм таков первым ставится ближайший к текущим координатам робота, каждый следующий блок руды - ближайший к предыдущему, выстраивается в нужном порядке, далее просто по циклу весь массив точек передается роботу - на съедение. Пока все реализовано топорно - в каждый блок руды робот просто едет(хотел потестить чтоб работало хоть как то) нет системы интеллектуальной копки(что то вроде если дотянуться до блока с рудой может - значит копаем, а не ездим в каждый блок лично), нету обработки нижней границы, тоесть бедрока. Думаю просто при появлении отрицательной плотности(бедрок), отрезать массив руд по этой границе и глубже не ходить - так проще и легче для робота. Думаю что будет актуально при задании большой площади - бить ее на сектора и с каждым в отдельности делать то что описал выше, но это для глубокой разработки, пока не обдумывал. Написать бы еще быстрый сортировщик для выстраивания цепочки руд. Из серьезных недостатков, если жила крупная, а вплотную еще ода, или две робот может пройти по краю жилы всю ее выедая и оказаться у дальнего конца цепочки жил, потом возвращается обратно за оставленным хвостом, как решить даже в теории не представляю, разве что делать какие то ключевые точки и сортировать ближайшие блоки руд относительно такой ключевой точке, чтоб далеко не уезжал не выбрав всю жилу. Тоесть нужна в сортировке система предпочтений...а как реализовать не понимаю пока.

меньше 10% это <0.1

Ребятки, критикуя не поняв сути вы выглядите глупо.

поясни же суть! )

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

ты от автора далеко ушел? ) Он стены сравнивает с рудами, а не с мусором.

"Класть в робота образцы руд" что простите?! Может лучше образцы мусора тогда?

Разве?
 
Строишь граф:
Блоки руды = узлы
Вес рёбер = количество энергии для перемещения робота в узел
 
Алгоритм пробегает по этому графу и выдает "кратчайший" путь который и будет самой эффективной "жилой" с точки зрения затрат энергии.
 
Если нужно минимизировать время - то в качестве веса рёбер бери время телодвижений робота.
Если нужно минимизировать расстояние - то расстояние.
 
Какой параметр выберешь в качестве веса ребра по тому параметру и будет проводиться оптимизация.

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

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

"Задача о кратчайшем пути"

И? Мне путь находить не требуется, задача состоит не в этом