S.T.A.L.K.E.R. Inside Wiki - Вклад участника [ru]

Декомпиляция уровней в формат СДК

2010-02-22T09:18:55Z

94.141.39.153:

Для декомпиляции игровых карт в формат LevelEditor-a используется Конвертер от Бардака, входящий в пакет !X-ray Game asset tools pack.

Пакет !X-ray Game asset tools pack качаем тут [http://stalkerin.gameru.net/modules.php?name=Downloads&d_op=getit&lid=288]. Обновление [http://stalkerin.gameru.net/modules.php?name=Downloads&d_op=getit&lid=348] ставим поверх пакета.

=== Пошаговое руководство по декомпиляции: ===

1. Распаковать утилиту Бардака в нужную папку

2. Там находим и открываем любым текстовым редакором converter.ini в нем находим строчки:
; 2947+ (финалка включая обновления)
[2947_config]:2945_config
$game_data$ = c:\temp\1\gamedata.3312\
$game_levels$ = c:\temp\1\gamedata.3312\levels\
-------------------------------------------------------------------------------------------------------
; 3456+ (Clear Sky включая обновления)
[3456_config]:2947_config
$game_data$ = c:\temp\1\gamedata.3502\
$game_levels$ = c:\temp\1\gamedata.3502\levels\
fake_mu_gamemtls = 34xx_fake_mu_gamemtls
fake_gamemtls = 34xx_fake_gamemtls
Тут $game_data$-путь до gamedata и $game_levels$-до папки levels в gamedata соответственно. Указываем правильные пути.

3. Находим fsconverter.ltx там находим строчку :
$sdk_root$ = false| false| c:\program files\x-ray sdk\level_editor\
где $sdk_root$ путь до полного СДК(покоцанный не работает нормально с этой утилитой)то есть после строчек false| false| пишем полный путь и именно со строчкой level_editor\ в конце как на примере(многие забывают).

4. Ну вот конвертер полностью настроен теперь ключ для конвертирования в формат СДК:
Для этого создаем текстовой файл в него вписываем этот параметр и меняем формат(переименованием)с .txt на .bat.
converter -level <имя_карты> -out <имя_сцены> -mode le
pause
где <имя_карты> точное название папки с картой пример:l08_yantar(локация янтарь из ТЧ), <имя_сцены> то как карта будет назваться после конвертирования, можно не писать в этом случае карта будет называться также как и до конвертирования в нашем случае l08_yantar, ну и ключ mode в нашем примере le то есть конвертирование карты в формат СДК,также можно использовать ключи maya(Конвертирование геометрии в формат Майи), le2(Формат использующийся для карты l12_stancia_2(может быть еще для каких не проверял)), raw(Опять же формат СДК но уже в отладочном режиме).

5. Если все сделано правильно после запуска батника пойдет процесс декомпиляции.

6. Найти карту можно будет по адресу $sdk_root$\maps-фаил читаемый СДК и $sdk_root$\rawdata\objects\levels обьекты используемые данным уровнем.

[[Категория:SDK]]

Работа с all.spawn

2010-02-22T09:17:21Z

94.141.39.153:

== Расспаковка all.spawn ==

Для того, чтобы распаковать ол спавн, нам потребуется acdc. Для каждой версии игры нам понадобиться свой. Я описываю для ЗП ( во
всех частях сталкера этот процесс идентичен), поэтому и пользуюсь acdc от ЗП. Для того, чтобы запустить acdc нам будет
нужен ActivePerl (нужная версия входит в архив)Качаем acdc для ЗП [http://narod.ru/disk/17377026000/ACDC%20Cop.rar.html здесь].После того, как вы скачали acdc, установите эктивперл(если вы этого еще не сделали). Распакуйте acdc и скопируйте в эту папку свой all.spawn. Запустите .bat файл decompile(если его нет, то откройте блокнот, запишите в нем такие строки:
perl acdccop.pl -d all.spawn
pause

И сохраните под именем "decompile.bat" Запускайте батник. Через некоторое время появятся .ltx файлы.
Все, ол спавн распакован и ждет шаманства над собой :)

== Структура файлов ==

Рассмотрим структуру файлов. Файлы типа alife_ - это основные файлы, в которых содержаться секции спавна. Файлы типа way_ - это и есть "вэй". Сквады, логика и прочая дребедень. Трогать мы их не будем.
Откроем любой alife_ файл и увидим там много секций спавна. Вот одна из них:

[0]
; cse_abstract properties
section_name = breakable_object
name = meshes\brkbl#0.ogf
position = -160.539749145508,21.5325393676758,-195.387329101563
direction = -0.00700339116156101,-0.108852192759514,0.412739604711533
; cse_alife_object properties
game_vertex_id = 0
distance = 0
level_vertex_id = 293223
object_flags = 0xffffffba
; cse_visual properties
visual_name = meshes\brkbl#0
; cse_alife_object_breakable properties
health = 1

А теперь подробнее

[0] - уникальный "id", то бишь номер секции
; cse_abstract properties - комментарий
section_name = breakable_object - название секции( НЕ В КОЕМ СЛУЧАЕ НЕ СТАВТЕ ЗДЕСЬ СВОЕ НАЗВАНИЕ, ИНАЧЕ all.spawn ВЫ НЕ ЗАПАКУЕТЕ)
name = meshes\brkbl#0.ogf - тоже название... Тут уже что годно можно написать
position = -160.539749145508,21.5325393676758,-195.387329101563 - позиция на которой будет спавн
direction = -0.00700339116156101,-0.108852192759514,0.412739604711533 - направление. В какую сторону "смотрит" обьект.
; cse_alife_object properties - комментарий
game_vertex_id = 0 - вертикс.
distance = 0
level_vertex_id = 293223 - тоже вертикс. (зачем они объяснять не буду)
object_flags = 0xffffffba - флаги обьекта. тоже рассматривать не будем
; cse_visual properties - комментарий
visual_name = meshes\brkbl#0 - визуал.
; cse_alife_object_breakable properties - комментарий.
health = 1 - здоровье.

Файл all.ltx - это список файлов, которые упакованы в ол спавн.

== Создаем новую секцию спавна ==
Ну вот, самое интересное начинается )
Открываем любой файл. Я буду спавнить свои объекты, на новой локации.

