stranger, топливо не вызывает перегрузку.
Перегрузка УЖЕ есть, т.к. куча оборудования стояла заранее. А при покупке проверяется факт перегрузки (а не то, что его вызвал покупаемый объект).
Перегрузка есть - показывается сообщение. Даже если покупаемый объект не повлиял на перегрузку. Так что не в моих правках дело...

P.S. да, я смотрел обработчик playerBoughtEquipment. И похоже, эту монстрообразную проверку надо добавить и в него:
Чтобы сообщения о перегрузке вызывалось только для того, что на эту перегрузку влияет. А оборудование не только покупается (вспомним про Cloaking Device). И в режиме перегрузки даже лицензию какую не купить - перегрузка.

P.P.S. Fuel Generator - это я сделал девайс по генерации топлива. EQ_FUEL_GENERATOR. Тестирую работу, буду выкладывать OXP. Влиять на подсчет не должен, в Equipment Bay нет поиска подстрок в строке (кроме проверок, но там топливо не участвует) - только прямое использование по ключу.

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

Equipment Bay 0.5

Небольшая оптимизация кода по совету Макса (реализован только более удачный алгоритм фильтрации оборудования, в отдельную функцию не вынесен).
Функционал пакета пока идентичен предыдущей версии.

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

Пакет вполне игровой при том условии, что корабль уже не перегружен в момент его установки. Скрипт корректно отслеживает попытки приобретения сверхгабаритного оборудования и изымает его, не допуская перегрузки. Подчеркиваю: обработчик работает корректно - он исходит из естественного допущения, что если приобретение предыдущего оборудования прошло фильтр, проблема именно в том оборудовании, которое приобретается в данный момент. Некорректна именно ситуация, когда геймер применяет эти новые правила к уже перегруженному кораблю. Потому что если бы правило применялось изначально, ситуация с перегрузкой не возникла бы. И раз уж некорректная ситуация создалась не в результате дефекта в логике пакета, а в результате действий геймера, геймеру ее и разруливать. Поэтому правильно будет так:
Ставим пакет.
Активируем интерфейс и проверяем заполнение отсека обрудования.
Если перегруза нет - играем дальше.
Если есть перегруз - у вас два варианта на выбор:
а) отключить пакет, продать часть оборудования и снова включить пакет, после чего возвращаемся к варианту "играем дальше".
б) просто отказаться от игры по новым правилам

Это не значит, что обработчик ситуации "отсек переполнен" вообще не нужен. Такая ситуация может возникнуть при приобретении бонусного оборудования как вознаграждения за выполнение миссии (Cloaking Device) или выдачи на время специального оборудования, которое нужно для выполнения миссии (фотокамера в Tionisla Reporter). В этом случае оборудование приобретается в обход обработчика, который запускается при его обычном приобретении, и не проходит тест на переполнение.
Я также очень сильно подозреваю, что не все так просто может быть с б/у оборудованием, приобретенным на косморазборке (salvaged equipment) - в момент приобретения оно по всем признакам проходит как занимающее 1 слот, но после установки конвертируется в стандартное оборудование и может разбухнуть до 2...3 слотов. Эту ситуацию обработчик пока тоже никак не отслеживает.
Именно поэтому я и хочу взять тайм-аут, чтобы неспешно подумать, как опимально решить эти особые случаи.

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

Теперь переходим к вопросу взаимодействия Equipment Bay с другими пакетами. Здесь могут быть сюрпризы.

