[SoC] Ковыряемся в файлах

[volazar 13]

Всем привет! Появился вопрос касательно логики вертолета. А именно выдачу поршня после смерти обьекта.

Имеем такую логику:

[logic]
active = heli_move@idle
on_death = death

[death]
on_info = %+heli_dead_1%

[heli_move@idle]
path_move = esc_heli_idle_move
path_look = esc_heli_idle_look
engine_sound = true
combat_use_rocket = true
combat_use_mgun = true
rocket_delay = 3000
combat_safe_altitude = -50
mute = true

 

move и look соответственно прописаны в алл спавне.

Вертолет спавнится, летит в нужную точку и обстреливает в моем случае дом.

Только вот незадача, on_death не работает после смерти вертолета.

Если ли какой нибудь другой способ, узнать, что вертолет мертв и выдать поршень/совершить действие?

Изменено 2 Сентября 2012 пользователем volazar

[volazar 13]

Magnus1, Прописываете диалоги обоим нужным неписям. У одного, ставите проверку поршня на диалог (<has_info>поршень</has_info>). А у другого, в конце диалога наоборот, выдаете этот поршень (<give_info>поршень</give_info>).

Виден сначала только один диалог. Как поговорили с ним, появляется другой диалог.

[volazar 13]

Struck, при вылезании из тоннеля? Когда приходит СМС от Сахарова, что мол ты жив, излучение отключено и т.д?

Если да, то там рестриктор, который выдает поршень yantar_tunnel_finish

[volazar 13]

Всем доброго вечера! Возникла проблема с проигрыванием анимации НПС.

Имеем такую логику:

 

 

[logic]
active = kamp@volazar

[kamp@volazar]
center_point = vol_war_kamp
radius = 2
meet = meet@on
on_info = {+vol_go_lab} sr_idle@wait

[sr_idle@wait]
on_timer = 5000 | patrol@open_door

[patrol@open_door]
path_walk = vol_patr_go_to_the_door
path_look = vol_look_go_to_the_door
meet = meet@off
on_info = {+vol_go_lab2} sr_idle@wait2

[sr_idle@wait2]
on_timer = 5000 | remark@open_door

[remark@open_door]
anim = press
meet = meet@off
target = vol_look_go_to_the_door,0
on_timer = 7000 | remark@open_door2

[remark@open_door2]
anim = punch
snd = use_abuse
meet = meet@off
target = vol_look_go_to_the_door,0
on_timer = 7000 | patrol@open_door2

[patrol@open_door2]
path_walk = vol_patr_go_to_the_door2
path_look = vol_look_go_to_the_door2
meet = meet@off

[meet@on]
use = true
use_wpn = false

[meet@off]
use = false
use_wpn = false

 

Соответствующие пути естественно прописаны.

Суть "сценки" вот в чем: НПС сидит у костра, в определенный момент (при наличии у актора поршня) он встает и идет к двери с кнопкой. Подойдя к кнопке, останавливается и проигрывает анимацию press (нажатие), затем ждет и говоря звуковую фразу (пока что написана от балды) бьет кулаком (анимка punch) по ней (кнопке). После чего, дверь открывается.

 

Все хорошо до начала проигрывания первой анимации. Вместо того, чтобы ее проиграть, НПС садится на землю и начинает "ездить" по локации.

Ради интереса, заспавнил еще одного НПС, который сразу же проиграл все анимации как мне нужно(!).

В чем может быть проблема? Или не все, что нужно, можно реализовать (глючность анимаций?).

[volazar 13]

ColR_iT, твой способ к сожалению тоже не сработал...

Покопался и нашел причину. В который раз убеждаюсь, что пути Зоны неисповедимы))

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

*** *** ***

Под "ездит" я подразумевал то, что НПС садился на пятую точку и таким образом беспорядочно "плавал/ездил" по всей локации.

[volazar 13]

AndreySol, а зачем добавлять в level.spawn? Я спавнил в Варлабе просто через all.spawn и все работало.

Приведу секцию настольного светильника:

 

section_name = lights_hanging_lamp
name = war_svet_5
position = 39.122,-2.500,-4.293
direction = 0,0.8,0
s_flags = 0x23

; cse_alife_object properties
game_vertex_id = 3223
distance = 0
level_vertex_id = 7772
object_flags = 0xfffffffa
custom_data = <<END
[collide]
ignore_static
END