Допустим, нам нужно заспавнить сталкера.
Создаем секцию спавна. ( ВНИМАНИЕ! ПРЕЖДЕ ЧЕМ СПАВНИТЬ СТАЛКЕРА, ЕГО НУЖНО СОЗДАТЬ). Как описывать новых напсано [http://stalkerin.gameru.net/wiki/index.php/%D0%A0%D0%B5%D0%B4%D0%B0%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_NPC здесь]

[20927] - уникальный номер секции
; cse_abstract properties - коментарий :)
section_name = stalker - название секции. Если спавните сталкера - stalker. Своих названий быть не должно.
name = marsh_koster_stalker - имя. я использую имя профиля, которого вы создавали при создании нпс
position = -150.17852783203,0.63608288764954,-293.19580078125 - координаты.
direction = 0.062321275472641,0.00316426996141672,0.0140644172206521 - направление. Куда сталкер будет смотреть.
; cse_alife_trader_abstract properties -
money = 5000 - деньги )
character_profile = marsh_koster_stalker - профиль, который вы указали при создании нпс. Вот тут нужно указывать его
; cse_alife_object properties
game_vertex_id = 934 - вертикс локации
distance = 4.90000009536743 - дистанция, зачем нужна не знаю.
level_vertex_id = 1418 - вертикс локации )
object_flags = 0xffffffbf
custom_data = <<END - кастом дата. Очень важный элемент при создании нпс. Проще говоря - логика.
cfg = scripts/marsh/koster.ltx - путь к конфигу кастом даты
[smart_terrains] - смарт террайны ( не рассматриваться)
END - окончание кастом даты
; cse_alife_creature_abstract properties
g_team = 0
g_squad = 1
g_group = 5
health = 1
dynamic_out_restrictions =
dynamic_in_restrictions =
(зачем нужно это не совсем понимаю, но заполнять так же, как и в основной секции)
upd:health = 1
upd:timestamp = 0x2009656c
upd:creature_flags = 0x3d
upd:position = -150.17852783203,0.63608288764954,-293.19580078125
upd:o_model = 0
upd:o_torso = 0.00316426996141672,0.062321275472641,0
upd:g_team = 0
upd:g_squad = 1
upd:g_group = 5
; cse_alife_monster_abstract properties
upd:next_game_vertex_id = 65535
upd:prev_game_vertex_id = 65535
upd:distance_from_point = 0
upd:distance_to_point = 0
; cse_alife_human_abstract properties
predicate5 = 1,1,0,0,1
predicate4 = 2,2,0,2
; cse_ph_skeleton properties
upd:start_dialog =
; se_stalker properties

Сохраняем. Запаковываем ол спавн, файлом comlite.bat.

В папке gamedata создаем папку spawns и копируем файл new.spawn(он будет называться именно так). Потом переименовываем в all.spawn.

Статья не закончена и будет пополняться время от времени. Для начала хватит.

Автор статьи - '''Andrey K aka f0rest'''

Как писать скрипты, не приводящие к вылетам и бою сейвов (часть 2)

2010-02-22T09:15:11Z

94.141.39.153:

[[Категория:Статьи участников]]
[[Категория:Скрипты]]

----

[[Как писать скрипты, не приводящие к вылетам и бою сейвов|Начало в первой части статьи]]

----

= Как безопасно использовать коллбэки и таймерные события =

В скриптовом движке есть удобный способ реакции на события - использование коллбэков - процедурных вызовов, привязанных к определённым событиям в жизни игрового объекта - получению повреждений, спавну, смерти и т.д. и т.п. Это hit_callback, death_callback из xr_motivator и многие другие... Все моддеры очень широко и совершенно спокойно пользуются ими, совершенно забывая при этом о таком важном факте, что это - обработки реального времени, как и таймерные события. Что это значит? А собственно вот что... Возьмём для примера коллбэк смерти неписей, мою головную боль последнего времени:

<code>xr_motivator.script -
function motivator_binder:death_callback(victim, who)</code>

Это функция обрабатывает смерть неписей. Когда вызывается этот коллбек он начинает по очереди вызывать внутренние функции, расположенные в других модулях. Они разрегистрируют умершего непися в гулагах, спавнят в него лут, обновляют статистику, отключают его от доп. схем логики и т.д.

Так вот, обычно, когда в функциях возникает конфликт параметров, бесконечный цикл, попытка индексации nil и т.д., функция вылетает со стандартным логом. '''Но только не в случае, когда она находится внутри коллбэка. Если функция внутри него, то в случае возникновении в ней любой нештатной ситуации, коллбэк наглухо виснет.''' Это происходит из-за того, что функции вызываются строго друг за другом, и каждая из них вызывается только тогда, когда её предшественница вернула управление коллбэку. В случае с death_callback опознать такого непися очень просто - в его трупе окажется фонарик, КПК и возможно ещё немного разных "мусорных" вещей, что говорит о том, что обработка его смерти повисла не дойдя даже до спавна лута. В подобной ситуации можно быть на 100% уверенным, что труп этот не был корректно разрегистрирован, и игра всё ещё считает его живым неписем. Кроме того, зависший коллбэк не освобождает стек (а он у Луа-подсистемы единый на все скрипты), что '''в итоге приводит к вылетам игры с переполнением памяти (вот она, реальная причина этих "родных" вылетов).''' Но было бы слишком хорошо, если бы всё ограничивалось этим... однако тут всё намного хуже... такие "зависшие" коллбэки, особенно если их произошло несколько подряд, очень серьёзно влияют на работу а-лайфа. В лучшем случае они, забивая, стек, мешают нормально работать схемам логики, в худшем вызывают зависания самого а-лайфа (этот эффект, кстати, производят и сами трупы таких неписей, так как они, как мы помним, не разрегистрировались корректно). '''Основной итог таких событий - бой сейвов, сделанных после возникновения таких ситуаций.''' Если повис один коллбэк, то такие сейвы ещё через раз загружаются, если же несколько, и остановилась работа а-лайфа - всё, сейвы бьются наглухо и реанимации не подлежат.

Поэтому, чтобы избежать такого развития событий, каждый раз, когда вы вносите в коллбэк новую функцию - проверьте её самым тщательным образом. Она не должна содержать никаких рекурсивных циклов, в ней обязательно должны быть проверки на валидность обрабатываемых объектов и значений, и обязательно должна быть обработка нештатных ситуаций - т.е. функция должна обязательно, в абсолютно любой ситуации вернуть управление коллбэку, так или иначе. В самом наихудшем случае - делайте как делали разработчики игры - вставляйте принудительный вылет на рабстол функцией abort - она позволяет передавать отладочное сообщение, и это всяко лучше чем незаметный бой сейвов. Если обработка оборвалась в самом начале, а ф-ция обязательно должна вернуть значение - заведите ей "безопасное" возвращаемое значение по-умолчанию, которое она будет выдавать, если всё пошло плохо. И никогда не пренебрегайте пошаговой отладкой коллбэков с выводом в лог, особенно когда пишете схемы логики - это критически важно для стабильности вашего мода.

== Основные внутриигровые признаки зависания коллбэков типа hit_callback, death_callback ==

1. В трупах попадаются фонарики, КПК, разный мусор и общий лут слишком богат.

2. Частые вылеты во время интенсивных боёв с логами типа
Sheduler tried to update object...
smart_terrain:1145(1146)
LUA: out of memory
любой_модуль_логики:любая_cтрока - stack overflow