Емкость отсека оборудования в Equipment Bay определяется исходя из массы корабля. А масса корабля в Оолите нигде не прописана напрямую, а считается по примитивной формуле: объем охватывающего корабль бокса (произведение габаритов) х плотность.
В Neolite Ships модель Кобры Марк Три поджата по сравнению с дефолтной Коброй Марк Три: 100х15.8х46.4 вместо дефолтных 130х30х65 м. Это приводит к тому, что неолитическая Кобра Марк Три по массе из тяжелого класса переходит в средний и объем отсека оборудования сокращается с 40 до 30 слотов. Писать обработку всех подобных исключений - занятие бессмысленное и беспощадное. Я сдуру посоветовал коммандеру vasig просто добавить эти десять слотов в скрипте, о чем сейчас жалею. Поджатые габариты корабля дают геймеру серьезный бонус в пушечных дуэлях, притом что корабль сохранил прежний грузовой отсек емкостью 20 тонн! По хорошему, за такой гандикап надо чем-то платить и перевод корабля в средний класс вполне разумен.
В Hard Ships бронированные варианты имеют вдвое большую массу, чем дефолтные корабли, за счет вдвое большей плотности. На классификацию Аддера это влияния не оказывает - при росте сухой массы с 16 до 32 т корабль по прежнему остаентся в легком классе. Кобра Марк Три при увеличении сухой массы с 215 до 430 т также остается в тяжелом классе, а вот Кобра Марк Один при увеличении сухой массы с 52 до 104 тонн уже классифицируется как тяжелый корабль и получает отсек оборудования на 40 слотов, что частично съедается установкой дополнительной брони, которую Equipment Bay обрабатывает как оборудование из разряда "прочее" с емкостью 1 слот. Но вот как раз этот дрейф основанной на сухой массе классификации скомпенсировать несложно, если основывать классификацию на "приведенной массе" с учетом плотности. Ставлю в рабочий план.

И последний вопрос: так что, пакет с перенастройками Ore Processor.oxp в моей сборке (e)Xternal OXP Tweaks теперь можно отключить за ненадобностью? В принципе единственный смысл этой перенастройки - прописать правило: рудный процессор несовместим с дополнительным грузовым отсеком ИЛИ с корпусом малого класса. Раз уж проблема решена на новом уровне, то в принципе да, необходимости в этой перенастройке больше нет. Но я бы рекомендовал оставить этот пакет как есть исходя из следующих соображений:
Пакет с перенастройками Ore Processor.oxp - это дополнительный контур настроек, который с пакетом Equipment Bay не конфликтует ни технически, ни логически. Возможно, кто из геймеров, которые приняли мои правила, прописанные в SW Equipment, новый пакет Equipment Bay ставить не захочет. А возможно, кто-то наоборот попросит "заверните мне вот это, а то не надо". Именно из этих соображений я не стал интегрировать Equipment Bay в Stranger's Set, а сделал как автономный пакет, который если что геймер может допилить на свой вкус. Я бы хотел оставить старые правила в силе - они неплохо работают и я не хотел бы вынуждать геймера "нет, теперь все будет по другому".

Fuel Generator 0.2
Новое оборудование - Fuel Generator. Позволяет синтезировать топливо из энергии. 1LY топлива за 1 энергоблок. Повреждает щиты из-за субпространственных возмущений. Занимает 5т в багажном отделении.
Это актвируемое оборудование, по умолчанию вешается на кнопку быстрого вызова защитного оборудования (кнопка 0 на клавиатуре). Или выбирается через Shift-N и активируется (N).

Доступен через встроенный диспетчер дополнений (Equipment)!
Скачать: В личной рубрике.

