artem211
Пользователи-
Публикации
109 -
Зарегистрирован
-
Посещение
-
Победитель дней
4
Тип публикации
Блоги
Профили
Форум
Багтрекер
Магазин
Все публикации пользователя artem211
-
Рекомендую реализовать запись в файл, с указанием времени обнаружения и ника/названия жизненной формы которая была засечена, чувствительность датчика движения выставить на 1 раз в сек. Добавить функции добавления в белый/черный список(хранить их в отдельных файлах). Трехмеризировать систему, защитный/сигнальный периметр, должен быть периметром, а не точкой. В зону влияния каждого датчика установить теслабашню(2,3 в зависимости от зоны охвата/поражения), реализовать алгоритм, при котором будут включаться только те теслы, которые перекрывают зону охвата того или иного датчика. Организовать 3д предупреждение для посетителей(голографический "забор" тут поможет как нельзя лучше). Установить тамбурную зону доступа на объект, в качестве дверей - только поршни, все остальное преодолимо. Систему уничтожения несанкционированных посетителей и сбор лута с них.
-
Спасибо за информацию, буду руководствоваться.
-
Покажи товар лицом )) скрины фигач )
-
Ждать нечего, просто заходишь на сервер и пишешь com.command(3)[32] Интересно что будет если писать из консоли а не от лица игрока
-
К слову, это дерьмо опять началось, стоит написать в чат выражение типа geolyzer.scan(0,0)[32] ты вылетаешь с дисконнектом. Убираем квадратные скобки - все нормально. Осточертела эта хрень ей богу. Уберем мб чатбоксы к зеленым криперовым яйцам?
-
Нет врядли ) я жадный )
-
мб превентивно решить эту проблему? )
-
Благословение или проклятие? Свинец против булыжника.
artem211 прокомментировал eu_tomat запись в блоге в eutomatic blog
я такой вариант в принципе рассматривал, можно отдельным счетчиком проверять блоки плотностью v(2), и если их скажем больше 100 - то игнорировать, меньше 100 - включать в список. Так хотя бы в 5 случаях из 10 получим свинец...надо попробовать такое поставить, потом сравнить время копания, есть ли сммысл, а майны у нас оч подробно перерыты всякими гениями от кирки ) -
Тебе в помощь апгрейд робота - база данных, там полный портрет предмета можно указать. Как в АЕ
-
Очередной интеллектуал от программирования номер 2...
-
Сноси его к яйцам эндерменовским...поговорить не дает
-
очередной гениал, считающий что программа робота запускается и работает на клиенте, а не на сервере?
-
Если бы было существо - детект робота вернул бы не воздух, а энтити
-
Асум ты слепой что ли?
-
См выше запостил логику алгоритма. Мб я совсем дурак? или это особая "уличная магия" ?
-
Я специально 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 раз
-
уверен, сейчас вот пишу отсечку для него по бедроку
-
а по какому алгоритму реализован стандартный сортер?
-
Томат не стоит сканировать все кластеры продвигаясь по вертикали. Вчера ночью с фингером проводили стресс-испытания уже реализованного алгоритма, при выборки 21к блоков(32х32х21 максимальный на данный момент охват(четверть макс охвата)) робот обрабатывает(т2 робот с т2 процем и 2 т2 планками) от минуты до двух. После обработки на уровне с 28 до 7, проходка заняла порядка 45-50 минут, при этом 1 возврат к сундуку, так как полезным лутом было занято более 80% инвентаря(всего 16 слотов). Бур используемый при этом(обычный ИК алмазный бур) разрядился едва на пару тысяч единиц, из 45к, пройденное расстояние я пока не вычислял, думаю стоит для статистики ввести калькуляцию найденных руд и суммарный пробег в блоках. Сегодня напишу отсечной алгоритм для бедрока и думаю дробление больших заданий(свыше 32х32) на более мелкие. Не уверен в целесообразности задействовать оставшиеся 3 четверти охвата геолайзера, время обработки резко возрастет, а объемы хранимых в памяти данных я не берусь исчислять.
-
Суть - сканируем заданный объем, по горизонтали границы мануальны, границы по вертикали во избежание критических помех - 10 вниз от робота и 10 вверх - 21 блок. Блоки руды фильтруются из массива данных и переносятся в таблицу с координатами для системы перемещений робота, далее спецсортировка массива с блоками руд - алгоритм таков первым ставится ближайший к текущим координатам робота, каждый следующий блок руды - ближайший к предыдущему, выстраивается в нужном порядке, далее просто по циклу весь массив точек передается роботу - на съедение. Пока все реализовано топорно - в каждый блок руды робот просто едет(хотел потестить чтоб работало хоть как то) нет системы интеллектуальной копки(что то вроде если дотянуться до блока с рудой может - значит копаем, а не ездим в каждый блок лично), нету обработки нижней границы, тоесть бедрока. Думаю просто при появлении отрицательной плотности(бедрок), отрезать массив руд по этой границе и глубже не ходить - так проще и легче для робота. Думаю что будет актуально при задании большой площади - бить ее на сектора и с каждым в отдельности делать то что описал выше, но это для глубокой разработки, пока не обдумывал. Написать бы еще быстрый сортировщик для выстраивания цепочки руд. Из серьезных недостатков, если жила крупная, а вплотную еще ода, или две робот может пройти по краю жилы всю ее выедая и оказаться у дальнего конца цепочки жил, потом возвращается обратно за оставленным хвостом, как решить даже в теории не представляю, разве что делать какие то ключевые точки и сортировать ближайшие блоки руд относительно такой ключевой точке, чтоб далеко не уезжал не выбрав всю жилу. Тоесть нужна в сортировке система предпочтений...а как реализовать не понимаю пока.
-
меньше 10% это <0.1
-
поясни же суть! )
-
ты от автора далеко ушел? ) Он стены сравнивает с рудами, а не с мусором.