3. Частые "родные" вылеты в момент смерти непися или попадания по нему

4. Произвольно бьются сейвы во время сражений, выброса и других насыщенных действиями событий

= Использование защищённого кода в LUA =

Периодически случаются такие ситуации, когда мы можем получить вылет при проверке аргумента, и не можем его адекватно заизолировать с помощью предварительной проверки на валидность значения. Вот простой пример: когда я отлаживал '''death_callback''' неписей, я периодически сталкивался с тем, что обращение к методу '''smart_terrain_id()''' при смерти непися иногда вызывало вылет

<code>smart_terrain:1143 "attempt to index a nil value"</code>

- хотя это свойство является родным методом объекта, и отсутствовать напрочь никак не может. В итоге я пришёл к выводу, что его просто иногда не успевает отработать движок, так как вылет этот проявлялся в основном в интенсивных боях и совершенно произвольно.

Вот код, в котором происходил вылет:

<code lua>function on_death( obj_id )
-- printf( "on_death obj_id=%d", obj_id )

local sim = alife()

if sim then
local obj = sim:object( obj_id )
local strn_id = obj:smart_terrain_id() --- вылет происходит тут

if strn_id ~= 65535 then
sim:object( strn_id ).gulag:clear_dead(obj_id)
end
end
end</code>

Это кусок родного кода из версии 1,0005 игры. Я долго пытался разными способами отсечь этот вылет, вводя предварительные проверки, однако это совершенно ничего не давало - вылет всё равно периодически случался, так как проверки эти сами его вызывали. Тогда я зарылся в документацию по Lua и обнаружил замечательную родную базовую функцию, введённую ещё с первых версий Lua, которой почему-то не пользовались ни разработчики игры, ни моддеры (хотя сама она в Lua сталкера присутствует, и работает отлично, без каких-либо нареканий). Вот она:

'''pcall (f, arg1, ···)'''

<blockquote>Вызывает функцию f с указанными через запятую аргументами в защищённом режиме. Это означает, что любая ошибка, даже критическая, внутри вызванной функции, не передаётся наружу - вызывавшей подсистеме. Вместо этого '''pcall''' перехватывает ошибку и возвращает код статуса. Первая возвращаемая переменная это сам код, (true или false) и если всё прошло хорошо, он равен true. В этом случае '''pcall''' сразу после статуса возвращает все результаты от работы защищённой им функции. Если же в защищённой функции произошла ошибка, то '''pcall''' вернёт false и затем сообщение об ошибке. (Обратите внимание, обработка ошибки присходит БЕЗ вылета! Вместо вылета вы получите вполне адекватную строку с ошибкой, которую можно вывести в лог для последующей обработки)</blockquote>

Я настоятельно советую пользоваться этой функцией в случаях, когда из коллбэков вызываются сложные комплексные обработки, вроде обработки из менеджера вооружений AI-пака. Это позволяет предотвратить как вылеты, так и зависания обработок, и в итоге позволяет хорошо стабилизировать игру.

Возвращаясь к нашим смарттеррейнам... вот как в итоге я подавил вылет типа smart_terrain:1143 с помощью pcall:

<code lua>--- эта функция пытается проверить св-во smart_terrain_id объекта. Именно её мы вызовем в защищённом режиме.
function prot_smt_td(obj)
if IsStalker(obj) or IsMonster(obj) then
return obj:smart_terrain_id()
else
return 65535
end
end

function on_death( obj_id )
-- printf( "on_death obj_id=%d", obj_id )
local sim = alife()
if sim then
local obj = sim:object( obj_id )
if obj then
local strn_id = 65535 --- предварительно проинитим переменную, на
--- случай если у нас prot_smt_td выдаст ошибку
local result, smt_id = pcall(prot_smt_td,obj) --- вызываем prot_smt_td в защищённом режиме
--- и сразу присваиваем его вывод переменным
if result then --- если pcall выдало true
strn_id = smt_id --- тогда применяем полученное значение
end
--- если же обработка выдаст ошибку, то strn_id останется неизменным...
if strn_id ~= 65535 then
sim:object(strn_id).gulag:clear_dead(obj_id)
end
end
end
end</code>

В других местах это делается совершенно аналогично. Подробнее об этой и многих других функция для контроля кода, незаслуженно игнорируемых большинством моддеров, можно почитать тут: http://lua-users.org/wiki/FinalizedExceptions - на английском правда, но захотите - разберётесь, там всё просто.

Настоятельно советую вам изучить работу кода в таких условиях и научиться его правильно применять - этим вы сильно облегчите жизнь как себе, так и тем, кто после вас будет рыться в вашем коде или импортировать его в свои разработки.

= Скрытые критические проблемы в обработке вылетов игрой =

Ведя на днях отладку, выяснил в чём проблема с периодическим боем сейвов и многими другими заморочками как в оригинале игры, так и во многих модах... дело, как выяснилось, далеко не всегда в кривых руках. Существует есть такая стандартная ф-ция '''abort''' - предназначенная для выкидывания из игры, если что-то пошло не так. И как оказалось, она срабатывает далеко не всегда. Выяснилось это следующим образом:

В одном из логов нашего бета-тестера я увидел '''стандартное сообщение о вылете внутри рабочего лога'''... да-да, то самое которое '''FATAL ERROR''' и дальше по тексту. При этом игра у него НЕ вылетала, это сообщение об ошибке мы обнаружили позже, по случайности. Я заподозрил, что что-то не в порядке, и вставил внутрь этой ф-ции контрольную метку, кидавшую в консоль сообщение, в котором содержался паттерн сообщения об ошибке и само сообщение. Так вот, оказалось, что эта самая функция '''abort''' вызывается в игре с завидным постоянством (вы удивитесь насколько часто), когда возникают исключения в схемах логики, звука и т.д., но игра от этого вылетает на рабочий стол '''максимум только 3 раза из 10 вызовов'''. Вылет НЕ происходит обычно, когда функции передан паттерн ошибки, а остальные параметры пустые, такое бывает, и частенько. И если не сделать внутри этой функции особой метки для вывода в лог, как сделал это я, её вызовы проходят совершенно незаметно, и '''игра после критических ошибок продолжается как ни в чём ни бывало.''' А приводит это вот к чему... Внутри '''xr_logic''' в процедуре записи пстора (хранилища логики и флагов) неписей есть вызовы этого самого аборта в случае если на запись в пстор передана некорректная величина. Ну а так как аборт периодически вообще не срабатывает, то часто попадается ситуация, что неписям в пстор пишется полный ахтунг: куски кода из ОЗУ, всякая муть из лтх-ов, куски аллспавна, всё что угодно. Происходит это оттого, что кодер, писавший эту функцию ('''xr_logic.pstor_store(obj, varname, val)'''), явно и думать не думал что '''abort''' может не сработать. У него запись в пстор стояла после проверки, а не внутри неё (very bad idea), и если abort не срабатывал, игра писала в пстор мусор совершенно спокойно и незаметно для игрока. Потом вся эта хрень попадала прямо в сейвы. Вот проблемный код для наглядности:

<code lua>function pstor_store(obj, varname, val)
local npc_id = obj:id()
if db.storage[npc_id].pstor == nil then
db.storage[npc_id].pstor = {}
end
local tv = type(val)
if not pstor_is_registered_type(tv) then
abort("xr_logic: pstor_store: not registered type '%s' encountered", tv) --- вот тут мы должны если что вылететь
end
db.storage[npc_id].pstor[varname] = val -- а если не вылетели, всё, получим запись в пстор левой мути
end</code>

Разумеется игра этим пстором в итоге давится, и сейвы сделанные после такой милой записи практически лопаются. Результат - "битые" (на самом деле подлежат реанимации) сейвы. Происходит это потому, что игра из сейва грузит неписям псторы сплошным чтением по словам, пока они не закончатся. В случае же если в псторе обнаруживается записанный ранее мусор, то обработка либо вылетает сразу, либо наглухо виснет, пытаясь запихать эдак с миллион слов в пстор особо отличившегося непися. Как вам например непись с размером пстора в 1697451 слова? В результате попытки его обработать игра просто на стадии синхронизации выжрала всю доступную ОЗУ и повисла.

Решение этой проблемы оказалось достатоно простым: во-первых я предположил максимальный размер полезной части пстора неписей в 20 слов r_u32() (пока ориентировочно, я ещё уточняю эту величину), и соответственно сделал остановку цикла загрузки пстора для неписей через 20 итераций. Там же, где в цикле стояла проверка на валидность записываемых данных (кстати тоже с вылетом в случае провала проверки), я сделал так, что если параметр не относится к валидному типу данных, то запись параметра в пстор не производится совсем. Это необходимо для того, чтобы если вдруг в сейве обнаружится мусор, то он был бы просто отброшен обработкой. Практика показала, что в итоге такие неписи вполне адекватны и в дальнейшем никаких проблем не вызывают, так как начало их пстора, с нормальными данными, обычно не повреждается - мусор дописывается после них, а не вместо них.

Ну и во-вторых модифицировал запись параметров в пстор, просто убрав запись под основание if-else так, чтобы если параметр неверен, он не записывался совсем. Теперь кстати, очень интересно, сохранились ли те же заморочки с ф-цией '''abort''' в Чистом Небе, и если да, то останутся ли в Зове Припяти?

------------

== Необходимые для стабилизации игры правки в модулях ==

'''Эта правка предотвращает запись в пстор если не сработал аборт:'''

''xr_logic.script''

'''Было:'''

<code lua>function pstor_store(obj, varname, val)
local npc_id = obj:id()
if db.storage[npc_id].pstor == nil then
db.storage[npc_id].pstor = {}
end
local tv = type(val)
if not pstor_is_registered_type(tv) then
abort("xr_logic: pstor_store: not registered type '%s' encountered", tv)
end
db.storage[npc_id].pstor[varname] = val
end</code>

'''Стало:'''

<code lua>function pstor_store(obj, varname, val)
if not obj then return end
local npc_id = obj:id()
if db.storage[npc_id].pstor == nil then
db.storage[npc_id].pstor = {}
end
local tv = type(val)
if not pstor_is_registered_type(tv) then
dgblog("xr_logic: pstor_store: not registered type encountered - write in pstor_store cancelled")
-- abort убран, так как один хрен не работает. Пусть тогда хотя бы в лог что-то валится.
else
db.storage[npc_id].pstor[varname] = val
-- вот так и только так. Если значение не валидно, ничего не происходит.
end
end</code>

'''А эта правка выкинет из пстора весь мусор при загрузке сейва, если он как-то в него попал'''

'''Было:'''

<code lua>function pstor_load_all(obj, reader)
local npc_id = obj:id()
local pstor = db.storage[npc_id].pstor
if not pstor then
pstor = {}
db.storage[npc_id].pstor = pstor
end
local ctr = reader:r_u32()
for i = 1, ctr do
local varname = reader:r_stringZ()
local tn = reader:r_u8()
if tn == pstor_number then
pstor[varname] = reader:r_float()
elseif tn == pstor_string then
pstor[varname] = reader:r_stringZ()
elseif tn == pstor_boolean then
pstor[varname] = reader:r_bool()
else
abort("xr_logic: pstor_load_all: not registered type N %d encountered", tn)
end
printf("_bp: pstor_load_all: loaded [%s]='%s'", varname, utils.to_str(pstor[varname]))
end
end</code>

'''Стало:'''

<code lua>function pstor_load_all(obj, reader)
local npc_id = obj:id()
local pstor = db.storage[npc_id].pstor
if not pstor then
pstor = {}
db.storage[npc_id].pstor = pstor
end
local ctr = reader:r_u32()
if tonumber(ctr) > 20 and tostring(obj:name()) ~= "single_player" and npc_id ~= db.actor:id() then
-- максимум 20 итераций - это число ещё уточняется, возможно понадобится больше
-- если у вас в пстор что-то свое пишется, ориентируйтесь на свои значения
-- и обязательно убираем из проверки актора - у него очень толстый пстор, и к тому же
-- если уж поврежденным будет его пстор, то тут точно уже ничего не поможет
dgblog("ОБНАРУЖЕН ОБЪЕКТ С ПОВРЕЖДЕННЫМ PSTOR: "..tostring(obj:name())..
" БУДЕТ ПРОИЗВЕДЕНА ПОПЫТКА ВОССТАНОВЛЕНИЯ")
ctr = 20
end
for i = 1, ctr do
local varname = reader:r_stringZ()
local tn = reader:r_u8()
if tn == pstor_number then
pstor[varname] = reader:r_float()
elseif tn == pstor_string then
pstor[varname] = reader:r_stringZ()
elseif tn == pstor_boolean then
pstor[varname] = reader:r_bool()
else
-- не надо пытаться вылетать - просто не пишем поврежденные данные
-- при этом обязательно удалять саму переменную - в результате записи
-- мусора в пстор одно только ее название может повесить загрузку
pstor[varname] = nil
end
end
end</code>

Эти примеры приведены для чистой игры. Единственное в чем не уверен пока, это в том, что максимум полезного размера - 20 слов. Возможно нужно выделить больше, это надо будет проверить ещё экспериментальным путем...

Кроме этого, советую ещё внутрь ф-ции abort вставить отладочные метки, чтобы точно знать когда она вызывалась. Настоятельно советую сделать это даже если вы матёрый моддер со стажем - гарантирую, будете неприятно удивлены.

Я это сделал вот так:

''_g.script''