Если кто не уснул за чтением дискуссии, которую мы с Максом затеяли с подачи vasig, то хочу пояснить ее суть со своей колокольни. Суть проблемы на мой пристрастный взгляд была не в том, что геймер видел красивенькую текстуру главной планеты только во время пребывания в системе. И даже не в том, как правильно показать эту красивенькую текстуру для удаленной системы вместо психоделического продукта процедурной генерации, который Оолит предлагает по умолчанию. А в том, что код, отвечающий за присвоение этих текстур главным планетам, чудовищный. Алгоритм выбора текстуры главной планеты интересный и не побоюсь сказать, я им горжусь. Ничего подобного ни у кого нет. Но вот финальный этап - собственно наложение уже выбранной текстуры на планету - блин, такое лучше накрыть дерюжкой и спрятать где-нибудь в чулане до лучших времен.
Почему так вышло, я уже объяснил. Но объясню еще раз.
Был в свое время такой интересный пакет System Redux. Это было по замыслу авторов комплексное решение оформления игрового фона. Помимо определения текстур главной планеты пакет также размещал в системе до 4 дополнительных планет и до 2 лун (геймер мог увеличить эту настройку по умолчанию до 4 лун) и даже устанавливал глобальные настройки вида неба (количество видимых на нем звезд и туманностей, уровень фонового освещения и прочее). Пакет бесконфликтно уживался с другим популярным пакетом той эпохи Famous Planets. И более того, в нем была заложена возможность перенастроек не вручную, а через интерфейс специального пакета OXPConfig. Но вот отображение текстур главных планет удаленных систем на экране F7 по признанию самих авторов пакета получилось горбатым и они эту опцию по умолчанию предпочли отключить.
По мере обустройства Оониверсума все эти дополнительные опции вроде внешних планет и лун потеряли актуальность. Мне от пакета требовалось только одно: чтобы он определял текстуру главной планеты. По хорошему надо было и правда просто попытаться написать скрипт с нуля, но по недостатку опыта я в то время ограничился тем, что повыбрасывал из пакета все явно лишнее, а остальной код оставил до лучших времен и сфокусировал свои усилия на алгоритме выбора текстур. Здесь как раз пришлось писать все с нуля и я чувствовал себя уверенно, отчетливо понимая, что я делаю и для чего.
Вот такая получилась химера. Издержки дилетантского подхода "я тебя слепила из того что было". Работает как ты хотел? Ну и нефиг трогать!
То же можно сказать и о Famous Planets - там был предусмотрен механизм проверки совместимости не только с System Redux, но и с альтернативными косметичками Deep Horizon - Systems API и System Demux (кто из ныне живущих их еще помнит, ау?!).
Макс такой фигней не страдал и не поленился посмотреть на задачу незамыленным взглядом, за что ему гран мерси.
Ну, теперь по сути дела.

System Makeup 2.1

По сути дела, это пакет нового поколения, в котором от прототипа System Redux осталась лишь благодарность предтечам в readme. Текстуры главных планет всех 256 систем назначаются при инициализации пакета и при переходе на новую карту, такой способ позволяет корректно отображать текстуры главных планет удаленных систем на экране F7. Хочу ясно указать: авторство скрипта system_makeup.js, назначающего текстуры, принадлежит SMax, я в этой части ограничился косметическими правками кода.
Логика выбора текстур в скрипте system_makeup_library.js осталась прежней, но поскольку прежний метод выбора текстуры из набора через system.scrambledPseudoRandomNumber() для удаленных систем не работает, SMax предложил альтернативный генератор псевдослучайных чисел, который использует как семя параметр random_seed (набор из 6 чисел в диапазоне 0...255, уникальный для каждой системы). То есть если скрипт, к примеру, определил что будет показана одна из 12 текстур с арктическими океанами, то правило остается в силе, но вместо прежней текстуры номер три геймер будет видеть текстуру номер семь. Для казуального геймера это совершенно неважно, но если вы черпали в игре вдохновение для фанфика, старое описание системы придется переписывать заново - и кто знает, к каким поворотам сюжета это приведет.
SMax присвоил начисто переписанному скрипту system_makeup.js номер 3.0.0. Я понял деликатный намек, но по историческим причинам предпочитаю придерживаться сквозной нумерации версий пакета.

Famous Planets ST 0.9

