Skocz do zawartości

The Emperor

Zasłużony
  • Postów

    622
  • Dołączył

  • Ostatnia wizyta

  • Wygrane w rankingu

    57

Odpowiedzi opublikowane przez The Emperor

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

    Wady:
    Dołączona grafika 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:

     

    post-3466-0-93053500-1386259938_thumb.pn

     

    [ 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

     

    post-3466-0-49893500-1386261407_thumb.pn

     

    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.

     

    post-3466-0-21722100-1386264188_thumb.jp

     

    [ 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

    • Dodatnia 8
    • Za szczególną pomoc 1
  2. Witam,

    Szukam praktycznie niedostępnego w sieci serialu: "Gwiezdna Eskadra" (ang "Space: Above and Beyond"), do którego głosu użyczył nieżyjący już Lucjan Szołajski - niezrównany lektor. Sam serial swego czasu był emitowany na antenie TV Polsat, dziś krąży po sieci w wersji ze spolszczeniem kinowym, jednak zależy mi na wersji o której traktuje nazwa tematu. Wspomnianą wersję znaleźć można tutaj, jednakże ogranicza się do odcinka pilotowego. Jeśli ktoś otarł się o link do pełnej wersji serialu z w/w lektorem - proszę o informację.

  3. Nikt nie udzieli Ci jasnej odpowiedzi - każdy mod podmienia różne pliki. Musisz sprawdzić czy mod AA2 oraz dowolna modyfikacja z której korzystasz - posiadają te same pliki. Nie jestem zwolennikiem modów graficznych, stawiam na inny aspekt rozgrywki. Piszę o tym, ponieważ nie pobierałem AA2 i nie mam jego plików. Jeśli znajdziesz pliki o rozszerzeniu .script [lokalizacja: gamedatascripts], wówczas mod ingeruje skryptowo w mechanikę gry. Jeśli dojdzie do sytuacji, iż oba mody będą posiadały te same pliki - musisz je połączyć, dobrze w tym celu skorzystać z WinMerge, programu do wyszukiwania różnic w plikach i ich edycji. Robisz kopię plików i edytujesz metodycznie - folder za folderem. Jeśli mod jest rozbudowany - zrób listę folderów i odznaczaj zapisane zmiany, co pomoże uniknąć pominięcia plików.

    • Dodatnia 2
  4. Jest taka strona: Universal Cyrillic decoder - umożliwia ona dekodowanie takiej "sieczki" jak w przykładzie:

    ęîňîđîě ěóňŕíňű ńîáčđŕţňń

    Wystarczy wkleić tekst w pole: Paste here the text to be decoded przy ustawionym dekodowaniu:

    Expert: source encoding: windows-1251 displayed as: windows-1250. Po kliknięciu OK - tekst zostanie przekodowany (pole Output)

    na:

    котором мутанты собираютс

    Cyrylicę traktujesz Google Translatorem albo Bing Translatorem, lub czymkolwiek innym.

    • Dodatnia 1
  5. Ekwipunek zapisuje się w plikach z rozszerzeniem .sav, są to pliki zapisu gry - dlatego trudno je edytować z uwagi na możliwość błędów w rozgrywce.

    Jest jednak unpacker do plików .sav, znajdziesz go pod tym linkiem: download. Z opisu wynika, iż nadaje się do Shoc i CoP, ale nie miałem okazji ani potrzeby go testować - trudno mi więcej powiedzieć o jego możliwościach. Jeśli chcesz zacząć przygodę z moddingiem - polecam tę stronę.Zawiera ona mnóstwo przydatnych narzędzi do edycji gry, niestety - w języku rosyjskim.

    • Dodatnia 1
  6. Tak na forum dziękujemy za pomoc - przyznając wirtualne ruble kliknięciem na strzałkę, a wracając do twojego pytania:

    jaką mam pewność, że moje pliki, które zmienię będą mi zastępowały pliki z baz db?

    w katalogu z grą masz plik o nazwie: fsgame.ltx.

    Jeśli w pliku masz zmienioną linijkę:

    $game_data$           = false|     true|    $fs_root$|        gamedata

    na:

    $game_data$           = true|     true|    $fs_root$|        gamedata

    wówczas nadrzędną wartość dla gry mają pliki zawarte w katalogu gamedata. To co umieścisz w gamedata - zachowując ścieżki i nazwy plików - będzie miało pierwszeństwo dla działania gry. Tak właśnie działają mody - Ty na tej samej zasadzie umieszczasz pliki zgodnie z ich ścieżkami, wpierw wypakuj wszystkie pliki .db (do jednego folderu), dzięki temu zyskasz dostęp do wszystkich plików gry.

    • Dodatnia 2
  7. Chwila kolego, zastanów się po co służy zielona strzałka w poście Dołączona grafika ? Poświęciłem czas, za Ciebie znalazłem plik, mało tego - napisałem skrypt...mam zatem prawo wymagać adekwatnej formy wdzięczności za informacje, bez których twój problem byłby nierozwiązany. Zastanów się dobrze - wówczas pogadamy...szkoda, że muszę upominać się o oczywiste sprawy, ale nic nie ma za darmo.

    • Dodatnia 1
  8. skrypt, zadziałał, misję mam zaliczoną

    i bardzo dobrze...już obawiałem się o brak kompatybilności.

    • pancerze znajdziesz w pliku outfit.ltx [lokalizacja: gamedataconfigmisc], identyfikator przedmiotu zawsze ujęty jest w nawias kwadratowy np. [novice_outfit]
    • bronie znajdziesz w folderze gamedataconfigweapons - jest tam szereg plików o wspólnej nazwie: w_*.ltx (* - nazwa broni np. w_mp5.ltx), jednak identyfikator znajduje się w pliku - dla podanego przykładu jest to [wpn_mp5] - nazwa w nawiasie kwadratowym.
    • przedmioty ogólne jak np. chleb, konserwa, wódka, antyrady - znajdziesz w pliku items.ltx [lokalizacja: gamedataconfigmisc] - nazwa również w nawiasach kw.
    • przedmioty unikatowe - zarówno bronie jak i kombinezony znajdziesz w pliku unique_items.ltx [lokalizacja: gamedataconfigmisc].

    Oczywiście - cały czas mówimy o "Cieniu Czarnobyla". Jak wypakować pliki gry? - noszą one rozszerzenie .db, przeczytaj ten temat. Możesz użyć tego unpackera. Fragment skryptu, który Cię interesuje w podesłanym pliku:

    if not db.actor:object("outfit_specnaz_m1") then     alife():create("outfit_specnaz_m1", db.actor:position(), db.actor:level_vertex_id(), db.actor:game_vertex_id(), db.actor:id())end

    wstawiasz poniżej funkcji:

    function actor_binder:update(delta)

    - jak w podanym pliku, sprawdź dokładnie położenie aby wstawić we właściwym fragmencie funkcji powyższy kod - inaczej spotkasz się w wypadem na pulpit.

    That's all...

    • Dodatnia 2
  9. @sk8boa

    Wersja 1.0000 to inwestycja w błędy gry, skoro jednak już grasz bez patcha,spróbuj tego:

    • w folderze gamedata, który powinieneś mieć z uwagi na mody o których pisałeś w poście nr. 9 - stwórz folder scripts.
    • do utworzonego folderu skopiuj ten plik: download (bind_stalker.script) - dostępność downloadu: 5 dni
    • uruchom grę - w ekwipunku powinien pojawić się pancerz.
    • zapisz grę z pancerzem w ekwipunku, wyjdź do windowsa i usuń plik.
    • kontynuuj grę bez pliku!

    Nie dam gwarancji, że gra zadziała - plik prawdopodobnie będzie kompatybilny (gamedata.db4), ale pewności nie mam. Jeśli masz już plik bind_stalker.script w folderze j/w - podeślij go do przeróbki.

    • Dodatnia 1
  10. Ale będzie też sporo pracy przy przenoszeniu plików pod CoP. Swoją drogą - Zew Prypeci jest znacznie stabilniejszy niż C-Sky, którego starałem się unikać w kwestii modowania. Dobrze jakbyś robił przenoszenie etapami - sprawdzając efekt, wówczas szybko wyłapiesz pewne błędy - jak chociażby ten z minimapą, co do której nie mam pomysłu na naprawę prawidłowego jej wyświetlania.

  11. W takim razie pomińmy wątek skryptów. Miałem nadzieję, że wgrałeś jakiś mod na HUD, który jednocześnie zawiera skrypty - i właśnie te skrypty chciałem sprawdzić pod kątem informacji o minimapie. Edytowałeś minimapę, może źle zapisałeś kanał alpha i brakuje przezroczystości? Najlepiej będzie przeanalizować ostatnio dodane pliki do twojego moda, innej rady niestety nie mogę dać.

  12. podstawową wersję angielską spolszczoną, bez żadnych patchy

    W takim razie nie jestem w stanie Ci pomóc, ponieważ na dysku mam pliki z Shoc 1.0004. Zalecaną dla gry wersją jest ta z patchami 1.0004 - 1.0005. Jeśli grasz bez patchy, które nota bene - są obowiązkowe dla prawidłowej rozgrywki, to wybacz, ale moja pomoc oznaczałaby konieczność wprowadzenia do gry pliku w wersji niedostosowanej do twojej rozgrywki, co mogłoby przełożyć się na poważniejsze błędy. Skorzystaj z porady w poście nr.5.

  13. Tworząc dialog nie osiągniesz zmiany frakcji, możesz jedynie aktywować skrypt, który umożliwi zmianę frakcji. Problem w tym, że nie spotkałem się z modem do CoP umożliwiającym zmianę ugrupowania (brak odpowiedniego skryptu), który jednocześnie nie ingerowałby w fabułę w znaczącym stopniu. Nawet jeśli zmienisz frakcję - to przy założeniu braku modyfikacji samej linii fabularnej gry - postać (Loki, Broda, Szulga, etc.) nie będzie oferować więcej dialogów, ponad te z oryginalnej wersji. Aby zmiana frakcji miała sens, musiałbyś stworzyć zadania oferowane po przyłączeniu do ugrupowania, a to z kolei stanowi ingerencję w dość znaczącym stopniu w fabułę, chyba że masz na myśli freeplay po ukończeniu głównej linii questów? Znam mod tylko pod Shoc na zmianę frakcji - "Faction Change And Reset" , ale nie liczyłbym na kompatybilność skryptu z CoP.

  14. Do jakiej wersji stalkera robisz modyfikację? Mapy nie miałem potrzeby modyfikować, ale wydaje mi się że plikiem/plikami za nią odpowiedzialnym jest zone_map.xml oraz zone_map_16.xml (dla monitorów panoramicznych). Trzeba by sprawdzić oryginalne pliki z wersją zmodyfikowaną. Podaj zawartość plików - oryginału i wersji zmodyfikowanej, może uda się coś ustalić...

  15. @sk8boa

    W podstawowym Shoc nie ma takiej opcji, by Łukasz miał ten kombinezon i jednocześnie zadanie było aktywne. Prawdopodobnie źle odczytujesz znacznik, który wskazuje na zleceniodawcę, zamiast posiadacza przedmiotu. Zadanie nie byłoby aktywne, gdyby Łukasz miał kombinezon. Odłożyłeś przedmiot i teraz nie pamiętasz gdzie...w Cieniu Czarnobyla stalkerzy nie okradają schowków, zatem powinieneś skupić się na odszukaniu przedmiotu.

    Leczący Beryl nosi identyfikator gry: outfit_specnaz_m1. Jeśli nie znajdziesz rzeczonego kombinezonu - zmień wynagrodzenie za wykonanie dowolnego questu zgodnie z tym poradnikiem - dodając pancerz o w/w identyfikatorze.

    reward_item = outfit_specnaz_m1

    P.S Zrób screen'a z zaznaczonym zadaniem i mapą ustawioną na quest.

  16. @umbrober2012 - jesteś pewny że to krew odpowiada za spadek płynności gry?

    W tej sytuacji zmniejsz efekt krwi. Znajdź plik system.ltx [lokalizacja: gamedataconfigs], przejdź do sekcji [bloody_marks] i zmień wartości na poniższe:

    dist            = 2.0max_size        = 0.3min_size        = 0.06nominal_hit     = 0.5

    sprawdź jakie masz wartości, ich zmniejszenie zminimalizuje efekt krwi.

  17. Z błędu wynika, iż zapotrzebowanie na pamięć dla aplikacji jest większe niż jej dostępność dla procesu, czyli "brak pamięci", który można rozwiązać poprzez zwiększenie pamięci wirtualnej do 4096 MB - link. Możesz również do skrótu na pulpicie dopisać parametr (ścieżka jest przykładowa):

    S.T.A.L.K.E.R. - Cień Czarnobylabinxr_3da.exe" -noprefetch

    Ewentualnie sprawdź jeszcze ten temat - link.

    • Dodatnia 1
×
×
  • Dodaj nową pozycję...

Powiadomienie o plikach cookie

Korzystając z tej strony, zgadzasz się na nasze Warunki użytkowania.