[Tutorial] Podstawowe metody spawnowania:ACDC - Smart Terrain, cz.||

[The Emperor]

Zagadnienia wstępne:

Ważna informacja: zanim zaczniemy zagłębiać się w arkana tworzenia obozowisk, warto skorzystać z zalogowania się na stronie, ponieważ istotną część poradnika stanowią załączniki. Umieszczenie grafik na darmowych hostingach często wiąże się z krótkim czasem ich dostępności - dodając załącznik mam pewność, że nie stracę istotnych uzupełnień poradnika - warto mieć to na uwadze.

 

Czym jest smart terrain? - najprościej mówiąc jest to obszar zespawnowany na konkretnej lokacji, który definiuje poszczególnym NPC/mutantom zadania (patrole, odpoczynek przy ogniskach, sen, zajmowanie posterunków, przeprowadzanie ataków, pełnienie wachty etc.) realizowane w cyklu dzień - noc. Można przyjąć, iż jest to obóz (w przypadku stalkerów) którego istotnym uzupełnieniem są pliki gulag_*.script oraz gulag_*.ltx. Smart terrain - najczęściej definiowany jest w postaci sfery [shape0:type = sphere] o określonym promieniu oraz określonej ilości obsługiwanych postaci/mutantów. Bez smart terraina NPC swobodnie przemierzają Zonę, co początkowo wydaje się realne - wygląda bowiem jak szukanie artefaktów, eksploracja - jednak z czasem, taki NPC ginie w anomalii, bądź zostaje zabity przez mutanty. Miejscem w którym należy dodawać smart terrain są pliki alife_*...ltx, osiągalne po dekompilacji all.spawn

* - nazwa mapy.

 

Podstawowym narzędziem do pracy z tworzeniem smart_terrainów jest uprzednio omawiany: "Smartterrain and Waypoint Tools by dez0wave"

http://sdk.stalker-game.com/en/images/d/d7/Smartterrain_and_Waypoint_Tools_by_dez0wave.zip

Częściowe omówienie (dotyczące zbierania punktów terenowych) narzędzia - zostało zawarte na początku tego tematu: link ,jednak jest ono podzielone na części, z których każda spełnia inną funkcję. Początkowo chciałem stworzyć osobny poradnik dot. omówienia podstawowych funkcji - jednak uznałem, iż wynikający z określonego przykładu kontekst - będzie właściwy do opisania jego możliwości. Bez w/w programu można stworzyć smart terrain, istnieją alternatywne skrypty do pokazywania współrzędnych spawnowanego obiektu, jednak nie znalazłem adekwatnego narzędzia do pokazywania pracy smart terrainów, prócz w/w. - a jest to bardzo ważne i znacznie ułatwia pracę. Po wypakowaniu "Smartterrain and Waypoint Tools by dez0wave" pojawią się następujące foldery:

• points_reader - służący definiowaniu punktów dla ścieżki NPC'a (osobiście nie korzystam).
• save_pos_patrol - umożliwiający zapisanie współrzędnych game_vertex_id, level_vertex_id, koordynatów: X,Y,Z do pliku loga z dużą precyzją.
• smart_on_map - pokazuje w PDA listę zespawnowanych smart_terrain'ów, zarówno aktywnych jak i czekających na aktywację poprzez infoportion.

Nas interesuje w kontekście smart terrain'a zawartość folderu smart_on_map, którą umieszczamy w gamedata. Folder ten zawiera podkatalogi wraz z plikami:

• config [uimap_spots.xml]
• scripts [smart_debug.script, smart_terrain.script]

Do celów modyfikacji, możemy połączyć zawartości folderów: smart_on_map oraz save_pos_patrol.
Zawartość save_pos_patrol, tj.

• config [ui: message_box.xml, ui_patrol_point_dlg.xml]
• scripts [ui_main_menu.script, ui_patrol_points.script]

Jak wynika z powyższego, foldery pomimo wspólnych podkatalogów - posiadają różne pliki, zatem nie występuje pomiędzy nimi konflikt! Do pracy możemy przygotować połączone foldery, dzięki czemu - zbieranie współrzędnych i obrazowanie pracy smart terraina - będzie znacznie prostsze.

Najlepszym rozwiązaniem jest utworzenie listy plików, które składają się na: "Smartterrain and Waypoint Tools by dez0wave" . Jeśli w przyszłości będę chciał usunąć narzędzie z moda - będę wiedział jakie pliki powinienem modyfikować (zwłaszcza gdy mamy długie przerwy w modyfikowaniu).

Ważne!: narzędzie przystosowane jest do niemodowanego stalkera SoC, zatem jeśli mamy zamiar tworzyć smart terrain w modzie, którego pliki kolidują pod względem zawartości z powyższymi - wówczas będziemy musieli je połączyć! Poniższe screeny przedstawiające działanie narzędzia:

 

Omówienie zawartości danych - wyświetlanych po wskazaniu kursorem na znacznik - na przykładzie smart_terrain2.jpg.

Informacja podstawowa: kolorem żółtym oznaczone są aktywne smart terrain'y, szarym (zawierającym przekreślenie na znaczniku)  - obozowiska, których praca jest zależna od infoportions (jeśli fabularnie nie spełniamy warunków zadanych w cond [conditions], wówczas smart terrain jest nieaktywny) jak również - obozy pozbawione NPC/mutantów - np. po ich wyeliminowaniu. Informacje o obozowisku - wyświetlają się w PDA gdy znajdziemy się w odległości > 100 metrów od niego. Będąc bliżej obozowiska lub w jego centrum - okno z informacjami nie zostanie wyświetlone.

