Author Topic: Изменения и проблемы последних версий  (Read 2778 times)

0 Members and 1 Guest are viewing this topic.

Offline serger (OP)

  • Commodore
  • **********
  • Posts: 634
  • Thanked: 120 times
  • Silver Supporter Silver Supporter : Support the forums with a Silver subscription
    2021 Supporter 2021 Supporter : Donate for 2021
    2022 Supporter 2022 Supporter : Donate for 2022
В эту ветку я планирую выкладывать актуальную информацию: во-первых - сложные или недокументированные аспекты новых фич, и во-вторых - сложности, баги и ещё не работающие механики (затычки), по которым зачастую бывает сложно откопать объяснения в общих (англоязычных) ветках.

Под новыми фичами я здесь понимаю то, что появилось уже в C# Aurora, но не обязательно в последнем релизе.

Надеюсь у меня хватит времени писать более-менее систематически, но, поскольку делать это я могу только урывками, обычно одновременно жуя или ещё в каком-нибудь недолгом перерыве между беготней и пахотой, то темп может быть так себе. Если кто-то хочет присоединиться - это, конечно, приветствуется.
 
The following users thanked this post: Warer

Offline serger (OP)

  • Commodore
  • **********
  • Posts: 634
  • Thanked: 120 times
  • Silver Supporter Silver Supporter : Support the forums with a Silver subscription
    2021 Supporter 2021 Supporter : Donate for 2021
    2022 Supporter 2022 Supporter : Donate for 2022
Детализация наземных войск
« Reply #1 on: February 01, 2021, 11:37:40 AM »
Начнем с одного из самых масштабных и интересных нововведений C# Aurora - детализации наземных войск, начиная с конструктора элементов и заканчивая введением командной иерархии произвольной глубины (и то и другое аналогично тому, как сделано и для флота).

Итак, теперь у нас есть конструктор базовых единиц - аналогично тому, как для флота с самого начала был конструкор кораблей. Единицы (units) можно упаковывать в произвольном количестве в такие себе пачки - такая пачка одинаковых единиц называется элемент (element), и уже этими элементами мы можем наполнять формирования (formations), а формирования можно подчинять штабным формированиям высшего уровня, выстраивая таким образом иерархию любого уровня сложности - хоть от огневых групп и отделений до фронтов и родов войск.

Какие здесь есть тонкости.

Во-первых, в отличие от того что было в VB, войска больше не апгрейдятся мгновенно и бесплатно на последний уровень соответствующией линейки технологий. С одной стороны - круто, это добавляет игре глубины и сближает механику наземных войск с механикой флотской. Теперь у наземных войск тоже есть реалистичный процесс устаревания, так что нужно продумывать, разрабатывать, планировать и обеспечивать их модернизацию - всё как мы любим (ну, не все, конечно, но согласитесь - Аврора прежде всего для маньяков штатных расписаний, а для любителей простоты есть масса более простых игрушек). С другой стороны - делать всё это вручную уж очень нудная работа. Начиная с версии 1.12 эта нудность значительно уменьшилась с введением двух новых аспектов механики: образцов пополнения (Replacement Templates) и серий (Unit Series).

В первых версиях C# Aurora формирования по темплейтам только создавались, а пополнять побитые или модернизировать их можно было только вручную. Теперь можно автоматически пополнять побитые в боях или раздерганные ручными переводами формирования до их штатной численности. Т.е. Formation Templates превратились в полноценные организационно-штатные расписания, это круто! В качестве источника пополнений используются формирования, находящиеся "на месте", т.е. в том же населении (population), и отмеченные галочкой 'Использовать для пополнений' ('Use for Replacements', вверху справа на первой вкладке окна Ground Forces). Происходят пополнения на каждом производственном этапе (construction phase), после этапа боёв. Для каждого формирования можно поменять приоритет (поле Priority рядом с галочкой использования для пополнений) - это значение используется при создании очередей на пополнение.
Кроме того, любому формированию - по отдельности или сразу всем таким же - можно заменить образец на другой (просто выбрать из списка существующих образцов по кнопке Change Temp на первой вкладке окна Ground Forces).

