artem211

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

)

Оу, спасибо, значит программа будет для робота 2 лвл)

Рекомендую юзать железный бур ) надольше хватит да и зарядить можно

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

Нет не спорт, просто эффективный карьер с геосканером и мозгами, который будет копать все в заданном объёме, а не делать туннель бессмысленный и беспощадный) а вообще разрабатываемый алгоритм будет универсальным, хочешь туннель, хочешь шахта, а хочешь огромный плоский пласт от 0 до 20 уровня не останется ни блока руды. По мне - так туннель и рядом не стоит по эффективности

В ComputerCraft есть библиотеки GPS и Vector, можно перенести на OpenComputers, поставить навигационные вышки на микроконтроллерах, конвертировать относительные координаты в абсолютные и гонять робота между ближайшими необходимыми блоками и будет не важно, находятся они в одной жиле или в разных.

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

Именно потому, что есть разница гонять робота по каждому блоку руды или по очереди выбирая жилы я и задал вопрос, не было бы разницы гонял бы тупо циклом по всем блокам плотностью больше 2.5, вот только при этом будет прорыт миллион ненужных ходов в кобле

Когда подготовлю ВСЕ звуки для ИТ, и для телепорта, и для  банков, и трынделки и прочее, что даже нового игрока на ИТ можно будет встречать голосовым приветствием, запихаю их в assets.zip  и поправлю sound.json  

 

Библиотека большая, более 200 Мб, и не хочется ее 100 раз дергать, чтобы игроки ее перекачивали. Отдельным sound паком делать не хочу, так как большинство игроков  или не юзает паки вообще и понятия про них не имеет, или юзают свои, и команда /playsound просто напросто ничего игроку не проиграет, если звук жестко не зашит в клиент.

 

Вот звук ТП, который планирую прикрутить:  https://yadi.sk/d/YyLOqWtVhLHGe

Также на игрока будет накладываться на 5-7 сек. дебаф тошноты (головокружение) после телепортационного броска. Это в плане стоит.

лучше на 3-5сек )) а то просто раздражать будет. Крутой сказал они починили компутроникс, просит вернуть ) прикрутить можно будет музычку к тп станциям )

Надо мелодию проигрывать, как в лифтах )) Только звука у нас нет )

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

очень содержательно и очень эффективно.

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

Так вот, уже второй вечер пытаюсь измыслить новый тип геомайнера, использующего geolyzer.scan(), майнера под geolyzer.analyze()  - уже написал и отладил, пользуюсь, не выкладывал, т.к. народ не считает карьер "1 через 2" с использованием геолайзера оправданным. 

К делу: задумал разбивать указанный карьер(ширина,длинна) на кластеры(чанки) 20х20х20(вроде у геолайзера по горизонтали помех нет, потому границы по горизонтали можно так не ограничивать, но это потом решать буду).

В общем имеем заданный кластер объемом 20х20х20 блоков, просвеченный геолайзером на предмет руд, по сути имеем 3д массив(может проще будет обычный тейбл с 3 координатами в ячейке, опять же не суть) в данном объеме есть некоторое количество рудных жил, например 5, кататься в цикле к каждому блоку в слое - не рационально вообще никак, будет бегать от одной жилы к другой.

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

Получается нужно побить массив рудных блоков на несколько групп, в данном случае на 5. Какой избрать алгоритм? Проверить все рудные блоки между собой и все, на расстоянии 0 блоков друг от друга определить в одну жилу? При проверке первый же блок руды кидать в подмассив "жила номер раз" с указанием 3 координат, каждый следующий блок сравнивать по координатам со всеми блоками в во всех жилах, разница соответствующих координат с которыми равна 1  - приписывать найденный блок к этой жиле...хмм может сработать.

Есть идеи? Может свой вариант?

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

...

Очень эпично, слов нет! Лепи еще!

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

Приветствую. Добрался в изучении ОС и до баз данных, пока нет возможности сделать АЕ, вот решил поинтересоваться что они могут, просмотрел офф вики(в первоисточнике), вычитал все функции, но понял только, что данный апгрейд, ничего кроме информации о предмете не хранит, это не волшебная ячейка АЕ, в которую можно пихнуть стак железа, а только блокнотик, где можно зарисовать иконку железяки и все ее свойства. Внимание вопрос, какие видите перспективы применения данной детальки? Я пока только 1 придумал, хранить схемы для например реакторов ИК, ну или список "мусора" при копании, с которым сверяться.