• esc2_most - nazwa smart_terrain'a (wykorzystuje ją plik way_...ltx).
• available (true/false) - dostępność uzależniona od zdefiniowania parametru cond, bądź prawidłowości wykonania smart terrain'a.
• working (true/false) - tryb pracy uzależniony od czynników j/w + obecności właściwego NPC/mutanta.
• level - poziom na którym znajduje się smart terrain
• state - określa dostępność zdefiniowaną w cyklu dzień-noc. State = 0 - jest to dzienny tryb pracy, State = 1 - tryb nocny. Smart terrain o wyższym stopniu skomplikowania - którego przykład mamy w obozowisku kotów (Kordon) - posiada owe wpisy, jeśli NPC idzie spać - po godz.22, jest to zależne od pracy zdefiniowanej dla trybu nocnego.
• quantity - określa ile NPC/mutantów obsługuje smart terrain.
• comed - określa ilu NPC/mutantów znajduje się wewnątrz obszaru smart terraina.
• casualities - określa liczbę NPC/mutantów, zabitych w ramach pracy obozu, który został im przyporządkowany.
• comm (communities) - frakcja lub typ mutanta, przypisana do smart terrain'a
• cond - warunki zadane w infoportions, których realizacja bądź brak - określają czynny tryb pracy smart terraina. Przy warunkach spełnionych - marker zmienia się na żółty. W kontekście przykładu mamy:
  

  cond = {+esc_kill_bandits_quest_kill}, {+esc_kill_bandits_quest_done}

  przykład obrazuje smart_terrain: esc2_most dla 3 osobowej grupy stalkerów zajmujących pozycję pod małym mostem w Kordonie. Jednak dostępność tego obozu jest możliwa po wykonaniu zadania eliminacji bandytów na parkingu, w konsekwencji którego otrzymujemy pendrive potrzebny Sidorowiczowi. Jeśli zadanie nie zostanie zrealizowane, wówczas - obóz nie będzie pracował.
  Warunek w/w jest zdefiniowany w pliku alife_l01_escape.ltx [esc2_most], który otrzymamy poprzez dekompilację pliku all.spawn. Parametr cond - nie musi zostać wprowadzony, jednak - mając zamiar tworzyć obóz, który zostanie zasiedlony w konkretnym miejscu fabuły np. wyłączenie mózgozwęglacza - wówczas warto zdefiniować cond, również celem odciążenia gry (można określać zakres pracy danego smart terraina).

Patrząc na screeny, widzimy jak bardzo przydaje się narzędzie. Wyobraźmy sobie, iż mamy sprawdzić działanie 100 smart_terrain'ów. Dzięki temu widzimy efekt spawn'a obozowiska, który w przypadku błędnego skonstruowania - da informację w postaci znacznika odpowiedniego koloru. Dzięki temu, możemy nanieść ewentualne korekty odpowiednio wcześnie, bez konieczności rekonesansu levelu, na który wprowadziliśmy nowy smart terrain.

 

 

Tworzenie smart terrain'a NPC [general_lager]: metoda uproszczona.

 

Korzystając z tej metody, nie jesteśmy zmuszeni dodawać NPC/mutantów do pliku all.spawn, ponieważ respawn wykonuje tę część zadania za nas. W metodzie tej - nie musimy modyfikować plików gulag_*.script oraz gulag_*.ltx oraz tworzyć specyficznych NPC'ów na konfigurację których składa się szereg plików. Tworząc dla NPC obozy typu general_lager, wystarczy dodać wpisy do plików: alife_...ltx oraz way_...ltx. Tą metodą nie stworzymy specyficznego zleceniodawcy czy handlarza, jednak możemy zaludnić puste obszary Zony w stalkerów dobieranych losowo, oraz dodać podstawowe mutanty.
Poniższy poradnik zawiera szczegółowy opis tworzenia nieskomplikowanych obozowisk, w których stalkerzy zbierają się przy ogniskach, zaś mutanty żerują na przestrzeni wyznaczonej smart terrainem - jednak do utworzenia tylko smart terrain'a (dla NPC) - wystarczy, iż zrealizujemy punkty poradnika: 1, 2, 3, 4.1, 5 i 6. Pozostałe wskazówki stanowią uzupełnienie obozu o model ogniska, ogień, poświatę etc. - można bez ich pomocy stworzyć smart terrain, jednak efekt będzie taki, iż stalkerzy będą siedzieli naprzeciw siebie na pustej polanie. Czym byłby Stalker bez klimatycznych ognisk? Chcąc cieszyć się pełnym efektem - warto przeanalizować całość poradnika, którego efekt finalny jest wart włożonej pracy. Wadą tej metody jest czas oczekiwania na respawn obiektu, który przyśpieszyć jednak można poprzez implementację moda np. na śpiwór. W niektórych przypadkach aby smart terrain zrestartował - zwłaszcza gdy wprowadzamy obiekty na danej mapie niewystępujące pierwotnie, wówczas należy zmienić lokację - przykład takiej sytuacji znajdziemy w rozdziale poradnika dot. smart terraina pijawek na Kordonie (końcowy rozdział poradnika).

 

Część właściwa poradnika: spawn obiektów.

 

