To Max

Сразу встречный вопрос: при сборке пакета PlanetLand картинки с ландшафтами лун точно были положены в папку Images?.
В папке Textures должны быть только пять картинок, которые используются для анимации взлета и посадки (файлы planetFall***.png).
В папке Images - 348 картинок ландшафтов и портов.
Совпадающие имена файлов, конечно, буду переделывать, спасибо за замечание.

Интересный дефект и мне удалось его повторить. Случайное копирование всех файлов изображений Planet Landing в папку Textures вместо папки Images ни сколько не повлияет на изображение Лун, а только приведет к замене картинок при посадке черным полем. А вот, если файл omoon_Luna.png из папки Textures (Planet Landing) попадет в папку Textures (Moons), но как? и зачем?, тогда действительно произойдет соответствующая замена, приведшая к подобному дефекту. Кстати, хочу заметить, что системы Leanin нет ни в одной галактике! есть только Laenin! Вполне возможно, что на не открытой до сих пор планете Leanin такое отношение к Луне вполне естественно

To vasig

Но вот и правда интересно, как можно случайно закинуть файлы с с ландшафтами в папку текстур совершенно другого пакета?
"Нисколько не влияет" - рад, если так. Но я помню, что на ранних этапах работы над своими солнечными системами я столкнулся с тем, что мой Orbits ST (который теперь Planetary Systems) захватывал одноименные текстуры планет из System Redux. То есть пакет запросто может брать текстуры из папки текстур другого пакета. У меня есть подозрение, что при наличии нескольких файлов с совпадающими именами загружаются файлы из папки с текстурами ниже по алфавиту. Если так, то в случае пары Moons и PlanetLand файлы с совпадающими именасми из папки текстур PlanetLand получат приоритет - если, конечно, они и правда оказались в папке Textures вместо Images!.
То, что пакеты могут использовать ресурсы из других пакетов - полезная опция. По хорошему большие пакеты с тяжелой графикой надо делить на рабочий пакет и пакеты с ресурсами (несколько, если нужно), а не надеяться на то, что геймер разархивирует тома и сам все соберет правильно.
Наверное, есть резон перейти к этой практике.

to stranger

Как бы сказал Шерлок Холмс - "Здесь не все так элементарно, как кажется". Оказывается все-таки есть и третий вариант этого расследования, который мне кажется более правдоподобным. Действительно все дело в последовательности расположения пакетов! Так как файлы изображений все-таки могут быть случайно распакованы в папку Textures вместо папки Images, то при последовательности пакетов Moons.oxp/PlanetLanding.oxp, они действительно будут перебиваться другими изображениями. Почему у меня первоначально этого не получилось? Все очень просто - у меня своя собственная структура папок, а именно PlanetLanding.oxp находится в папке Buisness.oxp, так как я считаю, что посадка на планеты это дело коммерческое. А вот Moons.oxp находится в папке Cosmos.oxp (и в ней, конечно, все относящееся к украшению Космоса).
Так что все совпадает и поэтому я и не заметил этого дефекта при первом эксперименте. Что касается случайного помещения файлов в другой пакет, то учитывая выше сказанное, это совершенно невероятно, хотя некто Дуглас Адамс в одном из своих произведений доказал, что и бОльшие невероятности все-таки возможны. Если не найдется других вариантов, то дело о "плохой" Луне можно считать закрытым

to stranger

Действительно, я для PlanetLand закинул в Textures изображения. По подобию пакетов Famous Planets ST и System Makeup.
И не смутили меня ни инструкция (кто их читает?), ни названия архивов "Images Vol" (ну Images и Images, что такого?), ни черный фон при посадке (из тех двух раз, что я садился на планету).
Спасибо, за подсказку

P.S. И да, грузятся текстуры по мере инициализации плагинов, что происходит согласно алфавитному порядку (сначала из ManagedAddOns, потом из AddOns, если я ничего опять не путаю ). Интересный момент - на Ubuntu простое переименование файлов (с правкой скриптов PlanetLand с учетом новых имен) не помогло, луны стали невидимками (черными). Пришлось "выключить и включить" плагин. Похоже, где-то еще есть кеш текстур, для ускорения загрузки.

To Max

Все правильно, грузятся OXZ из папки Managed AddOns, затем OXP из папки AddOns в алфавитном порядке - порядок загрузки можно отследить по latest.log.
Для очистки кэша достаточно загрузить игру с нажатым Shift. Рекомендуется делать это после установок OXP вручную (менеджер OXZ вроде после установки новых OXZ сам кэш чистит, но не ручаюсь).

to Max

Добавлю от себя - клавишу Shift нужно удерживать до появления заставки с вращающейся "Коброй".

Нашел проблему с "Sun Gear 2.2".
При отдалении от объектов скорость Torus drive увеличивается. Но если пройтись по информационным экранам (нажимая подряд 5-6-7-8), то скорость окажется фиксированным на 11200. Дальнейшие тесты показали, что проблема в переходе 7-8.

Если переходить на каждый экран в отдельности - проблем нет.

