[Tutorial] Dodawanie nowych mutantów do gry (+ funkcja utrzymywania pozycji).

[The Emperor]

Przedmowa

 

Poradnik stworzony zarówno dla niemodowanej wersji Shoc jak również modów pod rzeczoną wersję stalkera.
Poniższy wstęp polecam przeczytać dla lepszego zrozumienia idei opisanej metody jak i ograniczeń jej stosowania.

 

Niniejszy poradnik stanowi opis jednego ze sposobów dodawania mutantów do świata gry - traktując o skryptowej metodzie spawnowania, umożliwiającej w swej funkcjonalności tworzenie nowych przedmiotów/postaci/mutantów - bez konieczności rozpoczynania nowej gry - co widoczne jest na prezentacji umieszczonej na końcu poradnika. Od razu pragnę nadmienić - jeśli tworzymy od podstaw swojego moda - skorzystajmy z metody spawnu z użyciem ACDC [link], ponieważ zapewnia ona znacznie lepszą płynność gry - niż skrypty obciążające mechanikę rozgrywki. Jeśli jednak chcemy dodać np. tryb freeplay z zamiarem wykorzystania zapisów gry utworzonych na samym końcu rozgrywki, lub też chcemy wzbogacić świat Zony o dodatkowy aspekt grywalności w postaci nowych questów - wówczas skorzystajmy z zawartych tutaj informacji. Oczywiście podane przykłady nie ograniczają funkcjonalności owej metody. Dla forumowiczów zaczynających przygodę z moddingiem - krótkie przypomnienie, otóż dodając obiekt z wykorzystaniem ACDC jesteśmy zmuszeni rozpocząć nową rozgrywkę, aby ten pojawił się w grze. Każdy przedmiot, mutant, pojazd, anomalia, NPC etc. - dodany do pliku alife_*.ltx (* - nazwa mapy) jest ingerencją w liczbę obiektów zawartych w pliku all.spawn. Konsekwencją owej ingerencji jest konieczność rozpoczynania nowej gry w celu zespawnowania przedmiotu. Jeśli nawet uzupełnimy plik all.spawn o nowy przedmiot, zaś przerobiony plik umieścimy w folderze gamedata zgodnie ze ścieżką, ale nie zaczniemy nowej gry - lecz wczytamy dowolny savegame, wówczas dodany przedmiot nie zostanie zespawnowany, co wynika z ograniczeń silnika X-Ray. Dlatego chcąc korzystać z wcześniej utworzonych zapisów gry i jednocześnie pozostawić sobie możliwość modyfikacji gry o dodanie nowych postaci, przedmiotów, mutantów - musimy ominąć modyfikację wewnętrznej struktury pliku all.spawn (mowa o pod-plikach alife_*.ltx, powstałych po dekompilacji spawn'a). Plik all.spawn dzieli się na pod-pliki: alife_*.ltx oraz way_*.ltx. Te drugie odpowiedzialne są za ścieżki tras patrolowych, centra obozowisk, kierunki patrzenia NPC, etc. Wspomniany zakres funkcji pod-pliku way_*.ltx reprezentują punkty (waypoint'y). Piszę o tym nie bez kozery, otóż plik all.spawn można modyfikować dodając punkty do pod-plików way_*.ltx z jednoczesnym zachowaniem możliwości wykorzystania go po edycji - do wcześniej utworzonych zapisów gry. Innymi słowy - dodając waypoint do spawn'a nie musimy rozpoczynać nowej gry, ponieważ nie zmienia się liczba przedmiotów. Jest to znamienne w kontekście możliwości stosowania niniejszej metody, która również ma swoje ograniczenia dot. smart_terrain'a. Prócz samej konfiguracji mutanta, ważne jest stworzenie dlań smart_terrain'a bez którego utworzony potwór będzie swobodnie przemieszczał się po mapie. Czasami takie rozwiązanie ma swoje zalety, jednakże szybko może zostać uśmiercony przez anomalię, innego mutanta tudzież stalkerów, że nie wspomnę o szukaniu części ciał potwora, które stanowić mogą przedmiot zadania - jeśli takowe stworzymy. Dodając mutantowi smart_terrain - tworzymy obszar do którego przypisany jest nasz mutant, realizując określone zadanie w jego obrębie. Ograniczenie owej metody, o którym wspomniałem powyżej jest zależne od możliwości edycji/dekompilacji pliku all.spawn w strukturze way_*.ltx. Są mody jak np. Solijanka, w których plik all.spawn został zmodyfikowany xrSpawner'em, wówczas jego dekompilacja jest niemożliwa, mało tego - ograniczenia edycyjne narzędzia jakim jest xrSpawner - są determinujące dla możliwości dodawania waypoint'ów. Konkludując - metoda skryptowego tworzenia smart_terrain'a stanowiąca uzupełnienie konfiguracji mutanta o dodanie legowiska, ma zastosowanie w każdym modzie do Shoc (jak i wersji vanillowej) w którym możliwe jest dodanie waypoint'u do pod-plików way_*.ltx. Sama konfiguracja rozumiana jako zdefiniowanie mutanta - jest uniwersalna dla każdej z modyfikacji ("Cień Czarnobyla"). Wspomniane ograniczenie wiąże się jedynie ze smart terrain'em, nie zaś całością niniejszego opracowania. Metoda nawiązuje do tego poradnika, opisującego skryptowy spawn NPC - stanowiący uzupełnienie świata Zony o postacie.

