Ветка форума "Авторские рубрики", в моей личной рубрике есть линк на Google Drive, коммандер vasig поддерживает зеркало на ЯД.

Благодарю! Я заблудился на форуме

Замечу сразу: если вы твердо убеждены, что опция Docking Clearance Protocol в меню настроек игры F2 должна быть изначально установлена на OFF, дальше просто не читайте. Пакет рассчитан на геймера, которому постоять десяток минут в очереди на стыковку в конце полета не в падлу. В любом хорошем авиасиме, где геймер не один в воздухе, он даже после насыщенной событиями боевой миссии не плюхается на полосу с ходу, а встает в очередь за ранее прибывшими бортами.
Но вот проблема в том, что в Оолите ничего похожего на нормальную организацию трафика в аэропортах реальной реальности или хороших авиасимах не наблюдается. Это старая болячка и с каждым новым релизом разработчики пытались ее пролечить - но увы...
Знакомая картина: вы подходите к главной станции и видите кучу кораблей, которые возле нее скопились и стоят без движения. Запрашиваете очередь на стыковку, получаете свой номер 12 и терпеливо ждете. Следующие пять минут совершенно ничего не происходит. И еще следующие десять тоже ничего не произойдет. Причем без всяких видимых причин - никакого боя в окрестностях станции не происходит и станция не объявляла закрытие прибывающего трафика, чтобы выпустить звено Вайперов. А это, дорогие мои разработчики, уже не фича, а баг. Поэтому вы с тихим незлым словом ставите игру на паузу, лезете в меню настроек и переключаете Docking Clearance Protocol на OFF. И напоминаете себе: перед сохранением игры не забудь снова переключиться на Docking Clearance Protocol ON. Или активируете моду Fast Docking (Shift - C), которую было бы правильнее назвать Instant Docking, так как эта опция мгновенно переносит корабль геймера в доки, минуя процесс причаливания.
Веры в то, что в следующем релизе трафик в окрестностях главной станции уж точно пофиксят, все меньше, проблему надо как-то решать. Совсем отключать запрос на стыковку жаль: этот режим добавляет игровую атмосферу. Режим мгновенной стыковки, по правде говоря, вообще смахивает на читерство. Когда в очереди перед тобой три или четыре корабля, обычно очередь движется без задержек, проблем не возникает. Да и полтора десятка бортов станция часто принимает без проблем. Возникает такое ощущение, что длинная очередь - скорее не причина бага, а его следствие.
Что именно не так в игровом движке - честно отвечу: не знаю. Но делать что-то надо, чтобы не лазить вот так каждый проблемный раз в меню F2. Надоело уже.

Способ правильный, но сложный. Каждые две минуты сканируем очередь. Если первый корабль в очереди все еще не состыковался, изымаем его из очереди - отменяем запрос на стыковку (параметр dockingInstructions) и назначаем AI альтернативную инструкцию. Вали куда хочешь, только на глазах не маячь. И так пока пробка не рассосется.
Почему именно две минуты? Ровно на такое время открывают окно стыковки геймеру. Не успел - запрашивай по новой. Почему бы от AI не требовать то же самое?
Ну, во первых, вмешательство в AI требует определенного уровня квалификации - как бы лекарство не оказалось с побочными эффектами. Не умеешь - не лезь куда не просят. И во вторых, не факт, что поможет. Возможно, проблема не в AI кораблей, а в AI самой станции. Допустим, станция не дает добро на стыковку, пока не выпустила патрульное звено Вайперов или челнок, и именно эта процедура время от времени зависает. А с очередью покидающих станцию кораблей на мой дилетантский взгляд намного сложнее - физически они в Оониверсуме еще не засеяны.

Способ правильный и очевидный. Чем самому пилить велосипед, не проще ли поискать, что уже сделано?
Ага, вот что-то по теме. Station Dock Control, автор Nick Rogers, он же phkb (пакеты Email System, GalCop Galactic Registry и конечно же, амбициозный пакет для технофетишистов Ship Configuration). Серьезный дядька. Скрипт stationdockcontrol.js длиной 4280 строк не желаете на ночь глянуть? ИМХО ни разу не KISS.
Из описания пакета Station Dock Control на EliteWiki можно понять, что этот пакет создает нечто вроде информационного табло с указанием времени отбытия кораблей со станции - а некоторые корабли даже оповещают о системе назначения. Полезная фича, кстати, при отыгрыше альтернативного сценария старта на корабле, не снабженном гипердрайвом. Но на самом деле 4280 строк кода не только про это. Прибывающим бортам скрипт тоже уделяет внимание и время от времени вносит коррективы в их план полета.
О, а вот же, гляньте, начиная со строки 3831:

Неужели оно? Ну так и чего ради мастерить что-то самобытное, если умные люди проблемой уже озадачились?
Немного ревниво было, не скрою - только было собрался что-то решать, и вот оно уже сделано. Но самому писать 4280 строк самобытного кода как-то лениво.
Поставил пакет. И буквально тут же по прибытию на рейд главной станции в системе Тионисла - прекрасная модельная ситуация, лучше не придумаешь. Пробка из 12 бортов, ожидающих разрешения на стыковку.
Запросил разрешение, получил свой номер 13, завис и устроился поудобнее. Дай, думаю, погляжу, как скрипт эту ситуацию разрулит.
Что было дальше, сами уже догадались?
Никак скрипт эту пробку не разрулил. 15 минут ожидания - и никакой движухи.
А табло отбывающих бортов есть, да. И обновляется в ходе просмотра, как было обещано в описании.

