| Главная » Статьи » Мои статьи |
Ares Expansion DLL (Нововведения 02)
| Угонщики Воры техники могут пощихать вражескую технику, фактически угоняя их прямо на поле боя. Если вы разрешите угон через флаг VehicleThief=yes на InfantryType, вы можете настроить механику следующими способами: [InfantryType]►VehicleThief.EnterSound= (имя звука) Указывает звук при угоне машины угонщиком. Это работает и для пехоты с CanDrive=yes при входе в нейтрализованную машину. По умолчанию none. [InfantryType]►VehicleThief.LeaveSound= (имя звука) Звук при покидании угонщиком техники при её уничтожении. По умолчанию none. [InfantryType]►VehicleThief.BreakMindControl= (boolean) Может или нет этот вор техники угонять войска под контролем разума. Связь между контроллером и жертвой будет разорвана при входе угонщика в юнит. В ином случае угонщик не может украсть юнит. По умолчанию yes. [InfantryType]►VehicleThief.OneTime= (boolean) Будет или нет угонщик потерян при захвате юнита. В ином случае вор техники сумеет выжить после уничтожения захваченной техники. Во всех случаях цена угонщика будет возвращена при перемалывании юнита в гриндере. По умолчанию no. [InfantryType]►VehicleThief.KillPilots= (число) Число пилотов, уничтожаемое при проникновении вора техники в угоняемую машину. Эти пилоты лишатся шансов покинуть технику при угоне. Используйте -1 для убийства всех пилотов. В Tiberian Sun угонщик не позволял никому из экипажа выжить при уничтожении техники. По умолчанию 0. В Tiberian Sun ворам техники запрещалось угонять юниты с флагом NonVehicle=yes. Ares не использует NonVehicle, так как он также влияет на многое другое, что может быть излишне. Вместо этого вы можете использовать новый узкоспециализированный флаг VehicleThief.Allowed. [TechnoType]►VehicleThief.Allowed= (boolean) Может или нет этот VehicleType или AircraftType быть угнан ворами техники. По умолчанию yes. Замечание: Воры техники не могут водить нейтрализованную технику по умолчанию, но VehicleThief=yes можно сочетать с CanDrive=yes без всяких проблем. Угонщики теперь проработано взаимодействуют с контролем разума. Если угнан юнит под контролем разума, связь с контроллером будет разрушена, и фиктивная линия между ними не будет отображаться. Аналогично, угонщики под контролем разума захватят машину для их оригинальной стороны, а не контроллера. Контроль разума перейдет на захваченную технику, если она не защищена от контроля разума. В противном случае контроллер потеряет контроль и над угонщиком, и над жертвой. Тоже самое работает и в противоположном случае - когда взятый под контроль угнанный юнит уничтожается, связь передается на угонщика, если у того нет иммунитета к псионике. Воры техники не могут угонять союзные войска или нейтрализованные через боеголовки с Kill Driver. См. Убийство водителей. [#include] Ares позволяет разбить ваш rulesmd.ini на отдельные части, что позволяет лучше организовать различные настройки. Любые INI файлы, записанные в новой [#include] секции, будут загружаться после завершения загрузки основного файла. Записанные файлы также могут содержать свою секцию [#include] и загржать ещё INI файлы. Ограничения по глубине нет, и порядок загрузки идет с приоритетом на глубину (то есть если оригинальный INI включает несколько файлов, и включаемый файл включает ещё файлы, то эти файлы второго уровня будут загружены перед продолжением загрузки файлов первого уровня. Повторяется по необходимости). Например, секция [#include] вашего rulesmd.ini может выглядеть вот так: [#include] 1=rules_sw.ini 2=rules_vehicles.ini 3=rules_buildings.ini 4=rules_aircraft.ini 5=rules_infantry.ini По мере загрузки каждого файла INI, любой найденный уже заданный флаг будет перезаписан новым значением. Например, если сперва задать [E1]Strength=200 в rulesmd.ini, а затем [E1]Strength=300 в rules_infantry.ini, то в игре у GI будет Strength=300. INI файлы берутся относительно директории с Red Alert 2. Значения могут включать внутренние папки (т.е. 5=MyModrules_infantry.ini). Загружаемые MIX-ы тоже проверяются на файлы, если в директории игры не обнаружены незапакованные файлы, но такое работает только при отсутствии уточнений искать во вложенных папках. InfantryElectrocuted Анимация, проигрываемая при смерти пехоты от боеголовки с InfDeath=5, ранее была запрограммирована быть второй анимцией из списка [Animations]. Теперь вы можете задать [AudioVisual]InfantryElectrocuted=. Если InfantryElectrocuted не задано, то игра будет искать анимацию с именем "ELECTRO”, и уже при её отсутствии будет использовать вторую анимацию из списка. Убийство водителей Эта функция пытает воссоздать способности Джармена Келла, позволяя боеголовке убивать водителя техники вместо её повреждения, чтобы затем захватить ставшую нейтральной технику. [Warhead]KillDriver= (boolean): Определяет, будет ли эта боеголовка убивать водителя техники вместо нанесения ей урона. [TechnoType]ProtectedDriver= (boolean): Может или нет водитель этой техники быть убит, т.е. иммунитет к предыдущему флагу. [TechnoType]CanDrive= (boolean): Может или нет этот TechnoType выступать в роли водителя для техники, где водитель был убит. Замечание: Воры техники не могут по умолчанию водить нейтрализованную технику, но VehicleThief=yes можно свободно сочетать с CanDrive=yes. См. Угонщики для дополнительных опций, связанных с CanDrive. Громоотводы Громоотводы притягивают молнии во время грозы, и могут изменять получаемый от них урон. [BuildingType]►LightningRod= (boolean) Определяет, будет ли это здание притягивать молнии. Если это здание - самый близкий объект к созданному случайно грозовому облаку, то облако будет создано прямо над зданием. По умолчанию no. [BuildingType]►LightningRod.Modifier= (дробь - множитель) Здания с LightningRod=yes будут получать урон от молний, умноженный на этот модификатор. Значения выше 1.0 повышают урон, ниже - понижают. По умолчанию 1.0. Замечание: Эта логика скорее всего будет расширена в новых версиях. Длина списков Есть несколько флагом INI, использующих список разделенных запятыми значений. Игра устанавливает максимум длины флагов INI в 128 знаков, что не всегда достаточно, особенно учитывая некоторые из доступных в Ares расширения. Этот предел был ослаблен, так что теперь максимальная длина флагов составляет 2048 знаков. Незапакованные аудиофайлы Игра теперь может загружать звуки из файлов WAV - их более не обязательно архивировать в BAG файл. Звуки должны быть указаны в soundmd.ini прежним способом (без расширения .wav). MakeInfantryOwner Оригинальная логика MakeInfantry всегда передавала контроль над новосозданной пехотой нейтралам, если только анимация не вызывалась InfantryType, убитым боеголовкой с InfDeath=9 (в этом случае убийца получал контроль над новым InfantryType). Ares позволяет вам выбрать какой игрок станет владельцем, один из заранее подготовленных вариантов. [Animation]►MakeInfantryOwner= (вариант invoker|killer|victim|neutral|random) Определяет владельца появившегося после создания анимации InfantryType. Анимация будет окрашена в цвета игрока-владельца, если она содержат зависящие от стороны цвета. По умолчанию invoker. Замечание: Если вы создаете цепь анимаций, используя флаг Next=, то MakeInfantry= будет относится к последней анимации, а MakeInfantryOwner= к первой - той, которая запускает цепочку. Заметьте, что это не свойство warhead; оно располагается в соответствующей части artmd.ini. Тем не менее, MakeInfantryOwner работает лишь для определенных анимаций; а именно, тех, которые были инициированы через InfDeathAnim, DeathAnims и триггеры карты. По умолчанию владельцем MakeInfantryOwner будет invoker, инициатор, что означает разное в каждом случае. Для InfDeathAnim, invoker обозначает убийцу (владелец юнита, который убил цель). Для DeathAnims, invoker означает жертву (владельца убитого юнита). Для триггеров карты все invoker, killer и victim обозначают ту сторону, которая обозначена владельцем триггера. random выберет случайного игрока из всех участвующих в игре, включая нейтралов. Замечание: Как InfDeath=9, все анимации мутаций будут отображены в палитре юнитов, а не в anim.pal. Новая логика Powered В оригинальном Yuri’s Revenge, флаг PowersUnit= был ограничен лишь одним таким UnitType и одним контролирующим зданием на сторону. Ares расширяет логику, позволяя каждой стороне иметь по несколько таких юнитов/зданий. [UnitType]►PoweredBy= (BuildingType) Для функционирования этого юнита требуется указанное здание в рабочем состоянии. По умолчанию none. Замечание: PoweredBy= может использовать несколько зданий, но учтите, что запятая для разделения нескольких зданий здесб будет считаться "или”, а не "и". Требования "и", нескольких зданий, нет. Оператор Любой TechnoType теперь может требовать определенную пехоту в пассажирах для функционирования. [TechnoType]►Operator= (строка, InfantryType или "_ANY_”) Определяет какой InfantryType должен быть среди пассажиров этого TechnoType для его функционирования. Если "_ANY_” (без кавычек), то не важно - подойдет любой InfantryType. Используйте none для удаления требования оператора. По умолчанию none. Для TechnoType потребуется добавить Passengers=1 (или выше) и SizeLimit=1 (или выше). Для BuildingTypes вам также потребуется поставить InfantryAbsorb=yes. Если пассажир не находится внутри, то TechnoType отключится, примерно как роботанк без центра контроля - неспособный двигаться или атаковать. BuildingTypes без оператора не смогут атаковать, если они способны это делать. Никакие другие функции зданий не изменятся (т.е. снабжение энергией, работа фабрики, сворачивание в юнит, супероружие, радар и т.д.). Мираж-танки без оператора сохраняют маскировку. Логика операторов не влияет на ремонтное депо, так как оператор не может войти. Логика операторов не влияет на развернутые осадные вертолеты. Оператор не нужен. Логика оператора делает перерабатывающие заводы непригодными к использованию, так как оператор не может войти, а харвестер - разгрузиться. Логика операторов делает InfantryTypes непригодным к использованию, так как пехота не может содержать пассажиров. Логика операторов не может использовать на развертывающихся в здания видах техники, так как наличие пассажиров блокирует DeploysInto=. Логика операторов делает VehicleTypes с BalloonHover=yes непригодными к использованию, так как они постоянно в воздухе и пехота не может войти внутрь. Логика операторов не работает с AircraftTypes по двум причинам: Самолет создаются там, куда операторам не попасть. Вы можете приказать самолету без оператора двигаться, но он сразу же разобьется. Даже если вы поместите самолет туда, где в него может войти оператор (скажем хроносферой), при атаке самолет выбросит пассажиров на парашютах (включая оператора) - что приводит к его крушению. Замечание: ИИ ведет себя непредсказуемо при столкновении с требующими операторов юнитами, и не всегда успешно. Лучше лишить ИИ доступа к требующим операторов объектам. Иконки в PCX Иконки могут быть загружены в формате PCX вместо SHP. В artmd.ini: [UnitArt]►CameoPCX= (имя файла, *включая* расширение .pcx) Задает имя файла с иконкой, в формате "filename.pcx”. [UnitArt]►AltCameoPCX= (имя файла, *включая* расширение .pcx) Задает имя файла с альтернативной иконкой (опытного юнита), в формате "filename.pcx”. В rulesmd.ini: [SuperWeapon]►SidebarPCX= (имя файла, *включая* расширение .pcx) Задает имя файла с иконкой супероружия, в формате "filename.pcx”. Замечание: Как и другие используемые игрой PCX файлы, эти PCX файлы должны быть в 256 цветах и размерностью 60x48 пикселей. Prerequisites Система prerequisite подверглась множеству улучшений. Ниже приведены новые флаги, а также была решена проблема с апгрейдами зданий в качестве prerequisites (см. Исправление багов 2). [Unit]►Prerequisite.RequiredTheaters= (список имен театров) Театры, на которых этот юнит будет доступен. По умолчанию все театры. Например, если указано лишь SNOW, то юнит можно будет создать лишь на арктических картах. Это позволяет применить, например, функцию AlternateArcticArt от Navy SEAL, но для всех юнитов и для всех театров (однако это может вызвать затруднения для вашего ИИ). Имена театров: TEMPERATE - большинство карт SNOW - арктические/снежные карты URBAN - некоторые городские карты DESERT - некоторые пустынные, постарше используют Temperate LUNAR - советская миссия 6 NEWURBAN - большинство городских карт YR Замечание: PrerequisiteOverride не преодолевает Prerequisite.RequiredTheaters. [Unit]►Prerequisite.Negative= (список BuildingTypes) Здания, препятствующие строительству юнита. Если у игрока есть одно или более здание из списка, то он не сможет создавать этот юнит. По умолчанию none. Замечание: PrerequisiteOverride не преодолевает Prerequisite.Negative. [Unit]►Prerequisite.Lists= (число) Определяет сколько дополнительных списков Prerequisite будет действовать (см. далее). По умолчанию 0. [Unit]►Prerequisite.List#= (список BuildingTypes (где # - число от 1 до Prerequisite.Lists)) Каждый prerequisite.list действует как независимая копия уже существующего флага Prerequisite. Например, если вы установили Prerequisite=GAPILE,GATECH и Prerequisite.List1=NAHAND,NATECH, то юнит будет доступен любому игроку, у которого одновременно есть казармы Союзников и боевая лаборатория Союзников либо казармы Советов и боевая лаборатория Советов (должна быть хотя бы одна пара зданий). Prerequisite.List0, если указан, перепишет существующий флаг Prerequisite. [Unit]►Prerequisite.StolenTechs= (список чисел) Список номеров украденных технологий, которые нужны для создания объекта. См. Украденные технологии для деталей механики. Общие группы Prerequisite Теперь вы можете создавать свои группы prerequisite вроде существующих групп POWER (PrerequisitePower), FACTORY (PrerequisiteFactory), BARRACKS (PrerequisiteBarracks), RADAR (PrerequisiteRadar), TECH (PrerequisiteTech) and PROC (PrerequisiteProc и PrerequisiteProcAlternate). Для создания новой группы просто добавьте новую секцию [GenericPrerequisites] и добавляйте в неё флаги в формате GROUPNAME= (список зданий). Например: [GenericPrerequisites] NAVALYARD=GAYARD,NAYARD,YAYARD и т.п. И используйт её как обычную группу требований. [TechnoType] ... Prerequisites=NAVALYARD ... Если вы зададите уже существующую группу (POWER/FACTORY/BARRACKS/RADAR/TECH/PROC), то BuildingTypes, указанные в секции [GenericPrerequisites] будут использоваться вместо стандартных значений из флагов PrerequisiteGroup (т.е. [GenericPrerequisites]►POWER=, если указано, перепишет [General]►PrerequisitePower=). Заметьте, что [GenericPrerequisites]►PROC= не обнуляет или переписывает [General]►PrerequisiteProcAlternate=. Источник: http://redalert3.3nx.ru/viewtopic.php?p=2702 | |
| Просмотров: 1004 | Теги: | Рейтинг: 0.0/0 |
| Всего комментариев: 0 | |
Меню сайта
Категории раздела
| Мои статьи [14] |
Друзья сайта
Статистика
Онлайн всего: 1
Гостей: 1
Пользователей: 0
