Autor: CavalryCmdr
Od Tłumacza:
Ten poradnik to tak naprawdę wyjaśnienie większości poszczególnych algorytmów w skryptach AI plus kilka wskazówek. Pozwala on się rozeznać w jaki sposób AI zostało stworzone, jednak nie daje żadnych odpowiedzi na pytania. Pozwala je jedynie znaleźć samemu. Generalnie całe AI zbudowane jest na bardzo prostych zależnościach w stylu "jeśli_nastąpi:A - to_działaj:B" oraz na prostych funkcjach liniowych (dawna 7-ma klasa podstawówki, teraz to nie wiem). Oczywiście jest to trochę bardzie skomplikowane niż tu podałem. Z reguły jest tak"
"jeśli_nastąpi:A, oraz_nastąpi:B - to_działaj:C, chyba_że: spełniony_waruneki wartość:X mieści_się_pomiędzy_wartościami:Y_i_Z - wtedy_działaj:E"
do tego wartość X zależy od warunków M, N, O i P i jej minimalna wartość to G a maksymalna to H
Dlatego niestety przydaje się dobra znajomość matematyki. Sądzę, że ludzie z wykształceniem technicznym czy innym ścisłym poradzą sobie lepiej i zrozumieją to wszystko szybciej. Dodatkową przeszkodą niestety nadal będzie język. Minimalna znajomość angielskiego jest nadal NIEZBĘDNA. Wszystkie przytoczone algorytmy pozostawiłem w oryginalnej formie starając się je tłumaczyć w objaśnieniach ale językiem kodowania i skryptowania nadaj będzie angielski. Tak czy inaczej uważam, że większość przeszkód da się pokonać przy odpowiedniej dawce determinacji i zapału.
POWODZENIA I MIŁEJ ZABAWY!
Redaktor Szuwarek (czyli woda84)
Wszystkie informacje tu zawarte pochodzą z moich własnych długotrwałych badań nad działaniem i możliwościami modyfikacji AI kampanii i nie są w żaden sposób „oficjalne”. Nie ma tu też informacji wziętych z innych źródeł bez wcześniejszego sprawdzenia przeze mnie. Przeszukałem różne fora internetowe i zebrałem kawałki niemal zewsząd, lecz przez szerokie spektrum źródeł nie jestem w stanie powiedzieć, z których źródeł co pochodzi. Nie zastrzegam też niczego jako własne odkrycie, z tych samych powodów.
Poradnik jest dla M2TW w wersji 1.2. Wiele opcji nie jest dostępna we wcześniejszych wersjach. 1.3 to w większości to samo chociaż kingdoms dostarcza kilka nie opisanych tu opcji.
To są 4 główne pliki wpływające na zachowanie AI, determinują jak AI „myśli”
• descr_campaign_ai_db.xml
• descr_strat.txt
• descr_faction_standing.txt
• descr_diplomacy.xml
Dwa mniejsze pliki też wpływają na zachowanie AI, bez bezpośredniego wpływu na sposób „myślenia”.
• config_ai_battle.xml
• descr_character.txt
Zacznę od plików mających najmniejszy wpływ na AI, więc ostatnie wpisy będą najbardziej ingerujące w zachowanie AI.
config_ai_battle.xml
Są tak naprawdę tylko dwa wiersze w całym pliku istotne dla AI kampanii:
<sally-out-ratio>2.0</sally-out-ratio>
To się tłumaczy samo: jest to stosunek sił obrońcy do atakującego konieczny by AI zdecydował się na wypad zamiast bronić się w bitwie oblężniczej (Sally: ang. – wypad zbrojny, wycieczka zbrojna, przy. red.). To dosłownie oznacza, że siła obrońcy musi być dwukrotnie wyższa niż atakującego. To jest używane zarówno w kampanii jak i podczas bitwy by określić czy się bronić czy kontratakować.
<friendly-to-enemy-strength-ratio>0.8</friendly-to-enemy-strength-ratio>
To też samo się tłumaczy. Jest to stosunek siły danej armii do siły celu by określić czy atakować czy nie. Jak poprzednio używane jest zarówno w kampanii jak i w bitwie. W kampanii określa czy przystąpić do bitwy czy nie. W bitwie określa czy broniąca się armia będzie działać ofensywnie. Domyślna wartość tu pokazana (0.8) oznacza, że AI uważa się za silniejszego nawet gdy jest troszkę słabszy wg wartości matematycznych.
Niestety nie znalazłem sposobu na wpłynięcie na te ustawienia w kontekście tego czy cel jest kontrolowany przez AI czy gracza.
descr_character.txt
Ten plik nie ma wpływu na to jak AI „myśli” ale mimo to silnie wpływa na jego zachowanie. Ponownie są dwa istotne wiersze, choć oba pojawiają się dla każdego typu postaci:
starting_action_points80; default value for all characters and pathfinding calculations
Generalnie jest to zasięg ruchu na mapie kampanii. To ma spory wpływ na zachowanie AI, jak organizuje i przemieszcza armie, gdzie wybiera miejsce na łączenie jednostek w armie, co jest uważanie za realne zagrożenia/cele, gdzie wybiera umiejscowienie armii obronnych, generalnie wszystko. Dla różnych map kampanii będą różne optymalne ustawienia, z własnych doświadczeń wiem, że dla vanila (czysta, nie zmodowana podstawka – przyp. red.) idealne ustawienie to 135; generalnie średnia odległość pomiędzy lokacjami (miasta, zamki). Na doskonałej mapie (dla zachowań AI) odległości między lokacjami byłyby wszędzie takie same, a punkty ruch troszeczkę większe. Zwiększenie tej wartości spowodowałby, że AI zachowałoby się lepiej na bardziej pustych obszarach (przykładowo Rosja) natomiast tam gdzie jest gęściej (przykładowo Europa zachodnia) AI miałaby problem ze zgrupowaniem armii przed rozpoczęciem oblężenia. Obniżając tą wartość zauważymy, że armie na obszarach rozległych nie będą robić prawie nic tymczasem na tych o wyższym zagęszczeniu radziły by sobie nieźle.
Wniosek red.:
Należy zatem konstruować mapy o w miarę regularnym rozmieszczeniu lokacji i dopasować do tego adekwatny zasięg ruchu. Dodatkowo, tłumaczy to małe, wędrujące tu i tam grupki armii, które same nie mogą niczego zdziałać. No i wiadomo czemu Polska sterowana przez AI tak często dostaje wciry – słabe jednostki + za duże odległości między lokacjami.
Ważne: Indywidualne ustawienia dla każdego charakteru nie działają jak należy! Dla najlepszego efektu ustawić wszystkie na tą samą wartość co domyślna.
wage_base200
To jest „koszt utrzymania” (tak jak dla jednostek). To wpływa na AI ponieważ nie jest zaprogramowana (z jakichkolwiek przyczyn) na uwzględnianie tych kosztów. Dodatkowo na trudniejszych ustawieniach AI będzie „spawnować” generałów, przy 200 florenach na generała na turę, sporo pieniędzy będzie iść na niekontrolowaną sytuację. Pamiętaj, że musisz też płacić utrzymanie straży przybocznej generałów. To oznacza, że każdy generał kosztuje tak naprawdę 400-600 florenów na turę. Księżniczki kosztują 250 a dyplomaci tylko 50, więc wydaj księżniczkę najszybciej jak to będzie możliwe albo obniż ich koszty (są trochę bardziej przydatne niż dyplomaci więc sugeruję 75-100).
Oprócz w/w absurdalnych kosztów utrzymania AI ma tendencję do rekrutacji mnóstwa różnych agentów, po czym nie wydaje im rozkazów i stoją bezczynnie. To stwarza poważną rysę na gospodarce AI, zwłaszcza w późniejszym etapie gry gdy większe frakcje mogą mieć 20 lub więcej szpiegów (to 2000 florenów co turę) i tyle samo assassynów (dodatkowe 4000 na turę), do tego doliczmy kapłanów do oporu i kilku dyplomatów i nie dziwota, że nie może w pełni rozwinąć swoich lokacji. Osobiście zdecydowałem się zmodyfikować to do tego co uważam za rozsądniejsze wtedy zaskryptowałem refundację połowy kosztów dla frakcji AI. Widząc jak AI wykorzysta efektywnie tylko około połowę swoich agentów nie uznaję tego za cheatowanie (nie bardzo wiem jak to zrobił, że tylko AI dostaje refundację, ja postaram się raczej pogrzebać w limitach globalnych dla agentów, jak coś wykombinuję to dopiszę – przyp. red.).
descr_diplomacy.xml
Ten plik wpływa na dyplomację, głównie pomiędzy graczem i AI oraz w mniejszym stopniu między AI-AI. Krótka rozpiska jak działa.
<item name="offer_payment">
<cost modifier="1.0"/>
<faction_standing modifier="0.0"/>
<global_standing modifier="0.0"/>
</item>
„Item name” (dosł. - nazwa rzeczy – przyp. red.) jest całkiem zrozumiałe, nie trudno zgadnąć, której opcji dyplomatycznej dotyczy. Pamiętaj, że nie możesz nic dodać ani usunąć – możesz tylko zmieniać.
"Cost modifier" to względna „wartość”, z jaką AI będzie traktować opcję dyplomatyczną, ponieważ dokładna wartość jest abstrakcyjna, "cost modifier "określa jak bardzo AI chce czegoś (nie da się zmodować*), tutaj możesz przynajmniej względnie zmienić tą wartość. Uwaga: AI nigdy nie zaoferuje czegoś o wartości 0 lub niższej. Pamiętaj też, że „wartość” oznacza też koszt a niektóre opcje dyplomatyczne takie jak „offer_payment” zwiększają wartość a „demand_payment” kosztuje Ciebie ‘(w tym przypadku AI którego dotyczy ten skrypt – przyp. red.), a inne jak „offer_ceasefire” mogą być dodatnie lub ujemne w zależności czy AI chce wstrzymać ogień czy nie.
*Trochę to enigmatyczne ale już wyjaśniam. Ten plik pomaga tylko AI negocjować opcje dyplomatyczne. To czy AI naprawdę chce czegoś czy nie zależy od skryptów w descr_campaign_ai_db.xml. Tam jest to zdeterminowane od aktualnej sytuacji w grze, tak więc nie da się ustawić, żeby AI zawsze chciał pokoju nawet ja wygrywa wojnę. Ale o tym pliku później. – Przyp. red.
"faction_standing modifier" i "global_standing modifier" to wartości, które nie wpływają bezpośrednio na wartość transakcji dyplomatycznej, ale wpływają na szansę jej zaakceptowania przez AI. "faction_standing" oznacza jak bardzo AI Cię lubi, więc wartość pozytywna oznacza chętniej przyjmie propozycję gdy Cie lubi a negatywna oznacza, że chętniej przyjmie propozycję gdy Cię nie lubi. "global_standing" to reputacja twojej frakcji, więc wartość pozytywna oznacza, że AI chętniej akceptuje propozycję im lepszą masz reputację i na odwrót.
<diplomacy_text_fields>
To są jedynie tłumaczenia wartości numerycznych na wyświetlany tekst dla takich rzeczy jak stosunki, reputacja, bogactwo i siła.
Nie jestem dostatecznie zaznajomiony z „demeanour_entry” (demeanour – ang. postawa, jest to sposób w jaki AI reaguje na propozycje, np. obrażony, neutralny, zadowolony – przyp. red.) aby wygłaszać jakieś mądrości na ten temat. Chociaż bawiąc się wartościami tutaj udało mi się zwiększyć chęć AI do składania kontr-ofert (szkoda, że nie napisał jak – przyp. red.).
descr_faction_standing.txt
Tak jak sugeruje tytuł pliku, kontroluje on jak twoje działania wpływają na relacje z innymi frakcjami oraz na globalną reputację. To jest plik z decyzjami progowymi (o tym później – przyp. red.) taki jak ten z cechami i świtą generałów. Nie będę tu omawiał mechanizmów progowych, to rozległy temat i jest pokryty gdzie indziej. Co jest ważne to to, że warunek "FactionIsLocal" i "not FactionIsLocal"(„local” czyli kontrolowana przez gracza) można stosować w tym pliku, pozwalając na różnicę w efekcie pomiędzy akcją wykonaną przez gracza a AI.
Z uwagi na długość posta wyjaśnię początkową sekcję pliku.
min_faction_standing-1.0
max_faction_standing1.0
Są to oczywiście minimalne i maksymalne wartości relacji, NIE radzę tego zmieniać ponieważ te wartości są używane w mnóstwie innych miejsc, modowanie ich wszystkich byłoby dość nudne.
relations_improved_thresholds
{
0.25
0.4
0.6
}
relations_worsened_thresholds
{
-0.8
-0.4
-0.25
}
Gdy te wartości relacji zostają osiągnięte, odpowiednia wiadomość się pojawia, nic więcej.
Generalnie po wczytaniu się, jedynego może sprawić jakieś problemy to:
normalise [target_faction_standing] [divisor] --> for each
affected faction standing,
add (target_faction_standing - faction_standing)/divisor
podaję przykład:
FactionStanding target_faction normalise -1.0 20
[target_faction_standing] = -1.0
[divisor] = 20
Dokładne znaczenie tego wiersza może byś trudne do odcyfrowania, więc postaram się to wyjaśnić w najprostszy możliwy sposób.
Różnica pomiędzy obecną reputacją frakcji a docelową reputacją frakcji podzieloną przez dzielnik. Dla przykładu: powiedzmy, że obecna reputacja (faction_standing) wynosi 0.2 a wiemy, że docelowa reputacja to -1.0 (czyli gramy na poziomie h lub vh – przyp. red.), więc różnica wynosi -1.2. -1.2/20=-0.06. Ta wartość jest dodana do obecnej reputacji 0.2+(-0.06)=0.14. To oznacza, że im bliżej twojej frakcji do docelowej reputacji tym słabiej będzie ta funkcja działać. Prościej tego wyjaśnić nie umiem.
descr_strat.txt
Poza wartościami startowymi reputacji podanymi na końcu tego pliku, które są dosyć łatwe do zrozumienia, więc nie będę tego tłumaczył, istnieją tu dwa główne wiersze dla każdej frakcji, które znacząco wpływają na AI.
factionengland, balanced smith
Podobnie jak w Romku, myślę, że najlepiej to wyjaśnić w ten sposób:
To kontroluje zestaw osobowości produkcji AI, które wpływają na skłonność do budowania i rekrutowania (ale nie naprawy i doszkalania). Ta skłonność jest dość mała w porównaniu do czynników generowanych przez grę takich jak „wróg atakuje mnie mnóstwem kawalerii, nabuduję sobie włóczników i pikinierów”. Wyjaśnienie systemu ważenia (metoda badania stopnia ważności określonego czynnika lub zmiennej – przyp. red.), który napędza produkcję AI w pełni jest poza spektrum tego dokumentu i opisanie go zajęło by kilka dni.
Pokrótce, osobowości odpowiedzialne za konstrukcję budynków to (od najwyższej do najniższej):
• Balanced – skierowany na wzrost, dochód z podatków, bonusy z handlu (drogi), mury i budynki z xp bonus
• Religious - skierowany na wzrost, lojalność, dochód z podatków, farmy, mury i prawo
• Trader - skierowany na wzrost, poziom handlu, bazy handlowe, upgrady broni, igrzyska, wyścigi i budynki z xp bonus
• Comfort - skierowany na wzrost, farmy, igrzyska, wyścigi, bonusy doświadczenia i zadowolenie
• Bureaucrat - skierowany na dochód z podatków, wzrost, zdrowie publiczne, handel, mury, ulepszoną straż przyboczną i prawo
• Craftsman - skierowany na mury, wyścigi, dochód z podatków, upgready broni, bonusy doświadczenia, kopalnie, zdrowie publiczne i wzrost
• Sailor - skierowany na handel morski, wpływy z podatków, mury, wzrost, handel
• Fortified - skierowany na mury, dochód z podatków, wzrost, lojalność, obronność, straż przyboczną i prawo
Te osobowości odnoszą się do właściwości budynków, zamiast do samych budynków. Gra nie wie co to jest „Płatnerz”, wie tylko, że jest to budynek który wprowadza udoskonalenia broni, i dla tego osobowość Craftsman chętniej będzie budować te budynki niż inna.
Te osobowości są łączone osobowościami odnoście produkcji jednostek, czyli:
• Smith – wszystko po równo
• Mao - skierowany na liczne oddziały, lekką piechotę
• Genghis - skierowany na kawalerią miotającą i lekką
• Stalin - skierowany na ciężką piechotę, liczne oddziały i artylerię
• Napoleon - skierowany na kombinację lekkiej i ciężkiej piechoty, lekką kawalerię
• Henry - skierowany na ciężką i lekką kawalerię, piechotę miotającą
• Caesar - skierowany na ciężką piechotę, lekką kawalerię, artylerię oblężniczą
Tu działa ten sam system jak w przypadku budynków. Kategoria jednostek i klasa są zbierane w momencie gdy wgrywana jest baza danych dla jednostek aby dać typ produkcji jednostki i prawdopodobieństwo, że AI wybierze daną jednostkę, która aktualnie może być produkowana jest modyfikowana przez system ważenia (opisany wyżej – przyp. red.). {Tutaj trochę zamieszał, więc wyjaśniam: wybrana do produkcji jednostka to kombinacja osobowości frakcji, dostępnych jednostek i sytuacji gry. Przykładowo AI preferuje lekką kawalerię ale nie jest ona jeszcze dostępna i jest atakowany włócznikami i pikinierami, więc wybierze np. mieszaninę wszelkich miotaczy i ciężką piechotę - przyp. red.}. Jest też element losowy w wyborze produkcji budynków i jednostek, więc efekt końcowy zależny jest też od statystyki. Kolejny czynnik nałożony na to wszystko, który może namieszać w procesie to tendencja do produkcji zróżnicowanych jednostek (w odniesieniu do tego co już zostało wyprodukowane) i system ważenia w odniesieniu do siły oddziału.
Ponieważ M2TW ma podział na zamki i miasta bez uwzględnienia tego w AI, ważne jest by pamiętać, że AI będzie produkować dwa razy więcej machin oblężniczych i lekkiej piechoty niż to wynika z jej osobowości. Generalnie, eliminujcie wszystkie osobowości, które skierowane są na sprzęt oblężniczy a te skierowane na lekką piechotę przypiszcie frakcjom z bardzo dobrą milicją (np. Szkocja i frakcje włoskie). W tym momencie oto co nam zostaje.
• Genghis - skierowany na kawalerią miotającą i lekką
• Henry - skierowany na ciężką i lekką kawalerię, piechotę miotającą
oraz
• Mao - skierowany na liczne oddziały, lekką piechotę
• Napoleon - skierowany na kombinację lekkiej i ciężkiej piechoty, lekką kawalerię
Dwie ostatnie zarezerwowane będą dla frakcji z lepszą milicją. JEDNAKŻE są wyjątki pozbawione sensu. Np. Dania rekrutuje nieźle przy osobowości „Smith” a prawie wszystkie frakcje będą wypluwać samą milicję i machiny oblężnicze („Smith” to ustawienie domyślne dla wszystkich frakcji i stąd biorą się te idiotyczne armie w stylu Bizancjum: 50%-machiny, 30-kawaleria miotająca i 20-milicja miejska). Osobowości to ustawienia indywidualne, w których metoda prób i błędów oraz pozycja startowa frakcji odgrywają niemałe znaczenie. Dla przykładu „sailor” (ang.: żeglarz – przyp. red.) nie ma sensu dla w większości śródlądowego Świętego Cesarstwa Rzymskiego, ale ze względu na tereny górskie z kopalniami „craftsman” (ang.: rzemieślnik – przyp. red.) jak najbardziej. Z drugiej strony Hiszpania posiada sporo surowców kopalnianych a jej prowincje (przynajmniej początkowo) są w większości nadmorskie, więc obydwie osobowości pasują.
ai_label catholic
To jest ai_label (ang.: etykieta – przyp. red.) łączone z descr_campaign_ai_db.xml, którego ai używa do określenia swojego zachowania.
Teraz czas na największą sekcję.
descr_campaign_ai_db.xml
Ten plik jest potężny i nie jest wykorzystywany na miarę swojego potencjału, zwłaszcza w połączeniu z innymi plikami, które opisałem. Przelecę szybko przez intro i wyjaśnię:
<trusted_ally_fs_threshold float="0.5"/> // min threshold for how much we like the target faction to consider them a trusted ally
<trusted_ally_target_fs_threshold float="0.5"/> // min threshold for how much the target faction likes us to consider them a trusted ally
<trusted_ally_target_human_fs_threshold float="0.0"/> // min threshold for how much the target (human) faction likes us to consider them a trusted ally
<trusted_ally_gs_threshold float="-1.0"/> // min threshold for how trustworthy we are to consider the target faction a trusted ally
<trusted_ally_target_gs_threshold float="-0.1"/> // min threshold for how trustworthy is the target faction to consider them a trusted ally
<trusted_ally_enemy_auto_war bool="false"/> // flag to indicate if a faction automatically goes to war with a trusted allies enemy
Całkiem nieźle wyjaśnione przez twórców, jednak nie podoba mi się sposób użycia tej sekcji. „trusted_ally” (ang.: zaufany sojusznik – przyp. red.) to tylko jedyne odniesienie do frakcji trzecich (osób trzecich czyli spoza dwóch rozpatrywanych: nas i frakcji docelowej) w tej sekcji, bo są jeszcze "trusted_ally_enemy" (ang.: wróg zaufanego sojusznika – przyp. red.) i "trusted_ally_protectorate" (ang.: protektorat zaufanego sojusznika – przyp. red.). To oznacza, że nie da się namówić do współpracy sojuszników, którzy nie uważają Cię za zaufanego sojusznika. Używam „trusted_ally”dla tego celu podczas gdy vanilla i inne mody używają tego tylko do określenia czy frakcja mieści się w granicach uznania za „trusted_ally”czy też nie. Postępując w ten sposób eliminują wpływ frakcji trzecich a ja tworzę więcej interakcji*.
* Autor trochę tu namieszał, więc wyjaśniam. Najwyraźniej AI nie uwzględnia przy interakcji z daną frakcją kim frakcja jest dla jego zaufanego sojusznika (może być wrogiem zaufanego sojusznika lub jego protektoratem). Autor najwyraźniej znalazł sposób aby to dodać do łańcuch decyzyjnego, nie powiedział niestety jak. Nie wiem też czy istnieją odniesienia „zaufany sojusznik zaufanego sojusznika” i „protektor zaufanego sojusznika”.
<invade_priority_fs_modifier float="-400.0"/> // modifies the final invade priority for new faction targets by += (faction_standing * modifier) {makes factions more likely to start war with disliked targets}
<invade_priority_gs_modifier float="0.0f"/> // modifies the final invade priority for new faction targets by += (global_standing * modifier) {makes factions more likely to start war with untrustworthy targets}
<invade_priority_assistance_offset int="200"/> // modifies the final invade priority for new faction targets where military assistance has been asked by += (offset) {makes factions more likely to start war with military assistance targets}
To też jest całkiem nieźle wyjaśnione, jednak modyfikatory „fs” (faction standing – relacja – przyp. red.) i „gs” (global standing – reputacja – przyp. red.) są nieaktywne podczas wojny. To dobrze bo nie powinny być i lepiej by mi się ich używało gdyby odnotwoali to w wyjaśnieniu. Nie jestem też pewien czy żądanie pomocy wojskowej działa w stanie „AtWar” ale nie wydaje mi się (to by było naprawdę durne – przyp. red.).
<use_cheat_overrides bool="true"/> // determines if cheat
overrides (force peace with ai, force attack with humans) are
applied
To jest ważne, generalnie wszystkie odniesienia do kodów jądra gry w tym pliku są włączone ("true") lub wyłączone ("false"). Jedyny sposób aby AI było rozsądne to wpisać „false”.
Teraz min_entry thresholds (minimalna wartość progowa/graniczna – przyp. red.) i max_entry thresholds (maxymalna wartość progowa/graniczna – przyp. red.). Jeśli nie wiesz i nie możesz pojąć co to takiego to przykro mi ale znajdź inne hobby. Nie chcę brzmieć okrutnie ale jeśli nie jesteś w stanie samemu tego pojąć to twoje talenty leżą gdzie indziej a moja próba wytłumaczenia tego to strata twojego i mojego czasu.*
*Ja się akurat z nim nie zgadzam. Jak czegoś nie rozumiesz to przeczytaj drugi raz. A potem trzeci. I piąty. Dziesiąty też. I wracaj do tego tak długo aż zrozumiesz. Poza tym przeczytaj słowo wstępne od tłumacza (przyp. red.).
Każda frakcja kalkuluje każdą inną frakcję jako „target” (ang.: cel – przyp. red.) co turę zanim wykona ruch. AI zaatakuje te frakcje, które mają najwyższy "invade_priority" (ang.: priorytet inwazji czyli jak bardzi chce zaatakować – przyp. red.), poza jednym wyjątkiem (invade_opprotunistic) o czym powiem później.
frontline_balance="0.0" :: ratio of factions frontline military
strength vs the target
Na pierwszy rzut oka wydaje się zrozumiałe, wartość „2.0” powinna oznaczać, że w regionach granicznych jesteśmy dwa razy silniejsi od targetu. Jednak LTGD log (opiszę to później) mówi coś ciekawego. Ważne jest aby określić „is_neighbour” (ang.: jest sąsiadem – przyp. red.) gdy tego używasz, dodatkowo gdy jednostki są zaokrętowane tworzą nieczytelny balans graniczny (od 0.000001 lub mniej do 100000.0 lub więcej!). Takoż AI mogą mieć balans graniczny wyższy niż 2.0 a jednocześnie nie mieć prawie jednostek w regionach granicznych, a balans będzie wynikiem zaokrętowanych armii na drugim końcu mapy. Trzeba zatem koniecznie określić minimalną/maksymalną wartość progową/graniczną, ja używam 1000.0 i 0.001 ponieważ nie zostaną one spełnione i nie mają żadnego znaczenia ale AI będzie się do nich odwoływać i traktować tylko jako "frontline_balance" nie może być efektywnie odczytana. Nie da się jej użyć do niesąsiadujących frakcji.
military_balance="0.0" :: ratio of factions overall military
strength vs the target
Po prostu stosunek sił wojskowych liczonych całościowo, razem z ewentualną flotą.
production_balance="0.0" :: ratio of factions overall production
strength vs the target
To samo tylko dotyczące produkcji.
target_num_enemies="0" :: the number of enemies the target has
num_enemies="0" :: the number of enemies the faction has
target_num_enemies="0" (ilość_wrogów_targetu=”0” – przyp. red.) Proste prawda? BŁĄD! To muszę jeszcze rozpracować bo może być frakcja, która z nikim nie ma statusu „AtWar” a ma 2 czy trzech „wrogów” a inna może być „AtWar” z 2 lub 3 frakcjami i nie „wrogów”. Generalnie jakkolwiek działa nie pozwalam aby ten plik miał jakiś znaczący wpływ.
has_alliance_against="false" :: is the faction part of an
alliance against target
To jest trochę mylące. Większość ludzi (w tym ja) zakłada, że to umowa dyplomatyczna na zaatakowanie frakcji. NIEPRAWDA. Jest to oględne spojżenie na aktualną sytuację polityczną, „Mam sojuszników, którzy nie mają sojuszu z tą frakcją?” oznacza "has_alliance_against="true". To bardzo ogólne ale może być skutecznie stosowane.
military_balance_plus_enemies="0.0" :: ratio of factions overall
military strength vs the target (plus all of its enemies)
To znaczy dokładnie to na co wygląda, co ważniejsze, nie jest niczym innym. To balans siły wojskowej uwzględniający wrogów targetu, ale nie uwzględnia frakcji. Używać ostrożnie.*
*Tutaj autor chba popełnił jakiś błąd stylstyczny. Ja to czytam tak: stosunek ogólnej siły frakcji do targetu i jego wrogów (przyp. red.)
alliance_military_balance="0.0" :: ratio of factions (plus its
allies) overall military strength vs the target
To samo co wyżej tylko nie uwzględnia sojuszników targetu.
strongest_neighbour="false" :: is the target the factions
strongest neighbour
Czy target jest najsilniejszym z naszych sąsiadów. False-nie, true-tak.
most_desirable="false" :: is the target the factions most
desirable target
Nie mam pojęcia jak AI decyduje kto jest „most_desirable” (ang.: najbardziej pożądany – przyp. red.). Wiem, że to nie ten kto „ma najbogatsze ziemie”, „target określony w warunkach zwycięstwa”, „najsilniejszy” ani też nie „najsłabszy”. To może ale nie musi być sąsiad. Generalnie nie mam pojęcia (pewnie kombinacja powyższych w odniesieniu do aktualnej sytuacji politycznej – przyp. red.).
faction_standing="-1.0" :: how much does the faction like the target target_global_standing="-1.0" :: how trustworthy is the target to the rest of the world target_faction_standing="-1.0" :: how much does the target faction like this faction global_standing="-1.0" :: how trustworthy is this faction to the rest of the world
To tłumaczy się samo zwłaszcza jeśli odniesiesz to do descr_faction_standing.txt
target_religion="catholic" :: the religion of the target (see
descr_religions.txt)
Po prostu przypisanie religii, także w descr_religions.txt
enemy_excommunicated="false" :: is the target excommunicated
excommunicated="false" :: is this faction excommunicated
Też jasne. Frakcje niekatolickie zawsze będą miały „false”.
num_turns_allied="0" :: the number of turns since the faction agreed to an alliance with the target
num_turns_ceasfire="0" :: the number of turns since the faction has agreed to a ceasefire with the target (-1 for no agreement)
stance="Allied" :: diplomatic stance with the target (Allied, Neutral, AtWar)
target_faction="england" :: target faction label (see descr_sm_factions.txt)
target_human="false" :: is the target a human player
To też jasne.
target_is_shadow="false" :: is the target this factions shadow faction
Relikt z RTW:BI nie używany w M2TW
turn_number="0" :: the game turn number (starting at 0)
is_protectorate="false" :: is the target our protectorate
is_protectorate_of_catholic="false" :: is the target a protectorate of a non-excommunicated catholic faction
Proste.
free_strength_balance="0.0" :: ratio of factions free military strength vs the target
To jest to na co być może liczysz. To względna siła po uwzględnieniu bliskich wrogich armii dla obydwy frakcji; naszej i targetu. Pamiętaj, że to uwzględnia buntowników, więc ostrożnie na początku gry.
borders_all_our_regions="false" :: does the target border on all the factions region groups
target_weakest_neighbour="false" :: is the faction the targets weakest neighbour
has_ceasehostilities="false" :: does the faction have a cease hostilities mission against the target from the papal faction is_neighbour="false" :: does the target neighbour on any of the factions regions
trusted_ally="false" :: is the target a trusted ally (they like us more than fs_thresh, and their global standing > gs_thresh, and they are allied)
Znowu jasne.
trusted_ally_enemy="false" :: is the target an enemy of a trusted ally
trusted_ally_protectorate="false" :: is the target a protectorate of a trusted ally
O tym mówiłem wcześniej. To są jedyna odnośniki do „trzecich frakcji” (oprócz oględnego „ma_sojusz_przeciw” i „jest_protrktoratem_katolików”). Jeśli chcecie by sojusznicy bardziej z Wami współpracowali, obniżcie próg uznania jako „zaufanego_sojusznika” i użyjcie tej funkcji bez oporów.
num_settlements="0" :: how many settlements does the faction own
Wszystko jasne.
rand="0.0":: a random value
Losowa liczba jest generowana co turę dla każdej z frakcji targetowych. Liczba jest pomiędzy 0.0 i 1.0 ale nie ma ograniczenia dla stopnia dziesiętnego. 0.00000127 jest tak samo prawdopodobne ja 0.2. To oznacza, że możesz jej użyć do symulowania dowolnej wartości. Przykładowo:
max_entry rand="0.333333333"
To by była 1 na 3 szanse. Dalej można dać:
min_entry rand="0.333333334"
max_entry rand="0.666666666"
I idąc dalej:
min_entry rand="0.666666667"
Tak tworzymy losową liczbę od 1 do 3 i każda ma równą szansę na wygenerowanie. Osobiście używam tego jako wartości procentowej. Pamiętaj, że tylko jedna losowa liczba jest generowana dla każdego target co turę, więc upewnij się, że masz dla niej zastosowanie.*
*Nie bardzo rozumiem o co chodzi z tą liczbą. Niewiem gdzie i kiedy jest stosowana. Jak się dowiem to postaram się coś ciekawego dopisać (przyp. red.)
Teraz „action _attitude” (ang.: nastawienie_frakcji – przyp. red.) lub decyzja używana jeśli warunki minimalne i maksymalne są spełnione. Omówię wszystkie pozostałe a potem każde ustawienie „inwazji” i „obrony” indywidualnie.
defend_priority="0" :: The defensive priority of achieving stance against this faction (NOT USED AT PRESENT) (additive with previous decisions this turn)
Niestety "not used at present" oznacza, że algorytmu nie można zastosować.
invade_priority="0" :: priority of achieving invasion against this faction (additive with previous decisions this turn). Compared with priority for decisions against all other factions to choose highest. Value modified internally by faction standing.
To może być najważniejszy czynnik. Determinuje kogo AI zaatakuje i jaka część jej zasobów poświęci na ten atak. Im bliżej do "invade_priority_max" (maksymalna wartość priorytetu inwazji – przyp. red.) tym więcej zasobów będzie na inwazję przeznaczone. Pamiętaj, że AI jest zdolne atakować wiele celów jeśli ich „priorytet_inwazji” jest wysoki i spróbuje skupić na tym siły lokalne zamiast wszystkich. Będąc ostrożnym możesz stworzyć efektywną wielozadaniową AI. Dodatkowo jeśli „priorytet_inwazji” mniejszy niż "invade_priority_min" (minimalny priorytet inwazji – przyp. red.) AI nie zaatakuje, chyba, że istnieje warunek "invade_opportunistic" ale o tym później.
at_war="false" :: are we at war with this enemy
Bardzo dziwna opdja. Jeśli będzie używana we wcześniejszym ustawieniu w kombinacji z „continue="true"” (kontynuować=”tak” – przyp. red.) AI będzie uważało, że jest w stanie „AtWat” nawet jeśli nie jest. To nie zmieni statusu wojna/pokój (np. jeśli frakcja nie atakuje i jest w sojuszu , nadal będzie w sojuszu).
want_peace="false" :: do we want to be at peace with this faction
Czy AI chce zaoferować "ceasefire". Niestety nie można na razie przypisać do tego wartości, tylko tak/nie.
want_ally="false" :: do we want to ally with this faction
To można zastąpić tym:
pts_alliance="0" :: points total for measuring how much we want to be allies with these people (additive with previous decisions this turn)
Co tłumaczy się samo. I wpływa na „wartość” sojuszu w oknie dyplomacji.
want_be_protect="false" :: do we want to be a protectorate of this faction
want_offer_protect="false" :: do we want to offer protectorate status to this nation
To też proste, pozwala zdecydować czy AI zaoferuje/zaakceptuje protektorat od/do target. I znowu, jeszcze nie da się przypisać „wartości”.
force_invade="false" :: must we invade now
Jeśli to będzie ustawione na „true”, AI będzie atakować wszystkim i natychmiast niezależnie od szans, omija także "invade_priority". Ostrożnie z tym.
alliance_against="0" :: how much do we want to have an alliance against this nation (additive with previous decisions this turn)
To jest niejako odniesienie to trzecich frakcji. Jeśli AI ma tu liczbę dodatnią jest ona dodawana do "pts_alliance" (punktów sojuszu – przyp. red.) dla każdej frakcji, która nie jest w sojuszu z frakcją, przeciwko której chcemy zawrzeć sojusz. Niewiem czy liczby ujemne mogą być stosowane lub czy działają. Update: to jest wartość kumulująca się co tuję i może osiągać absurdalne wartości (w setkach) co spowoduje w końcu, że każdy będzie chciał zawrzeć sojusz z każdym przeciw każdemu. Ostrożnie z tym.
pts_desire="0" :: points total for measuring our desire for this faction's territory (additive with previous decisions this turn)
Co do tego nie jestem pewien. Zakładam, że jest połączone z "most_desirable" ale nie próbowałem tego używać.
can_force_invade="true" :: can naval or forced invasion settings overwrite invade parameters
Gdy ustawione na „false” anuluje wszystkie priorytety inwazji nie określone bezpośrednio w pliku. Dodatkowo nie pozwoli na inwazje morskie przeciwko targetowi, nawet jeśli inwazja jest rozkazana w pliku. Wg mnie najlepiej używać w bardzo ograniczonym zakresie. Inwazje morskie są kontrolowane przez "invade_priority" (ponownie z wyjątkiem "invade_opportunistic").
continue="false"/> :: do we stop evaluating decision entries (false) or continue
Wg mnie najważniejszy dodatek AI do wesji 1.2. AI zaprzestanie rozważań dla obecnego celu i zabierze się za następny jak tylko dla algorytmu spełnione zostaną wartości minimalne i maksymalne, chyba że continue="true" ma zastosowanie. Ta opcja pozwala dodać wyniki różnych ustawień bez konieczności wpisywania ich do algorytmu.
Teraz drugie najważniejsze wg mnie decyzje: "invade=".
invade_buildup
To jest to na co wygląda. AI będzie próbował zgromadzić jednostki w większą grupę uderzeniową. Niestety AI nie ma priorytetu do gromadzenia oddziałów przed atakiem, więc może dojść do konfrontacji przed zgrupowaniem. Dodatkowo AI nie może nagromadzić ("buildup") inwazji morskich.
invade_immediate
To jest podstawowy rozkaz inwazji (ang.: inwazja_natychmiast – przyp. red.). AI zaatakuje jak tylko będzie to możliwe, ale będzie starało się być silniejsze od targetu (jak w descr_ai_battle.xml opisanym wyżej).
invade_raids
Znowu całkiem proste. AI będzie atakować bez dążenia do masywnych rozstrzygnięć. To oznacza blokowanie portów, jedno turowe oblężenia i niszczycielskie rajdy wgłąb terytorium. Może być przydatne ale pamiętaj, że wtedy AI nawet nie spróbuje zformować większej armii i będzie bezbronny przeciwko zdecydowanej kontrofensywie.
invade_start
Kombinacja "buildup" i "raids".
invade_none
Bardzo przydatne. AI będzie się trzymał komendy „defend”, którą za chwilę omówię. Niektóre "defend=" używają "invade_priority", więc może to być bardzo efektywne dla przygotowania do inwazji.
invade_opportunistic
Najsprytniejszy i najpotężniejszy algorytm inwazji. Pozwala na wyłapanie słabych ponktów oraz różnorodne taktyki. Tak jak w "immediate" AI zawsze będzie starał się być „silniejszy” niż target. Poważną wadą jest ignorowanie "invade_priority" nawet jeśli priorytet jest niższy niż minimum nawet gdy inna frakcja ma 10-cio krotnie wyższy priorytet. Jednak używane ostrożnie jest bardzo potężnym narzędziem.
Teraz, wg mnie jeszcze ważniejsze opcje obrony.
defend_minimal
Użycie jest ograniczone. Przypuszczam, że tylko we wczesnym stadium przeciwko buntownikom, którzy i tak nigdy nie kontratakują. Z tym ustawieniem AI nie będzie nawet próbował przechwycić wrogich armii i być może nawet podda miasto bez ostatecznej walki w ostatniej turze oblężenia.
defend_normal
Najczęściej stosowane. Z tym ustawieniem AI może nawet obsadzać lokacje garnizonami i próbować podnieść oblężenia itp. Najbardziej ogólna obrona. Aczkolwiek, jest użyteczna tylko w kombinacji z "invade_immediate" i "invade_buildup" ponieważ nie ma ustawienia na punkt obrony i trzeba ustalic zamiast tego punkt ataku (definiowany właśnie przez "invade_immediate" i "invade_buildup" – przyp. red.) aby AI miało do czego dążyć.
defend_raid
To jest chyba nawet bardziej bezużyteczne niż ”defend_minimal”. Powoduje, że będzie cała masa 1-2 jednostkowych armii biegających po własnym terytorium.
defend_frontline
Całkiem użyteczne, można stosować z "invade_opportunistic", "invade_immediate" i "invade_buildup" z dobrym efektem. AI będzie chciał toczyć walkę na linii frontu. Wielkość armii będzie określona przez typ inwazji i najbliższych wrogów. Tem algorytm używa "invade_priority" by zdecydować, na której granicy zgromadzić oddziały. Uwaga: AI nie będzie używać tych jednostek do odsieczy miast jeśli nie są w zasiągu ruchu jednej tury. Nie używać przeciw niesąsiadującym frakcją.
defend_fortified
Bardzo przydatne chyba, że AI zbuduje fort. Tak jak w „frontline” w wielu aspektach, używa "invade_priority" by zdecydować, którą granicę obstawić, tyle, że bardziej elastycznie, można zespolić z dowolnym typem inwazji i może przywołać jednostki z granicy. AI będzie też rekrutować garnizony gdy zbliży się wroga armia. Jednak cały sens się sypie jeśli AI zbuduje fort bo będzie bronić go bardziej niż miast i zamków nawet za cenę utraty ostatniego miasta.
defend_deep
To jest ustawienie „ostatni bastion”. Armie będą blisko lokacji i będą się chować na wypadek zagrożenia. Trzy wady: AI tylko broni lokacji (nie przechwytuje armii), nie można połączyć z żadnym typem inwazji (brak celów obrony), AI nie będzie przegrupowywać jednostek wewnątrz lokacji dopóki przeciwnik nie zaatakuje.
LTGD log to opcja zapisujęca informacje i decyzje używane przez descr_campaign_ai_db.xml. Aby odblokować:
[ai]
ltgd_logging = true
[log]
to = logs/system.log.txt
level = ai.ltgd trace
Zapisuje do M2 preference (lub moda). Dobre do wyłapywania błędów.
Nota: na początku descr_campaign_ai_db.xml jest zapisane:
Additionally, the ai_labels can be tested through event conditions and set through // a script command, potentially allowing ai behaviour to be changed dynamically in game depending on current game state.
Oznacza to, że możesz zaskryptować zmianę w ai_label frakcji. Przykład:
link_faction_ai england default
Co oznacza, że AI Anglii zostanie zmienione na domyślne od tego momentu. To działa, jednak przy włączonym LGTD log będzie odnotowywać używanie ai_label z descr_strat, niezależnie od aktualnie używanej etykiety.
Tłumaczenie:
Redaktor Szuwarek (czyli woda84)
Odpowiedz z cytatem
.
Zamieszczone przez woda84