Серии (Unit Series) - это совершенно новая механика, приблизительно аналогичная сериям ракет, которые были ещё в VB-версиях Авроры. Для серий наземных единиц в окне Ground Forces добавлена новая вкладка. Список существующих серий выведен в левой части этой вкладки - по умолчанию он пуст, новые серии создаются по кнопке "Create Series" внизу справа окна. Новосозданные серии наполняются единицами, просто перетаскивая их мышкой: из списка в центре окна - влево, в нужную серию (ещё не растасканные по сериям единицы в списке сгруппированы по типам - разверните их щелчками по плюсикам если они свернуты). Перетаскиванием же мышкой можно менять приоритет единиц в серии - те, что выше по списку, будут первыми изыматься из маршевых пополнений и переправляться в первоочередные пополняемые формирования, так что это одновременно и механизм модернизации войск, компромисный между простотой и реалистичностью.

Комбинацию этих механик можно использовать и для массовой модернизации войск (дополняя их какими-то средствами усиления или заменяя устаревшие единицы более новыми), и для переформирования (взять стрелковые дивизии и переформировать их в дивизии РВСН; и не смейтесь: кто в армии служил, тот в цирке не смеется, а дивизии РВСН СССР вообще-то так и создавались), и для прекращения пополнений какого-нибудь формирования (сделать пустой образец и перевести это формирование на него).

К вопросу модернизации войск, подходя с другой стороны. Основные технологические линейки, нужные для модернизации войск:
1. Бронепробитие (Racial Weapon Strength)
Определяется самым продвинутым уровнем из "калибров" основного оружия прямого наведения. Т.е. считаются: Laser Focal Size, Railgun Type, Meson Focal Size, Particle Beam Strength, Carronade Calibre. Почему-то гауссовки не считаются, и почему-то считаются именно технологии максимальных калибров, а не вторые (влияющие на свойства всех калибров) технологические линейки. Это странно, но такова уж воля создателя.
2. Броня
Racial Armour Strength - основной технологической линейкой брони  (из раздела Defensive Systems) + Powered Armour и Heavy Powered Armour, которые исследуется независимо и далее не растут (от технологий щитов не зависят).


Переходим к иерархии. Главная тонкость, постоянно вызывающая вопросы - это штабы.

И тут сразу не очень хорошая новость: механика штабов в нынешней версии (1.12) недоделана - они работают для своего собственного формирования, но не для нижестоящих, причём вопреки написанной Стивом "спецификации". Эта недоделка усугубляется ещё и тем, что навык логистика, например (Ground Combat Logistics), действует в механике боя на уменьшение расхода боеприпасов, а не на экономность пополнения ими, т.е. нет никакого смысла ставить крутого логистика в логистическое формирование - он там вообще никак свой навык не будет использовать, даже если это формирование будет одновременно вышестоящим штабом для интенсивно стреляющих полевых частей.

Дальше о хорошем.

В первую очередь - главное правило: штабная единица (Unit с тэгом Headquarters, если вы хотите использовать его имено как штаб, а не исключительно для ролеплея) должна иметь емкость (Capacity) не меньше, чем объем войск (в тоннах), которыми этот штаб должен управлять. Ещё раз подчеркну: емкость штабной единицы. Т.е. нет смысла напихивать в тысячетонное формирование по десятку мелких штабов емкостью по 100 тонн, аналогично тому как напихиватся двигатели или трюмы в кораблях. Емкости штабных единиц не складываются. В образцах, которые постил Стив, как правило стоит по две штабных единицы, но это сделано в целях резервирования, на случай уничтожения одного из штабов, а не для увеличения максимальной (охватываемой при том работой штабов) численности формирования. (Я в своих формированиях часто тоже добавляю резервный штаб, но он у меня вдвое, а то и втрое меньшей емкости, чем основной, поскольку штабы уничтожаются в бою редко, и если уж это происходит, то как правило формирование уже к этому времени сильно избито и для его управления такой большой штаб избыточен.)
Ещё один тонкий момент сюда же. Стив и некоторые игроки уверены, что добавочные штабные единицы уменьшают вероятность гибели командира. Я - дипломированный специалист по теории вероятностей и математической статистике, а также в прошлом и программст - считаю что это ошибочные утверждения (исходя как из запощенных Стивом описаний механики, так и из нескольких тестовых сражений, запущенных специально для проверки). Просто по математике - количество штабных единиц никак не должно влиять на вероятность гибели командира, который в это формирование назначен, поскольку эти резервные штабы увеличивают штабное пространство (тоннаж, по которому случайным образом распределяются попадания), в котором командира в итоге не будет, но никак при этом не уменьшают штабное пространство, в котором командир таки будет, т.е. вероятность попадания в него никак не меняется. Или, другими словами - резервные штабы увеличивают вероятность того, что уничтожен будет резервный штаб, а не основной, но делают это ценой в точности такого же увеличения вероятности того, что какой-то из этих штабов таки получит попадание, и эти эффекты друг друга в точности уравновешивают. Тестовые сражения показали именно этот эффект - при добавлении резервных штабов тепмы выбивания командиров не уменьшались (хотя, конечно, это могло быть из-за долгого массового невезения, а декомпилировать код Авроры и убедиться, что он соотвествует описанию, я не могу, так что железных гарантий, конечно, не даю). Так что я резервные штабы добавляю просто чтобы командиру (выжившему при гибели штаба, где он находился, или срочно переведенному автоназначением на замену выбитому) сразу было где разместиться и продолжать работать без моего вмешательства - это уменьшает количество микроменеджмента в масштабных тяжелых сражениях.

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

