Одна из отличительная особенность программ AstroManta в том, что можно добавлять в карту точки которые расчитываются по совершенно произвольному алгоритму. Возможно это благодаря использовнию того же скриптового языка. Сейчас с этим разберемся. Вы помните, что мы в прошлый раз закончили на добавлении куспид домов. Давайте для полноты картины добавим и оси. Загружайте архив с примерами и открывайте start_3_1.bsh.

Запустили? Появился Asc и Dsc. Открываем файл. В начале идет создание объекта наследника от SpotCalcListener. Пропустим пока, идем до функции PointAxis  - здесь и идет добавление осей. Принцип сохраняется такой же, что с добавлением планет, что с добавлением куспид домов. Сначала создаем точку гороскопа. В нашем случае через вызов метода addAxis нашего натала. А потом создаем объект отрисовки, аналогично куспидам. Разница только в том, что при создании нашей линии для Asc мы еще и передаем имя файла на картинку. Картинка эта, в отличии от картинок отрисовки планет, рисуется всегда точно на линии. Но если вам нужно "двигать" картинку (чтобы не наползала на другие символы) - ничего не мешает создать два объекта отрисовки на одну точку - один рисует линию, а второй "планету". Теперь разберемся с Dsc. По сути это точка которая стоит в оппозиции к Asc и считать ее по эффемеридам нет смысла. Сделаем это сами. Для этого и существуют объекты класса CalcSpot.  Создается такой объект через вызов метода addCalcSpot карты. Объект который расчитывает точку это наследник от SpotCalcListener - его и нужно передать в метод setCalcListener расчитываемой точки. Если предполагается, что этот алгоритм будет работать с разными точками, то можно добавить еще один аргумент - как мы тут и делаем (передаем эклиптическую координату Asc). Возвращаемся выше к создании нашего CalcOposite. Вся расчетная часть происходит в методе onCalc, куда в качестве аргументов передаются: объект расчитываемой точки и аргумент если он был задан (если не задан там будет null). Расчет, как и ожидалось очень простой - увеличиваем долготу на 180 градусов, а скорость по долготе делаем такую-же как и у "оригинала".

Как вы наверное уже догадались CalcOposite используется не раз. Например не только в паре Asc/Dsc, но и в Mc/Ic или Лунных узлах. Поэтому он уже и прописался в библиотеке "point/oposite.bsh". Как и создание осей PointAxis, которая отличается от того что в примере, только дополнительным созданием и пары Mc/Ic. Загрузите start_3_2.bsh и убедитесь. Отмечу, что карта теперь начинается честно от Asc, а не от куспида I дома (что не всегда одно и то-же).

 Давайте попробуем что-нибудь посложней? Например создание жребия, Колеса Фортуны. Смотрим start_3_3.bsh. Смотрите, мы спрятали внутрь функции наш расчетный объект. В первых строчках создания объекта, сделано запоминание объектов эклиптических координат нужных нам точек. Это и компактней и добавит совсем немного скорости (этот кусок выполняется только один раз, при создании точки). Расчет как и прежде в методе onCalc. Мы ведь помним, что жребии считаются для ночных и дневных карт по разному. День или ночь найти просто - нужно просто посчитать угловое расстояние от Asc до Солнца. Это и делает метод angle объекта Asc. Если Солнце имеет меньшую долготу чем Asc в результате получаем отрицательный угол - это день. Иначе Солнце под горизонтом - ночь. Исходя из этого и считаем долготу нашего жребия.

Вот так вот просто все и делается, но это дает практически бесконечные возможности реализации расчетов точек гороскопа. Потому что вы ничем не ограничены в исходных данных.  В качестве домашнего задание переделайте функцию PointParsFortuna чтобы она считала любые жребии, с помощью передачи двух объектов точек. Дальше мы сможем вместо Asc подставлять, управителей куспид итд итп. Если с этим справитесь реализуйте создание мидпоинта от двух произвольных точек. Пусть мидпоинт распологается всегда по кратчайшему расстоянию между точками. Подсказка - если считать среднее арифметическое между координатами, не всегда будет правильно.

У вас нет прав чтобы комментировать