Doob

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

Можно сделать адаптацию под самые минимальные характеристики робота, прикрутить удаленный интерпретатор lua, чтобы расширить функционал. К примеру, на планшете сделать визуальное программирование маршрута со всякими редстоунами и табличками (поблочно, как в программе для рисования голограмм), потом, можно сделать запись лога действий и воспроизведения их в обратном порядке (чтобы быстро и точно вернуть робота). Вывод пройденного пути в виде мини-карты тоже бы не помешал. Прикрутить еще GUI, чтобы сделать все на кнопках-триггерах с выбором скорости движения - нажимаешь кнопку "loop" и выбираешь скорость, к примеру, для движения вперед и тогда робот в цикле прет, пока не упрется в блок. В общем, фонтан идей, я как взялся, но удобного GUI, как в компутеркрафте не нашел (чтобы с кучей перетаскиваемых окон и перенастройкой интерфейса на лету) Жаль, что свободного времени маловато, я текстурпак для OC уже вторую неделю рисую))

То, что надо! Ща затестим...

Что довольно странно, но делал программки на MC 1.8 с последним OC и встретил этот баг, решил проверить на 1.7.10 - аналогично. К примеру в этом коде: robot.swingDown() robot.down() robot.swingDown() robot.up() стабильно игнорится вторая строчка, при чем другие движения/взаимодействия работают довольно четко, но в паре с функцией swing происходят ошибки (иногда даже путает слоты инвентаря). Слипы не помогают, что делать? Переписать robot API?

Пока придумывал программы для Локи, до меня наконец дошло, что все корабли управляться должны одной машиной. Сделать ЦУП, который будет связанными платами общаться с кораблями, обрабатывать запросы на прыжки и следить, чтобы координаты финишей были корректны. Единственное, что мне не до конца ясно, можно ли управлять плагином привата от имени игрока.

Круто! Ландшафт бы еще адовый, а то он будто мимо проходил и замер)) И жертвенник по-атмосферней.

Все это круто, а как у системы с энерго-лаго эффективностью? Надо же еще кроме охраны дома что-то делать, а то прошел какой-нибудь %playername% мимо твоего дома, система всю энергию выжрала, а ты прилетаешь срочно передробить стак стаков руды и сидишь АФКшишь, пока энергия не восполнится.

Дефолтный ответ дефолтного программиста))

А чего бы не взять готовый IRC, как на computercraft.info?

Да, все так)) С роботами можно целый танк сделать, только агнельский апгрейд догороват для грифера.

https://www.youtube.com/watch?v=0H3kYbfTzqQ Начинающему гриферу теперь необходимы две жемчужины и три алмаза (и х3 TNT, конечно), и всякий мусор для крафта черепахи и кпк.

Не, это бредовый мод))

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

В дополнение к базовой автоматизации, можно дополнить проект концепцией идеального города. (+фича с пространственно-временной валютой, позволяющая ограничить передвижение игроков и заставить их больше использовать роботов) К примеру: заходит игрок на сервер, на спавне стоит регион с бесплатным временем, т.е. игрок может находиться там сколько хочет. У игрока на счету сразу есть 2 у.е., эти деньги он может потратить на покупку недвижимости (на спавне терминалы покупки). Игрок выбирает себе подходящее место и тип дома. На выбор: Сырой чанк 16x16x240 (не обработан муравейником) = 32 у.е. Пустой чанк 16x16x240 (в комплекте идет много камня) = 16 у.е. Подсолнечный куб 163 (типовой дом созданный муравейником с базовыми ресурсами и персональным роботом) = 2 у.е. Теневой куб 163 (находится ниже подсолнечного) = 1 у.е. Если игрок находится вне бесплатной зоны, то с его счета каждые 10 секунд списывается n копеек, когда баланс равен нулю, игрок замораживается на несколько минут и умирает. Возрождение происходит на спавне, либо, если у игрока есть приобретенная недвижимость, он возрождается у себя дома. Еще можно реализовать примитивную защиту от гриферства - если муравейник потерял связь с одим из своих юнитов, то по последним координатам проверяется наличие игроков в радиусе 40 блоков, все найденные игроки отправляются на спавн, а их недвижимость и время замораживаются до решения администратора-человека. Защита не ахти какая, опытный игрок может сбить муравья своим роботом или TNT пушкой, но у муравьев свой уровень, в который никто попасть не может, сбить их можно только в чанках, которые еще не терраформированны.

Можно еще по-другому сделать, т.к. для многих предметов рецепты повторяются, то чтобы не плодить сущности загоняем рецепты в формулы, и робот будет сам подставлять необходимые ресурсы в рецепт. К примеру: [a][a][a] [0][0] [0][0] это рецепт любой кирки, просим алмазную, робот ищет алмазы и палки a = алмаз, b = палка и все. Объем сохраняемой информации будет в разы больше. Можно даже таблицу всех возможных рецептов хранить на pastebin и роботу необходимо будет дать только правильный индекс.

Computercraft CommandComputer pastebin get Pce6fTta boom Очень медленно...

Да, а что, там можно включенный компьютер спавнить?