Было замечено, что после ухода с экрана планеты (1-7-1) скорость мгновение показывается как 11200, потом повышается до "правильных" значений. Этот же порядок переходов (1-7-1) позволяет вернуть правильную скорость (если был переход 7-8).

Скорость замерялась через Combat MFD.

P.S. При некоторых плагинах 7й (планетарный) экран меняется и такой проблемы нет. Некоторое время думал, что зависит от "Planetary Systems 0.9", но дальнейшие тесты это не подтвердили.
P.S.S. чистая установка, всего 2 плагина: "Sun Gear" и "CombatMFD".

To Max

Я в общем давно подозревал, что торус-драйв вдали от небесных тел сам по себе добавляет скорости - на моем варп-драйве я добираюсь до окраин заметно быстрее, чем следует из моих оценочных расчетов. Но померить было лениво.
Вот с одной стороны, как-то реагировать надо, так как всегда найдется геймер, который именно эту комбинацию F7-F8 в полете применит. Но в чем причина эффекта - пока без понятия.
Скорее всего, при установленном пакете Hard Way эффект исчезнет, так как скрипт warp_drive.js сканирует пространство каждые четверть секунды и соответственно изменяет максимальную скорость корабля.
В любом случае спасибо за замечание.

To stranger

Я вообще думал, что добавление скорости - результат работы "Sun Gear" (расширил границы системы - добавь и скоростей для облета границ).
Потому как без этого плагина я этого эффекта не видел (или летал неудачно, или какой другой плагин "отменил" ускорение)...

В общем вопрос снимается, в чистом oolite этот эффект присутствует )
Так что это бага самого oolite.

P.S. как-то неудачно я баги нахожу...

To Max

Это да, порой огребаешь почем зря
Мне не раз ставили на вид, к примеру, баг с экранами в PlanetLand. Сел на планету, появилась картинка, выход через Space, как и задумано. Однако стоит сесть в порту без рынка, и после входа на экран F3 или F8 выйти из картинки через Space никак, только через Enter! Баг самого Оолита, но геймер-то его видит в моем пакете и считает, что это в пакете что-то криво реализовано! И отчасти прав - будь у меня больше знаний, написал бы какой-нибудь обработчик на такой случай. Можно, конечно, и просто заменить в descriptions.plist стандартное сообщение Press Space Commander на что-нибудь вроде Press Space... или Enter... в общем, нажмите чё-то из этого.

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

Прочитать данные относительно просто:
1. Можно вызвать (пробовал, работает)
2. Взять текущие данные по посещениям непосредственно из Explorers Club в формате, который сохраняется в файл (не пробовал, но должно работать):
Оба способа работоспособны только после инициализации Explorers Club (так что в startUp вызывать не рекомендую - клуб еще мог не загрузиться, благо есть startUpComplete)

В простейшем случае, в плагине Here Be Dragons надо добавить строчку в shipWillExitWitchspace:

To Max

В общем да, я именно worldScripts["Explorers Club"].*** имел в виду, когда заявил, что знаю, как закрыть вопрос синхронизации технически.
В игровом плане временное отсутствие доступа к информации об уже посещенных системах не критично. У меня привычка сохраняться на каждой промежуточной станции и перезагружаться, чтобы перезапускать системный популятор. Но при длинном транзитном рейсе с дозаправкой от солнечного ветра рассинхронизация будет наблюдаться. В принципе дописать код можно, технически это будет правильно.
В любом случае за предложение спасибо.
Встречная мысль: проблему ненаблюдаемых изолированных систем в ZeroMap можно решить двумя путями:
а) установить в параметре System.infoForSystem(g, system.ID).systemsInRange(); радиус, больший дефолтных 7 (возможно, как функцию технологического уровня системы). 12.5 LY для самых удаленных систем на канонических картах будет достаточно.
б) обозначить эти системы как видимые при выполнении определенного условия (миссии).

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

Но если 12,5LY достаточно... То как вариант - открывать планеты в радиусе большем, чем 7LY - вполне неплох (по легенде - результат наблюдения окружающего пространства).

Есть над чем подумать, 1й вариант мне больше нравится как часть легенды. 2й - гораздо проще сделать.
Впрочем, варианты не взаимоисключающее. Можно добавить визуальное наблюдение систем в радиусе 2 прыжков, (200й режим, просто точка) и покупку карты текущей галактики на астероиде отшельника (100й режим, только названия).

To Max

Я неточно выразился: 12.5 LY будет недостаточно, чтобы увидеть, к примеру, все системы за Большим Разломом на седьмой карте - но достаточно, чтобы обнаружить все изолированные регионы.
Еще один из вариантов расширения дальности обнаружения - приобретение соответствующего оборудования.
А в принципе можно дальность визуального обнаружения соседей системы увязать не с ее TL, а с плотностью газово-пылевой материи в ее окрестностях, в planetinfo.plist прописать разные значения числа наблюдаемых звезд поля sky_n_stars и скрипт будет рассчитывать дальность видимости исходя из него. Для всех 8 карт, наверное, прописывать sky_n_stars локально слишком муторно, но отдельные регионы вполне можно сделать более трудными для навигации, чем карта в целом.