Poradnik inspirowany rozwiązaniami wykorzystanymi w Solijance.

 

Zalety obranej metody:
możliwość dodania mutanta w dowolnym momencie fabuły.
możliwość zasiedlania pustych lokacji.
możliwość tworzenia zadań opierających się o nowe potwory.
możliwość skryptowego spawnu warunków imitujących smart_terrain (utrzymywanie pozycji przez mutanta).
możliwość zmiany wielkości obszaru stanowiącego teren legowiska z poziomu pliku .ltx (smart_terrain bypass)
zastąpienie smart_terraina skryptem spełniającym podobną funkcję, skracającym czas przygotowania modyfikacji.

Wady:
w przypadku edycji pliku all.spawn - xrSpawner'em, tracimy możliwość dodania waypoint'u, koniecznego dla prawidłowej funkcjonalności smart_terrain'a.

 

Poradnik przygotowałem w oparciu o unikalny model mutanta - Zanozę, który możemy znaleźć pod  tym linkiem.
Twórcą oryginalnego modelu jest "Goroff", który wydał wersję pod CoP. Autorem konwersji pod Shoc jest "Modoskea".

Szczegółowy opis zawiera plik Заноза.txt, dostępny w archiwum zanozasoc.rar. Podane poniżej configi są już mojego autorstwa.

 

 

 

I. Etap przygotowawczy:

Ustalenie miejsca spawnu mutantów oraz położenia legowiska (4 punkty).
W przykładzie zespawnuję 3 mutanty zlokalizowane w pobliżu skupiska anomalii na płn-zach. od wioski kotów na Kordonie. W tym celu skorzystam z narzędzia "Smartterrain and Waypoint Tools by dez0wave", dostępnego pod tym linkiem i omówionego tutaj.

 

Poniżej wyciąg koordynatów z loga:

! Unknown command:  patrolName=camp_point|pos=-203.69958496094,-7.131486415863,-30.930252075195|game=69|level=49271* współrzędne centralnego punktu legowiska! Unknown command:  patrolName=zanoza_1|pos=-204.54653930664,-6.6603112220764,-25.652559280396|game=69|level=48633* współrzędne pierwszego mutanta! Unknown command:  patrolName=zanoza_2|pos=-192.31311035156,-6.034996509552,-34.309532165527|game=69|level=59351* współrzędne drugiego mutanta! Unknown command:  patrolName=zanoza_3|pos=-193.60884094238,-6.2782773971558,-43.94458770752|game=68|level=58068* współrzędne trzeciego mutanta

 

Jeśli chcemy skorzystać z innych metod pozyskiwania współrzędnych, pod tym linkiem, w pkt. I etapu przygotowawczego, zawarłem szereg przydatnych metod dot. omawianej kwestii koordynatów spawnu.

 

 

II. Etap wykonawczy:

Tworzenie struktury moda oraz edycja plików.
W pierwszej kolejności zajmiemy się konfiguracją mutanta, która prawidłowo wykonana jest gwarantem poprawnego działania modyfikacji. Pamiętajmy, jednak o jednym fakcie, otóż każdy ma obowiązek właściwej adaptacji plików pod swoją wersję moda.

 

O mutantach słów kilka...(nie dotyczy właściwej części wykonawczej)
Sam mutant stanowiący przykład do opisania metody - został stworzony w oparciu o mięsacza. Otóż wspominam o tym fakcie z uwagi trudność tworzenia animacji ruchu dla nowej postaci czy potwora. Modderzy - by ułatwić sobie pracę, tworzą modele w oparciu o istniejące - posiłkując się gotowymi animacjami, których nie ma potrzeby dodawać. Przykłady? - ależ proszę:
a). Bibliotekarz, którego mamy okazję spotkać w Solijance - wykonano w oparciu o plik m_fracture.ltx [lokalizacja: gamedataconfigcreatures], który odpowiada za konfigurację Połamańca. Wystarczy odszukać sekcję:

[bibliotekar]:fracture_strong

jak również jego frakcyjną przynależność:

community            = fracture

b). Karaluch, spotykany również w Solijance, wykonany w oparciu o plik m_tushkano.ltx [lokalizacja: gamedataconfigcreatures], odpowiadający za Rodenta znanego w vanillowym Shoc.
Jeśli są wątpliwości co do powyższego stwierdzenia, odszukajmy sekcję:

[tarakan_normal]:tushkano_normal

jak również frakcyjną przynależność:

community            = tushkano

W/w mutanty stanowiły w owym czasie (wydanie Solijanki 2009 r.) - novum, jednakże opierały się na configach już istniejących - w wersji zmodyfikowanej dla danego mutanta.
Każdy dobry, podkreślam - dobry modder, tworząc unikalny model mutanta powinien dołączyć do niego prócz tekstury, również plik konfigurujący jego cechy. Jeśli pobrany model nie posiada configu, starajmy się odszukać go w modzie wprowadzającym szukanego mutanta.

 

Struktura modyfikacji w postaci graficznej:

 

 

[ 1 ]. Tworzymy config mutanta. Do pliku m_flesh.ltx [lokalizacja: gamedataconfigcreatures] z uwagi na proweniencję wykorzystanej animacji w modelu, dodaję wpis następujący (w dolnej części pliku) - zapisując zmiany:

; Zanoza - sekcja nowego mutanta.; Zanoza posiada animacje wykonane w oparciu o mięsacza, stąd wpis w pliku m_flesh.ltx[zanoza]: flesh_strong$spawn			   = "monstersflesheszanoza"	 ; ustawiamy zgodnie z definiowanym identyfikatorem mutanta.visual			   = monsterszanozazanoza	    ; ścieżka do modelu .ogfcorpse_visual	    = monsterszanozazanoza_dead   ; ścieżka do modelu zwłok mutantaicon				 = ui_npc_monster_zanoza		 ; ikona mutanta (PDA-encyklopedia, przeglądanie zwłok)panic_threshold	  = 0.0						   ; współczynnik panikirank				 = 0							 ; rankingimmunities_sect	  = zanoza_immunities			 ; sekcja odporności mutanta - wiersz nr.18attack_params	    = zanoza_attack_params		  ; przyporządkowanie zakresu obrażeń - wiersz nr. 31spec_rank		    = strong					    ; odmiana mutanta zgodna z pierwszą linijką configu!			    community		    = flesh						 ; przynależność mutanta, flesh - mięsacz, plik game_relations.ltx; poniżej - sekcja odporności mutanta.; Wartości = 0 odpowiadają 100%-owej odporności na dany czynnik.; Wartość = 1 odpowiada za brak odporności.[zanoza_immunities]burn_immunity		    = 0.01					  ; odporność na ogieństrike_immunity		  = 0.001					 ; odporność na uderzenieshock_immunity		   = 0.7					   ; odporność na porażenie prądemwound_immunity		   = 0.1					   ; odporność na zadrapanieradiation_immunity	   = 0.0					   ; odporność na radiacjętelepatic_immunity	   = 0.0					   ; odporność na telepatięchemical_burn_immunity   = 0.1					   ; odporność na oparzenie chemiczneexplosion_immunity	   = 0.1					   ; odporność na wybuchy (np. granaty, RPG-7, Vog-25 etc.)fire_wound_immunity	  = 0.001					 ; odporność na ostrzał; poniższa tabela jest zestawieniem zakresu obrażeń otrzymywanych od mutanta - w zależności od sposobu ataku.; sekcja jest uproszczona do:  stand_attack_0, stand_attack_1, stand_attack_2, stand_attack_3.[zanoza_attack_params];---------------------------------------------------------------------------------------------------------------------------------------------;    anim		  | time[0..1] | hit_power | impulse | impulse_dir (x,y,z) | Field of hit_test   |    Test Dist;---------------------------------------------------------------------------------------------------------------------------------------------;Left leg strikestand_attack_0 =	 0.25,	  1.9,		  300,	   0.0, 0.5, 1.0,	   -1.0, 1.0, -1.0, 1.0,		 2.0;Both leg strikestand_attack_1 =	 0.30,	  1.9,		  250,	   0.0, 0.5, 1.0,	   -1.0, 1.0, -1.0, 1.0,		 2.5stand_attack_2 =	 0.30,	  1.9,		  250,	   0.0, 0.5, 1.0,	   -1.0, 1.0, -1.0, 1.0,		 2.5stand_attack_3 =	 0.40,	  1.9,		  250,	   0.0, 0.5, 1.0,	   -1.0, 1.0, -1.0, 1.0,		 2.5; hit_power - parametr siły uderzenia proporcjonalny do zadanej wartości.

