The Emperor

Długo mógłbym pisać o tym rewolwerze, ale to trzeba zobaczyć... https://www.youtube.com/watch?v=fAyXqU2q-CI Natknąłem się na w/w filmik ok. miesiąca temu - od tej pory bezskutecznie szukam tego modelu Colta a jest wyjątkowy. Autor moda Александрыч - nie daje informacji (tak przynajmniej wynika z opisu) gdzie można znaleźć ów model. Może ktoś z forumowiczów znalazł go w jakimś modzie do stalkera? Jeśli tak. to proszę o info, tylko jest mała uwaga z mojej strony, otóż istnieje podobny model Colt Python'a, udostępniony w tym temacie: link, ale posiada IMO znacznie gorsze animacje oraz brak addon'ów. Podaję również ten drugi model Colta aby nie było wątpliwości, że pomiędzy nimi są różnice. http://www.youtube.com/watch?v=zIxUVaFkQXw&feature=player_embedded Zależy mi tylko na modelu z 1 filmiku!

Mutant który doprowadzał mnie do furii, to Solijankowy karaluch: mały, szybki, trudny do trafienia, atakujący w grupie oraz odporny na ostrzał ze słabszej broni - bez shotguna lepiej darować sobie spotkanie z nim, ewentualnie granat małej mocy na dużą ich grupę załatwiał sprawę. Najbardziej irytujący jest fakt, że szybko potrafił pozbawić życia - zwłaszcza gdy miało się słaby pancerz i grało na mistrzu, mało tego - z zabicia większego okazu mutanta była uciecha, walcząc z godnym przeciwnikiem np. polując na chimerę (lub będąc zwierzyną w tym polowaniu) miało się satysfakcję z udanej walki - pomimo, iż marnowało się sporo amunicji, dobrze też płacono za pazur chimery. Karaluch natomiast jest - jak męczący komar: zero satysfakcji z wykończenia takiego okazu, zaś koszta amunicji czy zużytego na walce pancerza - wysokie. Mając gravityguna w końcowym etapie rozgrywki, używałem artefaktu to tworzenia anomalii grawitacyjnych i tak pozbywałem się irytujących karaluchów jednym strzałem - oh yeah...

@Hobby Plik olr sky.rar musisz wypakować do folderu gamedatatexturessky. Zastępujesz oryginalne pliki. Nie sprawdzałem tych tekstur, jeśli jednak nie będziesz z nich zadowolony - zanim zastąpisz pliki zrób kopię folderu sky, zawsze będziesz mógł go przywrócić.

Próbowałeś uruchomić jako administrator w trybie zgodności z XP? Szczerze mówiąc - oboje szukamy na oślep rozwiązania problemu, nie zaszkodzi jednak sprawdzić, ewentualnie przetestować grafikę na DX9.

Pobierz program stanowiący świetne uzupełnienie antywirusa - Malwarebytes, po zaktualizowaniu, włącz pełne skanowanie systemu - jeśli zostaną znalezione niebezpieczne elementy, program usunie je po zakończeniu operacji skanowania i zrestartowaniu systemu, o czym powiadomi stosowny komunikat. Program szczerze polecam.

Najlepiej będzie jak podasz loga - pomimo braku bugtrapów, ponieważ może zawierać informacje nt. błędów niekrytycznych, ale spowalniających grę. Plik loga wstaw na hosting lub w postaci załącznika. Jeśli w momencie pojawienia się błędu, zrestartujesz kompa - log może być pusty, więc przed wstawieniem go - sprawdź czy zawiera jakiekolwiek info. Tylko tak można będzie wykluczyć błędy wynikające z samej konstrukcji moda. Jeśli chodzi o optymalizację wydajności sprzętu, zawsze możesz w zależności od opcji oferowanej przez twój antywirus ustawić tryb gry lub nawet wyłączyć go całkowicie - na czas gry odłączając kabel sieciowy. Podstawowa kwestia - masz C-Sky na patchu 1.5.10 ? - pytam dla jasności sytuacji. Jeśli chodzi o wymagania, to podane przez Ciebie powinny w zupełności wystarczyć, chyba że w tle działa mnóstwo procesów obciążających rozgrywkę. Dobrym programem do optymalizacji jest ten program, wpierw trzeba ustalić co zawiera log. Koleżanka Nati odsyła do twórcy moda, ale pewny jestem że Smoq również o ów log poprosi, że o dxdiag (nie zaszkodzi jak podasz) - nie wspomnę.

@patryk38832 Niestety nie mam pomysłu jak należy zmienić skrypt, znalazłem jednak info o podobnym problemie jak twój: link. Forumowicze radzą aby emisję przeczekać w innej kryjówce.

Składam najlepsze życzenia: zdrowia, radości życia, pomyślności, spełnienia marzeń oraz wytrwałości w dążeniu do celu. Twoje urodziny są również okazją, aby podziękować Ci za wkład w rozwój Forum, za polonizacje bez których wiele modów pozostałoby nieodkrytych. 100 lat Metek!

W folderze levels znajdują się również tekstury - skoro mod jest graficzny, meshes - zmienia modele, być może zostały im przypisane nowe tekstury?. Jeśli chodzi o skrypty i configi - nie koniecznie muszą kolidować z plikami moda - foldery są co prawda te same, ale pliki mogą dotyczyć innych funkcji. Trzeba by sprawdzać foldery obu modów pod kątem występowania tych samych plików - zrobić ich listę a następnie łączyć. Nie widziałem tych modów, wiec trudno mi się wypowiadać. W pierwszej kolejności - trzeba porównać zawartości obu modyfikacji.

Jeśli Mystery 2.0 wprowadza zmiany tylko w grafice - można będzie połączyć mody. Mod powinien zawierać jedynie folder textures oraz plik który konfiguruje tekstury czyli textures.ltx. Nie powinien zawierać skryptów - chyba że zmienia pogodę, wówczas może zawierać skrypt, który ją reguluje. Musisz sprawdzić jakie foldery zawiera Mystery 2.0 - jeśli tylko tekstury? - wówczas można je będzie skopiować do katalogu moda i łączenia będzie wymagał w/w plik tekstur.

Być może ktoś posiada oficjalny Hud Ekipy do Solijanki? W tym temacie - link jest prośba o wznowienie tego linku, zamieszczonego tutaj.

Panowie, zgodnie z tym co mówiłem: [Tutorial]: Tworzenie stalkerskich obozów oraz dodawanie NPC do gry.