http://ocdoc.cil.li/component:database 

Зато универсально, мне большего и не надо.

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

Зато универсально, мне большего и не надо.

не говоря о том что встань на пути игрок или корова или зомби - привет твоей ферме

топорно и не интерактивно

Алекс! Даешь человеку в вайт! У него есть мозги!)))

И зачем так сложно? Не проще либу стандартную написать? и вызывать также require("liba")

local API = {}

function API.hello()

 print("Hello!")

end

API.var1 = 12345324

API.var2 = true

API.var3 = "aasdp"

...

...

...

return API

a.move(a.dig, 3)

Что самое странное, когда пробовал - не работало, перезапустил майн сингл - заработало.

День добрый/утро/вечер/ночь. 

Пишу свою библиотеку API для робота(фермер/копатель/проч).

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

function dig(arg)

  ...

  robot.swing()

  ...

end

function move(action, arg)

  ...

  robot.forward()

  action(arg)

  ...

end

move(dig, 3)

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

Те кто писал библиотеки для ОС, именно библиотеки, знают, что реализуются они так:

local api={}

...

function api.dig()

...

end

function api.move()

...

end

return api

При такой форме записи столкнулся с проблемой, в интерпретаторе(где проверяю апи) подключаю свою либу:

a=require("api")

Далее вызываю a.move(dig, 3)

Интерпретатор ругается на то, что аргумент - нил в точке его использования в функции move(). Вероятно интерпретатор не понимает аргумента, причем вызвать просто a.dig(3) работает штатно.

Я новичок в луа и уж тем более в написании библ, подскажите что делаю неверно? как правильно передать аргументом функцию, чтоб она работала?

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

думаю прост надо крафт чуть дороже )

Кое какие вещи уже начал писать Леший, у меня постоянно куча предложений и советов, вот решил оформить.

Система охраны дома/базы/сарая на ОС(без дополнений) делится, по моему мнению, на 4 блока:

1. Мониторинговая система - Голографическая обновляемая карта окружающей местности с указанием точек наблюдейния/активной обороны, сопряженная с детектором жизненых форм(обновление в реальном времени), отображение всех ЖФ на карте.

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

      Для мониторинговой системы предусмотрено 4 режима работы: а) обновление голокарты раз в 20 сек, при отсутствии любых ЖФ. б) обновление раз в 5 сек, при наличии в зоне ответственности неигровых персонажей. в) обновление 1 раз в секунду при появлении игровых персоналий. Также при отсутствии на базе хозяев - отключение карты, дисплеев, доп оборудования(для экономии ресурсов/энергии)

2.  

        Общая система доступа на ОО(Охраняемый Объект) - коридор с тамбуром и шлюзовой камерой(2-х возможно 3-х дверная система на поршнях(либо роботы с соотв, апгрейдами)). Сенсоры перед внешними дверьми - пропускают только игроков, сенсоры перед первыми внутренними дверьми - пропускают игроков строго по 1 в шлюзовую камеру(в случае 2 игроков, игрока и моба и т.п. - первые внутренние двери не будут закрыты, процесс прохождения контроля не продолжится, пока не будут выполнены условия(возможно инфо панель/монитор для пояснения)). Между внутренним(со стороны базы) и средним(тамбурным) шлюзами хопперы/роботы и сенсоры проверки личности для пропуска на базу. В случае, если гость нежелателен - включить систему стерилизации тамбура, с последующим сбором останков.

3.  

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

4.  

      Охранная система базы(внутренние помещения) по всему объему доступных для перемещения игрока пространств будет зона агрессивной защиты - теслы/роботы/проч, за исключением безопасной зоны(вокруг кровати, если не отключат /home, а также возможно торговой/гостевой территории). Включение автоматическое, через 20 сек, отсутствия хозяев, отключается система автоматически, либо мануально. По базе в ключевых точках сенсоры, для определения "все ли дома?" и не пора ли встать на боевое дежурство.

    

   На данный момент мыслей больше нет, пора думать об исполнении. Дополнения, рекомендации, критику, пожалуйста в студию.

   
   
   

    

    