Важный момент, который упускают при разработке новых войсковых единиц: не забывайте правильно выставлять галочку 'Avoid Combat' (и проверять соотвествующий ей тэг 'Non-Combat Class') - эта галочка вчетверо уменьшает как совершаемый этой единицей настрел (если ей вообще есть чем и в кого стрелять), так и её "эффективную площадь", которой определяется вероятность попаданий по ней. Т.е. эту галочку нужно выставлять для штабов, наводчиков (FFD), инженеров (Construction), ксеноархеологов и изыскателей (geosurvey), которые вообще не стреляют никогда, а также для единиц орбитальной обороны (STO) - последние стреляют, но не в рамках наземного боя, который имеется в виду под словом 'Combat' в данном случае. А вот для артиллерии и ПВО эту галочку выставлять вредно - они стреляют именно в рамках наземного боя, так что делать их Non-Combat - это будет вчетверо худшее использование потраченных на их производство времени, денег и TNE, а также и тоннажа на их перевозку, если вы будете использовать их во вторжениях.

Другой тонкий момент, также важный для разработки войсковых единиц и их испольования - в механике случайного распределения целей. C# Aurora в этом подобна старой доброй Galaxy+, с её сочетанием "пылесосов" и "непробивах" - в Авроре роль "пылесосов" играют пехота, лёгкие противопехотные машины и артиллерия (в разной степени эффективные против разных противников), а роль "непробивах" - тяжелые бронированные машины, бункеры и космические аппараты огневой поддержки с автопушками (эффективность последних в текущей версии сомнительна). "Пылесосы" крайне важны как правило в начале сражения, когда почти вся эффективная площадь войск противника - это мелкие, слабо бронированные единицы, которые нужно как можно быстрее подрасчистить, чтобы тяжелое вооружение начало попадать по крупным, сильно бронированным целям. Распределение целей происходит равномерно-пропорционально эффективной площади целей. Эта эффективная площадь может быть уменьшена небоевым статусом, но никакие единицы не привлекают на себя какой-то специфический огонь ни тем, что сами открыли огонь, ни своим уровнем бронирования или вооруженности, поэтому в этой начальной фазе тяжелое вооружение как правило чудовищным образом тратит боеприпасы (supplies) практически впустую, на уничтожегние мелких целей, которые почти столь же хорошо могли бы быть уничтожены более легким вооружением с несравнимо меньшим расходом припасов. На следующих этапах, когда мелочь уже расчищена - стоит выводить тяжелое вооружение на передовую (Front Line Attack, в обороне допустимо и Front Line Defence), чтобы уничтожить "непробивахи" противника, от которых мелочь больше не особо отвлекает огонь.
Слабая сторона этой механики не столько в ней самой, сколько в том, что компьютер (AI) не умеет ей пользоваться - управляемые им противники не держат тяжелое вооружение в резерве, когда против них выставляют массу легких целей. Кроме того, эта механика делает малоэффективными классические смешанные дизайны типа "штурмовой танк с огромной бронебойной пушкой и двумя пулеметами", поскольку вместо пары таких танков выгодней взять один танк только с пулеметами и второй - только с пушками, и бросить в атаку первый из них в начале сражения, а второй - в конце. Поскольку Стив - большой любитель сеттингов типа Вархаммер, то можно с некоторыми основаниями для оптимизма надеяться, что он эту механику как-то поправит, чтобы титаны стали осмысленным решением не только с чисто ролеплейной точки зрения.