Ну ладно. Попробуем с другой стороны. Пусть неправильно, но попроще.
Если пробку не удается устранить, то почему бы не дать геймеру возможность ее обойти без этих манипуляций "ставим игру на паузу - заходим в меню F2 - переключаем Docking Clearance Protocol на OFF - возвращаемся в игру - стыкуемся - снова заходим в меню F2 - переключаете Docking Clearance Protocol на ON - сохраняемся и играем дальше". В идеале все эти манипуляции должен делать скрипт как часть игрового процесса. Мужчина, тут на трассе авария, ехайте в объезд.
Думаю, пора перейти к изложению сути идеи.

Изначально алгоритм объездного пути мыслился так.
На подходе к главной станции устанавливается верхний предел длины очереди, скажем, 15 кораблей. Более длинные очереди реализуются крайне редко.
Запрашиваем разрешение на стыковку. Запускается таймер.
Через две минуты таймер сравнивает реальную длину очереди с верхним пределом. Если реальная очередь меньше верхнего предела, то верхний предел выставляется на реальную длину очереди. Иначе верхний предел уменьшается на единицу.
Далее каждые две минуты сравнение повторяется.
В результате - если очередь движется без задержек, то корабль получает разрешение на стыковку как обычно. Если очередь застряла, то придется ждать при наихудшем раскладе максимум 30 минут.
То есть в принципе такой алгоритм как бы реализует работу диспетчерских служб по разблокировке пробки. Если очередь не продвигается, то каждые две минуты высвечивается обновление максимального времени ожидания.
Но потом лень пересилила. По моим наблюдения, больше 10 минут стоять в очереди приходится редко, а больше 15 минут - крайне редко. Когда все идет нормально, то прибывающие борта стыкуются с главной станцией с интервалом меньше минуты, а отбывающие так вообще вылетают каждые 10...15 секунд. Поэтому достаточно задать время ожидания 15 минут без оглядки на длину очереди. Как правило, очередь или успевает пройти за эти 15 минут, или застревает намертво и не движется вообще.
Ну а теперь конкретно описание пакета.

Emergency Docking Clearance 0.6

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

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

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

Docking clearance status: Emergency docking in # min
Статус запроса на стыковку: стыковка вне очереди через # мин

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

А теперь варианты "не как обычно", ради которых и был создан пакет.

Вариант третий. Очередь заморозилась. Когда таймер достигает нуля, Docking Clearance Protocol устанавливается на OFF (разрешение на стыковку не требуется) и выводится сообщение:

Docking clearance status: Emergency docking allowed
Статус запроса на стыковку: стыковка вне очереди разрешена

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

Вариант четвертый. В окрестностях станции завязался бой. Станция прекращает принимать борта, чтобы экстренно выпустить звено Вайперов, потом возобновляет прием бортов. Или не возобновляет. На время боя таймер замораживается и выводится сообщение

Docking clearance status: Emergency docking freezed
Статус запроса на стыковку: стыковка вне очереди приостановлена

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

И напоследок еще один возможный вариант номер пять - в дефолтном Оониверсуме он реализуется крайне редко, но в моем Оониверсуме с расходом топлива это вполне типичная аварийная ситуация, которую пакет просто обязан принимать во внимание.
Вы подходите к станции с минимальным запасом топлива, скажем, 0.2 LY, и вас ставят в очередь на общих основаниях. Топливо кончается раньше, чем вы получаете разрешение на стыковку. В дефолтном Оониверсуме отсутствие топлива означает лишь невозможность вести скоростной бой на форсаже или спастись бегством, если вас вдруг атакуют в окрестностях станции. В моем мире с пакетом Hard Way отсутствие топлива означает невозможность вести бой вообще, так как корабль без топлива лишается щитов. Оставшись без щитов, корабль геймера получает разрешение на стыковку вне очереди (вариант номер три, но до истечения 15 минут обратного отсчета).
Хочу обратить ваше внимание: скрипт проверяет условия открытия стыковки вне очереди не непрерывно, а раз в минуту И отдельно по запросу. Может выйти так: топливо у вас закончилось в начале очередной минуты цикла, но пока таймер не досчитает эту минуту, права на внеочередную стыковку у вас нет. Попытка состыковаться до истечения этой минуты повлечет штраф (вообще говоря, при подходе к створу причального колодца станция предупреждает, что у вас нет права на стыковку, но кто эти буквы читает?). Поэтому повторно пошлите запрос. По первому запросу станция вернет стандартное сообщение, но флаг Docking Clearance Protocol переключится на OFF. Второй запрос - исключительно для подстраховки, чтобы убедиться, что разрешение больше не требуется.

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

Вариант номер шесть. То же самое по варианту номер пять. Получив запрос, станция пошлет стандартный ответ, но флаг Docking Clearance Protocol переключится на OFF и можно будет стыковаться.
Почему так сложно? Неужели нельзя дать геймеру сразу понять, что его запрос принят и одобрен?
Здесь, видите ли, конфликт уровня приоритетов. Игровой движок в ответ на запрос формирует свое стандартное сообщение и только потом скрипт переключает флаг Docking Clearance Protocol. Поскольку отключить стандартное сообщение нельзя, выводить вдогонку сообщение, что стыковаться таки можно - плохая идея: это приведет к путанице. Поэтому скрипт выводит свои сообщения только по таймеру, а не по запросу. Если уж обозначать, что разрешение на стыковку получено - то не через текст, а через какой-то индикатор на HUD или через обновляемую строку на панели MFD. А пока так: чтобы уточнить статус, посылаем повторный запрос и получаем стандартное сообщение.

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