• Po zainstalowaniu Smartterrain and Waypoint Tools by dez0wave, zbieramy dane terenowe dotyczące spawnowanych obiektów. Najprostszą formą smart terrain'a jest ognisko (nie wymaga zdefiniowania ścieżek patrolowych), przy którym stalkerzy będą snuli opowieści o cudach Zony. Aby stworzyć w pełni funkcjonalne ognisko - nie wystarczy obszar, w promieniu którego skupią się NPC, dodać musimy również model ogniska, sam ogień, poświatę oraz rzecz jasna - nasz smart terrain. Będę potrzebował następujących współrzędnych - wyciąg z loga uzyskany dzięki Smartterrain and Waypoint Tools by dez0wave:
  

  ! Unknown command:  patrolName=spawn_modelu_ogniska|anim=p1|sig=s1|pos=-207.39770507813,-20.337919235229,-169.73512268066|game=50|level=45903* Log file has been saved successfully!! Unknown command:  patrolName=spawn_smart_terraina|anim=p1|sig=s1|pos=-207.35034179688,-20.336498260498,-169.73164367676|game=50|level=45903* Log file has been saved successfully!! Unknown command:  patrolName=spawn_dla_way_ltx|anim=p1|sig=s1|pos=-207.46408081055,-20.339685440063,-169.71632385254|game=50|level=45903* Log file has been saved successfully!! Unknown command:  patrolName=light_1|anim=s1|sig=p1|pos=-207.4836730957,-20.32960319519,-168.48292541504|game=50|level=45904* Log file has been saved successfully!! Unknown command:  patrolName=light_2|anim=s2|sig=p2|pos=-205.34201049805,-20.317893981934,-169.54710388184|game=50|level=47815* Log file has been saved successfully!! Unknown command:  patrolName=light_3|anim=s3|sig=p3|pos=-207.49937438965,-20.357049942017,-171.50830078125|game=50|level=45900* Log file has been saved successfully!! Unknown command:  patrolName=light_4|anim=s4|sig=p4|pos=-209.22709655762,-20.384145736694,-169.54151916504|game=50|level=43915* Log file has been saved successfully!! Unknown command:  patrolName=ogien_1|pos=-207.34364318848,-20.324412918091,-169.62983703613|game=50|level=45903

  
  
  Powyższe współrzędne znajdują się w obozie nowicjuszy na kordonie, każdy parametr jest opisany: patrz wpis po Name, ale na uwagę zasługują punkty:
  □ spawn_dla_way_ltx -  współrzędne punktu potrzebne w pliku way_...ltx - są one b. podobne do współrzędnych smart terrain'a, jednakże nie takie same. Pamiętajmy aby koordynaty dla smart terraina umieszczenego w alife_...ltx i punktu way_...ltx nie były takie same. Wystarczy drobne przesunięcie aktora względem pozycji spawnu pierwszego punktu i zebranie danych terenowych o innych wartościach. Nie używajmy jednego punktu do określenia wartości pozycji w 2 różnych plikach! 
  □ light_1, light_2, light_3, light_4 - W punktach light - będę spawnował poświatę, którą daje ognisko. Trzeba bowiem wiedzieć, iż sam ogień z ogniska nie wystarczy by rozświetlić obszar wokół niego, trzeba zespawnować punkty świetlne, które dadzą sprzyjający klimatowi - poblask. Punkty te nie są wymagane - ale jeśli chcemy odpowiedniego efektu - należy je umieścić po obwodzie ogniska.

• Dekompiluję plik all.spawn zgodnie z poradnikiem - link.
• Dodaję obiekty w Kordonie, zatem będę modyfikował pliki:
  □ alife_l01_escape.ltx
  □ way_l01_escape.ltx