; cse_visual properties
visual_name = physics\light\lampa_01_on

; cse_ph_skeleton properties
skeleton_name = 

; cse_alife_object_hanging_lamp properties
main_brightness = 0.8
main_color_animator = light 40 hz
main_range = 2
light_flags = 0xb55c
startup_animation = 
lamp_fixed_bones = link
health = 10000000
main_virtual_size = 0.1
ambient_radius = 2
ambient_power = 0.3
ambient_texture = lights\lights_duolight02grey
main_bone = bone_lamp
main_cone_angle = 2.0
glow_texture = glow\glow_orange
glow_radius = 0.3
ambient_bone = bone_lamp

 

[volazar 13]

AndreySol, как вариант, взять любую уже существующую в игре секцию светильника, скопировать ее изменив только имя и координаты. А затем посмотреть, появится ли объект в игре. Без редактирования level.spawn'а

Если не появится, могу предположить, что собака зарыта в каком то другом месте. Только вот в каком...

 

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

На крайний случай, сделайте поиск по папке с игрой, на наличие в кодах игры выражения ui_hud_ammo_info.

Описали бы хоть, во что играете, что ковыряли и при каких обстоятельствах вылет происходит. А так выходят одни погадалки.

Изменено 3 Октября 2012 пользователем volazar

[volazar 13]

AndreySol, а координаты верные? В 1 после написано: "нормально вроде". Нормально или вроде?

Я у себя встречался с такой ситуацией, когда путал местами гейм/левел вертексы.

В лог выводятся lv - gv. А я в алл спавне и писал в таком же порядке. А потом гадал, где мой предмет. При проверке и оказывалось, что напортачил.

ЗЫ: А номер секции поставлен новый?

ЗЗЫ: Сразу отвечу на "не дал бы acdc запаковать" - ковыряясь в алл спавне от НС - я встречал там такие чудеса...при этом было запаковано. И работало! Начиная от одинаковых секций и кончая русскими(!) буквами в именах секций.

ЗЗЗЫ: Если все это в норме, возможно где то, что то сбоит/глючит. Например в скриптах.

Изменено 3 Октября 2012 пользователем volazar

[volazar 13]

AndreySol, да запросто. Приведу пример не по теме (встретился с ним на практике): если в файле объявить например более 10-15 переменных, каждая из которых ссылается на ф-ию, которая возвращает таблицу (как пример) - то файл становится полностью не читаемым игрой. У меня из-за этого вылазили вылеты по анимациям оружия, безлоговые вылеты при попытке поговорить с каким нибудь НПС, не появление спавнящихся объектов. Казалось бы, причем тут анимации по оружию, или например вылеты с НПС? Однако вот так вот...

*** *** ***

Я не говорю, что виноваты именно они. Я предположил, в чем может быть проблема.

Думаю, что кто нибудь более посвященный в этом деле, придет и возможно укажет причину/поделится похожим опытом.

[volazar 13]

AndreySol, осмелюсь спросить. А файл то в папку с игрой кинули?

ЗЫ: Для проверки, запакуйте, а затем снова распакуйте all.spawn и гляньте, будет ли секция там или нет.

Может дело в распаковщике...

[volazar 13]

Всем привет!

Может кто нибудь поделится значениями флагов из алл спавна, когда объект спавнится через net_packet.

Т.е например, значение 0xfffffffa соотв. числу 5 и т.д

А именно, интересуют значения: 0xffffff3a, 0xffffff3e, 0xffffffba и 0xffffffff

[volazar 13]

Artos, я как раз по модулю m_netpk.script и делаю ф-ию спавна физического объекта с возможностью фиксации.

Копаясь также в amk.script встретился там с функцией спавна вертолета, всю ф-ию приводить не буду, приведу кусочек, который заинтересовал при заполнении параметров cse_alife_object:

 

object_flags = bit_not(5) -- ~5 = 0xfffffffa
packet:w_s32(object_flags)

Получается, что 0xfffffffa = 5. А вот как оно было высчитано?

 

Я пробовал переводить 0xfffffffa в десятичное число - однако получил совершенно другой результат, а не число 5.

[volazar 13]