Ponieważ sekcja potwora jest oparta na uprzednio zdefiniowanej "flesh_strong" - patrz [zanoza]: flesh_strong, definiujemy tylko część parametrów, które mają wyróżniać mutanta. Powyższy config nie został skonfigurowany o nowy przedmiot znajdywany po zabiciu mutanta z uwagi na brak adekwatnego modelu części ciała. Z obecną konfiguracją w ciele potwora znajdziemy oko mięsacza.

Utworzony "config" zawiera opis parametrów w postaci komentarza - radzę zapoznać się z zawartością.
Na dodatkowe słowo opisu zasługuje fakt zmiany nazwy modelu, który pobrany w oryginale - podmieniał model mięsacza w wersji "strong" na Zanozę. Chcąc zachować wspomnianą odmianę mięsacza - warto zdefiniować własną nazwę dla modelu.
Pierwotna nazwa modeli: flesh_strong.ogf oraz flesh_strong_dead.ogf, zmienione na odpowiednio: zanoza.ogf i zanoza_dead.ogf (patrz parametry configu: visual oraz corpse_visual). Warto również wspomnieć o nowej ikonie - stworzonej na potrzeby wprowadzenia informacji do encyklopedii nt. mutanta - parametr: icon - opis pkt. 4
Pobrany model posiadał już config, jednakże chcąc nadać unikalne cechy mutantowi - zmieniłem wartości zarówno dla sekcji odpowiedzialnej za odporność mutanta: [zanoza_immunities] jak również siłę zadawanych obrażeń : [zanoza_attack_params].
Utworzony mutant posiada dźwięki zdefiniowane dla mięsacza. Chcąc dodać własne - unikalne odgłosy, musimy dodać do configu mutanta w sekcji: Sounds and sound parameters - właściwe pliki dźwiękowe, z komentarzem w pliku .ogg - przydatny tutorial: link.
Bez komentarza w pliku .ogg, interakcja AI mutanta ze światem gry nie będzie prawidłowa!

 

[ 2 ]. Zgodnie z wprowadzonymi parametrami, dodaję modele wg. ścieżki określonej w: visual oraz corpse_visual, tj. zanoza.ogf i zanoza_dead.ogf - umieszczam w gamedatameshesmonsterszanoza. Pamiętajmy, iż ścieżki do modelu .ogf zawarte w configu, nie zawierają w nazwie folderów: gamedata i meshes - są one jednak obowiązkowe!

 

[ 3 ]. Model posiada przypisaną teksturę, określoną wewnętrznie. Pobrany mutant miał już utworzony folder z teksturami: act_zanoza.dds oraz act_zanoza_bump.dds, które docelowo powinny się znaleźć w: gamedatatexturesact (dla tego konkretnego przypadku!). Jeśli brakuje potrzebnych folderów - tworzymy je zgodnie ze ścieżkami określonymi w modelu. Jeśli dojdzie do sytuacji, iż pobrany model nie będzie miał utworzonego folderu na teksturą - jej lokalizację można odszukać posiłkując się tym poradnikiem: link.

 

[ 4 ]. Zgodnie z parametrem configu: "icon", dodaję do pliku tekstur mutantów tj. ui_npc_monster.dds [lokalizacja: gamedatatexturesui] - właściwą ikonę potwora, którą muszę utworzyć. Przydatny w tworzeniu ikon może okazać się ten poradnik - Tworzenie ikon przedmiotów.

 

[ 5 ]. Następnym krokiem jest właściwa konfiguracja ikony w siatce współrzędnych pliku .dds. Plikiem odpowiedzialnym za zdefiniowanie położenia ikon mutantów jest - ui_npc_monster.xml [lokalizacja: gamedataconfigui], zatem dodaję do niego sekcję:

<texture id="ui_npc_monster_zanoza" x="1" y="430" width="325" height="210" />

Fraza "ui_npc_monster_zanoza" jest określona w parametrze configu "icon", patrz config w pkt. 1
Należy mieć na uwadze fakt, iż standardowo ikony mają rozmiar: 165 px (szer.) x 108 px (wys.), jednakże wartości w/w nie są obligatoryjne. W moim przypadku stworzyłem ikonę 4-krotnie większą (na potrzeby przeglądania ekwipunku - po zabiciu mutanta zostanie przeskalowana przez silnik gry - patrz film).