Tytułem wstępu... Poprzedni tutorial traktował o uproszczonej metodzie tworzenia obozowisk [general_lager] oraz [general_lair], w której korzystając z funkcji respawnu jednostek - skracaliśmy czas potrzebny na przygotowanie smart_terrain'a. Wadą tej metody był brak możliwości stworzenia (dla tego typu obozowiska) charakterystycznych postaci (z uwagi na losowy spawn NPC'ów), jak np. handlarze, zleceniodawcy, mechanicy etc., oraz długi czas respawnu. Ten poradnik przedstawia sposób umożliwiający tworzenie obozów znacznie bardziej rozbudowanych, w których wprowadzamy postacie zgodnie z naszym zamiarem, konfigurując poprzez odpowiednie pliki - ich cechy jak: wygląd, uzbrojenie, zachowanie (np. wartownik, zleceniodawca, snajper, handlarz etc.) oraz poprzez dodanie odpowiednich kwestii dialogowych - wprowadzając możliwość wykonywania zadań dla nowo utworzonych NPC'ów. Jest to metoda szczegółowa, ponieważ prócz budowy samego smart terrain'a narzuca wymóg konfiguracji wielu plików, bez których obozowisko nie będzie funkcjonować. Wpierw warto zapoznać się z początkową częścią tego poradnika (Link), dotyczącą opisu działania narzędzia "Smartterrain and Waypoint Tools by dez0wave" za pomocą którego będziemy wyznaczać współrzędne terenowe obiektów spawnowanych (koordynaty X,Y,Z, game_vertex_id, level_vertex_id), ścieżki patrolowe i kierunki widzenia NPC'ów. Omawiane powyżej narzędzie jest dostępne pod linkiem: http://sdk.stalker-game.com/en/images/d/d7/Smartterrain_and_Waypoint_Tools_by_dez0wave.zipGdyby doszło do sytuacji, iż podany link wygaśnie - dodaję załącznik z w/w narzędziem Smartterrain_and_Waypoint_Tools_by_dez0wave.zip Uwagi dot. tekstu ujętego w code I. Etap przygotowawczy. Moim zamiarem jest stworzenie obozowiska składającego się z 10 stalkerów, zlokalizowanych na starej stacji benzynowej na Zatonie. Zasada ogólna: na 1 jednostkę wprowadzaną do gry (NPC/mutant) należy zebrać min. 3 punkty terenowe. Zasada nie tyczy się jednostek patrolujących, dla których ilość zbieranych punktów jest zależna od długości oraz złożoności trasy. Warto uzmysłowić sobie ten fakt, ponieważ musimy zebrać odpowiednią ilość współrzędnych do określenia złożoności zadań, które zostaną przydzielone NPC'om w ramach przypisanego im smart terrain'a. Pomimo iż poradnik jest pod Cień Czarnobyla 1.0004, dodatkowe mapy wykorzystane w jego przygotowaniu pochodzą z modyfikacji wprowadzającej dodatkowe poziomy do gry: Stalker Map Pack volume 1 (SMP1) + with Addons (by Kostya), całość dostępna pod linkiem: http://www.amk-team.ru/forum/index.php?showtopic=5533&p=197946Punkty zebrane poniżej (spoilery) - wytyczone zostały na lokacji Zaton, jeśli chcemy stworzyć obozowisko na innej mapie - musimy obrać dla niej właściwe współrzędne, wspominam o tym - być może oczywistym fakcie - z uwagi na różny poziom zaawansowania adeptów moddingu stalkera. By zespawnować smart terrain, space restrictor oraz stalkerów, będę potrzebował następujących punktów terenowych (dla pliku alife_*.ltx): * - nazwa mapy Punkty zebrane w pobliżu bazy. Powyżej - wyciąg z loga zawierający koordynaty + opis dot. spawnowanych obiektów: Poniższy screen ilustruje zasadę zbierania potrzebnych współrzędnych dla jednostek niepatrolujących Kolejne punkty koordynatów (zebrane w spoiler) dotyczą konfiguracji ścieżek patrolowych, miejsc zajmowanych w obiekcie przez stalkerów, kierunków patrzenia NPC'ów (dla pliku way_*.ltx) □ dla strażnika potrzebujemy min. 3 pkt: zajmowanej pozycji oraz kierunek patrzenia (3 współrzędna to spawn - patrz wyciąg z loga powyżej) □ dla snajpera potrzebujemy min. 3 pkt: spawn, zajmowana pozycja oraz kierunek patrzenia. □ leader obozu będzie również potrzebował min. 3 pkt: spawn, pozycja zajmowana, kierunek patrzenia. Powyżej - szkic poglądowy obozowiska z naniesioną trasą patrolową. Trasa NPC omówiona została w pkt. 7 poradnika. Generalnie - stalkerzy, którzy stoją w jednej pozycji - nie wymagają wielu punktów do zdefiniowania ich zachowania, oczywiście ilość wprowadzonych punktów zależeć będzie od schematu wg. którego będzie się przemieszczał NPC. Możemy wprowadzić np. zmieniającego pozycję snajpera czy wędrującego leadera - decyzja należy do nas, warto jednak zacząć od prostych tras NPC'a, by wyrobić sobie sprawność tworzenia obozowisk, które wymagają wiele cierpliwości do moddera. Poniżej wyciąg z loga dot. współrzędnych zbieranych dla pliku way_*.ltx (w moim przykładzie plik: way_zaton.ltx uzyskany po dekompilacji all.spawn) II. Etap wykonawczy. Poszczególne punkty poradnika oraz wykaz potrzebnych plików ilustruje poniższy załącznik: Dekompilujemy plik all.spawn zgodnie z tym poradnikiem (Link), uzyskując interesujące nas pliki alife_*.ltx oraz way_*.ltx * - nazwa mapy. W zależności od miejsca dodawania smart terrain'a, wybieramy odpowiedni plik - w moim przykładzie tworzę obozowisko na Zatonie, dlatego korzystam z plików: □ alife_zaton.ltx □ way_zaton.ltxW pierwszej kolejności tworzę smart terrain dodając do pliku alife_zaton.ltx z zachowaniem odpowiedneiej numeracji (brak powtórzeń numeru obiektu) wpis następujący: Omówienie parametrów sekcji: □ [11627] - numer obiektu (warunek konieczny dotyczący wszystkich plików .ltx uzyskanych po dekompilacji: numery nie mogą się powtarzać!) □ section_name = smart_terrain - jest to wpis definiujący obiekt stanowiący obszar, w którym określone typy jednostek (NPC/mutanty) realizują zdefiniowane skryptem (gulag_*.script) zadania, innymi słowy - stalkerskie obozowisko. Jest to parametr niepodlegający edycji dla tego typu obiektu! □ name = zat_gas_station - jest to nazwa (dowolna) nowo utworzonego smart terrain'a. Ważna uwaga, występujący w name - wpis musi być powtórzony również w parametrze type, tzn. name = type Tworząc nowy smart terrain w odróżnieniu od general_lager (dla NPC) czy general_lair (dla mutantów), pamiętajmy by wpisy stojące przy omówionych parametrach były jednakowe! □ position - są to koordynaty spawnu naszego obiektu (X,Y,Z). □ direction - obrót obiektu, który z uwagi na sferyczny kształt smart terrain'a możemy ustawić na 0,0,0. Gdyby kształt obiektu był określony jako box (graniastosłup prawidłowy czworokątny) wówczas parametr direction miałby znaczenie. Ponieważ kształt smart terrain'a widać dopiero na etapie projektowania z użyciem SDK, możemy ułatwić sobie pracę poprzez ustanowienie kształtu sferycznego. □ game_vertex_id, level_vertex_id - punkty wierzchołkowe uzyskane dzięki Smartterrain and Waypoint Tools by dez0wave (zapis koordynatów w logu). □ distance - parametr którego zmiana podczas testowania nie wpłynęła znacząco na rozgrywkę. Zawsze parametr odległości zawieram w przedziale 10 do 20 jednostek. Jeśli tworząc smart terrain masz wątpliwości jakie wartości przyporządkować do distance, sprawdź poprzez analogię obozowiska pierwotnie zaimplementowane przez GSC w niemodowanym SHOC jako wzorce z pomocą których dobierzesz wartości adekwatne do tworzonego smart terrain'a. □ type - zgodnie z tym co wcześniej pisałem, typ smart terrain'a jest równy wpisowi w name i tej zasady należy się bezwzględnie trzymać tworząc obozowisko stalkerów o unikalnych cechach - bez losowego udziału spawn'a NPC/mutantów. □ capacity - ilość obsługiwanych przez smart terrain NPC lub mutantów. □ groups, squad - są parametrami opcjonalnymi, przy ich doborze kieruję się wzorcami istniejących już smart terrain'ów. np. esc_lager (smart terrain wioski nowicjuszy z Kordonu - patrz plik alife_l01_escape.ltx), ponieważ wartości powyższe nie wpływają na pracę jednostek obsługiwanych przez smart terrain. Jeśli parametrów tych nie zdefiniujemy - gra ustawi wartości defaultowe. □ shape0:type = sphere - określenie kształtu smart terrain'a jako sfery. (kształt nie jest widoczny bez SDK) □ shape0:radius - promień sfery smart terrain'a. Wartość nie ma wpływu na stan pracy stalkerów. Parametr nie decyduje o odległości na jaką stalker może oddalić się od obozowiska! jadnakże nie można jej pominąć. Wartość min. = 1. □ restrictor_type = 3 - bardzo ważny wpis. Ilekroć tworzę obozowisko unikalnych NPC/mutantów, tj. obiektów w których parametry name = type, wówczas wartość restrictor_type jest zawsze równa 3. Jeśli ustawię wartość 0, wówczas przy rozpoczynaniu nowej gry spotkamy się z CTD o treści: FATAL ERROR[error]Description : any vertex in patrol path*...is inaccessible for object **... * - ścieżka patrolowa zdefiniowana w way_*.ltx ** - obiekt np. NPC określony w alife_*.ltx, przemieszczający się zgodnie ze ścieżką patrolową. Należy mieć na uwadze w/w informacje, ponieważ są bardzo istotne. Wskazówka ogólna: aby proces kompilacji przebiegał prawidłowo, dodając kolejne obiekty do plików alife_*.ltx, way_*.ltx - należy zachować pomiędzy dodawanymi sekcjami odstępy 2 wierszy. Do pliku alife_*.ltx (alife_zaton.ltx) dodaję wpis odnoszący się do space_restrictor, który jest immanentnym elementem pracy smart terrain'a (jest wykorzystywany przez pliki gulag_*.script w moim przykładzie). Space restrictor w zależności od dodatkowych wpisów (np. active = sr_no_weapon) - pełni różną funkcję, np. powoduje, iż gracz w jego strefie (np. bunkier Sidorowicza, bar etc.) chowa broń. W tym przypadku - obszar ten wykorzystują NPC w pliku gulag_*.script jako dodatkowy punkt odniesienia, gdy oddalą się od obozowiska np. wskutek ataku. * - nazwa mapy. analizując wpisy space_restrictor można zauważyć, iż game_vertex_id = 0. (na podst. analizy 77 wpisów z pliku alife_l01_escape.ltx). Dodawany wpis ma postać następującą: Opis parametrów sekcji jest taki sam jak w pkt.3 dot. smart terrain'a, toteż do niego odsyłam. Zwracamy uwagę, aby: restrictor_type = 3 Następny element pracy to zarejestrowanie nowego smart terrain'a. Stosowne wpisy (3 sekcje) należy umieścić w pliku gulag_*.script [gamedatascripts]. Możemy stworzyć nowy plik, jednak by skrócić proces tworzenia smart terrain'a możemy też wykorzystać istniejące pliki skryptu. W przykładzie - wpis umieszczę w pliku gulag_escape.script Wskazówki: Długość wpisu uzależniona jest od ilości jednostek przypisanych do smart terrain'a, w moim przykładzie 10 osobowa grupa. W jednym pliku dodaję 3 sekcje, zgrupowane w różnych jego częściach. Przykładowo: wpis dot. "esc_lager" (Shoc 1.0004) występuje w pliku gulag_escape.script w linijkach 293, 2048 oraz 2308. Każda sekcja określa różną funkcję - przykład podaję by można było na jego podstawie określić rozlokowanie wpisów w pliku. Omówienie parametrów sekcji 1: □ rozdzielenie parametrów. t = { section = "logic@zat_gas_station_guard1", idle = 0, prior = 10, state = {0, 1}, in_rest = "", out_rest = "gas_station_team"} Zapis w postaci 1-wierszowej znacznie lepiej zwraca uwagę na konieczność oddzielenia parametrów przecinkiem - być może uwaga jest truistyczna, jednak wystarczy brak przecinka w jednym tylko miejscu by skrypt nie funkcjonował prawidłowo, zaś duża ilość jednostek, które będą obsługiwane przez smart terrain, to duża ilość wpisów przy których łatwo można pominąć - tak wydawać by się mogło - mało istotną sprawę, dlatego zwracam uwagę na konieczność dokładnego sprawdzenia tworzonego skryptu obozowiska pod kątem odseparowania każdego z parametrów. logic@zat_gas_station_guard1 jest to link do pliku gulag_*.ltx (w przykładzie gulag_escape.ltx) lokalizacja:[gamedataconfigmisc], w którym znajduje się wpis wiążący skrypt (gulag_*.script) z plikiem way_*.ltx. Ów wpis łączy skrypt z schematem działania NPC. Opis pliku gulag_*.ltx - w następnym punkcie. □ idle - to czas przeznaczony na przerwę pomiędzy wykonywaniem tego samego zadania przez skrypt. Gdy parametr ma wartość 0, wówczas obóz pracuje w sposób ciągły zapewniając stalkerom 24 godz. tryb pracy. □ prior - stopień ważności zadania, który im jest wyższy - tym zadanie (np. patrolowanie) jest ważniejsze. Zadania o wyższym priorytecie są podejmowane przez zespawnowanych stalkerów w pierwszej kolejności (z wyjątkiem parametru "predicate") □ state = {0, 1} oznacza, iż zadanie, które zdefiniujemy jednostce - jest wykonywane w cyklu dzień-noc.Jeśli ustawię state = {0}, wówczas zadanie bedzie dostępne tylko podczas dnia. Przy state = {1} - zadanie jest realizowane nocą. Jeśli wybiorę jedną z opcji tj, state 0 lub 1 wówczas muszę stworzyć jednostce róznież zadanie ekwiwalentne dla drugiego trybu. Innymi słowy - jeśli NPC będzie patrolował z parametrem state = {0}, wówczas po zapadnięciu zmroku - opuści obozowisko, ponieważ smart terrain nie znajdzie dla niego zadania, które będzie dostępne w nocy. Należy wówczas stworzyć dla takiej jednostki zadanie np. odpoczynek przy ognisku lub sen, z parametrem state = {1}, aby zapewnić jednostce możliwość realizowania zadania w cyklu dzień/noc. □ in_rest - opisuje ogranicznik (space_restrictor), który uniemożliwia wyjście stalkerom poza obszar obozowiska podczas walki. U mnie stalkerzy mają pełną swobodę opuszczania go w przypadku ataku, ponieważ in_rest = "" nie jest zdefiniowany. □ out_rest - wpis odnosi się do stworzonego obiektu z pkt. 4 tj. gas_station_team, które określa obszar pomocniczy dla stalkerów przebywających poza obozowiskiem. W moim przykładzie wzorowanym na obozowisku nowicjuszy z Kordonu, gdzie out_rest - został określony jako: out_rest = "gas_station_team" w/w wpis jest określony w pliku alife_zaton.ltx jako obiekt o numerze [11628], zespawnowany w pobliżu m-ca smart terrain'a. □ predicate - jest to wpis, który przydziela zadanie określonej postaci dzięki parametrowi profile_name, który znajduje się również w pliku alife_*.ltx (character_profile). Dzięki wpisowi, mamy pewność, że określony NPC np. leader - zajmie pozycję na której nam zależy. W niektórych przypadkach można wpis zdefiniować następująco (wartość 700 oznacza m-ce rankingowe stalkera): predicate = function(obj_info) return obj_info.rank >= 700 end Co oznacza, iż stalkerzy z reputacją równą lub większą niż 700 - będą realizować zdefiniowane zadanie (dla pozostałych będzie ono niedostępne). Innym sposobem na przydzieleniu postaci określonego zadania jest umieszczenie wpisu: predicate = function(obj_info) return obj_info.story_id == 5481 Tylko postać o określonym numerze identyfikacyjnym, zgodnym z wpisami zawartymi w plikach: alife_*.ltx (parametr story_id - patrz punkt 8.1) oraz game_story_ids.ltx (omówienie w pkt. 8.4) - będzie realizować zadanie. Omówienie parametrów sekcji 2: Funkcja która występuje w sekcji 2, została zdefiniowana do pracy w cyklu dobowym, określając czas [godz.] w którym następuje zmiana state = {0} na state = {1} Omówienie parametrów sekcji 3: wpis przyporządkowuje obozowisko określonej frakcji - w tym przypadku npc_community == "stalker" Wykaz frakcji i mutantów - plik game_relations.ltx [gamedataconfigcreatures]. Sekcje 1,2,3 są obowiązkowe do wpisania!. Kolejny etap to dodanie wpisów wiążących skrypt obozowiska ze schematem działania opartym o wyznaczone koordynaty. Musimy zgodnie z poprzednim plikiem gulag_*.script odszukać [gamedataconfigmisc] odpowiadający mu plik gulag_*.ltx. * - nazwa mapy. Ponieważ plik omawiany poprzednio to gulag_escape.script - odpowiadającym mu plikiem jest gulag_escape.ltx. Plik gulag_escape.ltx (zgodnie z obranym przykładem) uzupełniam o wpisy (pomiędzy kolejnymi sekcjami są 2-wierszowe odstępy): Opis parametrów sekcji: Ogólnie rzecz ujmując - wpis: logic@Nazwa_Smart_Terraina + Identyfikator - musi występować w 2 plikach tj. gulag_*.ltx i gulag_*.script. W ten sposób wiąże się wpisami ścieżkę i kierunki patrzenia z określonym smart terrain'em. - porównaj wpisy z pkt. 5 i 6. Sprawa priorytetowa: ilość wpisów zawarta powyżej tj. [logic@...] jest zależna od ilości parametrów "section", zawartych w plikach gulag_*.script [gamedatascripts]. Warunek: Każdy z parametrów logic@ musi mieć odniesienie wpisowe w pliku gulag_*.script - patrz Zaton Gas Station, sekcja 1. Wyjątkiem jest (jeden) wpis [logic@zat_gas_station_kamp1], który jest wykorzystywany przez 2 postacie. (schemat pracy dotyczy punktu zajmowanego przy ognisku: pierwszy NPC zasiada przy ognisku przez całą dobę ponieważ state = {0, 1}, drugi NPC nocą zasiada do ogniska z uwagi na state = {1}, za dnia będąc wartownikiem stacji, gdyż state = {0} patrz plik omówiony w pkt.5 - guard6). [logic@zat_gas_station_guard1] Ujęty w nawias kwadratowy powyższy wpis, odnosi się do pliku skryptu gulag_*.script, w którym gra szuka w określonym smart terrain'ie (w moim przykładzie - zat_gas_station) sekcji logic@..***, którą zawierać powinny oba pliki gulag'u tj. wykorzystywany w przykładzie gulag_escape.ltx i gulag_escape.script (patrz pkt.5, sekcja 1 wpisu). W ten sposób tak samo nazwane schematy są łączone swoistym linkiem poprzez: logic@..**** **** - nazwa smart terrain'a + wyróżniający schemat wpis np. kamp1 □ active - parametr, który przyporządkowuje wartości [logic@..****], określony zbiór punktów poprzez path_walk i path_look. Jak możemy zauważyć na przykładzie: [logic@zat_gas_station_guard1]active = walker@zat_gas_station_guard1[walker@zat_gas_station_guard1]path_walk = patrol_walk1path_look = patrol_look1meet = meet@station Wpis [logic@zat_gas_station_guard1], wykorzystuje poprzez active zdefiniowany w nawiasie kwadratowym [walker@zat_gas_station_guard1] zbiór konkretnych koordynatów (ścieżka i kierunki patrzenia), wg. których NPC będzie pracował - patrolując, stojąc, siedząc, śpiąc czy atakując cel. Jak widzimy w prezentowanym przykładzie - zarówno logic@ jak i walker@ wykorzystują tę samą frazę: zat_gas_station, która jest nazwą utworzonego wcześniej w pliku alife_zaton.ltx - smart terrain'a (pkt. 3 poradnika - parametry "name" oraz "type"). Tworząc wpisy j/w musimy trzymać się zasady właściwego powiązania plików z utworzonym smart terrain'em, wykorzystując jego nazwę. □ path, look - są odnośnikami do koordynatów (X,Y,Z,game_vertex_id, level_vertex_id)zawartych w pliku way_*.ltx (w moim przykładzie: way_zaton.ltx). path_walk = patrol_walk1path_look = patrol_look1 Punkty wyznaczają zajmowaną pozycję (path) oraz kierunek/ki patrzenia NPC (look). □ meet - wpis który definiuje zachowanie NPC, wg. którego będzie reagował na postać główną - ignorując ją, rozpoczynając rozmowę lub wykonując określoną animację zależną od rozbudowy tegoż wpisu. Zdefiniowany w moim przykładzie wpis to standardowy schemat postępowania. Musimy go dodać do pliku, ponieważ w oryginale ów wpis tj. meet@station - nie występuje (patrz ostatnia sekcja dodawana do pliku gulag_escape.ltx - spoiler). use_wpn = true ;-- możliwość używania broni przez NPCmeet_talk_enabled = true ;-- możliwość rozmowy z aktorem □ radius = 2.30 - parametr występujący przy definiowaniu pozycji NPC'a zajmującego określoną odległość od punktu centralnego (najczęściej zasiadający przy ogniskach NPC) - w tym przypadku odl. jest równa 2m 30 cm. Defaultowa wartość jest równa 2 metry. Tworząc większą ilość NPC korzystających z tego schematu - wartość promienia można zwiekszyć aby nie dochodziło do przepychanek stalkerów. Aby oszacować odległości warto włączyć w menu opcję - pokaż odległość od celu. Opcja przydaje się wówczas, gdy mamy zamiar stworzyć zasiadających przy ognisku stalkerów na obszarze ograniczonym innymi obiektami (mur, siatka, urwisko etc.) W przypadku błędnego oszacowania odległości, zbyt duża wartość promienia bedzie skutkowała błędem, ponieważ punkty przyporządkowane jednostce będą dla niej niedostępne z uwagi na przeszkody, których NPC nie bedzie w stanie pokonać. Chcąc ustalić za co odpowiadają poszczególne schematy obozowiska tj. [logic@zat_gas_station_*] (gdzie * oznacza identyfikator schematu), wystarczy przyjrzeć się jakie animacje przypisano do identyfikatora, przykładowo dla: [zat_gas_station_patrol_look1] mamy przyporządkowaną animację: p0:name = wp00|a=guard czyli postać będzie wartownikiem. Wyjątkiem jest schemat stalkerów zasiadających przy ognisku, gdzie schematem odpowiedzialnym jest w moim przypadku wpis: [zat_gas_station_camp3_center] istotnym wpisem rozpoznawanym przez grę jest camp3_center (numeracja może być inna). Przy frazie camp - gra wykorzystuje animacje stalkerów siedzących w określonej odległości od punktu centralnego. Animacje opisano w pkt. 7 poradnika. Następna czynność to dodanie zebranych wcześniej koordynatów do pliku way_*.ltx (w przykładzie: way_zaton.ltx). Współrzędne - jak już wspominałem określają pozycje zajmowane przez NPC'ów, ich ścieżki patrolowe i kierunki patrzenia. Ogólna zasada tworzenia punktu jest następująca: w nawias kwadratowy wpisujemy nazwę naszego smart terrain'a połączoną z nazwą punktów, osobno dla path_walk i path_look. Wpis nie może zawierać pustych znaków jak spacja czy tabulacja, elementy tworzące całość oddzielamy poprzez _ ("podkreślnik dolny"). Przykład: [zat_gas_station_patrol_look1][zat_gas_station_patrol_walk1] gdzie: □ zat_gas_station - nowo utworzony smart terrain (Etap II, pkt. 3 poradnika). □ patrol_look1 - punkt określony w pliku gulag_*.ltx wyznaczający kierunek patrzenia (Etap II, pkt. 6 poradnika). □ patrol_walk1 - punkt wyznaczający zajmowaną pozycję przez NPC'a, zdefiniowany w gulag_*.ltx (Etap II, pkt. 6 poradnika). □ points = p0,p1 oznacza, iż NPC wodzi wzrokiem od pkt. p0 do p1 po osiągnięciu którego poprzez wpis: p1:links = p0(1) kieruje wzrok do pierwotnej pozycji, po czym rozpoczyna się cały schemat. Wg. powyższych punktów trasy patrolowej, NPC przemieszcza się następująco : p00 -> p02 -> p04 -> p06 -> p08 -> p10 -> p11 (powrót) -> p09 -> p07 -> p05 -> p03 -> p01 -> p00 (cykl rozpoczyna się na nowo) W/w schemat trasy zaznaczono na załączniku (I Etap poradnika, pkt.2), gdzie na czerwono oznaczono trasę wiodącą do celu, powrót natomiast na pomarańczowo. W powyższym pliku występują również wpisy (najczęściej spotykane): wp00|a=hide - animacja przykucniętego NPC w zajmowanym punkcie.wp00|a=ward - animacja NPC z rękoma założonymi do tyłu.wp00|a=guard - animacja dla strażnika.wp00|a=patrol - amimacja jednostki patrolującej.wp00|a=sit_ass - animacja stalkera siedzącego.wp00|a=binocular - animacja stalkera obserwującego zadany punkt lornetką (czas obserwacji - cały cykl).wp00|a=bar_fas - animacja stalkerów opierających się o stolik.wp00|a=sleep - animacja śpiącego stalkera.wp00|a=sneak - animacja skradającego się stalkeraname02|a=assault - animacja NPC szturmującego. (patrz wpisy analogiczne w plikach way_*ltx). Aby lornetka była dostępna dla obserwatora w sekcji spawnowanej postaci tj. pliku alife_*.ltx należy dodać wpis: [spawn]wpn_binoc Wówczas zostanie ona zespawnowana w ekwipunku postaci (patrz pkt.8.1 - dodawanie NPC). Ów wpis należy wkomponować pomiędzy parametry - jak w przykładzie poniżej: [smart_terrains]zat_gas_station = true[spawn]wpn_binocEND Animacja w każdym punkcie może być inna, jednakże dla niezmieniającego pozycji NPC warto obrać tylko jedną. Jeśli tworzymy skomplikowaną trasę NPC, np. szturm wrogiej bazy, wówczas możemy dla poszczególnych punktów trasy obrać animacje: a=binocular|t=20000 (obserwację obiektu w czasie t) a=assault (szturm), a=sneak (podkradanie się). Stworzenie takiej trasy jest bardzo czasochłonne - wytrwałym polecam spróbować, wcześniej poprzez analogię sprawdzając jak skonstruowano schemat takiej trasy w plikach way_*ltx z niemodowanego stalkera. * - nazwa mapy. Przykłady animacji stalkerów w funkcji schematu obozowiska ilustruje poniższy załącznik: □ position, game_vertex_id, level_vertex_id - koordynaty i punkty wierzchołkowe, wyznaczone uprzednio - patrz Etap I, pkt. 2 poradnika. Pomiędzy wpisami zachowany jest 2-wierszowy odstęp! Mamy już niemal wszystko z wyjątkiem NPC'ów, których musimy od podstaw skonfigurować. Nasz smart terrain obsługuje 10 stalkerów i tyle muszę stworzyć jednostek, by wykorzystać pełen potencjał obozowiska. Podam jeden przykład wg. którego postępujemy - pozostałych NPC'ów dodaje się analogicznie, zmieniając wg. uznania model postaci, pozycję rankingową, posiadaną kwotę, dźwięk rozmów, posiadaną broń etc. Do podstawowej konfiguracji NPC potrzebujemy następujących plików: - alife_*.ltx [zdekompilowany plik all.spawn]- character_desc_*.xml [gamedataconfiggameplay]- npc_profile.xml [gamedataconfiggameplay]- game_story_ids.ltx [gamedataconfig]- spawn_sections.ltx [gamedataconfigcreatures] * - nazwa mapy 8.1. Do pliku alife_*.ltx (w przykładzie alife_zaton.ltx) dodaję sekcję spawnowanego NPC. Omówienie parametrów sekcji: □ [11629] - nr. dodawanego obiektu (nie może się powtarzać dla całego pliku). section_name = stalker wpis stały przy dodawaniu NPC, nie wpływa na frakcję! □ name - nazwa dodawanego obiektu, która dla każdego obiektu powinna być inna. □ position - koordynaty X,Y,Z □ direction - obrót obiektu po zespawnowaniu. □ money - ilość posiadanej gotówki. □ character_profile - jest to przyporządkowanie postaci określonego profilu, definiowanego szczegółowo w pliku character_desc_*.xml oraz wykorzystywanego w skrypcie (jeśli takowy stworzono) gulag_*.script (w moim przykładzie gulag_escape.script) poprzez funkcję: predicate = function(obj_info) return obj_info.story_id == 5481 (związaną poprzez plik game_story_ids.ltx - omówienie pkt. 8.4) dzięki której wyznaczamy określony typ zadań postaci o zadanym profilu. □ game_vertex_id, level_vertex_id - punkty wierzchołkowe wyznaczone za pomocą "Smartterrain and Waypoint Tools by dez0wave" (patrz etap I, pkt.1 poradnika) □ zat_gas_station = true - wpis określa smart terrain z którego będzie korzystała postać. □ story_id = 5481 - parametr odnoszący się do pliku game_story_ids.ltx [gamedataconfig] omówiony w pkt.8.4 □ visual_name - ścieżka do modelu .ogf □ upd:position - parametr określający współrzędne obiektu. Musi być zawsze taki sam jak position. □ pozostałe parametry pozostawić należy domyślnie (tworzenie spawna z uzyciem SDK). 8.2. Tworzę szczegółowy profil NPC. Plik w którym umieszczam stosowny wpis (zwróć uwagę na nazwę przyporządkowaną do character_profile w pliku alife_*.ltx - w którym została dodana postać) zależny od mapy na której spawnujemy postać. Ponieważ wykorzystywałem pliki gulag_escape.script oraz gulag_escape.ltx - wpis dodaję do [gamedataconfiggameplay] character_desc_escape.xml (jest to sytuacja wyjątkowa - pliki w/w wykorzystałem by skrócić czas przygotowania stalkerskiego obozowiska). Opis parametrów sekcji na przykładzie: □ specific_character id - jest to unikalny identyfikator postaci, wykorzystywany w plikach: alife_*.ltx, gulag_*.script, spawn_sections.ltx, game_story_ids.ltx. Ów parametr jest taki sam dla wszystkich wymienionych plików, łącząc różne funkcje składające się na funkcjonowanie NPC o określonym identyfikatorze profilowym. □ <name>Keldorn</name> - nazwa postaci. □ <icon>ui_npc_u_stalker_ki_antigas</icon> - określa jaka ikona postaci będzie wyświetlana podczas przeglądania kontaktów na PDA, rozmów, przeglądania zwłok etc. Odpowiednie konfiguracje położenia ikony można znaleźć w pliku ui_npc_unique.xml [gamedataconfigui]. W tym przypadku gra odczytuje na podst. współrzędnych z w/w pliku - sektor z interesującą nas ikoną zawartą w pliku tekstur ui_npc_unique.dds [gamedatatexturesui]: <texture id="ui_npc_u_stalker_ki_antigas" x="330" y="756" width="165" height="108" /> Zapis j/w oznacza położenie ikony w oddaleniu od osi OX o 330 px. (wartość naliczana od lewej strony pliku ikon) oraz odległość od osi OY o 756 px. (wartość naliczana od górnej części pliku ikon). Położenie mierzone jest do górnej-lewej części ikony. Width (szerokość) i height (wysokość) również mierzone są w pixelach. Znając powyższe wskazówki jesteśmy w stanie określić położenie ikony w pliku oraz stworzyć własną. □ <bio>zat_leader</bio> jest odnoszącym się do biografii parametrem, który zawiera plik [gamedataconfigtextpol] stable_bio_name.xml. □ <class>zat_leader</class> - klasa postaci z uwagi na jej unikalny charakter określona w pliku npc_profile.xml [gamedataconfiggameplay] □ <community>stalker</community> - przynależność frakcyjna. Możemy ustawić dowolną frakcję, jednak musi być ona zawsze zgodna z parametrem npc_community - występującym w pliku gulag_*.script [gamedatascripts] - patrz Etap II, pkt. 5 poradnika (sekcja 3) □ <rank>810</rank> - pozycja rankingowa NPC. □ <reputation>200</reputation> - reputacja NPC'a □ <money min="9000" max="10000" infinitive="0"></money> - zakres min. i max. posiadanej gotówki (gra wybierze wartość z zadanego zakresu). □ <visual>actorszaton_leader</visual> - ścieżka do modelu .ogf, czyli wygląd postaci zgodny z parametrem "visual_name" zdefiniowanym w pliku alife_zaton.ltx. □ <snd_config>characters_voicehuman_01stalker</snd_config> - ścieżka do pliku dźwiękowego wykorzystywanego przez NPC np. w czasie rozmów przy ognisku, zwracania uwagi na podniesioną broń, reakcji na zagrożenie etc. □ <crouch_type>-1</crouch_type> - animacja przykucniętego NPC (obieram wartość defaultową). □ <supplies>..... </supplies> - tag definiuje rodzaj posiadanego przez postać ekwipunku oraz zawiera odnośniki do plików odpowiadających za: a). jedzenie (character_food.xml) - wykaz oraz prawdopodobieństwo zespawnowania w ekwipunku stalkera: bread = 1, prob=0.3 nkolbasa = 1, prob=0.3 nvodka = 1, prob=0.2 nenergy_drink = 1, prob=0.5 n b). środki medyczne (character_drugs.xml) medkit = 1, prob=0.2 nbandage = 1, prob=0.4 n c). przedmioty dodatkowe (character_items.xml) harmonica_a = 1, prob=0.7 nguitar_a = 1, prob=0.7 ndevice_torch = 1, prob=0.5 n W/w pliki zlokalizowane są w [gamedataconfiggameplay]. Szereg wpisów sekcji supplies odpowiedzialnych za ekwipunek postaci: wpn_pm n <!------ Broń krótka, Makarovammo_9x18_fmj = 1 n <!------ Amunicja kalibru 9x18 mmwpn_val n <!------ Broń podstawowa, AS Valammo_9x39_ap n <!------ Amunicja kalibru 9x39 mmdevice_torch n <!------ Latarka na wyposażeniu □ <start_dialog></start_dialog> - pomiędzy tag dodawany jest dialog postaci z Naznaczonym. Odpowiednio skonstruowany skrypt połączony z dialogiem oferuje postaci mozliwość zlecania zadań, naprawy broni, handlu etc. To dialogi są kluczowym elementem rozwoju fabułu - jeśli chcemy uczynić postać kimś więcej niż tylko wartownikiem, modyfikujemy tą cześć sekcji poprzez dodanie nowego dialogu, którego konstrukcja to temat innego poradnika. Częściowo - na przykładzie zlecania zadań jest to omówione w tym poradniku (Link). Mój przykład zawiera standardowe dialogi - ponieważ tematem tutoriala jest tworzenie obozu - nie dialogów. 8.3.Tworząc nowego NPC, uzupełniamy plik npc_profile.xml [gamedataconfiggameplay] o wpis: <character id="zat_leader"> <class>zat_leader</class> <specific_character>zat_leader</specific_character></character> Który jest zgodny z występującym w character_desc_escape.xml parametrem <class> (patrz profil NPC - pkt. 8.2) 8.4. Kolejnym plikiem, który musimy uzupełnić jest game_story_ids.ltx [gamedataconfig]: 5481 = "zat_leader" Numer musi być taki sam jak występujący w parametrze story_id = 5481, który zawiera sekcja postaci spawnowanej w pliku alife_zaton.ltx (patrz pkt. 8.1). Numeracji nie wolno dublować, w przeciwnym wypadku rozpoczęcie gry zakończy się wypadem na pulpit! Zawsze dostosowujemy ją do zawartości pliku. 8.5. Ostatni z plików potrzebnych do sfinalizowania konfiguracji NPC jest spawn_sections.ltx [gamedataconfigcreatures].Dodajemy wpis, którego kluczowa zawartość odnosi się do identyfikatora profilowego (unikalnego dla każdej postaci). W moim przypadku jest to "zat_leader" [zat_leader]:stalker$spawn = "respawnzat_leader"character_profile = zat_leaderspec_rank = veterancommunity = stalker Jedyne na co warto zwrócić uwagę to spec_rank, dostosowanie do rangi postaci określonej przez parametr <rank> zawarty w pliku character_desc_*.xml [character_desc_escape.xml]. - Tutorial, Etap II - pkt. 8.2. Dostosowujemy wg. pliku _g.script [gamedatascripts] gdzie: - novice - ranga od 0 do 299- stalker - ranga od 300 do 599- veteran - ranga od 600 do 899- master - ranga powyżej 900.Wszystkie wprowadzone zmiany zapisujemy, przy czym te wprowadzone do plików alife_*.ltx oraz way_*.ltx musimy poddać kompilacji, by zapisane sekcje znalazły się w pliku all.spawn! Jeśli zrobiliśmy wszystko zgodnie z tutorialem - możemy sobie pogratulować cierpliwości sprawdzając efekt naszej pracy, który w przypadku mojej bazy prezentuje się następująco. http://www.youtube.com/watch?v=5nqS-Kr6268 II. Etap wykonawczy - przypadki szczególne. Przypadek szczególny należy rozpatrywać w kontekście braku dostępności pozycji - przez NPC np. dachy budynków w związku z czym, taka jednostka nie może mieć przyporządkowanego smart terraina z uwagi na niedostępność docelowej pozycji (path) - wynikającej z braku siatki AI wg. której NPC odnajduje drogę do celu. Tworzenie snajpera: Moim zamiarem jest dodanie snajpera, którego zajmowana pozycja mieści się na zniszczonym moście na Kordonie. Ponieważ jest to miejsce niedostępne dla stalkerów - z uwagi na znajdujące się tam wagony oraz siatkę - snajper musi być zespawnowany w miejscu docelowym (w punkcie do którego nie byłby w stanie dojść), ale uwaga - w tej sytuacji nie może zostać przypisany smart terrain'owi, którego punkty terenowe konieczne dla stworzenia zadań powinny być osiągalne dla stworzonych jednostek, innymi słowy - taki stalker nie zająłby pozycji z uwagi na brak dojścia na most - doszło by do wylotu na pulpit! Aby tego uniknąć jest prosty sposób: W pliku powstałym po dekompilacji all.spawn, zależnym od miejsca dodawania - w moim przypadku alife_l01_escape.ltx, umieszczam sekcję snajpera: Parametry sekcji NPC zostały omówione w pkt. 8.1 To co wyróżnia w/w jednostkę to wpisy: [logic]active = camper[camper]path_walk = esc_snip_spec_1_standpath_look = esc_snip_spec_1_lookradius = 7sniper = true Oznacza to, iż nasz NPC korzysta z schematu [camper], który ma określone punkty: □ zajmowanej pozycji - path_walk □ kierunku patrzenia - path_look W/w współrzędne należy dodać do pliku way_*.ltx (w moim przykładzie: way_l01_escape.ltx). □ sniper = true - animacja snajpera. [smart_terrains]none = true Powyższy wpis oznacza, iż NPC nie korzysta z żadnego smart terrain'a (utrzymuje jednak pozycję wg. punktów). Do pliku way_l01_escape.ltx dodajemy współrzędne o takiej samej nazwie jak dla w/w punktów schematu [camper] path_walk oraz path_look. Nazwę identyfikującą współrzędne należy ująć w nawias kwadratowy - patrz poniżej: Z powyższych punktów terenowych korzysta wcześniej przypisany snajperowi schemat [camper]. Tak wprowadzone dane zapisujemy - kompilując plik all.spawn, umieszczając go następnie w gamedataspawns. Następnie konfigurujemy profil postaci - dodając do plików stosowne sekcje, wg. pkt. poradnika 8 do 8.5 character_profile = esc_soldier_specnaz w/w wpis esc_soldier_specnaz - jest oczywiście unikalnym identyfikatorem postaci - o czym należy pamiętać tworząc NPC'ów. Po dodaniu potrzebnych plików, sprawdzamy efekt naszej pracy.Schemat snajpera - pomijając fakt braku snajperki i ghillie suit'a - elementy które można dodać, nasz NPC prezentuje się następująco. Prawa autorskie na podstawie regulaminu, pkt.1.6. - The Emperor, wyłączność: StalkerTeam. _____________________________ Autor: The Emperor dla StalkerTeam