<code lua>-- Крешнуть игру (после вывода сообщения об ошибке в лог)
function abort(fmt, msg)
local message = tostring(msg)
dbglog("ERROR PATTERN: "..tostring(fmt))
dbglog("ERROR REASON: "..message)
local reason = string.format(fmt, message)
assert("ERROR: " .. reason)
printf("ERROR: " .. reason)
dbglog("%s", reason)
printf("%s")
end</code>

= Другие частые проблемы =

Спустя некоторое время я обнаружил причины ещё нескольких часто встречающихся вылетов, и решил записать их описание сюда - эта информация наверняка ещё много кому пригодится.

== Вылеты при удалении объектов из игры ==

При использовании для удаления объектов родной движковой функции '''alife():release(obj:id(), true)''' возможен целый ворох разнообразнейших вылетов, обычно - безлоговых, что сильно затрудняет их отладку. Вот из-за чего они возникают:

1) Вылет при удалении непися или монстра.
Решение: с помощью alife():release '''можно удалять только мёртвые объекты'''. Поэтому если вам нужно удалить с её помощью непися или монстра, его нужно убить любым доступным методом, хотя бы нанеся ему hit() с любым запредельным уроном по вкусу.

2) Вылет при удалении оружия или артефакта.
Решение: такая проблема часто встречается в случае если объект неудачно расположен или находится в руках у непися. Для того чтобы не произошло вылета, убедитесь что объект доступен как серверный перед удалением. Вот так:

<code lua> local obj = alife():object(i)
if obj then
alife():release(obj, true)
end</code>

Эту конструкцию вообще желательно использовать всегда, когда вы так удаляете объекты.

3) Вылет при удалении аномалии.
Решение: аномалии - очень капризные при подобном с ними обращении объекты. Они влияют на своё окружение, и если рядом с ними находится непись или монстр, то удаление такой аномалии приведёт к вылету игры. Чтобы этого не произошло, аномалию надо сначала выключить функцией '''disable_anomaly''', и удалять затем ТОЛЬКО тогда, когда она не будет занята влиянием на динамический объект. Для этого нужно получить список мобов на локации, и из их нетпакетов считать идентификаторы действующих на них рестрикторов. Если ваша аномалия будет в этом списке - удалять её нельзя. Дождитесь пока она освободится.

== Вылет при открытии закладки "Контакты" в ПДА ==

Простой безлоговый вылет при открытии закладки "Контакты". Встречался во всех крупных модах, и никто не знал как его излечить. А лечится он банально - '''его причина - дублирование идентификаторов секций в XML-файле, описывающем иконки неписей для закладки "Контакты"'''. Нужно всего лишь проверить этот файл на наличие дублированных идентификаторов и удалить их. Вылет пропадёт и никогда больше не будет встречаться.

== Вылеты при вызове несуществующих функций из XML ==

В ХML-файлах, используемых для описания инфопоршенов, для многих инфопоршенов прописаны действия, которые игра вызывает при взятии этого инфопоршена. Вот так примерно:

<code xml>
<info_portion id="barman_document_have">
<action>dialogs.set_actor_prebandit1</action>
<action>bar_spawn.bandits2</action>
<action>bar_spawn.bandits3</action>
<action>bar_spawn.bandit7</action>
<action>bar_spawn.bandit8</action>
</info_portion>
</code>

Так вот, если вы допустите опечатку в названии вызываемой функции или же случайно её удалите - игра будет стабильно вылетать без лога при взятии этого инфопоршена.

--[[Участник:Kamikazze|KamikaZze (OGSE Team)]] 11:04, 3 сентября 2009 (UTC)

= Авторы =
Статья создана: [[Участник:Kamikazze|Kamikazze]]

Формат файлов постпроцессинга (ppe)

2010-02-22T09:06:14Z

94.141.39.153:

==Вступление==

Представляю на суд общественности результаты моих изысканий по формату файлов постпроцессинга ('''.ppe''')

Нераскрытыми для меня осталось 6 переменных (переменные, которые я для себя назвал free, обязательно идут перед каждой триадой цепочек, управляющих цветом и 3 коэффициента, идут в каждом правиле после байта функции), но простенькие '''ppe'''-файлы можно делать и без них.

Вообще, оказалось, что возможности '''ppe''' были сильно мною переоценены (например тепловизор сделать с их помощью если и можно, то крайне проблематично). Основной недостаток - '''ppe''' можно применить только ко всему экрану, на отдельный обьект это не предусмотрено движком (даже стелс-режим кровососа реализуется подменой модели). Так что могу предложить только слегка улучшеный прибор ночного зрения.

Получилось так себе, просто убрал шумы, добавил яркости/контрастности, но зато теперь со включенным nv днем не побегаешь - засветка почти как на настоящем (как в кино показывают) и туман гораздо сильнее мешает, клубы тумана почти непрозрачны.

По поводу компилятора/декомпилятора, пришел к выводу, что фильтр постпроцесса изделие штучное, смысла в отдельных утилитах нет - я все анализировал, клепал, менял только с помощью блокнота и шестнадцатеричного редактора (кстати, выяснил, что при смене файла постпроцесса необязательно перезапускать сталкера и даже релоад делать ни к чему - изменения подхватываются при следующем выключении постпроцесса в данном случае nv).

При анализе ppe сильно помог тот факт, что постпроцесс существует в игре в текстовом и компилированом виде (кому интересно, копайте '''\gamedata\script\postprocess.script''' - полный разбор текстовых файлов написан обычным скриптом, там же, в самом конце функция ''main'' загружает погоду и файл постпроцессинга, сами файлы лежат '''\gamedata\config\scripts''' например '''proba.ltx'''). Компилированные ppe лежат в anims.

==Практика==

Итак, '''ppe'''-файл - это набор правил, как должен изменяться тот или иной параметр изображения во времени, всего этих параметров - 16 (названия взяты из текстовых версий, чтобы путаницы не было). В отличие от текстовой версии, цепочки должны идти только в этом порядке и их всегда должно быть только 16 (если игра вывалилась с сообщением в логах ''noise.grain cannot be zer''o, значит вы что-то пропустили).

Выбраная цветовая компонента умножается на коэффициент, то при параметре равным 1 чистый белый цвет останется белым, а чистый черный - черным, остальные приобретут компонентный оттенок.

* '''free1''' - об этой переменной чуть ниже
* '''color_add_red'''
* '''color_add_green'''
* '''color_add_blue'''

Указанное значение принимается как база для данного цвета, то есть, если у данного пикселя значение цвета меньше указанного, то оно принимается как указанное, а если больше, то остается прежним. Следует заметить, что это единственный набор переменных, задирать значения в которых выше 0.5 не имеет смысла, 0.5 прибавляется где-то в дебрях движка.

* '''free2'''
* '''color_base_red'''
* '''color_base_green'''
* '''color_base_blue'''

