Скрипты.
Скрипты - сценарии, выполняемые игрой. Движок игры распознаёт различные события (например, OnHit() - актёра стукнули). Скрипты можно привязывать к различным вещам, в том числе и к событиям. События характеризуются частотой, а функции Папируса - скоростью выполнения (об этом можно почитать на Реддите). Различные их комбинации могут повлиять на обработку скриптов. Например, событие OnHit() очень часто происходит во время кулачной драки, поэтому при привязке к нему скрипта движок может быть перегружен в момент драки. Событие OnUpdate() может быть очень жрущим, т.к. вызывается каждые N секунд и может содержать в себе "долгие" функции. Если это событие не успеет выполниться (налезет на следующее такое же) или не будет подчищено с помощью UnregisterForUpdate(), то работа Папируса замедлится, а сохранение раздуется. То, с какими скриптами справится твоя сборка, а с какими - нет, зависит от твоих модов и железа. Ты можешь навернуть хренову гору модов со скриптами, выполняющимися только при определённых условиях и содержащими быстрые функции, и твоя сборка не будет иметь задержек/переполнений стека, а можешь повесить игру одним-единственным модом, скрипт которого плохо написан или часто выполняет очень долгие функции.
Иногда ты можешь найти мод, про который мало информации о его подводных камнях. Насколько сильно он нагружает игру своими скриптами (если они есть)? Здесь мы разбираем Script Latency.
Для начала ссылка, полезная для понимания темы:
Паста от мудрых анонов:
Задержка выполнения скриптового действия должна быть 50-100 миллисекунд. В некоторых ситуациях задержка может подскакивать, и твоя задача подобные ситуации избегать. Что за ситуации? Например, обработка частых событий (яркий пример - OnHit(), если ты бьёшь цель мечом с двумя зачарованиями, то OnHit() запустится аж 3 раза - 1 на физический урон и по 1 на каждое зачарование), что может вызвать скачок задержки. Жрущей является функция Game.GetPlayer(), время её выполнения - около 20 миллисекунд. Ещё одним источником пиздеца может стать OnUpdate() - если добрый кодер поставит аргумент 0.01 или типа того, то за секунду Папирус должен будет обработать 100 таких вызовов. А теперь смотрим описание OnUpdate:
Be careful with the use of this event. Because it uses real-time, it can start piling up on itself if the OnUpdate doesn't finish before the time is up. To avoid this, try using a longer time at registration, or do a 'single update chain'.
Это значит, что при малом значении аргумента OnUpdate() намотает на вал и себя, и всех остальных.
Чтобы разбираться во всём этом, нужно знать скриптинг. Как освоить скриптинг? Enai Siaion ответил так: читать сайт CK и использовать здравый смысл. Да-да, этот момент настолько прост и понятен, что любой справится, было бы желание. Надо найти хороший туториал по скриптингу, но есть нюансы. Тот же www.CreationKit.com имеет неточности. Есть и другие туториалы, например от DarkFox'а. Проблема в том, что работающий скрипт и оптимизированный скрипт - вещи разные, и для оптимизации нужно понимать, что и как работает, потому нужно будет самому экспериментировать с функциями. Если нет времени/желания, то можно положиться на знания более опытных скриптеров - гения Папируса они из тебя, конечно, не сделают, но ответить на вопрос-другой могут.
Текстуры, модели и плагины.
Меш (mesh) - 3D-моделька, на которую натягиваются текстуры. Это делается прописыванием пути текстур в nif-файле модели. Чтобы понять, как всё это взаимосвязано, приведу пример:
У тебя есть мод, добавляющий новую ложку (в МО2 он будет отображаться как "Spoon"). Он состоит из плагина Spoon.esp, а также папкок Meshes и Textures. В Meshes лежит файл модели - spoon.nif, который ссылается на текстуры spoon.dds и другие, лежащие в Textures. В Spoon.esp есть запись, ссылающаяся на spoon.nif. Допустим, ты хочешь поставить ретекстур этой ложки (в МО2 это будет мод "Spoon Retexture"). Самый простой способ - поставить новую текстуру с таким же названием, т.е. spoon.dds (МО2 при этом покажет частичную перезапись мода "Spoon"). Вдруг ты решил, что тебе нужен не ретекстур, а реплейсер этой ложки. Ты ставишь через МО2 мод "Spoon Replacer", содержащий spoon.nif. Далее возможны варианты: меш использует те же пути к текстурам или меш ссылается на другие текстуры (например, на spoon_new.dds). Во втором случае с реплейсером также будет идти новая текстура.
Теперь про реплейсеры. Принцип реплейсеров, не содержащих esp, ты уже понял из описанного выше. Теперь рассмотрим другой случай.
В игре есть объекты А, Б и В. Они используют одну и ту же модель (допустим, 1.nif). Ты устанавливаешь мод, который изменяет эти объекты и выдаёт им новые модели - А по-прежнему использует 1.nif, но Б стал использовать 2.nif, а В - 3.nif. Как это делается? В плагине изменяются объекты Б и В - им прописываются другие пути к модели. Эти новые модели могут ссылаться как на старые текстуры, так и на новые.
| Назад к оглавлению |
|---|