Interpretacja wartości:
Powyższy wpis oznacza odczyt ikony z przesunięciem 1 piksela od osi X (lewa strona pliku ikon) oraz 430 pikseli od osi Y (wartość mierzona od górnej części pliku do górnej krawędzi ikony) na polu o wartości 325 px x 210 px. W tym zadanym zakresie gra odczytuje ikonę z pliku .dds. Obrazowo sytuację przedstawia poniższy screen. Ponieważ Solijanka posiada duże pliki ikon, wykorzystałem plik ikon postaci w przykładzie, zachowując jednak nazwę właściwą dla ikon mutantów: ui_npc_monster.dds

 

 

Do ustalenia położenia ikony oraz edycji pliku ui_npc_monster.dds, wykorzystałem program Gimp 2.8.

Jak widać na screen'ie - za pomocą podziałki możemy ustalić rozmiar oraz położenie ikony. Przy ustalaniu parametrów można wywołać siatkę o rozmiarze oczka 10 x 10 px, lub mniejszą by z łatwością zebrać potrzebne wartości dla pliku ui_npc_monster.xml. Pamiętajmy - wartości powyżej opisane stanowią tylko przykład dla potrzeb tego poradnika i tej konkretnej ikony!. Chcąc utworzyć dużą ikonę warto powiększyć rozmiary pliku ui_npc_monster.dds, zachowując jednak pierwotne położenie ikon już istniejących.

 

[ 6 ]. Następnym krokiem jest wprowadzenie informacji o naszym mutancie do encyklopedi w PDA.
Do pliku encyclopedia_mutants.xml [lokalizacja: gamedataconfiggameplay] dodaję wpis poniższy:

    <!-------------------------------- Zanoza ----------------------------->    <article id="mutant_zanoza" name="zanoza" group="Mutants">	    <texture>ui_npc_monster_zanoza</texture>	    <text>enc_mutant_zanoza</text>    </article>        <!-------------------------------- Zanoza ----------------------------->

 

Odpowiada on za wzajemne połączenie id notatki opisującej mutanta z ikoną umieszczoną w PDA oraz opisem.

 

[ 7 ]. Za pojawienie się opisu mutanta w PDA odpowiada dodanie określonego infoportion. Ja w przykładzie wykorzystałem prosty dialog z Wilkiem dla ukazania samego sposobu aktywacji. Tworzę infoportion - dodając do pliku info_l01escape.xml [lokalizacja: gamedataconfiggameplay] wpis:

    <!-- Zanoza infoportion -->    <info_portion id="zanoza_info_start">        <article>mutant_zanoza</article>    </info_portion>    <!-- Zanoza infoportion -->

 

wykorzystuję plik info_l01escape.xml, ponieważ postać oferująca dialog jest zespawnowana na Kordonie (l01escape). Dla postaci na innych lokacjach należy znaleźć odpowiedni plik - ścieżka j/w.

 