W dużym skrócie... Spawn NPC otrzymuje się dodając sekcję odpowiedzialną za obiekt (i związane z nim wpisy), tj. section_name = stalkerdo plików alife_*ltx, które uzyskuje się na drodze dekompilacji pliku all.spawn. * nazwa mapy na którą dodawany jest obiekt. Poprzez poniższy parametr character_profilewystępujący w sekcji dodawanego NPC, gra szuka profilu postaci, który znajduje się w plikach [gamedataconfiggameplay]: character_desc_*.xml (np. dla kordonu plikiem konfigurującym postacie jest character_desc_escape.xml powiązany z plikiem alife_l01_escape.ltx). Ekwipunek zmieniasz poprzez modyfikacje plików character_desc_*.xml - przykład: <supplies>      [spawn] n      wpn_pm n      ammo_9x18_fmj = 1 n      wpn_ak74u n      ammo_5.45x39_fmj n      device_torch n    </supplies>Powyższe wpisy decydują o broni: wpn_pm (pistolet Makarov), amunicja kalibru 9x18, wpn_ak74u, amunicja kalibru 5.45x39 oraz device_torch - czyli latarka. W tym miejscu zmieniasz sprzęt stalkerom, których id profilu - musi być zawarte w sekcji dodawanego stalkera (pliki alife_*ltx, sekcja j/w). Kombinezon zmienisz edytując wpis zawierający ścieżkę do modelu .ogf - przykład: <visual>actorsneytralstalker_neytral_rukzak_3</visual>stalker_neytral_rukzak_3 - model .ogf Pliki alife_*ltx wypakuj wg. tego poradnika. Nie opiszę Ci jak stworzyć od początku NPC ponieważ wymaga to napisania tutoriala. Jestem w trakcie pisania poradnika o tworzeniu obozów stalkerskich i dodawaniu NPC, aktualnie ma 30 str. A4. Jeśli poczekasz ok. tygodnia - nie pożałujesz, bo znajdzie się tam wszystko co potrzebne by stworzyć stalkerską bazę. Jeśli jednak bardzo chcesz stworzyć NPC - skorzystaj z ubogiego poradnika - tutaj. Na początek wystarczy by stworzyć postać. Chcąc zebrać współrzędne obiektów spawnowanych - przeczytaj początkową część tego poradnika.