Ну и еще один мысленный эксперимент. Предположим, вы запросили стыковку, а потом передумали и направились куда-то еще.
Как только вы покинете зону контроля главной станции, запущенный таймер сбросится. То же самое произойдет, как только вы откроете червоточину, чтобы направится в другую систему. Если разрешение на стыковку вне очереди было уже получено, то флаг Docking Clearance Protocol останется в положении OFF. Но как только вы вернетесь в зону контроля главной станции, Docking Clearance Protocol снова переключится в положение ON и разрешение надо будет запрашивать по новой.
Главная станция всегда находится на высоте, равной радиусу планеты. Если радиус планеты менее 5120 км (51.2 км в игровой шкале), то зона контроля станции достигает поверхности планеты. Что произойдет, если геймер совершит посадку в планетном порту, не покидая зону контроля главной станции? То же самое, что и в предыдущем случае: при посадке в планетном порту таймер сбросится, при взлете флаг Docking Clearance Protocol установится на ON.

И еще одно техническое замечание напоследок.
Сам по себе скрипт в сэйв ничего не пишет. Но поскольку в сэйве фиксируется состояние флага Docking Clearance Protocol, то в сэйве запишется то состояние флага, которое было в момент стыковки с главной станцией. Для игры это не играет роли, потому что при загрузке из сэйва и старте с главной станции флаг Docking Clearance Protocol установится на ON независимо от того, что там было записано в сэйве. Но если вы решите удалить этот пакет и играть с отключенным запросом на стыковку, вам надо будет после удаления пакета отключить флаг Docking Clearance Protocol в меню F2 вручную.

Я выражаю благодарность коммандеру vasig за тестирование пакета в ходе его разработки и в особенности за обнаружение критического бага в алгоритме версии 0.1.

Скриншот иллюстрирует работу пакета. Желтая строка - показание таймера с обратным отсчетом момента открытия окна стыковки вне очереди (осталось 10 минут). Зеленая строка - стандартное сообщение о продвижении очереди.

Добавлено 15.06.2017: В функционал пакета добавлен модуль визуального отображения статуса разрешения на стыковку. Название пакета изменилось на Traffic Lights. Дополненное описание пакета готовится.

Traffic Lights 0.7

Итак, что добавилось в пакете и почему я решил сменить его название.
Изначально основной функцией пакета Emergency Docking Clearance было разрешение проблемы замороженной очереди на стыковку. Если все идет нормально (а обычно так оно и бывает - как только ты написал и отладил инструмент для решения проблемы, она почему-то перестает досаждать своей удручающей регулярностью), то пакет работает в фоновом режиме, раз в минуту выводя свои сообщения, чтобы информировать геймера, сколько ему осталось ждать, если очередь вдруг застрянет. Но когда я уселся за описание всех этих возможных вариантов нештатного развития событий, мне стало ясно, что рекомендации "если сомневаетесь - пошлите повторный запрос" геймеру недостаточно. При нормальном ожидании повторный запрос на стыковку игровой движок воспринимает вообще как выход из очереди и очередь придется занимать заново. По хорошему, нужен хорошо читаемый визуальный хелпер, ясно сигнализирующий: разрешение на стыковку получено, путь свободен.
Один из очевидных вариантов - индикатор на HUD. Но по здравому размышлению, это не лучшее решение. Вариантов HUD много и сигнал, хорошо читаемый на дефолтном HUD, будет плохо различим на полупрозрачном CB HUD и наоборот. Поэтому я решил проблему с помощью сигнальных огней.
В основу модуля визуализации режима стыковки я взял скрипт и ресурсный файл effectdata.plist из пакета Таргоида Neo-Dock Lights 1.00. Этот пакет создает цепочку мигающих огоньков (flashers) на линии между главной станцией и бакеном. В пакете Таргоида огоньки находятся в двух состояниях:
Зеленый - кораблей на причальной линии между станцией и бакеном нет.
Красный - корабли на причальной линии есть.
Никакой информации о статусе стыковки пакет Таргоида не дает - он помогает пилоту выставиться по оси шлюза на подходе и предупреждает о внезапном появлении корабля в створе (скажем, выпуск стартующего корабля навстречу вашему подходящему к станции).
Я добавил в effectdata еще один цвет и модифицировал скрипт Таргоида, привязав цвета к статусу стыковки:
Красный - стыковка запрещена.
Желтый - стыковка разрешена, но в створе есть другие корабли.
Зеленый - стыковка разрешена, створ чист.

Я обязан предупредить: пульсирующие огни могут спровоцировать приступ эпилепсии при наличии предрасположенности.
Это не стёб, а реальный медицинский факт.
Но даже если не брать в учет это обстоятельство, возможно, необходимость пролетать сквозь цепочку пульсирующих огней может вызвать субъективно неприятное ощущение. Или вы привыкли к альтернативной схеме причальных огней. Или принципиально не признаете эту иллюминацию, потому что в стыковке самой по себе нет ничего сложного. Поэтому вы вправе задать вопрос: а можно просто Emergency Docking Clearance без этой иллюминации?
Можно.
Скрипты emergency_docking.js и traffic_lights.js работают независимо. Они собраны в одном пакете потому, что делают два куска общей задачи. Если вам не нужна илюминация, то проще всего поступить так:
Открываете файл world-scripts.plist в папке Config и убираете под коммент строку "traffic_lights.js",
То есть так:
// "traffic_lights.js",

Пакет Traffic Lights конфликтует с пакетом Neo-Dock Lights Таргоида. Я также не рекомендую его использование с другими пакетами, создающими дорожку причальных огней, так как результат их наложения может выглядеть мусорным.
И еще раз обращаю ваше внимание. Область компетенции пакета Traffic Lights - исключительно главная станция.

