Сообщений в теме: 11116

[bitterhowl]

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

[bitterhowl]

Думаю, продвинутые скриптеры знают эти вещи и так, но начинающим, как я например, будет полезно. Итак, оптимизация скриптов нужна главным образом для быстродействия, чтобы не загружать процессор и операционку. Возможно, помимо быстродействия уменьшится и вероятность вылетов заодно. Полезно знать принцип работы программного кода (я не программист, не претендую, пишу только то, что прочел в теме про оптимизацию). Игра разбирает каждый монитор поэтапно, проверяет каждое условие, и если оно верное, то переходит к следующему. На это и тратится время работы процессора, поэтому нужно уметь оптимально подбирать условия скрипта. Пример как это работает.monitor_event FactionTurnStart FactionType englandand FactionBuildingExists >= governor_houseand FactionIsLocalИгра поэтапно проверяет условия, т.е. начало хода фракции, проверяет тип фракции в момент начала хода каждой фракции и если это Англия, то идет дальше. При этом проверка условия наличия у фракции здания "дом губернатора" занимает больше времени, чем проверка условия FactionIsLocal, и при вышеописанном расположении мониторов получается, что если вы играете не за Англию, то игра долго проверяет наличие здания у англичан, а потом обнаруживает что эта фракция ИИ и сбрасывает монитор. В таком случае выходит что процессор выполнил бесполезную работу, затратив время вхолостую. То есть в этом примере как минимум FactionIsLocal должно проверяться до FactionBuildingExists, чтобы не тратить время работы процессора зря. Под этим и понимается рациональное расположение условий.Вот еще более наглядный пример, с цифрами. Допустим, на карте кампании действует 300 персонажей, из них 15 английских. Например, нужно проверить, если на момент начала хода английского персонажа с определенным уникальным трейтом Англия владеет Парижем - происходит событие. Если Парижем владеет другая фракция, то другое событие. Такой скрипт при этом

Спойлер

monitor_event CharacterTurnStart FactionType englandand Trait xx_trait > 0and I_SettlementOwner Paris england... нужный эффект от англииend_monitormonitor_event CharacterTurnStart FactionType englandand Trait xx_trait > 0and I_SettlementOwner Paris france... нужный эффект от францииend_monitormonitor_event CharacterTurnStart FactionType englandand Trait xx_trait > 0and I_SettlementOwner Paris hre... нужный эффект от св римской империиend_monitor

Таким образом, при проверке этих условий монитор сработает 900 раз (3 монитора на 300 персонажей по условию CharacterTurnStart), из них для Англии сработает 45 мониторов (15 персонажей и 3 монитора), дальше проверка трейта будет проходить 45 раз, из которых эффективными будут 3 (1 персонаж с уникальным трейтом и 3 монитора), и 3 раза проверится принадлежность Парижа. А вот если запись скрипта будет такой

Спойлер

monitor_event CharacterTurnStart FactionType englandand Trait xx_trait > 0if I_SettlementOwner Paris england... нужный эффект от англииend_ifif I_SettlementOwner Paris france... нужный эффект от францииend_ifif I_SettlementOwner Paris hre... нужный эффект от св римской империиend_ifend_monitor

При этом монитор запустится 300 раз (300 персонажей на карте для условия CharacretTurnStart), 15 раз для Англии проверится Trait xx_trait >0 (15 английских персонажей на карте) и 3 раза проверится принадлежность Парижа. Итого на 600 запусков монитора CharacterTurnStart меньше и на 30 проверок трейта для Англии меньше. Процессор занят меньше на 2/3 при том, что на карте произойдет то же самое. Если учесть, что в скрипте бывает несколько тысяч с лишним мониторов и больше 300 персонажей на карте, цифры "холостой" работы процессора при нерациональной прописи скрипта возрастают на порядки.По длительности загрузки процессора команды распределяются так - if < monitor_event < monitor_conditions < while. То есть проверка условия с if занимает наименьшее время, дальше идет периодическая проверка ивента, проверка условия происходит постоянно в фоновом режиме и постоянно занимает процессор, так же как и проверка условия while. По некоторым сведениям, 70 monitor_conditions снижают скорость игры до 1 fps. В любом случае, чем больше у вас в скрипте monitor_conditions и while, тем больше грузится процессор и тем дольше обсчитывается скрипт. В той теме на твц есть упоминание мода DotS, который использует методику "nesting ifs" (насколько я понимаю, это разветвленное дерево с использованием условия if), где campain_script имеет объем 60 мегабайт, миллион строк кода и при этом 1 monitor_event и 1 monitor_conditions и притормажиает только при ходе ребелов, т.к. исполняет многочисленные консольные команды.

Сообщение отредактировал bitterhowl: 11 апреля 2015 - 05:32

[bitterhowl]

Не встречал раньше такого вроде - для EDU, если в конце, перед recruitment_priority_offcet вставить такие строки (например для юнита English Huscarls)info_pic_dir huskarlcard_pic_dir huskarlТогда игра будет использовать папку /ui/unit_info/huskarl/english_huskarls_info.tga для инфокартинки, и /ui/unit/huskarl/#English_Huskarls.tga. для иконки юнита - только одну папку и одну картинку для всех фракций, которым он прописан. То есть если один и тот же юнит прописан у вас многим фракциям и его иконка и инфокартинка для всех одинаковые - вы экономите время и место, не надо раскидывать .tga файлы по папкам всех фракций в ui/unit, а достаточно создать одну, с любым названием, которое вы указываете в поле info_pic_dir и card_pic_dir. Если юнит прописан многим фракциям, и картинки отличаются, тогда этот метод не подойдет и нужно делать как обычно.