С этим пакетом была та же беда - избыточно сложный код назначения текстуры главной планеты. Хуже того, оставлять пакет как есть было никак нельзя, так как пакет не показывал текстуры главных планет удаленных систем. В результате геймера ожидала ситуация, что на экране F7 он увидит текстуру, которую определил для удаленной системы System Makeup по своим правилам, и только по прибытии на место увидит правильную текстуру.
Скрипт канонического Famous Planets радикально переписан по аналогии с решением, которое предложил SMax для пакета System Makeup. Фактически от прежнего кода остались только функции запуска и остановки аудиотреков при посещении десятка самых примечательных систем.
При синхронизации Famous Planets ST с обновленным System Makeup я держал в голове возможность, что System Makeup может запуститься после Famous Planets ST и перекрыть его настройки. Я решил эту проблему таким образом: назначение текстур Famous Planets ST вызывается по событию this.startUpComplete, то есть после того, как отработала аналогичная процедура в пакете System Makeup по событию this.startUp.
Тем не менее потенциальная уязвимость в синхронизации пакетов осталась. При переходе на новую карту оба обработчика будут вызваны по событию this.playerEnteredNewGalaxy(galaxyNumber) и какой из них будет запущен первым, без тестов сказать трудно (я сдержанно опасаюсь, что это может зависеть от индивидуальной организации пакетов в папке AddOns геймера). В этом случае System Makeup может навязать свои текстуры вместо текстур Famous Planets ST. Проблема временная - она может возникнуть только при переходе с 1 карты на 2 и с 8 на 1 и решится после первой же загрузки из сохраненной позиции.

PlanetLand 2.2

В пакете есть кусок кода, который обращается к внешней функции $home_planet_makeup(info) в пакете System Makeup, чтобы узнать номер планетной текстуры и подставить соответствующий планетный ландшафт. Так как на эту функцию сейчас передается входная информация о системе, я внес изменение в скрипт PlanetLand. Возможно, это и не обязательно, так как SMax предусмотрел ситуацию, когда информация о системе не будет передана в явном виде. Но подстраховаться не помешает.
В остальном функционал пакета без изменений.

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

Zero Map - исследуй галактику самостоятельно! v0.6
Очередной апдейт моего исследовательского дополнения.

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

Изменений в механике работы плагина нет.

Доступен через встроенный диспетчер дополнений (Mechanics)!
Скачать: В личной рубрике.

Famous Planets ST 1.0

Мой переписанный скрипт замещен на вариант, предложенный SMax, который по идее должен устранить возможную ситуацию, когда при переходе на новую карту System Makeup может перекрыть своими настройками настройки Famous Planets ST. Этот момент, однако, все еще требует проверки в игре. Уязвимость для игровой механики не критична, но я согласен с Максом: код должен работать как задумано, а не как получилось.
Заодно информация в заголовке скрипта исправлена на более актуальную.

Famous Planets ST 1.1

К сожалению, проблему синхронизации Famous Planets ST и System Makeup при переходе на новую карту предыдущее обновление не закрыло, а наоборот, обострило. Поэтому до тех пор, пока решение не будет найдено, я откатил алгоритм работы пакета на исходный, который был в версии скрипта 0.9.
Пользуясь случаем, я перенес саундтреки 10 Знаменитых Планет (в общей сложности 28.7 MB) в отдельный ресурсный пакет. То есть теперь структура сборки выглядит так:
Famous Planets ST 1.1
Famous Planets ST Texture Pack A
Famous Planets ST Texture Pack B
Famous Planets ST Texture Pack C
Famous Planets Music Pack
Обращаю ваше внимание, что воспроизведение саундтреков можно отключить в самом скрипте. Достаточно найти строку

и заменить ее на

System Makeup 2.2

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

Famous Planets 1.2

Аналогичное соображение использовано в отредактированном алгоритме назначения текстур Знаменитых планет. Так как эта процедура запускается по событию startUpComplete, Знаменитые планеты гарантированно получают свои текстуры "в последней редакции".

Надеюсь, эти два обновления окончательно закрывают проблему синхронизации обновленных пакетов.

Sun Gear 2.5