Traffic Lights 0.8

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

И снова работа над небрежными решениями.

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

SW Shipdata 3.1

Все перенастройки ТТХ дефолтных кораблей перенесены в этот новый модуль.
В это же пакет я перенес перенастройку множителя скорости на форсаже (WFI) 4 Vmax вместо дефолтной величины 7 Vmax. Для компенсации увеличения расхода топлива на единицу пути скорость расхода топлива снижена с дефолтной 0.25 LY за 10 секунд до 0.125 LY за 10 секунд. Это глобальная перенастройка, действующая не только на все варианты корабля геймера, но и на всех ботов.

SW Equipment 3.1

Класс корпуса корабля по прежнему определяет возможность приобретения оборудования. К примеру, для приобретения рудного процессора необходим как минимум корпус среднего класса, а флотских силовых щитов - тяжелого.
Уровень заряда кормового щита также зависит от класса корпуса корабля.

Легкий класс - заряд кормового щита 50% носового
Средний класс - 75%
Тяжелый класс - 100%

Зависимость множителя скорости полета на форсаже от класса корпуса корабля из пакета изъята.

Пакеты SW Equipment 3.1 и SW Shipdata 3.1 входят в состав суперпакета Stranger's Set 3.1. Напоминаю, все пакеты в этом наборе можно ставить по отдельности.

Hard Way 2.0

Перенастроенный множитель скорости полета на форсаже 4 Vmax из пакета изъят и перенесен в новый пакет SW Shipdata.

Here be Dragons 0.9

По моим наблюдениям, System Makeup с переписанным с помощью SMax новым алгоритмом не всегда правильно определяет текстуру планеты при входе в новую систему. Я предполагаю, что это связано с тем, что Here be Dragons успевает спрятать непосещенные системы на карте до того, как System Makeup формирует свой массив с текстурами удаленных систем.
В обновлении Here be Dragons 0.9 пакет обрабатывает системы на карте и скрывает информацию о непосещенных системах по событию this.startUpComplete, после того, как System Makeup формирует свой список текстур.
Я думаю, эта пилюля должна решить проблему, но рассчитываю на помощь в тестировании.

Traffic Lights 0.9

В коде пакета исправлен замеченный коммандером cyxoway баг - размножение таймера при повторном запросе стыковки с ГОС.

Planet Land 2.3

Хм... раз уж эти космослесари на ГОС при плановом техобслуживании корабля вполне в состоянии отъюстировать гипердрайв, то уж технологии, берущие начало аж в XX, веке, им вполне по силам, не?
Восстановление ресурса службы системы планетной посадки PLC включено в плановое техническое обслуживание (Maintenance overhaul). В связи с этим фирменная гарантия "10 стопроцентно безотказных посадок на новой приобретенной системе" изъята из лицензии.

Traffic Lights 1.0

Дискуссия с коммандером cyxoway окончательно подтолкнула меня к мысли, что с набегающими в лицо огнями и правда надо что-то делать. Думаю, я нашел удачное решение (см. приложенный скриншот).
В ходе дискуссии мы оба как-то упустили серьезный изъян пакета, на фоне которого прочие замечания и предложения - и правда на вкус и цвет.
Сигнальные огни никак не информируют геймера, стоит ли он в очереди на стыковку.
Добавлен четвертый цвет огней.
КРАСНЫЙ - стыковка запрещена
ЖЕЛТЫЙ - стыковка разрешена, но в зоне подхода есть другие корабли ИЛИ осталось менее 30 секунд до закрытия окна стыковки.
ЗЕЛЕНЫЙ - стыковка разрешена, зона подхода свободна от других кораблей.
СИНИЙ - геймер не поставлен в очередь на стыковку или вышел из нее.

И кстати, мне понравился способ объявления таймера в версии коммандера cyxoway. Я использовал его решение в своем допиленном пакете.

Stranger's Economy 3.2

В целом суть пакета осталась прежней.
Товары промышленной группы отсутствуют в продаже на рынках аграрных систем.
Товары аграрной группы отсутствуют в продаже на рынках индустриальных систем.
Товары сырьевой группы имеются в продаже только в ориентированных на добычу сырья системах низкого технологического уровня и в индустриальных системах.
Нелегальные товары доступны в свободной продаже только в политически нестабильных системах низкого технологического уровня.
Фильтры, однако, стали гибче и теперь учитывают не только технологический уровень и экономический профиль системы, но показатель продуктивности.
Берем, к примеру, три индустриальных системы:

Заонце - 12 технологический уровень, сильная индустриальная экономика, продуктивность 41976 МКр/сутки.
Листи - 11 технологический уровень, обычная индустриальная экономика, продуктивность 35200 МКр/сутки.
Ореску - 10 технологический уровень, сильная индустриальная экономика, продуктивность 17280 МКр/сутки.

В дефолтной экономической матрице рынок определяется исключительно индексом экономической специализации (это то, что геймер видит в паспорте системы под вводящими в заблуждение названиями "средняя индустриальная" или "бедная аграрная"). Рынки Заонце и Ореску в дефолтной экономике идентичны. Если взять такие товары индустриальной группы, как электронику и механизмы, то в среднем получим такую картину:

Заонце - электроника 42...45 т, механизмы 34...41 т
Листи - электроника 28...31 т, механизмы 28...35 т
Ореску - электроника 42...45 т, механизмы 34...41 т