[ 8 ]. Jak wspomniałem - dla testów wykorzystałem postać Wilka, zatem wprowadzam dialog odpowiedzialny zarówno za spawn mutantów jak i dodanie infoportion. Do pliku definiującego cechy postaci tj. character_desc_escape.xml (dla Kordonu), do sekcji Wilka tj. [specific_character id="esc_wolf] dodaję nowy dialog :

<actor_dialog>spawn_dialog</actor_dialog>

 

[ 9 ]. Następnie tworzę drzewo dialogowe o identyfikatorze ("dialog id") j/w czyli "spawn_dialog". Do pliku dialogs_escape.xml [lokalizacja: gamedataconfiggameplay] odpowiedzialnego za konstrukcję dialogu z Kordonu dodaję wpis:

      <dialog id="spawn_dialog">	    <phrase_list>		    <phrase id="0">			    <text>spawn_dialog_0</text>	    <next>1</next>		    </phrase>		    <phrase id="1">			    <text>spawn_dialog_1</text>                <give_info>zanoza_info_start</give_info>			    <action>zanoza.spawn_zanoza</action>	    <next>2</next>		    </phrase>		    <phrase id="2">			    <text>spawn_dialog_2</text>			    <action>dialogs.break_dialog</action>		    </phrase>	    </phrase_list>    </dialog>

gdzie:

spawn_dialog_0, spawn_dialog_1, spawn_dialog_2 - są odnośnikami do tekstu spolszczenia.  

<give_info>zanoza_info_start</give_info>

w/w wpis odpowiada za dodanie infoportion "zanoza_info_start" utworzonego w pkt. 7 (informacja o mutancie zostaje dodana do PDA w toku rozmowy).

<action>zanoza.spawn_zanoza</action>

w/w wpis odpowiada za aktywację funkcji "spawn_zanoza" zawartej w pliku zanoza.script [gamedatascripts] - plik opisany w pkt.12

<action>dialogs.break_dialog</action>

ucięcie dialogu realizowane funkcją "break_dialog" zawartą w pliku dialogs.script
Uwaga: powyższy dialog stanowi wersję uproszczoną, ponieważ nie zawiera dodatkowych wpisów warunkujących jego pojawienie, mających stanowić formę zabezpieczenia przed powtarzaniem tej samej kwestii dialogowej. Dialog jest jedynie sposobem wywołania funkcji oraz informacji w PDA - nie powinien się powtarzać dla tych samych warunków tj. te same współrzędne spawnu mutantów już istniejących. Spawn w ten sposób realizowany powinien odbywać się w sytuacji uśmiercenia jednostek wcześniej utworzonych - eliminacja obozu. Po szczegółowe informacje nt. infoportion'ów zapraszam tutaj - link.

 

[ 10 ]. Następnym krokiem jest uzupełnienie drzewa dialogowego utworzonego w pkt. 9 oraz opisu do encyklopedii.
Wpierw zajmiemy się dialogiem dla Wilka, otóż do pliku stable_dialogs_escape.xml [lokalizacja: gamedataconfigtextpol] dodaję opis:

    <string id="spawn_dialog_0">	    <text>Cześć Wilk, idę sprawdzić doniesienia o nowym legowisku mutantów.</text>    </string>    <string id="spawn_dialog_1">	    <text>Zdaj raport jak coś znajdziesz. Ostatnie informacje mówią o atakach na północny-zachód od naszej wioski - %c[255,255,1,1]w pobliżu dużej koncentracji anomalii.</text>    </string>    <string id="spawn_dialog_2">	    <text>W porządku.</text>    </string>

 

gdzie:  
spawn_dialog_0, spawn_dialog_1, spawn_dialog_2 - są odnośnikami zdefiniowanymi w pkt. 9, odpowiedzialnymi za poszczególne kwestie dialogowe. Pamiętajmy iż plik stable_dialogs_escape.xml odpowiada za dialogi z Kordonu, dla innych lokacji musimy dobrać właściwy im plik spolszczenia!

 

[ 11 ]. W pliku string_table_enc_mutants.xml [lokalizacja: gamedataconfigtextpol] - odpowiedzialnym za opis mutantów w PDA, dodaję opis Zanozy. Oczywiście - tutaj mamy dowolność tworzenia i modyfikacji tekstu w zależności jakiego mutanta opisujemy.

    <string id="zanoza">        <text>Zanoza</text>    </string>   	 <string id="enc_mutant_zanoza">        <text>Rzadki mutant stanowiący doskonały przykład adaptacji organizmu żywego do warunków otoczenia - z uwagi na kształt przypominający konary drzew lub gałęzie, które w połączeniu z umiejętnością pozostawania w bezruchu - stanowią idealny kamuflaż komponujący się z przyrodą Zony. Opowieści stalkerów w które wielu dotychczas powątpiewało - donoszą o "żywych konarach" atakujących nieświadomych obecności mutanta - eksploratorów. Bezpośrednia konfrontacja z potworem kończy się śmiercią, są jednak świadkowie tychże ataków, opisujący nieznany dotychczas typ zagrożenia jakim jest rzeczony mutant. Informacje dotychczas zebrane jednoznacznie wskazują na fakt, iż broń palna jest nieskuteczna w walce z opisywanym stworem. Istnieje niepotwierdzona informacja wg. której mutant ten jest %c[255,255,1,1]nieodporny na wyładowania elektryczne%c[default], co potwierdzać ma jedna z opowieści, mówiąca iż ratujący się przed Zanozą stalker wprowadził ją na "Elektro", która uśmierciła wyładowaniem stwora. Warto odnotować to w PDA, wybierając ekwipunek adekwatny do słabych punktów mutanta.n        n%c[255,1,255,255] Zdrowie:%c[255,1,255,1]2000 (200 x NPC health)n%c[255,1,255,255] Szybkość:%c[255,1,255,1](do 4 m/s)n%c[255,1,255,255] Waga:%c[255,1,255,1] brak danychn%c[255,1,255,255] Atak: fizyczny, typ%c[255,1,255,1] "uderzenie"n%c[255,1,255,255] Odporność%c[255,1,255,1] -n%c[255,1,255,255] Oparzenie:%c[255,1,255,1] 70%n%c[255,1,255,255] Uderzenie:%c[255,1,255,1] 99,9%n%c[255,1,255,255] Porażenie prądem:%c[255,255,1,1] 30%n%c[255,1,255,255] Rozerwanie:%c[255,1,255,1] 90%n%c[255,1,255,255] Promieniowanie:%c[255,1,255,1] 100%n%c[255,1,255,255] Telepatia:%c[255,1,255,1] 100%n%c[255,1,255,255] Chem. oparzenie:%c[255,1,255,1] 90%n%c[255,1,255,255] Wybuch:%c[255,1,255,1] 90%n%c[255,1,255,255] Kuloodporność:%c[255,1,255,1] 99,95%</text>    </string>

 

Edycja tekstu w PDA.

Warto zwrócić uwagę na zmianę koloru tekstu, osiągalną pod dodaniu przed zdaniem/frazą przedrostka:
%c[255,255,1,1] - odpowiedzialnego za czerwony kolor tekstu.
%c[255,1,255,255] - odpowiedzialnego za błękitny kolor tekstu.
%c[255,1,255,1] - odpowiedzialnego za zielony kolor tekstu.
%c[default] - jest odpowiedzialny za przywrócenie koloru defaultowego, np. gdy chcemy wyróżnić frazę wewnątrz zdania.
n - oznacza, iż tekst przenoszony jest do nowego wiersza.
string id="enc_mutant_zanoza" - identyfikator tekstu spolszczenia, utworzony w pkt. 6

<text>Zanoza</text>

w/w wiersz odpowiada za nazwę mutanta w PDA.

 

 

[ 12 ]. Tworzymy plik skryptu odpowiedzialny za funkcję spawnu i utrzymywania stałej pozycji. W folderze skryptów: gamedatascripts, tworzę plik o nazwie zanoza.script .Nazwa wcześniej została użyta w drzewie dialogowym - pkt. 9 w sekcji:

<action>zanoza.spawn_zanoza</action>

przy czym - nie podaje się rozszerzenia pliku. Mówimy o frazie "zanoza" oddzielonej kropką od funkcji w tymże wpisie.
Pamiętajmy by tworząc nazwę zachować zgodność nazw w utworzonych wcześniej plikach, odpowiedzialnych za aktywację funkcji!

Abstrahując od w/w - w pliku zanoza.script tworzę następujące funkcje:

--funkcja spawnu 3 mutantówfunction spawn_zanoza()local obj =alife():create("zanoza",vector():set(-204.54653930664,-6.6603112220764,-25.652559280396),48633,69)local params=xrs_utils.read_monster_params(obj)params.custom="[logic]ncfg = scriptstest_zanoza_logic.ltx"xrs_utils.write_monster_params(params,obj)local obj =alife():create("zanoza",vector():set(-192.31311035156,-6.034996509552,-34.309532165527),59351,69)local params=xrs_utils.read_monster_params(obj)params.custom="[logic]ncfg = scriptstest_zanoza_logic.ltx"xrs_utils.write_monster_params(params,obj)local obj =alife():create("zanoza",vector():set(-193.60884094238,-6.2782773971558,-43.94458770752),58068,68)local params=xrs_utils.read_monster_params(obj)params.custom="[logic]ncfg = scriptstest_zanoza_logic.ltx"xrs_utils.write_monster_params(params,obj)end

 

gdzie:
□ "zanoza" - id naszego mutanta, patrz config w pkt. 1
Koordynaty odpowiednio w skrypcie:

X: -204.54653930664Y: -6.6603112220764Z: -25.652559280396level_vertex_id: 48633game_vertex_id: 69

pozostałe koordynaty analogicznie do w/w przykładu.

"[logic]ncfg = scriptstest_zanoza_logic.ltx"

powyższy wiersz definiuje plik konfiguracyjny legowisko mutantów [lokalizacja: gamedataconfigscripts], zawierając odniesienie do punktu (waypoint) dodanego w strukturze way_*.ltx - opis pkt.14
Wpisy: read_monster_params(obj) oraz write_monster_params(params,obj) są bardzo ważne w kontekście możliwości utrzymywania stałej pozycji przez mutanta. Dzięki skryptowi xrs_utils.script (opis pkt. 13) nie musimy tworzyć smart_terraina, bowiem wspomniane funkcje realizują podobne jak wspomniany obiekt - zadanie, dzięki czemu mutanty posiadają legowisko. Jeśli wykorzystujemy mody na bazie kodu AMK, wówczas wpisy:

xrs_utils.read_monster_params(obj) oraz xrs_utils.write_monster_params(params,obj)

możemy zastąpić:

amk.read_monster_params(obj) oraz amk.write_monster_params(params,obj)

 

ponieważ skrypt amk.script posiada te same funkcje co wspomniany xrs_utils.script. Edytując mody z kodem AMK, mamy dowolność wyboru. Analizując skrypty z Solijanki, udało mi się znaleźć skrypt spełniający podobną rolę w kontekście wykorzystanych funkcji, dzięki czemu możliwe jest przeniesienie unikalnych rozwiązań na grunt pozbawiony rozbudowanego kodu AMK, np. pod Shoc 1.0004
Uwagi dot. modów z kodem AMK:
warto sprawdzić rozwiązania skryptowe zawarte w pliku new_spawn.script, który znaleźć można w modzie Solijanka/DMX [gamedatascripts].

 

[ 13 ]. Do folderu skryptów [gamedatascripts] kopiuję plik xrs_utils.script. Jest on wykorzystywany w funkcji utworzonej w pkt. 12 i niezbędny do prawidłowego funkcjonowania warunków przypominających smart_terrain.

xrs_utils.rar

Zawartość pliku znajdziemy również w tym poradniku - link, pkt. 1
Jeśli w naszym modzie istnieje ów plik, sprawdźmy czy zawiera funkcje: "read_monster_params" oraz "write_monster_params" - jeśli tak, sprawdźmy czy zostały zmodyfikowane by wykluczyć ewentualność niewłaściwego działania funkcji, która w postaci podanej w załączniku nie powoduje błędów (sprawdzono wielokrotnie).

 

[ 14 ]. Tworzymy plik test_zanoza_logic.ltx zgodnie ze ścieżką: gamedataconfigscripts (nie mylić z folderem skryptów!). Nazwa pliku jest zależna od wpisu w funkcji opisanej w pkt. 12.
Zmieniając nazwę pliku - nie zapomnijmy o edytowaniu skryptu, aby korzystał z właściwego configu legowiska.
Do pliku test_zanoza_logic.ltx dodajemy wpis określający cechy obozowiska mutantów tj.

[smart_terrains]none = true[logic]active=mob_home@zanoza[mob_home@zanoza]path_home = esc_zanoza_homehome_min_radius = 10home_max_radius = 20

 

gdzie:
□ "active" odpowiada za wykorzystanie schematu "mob_home@zanoza"
□ path_home - jest ścieżką o identyfikatorze:  "esc_zanoza_home", którą należy dodać po właściwego pliku way_*.ltx (opis w pkt. 15)
□ home_min_radius oraz home_max_radius - minimalna oraz maksymalna wartość promienia, wyznaczająca zakres obszaru legowiska. Jak wspomniałem w zaletach na początku poradnika, z pozycji tegoż pliku możemy ją zmieniać. Optymalny zakres dla większości legowisk to 20 (min.) do 40 (max.) metrów.

 

[ 15 ]. Ostatnim plikiem jaki należy modyfikować - chcąc uzyskać warunki smart_terrain'a - jest all.spawn
Po procesie dekompilacji z użyciem ACDC - [link] modyfikujemy pod-plik way_l01_escape.ltx. Oczywiście wybór pliku zależny jest od lokacji na której dodajemy mutanty, w moim przykładzie - Kordon (Escape).

[esc_zanoza_home]points = p0p0:name = name00p0:position = -203.69958496094,-7.131486415863,-30.930252075195p0:game_vertex_id = 69p0:level_vertex_id = 49271

 

gdzie:
□ [esc_zanoza_home] - identyfikator punktu stanowiącego centralną część legowiska, zgodny z parametrem "path_home" - patrz pkt. 14. Po zapisaniu zmian i kompilacji, plik all.spawn umieszczamy w gamedataspawns.
Pomimo wprowadzeniu punktu o określonych współrzędnych do pliku w/w, nie trzeba rozpoczynać nowej gry. Jak widać na prezentacji poniżej - dodane mutanty utrzymują pozycję na zadanym w pliku: test_zanoza_logic.ltx - obszarze, o centralnym punkcie ustalonym w way_l01_escape.ltx.

Pełną funkcjonalność modyfikacji uzyskamy tylko wtedy, jeśli uda się nam dodać punkt do plików way_*.ltx!

 

Uwagi dodatkowe (dot. całkowicie nowych mutantów):
Jeśli mamy zamiar stworzyć smart_terrain typu "general_lair" - musimy uzupełnić jeszcze kilka plików. Opis znajdziemy w tym poradniku. Uzyskanie pełnej statystyki za zabicie mutanta wymaga uzupełnienia pliku xr_statistic.script. W moim przypadku statystyka jest już uzupełniona z uwagi na wykorzystany config mięsacza.
Szczegółowe informacje w związku z ustaleniem statystyk dla nowych jednostek - tutorial.

Poniżej prezentacja prawidłowo wykonanego configu i oskryptowania:

 

http://www.youtube.com/watch?v=YCH0fPB3sV8

 

 

 

Prawa autorskie na podstawie regulaminu, pkt.1.6. - The Emperor, wyłączność: StalkerTeam.

__________________________

Autor: The Emperor dla StalkerTeam