Спешу успокоить геймера: масштабы солнечных систем остались прежними, размеры солнц и их спектральные характеристики тоже. Популяция светил Оониверсума тоже использует прежнюю базу данных: в системе Leesti по прежнему оранжевый карлик спектрального класса K9V, в Lave - более крупный и более горячий оранжевый карлик спектрального класса K1V, а в системе Reedquat - желтый двойник Солнца спектрального класса G2V. И все же обновление пакета, не побоюсь этого слова - революция в оострономии и игровой механике.
Солнца стали активными в полном смысле этого слова: уровень развития солнечной короны теперь не зафиксирован в planetinfo.plist, а динамически изменяется через скрипт. Каждый раз не только при входе в систему, но и при старте со станции активность солнца будет выставлена на новое значение. Вариации солнечной активности, однако, не вполне хаотичны: они основаны на определенной логике с отсылкой к реальной астрономии.
Большую часть времени солнце системы находится в спокойном состоянии. Уровень развития его короны в этом состоянии низкий. Время от времени, однако, светило вступает в активную фазу и его корона увеличивается. Как общее правило, холодные красные карлики вспыхивают чаще, чем горячие желтые звезды вроде Солнца. В реальной реальности - в сотни раз чаще, однако из игровых соображений я сильно смягчил эту зависимость, оставив лишь общую тенденцию. Вспышки оранжевого светила в системе Листи, к примеру, происходят чаще, чем желтого аналога Солнца в системе Риедкуат - но всего в полтора раза.
Системы, в описаниях которых упоминается солнечная активность, обрабатываются как особый случай. Вспышки в таких системах происходят чаще и могут достигать большей магнитуды. Если вам интересно, насколько часто попадаются такие системы в Оониверсуме, то вот вам статистические данные в сумме по всем 8 секторам:

Occasional solar activity - 53
Unpredictable solar activity - 29
Frequent solar activity - 24
Dreadful solar activity - 25
Deadly solar activity - 14

Total - 145

Так как поток солнечного ветра в моей модели зависит от уровня развития солнечной короны, этот поток теперь тоже меняется от полета к полету. Я перекалибровал коэффициенты в формуле расчета солнечного ветра с учетом более низкой активности солнц в спокойном состоянии (и кстати, благодаря этому преобразованию коэффициенты сократились и формула стала сказочно простой), но предпочел не восстанавливать прежние привычные геймеру уровни потоков солнечного ветра. Думаю, в игровом плане новая модель более интересна. Если раньше геймер, к примеру, гарантированно знал, что может всегда подкормится в системе Листи, не отклоняясь от трассы, то теперь в спокойном состоянии солнца напора солнечного ветра не хватает и пополнить баки можно только во время вспышки солнца. Вспышки светила Листи тем не менее происходят достаточно часто, чтобы не лениться заглядывать на страницу Stellar Data.
Формат вывода информации о солнечной активности доработан. Сейчас геймер видит на экране не Corona flare в сотых долях, который ему ниачем, а строку Solar activity - индекс активности солнца в "человеческом" формате. Спокойное солнце имеет индекс активности от 1 до 2, максимальная возможная магнитуда вспышки - 10.
Надеюсь, геймеру с наклонностью к исследованиям такой подход понравится. Теперь коммандер vasig может не спеша раскурить трубку где-нибудь в "Дымчатом драконе" и заметить что-то вроде:
- Ну, насчет десятибалльного солнечного шторма врать не буду, а вот во вспышку с индексом 9.97 я разок попал, было дело.
И заодно я исправил старую небрежность в выводе информации на экран Stellar Data. За стандартную свечу в линейке светил Sun Gear принято солнце спектрального класса G0V и от него все калибруется, но для геймера я вывожу на экран Stellar Data параметры светил, приведенные к привычному нам Солнцу. К сожалению, в свое время я допустил ошибку в коэффициенте пересчета светимости, отчего светимости светил на экране Stellar Data были изрядно занижены. Эта величина приведенной светимости в расчетах нигде не используется и на игровую механику никак не влияет, но она давала геймеру неверную информацию.
Исправлено.
Солнце системы Riedquat теперь имеет светимость 1.01 - как и положено двойнику Солнца (на расчетные параметры светил наложена псевдослучайная составляющая, чтобы замаскировать дискретный шаг линейки светил).

Набор пакетов Sun Coronae (8 planetinfo.plist с параметрами солнечных корон) из сборки удален за ненадобностью.

И хочу обратить ваше внимание - информация для геймера о пакете Sun Gear info RUS.pdf и о модели звездного ветра solar wind.pdf обновлена. Оба документа находятся в той же папке, где файл обновления пакета.

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