Эта триада правил отвечает за вес цвета в сером/яркостном представлении и в обычном цветном режиме результат не виден. Но при увеличении правила '''gray''' становится ясно, что при например '''color_gray_red''' = -1 чисто красные компоненты становятся черными, 0 = остаются без изменений, 1 - чисто белыми:

*'''free3'''
*'''color_gray_red'''
*'''color_gray_green'''
*'''color_gray_blue'''

Переменная управляет величиной обратной насыщенности, то есть, чем больше gray (максимум +1) тем меньше насыщенность изображения:

*'''gray'''

Размытие изображения, при больших значениях (пробовал 25) начинаются косяки, портится нижняя часть, если долго стоять на месте:

*'''blur'''

Раздвоение изображения по горизонтали и вертикали соответственно. Значение указывается относительно экрана, то есть при 1 копии обьекта, первоначально находящегося в центре окажутся точно по краям:

*'''duality_h'''
*'''duality_v'''

*'''noise_intensity''' - интенсивность шума
*'''noise_granularity''' - размер зерна шума
*'''noise_fps ''' - сколько раз в секунду шум должен пересчитываться

Файл '''всегда''' начинается с '''01 00 00 00''' - скорее всего это синатура, по которой движок определяет содержимое(кстати, у файлов anm, которые содержать анимацию камеры и похоже имеют ту же логику строения, что и ppe сигнатурой является '''00 11 00 00''' ).

Затем идет 4 байта неопределенной переменной, которую я для себя назвал free. Всего их 3. Эти переменные стоят только перед триадами, отвечающими за изменения цветов, обычно равны '''7C 00 00 00''', но есть небольшие вариации. Визуально определить, что меняется при изменении этой переменной я не смог, если кто совершит этот подвиг - вечная слава :)

Затем начинаются цепочки в перечисленном выше порядке.
Цепочка начинается с '''01 01 ''ХХ'' 00''', где '''''ХХ''''' - число правил в данной цепочке. Если указано 01 01 00 00 (то есть цепочка с 0 правил, то данная цепочка в постпроцессинге не участвует и сразу после нее должна начинаться следующая цепочка). '''Основная ошибка, которую можно допустить - несоответствие реального числа правил с указаным в заголовке цепочки. Контроль, контроль, и еще раз контроль.'''

Каждая цепочка состоит из правил изменения переменной. Исходя из скрипта разбора текстовых версий можно предположить, что правил в цепочке не должно быть больше 16 (хотя возможно это только для текстовых).Совершенно необязательно, что этих правил в разных цепочках будет одинаковое количество или даже длиться они будут одинаковое время.

Правило содержит в себе всегда ровно 23 байта. Примерное описание -

<pre>
9A 99 99 3E 00 00 A0 40 00 00 80 00 80 00 80 00 80 00 80 00 80 00 80
----------- ----------- -- ----- ----- ----- -----------------------
значение время ф k1 k2 k3
</pre>

*'''значение''' - 4-байтная float переменная, обычно меняется от -1 до +1
*'''время''' - в секундах 4-байтная float переменная
*'''ф''' - функция, во всех ppe равна 00, но попробовал менять('''не должна быть 04 - игра вылетает'''). 00,03 - синус, 01,05 - косинус, 02 - линейная, остальные значения игнорируются и правило перестает работать вообще.
*'''k1, k2, k3''' - коэффициенты для функций вот с ними почти не разбирался, на линейную фунуцию изменений не выявил, на синус/косинус влияют очень сильно, но на поиск закономерности не хватило времени, по умолчанию равны 00 80 00 80 00 80
*остаток строки во всех файлах 00 80 00 80 00 80 00 80 - изменение визуально ничего не меняет, возможно зарезервировано для следующих версий.

Вот и все. Поле для работы как видите еще есть - коэффициенты k[1,2,3] и переменные free[1,2,3] - предлагаю общественности устроить мозговой штурм на них.

Напоследок мой файл ночного зрения с комментариями (для использования комменты удалить, шестнадцатиричный код загнать в WinHex и сохранить как '''anims\x.ppe'''(имя любое), и не забыть поправить '''config\misc\postprocess.ltx''' в нужной секции).

<pre>
01 00 00 00 // сигнатура

// Цвета выкручиваем на максимум
7C 00 00 00 // free1
01 01 02 00 // color_add_red
00 00 80 3F 00 00 00 00 00 00 80 00 80 00 80 00 80 00 80 00 80 00 80
00 00 80 3F 00 00 00 41 00 00 80 00 80 00 80 00 80 00 80 00 80 00 80
01 01 02 00 // color_add_green
00 00 80 3F 00 00 00 00 00 00 80 00 80 00 80 00 80 00 80 00 80 00 80
00 00 80 3F 00 00 00 41 00 00 80 00 80 00 80 00 80 00 80 00 80 00 80
01 01 02 00 // color_add_blue
00 00 80 3F 00 00 00 00 00 00 80 00 80 00 80 00 80 00 80 00 80 00 80
00 00 80 3F 00 00 00 41 00 00 80 00 80 00 80 00 80 00 80 00 80 00 80

// Не понимаю как, но эта триада подкрашивает уже переведенное в
// чб изображение, то есть делаем слегка синеватым результат, заодно
// огрубляем слегка красные или зеленые.

6C 10 00 00 // free2
01 01 02 00 // color_base_red
CD CC CC 3D 00 00 00 00 00 00 80 00 80 00 80 00 80 00 80 00 80 00 80
CD CC CC 3D 00 00 00 41 00 00 80 00 80 00 80 00 80 00 80 00 80 00 80
01 01 02 00 // color_base_green
CD CC CC 3D 00 00 00 00 00 00 80 00 80 00 80 00 80 00 80 00 80 00 80
CD CC CC 3D 00 00 00 41 00 00 80 00 80 00 80 00 80 00 80 00 80 00 80
01 01 02 00 // color_base_blue
CD CC 4C 3E 00 00 00 00 00 00 80 00 80 00 80 00 80 00 80 00 80 00 80
CD CC 4C 3E 00 00 00 41 00 00 80 00 80 00 80 00 80 00 80 00 80 00 80

// В сером режиме все красные обьекты - белым, синие и зеленые - черным

7C 00 00 00 // free3
01 01 02 00 // color_gray_red
00 00 80 3F 00 00 00 00 00 00 80 00 80 00 80 00 80 00 80 00 80 00 80
00 00 80 3F 00 00 00 41 00 00 80 00 80 00 80 00 80 00 80 00 80 00 80
01 01 02 00 // color_gray_green
00 00 80 BF 00 00 00 00 00 00 80 00 80 00 80 00 80 00 80 00 80 00 80
00 00 80 BF 00 00 00 41 00 00 80 00 80 00 80 00 80 00 80 00 80 00 80
01 01 02 00 // color_gray_blue
00 00 80 BF 00 00 00 00 00 00 80 00 80 00 80 00 80 00 80 00 80 00 80
00 00 80 BF 00 00 00 41 00 00 80 00 80 00 80 00 80 00 80 00 80 00 80