В моей экономической модели количество электроники и механизмов перебалансировано, при этом в первой дискретной версии фильтра порог обрезания электроники был установлен на 11 технологический уровень. Ниже этого уровня электроники на рынке не было вообще вне зависимости от экономического профиля системы. То есть на рынке Ореску электроники не было, были только механизмы. Примерно так:

Заонце - электроника 19 т, механизмы 45 т
Листи - электроника 15 т, механизмы 36 т
Ореску - электроника 0 т, механизмы 45 т

Теперь перенастроенный более гибкий фильтр дает на выходе примерно вот что:

Заонце - электроника 26 т, механизмы 61 т
Листи - электроника 18 т, механизмы 44 т
Ореску - электроника 16 т, механизмы 38 т

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

Вторая новость касается рынков внешних портов. И это хорошая новость: я их теперь уже точно пофиксил.
Думаю, стоит еще раз напомнить суть проблемы. С выходом Oolite 1.82 с его новым форматом объявления рынков старый формат перестал работать и рынки таких популярных внешних портов, как косморазборки, астрогулаги и драги легли. Чтобы заполнить вакуум, я сделал плагин (e)Xternal Markets, в котором перенастроил эти порты под свою экономическую модель. Плагин работал замечательно, но лишь до тех пор, пока авторы пакетов не принялись наконец адаптировать их к новой реальности. А так как они объявили рынки по своему, мой плагин в свою очередь перестал работать как было задумано.
Ну казалось бы, что он Гекубе, что ему Гекуба? Заглушка дыру в экономике Оониверсума на время закрыла, перестройку и разруху пережили, жизнь наладилась - спасибо и до свиданья. Но вот в чем дело: я как-то вжился в логику своей экономической модели и в чужой мне неуютно. Не для того я настраивал рынки своих внешних портов, чтобы вмиг обрушить систему внутрисистемных перевозок несуразно низкими ценами на сплавы на драгах. Да и косморазборки - чем кормятся космослесари? Режут корпуса брошенных кораблей, торгуют металлом и механизмами - тем и живут. А руда и тем паче драгметаллы - вы уж извините, не их профиль. Астероидные отшельники тогда на что?
Думаю, технические подробности уместно вынести в отдельную тему. А здесь достаточно сообщить, что переписанный плагин больше не существует как отдельный пакет, а интегрирован в Stranger's Economy. Логика такого решения проста. За пределами моей экономики плагин не работает корректно, так как он регулирует в том числе три новых товара моей матрицы - пресную воду, кислород и медикаменты. А при переключении экономики на мою модель плагин обеспечит синхронизацию рынка внешних портов с рынком главной станции.
Рынки переназначены для следующих внешних портов:

Anarchies

Salvage Gang
Hackers Outpost
Renegade Station

Commies

Astrogulag Penal Colony
CZGF
SLAPU

Dictators

Astrofactory

Galactic Navy

Navy Station

Deep Space Dredgers

Dredgers

Пакет Stranger's Economy 3.2 входит в состав суперпакета Stranger's Set 3.2.

Start Choice Addenda 0.5

Пакет, напоминаю, предлагает два новых игровых сценария - карьеру экспедитора на маршруте земля-орбита (Транспортер с PLC) и астероидного старателя на Бушмейстере с горным лазером и сборщиком топлива.
Я наконец нашел время исправить косметический дефект пакета - задний вид из игрового Бушмейстера отредактирован так, что детали модели корабля теперь не попадают в поле зрения камеры.
И напоминаю еще раз, для работы пакета Start Choice Addenda необходима установка пакета Start Choices (автор spara).

Mineral Store Reset 0.4

Пакет время от времени обновляет рынок минералов главной станции, предотвращая его переполнение. Это дает возможность геймеру отыграть альтернативный старт на корабле, не оборудованном гипердрайвом.
Алгоритм обновления рынка минералов на главной станции переработан.
В предыдущей версии рандомайзер определял обновление рынка минералов независимо от времени предыдущего обновления. Геймер был вынужден терпеливо ждать, когда рандомайзер почистит наконец рынок и можно будет снова таскать на ГОС минералы. А при невезении эта серия не пошедших в зачет бросков костей могла длиться долго.
Теперь после обновления рынка минералов флаг состояния устанавливается на ноль и рандомно увеличивается на каждом цикле. При достижении единицы рынок обновляется и флаг снова сбрасывается на ноль.
Для обновления рынка минералов главной станции теперь недостаточно стартовать с нее и быстренько вернуться. Теперь после старта со станции надо отлететь от планеты минимум на три радиуса, что ищущий астероиды старатель обычно и делает.

Начну с традиционного длинного предисловия по сути проблемы.