Here Be Dragons 0.8

Напоминаю: суть пакета в том, что он скрывает от геймера информацию о непосещенных системах за пределами 7 LY информационного горизонта. Причем на станции геймер видит на карте все системы и может планировать маршрут к ним, но ни паспорта этих удаленных непосещенных систем, ни их пиктограммы на карте он не видит. В полете все непосещенные системы за пределами 7 LY на карте спрятаны. Какой-либо обработчик особых случаев в пакете не предусмотрен.
К сожалению, такое легкое ленивое решение чревато конфликтом с пакетами других авторов, и один конфликт я отловил. Скрипт CargoTypeExtension-Dynamic в пакете New Cargoes (автор cim) в момент гиперпрыжка пытается обновить информацию о своих целевых системах. Не найдя их на карте, скрипт впадает в ступор и замораживает прыжок. Примерно через 20 секунд этот скрипт абортивно прерывается и прыжок происходит, но лаг в 20 секунд, сами понимаете, игру не украшает.
В обновлении пакета этот конфликт разрешен таким образом: при запуске обратного отсчета карта переключается в режим прыжка: видны все системы, но нет никакой информации о них даже в пределах 7 LY. После перехода в новую систему, прерывания отсчета или блокировки прыжка карта переустанавливается в обычный полетный режим.
При переходе в межзвездное пространство карта остается в режиме прыжка. Но поскольку все системы на карте видны, а маркер дальней навигации остается замкнутым на системе назначения, возвращение в обычное пространство проблем не составляет. При возвращении в обычное пространство опять же происходит обновление карты в обычном полетном режиме.

Добавлено 26.04
К сожалению, апдейт проблему конфликта с New Cargoes полностью не решил. При прыжке в воронку, открытую другим кораблем, скрипт не получает нужный сигнал и не переключает карту. Очевидный совет использовать событие "корабль сейчас совершит прыжок" не работает: скрипт CargoTypeExtension-Dynamic успевает первым перехватить управление.

И еще одно замечание о непростых взаимоотношениях моих пакетов с каноническими.
Не прошло и двух лет с момента перехода на новый механизм определения рынков (напоминаю, эта реформа произошла в Oolite 1.82), а авторы пакетов отреагировали на ситуацию и начали таки восстанавливать обрушенные старые рынки. Любопытно, что авторы почему-то не используют новый формат, где рынок порта объявляется непосредственно в shipdata.plist, а эмулируют через скрипт старый механизм. В принципе у такого подхода есть свой плюс - он гарантирует совместимость пакета с более ранними версиями Oolite. Так как рыночная матрица, определенная через скрипт, имеет приоритет перед рыночной матрицей, объявленной в shipdata.plist, мои перенастроенные рынки в этих портах не работают. Первым сигналом была ситуация с Deep Space Dredgers, а сейчас и в Anarchies то же самое - космослесари теперь воду, кислород и медикаменты не покупают, но торгуют драгметаллами, как в старые добрые времена.
По правде говоря, я сейчас не хочу эту ситуацию как-то разруливать. Есть мои орбитеры и планетные порты, вот там моя экономика работает как задумано.

Добавлено 26.04
Вероятно, ситуацию на самотек пускать таки нельзя. Скрипт рынка станций Anarchies определяет массу драгоценностей и наркотиков в тоннах, а в моей экономической модели они измеряются в килограммах. Я не тестировал ситуацию вживую, но не исключаю, что после визита на косморазборку и проведения там торговых операций геймер может обнаружить серьезное расхождение количества товара в грузовом манифесте
Независимое тестирование этой ситуации приветствуется.

Hard Way 1.9