Ja na w/w błąd kolegi radziłbym sprawdzić plik localization.ltx [gamedataconfig] pod kątem poprawności wpisu, który dla polskiej wersji powinien wyglądać tak: [string_table]language   = polfont_prefix   = _cent ;_westPonadto folder pol [gamedataconfigtext] powinien zawierać pliki, które zawarte są w localization.ltx. Jeśli będą rozbieżności - mod został źle zainstalowany.

@TomordenPL czy w logu jest wpis Fatal Error? Jeśli tak - wrzuć treść loga od tego wpisu. Dzięki temu można będzie zlokalizować błędny plik/pliki.

@tomlopag zobacz ten post ( zakładka Бар) - jest po rosyjsku, ale zawiera screeny z lokalizacji potrzebnych dokumentów.

@Logic Na tej stronie - link oraz kilka postów poniżej radzą jak obejść ten problem: uruchomić grę jako administrator wyłączyć autosave z menu przełączyć oświetlenie na statycznesprawdź w/w i daj znać czy działa, może komuś jeszcze rada (o ile się sprawdzi) pomoże?

Nie mam co prawda tej aplikacji, ale znalazłem taki temat: link, być może twój problem rozwiąże ten post.?

Pisz do autora moda w tej sprawie, aktualnie brak mi czasu na analizę moda, który wydaje się być powodem problemu. Jeśli jednak po rozpakowaniu Gamedata Magazines - natkniesz się na pliki, które wymieniłem w poprzednim poście jako odpowiedzialne za ekwipunek, wówczas edytuj je zgodnie z zaleceniami.