Оолит, бережно сохранивший наследие Элиты, сохранил и ее упрощенную донельзя модель боевых повреждений. Корабли в Оолите - это такие тонкостенные алюминиевые банки, защищенные лишь энергетическими полями. Никакого прочного корпуса как такового нет в помине. Для лунной кабины Аполлона это нормально, для ведущих боевые действия кораблей как-то странно. Чего уж там, даже сугубо гражданские по предназначению модули МКС имеют противометеоритную экранную защиту.
Такая упрощенная модель приводит к очень серьезной дыре в игровой механике.
Представьте себе пушечную дуэль между тяжелой Коброй Марк Три с ее максимальным уровнем 256 единиц и темпом заряда 4 и легким Аддером, у которого всего 85 единиц энергии и темп заряда 2. Допустим, оба корабля не имеют апгрейда энергетики и щитов и вооружены лучевым лазером. Если учесть скорость Аддера 240 против 350 Кобры, то при равной квалификации оппонентов шансы пилота Аддера выглядят уныло.
Не все так просто.
Исход пушечного боя на самом деле определяется в первую очередь не энерговооруженностью корабля, а тем, кто первым сумеет добиться попадания и удержать цель в конусе огня. Оба корабля без апгрейдов имеют одинаковый уровень заряда носового щита (128 единиц энергии), но Аддер за счет маленького силуэта имеет хорошие шансы пристреляться первым. Прожигание носового щита из лучевого лазера занимает чуть больше двух секунд - ровно столько у пилота Кобры будет времени на принятие решения обрывать огневой контакт и выходить из боя во избежание каскадного отказа оборудования под дальнейшим сосредоточенным огнем противника. Четыре уровня энергостека и высокий темп восполнения энергии в этой ситуации никак не защищают оборудование и груз от повреждения, а лишь задерживают момент появления экрана Press Space Commander и дают самонадеянному пилоту Кобры больше времени на попытку спастись с поля боя бегством.
Я не хочу сказать, что уровень энергии в бою не важен. Энергия нужна в первую очередь для работы ECM, да и лазерная пушка тоже при ведении огня потребляет энергию. Опять же, попав под сосредоточенный огонь группы пиратов на выходе из червоточины, корабль с емким энергостеком имеет шанс выжить, отделавшись потерей части груза и некритичного оборудования там, где корабль с энергостеком меньшей емкости будет гарантированно уничтожен. А такие случаи бывают.
Обычно на жалобные вопли геймера, который в ходе стычек регулярно залетает на ремонт оборудования стоимостью в тысячи кредов, хочется ответить: мужчина, а вы не пробовали для начала поработать над тактикой боя? Ну, хотя бы обрывать огневой контакт, не дожидаясь прожига щитов? Но и правда, в моем мире с щитами, которые переключаются на джампе до четверти номинального уровня, не всегда есть возможность изготовиться к бою заранее и внезапный меткий огонь военного лазера с края поля сканера всего за долю секунды запросто может превратить прокачанную до железной задницы Кобру в хромую утку с убитым инжектором. И ведь самое обидное - боты на энергетический урон при формальном паритете ТТХ реагируют куда спокойнее. По правде говоря, на энергетический урон они начинают обращать внимание только когда их основательно поджаришь. Перед тем, как окончательно сдохнуть. При том, что здравомыслящий геймер при таком раскладе предпочтет не нарываться на новые неприятности и благоразумно покинуть поле боя. И опять же, помимо обычных стычек, которые геймер волен оборвать на свое усмотрение, есть специальные миссии вроде контрактов в Random Hits, где хочешь не хочешь, а валить клиента как-то надо невзирая на заградительный огонь эскорта.

Что можно сделать для закрытия дыры в игровой механике старой Элиты, которая в Оолите превратилась в бережно хранимый канон? Ну, конечно, кроме очевидного апгрейда щитов Shield Boosters?
Можно защищать критически важное в бою дорогое оборудование толстым слоем корабельных котов, пивных кулеров и прочих гаджетов, лишь бы они обрабатывались игровым движком как повреждаемое оборудование и принимали на себя часть вероятности повреждения при энергетическом уроне после прожига щитов. Модель повреждения оборудования в игровом движке проста донельзя: при энергетическом уроне взвешиваются вероятности повреждения по всему списку оборудования и на основании этих весов делается случайный выбор. Прием пассивной защиты разбавлением вероятности повреждения реально работает, но эксплуатирует другую дыру игрового движка - отсутствие отсека оборудования ограниченной емкости. Возможность набивать корабль таким хламом без ограничений - очевидный, грубый и некрасивый чит, интересный разве что геймеру с IQ пятиклассника, который даже не подозревает, что опытный геймер о таких способах узнал задолго до кулхацкера и попросту ими брезгует.

Можно использовать дополнительную защиту оборудования. Преамбула моего доклада наводит на мысль, что речь далее пойдет о симуляции брони. И действительно, я изучил и опробовал такую возможность. Вы ведь тоже начинаете со сложных решений задачи, правда? Скажу сразу: способ вроде IronHide Таргоида задачу не решает. Да, после прожигания щитов броня принимает на себя удар, предотвращая опустошение энергостека, но броня не защищает оборудование и груз корабля от повреждений при проникающем ударе, так как проверка события "оборудование повреждено" - процедура, которая запускается игровым движком до того, как медленный JavaScript успевает восстановить максимальный уровень энергостека. Технически есть, конечно, возможность допилить алгоритм Таргоида, принудительно восстанавливая повреженное оборудование опять же через скрипт, пока броня не исчерпает запас стойкости. Ну или перебалансировать вероятность восстановления поврежденного оборудования исходя из оставшегося процента стойкости брони. Можно даже симулировать деградацию брони при систематическом игнорировании регулярного технического обслуживания корабля (Maintenance Overhaul). В общем, идей в этом направлении куча и часть из них я опробовал в опытном пакете Strong Hull. До чего можно довести идею бронирования, если взяться за разработку этой темы всерьез, понятно из пакета Норби HardShips, где не просто симулирована монолитная скорлупа, как у Таргоида в IronHide, а реализовано разнесенное многослойное бронирование. Норби, кстати, использует именно описанный выше прием: скрипт проверяет, какая именно единица оборудования получила повреждение, и если она была прикрыта броней, принудительно ее восстанавливает, повреждая взамен броню. Это я обнаружил задним числом, поигравшись со своим опытным пакетом и остыв к нему, так что тут я Америку не открыл. Симуляция прочного корпуса с ограниченной стойкостью - идея сама по себе разумная и вовсе необязательно доводить ее до суровой хардкорности HardShips. Но тогда из принципа паритета надо симулировать и броню ботов, а при таком раскладе KISS решение с кодом в полсотни строк ну никак не получается. Да и прием принудительного восстановления поврежденного оборудования имеет легкий привкус небезупречности и чреват непредсказуемыми сюрпризами. В идеале надо бы защитить оборудование от повреждений, а не восстанавливать его задним числом. А поскольку вероятность повреждения оборудования имеет статус "только для чтения" и воздействовать на нее через скрипт нельзя, остается единственный законный способ защиты оборудования - увеличить эффективность щитов, используя наличный потенциал энергетики корабля.