Скорость корабля на топливном инжекторе (Witchfuel Injector) снижена с дефолтных 7 Vmax до 4 Vmax. Расход топлива при работе WFI снижен с дефолтных 0.25 LY/min до 0.125 LY/min. Эта перенастройка затрагивает не только корабль геймера, но и всех ботов.
Для чего сделано?
А вас не смущает, что даже здоровенная Анаконда с ее скоростью 140 при включении топливного инжектора уходит легкой трусцой от ракеты (скорость Анаконды на форсаже 140*7 = 980, скорость ракеты 750)? На мой вкус, с семикратным коэффициентом Джайлс слегка перебрал, да он и сам это признает. Но что поделаешь, 7 Vmax стал новым каноном.
Так что, теперь у Анаконды даже на инжекторе нет шансов уйти от ракеты?
При своевременном обнаружении пуска и быстрой реакции - есть. 750-4*140 = 190. При дистанции пуска 10 километров в угон ракете нужно 52.63 секунды, чтобы настичь цель. За это время ракета пройдет 39475 метров и самоликвидируется. А вот при пуске с 10 километров на встречных курсах шансов и правда нет: тяжелой Анаконде нужно примерно 8 секунд на отворот от ракеты. За это время ракета сократит дистанцию до 4 километров и настигнет цель через 29 секунд после пуска, пройдя расстояние 21750 м.
Это я к чему веду. В реальной реальности у ракетного оружия есть пространство решений пуска (weapon envelope), которое зависит от ракурса пуска и вектора скорости цели, и в авиасимуляторах этот фактор учитывается. В Оолите такими мелочами кодеры не озадачились - любой корабль с топливным инжектором гарантированно уходит от ракеты. По новым правилам даже сравнительно тихоходная Кобра Марк Один от ракеты по прежнему легко уходит, но полностью игнорировать пуск ракеты в бою будет сложнее.
В целом по моим наблюдениям перенастроенная скорость на форсаже игровой баланс не ломает. В реальной реальности типичные режимы полета - порядка 0.8 М в бесфорсажном режиме и разгон до 2 М по прямой на форсаже, соотношение 2.5.

Sun Gear 2.7

Внешне для геймера мало что поменялось. Ну разве что в Оониверсуме теперь стало больше оранжевых и меньше желтых звезд, и в среднем планеты стали более холодными, но ненамного. Планет с тропическим климатом как следствие стало меньше, но и миры с экстремально холодным арктическим климатом теперь скорее исключение, так как планеты в системах красных карликов стали ближе к своим солнцам. Но вот астрофизическая модель, лежащая в основе мира, основательно переработана.
Пожалуй, рассказ о выверке первоисточников, которые я использовал для построения модели, я пропущу, достаточно сказать, что граница между оранжевыми и желтыми звездами отодвинулась выше по шкале радиуса. Прежнее правило "большая планета - большое солнце" осталось в силе, но теперь планета получает желтое солнце начиная с радиуса 5000 км, а не 4500 км, как раньше. Оттого и оранжевых звезд стало больше.
Но это не все. Набора калиброванных шариков со стандартными радиусами больше нет. Радиусы светил заполняют диапазон значений, отведенных для данного спектрального класса. Температуры и массы светил тоже не заданы жестко из дискретного набора, а рассчитываются как функция радиуса и плавно заполняют шкалу. Каждое солнце на карте теперь имеет уникальный набор астрономических характеристик.
Радиус планеты больше не используется как базовая единица, определяющая расстояние между планетой и солнцем системы. Вместо морально устаревшего параметра sun_distance_modifier используется не привязанный к радиусу планеты параметр sun_distance. Радиусы орбит планет рассчитаны исходя из инсоляции и опять же плавно заполняют пространство расчетной зоны обитания - соответственно, планеты в системах красных карликов слегка придвинулись к своим тусклым светилам. В радиусы орбит добавлена небольшая псевдослучайная компонента, поэтому климат планеты теперь не так жестко зависит от спектрального класса солнца (но общая закономерность осталась: желтые звезды спектрального класса G в среднем обеспечивают более высокую температуру главной планеты).
Я прсмотрел все 99 Знаменитых планет из моего расширенного набора и индивидуально подстроил их орбиты, чтобы добиться лучшего совмещения текстуры планеты с ее расчетной температурой.
Разумеется, такой кардинальный апгрейд модели повлек за собой изменения кода - функции в библиотеке AstroLibrary переписаны. Структура пакета упростилась: я объединил все восемь индивидуальных planetinfo.plist для каждой карты в единый planetinfo.plist. Я готовлю всю исходную информацию в БД FileMaker, а десять минут на генерацию одного большого planetinfo.plist - это лучше и надежнее, чем восемь раз по десять минут на генерацию файлов для восьми вложенных пакетов, так что во вложенной структуре больше нет необходимости. Если что, коммандер vasig тоже присунет свои наклонные палочки не вручную
Новая модель Sun Gear полностью совместима с существующим деревом моих пакетов, их обновление не требуется. В чем прелесть AstroLibrary - это черный ящик. System Makeup, к примеру, просто пересылает радиус светила системы в AstroLibrary и получает оттуда расчетную температуру планеты, это все, что ему нужно знать, чтобы выбрать для нее текстуру. Аналогично Planetary Systems посылает радиус светила в AstroLibrary и получает уже рассчитанный орбитальный период главной планеты.