@Hentaj niefortunny błąd - podobny problem z różnicą odnoszącą się do linijki 150 - również w modzie do CoP, odnotowano tutaj: link. Jedna z porad to odszukanie pliku death_items_count.ltx i przyporządkowanie problematycznych itemów pod item_count_0. (link - post usera mnn), inna mówi o zmianie trybu trudności na mistrz, jednakże - to zupełnie inny mod, więc próbowałbym pierwszego sposobu - edytowania pliku (pracując na jego kopii). Musisz bardziej precyzyjnie opisać sytuację: jaki ekwipunek posiada NPC? czy został przeszukany przez Ciebie, a może zrobił to inny stalker? Być może problem stwarza przedmiot posiadany przez zabijanego bandytę? Ustalając przedmioty, będziesz wiedział jakie pliki w kontekście pierwszej porady - dodać do item_count_0. Mam nadzieję, że grasz z kompletem patchy. A jeśli chodzi o skrypt, to musisz odszukać wiersz 149, pliku death_manager.script, sprawdzić całość problematycznej funkcji z tym samym plikiem z patch'a. Być może znajdziesz istotną różnicę - nie mam moda na dysku, więc bardziej nie pomogę.

Witam kolegę, plik ogólnej konfiguracji stalkerów to character_desc_simulation.xml [gamedataconfiggameplay]. Każdy NPC jest zdefiniowany pod kątem wizualnym, ekwipunkowym, dialogowym w plikach .xml - wyjaśnię Ci to na przykładzie Wilka z kordonu. Ale wpierw zadaj sobie pytanie - widziałeś kiedykolwiek by skończyła mu się amunicja do ak74u (w podstawce), po czym przeszedł na broń krótką? - ja nie spotkałem się z tym. Poniżej konfiguracja ekwipunkowa Wilka: [spawn] nwpn_pm nammo_9x18_fmj = 1 nwpn_ak74u nammo_5.45x39_fmj ndevice_torch nhand_radio nJak widać w swoim wyposażeniu posiada: pistolet Makarov'a, ak74u, latarkę (torch), radio oraz amunicję. Wpis ammo_5.45x39_fmj nie ma przyporządkowanej wartości liczbowej, natomiast przy 9x18_fmj mamy wartość 1 ammo_9x18_fmj = 1Masz dwie opcje: albo usuniesz jedynkę stojącą przy amunicji określonego stalkera albo dopisz np. ammo_9x18_fmj = 10 (czyli 10 magazynków przyporządkuj postaci, która straciła amunicję). Będę szczery - nigdy nie była mi potrzebna zmiana, którą wymusiłby brak amunicji - dlatego musisz sprawdzić zmiany, które wymagają nowej gry by zostały zauważone. Sprawdź na kopiach plików wartości przyporządkowane do amunicji, bądź też ich brak - lokalizując plik z NPC'ami, których będziesz modyfikował.