Уже сделано, с ходу заметит опытный геймер. Два варианта на выбор: Shield Equalizer and Capacitors и Shield Cycler / Shield Cycler Next. Оба пакета используют схожую идею: перекачивать энергию из ненагруженного щита в нагруженный.
Полумэр, как выражается коммандер vasig. Перекачка энергии между щитами проблему не решает, а лишь на скорую руку маскирует. Суть парадокса ведь никуда не делась: что Аддер, что Кобра Марк Три имеют тот же стандартный уровень заряда щитов 128 + 128. "А если нет никакой разницы, зачем платить больше? ©"

Так что, отказаться от парадигмы "стандартный щит 128 единиц"? Технически это несложно и нечто подобное сделал Redspear в своем пакете Equipment by Ship Class. В крайнем обновлении пакета у него пять классов корпуса, заряд щитов от 96 + 96 у Аддера до 192 + 192 у Анаконды, при этом заряд щитов Кобры Марк Три имеет привычное для геймера значение 128 + 128, чтобы не шокировать казуального геймера радикальными переменами и в то же время ненавязчиво мотивировать на приобретение дредноута вроде Боа Круизера. Идея в целом неглупа, вот только как же боты? В Custom Shields, вот незадача, для ботов принят стандартный уровень щитов 128 + 128, к которым прибавляются бонусные 128 единиц, если бот имеет виртуальный Shield Booster, и еще плюс 128 единиц бонуса на Shield Enhancer. Так что KISS решение тоже не получается: надо аккуратно препарировать код Custom Shields и зашивать туда проверку на класс корпуса бота. В принципе заниматься такой допилкой чужого кода мне не впервой, но я берусь за такую работу лишь когда пакет меня в целом устраивает и я хочу просто перенастроить его по своему. Custom Shields меня за неимением лучших альтернатив устраивает полностью и я не хочу лезть в него без крайней нужды.
А зачем так сложно? Может быть, просто докидывать ботам при засеве бонус к максимальной энергии - Аддеру поменьше, Анаконде побольше, как бы симулируя разную емкость щитов?
Просто не получится. Максимальная энергия бота - параметр read-only, через скрипт ее менять нельзя, вот и приходится терпеливо пилить лобзиком скрипты вроде Custom Shields и привязывать их к ботам.
Есть еще идеи?
Только сразу помидорами не кидайтесь, ладно?
В общем так, парни. У нас Кобра Марк Три имеет щиты 128 + 128 единиц и энергобанк емкостью 256 единиц, верно? А теперь смотрите. Мы урезаем сердцевину, скажем, до 128 единиц и эту энергию распределяем между щитами. Получаем щиты по 192 единицы. Ту же операцию проводим и с остальными игровыми кораблями. Это как раз через скрипт сделать легко. И получится примерно так:

Аддер 106 + 128 + 106
Кобра Марк Один 139 + 128 + 139
Кобра Марк Три 192 + 128 + 192
Питон 289 + 128 + 289
Боа Круизер 326 + 128 + 326

Конечно, справочники придется переписывать, но революции в Оониверсуме Stranger's World - вполне обычное дело.

Хм, а этот юноша из инженерного отдела неглуп. Что-то в его идее определенно есть.
Тепло, еще теплее, горячо...
Бинго!
Отставить панику. Справочники переписывать не придется. Все аккуратно вписывается в рамки канона.

А теперь KISS решение от Стрэнджера.
Самый правильный способ решения проблемы повреждения оборудования - восполнять энергетический урон щитов за счет емкости энергостека. Вот при такой постановке вопроса мотивация летать именно на Кобре Марк Три с ее четырьмя ячейками энергостека оправдана. Больше энергии и выше темп ее восполнения - дольше щиты держат нагрузку до прожига.

Energy Rebalance 0.2