• Do pliku alife_l01_escape.ltx dodaję następujące wpisy ze współrzędnymi, które obrałem uprzednio: (Zapamiętaj: utrzymuj 2 wierszowe odstępy pomiędzy spawnowanymi obiektami!)
  4.1. pierwszy obiekt to nowy smart terrain
  

  [8641]; cse_abstract propertiessection_name = smart_terrainname = esc_smart_stalker_empposition = -207.35034179688,-20.336498260498,-169.73164367676direction = 0,0,0; cse_alife_object propertiesgame_vertex_id = 50distance = 7level_vertex_id = 45903object_flags = 0xffffff3ecustom_data = <<END[smart_terrain]type = general_lagercapacity = 3communities = stalkergroups = 7END; cse_shape propertiesshapes = shape0shape0:type = sphereshape0:offset = 0,0,0shape0:radius = 3.79640030860901; cse_alife_space_restrictor propertiesrestrictor_type = 0; se_smart_terrain properties

  Najbardziej istotne wpisy - omówienie:

  □ section_name = smart_terrain ten wpis charakteryzuje typ obiektu jako obozowisko (jest taki sam zarówno dla NPC jak i mutantów).

  □ name - nazwa naszego smart terraina, która będzie wykorzystana w pliku way_...ltx

  □ position - pozycja obiektu: X,Y,Z

  □ direction - obrót (tutaj możemy ustawić 0,0,0 ponieważ obiekt jest sferą)

  □ game_vertex_id, level_vertex_id - punkty wierzchołkowe uzyskane dzięki Smartterrain and Waypoint Tools by dez0wave.

  □ type - typ smart terraina, gdy tworzymy unikalny obóz wpis: type = name (zawarty w pliku alife_...ltx), natomiast general_lager - stosuje się dla losowo wybranych przez grę NPC'ów tj. obóz ogólny - rozpatrywany w przykładzie.

  □ capacity - ilość obsługiwanych NPC (bądź mutantów). Dla ognisk ilość optymalna to 3, max = 4 osoby. Przy większej ilości - NPC przepychają się nawzajem - by zająć pozycję, często kończy się to ich zawieszeniem, bądź wepchnięciem w ognisko - dlatego nie przesadzajmy z ilością!

  □ communities - frakcja (bądź rodzaj mutanta) który będzie przypisany do naszego smart terrain'a

  □ groups - liczba grupy, parametr związany z respawnem (testowałem wartości do. max 10).

  □ radius - promień sfery smart terrain'a, wartość której nie musimy zmieniać ponieważ to nie ona decyduje o średnicy zasięgu działań NPC/mutantów!

  □ restrictor_type = 0 ;zawsze dla tego typu obozowiska tj. typu general_lager wartość wynosi 0!
   

  4.2. Następny dodawany obiekt: model ogniska. Do pliku alife_l01_escape.ltx dodajemy, zwracając uwagę na numerację:

  [8642]; cse_abstract propertiessection_name = physic_objectname = esc_ognisko_0001position = -207.39770507813,-20.437919235229,-169.73512268066direction = 0,0,0; cse_alife_object propertiesgame_vertex_id = 50distance = 0level_vertex_id = 45903object_flags = 0xfffffffacustom_data = <<END[collide]ignore_staticEND; cse_visual propertiesvisual_name = objectskosterok_gorit; cse_ph_skeleton propertiesskeleton_name =; cse_alife_object_physic propertiesphysic_type = 0x3mass = 10000fixed_bones = bone01

  Ważne: w oryginalnym SoC nie występuje obiekt kosterok_gorit, zatem musimy dodać do naszego gamedata. W katalogu objects [gamedatameshes] umieszczam model kosterok_gorit.ogf (wycięty z Solijanki) - zgodnie z parametrem visual_name.

  □ fixed_bones = bone01 - ów wpis służy przytwierdzaniu obiektów do podłoża. Gdyby nie został dodany - NPC przepchnęliby model ogniska - dlaczego? W Stalkerze podczas kompilacji map - generuje się tzw. siatkę AI, która umożliwia NPC'om/mutantom właściwe przemierzanie obszaru - bez siatki NPC/mutant "nie widzi" przeszkód w postaci obiektów fizycznych - jak ściany, bloki betonowe, przyczepy, drzewa etc. Zwróćmy uwagę na poniższy screen:

  

  Na pierwszym planie mamy pniak, wokół którego wektory siatki są zorientowane inaczej niż dla płaszczyzny pozbawionej przeszkód. Jeśli dodajemy obiekt, wówczas tworzymy na płaszczyźnie siatki, której element ma charakter czterokierunkowy (pn-płd-wsch-zach) - nie będzie on widoczny dla NPC, ponieważ siatka - tworzona w SDK, nie rozkłada się wokół obiektów dodanych w późniejszym czasie. NPC widzi zatem teren pozbawiony przeszkody i stara się go przejść, aż trafi na zespawnowany obiekt. Przykłady braku wyobraźni modderów w tym względzie widać np. w Solijance - gdzie obok Prapora pilnującego przejścia na Bar, stała skrzynia  - którą niejednokrotnie chciał przepchnąć strażnik. Wracając do meritum pkt. 4.2 - musimy obniżyć położenie obiektu w osi Y (korekta została uwzględniona w pkt.1 oraz 4.2):

  zmieniamy wartość Y: -20.33 na -20.43

  dzięki czemu, NPC łatwiej pokona przeszkodę - ponieważ ją obniżymy. Ja obrałem wartość obniżenia o 0.1, możemy poeksperymentować z wartością obniżając obiekt o 0.08 lub mniej - jednak dla tej wysokości obiektu - wartość 0.1 jest adekwatna.

  fixed_bones = bone01

  bone01 - kość modelu .ogf, którą przytwierdzamy do gruntu. Każdy obiekt posiada inne kości składające się na model, zatem mamy dwie możliwości sprawdzenia modelu:

  □ z użyciem programu do modelowania 3D, ja wykorzystałem Milkshape 1.8.4 (do otwarcia modelu .ogf należy pobrać odpowiedni plugin), który możemy w wersji trial testować przez 30 dni.

  

  □ otwierając model za pomocą Notepad ++ i szukając po frazie bone, jednak w przypadku gdy kości jest wiele - nie wiemy, która z nich znajduje się najbliżej podłoża - za taką kość należy przytwierdzać nasz model!

  

  4.3  Do pliku alife_l01_escape.ltx dodaję wpisy, których współrzędne znajdziemy w pkt.1 poradnika (light_1, light_2, light_3, light_4) odpowiedzialne za poświatę ogniska:

  [8643]; cse_abstract propertiessection_name = lights_hanging_lampname = lights_ognisko_0001position = -207.4836730957,-20.32960319519,-168.48292541504direction = 0,0,0; cse_alife_object propertiesgame_vertex_id = 50distance = 0level_vertex_id = 45904object_flags = 0xffffffba; cse_visual properties; cse_ph_skeleton properties; cse_alife_object_hanging_lamp propertiesmain_color = 0xfffab807main_brightness = 0.400000005960464main_color_animator = kostermain_range = 6light_flags = 0x2ahealth = 100main_virtual_size = 0.100000001490116ambient_radius = 2ambient_power = 0.400000005960464main_cone_angle = 2.09439516067505glow_radius = 0.699999988079071[8644]; cse_abstract propertiessection_name = lights_hanging_lampname = lights_ognisko_0002position = -205.34201049805,-20.317893981934,-169.54710388184direction = 0,0,0; cse_alife_object propertiesgame_vertex_id = 50distance = 0level_vertex_id = 47815object_flags = 0xffffffba; cse_visual properties; cse_ph_skeleton properties; cse_alife_object_hanging_lamp propertiesmain_color = 0xfffab807main_brightness = 0.400000005960464main_color_animator = kostermain_range = 6light_flags = 0x2ahealth = 100main_virtual_size = 0.100000001490116ambient_radius = 2ambient_power = 0.400000005960464main_cone_angle = 2.09439516067505glow_radius = 0.699999988079071[8645]; cse_abstract propertiessection_name = lights_hanging_lampname = lights_ognisko_0003position = -207.49937438965,-20.357049942017,-171.50830078125direction = 0,0,0; cse_alife_object propertiesgame_vertex_id = 50distance = 0level_vertex_id = 45900object_flags = 0xffffffba; cse_visual properties; cse_ph_skeleton properties; cse_alife_object_hanging_lamp propertiesmain_color = 0xfffab807main_brightness = 0.400000005960464main_color_animator = kostermain_range = 6light_flags = 0x2ahealth = 100main_virtual_size = 0.100000001490116ambient_radius = 2ambient_power = 0.400000005960464main_cone_angle = 2.09439516067505glow_radius = 0.699999988079071[8646]; cse_abstract propertiessection_name = lights_hanging_lampname = lights_ognisko_0004position = -209.22709655762,-20.384145736694,-169.54151916504direction = 0,0,0; cse_alife_object propertiesgame_vertex_id = 50distance = 0level_vertex_id = 43915object_flags = 0xffffffba; cse_visual properties; cse_ph_skeleton properties; cse_alife_object_hanging_lamp propertiesmain_color = 0xfffab807main_brightness = 0.400000005960464main_color_animator = kostermain_range = 6light_flags = 0x2ahealth = 100main_virtual_size = 0.100000001490116ambient_radius = 2ambient_power = 0.400000005960464main_cone_angle = 2.09439516067505glow_radius = 0.699999988079071

  4.4 Do pliku alife_l01_escape.ltx dodaję wpis odpowiedzialny za ogień.

   

  [8647]; cse_abstract propertiessection_name = zone_flame_smallname = esc_ogien_0001position = -207.34364318848,-20.324412918091,-169.62983703613direction = 0,0,0; cse_alife_object propertiesgame_vertex_id = 50distance = 3.5level_vertex_id = 45903object_flags = 0xffffff3e; cse_shape propertiesshapes = shape0shape0:type = sphereshape0:offset = 0,0,0shape0:radius = 0.64168655872345; cse_alife_space_restrictor propertiesrestrictor_type = 0; cse_alife_custom_zone propertiesmax_power = 0; cse_alife_anomalous_zone propertiesoffline_interactive_radius = 3artefact_spawn_count = 32artefact_position_offset = 0x1380

  Po dodaniu powyższego wpisu, warto zmodyfikować odpowiedzialny za obrażenia zadawane od ognia  - plik zone_kampfire.ltx [gamedataconfigmisc]
  w pliku tym zmieniamy wartości dla [zone_flame_small] wiersz 417 i 418 w pliku z niemodowanego SoC 1.0004:

  min_start_power        = 0.39max_start_power        = 0.40

  na:

  min_start_power        = 0max_start_power        = 0

  Eliminując obrażenia od ognia. Jest to uzasadniona zmiana, ponieważ - zgodnie z tym co pisałem w pkt. 4.2 - NPC nie będzie widział tego ogniska i aby nie zginął w płomieniach - należy pozbawić ogień obrażeń.