@Sovat - który link nie działa? Pierwszy link działa na 100%

Link jest dobry na 100%, sprawdzałem chwilę temu i nie miałem problemów z pobieraniem, rzecz w tym, że trzeba wiedzieć jak pobierać z tej strony pliki, jest to proces wieloetapowy. [*]w nowym oknie/karcie otwieram wyróżniony pogrubieniem wpis Просмотреть рекламу. [*]pojawia się nowa strona z szeregiem wpisów, wybieram dowolny - ja skorzystałem z Полная база таунхаусов Подмосковья. [*]wchodzę w w/w link - pojawia się zegar odmierzający czas 30 sek. [*]gdy odliczanie się zatrzyma - klikam na samej górze wpis нажмите сюда. [*]przepisuję wygenerowany kod do okna [*]tym samym przechodzę do kolejnej strony: link i klikam cкачать. [*]The End Wygenerowane wpisy, które podałem przykładowo często są różne (losowe) i dostępne dla określonej sesji pobierania, generalnie chodzi o pokazanie sposobu downloadu. Tutaj masz wstawiony plik na inny serwer, nie rozpakowywałem go, więc po ściągnięciu sprawdź antywirusem.

Nie pamiętam tego zadania, wiem że Woronin chciał dokumenty z metalowej walizki z Doliny Mroku, pamiętam też zadanie z rejestratorem lotu dla Woronina - ze śmigłowców rozbitych na CEA-2, ale nie przypominam sobie aby kiedykolwiek mówił o dokumentach w takiej ilości (11 szt.). Daj screen'a z PDA ustawionym na to zadanie. Masz solijankę z dodatkami (DMX Mod 1.3.4, ООP) czy bez?