Doob

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

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

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

У игрока на счету сразу есть 2 у.е., эти деньги он может потратить на покупку недвижимости (на спавне терминалы покупки).

Игрок выбирает себе подходящее место и тип дома.

На выбор:

1. Сырой чанк 16x16x240 (не обработан муравейником) = 32 у.е.
2. Пустой чанк 16x16x240 (в комплекте идет много камня) = 16 у.е.
3. Подсолнечный куб 16³ (типовой дом созданный муравейником с базовыми ресурсами и персональным роботом) = 2 у.е.
4. Теневой куб 16³ (находится ниже подсолнечного) = 1 у.е.

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

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

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

Э... А про OpenComputers, сударь, Вы забыли?

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

Было б круто запилить 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, с правилами в таблице будет короче, но принцип точно такой же.

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

У кубика есть два типа множеств - квадратов и действий, вот список:

• Квадраты

1. угловой (24 шт)
2. боковой (24 шт)
3. центральный (6 шт)

• Действия (для одной стороны)

1. сдвиг верхнего слоя
2. сдвиг центрального слоя
3. сдвиг нижнего слоя
4. вращение активной стороны

Для четырех сторон, лежащих в одной плоскости, первые три действия не отличаются.

Так как у нас 3 таких группы по 4 стороны, количество действий = 9  (3 группы*3 слоя, инверсию не считаем)

Вопрос:

Как должен выглядеть оптимальный алгоритм вращения?

Изначально я записал правила в таблицу и по этим правилам переназначал цвета в таблице состояний кубика просто сдвигая параметр квадрата по петле.

Правила были примерно такие: {1,4,7}, {2,5,8}, {3,6,9}, {1,2,3,6,9,8,7}

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

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

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

executeCMD ловит сообщения игроков и параллельно команды дилера, может мне на каждого игрока по потоку сделать?

Давно пытаюсь написать ядро, на котором можно было играть в любую карточную игру с минимумом допиливаний, но энтузиазм быстро затухает и постоянно останавливаюсь перед самым главным.
 
Суть идеи такая: в массиве хрянятся инфа об игроках, картах и монетах, у игроков одинаковый набор команд, у дилера - расширенный.
 
Команды игрока:

• открыть/закрыть карты
• передать карты на стол/передать другому игроку
• передать монеты на стол/игроку

Команды дилера:

• перепешать колоду
• раздать карты игрокам/на стол
• перевести деньги со стола игрокам
• заморозить игрока
• сбросить информацию о картах

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

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

Может кто посоветовать, как настроить синхронизацию команд и быстрое обновление таблицы?
 
Вот ссылка на сам коммандный движок http://pastebin.com/0m3LXTzD

Есть такая древняя задумка, которая появилась еще при СС1.3:

Берем черепаху-шахтера, устанавливаем, запускаем прогу.

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

Рабочие строят фермы деревьев, терраформируют мир по такому шаблону - от y5 до y32 строятся фермы, склады, заводы, а все что выше превращается в каменную суперплоскость.

Можно прикрутить взаимодействие с игроками - игрок заказывает предметы/постройки, а черепахи это создают за энергоресурсы.

Хотелось такое запилить с голым CC, без модов, но тогда это было довольно сложно, теперь есть возможность, но нет желания. В OC больше всяких плюшек, которые упростят некоторые функции, но усложнят другие, в общем я больше на стороне OC.

Zer0Galaxy, кинь код на пастебин, я про OC узнал только сегодня, очень интересно поковырять.