• Do pliku way_l01_escape.ltx - osiągalnym po dekompilacji all.spawn, dodajemy następujący wpis zachowując 2 wierszowy odstęp pomiędzy sekcjami kolejnych punktów.

  [esc_smart_stalker_emp_kamp_1]points = p0p0:name = name00p0:position = -207.46408081055,-20.339685440063,-169.71632385254p0:game_vertex_id = 50p0:level_vertex_id = 45903

  gdzie:

  □ esc_smart_stalker_emp jest prefixem odnoszącym się do naszego smart terraina z pliku alife_l01_escape.ltx. Jakkolwiek nie nazwiemy naszego smart terraina, jego nazwa musi być zawarta w pliku way_...ltx i być zgodna z zdefiniowanym przez nas obozem - patrz pkt. 4.1 - name.

  □ kamp_1 [przyrostek: kamp]: zawsze dla ognisk umieszczamy występujący po nazwie smart terraina wpis kamp z odpowiednią numeracją (jak w przykładzie) - jest to sposób definiujący układ smart terraina jako obóz, tzn. NPC w oddaleniu od punktu bazowego o defaultową wartość promienia równą 2 metry. kamp jest stałą częścią skałdającą się na: nazwa_smart_terraina_kamp_1. Kamp - warunkuje określony typ obozowiska. Ważne jest aby nazwa smart terrain'a nie zawierała spacji.

• Po wprowadzeniu wpisów do plików: alife_l01_escape.ltx, way_l01_escape.ltx - zapisuję zmiany i kompiluję plik all.spawn, który umieszam w katalogu z grą: gamedataspawns

• Efekt naszej pracy to nowy obóz, którego znacznik przedstawia się następująco (zwróćmy uwagę na nazwę zgodną z nadaną w pkt. 4.1, górny znacznik odpowiada pierwotnemu smart terrain'owi obozowiska kotów, dolny znacznik screen'a - nasz nowy obóz)

  

• Korzystając z metody uproszczonej nie muszę tworzyć NPC, ponieważ pojawią się po upływie od 8 do 16 godz. (warto użyć moda na śpiwór i przyśpieszyć czas) w wyniku respawnu, którego częstotliwość opisuje plik se_respawn.script, jednak nie musimy go modyfikować. Gra wykona tę część pracy za nas! - musimy tylko cierpliwie poczekać czas przeznaczony na respawn. (respawnu stalkerów nie muszę tworzyć, ponieważ już istnieje i to zostanie wykorzystane dla ułatwienia nam pracy).

 

Pamiętajmy:, korzystamy z metody uproszczonej, gdzie spawn obiektów jest realizowany przez skrypt [se_respawn.script]. W następnym poradniku zapoznamy się z metodami pozwalającymi na tworzenie charakterystycznych NPC, ścieżek patrolowych, snajperów etc. - najlepsze przed nami!

P.S. Dodając na określonej lokacji NPC, sprawdźmy czy jego sekcja występuje w plikach [gamedataconfigmisc]: general_lager.ltx oraz smart_terrain_presets.ltx.

 

 

 

Tworzenie smart terrain'a dla mutantów [general_lair]: metoda uproszczona.

 

Metoda uproszczona opiera się o wykorzystanie respawnu mutantów, toteż efekt naszej pracy nie będzie natychmiastowy tylko zależny od częstotliwości respawna - pamiętajmy o tym! W przykładzie smart terrain dla 3 snorków w kordonie.

 

• Standardowa procedura zbierania danych terenowych (koordynaty: X,Y,Z, game_vertex_id, level_vertex_id) rozpoczyna etap wstępny: Poniżej punkty zebrane do zespawnowania potrzebnych elementów smart terraina (zawierają właściwe opisy).
  

  ! Unknown command:  patrolName=snork_smart_terrain|anim=p1|sig=s1|pos=2.3360643386841,-16.228755950928,-142.29521179199|game=108|level=278506* Log file has been saved successfully!! Unknown command:  patrolName=snork_way_ltx|anim=p1|sig=s1|pos=2.0729126930237,-16.054887771606,-141.61898803711|game=108|level=278507* Log file has been saved successfully!Dla respawna obrałem odległość ok. 40 metrów od smart terrain'a! Unknown command:  patrolName=respawn_snork|anim=s1|sig=p1|pos=17.95068359375,-8.5842018127441,-106.66184997559|game=110|level=295951* Log file has been saved successfully!