Как работает этот простой пакет.
Полностью заряженные щиты без апгрейда имеют канонический уровень энергии 128 единиц. Как только энергия щита под нагрузкой падает до 1/4 номинала, дальнейшая потеря энергии щита восполняется из энергостека, пока уровень энергостека не падает до 64 единиц. Если пилот и после этого продолжает тупить, подпитка щита прекращается и щит прожигается.
Я думаю, это честный пакет. Геймер не получает несправедливых преимуществ перед ботами - у него в распоряжении тот же общий запас энергии, как у бота-аналога с щитами Custom Shields. Геймер просто получает более эффективный механизм распределения этой энергии. Для уничтожения бота вам нужно наносить ему больший урон, чем он успевает восполнить. Теперь и боту придется делать то же самое, чтобы нанести вам повреждения и вынудить выйти из боя.
Energy Rebalance не защищает корабль геймера от поражения ракетой. Темп переноса энергии ограничен максимальной величиной 16 единиц. Эта встроенная защита предотвращает опустошение уровня энергостека до критически низкого уровня при запредельно высокой нагрузке на щит. 16 единиц более чем достаточно для компенсации энергетического урона от импульса военного лазера (12 единиц в импульсе).
Я сознательно не стал делать Energy Rebalance как апгрейд оборудования за отдельную плату. Energy Rebalance - это перенастройка игровой механики, доступная геймеру изначально. Именно так должна работать грамотно спроектированная система активной защиты корабля.
Есть, однако, один момент. Скорее всего, он вам не понравится, но тут уж я не намерен ничего менять.
Energy Rebalance работает только при условии, что у вас установлены пакеты Breakable Shield Generators и Breakable Energy Unit. Скрипт проверяет состояние генераторов щитов и при выходе генератора из строя отключает подачу энергии на связанный с генератором щит. Проверка состояния генератора энергии технически необязательна, так как при его выходе из строя расход энергии из энергостека не восполняется и после разрядки энергостека до 64 единиц подпитка щитов прекращается. Но как-то нелогично требовать обязательного наличия генераторов щитов и смотреть сквозь пальцы на отсутствие генератора энергии.
Подпитка щитов также прекращается при падении запаса топлива до нуля, даже если у вас не установлен пакет Hard Way (технически он необязателен). Считайте перечисленные выше требования сознательной технической политикой Stranger's World: мои пакеты ориентированы на геймера, который готов принять идею, что энергия - ценный ресурс, который не может добываться в неограниченных количествах из неисчерпаемого и неуязвимого черного ящика.
Логика работы Energy Rebalance конфликтует с логикой работы оборудования Shield Equalizer and Capacitors и Shield Cycler / Shield Cycler Next. Пакет Energy Rebalance также несовместим с Ship Configuration, так как этот пакет несовместим с Breakable Shield Generators и Breakable Energy Unit.

SW Equipment 3.3

В свое время я уменьшил уровень кормового щита для корпуса легкого и среднего класса до 0.5 и 0.75 от уровня носового. С появлением решения Energy Rebalance в таком гандикапе больше нет нужды и я вернул уровни щитов на номинальное значение.
Пакет SW Equipment 3.3 включен в суперпакет Stranger's Set 3.3.

Skilled NPCs ST 1.5.1

Синхронизация моей перепиленной версии пакета Skilled NPCs (автор оригинального пакета cim) с крайним обновлением исходного пакета. В версии 1.5 бонусы к accuracy для пиратов и охотников начисляются по отдельности (на самом деле при дефолтных настройках они по прежнему получают одинаковые бонусы, но геймер теперь может раздельно настраивать базовый уровень бонусов для пиратов и охотников).

Hard Eject 0.3

Правила обработки оборудования в обновлении пакета остались прежними, изменился механизм обработки. Предыдущая версия пакета была, по сути дела, альфа-версией с ограниченным функционалом: она умела распознавать и обрабатывать только оборудование из заранее сформированного списка. Переписанный скрипт в обновленной версии теперь умеет распознавать и обрабатывать любое установленное нестандартное оборудование.
Правила, напоминаю, таковы:
После катапультирования вы получаете взамен идентичный корабль, но в стартовой конфигурации.
Все лазеры изымаются и замещаются на импульсный лазер в носовом порту.
Все вооружение и оборудование на ракетных пилонах (ракеты, бомбы, подвесные баки, подвесной межгалактический гипердрайв и так далее) изымаются без компенсации.
Все флотские апгрейды, полученные как бонус при выполнении миссий, изымаются без компенсации.
Все приобретенное дополнительное оборудование с ненулевой вероятностью повреждения переводится в состоянии “повреждено”. То есть вы как бы приобретаете утраченное с прежним кораблем оборудование с 50% страховой скидкой в любой системе подходящего технологического уровня.
Любое неповреждаемое оборудование остается в активном состоянии. То есть пассажирские каюты и расширение грузового отсека в новом корабле останутся рабочими. Останутся рабочими также всякие подписки, лицензии и сертификаты, которые технически обрабатываются как неповреждаемое оборудование.
Одноразовый межгалактический гипердрайв остается. Это сделано для того, чтобы не поставить геймера в безвыходное положение в изолированных системах, где попросту негде купить межгалактический гипердрайв.
Особый случай – MFD. Часть мод MFD переводится в поврежденное состояние, часть остается в рабочем. Это зависит от того, объявлена ли возможность повреждения MFD в соответствующем пакете. Теоретически можно было привести все моды MFD к одному состоянию – изъять их все или оставить все в состоянии на момент катапультирования – но раз уж автор пакета предусмотрел возможность боевого повреждения MFD, очевидно, по авторской логике их нормальная работа требует какого-то периферийного оборудования.
Breakable Equipment обрабатывается как исключение – скрипт его обходит и оставляет в состоянии на момент катапультирования. Поэтому не удивляйтесь, что на корабле, который вам выдадут взамен утраченного, может не работать генератор носового щита или HUD/IFF. Это не баг, это фича

SW Equipment 3.4

Разрабатывая свою систему привязки приобретения оружия к криминальному статусу геймера, я как-то упустил из виду, что эти правила вступают в конфликт с алгоритмом замещения корабля в Hard Eject.
Вы катапультируетесь, имея лучевой лазер в носовом порту. Если у вас чистый правовой статус, скрипт работает в точности как задумано – заменяет этот лучевой лазер на импульсный. Но если ваш статус подпорчен, вы не имеете права на приобретение импульсного лазера, находясь на главной станции, и скрипт оставляет лучевой лазер в носовом порту как есть, без замены!
Исправлено. Импульсный лазер теперь приобретается без проверки правового статуса.
Пакет SW Equipment 3.4 входит в состав суперпакета Stranger’s Set 3.4.