У скриптах є одна єдина функція, що відповідає за спавн об'єктів:
Перший параметр - секція в конфігураціях, що описує об'єкт, наприклад "bolt", "med_kit" - це прості секції, простих об'єктів а є об'єкти, які переходять в онлайн / оффлайн, це непісям, монстри і так далі, наприклад mil_killer_respawn_2 - спавна снайпер угруповання кілерів.
З позицією, думаю пояснювати не треба, тільки існує нюанс - висота це Y, а не Z. Задати позицію можна такою конструкцією vector (): set (x, y, z), де x, y і z - координати точки на рівні, де спавн об'єкт.
Далі складніше, так як сам толком сформулювати не можу.
Почнемо від простого до складного. На кожному рівні багато об'єктів, всі об'єкти складаються з полігонів, у кожного полігону є вершини - вертекси.
Саме вони і повинні тут бути вказано, навіщо - не особливо розумію, швидше за все для точного позиціонування об'єкта. Наприклад, можна отримати вертекс найближчий до актору - db.actor:level_vertex ()
Далі йде набагато цікавіший параметр game_vertex, це майже те ж саме, що і level_vertex, але (!) Це глобальні величини! Якщо level_vertex вважається для рівня, то game_vertex - для всієї гри, і потрібен він для того, щоб вказати на якій карті спавн об'єкт (більш зрозумілого пояснення я не знайшов).
Відповідно, щоб заспавніть що-небудь на іншій карті, досить вказати game_vertex в четвертому параметрі Наприклад:
Отже, щоб, наприклад, заспавніть болт під ногами актора, пишемо:
Чому 1, а не level_vertex? Перевірено - різниці особливої немає, який level_vertex, хоча в деяких випадках треба прописувати валідний вертекс, а то предмет може просто заспавнітся не там, де планувалося. Але здебільшого все проходить нормально і з одиницею. (Ігнорування level_vertex може призводити до провалювання вироблених предметів / персонажів під землю.) А ось game_vertex вирішує все - він вказує на якому рівні спавн предмет, тому його треба вказувати. Теоретично можна просто знайти для кожного рівня по одному game_vertex'у і використовувати їх в скриптах. Насправді game_vertex показує який фрагмент карти використовується (вся карта розбита на шматки мають наскрізну нумерацію по всіх рівнях і game_vertex вибирає потрібний) соответсвенно неправильне використання черевато.
Крім того - є ще один параметр - ID об'єкта, якщо вказати ID NPC або актора - то предмет заспавнітся у нього в інвентарі.
Приклад (спавн артефакт Медуза в інвентарі у актора):
Функція спавна повертає серверний об'єкт, тобто ні NPC, ні монстра ні що-небудь ще.
Серверний об'єкт дозволяє свіжо створеного NPC або схованку затарить різними Рулез / артефактами. Наприклад, ось так створимо перед входом до Сидоровичу долговца і засунь в нього пачку патронів:
Просто мінімальний набір - координати, ID, секція, а з нього (серверного об'єкта) зазвичай потрібен тільки ID, так як по ID можна отримати цей самий серверний об'єкт:
Його можна використовувати, щоб поставити мітку, наприклад, але я його особисто використовую для інших цілей - спавн складних об'єктів, конкретно - NPC.
Наприклад треба вирішити наступне завдання - треба створити найманця, змінити йому угруповання і змінити його інвентар, ну і на додачу - зробити іншому для гравця.
У певний момент заспавнений об'єкт переходить онлайн, в цей момент викликається callback - net_spawn.
Що ми робимо? Звіряємо ID онлайн об'єкта зі збереженим ID!
Якщо вони збігаються, наприклад так:
Важливим є те, що у серверного об'єкта ID - це параметр, а у онлайнового об'єкта ID виходить за допомогою функції. Це важливо, а то можна прогоріти.
Отже, ми зловили нашого кілера по ID.
Далі все дуже просто - викликаємо команди для спавна Гаусса і патронів до нього в інвентарі NPC (див. Вище), міняємо угруповання спеціальний пристрій, який і робимо його другом.
Навіщо такі складнощі? Просто в офлайні NPC як би не існує, є тільки непряме згадка про нього, і, плюс, всі ці функції працюють саме з об'єктом типу "NPC", а не з серверними об'єктами.
Практика (частина 1)
1. Щоб не повторюватися в описі створення нового квесту, просто вивчіть статтю зі створення квестів від Fr3nzy - кращої статті на цю тему я просто не бачив :) Ми просто зв'яжемо все воєдино і навчимося спавн об'єкти з скрипта.
Чому краще робити спавн скриптом, а не через той же xrSpawner? Програма xrSpawner, при всіх своїх перевагах, має один недолік, а саме - вона робить спавн через файл all.spawn, що призводить до:
- Неможливість поєднати два мода, такий спавн використовують
- Необхідності кожного разу починати нову гру
При спавн через скрипт ситуація інша: в переважній більшості випадків, раніше збережені ігри будуть працювати, що не може не радувати :)
Отже, визначимося з квестом.
Завдання: після розмови з Сидоровичем спавн зомбі на території фабрики в першій локації. Для того, щоб не пошкодити оригінальний сюжет гри, завдання буде видаватися після проходження квесту з флешкою спритного, так як з'явися там зомбі одночасно з бандитами і Шустрим. я думаю, результат бою вирішений :)
Реалізація: Постараюся описати всі дії максимально докладно, буквально по кроках. Насамперед запустіть гру :)
В консолі введіть команду:
Тим самим ми включаємо висновок інформації на екран. Далі вводимо ще одну команду:
І «летимо» на фабрику. Нам потрібно вибрати місце для спавна об'єктів і даний режим якнайкраще підходить для реалізації задуманого. Розміщуємо камеру в точці передбачуваного спавна і записуємо координати - у мене вийшли 115, -6, -16.
Для виходу з режиму demo_record натискаємо Esc, в консолі пишемо rs_stats off або rs_stats 0 (прибираємо висновок інформації).
Інший спосіб отримання тих же відомостей - прийти в потрібне місце і запустити там скрипт, який видасть всі необхідні координати. Я користуюся наступним скриптом (викликаю загальновідомим способом, через main_menu):
Виходимо з гри, йдемо в папку з встановленою грою і створюємо каталог gamedata (передбачається, що «ліпимо» свій «мод» на «чисту» гру, без встановлених модів, і маємо розпаковані ресурси гри в папці, скажімо, gamedata source).
В папці gamedata створюємо папку config, а в ній - папку creatures. Скопіюємо з оригінальною папки файл m_zombie.ltx і відкриємо його на редагування.
У файлах гри присутні 5 моделей цивільних зомбі:
Повернемо в гру їх усіх :)
Вже є секції:
Два останніх типу використовують одну і ту ж модель zombi_trup.ogf, хм. непорядок, виправляємо. Остання секція виглядає тепер так:
Додамо п'яту модель.
Для цього в кінці файлу створимо секцію:
Це означає, що наш п'ятий зомбі успадковує всі параметри zombie_strong, ми додамо лише візуальне уявлення.
Усе. Зберігаємо зміни і закриваємо файл.
2. Пишемо скрипт спавна. В папці gamedata створюємо нову папку scripts, в ній створюємо новий текстовий документ і називаємо його esc_zombie.script.
Отже, відкриваємо наш порожній файл на редагування, першим рядком оголошуємо змінну, в якій зберігаються наші зомбі:
Далі пишемо функцію:
Усе. Зберігаємо і закриваємо файл.
Для того, щоб гра не вилітала після того, як ми додали новий тип монстрів, їх потрібно додати в файл xr_statistic.script. Отже, скопіюємо цей файл з папки гри scripts в нашу папку до файлу esc_zombie.script і відкриємо на редагування.
Додамо в local killCountProps до монстрам рядок:
У local sect_alias рядок:
А нижче в monster_classes рядок:
У функцію getNpcType (npc) додаємо конструкцію:
Зберігаємо зміни і закриваємо файл.
Все буде працювати на ура, поки ми не спробуємо обшукати вбитого зомбі. Як тільки ми це зробимо, гра вилетить з приблизно такою помилкою.
Все вірно - гра не знає яку іконку нам показувати для зомбі. Іконки монстрів зберігаються в файлі ui_npc_monster.dds. Тут є два варіанти:
Повернемося до файлу m_zombie.ltx і в секцію [m_zombie_e]: monster_base впишемо параметр
Усе. Вильотів не буде.
3. Тема даної статті не передбачає докладного опису того, як зробити новий діалог. На початку статті я згадав джерело, де можна знайти вичерпну інформацію по створенню діалогів, можу також привести в приклад статтю зі створення діалогів від BAC9-FLCL.
Нам потрібно просто перевірити працездатність скриптового спавна, тому я приведу просто власне сам змінений діалог з файлу dialogs_escape.xml:
І також пов'язаний з ним файл stable_dialogs_escape.xml. На самому початку файлу пишемо наступне:
Усе. Можна запускати гру, йти на Кордон, після разговороа з Сидоровичем, в залежності від обраного Міченим рішення, біжимо на фабрику і ... дивимося самі :)
Домашнє завдання - повернути в гру 6-ий тип громадянського зомбі :)
Практика (частина 2)
4. Сьогодні ми закінчимо з зомбі в повному обсязі - додамо їх опису в енциклопедію, додамо іконки, і розберемося з «домашнім завданням» :) Думаю, що уважно вивчивши цю статтю, ви самі зможете через скріптові функції відновити будь-якого персонажа, яке не увійшло до фінальний реліз гри. Якщо у кого вистачить часу і бажання, ті можуть навіть написати щось типу «Ночі живих мерців» :) - серію квестів, пов'язану своїм власним сюжетом. Отже, «домашнє завдання» - додаємо в гру шостого зомбі.
Файл моделі до редагування
Файл моделі після редагування
5. Тепер пропишемо нашого нового зомбі в усі файли, які ми створили раніше. У файл m_zombie.ltx в самий кінець додаємо секцію:
в файлі esc_zombie.script змінюємо масив в першому рядку:
У функції spawn_zombies змінюємо рядок спавна:
в функції zombie_story_1 міняємо число об'єктів на кратне 6-ти (необов'язково):
Усе. Зберігаємо і закриваємо.
6. Копіюємо в папку gamedata \ config \ gameplay \ файл encyclopedia_mutants.xml, додаємо опис зомбі в енциклопедію:
І в пов'язаний з ним файл string_table_enc_mutants.xml в папці gamedata \ config \ text \ rus \ додаємо:
Копіюємо сюди ж файл stable_statistic_caption.xml і змінюємо в ньому 3 рядки:
Зберігаємо і закриваємо.
7. І останнє - додамо іконки. Скажу відразу, скористався готовим файлом, вже містить іконки зомбі і інших «відновлених монстрів» (спасибі Fr3nzy). Тому просто скопіюйте файл ui_npc_monster.dds з архіву в папку gamedata \ textures \ ui \, а файл ui_npc_monster.xml - в папку gamedata \ config \ ui \. Якщо ви хочете зробити власні - прочитайте урок зі зміни текстур.
Якщо коротко, що описує файл ui_npc_monster.xml: в ньому задаються координати іконок, розташованих у файлі ui_npc_monster.dds, стосовно кожного типу монстрів в грі.
Заключний штрих. Відкрийте файл m_zombie.ltx і в першій секції замініть рядок
У секцію [zombie_ghost] додайте рядок:
Зберігайте зміни. Усе.
Ця частина статті написана Arhet і створена на прикладі того, як в SRP Mod були створені NPC угруповання "Гріх".
- gamedata \ config \ gameplay \ character_desc_escape.xml
- gamedata \ config \ gameplay \ npc_profile.ltx
- gamedata \ config \ creatures \ spawn_sections.ltx
Почнемо з character_desc_escape.xml. Опис що означає кожен рядок писати не буду, так як все до мене вже зроблено.
Тут створимо нового персонажа:
Впишемо наш код після якогось
Тепер йдемо в npc_profile.xml і туди вганяємо:
Тепер треба зайнятися spawn_sections.ltx. Скрипт буде «брати NPC» якраз з цього файлу. Пишемо туди:
Тепер беремо будь-який скрипт спавна NPC, вганяємо туди ім'я секції з spawn_sections.ltx і ву-а-ля.
Тока забули що даним НПС буде привласнена дефолтовая логіка (тобто тупо ходжу куди сам не знаю) забули згадати про (ххх - лока):
ххх gulag.script (дії НПС! Де можна: де можна привласнити статус Кампера; Волкера; і.д.т)
ххх gulag.ltx (дублер логіки тобто дублює коротко дії НПС)