• Moim zamiarem jest stworzenie obozowiska snorków w Kordonie , więc po dekompilacji pliku all.spawn, będę potrzebował tylko 2 plików:
  □ alife_l01_escape.ltx
  □ way_l01_escape.ltx
• Do pliku alife_l01_escape.ltx dodaję sekcję odpowiedzialną za smart terrain:

  
  

  [8648]; cse_abstract propertiessection_name = smart_terrainname = esc_smart_monster_1position = 2.3360643386841,-16.228755950928,-142.29521179199direction = 0,0,0; cse_alife_object propertiesgame_vertex_id = 108distance = 10.8999996185303level_vertex_id = 278506object_flags = 0xffffff3ecustom_data = <<END[smart_terrain]type = general_laircapacity = 3communities = snork;squad = 1;groups = 5stay = longEND; cse_shape propertiesshapes = shape0shape0:type = sphereshape0:offset = 0,0,0shape0:radius = 1; cse_alife_space_restrictor propertiesrestrictor_type = 0; se_smart_terrain properties 

  Ponieważ większość opisu parametrów jest zgodna z pkt. 4.1 (dot. smart terraina dla NPC), toteż do niego odsyłam. To co interesuje nas przy definiowaniu obozowiska:
  □ name - nazwa naszego smart terraina, która będzie wykorzystana w pliku way_...ltx
  □ type = general_lair - ogólny typ obozowiska, w którym za dobór mutantów odpowiada gra. Ten typ nie daje możliwości przypisania charakterystycznego mutanta do smart terrain'a. Jeśli chcemy stworzyć zadanie na wzrór Solijanki, gdzie polowaliśmy na czerwonego pseudogiganta - musimy stworzyć inny niż metodą uproszczoną - typ smart terrain'a.
  □ communities - tutaj podajemy rodzaj mutanta, ale nie stosujemy rozróżnienia na weak/normal/strong np.snork_strong. Tutaj możemy posiłkować się wpisami zawartymi w plikach mutantów m_*.ltx [gamedataconfigcreatures]. Np. dla m_snork.ltx w sekcji [snork_weak] znajduje się wpis
  

  community = snork

  Pamiętajmy o tej uwadze! 

  □ capacity - dopowiada za ilość mutantów obsługiwanych przez smart terrain.

  □ stay [quick/medium/long/default] - czas (gry - nie czas zegarowy) przebywania w obozie, jednak parametr jest opcjonalny. Jego wartości znajdziemy w pliku smart_terrain.ltx [gamedataconfigmisc]. Nigdy nie testowałem go dla wszystkich opcji, jednak warto posłużyć się analogią definiując czas przebywania na podst. istniejących obozowisk, które z narzędziem Smartterrain and Waypoint Tools by dez0wave możemy z łatwością zlokalizować, uprzednio sprawdzając pliki w których parametr stay ma wartości: quick/medium/long/default. Możemy stworzyć kilka podobnych obozów celem sprecyzowania interesujących nas różnic.

  □ groups (opcjonalnie) - odpowiada za liczbę grup przydzielonych do zadania. W razie braku jej wpisania - gra ustawi wartość defaultową. 

  □ squad (opcjonalnie) - skład wszystkich obiektów przypisanych smart terrain'owi, w przypadku redukcji ilości postaci (eliminacja obozu) gra będzie odzyskiwała oryginalną ilość. Chciałbym zaznaczyć jedną rzecz, mianowicie: nie ustaliłem korelacji pomiędzy groups a squad, wartości dobieram posiłkując się istniejącymi obozowiskami. Jeśli znajdzie się osoba, króra będzie znała odpowiednie powiązanie? - proszę o pisanie w temacie. 

  □ shape0:type = sphere - kształt obszaru smart terrain'a - w przykładzie sfera o promieniu 1.

  □ restrictor_type = 0 - dla obozów typu general_lair wartość wynosi zawsze 0. Patrz pliki alife_...ltx po dekompilacji all.spawn

• do pliku alife_l01_escape.ltx dodaję sekcję odpowiedzialną za respawn snorków (zachowując obraną numerację obiektów), ponieważ w niemodowanym SoC nie występuje respawn snorków dla Kordonu. - wpis poniższy należy umieścić.

  [8649]; cse_abstract propertiessection_name = respawnname = esc_snork_respawnposition = 17.95068359375,-8.5842018127441,-106.66184997559direction = 0,0,0; cse_alife_object propertiesgame_vertex_id = 110distance = 1.39999997615814level_vertex_id = 295951object_flags = 0xffffff3ecustom_data = <<END[respawn]respawn_section = snork_weak;max_count = 15;min_count = 10max_spawn = 3idle_spawn = seldomEND; cse_shape propertiesshapes = shape0shape0:type = sphereshape0:offset = 0,0,0shape0:radius = 1; cse_alife_space_restrictor propertiesrestrictor_type = 0; se_respawn properties

  
  Parametry podstawowe zostały omówione w pkt. 4.1 dla smart terraina NPC oraz pkt 3 - dla smart terraina mutanta.
  □ respawn_section - tutaj określamy szczegółowy typ mutanta weak/normal/strong - wpisy dla poszczególnych potworów znajdziemy w plikach m_*.ltx [gamedataconfigcreatures],wykaz mutantów znajdziemy w pliku monsters.ltx katalog j/w.
  * - nazwa mutanta
  przykładowe sekcje pliku m_snork.ltx - nazwy ujęte w nawias [ ]: snork_weak, snork_normal, snork_strong.
  □ max_spawn - liczba max. spawnu potworów/cykl 8 godzinny**. Jeśli nasz smart terrain obsługuje 3 potwory - ustawiamy ilość respawnu na max.3 (wartośći 1-3) liczbę użależniamy zawsze od ilości obsługiwanych jednostek
  **cykl respawnu często jest większy niż 8. godz., w niektórych przypadkach respawn następuje w cyklu 24 godzinnym.
  □ idle_spawn - określa częstotliwość respawnowania, która zdefiniowana jest w pliku se_respawn.script [gamedatascripts]. Do wyboru mamy: seldom, medium, often. W niemodowanym SHOC wartości dla każdego przypadku są takie same.
  czasami występuje również opcjonalny parametr conditions, od zdefiniowania którego zależy czynny/bierny tryb pracy smart terrain'a, np. stworzenie obozowiska, które będzie aktywne w przypadku wypełnienia określonego zadania. Jeśli spotkamy się z sytuacją, iż
  

  ;conditions

  średnik oznacza wyłączenie wiersza z użycia.