// Полностью черно-белое изображение с учетом правил color_gray_*
01 01 02 00 // gray
00 00 80 3F 00 00 00 00 00 00 80 00 80 00 80 00 80 00 80 00 80 00 80
00 00 80 3F 00 00 00 41 00 00 80 00 80 00 80 00 80 00 80 00 80 00 80

01 01 00 00 // blur

// Двоения в глазах не будет

01 01 00 00 // duality_h
01 01 00 00 // duality_v

// Шума не будет
01 01 00 00 // noise_intensivity
01 01 00 00 // noise_granularity
01 01 00 00 // noise_fps
</pre>

===Ссылки===
Утилиты так или иначе связанные с этим форматом:
*[http://stalkerin.gameru.net/modules.php?name=Downloads&d_op=getit&lid=331 xrFSL src 18/06/08] от '''Neo]['''
*[http://stalkerin.gameru.net/modules.php?name=Downloads&d_op=getit&lid=352 Ppe Editor 1.2.0] от '''SmanxX1'''
[[Категория:Форматы_файлов]]

Space restrictor

2010-02-22T09:04:49Z

94.141.39.153:

==Начало==
----------------------------------------------------------
Значит распаковываем алл.спавн с помощью ACDC...Распаковали.
Откроем,например,alife_l02_garbage.ltx.
в самом конце допишем:

[2145] 
<nowiki>; cse_abstract properties</nowiki> 
section_name = space_restrictor 
name = sgm_kvest 
position = 41.297409057617,0.44233170151711,-299.86953735352 
direction = 0,0,0 
<nowiki>; cse_alife_object properties</nowiki> 
game_vertex_id = 253 
distance = 0 
level_vertex_id = 214760 
object_flags = 0xffffff3e 
custom_data = <<END 
[logic] 
active = sr_idle 
 
[sr_idle] 
on_actor_inside = %+story_sgm_kvest2_3% 
 
END 
 
<nowiki>; cse_shape properties</nowiki> 
shapes = shape0 
shape0:type = box 
shape0:axis_x = 6.5,0,0 
shape0:axis_y = 0,6.5,0 
shape0:axis_z = 0,0,6.5 
shape0:offset = 0,0,0 
<nowiki>; cse_alife_space_restrictor properties</nowiki> 
restrictor_type = 3 
----------------------------------------------------------
где: 
[2145] - порядковый номер; 
section_name = space_restrictor - имя секции(HаM надо space_restrictor); 
name = svalka_prikol - имя(задаём любое); 
position = - позиции(место где будем спавнить его); 
direction = - поворот рестриктра(не трогаем..); 
game_vertex_id = гейм вертекс; 
level_vertex_id = - левел вертекс; 
----------------------------------------------------------
==Координаты==
Примечание: 
координаты спавна, game_vertex_id и level_vertex_id можно получить с помощью функции: 
 
function main_menu:OnButton_credits_clicked() 
local text 
local vid 
local gvid 
local a = vector() 
local text 
a = db.actor:position() 
vid = db.actor:level_vertex_id() 
gvid = db.actor:game_vertex_id()
text = "Позиция:\\nX= "..a.x.."\\nY= "..a.y.."\\nZ= "..a.z.."\\nlevel_vertex= "..vid.."\\ngame_vertex_id= "..gvid 
news_manager.send_tip(db.actor, text, nil, nil, 30000) 
end 

просто допишите её в ui_main_menu.script,в самом конце. 
---------------------------------------------------------- 
object_flags = не трогаем (оставим 0xffffff3e) 
custom_data = не трогаем (тоесть оставляем <<END ) 
---------------------------------------------------------- 
==Logic==
===Выдача infoportions===
теперь логика для рестриктра: 
 
[logic] 
active = sr_idle 
 
[sr_idle]
on_actor_inside = %+имя инфопоршня% 
END 
 
С такой логикой рестриктор будет выдавать ГГ инфопоршень. 
----------------------------------------------------------
===Эффекты выброса===
 
[logic] 
 
active = sr_idle 
 
[sr_idle] 
on_timer = 100000| %=start_small_reject% sr_idle2 
 
[sr_idle2] 
on_timer = 100000| %=start_small_reject% sr_idle 
END 
 
такая логика будет запускать каждые 100 сек,эффекты выброса. 
----------------------------------------------------------
===Проверка на наличие и выдача Infoportion===
 
[logic] 
active = sr_idle 
[sr_idle] 
on_actor_inside = {=имя_инфопоршня_3 +имя_инфопоршня_2} nil %+имя_инфопоршня_1% 
END 
 
{=имя_инфопоршня_3 +имя_инфопоршня_2} - это проверка(условие) что у ГГ есть нужный инфопоршень.Если есть,то рестриктор выдаст нужный инфопоршень. 
---------------------------------------------------------- 
==Shapes==
Двигаем дальше. 
shapes = тут вписываем названия шейпов 
Пример: 
shapes = shape0 
 
shape0:type = - это тип шейпа.Ставить или box,или sphere. 
box - коробка 
sphere - сфера 

shape0:axis_x = ваша цифра,0,0 
shape0:axis_y = 0,ваша цифра,0 
shape0:axis_z = 0,0,ваша цифра 
- размеры шейпа. 
 
restrictor_type - тип рестриктра. 
 
я везде ставлю restrictor_type = 3,поэтому сказать не могу на что влияет значение. 
Ну вот и всё.Думаю всё чётко и ясно.Будут вопросы обращайтесь. 
ПС: спасибо р-09 за объяснение некоторых моментов с логикой. 
 
space restrictor 

Статью написал джЭдай,SGMTeam. 
Статью преобразовывал в вики (неправильный перенос строк, ошибки с отсутствием некоторых знаков, запись в категорию) - '''Rekongstor'''

[[Категория:Скрипты]]

3dsmax 2010. Создание террейна

2010-02-22T09:03:22Z

94.141.39.153:

== Инструменты. ==
В работе использован плагин экспорта в формат[http://www.stalkerin.gameru.net/downloads/SDK/xraymaxtools-20090821.rar .object]
 И сам 3D’s Max 2010
<hr>

== Начало работ ==
[[Изображение:B3fa0ddb2803.jpg|thumb|Плоскость и Панель]]
Открываем 3д макс, создаем, например, плоскость '''Object Type > Plane '''. Она должна быть небольшой, так как в процессе работы она нам не понадобится и мы её удалим.
 А сейчас кликаем по ней правой кнопкой мыши Convert to > Editable Poly > и видим что сверху в панели управления(FreeForm) появилось две вкладки ''Poly Draw'' и ''Paint Deform''[[Изображение:Example.jpg|thumb|Тропинки]]

 Далее кликаем Poly Draw и выбираем '''Strips'''. Рисуем тропинки для нашей локации. После того, как они будут готовы, плоскость которую мы создали, нужно удалить.
 Теперь у нас есть несколько тропинок, но они не соединены между собой.
Переходим в режим редактирования Edge'eй, правой кнопкои '''> Convert to > Editable Poly > Edge '''
 
Соединяем между собой тропинки, чтобы это сделать выделяем нужный эдж, после чего кликаем по кнопке''' Bridge''' в свитке ''Edit Edges'' - Готово!

== Создание земли ==
Повторяем процедуру с плоскостью, но теперь в ''Poly Draw'' выбираем не Strips а''' Shapes'''<hr>
 Опять рисуем, только уже не тропинки а землю. Должно получится как то так*.[[Изображение:Wwrdsad.jpg|thumb|как то так*]]
Теперь осталось дать материал земле и дороге. Выделяем их поочерёдно, нажимаем кнопку M(Ь) > Standart > в открывшемся окне выбираем '''X-Ray Material'''.<hr> Напротив texture кликаем по None> Bitmap > Находим текстуру для объекта. Напротив параметров: ''Engine/Compiler Shader'' и ''Game Material'' выбираем из списка нужные вам!
 Растягиваем текстуру по обьекту с помошью '''Unwrap UVW''' (Сonvert to Editable Poly > Modifier List > Unwrap UVW )
 '''Готово!'''
 Теперь осталось лишь экспортировать полученный terrain в '''Level Editor'''
 Выделяем все объекты. В левом верхнем углу кликаем по значку макса > '''Export > Export > Сохраняем в нужном вам мете на диске X '''(можно сразу в папке rawdata/objects или просто кинуть в папку import)
 <hr>Теперь осталось лишь загрузить терреин в Level Editor'e расставить спауны, лаиты и глоу, объекты и можно компилировать уровень!

[[Категория:SDK]]

3dsmax. Работа с Unwrap UVW

2010-02-22T09:00:02Z

94.141.39.153:

==Подготовка==
===Предисловие===

Эта статья рассчитана на людей, не понимающих всех моментов работы в Max'е

Некоторые вообще не умеют накладывать текстуру на модель, многие не умеют применять текстуру к определённой части объекта, но всё же очень многие не умеют пользоваться Unwrap UVW. О нём уже упоминалось в [[Создание_моделей_и_их_добавление_в_игру|статье по созданию 3d моделек]]

Но тем не менее она была не подробной. Например научился накладывать текстуру я только в одном из уроков из ЛКИ :D
Поэтому начнём.

===Инструментарий===
* 3ds max 8
* Плагины экспорта (лучше будет и иметь плагины импорта тоже)
* X-Ray SDK
* Photoshop (или другой редактор... Paint.NET например)
* Совсем небольшие навыки создания объектов в максе (то, что не знаете, meltn описано здесь)

==Практика==
===Модель===
Для начала я создал бокс. Потом изменил его высоту, ширину, длину:
L. = 0,3
W. = 0,21
H. = 0,007

Вы можете использовать свои размеры.

[[Изображение:Rek0_UVW_-_модель.png]]

===Текстурирование===
====Накладываем текстуру====
Теперь наложите на него текстуру:
* Откройте Material Editor
Далее я пропущу шаги, т.к. это уже не раз описывалось в уроках по теме 3ds max на Stalker Inside
* Вот Вы наложили текстуру (обратите внимание, что текстура должна быть одним файлом!

[[Изображение:Rek0_UVW_-_текстура.png]]

Не все знают, как накладывается текстура. Поэтому напишу:
- '''Зажмите''' на шарике в Material Editor левую кнопку мыши.

Если передвинуть мышь, указатель станет другим (квадратная рамка и круг с крестом поверх рамки)

- Перенесите текстуру на модель.

Указатель снова поменяется (квадратная рамка, но только поверх неё - курсор) и появится подсказка,
на какой объект мы перемещаем материал.

- Разожмите клавишу мыши, когда произойдёт последнее вышесказанное изменение курсора

Не забудьте нажать на сине-белый кубик в Mat.Editor'е (чтобы мы видели, как легла текстура)

====Unwrap UVW====
Но что это? Когда мы посмотрели на модель, увидели, что текстура легла беспорядочно! Вот для этого и нужен Unwrap UVW

Перейдите в режим Modify. Сделайте последние изменения объекта и можно создавать Un-UVW. Нажмите на свиток Modifier List\Unwrap UVW

* Нажмите на "+" перед Unwrap UVW и выберите в открывшемся свике Face.
* Нажмите на нужную сторону объекта.

[[Изображение:Rek0_UVW_-_face.png]]

*Теперь в правой панели нажмите в свитке Parameters кнопку Edit
*В открывшемся окне нажмите на свиток Character Pattern и выберите в контекстном меню "Map#1" (или другой, но чтобы в скобках было написано название вашей текстуры)

Есть 4 варианта изменения наложения и режим Mirror - для отражения текстуры по горизонатли)
*Move - Двигать выделенные точки
*Rotate - Вращать их
*Scale - Изменять размер
*Freeform mode - Поговорим отдельно.

FF Mode:
Можно свободно изменять размер и т.д. без одновременного изменения нужного по другим осям.
Чтобы изменить:
Размер - Выделите точки и двигайте углы
Позицию - Двигайте красную сетку
Угол поворота (Rotate) - Двигайте бока выделенных точек.

Вот мы и закончили изменение одного лица (face), затем другого...

Потом нажмите правой кнопкой на объект и перейдите в: Convert To\Editable Mesh

Затем в панели Modify можно отсоединять Faces и уже по-отдельности (если не получилось в одном объекте) можно создавать для объектов Un-UVW

И вот у меня получилась такая модель:

[[Изображение:Rek0_UVW_-_end.png]]

Хм... Где-то я её уже видел.... Что-то похожее..... А! Точно!
Сама игромания писала однажды урок :)). По созданию объектов в максе.

Вот [http://www.igromania.ru/upload/articles/109/54894/models_import_04.jpg|Вот я её вспомнил] :)
==Заключение==
Мы научились накладывать на объекты текстуры, которые будут правильно ложиться в последующих действиях.
Кстати.. Перед тем, как создавать Physique (или, если будете делать статический, то перед экспортом),
сконвертируйте объект в Editable Mesh ещё раз на всякий...

'''''Журнал, текстуру которого я пирменл для этой статьи - пробил мне дорогу в модмейкерство Сталкера. Без него не было бы меня здесь...'''''

==Авторы==
* [[Участник:Rekongstor]] - Написал статью, проверил, показал.
* Stalker2012 - Подал идею <десу>

[[Категория:SDK]]