Альтернативный кондовый метод решения проблемы расхода боеприпасов - это, конечно, просто высаживать мегатонны грузовиков с боеприпасами (Light Vehicle - Logistics Module) и распределять их по вышестоящим штабам самых прожорливых войск. Обратите внимание, что это должны быть именно грузовики, потому что пехотные запасы (Infantry - Logistics Module) вниз по командной иерархии атоматически не уходят, распределять их вручную в крупном сражении - это свихнуться можно, а заранее наполнять ими фронтовые части из расчета на всё долгое сражение с ипользованием тяжелого вооружения - это фатально ослабить огневую мощь этих фронтовых частей в первой же, решающей для достижения перевеса, фазе сражения.

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

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

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

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

Полицейские силы для усмирения бунтов - тут всё ещё проще: мощное оружие и броня им не нужны, нужно просто как можно больше единиц, так что с этой целью и по игровой механике, и в ролеплейных целях равным образом нужна простая пехота с легким вооружением (PWL). Из ролеплейных соображений я лично обычно добавляю в них единичных снайперов (PWI), гранатометчиков (LAV), стингеры (LAA) и пулеметные боксы (Static CSAP) устаревших типов. Ну, с какой-то вероятностью им может быть придётся участвовать в отражении внезапного вторжения.
 

Offline serger (OP)

  • Commodore
  • **********
  • Posts: 634
  • Thanked: 120 times
  • Silver Supporter Silver Supporter : Support the forums with a Silver subscription
    2021 Supporter 2021 Supporter : Donate for 2021
    2022 Supporter 2022 Supporter : Donate for 2022
Корабельные компоненты
« Reply #2 on: February 03, 2021, 10:31:30 AM »
1. Системы заправки топливом и погрузки боеприпасов

В VB Aurora время и оборудование для заправки топливом и погрузки боеприпасов не учитывались. В C# и то и другое учитывается - на обслуживающие корабли, станции обслуживания и удаленные колонии нужно ставить заправочные и погрузочные модули разных типов, в технологиях появились новые ветки.
В сочетании с соответствующими регламентами (Standing Orders) и управляемым параметром минимального уровня топлива (Minimum Fuel) для каждого типа кораблей это одновременно и углубило игру, и убрало часть проблем с микроменеджментом.

2. Прыжковые двигатели

В VB Aurora были постоянные проблемы со стандартными прыжками смешанных (с коммерческими и военными двигателями) флотов - их приходилось расцеплять и проводить по-отдельности. В C# эти типы работают по-отдельности.
Кроме того, теперь имеет смысл ставить на трапмы прыжковые двигатели более крупные, чем тоннаж самого трапма - он будет успешно обеспечивать проход больших кораблей.

3. Командные модули

К существовавшим ранее обычным и флагманским мостикам добавились:
Пост дистанционного управления (Auxiliary Сontrol), где можно разместить старпома (Executive Officer), что заметно влияет на темпы подготовки экипажа.
Главный инженерный поcт (Main Engineering) - размещается соответственно стармех, влияет на обслуживание и устранение повреждений.
Боевой информационный пост (Combat Information Centre) - размещается офицер по тактике, влияет на точность огня и, кажется, на задержки тоже.
Главный пост управления полетами (Primary Flight Control) - размещается командир группы, влияет на скорость ангарных операций
Научный отдел (Science Department) - размещается офицер по науке, вляет на скорость изыскательских работ.

4. Двигатели и реакторы

В C# линейки корабельных и ракетных двигателей объединены, причём зависимости топливной эффективности и HTK от размеера стали квадратичными. Соответственно, резко увеличилась осмысленность крупных двигателей, особенно для крейсеров, а дальность ракет теперь нужно аккуратно подбирать. То же касается реакторов и генераторов щитов - более крупные стали значительно эффективней. Кроме того, технологические линейки развития двигателей и реакторов стали более дробно-растянутыми на раннем этапе.

5. Плазменные каронады

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

6. Корпускулярное копье (Particle Lance)

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

7. Пусковые установки

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

8. Ракеты

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

9. Башенные установки