Было б круто запилить Starbound в майне, собственно описание идеи: Корпус корабля из бедрока, в корпус вшит командный компьютер. Командный компьютер управляется с КПК игрока или монитора в самом корабле, вот список функций: Beam to ship/Beam to planet - просто сканирование столба от корабля до земли и телепортация на твердую поверхность (если внизу океан, то пару блоков воды превращаются в лед). Jump - перенос всего корабля (к примеру через scoreboard) в месте с сундуками и игроком по заданным координатам, либо на определенное количество блоков. Реализуется через testforblock, setblock. Pixels - на корабле есть углубление в стене, поставив в которое любой блок и нажав пару кнопок можно конвертировать его в пиксели (валюта в scoreboard), на этих пикселях корабль и будет перемещаться +из них можно печатать необходимые блоки. Miner - это просто лагогенератор, но для синглплеера сойдет. За определенное количество пикселей можно отсканировать чанк под кораблем и выбрав блоки, которые нужно добыть, за пиксели майнер их удаляет из чанка и кидает в инвентарь игроку. Но... Если б все было так просто, это уже было б реализовано. Чтобы после переноса корабля компьютер работал опять, необходимо его включить и загрузить программу, но командный компьютер это читерство, доступ к нему должен быть закрыт. На computercraft.info уже предлагали сделать дополнительные параметры для setblock блоков из CC, но воз и ныне там. А так идейка интересная, правда?

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

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

Еще бы библиотеку python>lua и lua>python, а то питон популярный, на нем больше реализовано алгоритмов.

Мда... Получается отражение по диагонали. Вот наглядные координаты среза для нечетных кубиков: Вот какие правила можно вывести: угол = [-x, -y]=>[-x, +y]=>[+x, +y]=>[+x, -y]=>[-x, -y] центр = [-x, 0y]=>[0x, +y]=>[+x, 0y]=>[0x, -y]=>[-x, 0y] берем срез кубика 3x3, у него кроме центрального еще два кубика с такими правилами: x-1, y+2 => x+2, y+1 => x+1, y-2 => x-2, y-1 => x-1, y+2 x+1, y+2 => x+2, y-1 => x-1, y-2 => x-2, y+1 => x+1, y+2 [+-]____________[+-]___[+-]_____________[+-]___[+-] - это у нас инверсия знака Далее у нас заметна последовательность типа: x-3, y+4 => x+4, y+3 => x+3, y-4 => x-4, y-3 => x-3, y+4 x-2, y+4 => x+4, y+2 => x+2, x-4 => x-4, y-2 => x-2, y+4 x-1, y+4 => x+4, y+1 => x+1, y-4 => x-4, y-1 => x-1, y+4 и это только для 1/8 периметра, т. е. вращается только половина квадрата, надо еще добавить инверсию знака как я указал для 3х3 в итоге выходит цикл с такой формулой: от i+v до i+1 x = 0-m, y = i-1 => x = i-1, y = m => x = 0-m, y = 0-(i-1) => x = 0-(i-1), y = m => x = 0-m, y = i-1 v = длина грани m = значение сконвертированное из длинны грани по формуле 3 = 1 5 = 2 7 = 3 9 = 4 11 = 5 ... Вроде-бы довольно удобно, если доработать, то можно будет задать размер кубика, и спокойно играться, но для четных формула другая и как-то лень перелопачивать все правила и запихивать их в формулы. Должен быть способ попроще.

Итак, что мы имеем? 1. Срезы в виде одномерного массива, сдвиг таблицы петлей (индекс +- длина грани) Можно автоматизировать генерацию срезов для любой длинны грани, но получается очень избыточно (но какая разница, если допиливать не надо?). Если сделать срез в виде двумерного массива, то правила сдвига усложняются, но упрощается вывод относительных координат на командный блок. 2. Сканирование сторон в срезе и круговое переназначение координат (по тому-же принципу, по которому происходит построение кругов отражением 1/8 круга). Так как у меня используются относительные координаты, координаты командного блока = x0 y0 z0, берем срез. ####[-2][-1][00][+1][+2][xx] [+2][00][RR][RR][RR][00] [+1][GG][00][00][00][BB] [00][GG][00][00][00][BB] [-1][GG][00][00][00][BB] [-2][00][YY][YY][YY][00] [yy] Присваиваем [x, y = y, x] и (если я ничего не путаю) получаем срез повернутый на 90 градусов. Подкиньте еще идеи с реализацией. Кстати, вот TouchCube интересно бы узнать, что внутри.

Ну я так и делал, все это очевидно, но расширять придется вручную. Хотелось бы найти более математическое решение, т. е. чтобы можно было запросить у программы кубик 3х3х3 или 90х90х90, а она из базового алгоритма берет все сдвиги в вращения (которых всего 2 штуки) и применяет для каждого среза. А гуглить я пробовал, запрашивать "кубик Рубика" и "алгоритм" бесполезно - только алгоритмы сборки или "физические" реализации (эмулируются срезы и вращение 3д модели), а более абстрактные также не расширяются. Вот мой нубокод: http://pastebin.com/XFxXRKUu, с правилами в таблице будет короче, но принцип точно такой же.

Подскажите, как можно записать алгоритм вращения сторон кубика Рубика, используя теорию множеств. У кубика есть два типа множеств - квадратов и действий, вот список: Квадраты угловой (24 шт) боковой (24 шт) центральный (6 шт) Действия (для одной стороны) сдвиг верхнего слоя сдвиг центрального слоя сдвиг нижнего слоя вращение активной стороны Для четырех сторон, лежащих в одной плоскости, первые три действия не отличаются. Так как у нас 3 таких группы по 4 стороны, количество действий = 9 (3 группы*3 слоя, инверсию не считаем) Вопрос: Как должен выглядеть оптимальный алгоритм вращения? Изначально я записал правила в таблицу и по этим правилам переназначал цвета в таблице состояний кубика просто сдвигая параметр квадрата по петле. Правила были примерно такие: {1,4,7}, {2,5,8}, {3,6,9}, {1,2,3,6,9,8,7} Но где-то была ошибка с параллельным присваиванием и я, чтобы ускорить процесс, при помощи команды testforblock (кубик Рубика работает на командном блоке) записал все действия в таблицы, а таблицы вставил в код. Результат хоть и работает, но код режет глаза.