Moons 0.7

Бывают такие мерзкие дефекты в коде - проявляются через раз, а то и изредка, и поди разбери, почему.
Индикация лун планет-гигантов была одним из таких плавающих дефектов - иногда пакет Таргоида Planetary Compass их видит, иногда нет. До поры до времени я с этим мирился: сама планета-гигант на астрокомпасе видна нормально, а луны глазом видны еще на дальнем подлете.
Но вот с обновлением пакета PlanetLand, в котором принята новая схема "одна планета - один порт", получилось нехорошо. Чтобы сесть в этот порт, надо замкнуть астрокомпас на планету или луну назначения. Но раз луна на астрокомпасе не видна, то и сесть в порту невозможно. Ни рынка, ни картинок, даже на пейзаж луны с газовым гигантом на дальнем плане не полюбуешься. На что и обратил мое внимание коммандер vasig, и на этот раз откорячка "да ладно, не критично же" не прокатывала.
Проблему можно было решать двумя путями. Можно было переписать кусок кода в пакете PlanetLand, который отвечает за выбор порта - вновь объявить PLC как активируемое оборудование (primed equipment), но вот честно - решение с астрокомпасом мне нравится. К дальнему газовому гиганту все равно приходится лететь по астрокомпасу. Ну или разобраться наконец, что не так с Planetary Compass - почему он стабильно видит луны главной планеты, но видит луны дальних газовых гигантов через раз.
Вот знаете, слепые пятна в восприятии мира - интересная штука. Ясно же, что технически луны газовых гигантов ничем от лун главной планеты не отличаются. Кроме одного момента. Луны газового гиганта в пакете Moons засеваются с небольшой задержкой, для того чтобы успел отработать пакет Planetary Systems и планеты определились по своим орбитам.
Полез в код Таргоида, чтобы посмотреть, как оно там устроено внутри. И точно. Таргоид - грамотный кодер. Процедура сканирования небесных тел системы и обновления локальной базы данных астрокомпаса запускается с задержкой 0.25 секунды, чтобы дать всяким сторонним пакетам время добавить свои планеты и луны в систему. А у меня при засеве лун газовых гигантов объявлен лаг в целую секунду!
В обновлении Moons 0.7 время задержки засева лун уменьшено до 0.2 секунды.

Коммандер vasig не только вновь обратил мое внимание на проблему, но и протестировал обновление пакета. Спасибо за помощь, vasig!

P.S. Я все же не исключаю, что для совсем уж маломощной машины задержка в 0.2 секунды окажется слишком маленькой и тогда в Оониверсуме появятся "оторванные" от планет луны. Поэтому по прежнему призываю: не будьте потребителями. Пробуйте и сообщайте, видны ли луны газовых гигантов на астрокомпасе.

P.P.S. Для тех, кто многобукф в мануале PlanetLand ниасилил. Для посадки в порту нужно
а) замкнуть астрокомпас на планете/луне назначения
б) в момент посадки держать скорость в пределах зеленого сектора

А где эти oxp найти можно?