А какой тип объекта указывать для маяка? Их нужно добавить в "тип", как и добавить платформы (отделить их от станций). Будет нагляднее. ИМХО
[Сообщество] Association of Galaxy Exploration (AGE)
- Thread starter AlexMcArrow
- Start date
Да для "Маяка" - сделал.
А вот по поводу станций - там будет использоваться СубТип, указывая для станций ее тип (Кориолис, Оцелус, Платформа и т.д.)
Еще одно, сейчас не могу вписать (в названии) nav beacon с пробелом, не дает сохранить. Или слитно или через "_"
Внес систему wailladyan. Эта система сама по себе странная, в другой теме писал про нее, поэтому внесенные данные по ней полные. )
Внес систему wailladyan. Эта система сама по себе странная, в другой теме писал про нее, поэтому внесенные данные по ней полные. )
Очень странно, не замечал такой проблемы. Попробую воссоздать ошибку и найти ее решение.
Спасибо за участие.
Upd: Ваша правда, была такая проблема - устранено. Если заметите еще какие-то странности или ошибки, сообщайте. Спасибо.
Last edited:
Очередное обновление:
- Версия Api - 0.8.2
- Обновление Api:
- Убраны излишние (дублируемые) методы
- Сменилась логика блока object (теперь точные операции: get, set, add - требуют указания системы и объекта)
- Обновление веб-фронта:
- добавлены формы авторизации, регистрации и профиля
- обновление поддержки Api (0.8.2)
- Изменение структуры БД:
- Добавлена "Пилоты"
- Добавлена "История" для всех операций производимых пилотами
Внимание!!!
С текущей версии Api (0.8.2), операции по добавлению или изменению данных, проходят проверку авторизации (token пилота).
Для работы необходимо пройти регистрацию (Имя пилота и пароль).
Веб-фронт уже адаптирован для использования token`а (необходимо пройти авторизацию - станут доступны методы добавления и изменения данных)
Last edited:
Набил в общей сложности координаты 10 систем.
Убедился, на примере youming, что нумерация (очередной порядок в системе, не в зависимости от данного положения на орбите) должны быть.
- - - - - Additional Content Posted / Auto Merge - - - - -
Иначе очередность нарушается, а с ним и восприятие порядка.
YOUMING АВ 3 ближе чем АВ 2... (цифры дистанции от 1-й звезды, на тот момент времени, верны)
Убедился, на примере youming, что нумерация (очередной порядок в системе, не в зависимости от данного положения на орбите) должны быть.
- - - - - Additional Content Posted / Auto Merge - - - - -
Иначе очередность нарушается, а с ним и восприятие порядка.
YOUMING АВ 3 ближе чем АВ 2... (цифры дистанции от 1-й звезды, на тот момент времени, верны)
Согласен, YOUMING - доказывает необходимость указания подчиненности.
Но к сожалению у меня остается открытым вопрос, про парные объекты. Планеты или звезды, которые имеют не только родительский объект во круг которого они вращаются, но и "напарника" во круг которого он вращается тоже.
Попробую описать проблему наглядно.
Структура (какая должна быть реально)
1. Star
1.1 Planet A
1.2.1 Planet A1
1.2.2 Planet A2
на данной схеме, есть Star во круг которой вращается Planet A. Во круг Planet A вращаются дву парные планеты Planet A1 и Plnaet A2.
если же это хранить в БД - то самый оптимальный способ это "родитель-ребенок".
ИД - Родитель - Имя
1 - 0 - Star
2 - 1 - Planet A
3 - 2 - Planet A1
4 - 2 - Planet A2
при таком варианте хранения - теряется понятие "парные" объекты.
Может у кого то будут идеи, как справиться с этим моментом или упустить его вовсе?
Last edited:
0.8.3 (Статистика)
Очередное обновление:
Fix:
Восстановлена история пилота (KOYAANISQATSI)
Очередное обновление:
- Версия Api - 0.8.3
- http://a-ge.org/api/core/stat - статистика
- Обновление веб-фронта:
- добавлена статистика (пилоты, системы и объекты)
- обновление поддержки Api (0.8.3)
Fix:
Восстановлена история пилота (KOYAANISQATSI)
YOUMING выглядит так и таких систем довольно много (не знаю как она отображается у вас в игре без исследования):
Вопрос - хранить информацию о "спаренных" объектах???
Как видно на скрине.. тут звезда А и b спаренные и они вместе спарены со звездой c и уже эта пара спарена со звездой d !!!
тут даже не только проблема как это сохранить в БД, но и как отобразить на сайте.
Last edited:
Может как-нибудь начать учитывать гравитационные центры (то, что обозначено как "X" на сриншоте выше) в качестве родителей (чаще будут встречаться системы у которых гравитационный центр совпадает со своим ребенком - звездой, но в таких как Youming это позволит решить проблему)
Если их учитывать, то на пилотов, ляжет дополнительная нагрузка - не только описывать объекты системы, но и воссоздавать их структуру.
Плюс - это дополнительная нагрузка (количество данных) на БД.
Если честно, не особо понимаю какую "техническую" роль может нести структурное положение объектов. Да, это будет нагляднее, может даже удобнее для восприятия, но это все во лишь - картинка.
При планировании маршрутов торговли (когда будет вестись база товаров), пилот будет руководствоваться конечной точкой и отдаленностью ее от точки входа в систему - максимум (я сам не всегда придаю этому значение, особенно если профит большой, то уже не важно как далеко лететь).
Да и насколько я сам замечал, используется список объектов и выбирается конечная точка полета - думаю, мало кто летает по визуальным ориентирам (сначала летим на планету вокруг которой станция и потом на саму станцию)
Смотря какие цели ставить перед собой создавая эту БД.
Для планирования маршрутов торговли, достаточно таблиц с ценами. Далее, как только сделал один полет по маршруту становится понятно (если, конечно, не взглянул на игровую карту системы), стоит туда лететь или нет (я про дальность от звезды).
Какая бы не была информация, она должна быть "удобно воспринимаимая" любым человеком, а не узким кругом лиц/игроков. В данном случае, нужна правильная, визуальная, подача информации в таблице объектов, так как мы это видим в игре: слева направо, сверху вниз. Как стало понятно, сортировка только по дистанции/алфавиту не подходит.
Для планирования маршрутов торговли, достаточно таблиц с ценами. Далее, как только сделал один полет по маршруту становится понятно (если, конечно, не взглянул на игровую карту системы), стоит туда лететь или нет (я про дальность от звезды).
Какая бы не была информация, она должна быть "удобно воспринимаимая" любым человеком, а не узким кругом лиц/игроков. В данном случае, нужна правильная, визуальная, подача информации в таблице объектов, так как мы это видим в игре: слева направо, сверху вниз. Как стало понятно, сортировка только по дистанции/алфавиту не подходит.
Хорошо, а сколько пилотов согласиться не только вносить информацию о системах и объектах, но еще и выстраивать их структуру??
В любом случаи, необходимо разработать структуру хранения данных объектов.
Уже понятно что обычного "дерева" - не достаточно. Так как в нем не возможно отразить "парные" объекты.
Если у кого-либо есть представление, о том как это реализовать - буду рад увидеть Ваши предложения. И сам пока буду думать.
Внимание!!!
Исправлены критические ошибки.
При внесении координат (создание или изменение) - их значения округлялись до целых значений.
Возможность регистрации пилота с пустым именем.
Приносим извинения.
Исправлены критические ошибки.
При внесении координат (создание или изменение) - их значения округлялись до целых значений.
Возможность регистрации пилота с пустым именем.
Приносим извинения.
Last edited:
Если речь идет о торговой базе - то не очнь понятно зачем наполнять ее данными и планетах. Достаточно знать какие станции есть на каком удалении от точки входа, какие на них цены, какие есть зоны добычи и астероидные поля, какие есть зоны конфликтов - это необходимые данные. А если пилотам будет неинтересно заполнять гравитационные центры, то почему ты думаешь, что им будет интересно заполнять данные о планетах?
Пока, на мой взгляд, нужно просто немножко подождать и посмотреть, какие внутри-игровые инструменты нам предложат сами разработчики. Иначе это черевато добровольным выполнением Сизифовой работы. Хотя, я тоже например собираю скриншоты с ценами и аутфиттингом с кажой, посещенной станции
А с релизом это все скорее всего изменится.
Пока, на мой взгляд, нужно просто немножко подождать и посмотреть, какие внутри-игровые инструменты нам предложат сами разработчики. Иначе это черевато добровольным выполнением Сизифовой работы. Хотя, я тоже например собираю скриншоты с ценами и аутфиттингом с кажой, посещенной станции
А с релизом это все скорее всего изменится.Уже неоднократно писал.
Основная суть проекта - сбор информации о системах и их объектах (координаты систем, список объектов с отдалением от точки входа).
Плюс - в последующем на базе этих данных можно будет расширять информационную составляющую БД, наполнять списки товаров и т.п.
Еще - на базе Апи можно делать различные приложения (3Д-карта один из примеров). Если какие-то варианты будут очень востребованы, то будем включать их в состав проекта.
Я ни в коем случаи не позиционирую проект как Торговую Базу или еще как. Больше подходит - АстроПедия.
Собирать данные, какие только возможно (кстати в этой концепции структура объектов будет важна и полезна) и чем больше тем лучше.
Да, знаком с экселькой в которой идет расчет координат по фиксированным точкам - хочу этот алгоритм интегрировать в проект, для расчета координат новых систем.
А вот с первой - нет.
Кстати, для прокладки маршрутов, пока вот эта нравится http://tajti.co/elite/map/
Именно своей двухмерностью и подсчетом куда прыгать и кол-во прыжков, если цель далеко.
На игровой 3Д карте вечно по оси Z приходится перебирать варианты... не наглядно. (
Именно своей двухмерностью и подсчетом куда прыгать и кол-во прыжков, если цель далеко.
На игровой 3Д карте вечно по оси Z приходится перебирать варианты... не наглядно. (