Сообщение отредактировал bitterhowl: 12 апреля 2015 - 17:26

[bitterhowl]

В дополнение из той же темы - пишут, что стараются избегать monitor_conditions, как чумы ) В этом же сообщении приводят пример про мод 1648 - добавление/удаление одного монитора monitor_event, содержащего 250 проверок if никак не отражается на производительности игры. Добавление/удаление скрипта "Carl the taxman" (какой-то известный экономический, вроде раньше слышал про него), содержащего 600 мониторов monitor_event для всех фракций в игре - меняет производительность на 40 секунд. В цифрах как-то понятнее, да? )

 

Здесь же. Одно из самых вредных условий это CharacterTurnStart/End, потому что как мы теперь понимаем, срабатывает для каждого персонажа на карте, это потом уже движок проверяет принадлежность фракции (и тратит на это процессорное время тоже). Дальше по загрузности идет SettlementTurnStart/End, менее вредное, для каждого поселения проверяется то же самое. Ну и потом FactionTurnStartEnd. Какая альтернатива? Предлагают следующие операторы - CharacterSelected (когда игрок выбрал персонажа), Pre/PostBattle (до или после сражения), EventCounter (значение определенного счетчика событий). По идее эти мониторы срабатывают реже и более адресно, нагрузка на процессор снижается.Это не значит, что от других мониторов надо отказаться, я сам сначала стал ломать голову как мне переделывать свой скрипт. Но поскольку мои старые мониторы не занимают много времени их я решил оставить как есть, а вот новые делать уже исходя из полученных знаний. Потому что очень легко сломать работающий скрипт заменой одного оператора, а потом дольше будет отлаживать, с этого я начал, собственно, рассказывать )

 

Вот еще важный момент из учебника alpaca Порядок загрузки для событий  TurnStart и TurnEnd выглядит следующим образом: CharacterTurn[Start/End], SettlementTurn[Start/End],FactionTurn[Start/End]. Почему это важно? Иногда есть взаимосвязанные мониторы в скрипте, но они не работают как вы задумали, т.е. событие происходит в лучшем случае на ход позже, или вообще не происходит. Тогда смотрите очередность мониторов, возможно, к примеру какой-то счетчик меняет нужное вам значение раньше, чем проверяется его значение в другом нужно вам мониторе. Ну и совсем общее - все файлы игра читает сверху вниз, в этом смысле очередность скрпитов и особенно трейтов имеет большое значение.

Сообщение отредактировал bitterhowl: 15 апреля 2015 - 05:10

[bitterhowl]

Да, вот еще уточнение - порядок файлов, которые проверяет игра всегда один, сначала campaign_script, потом export_descr_character_traits, потом export_descr_ancillaries. Почему это имеет значение лично я убедился на конкретном примере - одно и то же событие, PostBattle, к которому я хотел привязать эффекты в скрипте и трейтах, проверяется с вышеуказанной очередностью и мне пришлось менять скрипт. Я хотел чтобы после битвы в случае появления трейта "Ранен" начинал бы крутиться счетчик в campaign_script. Но получается, что CS проверяет событие PostBattle первым, и в этот момент трейты еще не проверялись и не присваивались и счетчик не сработает никогда, даже если генерала все же ранят. Поэтому пришлось менять условие в CS на менее выгодное CharacterTurnEnd, которое проверяется чаще и больше грузит процессор, ну зато проверяется тогда, когда трейты после битвы уже присвоены.

[Вильгефорц]

Как сделать чтобы “Папа“ римский выберался из дипломатов.. И еще как. сделать женщину фракция правителем фракции , думаю убить ее и оставить ее в древе фракции ,но не знаю как сделать чтобы муж был воякой ,а не просто числился в древе?

[Master_TW_DAR]

 

 

[color=rgb(153,153,153);font-family:helvetica, arial, sans-serif;background-color:rgb(34,34,34);]ак сделать чтобы “Папа“ римский выберался из дипломатов..[/color]

Папа = лидер фракции, имеющей атрибут papal_faction. Он может быть только полководцем, то есть named character. 

 

 

[color=rgb(153,153,153);font-family:helvetica, arial, sans-serif;background-color:rgb(34,34,34);]И еще как. сделать женщину фракция правителем фракции , думаю убить ее и оставить ее в древе фракции ,[/color]

Попробуй в декскр_страт лидеру фракции поставить другой пол - вместо male используй female. Я не помню, будет ли лог реагировать как-то на это, проверь ...

[Mesn]

Мед не поддерживает женщин-полководцев. А лидер фракции должен быть полководцем.

[Вильгефорц]

1. Вы не поняли меня.Я имелл ввиду что бы Папа римский изберался не из священиков ,а из дипломатов. Ясно?2. Ну что ж того Цинтрийская Львица будет мужиком , а скелигийский пират бабой.. А Павета их сыном,воо..

[Master_TW_DAR]

1. Батя избирается из священников по показателю "Благочестие". У дипломатов же "Влияние". Поэтому никак не сделаешь. Как вариант - отредактировать в descr_character.txt у данного типа персонажей параметр actions. Но у меня большие сомнения в том, что игра и движок адекватно оценят такую сторону моддинга ...

 

 2. Как сделать бабу мужиком )

 

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