Buusty​, когда то тоже намучился с путями вертушек. Спавним - летит нормально. Спавним в другой раз - летит абы как. Возможно иногда схема обрабатывается немного криво. А может и еще что.

По взлету - попробуй добавить точку чуть выше (метров 10) и впереди, от того места - где он (вертолет) зависает. А затем уже с той точки, пусть летит по остальным.

Так например сделано с вертушкой Бати на Янтаре - единственный минус там - там не взяли в расчет высоту забора вокруг территории бункера.

[volazar 13]

Struck, а не посмотреть в state_lib.script? Там ВСЕ анимации. И я думаю из их названия, понятно, что это за анимация.

Изменено 11 Октября 2012 пользователем volazar

[volazar 13]

Если ТЧ чистый и если не ошибаюсь - то там нету этой анимации.

Можешь посмотреть например в НС - там она есть - sit_stul.

[volazar 13]

AndreySol, а ты уверен, что имя light_alarm_glass_0004 уникально в игре? Что оно нигде не встречается? Зная ПЫС-ов, они могли спокойно пронумеровать все источники в игре по порядку...

Попробуй сменить имя на уникальное, которое уж точно в игре не используется.

Ну и к сказанному malandrinus-ом, на прошлой странице, добавлю: что встречал в игре такие примеры: спавн сначала физической модели светильника (без всего), а затем уже спавн самого источника света и его расположение в нужном месте физ. объекта ->итого имеем ту же самую лампу.

Изменено 13 Октября 2012 пользователем volazar

[volazar 13]

Artem_K., я не о том. Я про совпадение имен секций.

Одно дело так:

esc_light_1, esc_light_2, esc_light_3 и т.д

И совершенно другое дело, когда например light_alarm_glass_0004 находится и в alife_l01_escape.ltx и например еще где нибудь.

[volazar 13]

stalkerok007, такого шедевра я еще не видел

 

[logic]
active = walker@stay

[walker@stay]
path_walk = walker_stay
on_info = {+infoportion_111} walker@go

[walker@go]
path_walk = walker_go

​

 

Вот рабочий вариант - после того, как ГГ получит поршень infoportion_111, НПС перейдет на другую схему.

ЗЫ: А где точки, куда будет НПС смотреть? path_look

***

stalkerok007, то, что ты там написал, извини конечно - бред. Зачем ставишь разделитель? Зачем пишешь nil? НПС, вместо того, чтобы следовать твоей логике - перейдет под управление движка.

Запятая нужна только в том случае, если у тебя несколько условий. Например:

on_info = {+taynik_nayti_oz_10} mob_walker@bl_3, {+taynik_nayti_oz_10_fail} nil

Если есть поршень taynik_nayti_oz_10, то переходим на новую схему. Если же есть taynik_nayti_oz_10_fail, то nil

***

Данная логика подойдет только для НПС. У БТР-а и мутанта будет немного другая.

О логике можно почитать тУт. Все подробно, с примерами и понятно расписано..

Изменено 31 Октября 2012 пользователем volazar

[volazar 13]

ColR_iT, я про саму логику, а не переход на другую схему.

А такую же логику можно прописать, например, и БТРу и мутанту

 

Извини, не до понял...

ColR_iT

 

Мой косяк, не так сказал)

Я привел пример логики, которая была нужна. А потом спросили - можно ли такую же логику использовать для БТР-а или мутанта.

Я сказал что нет. Именно мой пример - не подойдет. Для мутанта будет не walker, а mob_walker. Для БТР-а будет ph_car и т.д

Пример условия, когда ставится запятая - я привел потому, что спросили:

нужно ли между walker_stay и {+infoportion_111} ставить запятую, или "запятую" и "nil" после черты " | " ?

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

 

"Извини, не до понял" я написал на предыдущую реплику, не в смысле, что я тебя не понял.

ColR_iT

Изменено 31 Октября 2012 пользователем ColR_iT

[volazar 13]

я вот знаю что есть опытные программы для ковыряния движка

Где же вы такие программы нашли? Разрабы дали? 

Что сложного в визуале то? Надо 10? Копируете нужную модель 10 раз и в СДК/через hex/блокнот редактируете путь к текстуре. Будет вам 10 "разных" моделей.

Либо же рисуете свой, вместо старого.

Изменено 23 Мая 2013 пользователем volazar