Многоствольные стали эффективней. Однако в сочетании с механикой сосредоточения огня по ракетным залпам - на настоящий момент (v1.12) осмысленность многостволок всё равно под вопросом - они дают слишком много оверкиллов.

10. Коммерческие ангары и погреба боезапаса

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

11. Койко-места экипажей крыльев

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

12. Причальные отсеки грузовых шаттлов

В C# Aurora считается, что корабли (т.е. космические аппараты эфироизмещением выше 500 тонн) принципиально не способны спускаться в гравитационные колодцы, поэтому для грузообмена между ними и колониями, а также и между объектами на орбите, должны использоваться грузовые шаттлы (Cargo Shuttles). Различные по типу отсеки для таких шаттлов заменили собой бывшие в VB Aurora погрузочные системы (cargo handling systems).

13. Отсеки-склады запчастей (Maintenance Storage Bays)

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

14. Орбитальные жилые комплексы

Заметно подешевели, что особенно заметно в сочетании с введением безбронного типа станций.

15. Ракетные погреба

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

16. Модули электронной разведки и дипломатические модули

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

17. Подвески и подвесочные узлы

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

18. Орбитальные добывающие комплексы

Замена бывшим в VB Aurora астероидным добывающим комплексам. Могут использоваться для любых тел доступного диаметра - и добавлена соответственная технологическая линейка, постепенно увеличивающая диаметр тел, доступных для эксплуатации этими модулями.

19. Мезонные пушки

Теперь не полностью игнорируют броню, а имеют отдельную технологическую линейку по бронепроницаемости. Щиты игнорируют, как и раньше. По стоимости уравнены с лазерами.

20. Топливные баки

Исправлена странность с их очень высокой в VB Aurora стоимостью и, кроме того, удельная стоимость баков теперь ещё и падает с их размерами, так что танкеры стали правдоподобно-недорогим классом.

21. Гауссовки

Стоимость разработки заметно уменьшилась, что повышает интерес к гауссовкам как возможному основному противоракетному оружию.
« Last Edit: February 05, 2021, 07:28:55 AM by serger »
 

Offline serger (OP)

  • Commodore
  • **********
  • Posts: 634
  • Thanked: 120 times
  • Silver Supporter Silver Supporter : Support the forums with a Silver subscription
    2021 Supporter 2021 Supporter : Donate for 2021
    2022 Supporter 2022 Supporter : Donate for 2022
Изменения механики колонизации
« Reply #3 on: February 05, 2021, 07:25:17 AM »
1. Низкогравитационная инфраструктура (Low Gravity Infrastructure)

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

2. Емкость колонии (Population Capacity)

Новое свойство небесного тела, задающее по сути плотность населения на его поверхности, т.е. сколько народу там должно жить, чтобы рост населения уполовинлся или вообще остановился. Зависит от:
# Площади поверхности - чем больше, тем лучше.
# Доли поверхности, занятой водой. До 75% - не влияет (считается, что хотя площади для жилья из-за воды становится меньше, но она лучше увлажняется и мягче по климату), от 75% до 99% - сокращается, и выше 99% остается на уровне 1% от максимальной (относительно небольшое население может жить на плавучих островах и без "твердой" инфраструктуры).
# Наличия приливного захвата - он уменьшает емкость впятеро, но зато впятеро же снижает штраф за температурную неоптимальность.

Для примера, предельная емкость (после которой население перестает расти и начинает генерировать недовольство перенаселенностью) для Земли - 12 млрд, Марса - под 3 с половиной, Луны - меньше миллиарда, а 50-км астероида - меньше 20 млн.

3. Колонизационные свойства видов

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

4. Стоимость колонии (инфраструктурная)

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

5. Терраформирование

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

Тела с гравитацией меньше 0,1G терраформированию не поддаются, т.к. не могут удержать атмосферу.

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

Механика парникового эффекта заметно улучшена.
Бывшие "безопасный парниковый газ" и "безопасный анти-парниковый газ" переименованы в Aestusium и Frigusium.

Двуокись углерода (Carbon Dioxide) включена в список опасных газов.

6. Генные модификации

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

7. Регулирование гражданских колонистских перевозок

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

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

В-третьих - направления колонизации (источник, стабильная, цель) можно теперь вручную выставлять при населении с 10 млн, а не 25 млн.