Да, салат берега утратил, решил обкопать меня со всех сторон дырки найти

Ну фиг его знает, весь приват обрыли, как понять. Пусть там роют))) А что они искали? Подземный вход в приват типа?=)

Что значит, с умом подошел к строительству базы, но всю базу до бедрока прошерстили? Что-то не вяжется.

Алекс ты хоть внимательно читаешь когда "остапа понесло" ? Я написал "ОБРЫЛИ", вокруг, просто намусорили на карте, мое все цело и невредимо

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

Отлично. Нужная программа. Так как никто и ничто в майнкрафт кроме человека, ну и естественно робота, не сможет точно контролировать состояние стержней. 

 

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

 

while true do
   require('robot').forward()
end

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

 

Там же они горят часа 2 минимум. Зачем так часто там гонять циклы. Понятно, что там работа с 4-мя слотами и измерение энергии своей, вроде мелочь, но просто не рационально, тем более, что он никуда инфу не шлет пока на внешние отображалки. Если сделаешь диспетчерскую, тогда да, раз в 10-20 секунд можно там гетить все и проверять, принтить на большие экраны состояние стержней в % износа полосочками прогрессбара и прочее. 

 

Но в целом отлично, что сделал робота-ядерщика и применил АПИ продвинутое по контролю внешнего инвентаря, слотов и демеджа айтемов.

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

В ОС я новичок, до этого кодил в майнкрафте только в СС, в реальности привык к жестко-типизированному C#, так что нюансы луа даются не просто. 

Итак общая задача такая - исключить игрока из схемы "склад-реактор".

По пунктам:

1. Выбор однородного топливного комплекта(уран/МОХ) для жидкостного реактора(далее реактор)

2. Отслеживание выработки текущей топливной закладки в реакторе.

3. Своевременное отключение реактора, изъятие отработанного топлива, закладка свежих стержней в заданной конфигурации.

4. Постоянное самостоятельное дежурство у реактора(ов), автозарядка, недопущение ошибок конфигураций закладок стержней.

5. Конвеерное получение оружейного плутония в коварных целях и обеспечение базы электроэнергией.

На данный момент программа в длительном бета-тесте уже почти 20 часов(уран вырабатывается 10 000 секунд, МОХ 5 000 секунд).

Чего удалось достичь:

- отсутствие привязки к таймеру(процесс завязан на реальное состояние топлива в реакторе),

- проверка и подборка цельных комплектов подходящего топлива(система не всегда готова поставить нужное топливо)

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

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

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

- адаптивность(программу можно запускать на любом этапе работы реактора и продолжит ее с нужного шага)

Чего пока не получилось/не успелось, но что в перспективе хочется видеть в программе:

- программу-конфигуратор с ГУИ и сенсорными кнопками, для настройки схемы реактора, количества, конфигурации и типа топливной закладки(вероятно на управляющем компьютере)

- централизованный менеджмент(сервер) для контроля "Уранитов", оценки состояния системы, корректировки схем топливных закладок "на лету"

- взаимодействие с АЕ сетью напрямую(на данный момент робот получает топливо и сбрасывает отработку через преднастроенный МЕ Интерфейс)

В общем выглядит так: 

Робот лицом к люку реактора, под ним интерфейс МЕ сети, с одной стороны зарядник, с другой можно рычаг поставить, если не нравится сверху. С какой стороны что стоит можно указать в самом начале программы, далее все управление параметризовано, исходя из настроек charge_side(с какой стороны зарядник), switch_side(с какой стороны рычаг), остальные параметры типа reac_side и fuel_side на данный момент не используются или почти не используются, задел на перспективу.

Паст программы http://pastebin.com/4RN9s0Aa

П.С.

Прошу прощения за "топорное" изложение. 

Идет Бета-тест первой версии "уранита".

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

Прошу конструктивной критики и советов.

П.П.С

Самоуверенно считаю это "кандидатской" на статус программиста.

А вообще граждане хватит валять дурака! Пилите 3д ТЕТРИС! Олдфаги(далеко не все) меня поддержат, крутейшая вещь!