• Do pliku way_l01_escape.ltx dodaję wpis wiążący esc_smart_monster_1 z przyrostkiem: home_1. (zachowuję 2 wierszowe odstępy między kolejnymi sekcjami):
  

  [esc_smart_monster_1_home_1]points = p0p0:name = name00p0:position = 2.0729126930237,-16.054887771606,-141.61898803711p0:game_vertex_id = 108p0:level_vertex_id = 278507

  Ważne:

  □ home - przyrostek (stojący przy nazwie smart terrain'a) warunkuje określony typ zachowań potworów (zajmowanie określonej powierzchni, której mutant bezwzględnie się trzyma), które są do niego przypisane.

• Ponieważ na kordonie nie występują mutanty, które mam zamiar dodać, muszę uzupełnić plik general_lair.ltx [gamedataconfigmisc]. Pierwotna postać wpisów dla Kordonu:
  

  [l01_escape]boar         =    weak, normalflesh        =    weak, normaldog          =    weak, normalpseudodog    =    weakzombie       =    weak

  dodaję wpis uwzględniający snorki:
  

  snork        =    weak, normal, strong

  Zapisując zmiany.
• Kolejny plik, który muszę uzupełnić to smart_terrain_presets.ltx [gamedataconfigmisc]. W sekcji odpowiedzialnej za level, na którym realizuję spawn smart terraina - w przykładzie:
  

  [l01_escape]stalker     = novice, experiencedmilitary    = novice, experienced, veteranbandit      = novice, experiencedboar        =    weak, normalflesh       =    weak, normaldog         =    weak, normalpseudodog   =    weak

  Dodaję wpis odpowiedzialny za snorki:
  

  snork        =    weak

  ponieważ w pliku alife_l01_escape.ltx w sekcji respawna  - dodawałem:
  

  respawn_section = snork_weak

• Zapisuję zmiany w modyfikowanych plikach i przystępuję do kompilacji all.spawn, który w wersji finalnej umieszam w katalogu z grą: gamedataspawns - sprawdzając rezultat.

Najwięcej błędów bierze się z niewłaściwego dobrania sekcji mutanta tj. weak/normal/strong względem wpisów występujących w smart_terrain_presets.ltx oraz general_lair.ltx.

 

 

Przykład dodatkowy: legowisko pijawek w Kordonie.

 

Daję przykład do wglądu, ponieważ za pomocą zawartych tutaj wskazówek, można będzie odtworzyć to obozowisko, które jednak wymaga zmiany lokacji, aby smart terrain został aktywowany (zmiana znacznika z koloru szarego na żółty). Zmiana czasu w tym przypadku nie wpływała na pojawienie się potworów, których obecność spowodowała podjęcie pracy przez utworzony smart terrain. Screen przedstawia obozowisko oczekujące na respawn pijawek:

Jeśli tworząc dane obozowisko - jesteśmy pewni, że wszystko zostało wykonane prawidłowo, warto spróbować zmiany lokacji połączonej z przyśpieszeniem (dla testów) czasu rozgrywki. W przykładzie wykorzystam te same nazwy i współrzędne - jak dla legowiska snorków z pkt. od 1 do 6.

• W pliku alife_l01_escape.ltx - umieszczam wpis odpowiadający za smart terrain pijawek oraz ich respawn.

  
  

  [8648]; cse_abstract propertiessection_name = smart_terrainname = esc_smart_monster_1position = 2.3360643386841,-16.228755950928,-142.29521179199direction = 0,0,0; cse_alife_object propertiesgame_vertex_id = 108distance = 10.8999996185303level_vertex_id = 278506object_flags = 0xffffff3ecustom_data = <<END[smart_terrain]type = general_laircapacity = 2communities = bloodsuckersquad = 1groups = 5;stay = longEND; cse_shape propertiesshapes = shape0shape0:type = sphereshape0:offset = 0,0,0shape0:radius = 1; cse_alife_space_restrictor propertiesrestrictor_type = 0; se_smart_terrain properties[8649]; cse_abstract propertiessection_name = respawnname = esc_respawn_bloodsuckerposition = 17.95068359375,-8.5842018127441,-106.66184997559direction = 0,0,0; cse_alife_object propertiesgame_vertex_id = 110distance = 6.39999997615814level_vertex_id = 295951object_flags = 0xffffff3ecustom_data = <<END[respawn]respawn_section = bloodsucker_weakmax_count = 25min_count = 10max_spawn = 2idle_spawn = seldomEND; cse_shape propertiesshapes = shape0shape0:type = sphereshape0:offset = 0,0,0shape0:radius = 1; cse_alife_space_restrictor propertiesrestrictor_type = 0; se_respawn properties

• W pliku way_l01_escape.ltx dodaję współrzędne punktu (w pobliżu smart terrain'a - warto porównać koordynaty X,Y,Z) legowiska.
  

  [esc_smart_monster_1_home_1]points = p0p0:name = name00p0:position = 2.0729126930237,-16.054887771606,-141.61898803711p0:game_vertex_id = 108p0:level_vertex_id = 278507

• Zapisuję zmiany i kompiluję plik all.spawn. - sprawdzam rezultat pracy, który powinien wyglądać następująco:
  
• Jeśli  na danej lokacji nie występuje mutant, którego obozowisko tworzymy - uzupełniamy pliki [gamedataconfigmisc]: 
  □ general_lair.ltx w sekcji danego level'u - w przykładzie:
  

  [l01_escape]bloodsucker    =    weak, normal, strong

  □ smart_terrain_presets.ltx
  

  [l01_escape]bloodsucker    =    weak

  analogicznie jak w przypadku dodawania snorków - opis pkt. 6 i 7.
   

Jeśli przyswoimy sobie podstawy tworzenia tego typu obozowisk, możemy w kilku punktach zrealizować spawn naszego smart terrain'a.

 

Składam ekipie dez0wave serdeczne podziękowania za stworzenie Smartterrain and Waypoint Tools, które zarówno pod względem funkcjonalności jak również precyzji pracy - jest bezkonkurencyjne wśród wielu podobnych narzędzi modderskich, na których miałem okazję pracować. Niech to podziękowanie będzie wyrazem szacunku za pracę włożoną w rozwój S.T.A.L.K.E.R.A

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

_____________________________

Autor: The Emperor dla StalkerTeam

[PMG]

Jako iż jestem nowym użytkownikiem to chciałbym Was wszystkich serdecznie przywitać. ;)

 

Wiem, że tutorial ten jest dość stary (choć i tak pomocny i genialny), ale potrzebuję pomocy. Mam dość spory problem ze spawnem, a właściwie respawnem. Otóż stworzyłem respawn mutanta kota w Kordonie oraz general_lair (z sekcją "capacity = 3"), który jest mu poświęcony. Następnie skopiowałem ten spawn i lair do Doliny Mroku, zmieniając oczywiście położenie i vertexy. Następnie edytowałem pliki general_lair.ltx i smart_terrain_presents.ltx.

 

Na samym początku wszystko szło gładko. Po małym teleporcie na Wysypisko i z powrotem, w Kordonie rzeczywiście pojawiły się koty. Ale zaraz... dlaczego jest ich aż 6? Przeniosłem się do Doliny Mroku, gdyż miałem już pewną hipotezę. Niestety, okazała się prawdziwa. Otóż w Dolinie Mroku nie było żadnych kotów, gdyż wszystkie były w Kordonie... Mam więc pytanie: dlaczego koty postanowiły zespawnować się w Kordonie, a nie w Dolinie Mroku? A poza tym dlaczego gra olała sekcję "capacity = 3" i general_lair nagle zaczął obsługiwać aż 6 mutantów? Z góry dziękuję za pomoc i pozdrawiam.

[Gość]

Ktoś wie skąd można pobrać wersję acdc pod Soljankę OP2?

BTW Skąd można pobrać mapki do multiplayera bo bym chciał je zaimplementować do Soljanki do singleplayer.

Edytowane 10 Marca 2016 przez Kacper777777

[cichy]

Tutaj masz wszystko: http://bar-reaktor.ru/forum/310-2846-1

[Gość]

Żadna z wersji ACDC z tego linka nie działa dla modów. Nikt nie wie czegokolwiek na temat rozpakowania all.spawn Solianki? Ja próbowałem universal acdc 1.38 ale mam błąd w jednym z plików stkutils i nie mogę nic zrobić. Może ktoś wypakowywał all.spawn Solianki OP2 i podzieli się linkiem?

[LVutner]

soljanka była edytowana chyba jakimś edytorem, xrspawnem bodaj. Szukaj adcd na ruskich forach

[Gość]

EDIT
Znalazłem taki filmik wpisując w wyszukiwarkę acdc Solyanka po rosyjsku. 
www.youtube.com/watch?v=BNJ-Vbc5RZ4
Co prawda na filmiku nie ma OP2, ale jest DMX 1.3.5, który jest jedną z wcześniejszych wersji Solyanki. Od razu mam pytanie bo nie chce mi się grzebać po tematach - czy są duże różnice między DMX 1.3.5 a Narodnaya Solyanka OP2? Zwłaszcza chodzi mi o lokacje. Bo jeśli w DMX-ie są wszystkie te same lokacje co w OP2 to najwyżej pobiorę DMX-a i rozpakuję jego all.spawn. Potem może spróbuję zaadaptować zmiany do OP2 kopiując odpowiednie pliki (ale to już opcjonalnie).
Problem tkwi w tym, że nie wiem skąd pobrać te wszystkie wersje ACDC, które widać na filmiku od 1.13. Gdy wpisuję w wyszukiwarce ich nazwy to nie ma żadnych wyników. Nie wiem jak gościu mógł zrobić taki filmik i nawet nie dać linka, skąd pobrał ten ACDC.

[Gość]

A xrSpawnerem można robić to samo co ACDC? Tzn. oprócz spawnowania tworzyć obozowiska, ścieżki patrolowe, wyznaczać kierunki patrzenia NPC-ów etc? 
Czy żeby pracować xrSpawnerem to muszę mieć wypakowany all.spawn tak jak w przypadku ACDC?
Jeśli nie muszę to będę modował mody xrSpawnerem.
Tylko pytanko - czy też jest tak dużo jego wersji jak ACDC i czy do Solianki muszę odpowiedni pobrać czy obojętne jaki xrSpawner mam?

Pobrałem takie coś 
http://stalkerin.gameru.net/modules.php ... ned&lid=84
To najnowsza wersja?

Nie wierzę, żeby nie było możliwości modowania modów. Przecież jak stworzono pierwszą wersję Solyanki, a potem następną (DMX) to w tej następnej na pewno plik all.spawn już był inny, a w jeszcze kolejnej (OOP) jeszcze inny, i inny w OP2. Zatem jakiś sposób musi być.