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

[Kirag 39]

malandrinus

Спасибо за помощь и просвещение! А то делать-то я делаю, но половину не сильно понимая, "зачем" и "почему", только "как"

 

Это вот такое перечисление (суть набор именованных констант) языка C++:

enum MonsterSpace::EScriptMonsterMoveAction {

eMA_WalkFwd,

eMA_WalkBkwd,

eMA_Run,

eMA_Drag,

eMA_Jump,

eMA_Steal,

};

Ему соответствуют константы, определённые в том-же классе move:

move.walk_fwd

move.walk_bkwd

move.run_fwd

move.drag

move.jump

move.steal

 

 

А где можно посмотреть все эти перечисления и чему они соответствуют, чтобы тебя каждый раз не дергать?

[Kirag 39]

Monnoroch

 

Что-то, значит, я туплю. Строка, например, eMA_WalkFwd в lua_help вообще не встречается, а MonsterSpace::EScriptMonsterMoveAction - только как аргумент в функциях. Можешь носом ткнуть? У меня lua_help от патча 1.0004, если что, но не думаю, что этот файл менялся от патча к патчу.

 

А eMA_WalkFwd - константа движка как я понял,она из С++, и в луа хелпе не обозначена.

В том-то и дело, что как их вычислять по enum-ам? И enum-ы в аргументах встречаются сплошь и рядом. malandrinus же как-то составил список...

Изменено 28 Июля 2009 пользователем Kirag

[Kirag 39]

Возможно ли определить направление взгляда ГГ? Метод direction() здесь не подходит - этот метод выдает положение тела, при движении мышкой в каких-то пределах тело не двигается. А нужно именно направление взгляда/линии прицеливания.

 

Метод head_orientation() выдает какие-то заоблачные цифры, его я уже пробовал.

 

malandrinus

Спасибо, помогло! Оно и есть

Изменено 3 Августа 2009 пользователем Kirag

[Kirag 39]

Вопрос по нет-пакетам:

 

Все примеры перепаковки нет-пакетов, что я видел, никак не затрагивали свойства cse_abstract:

 

; cse_abstract properties
section_name = helicopter
name = esc_heli
position = -317.183898925781,16.3679752349854,83.289665222168
direction = 0,-1.47526597976685,0

 

Можно ли до них как-нибудь добраться? Конкретно интересует direction, чтобы задать при спавне через скрипт сразу нужную ориентацию в пространстве. Или есть другие способы это сделать?

Изменено 4 Августа 2009 пользователем Kirag

[Kirag 39]

malandrinus,

 

Вот функция спавна вертолета:

 

function heli(posx,posy,posz,lvid,gvid,logic)
    local obj = alife():create("helicopter",vector():set(posx,posy,posz),lvid,gvid)
    local packet = net_packet()
    obj:STATE_Write(packet)

    -- свойства cse_alife_object
    local game_vertex_id = packet:r_u16()
    local cse_alife_object__unk1_f32 = packet:r_float()
    local cse_alife_object__unk2_s32 = packet:r_s32()
    local level_vertex_id = packet:r_s32()
    local object_flags = packet:r_s32()
    local custom_data = packet:r_stringZ()
    local story_id = packet:r_s32()
    local cse_alife_object__unk3_s32 = packet:r_s32()

    -- свойства cse_visual
    local model_visual = packet:r_stringZ()
    local cse_visual__unk1_u8 = packet:r_u8()
    -- свойства cse_motion
    local motion_name = packet:r_stringZ()

    -- свойства cse_ph_skeleton
    local skeleton_name = packet:r_stringZ()
    local cse_ph_skeleton__unk1_u8 = packet:r_u8()
    local cse_ph_skeleton__unk2_u16 = packet:r_u16()
        
    -- свойства cse_alife_helicopter
    local cse_alife_helicopter__unk1_sz = packet:r_stringZ()
    local engine_sound = packet:r_stringZ()

    --устанавливаем логику
    custom_data = "[logic]\ncfg = scripts\\heli\\"..logic..".ltx"

    -- теперь заполняем нужные параметры
    -- свойства cse_alife_object
    packet:w_begin(game_vertex_id)
    packet:w_float(cse_alife_object__unk1_f32)
    packet:w_s32(cse_alife_object__unk2_s32)
    packet:w_s32(level_vertex_id)
    object_flags = bit_not(5)    -- ~5 = 0xfffffffa
    packet:w_s32(object_flags)
    packet:w_stringZ(custom_data)
    packet:w_s32(-1)
    packet:w_s32(cse_alife_object__unk3_s32)

    -- свойства cse_visual
    packet:w_stringZ(model_visual)
    packet:w_u8(cse_visual__unk1_u8)
    
    -- свойства cse_motion
    packet:w_stringZ(motion_name)        
    
    -- свойства cse_ph_skeleton
    skeleton_name = "idle"
    packet:w_stringZ(skeleton_name)
    packet:w_u8(cse_ph_skeleton__unk1_u8)
    packet:w_u16(cse_ph_skeleton__unk2_u16)

    -- свойства cse_alife_helicopter
    cse_alife_helicopter__unk1_sz = "idle"
    engine_sound = "alexmx\\helicopter"
    packet:w_stringZ(cse_alife_helicopter__unk1_sz)
    packet:w_stringZ(engine_sound)

    -- считываем скорректированные параметры
    packet:r_seek(0)
    obj:STATE_Read(packet, packet:w_tell())


    return obj
end

 

 

 

Вот вертушка из алл.спавна:

[107]
; cse_abstract properties
section_name = helicopter
name = esc_heli
position = -317.183898925781,16.3679752349854,83.289665222168
direction = 0,-1.47526597976685,0

; cse_alife_object properties
game_vertex_id = 0
distance = 0
level_vertex_id = 594270
object_flags = 0xfffffffa
custom_data = <<END
[logic]
...тут логика...
END
story_id = 14

; cse_visual properties
visual_name = physics\vehicles\mi24\veh_mi24_u_01

; cse_motion properties
motion_name = helicopter\aaa.anm

; cse_ph_skeleton properties
skeleton_name = idle

; cse_alife_helicopter properties
startup_animation = idle
engine_sound = alexmx\helicopter

 

 

 

В нет-пакете обрабатываются свойства cse_alife_object, cse_visual, cse_motion, cse_ph_skeleton, cse_alife_helicopter - т.е. все свойства из алл.спавна, кроме cse_abstract. Насколько я понимаю, после команды

obj:STATE_Write(packet)

пакет начинает разбираться последовательно и с самого начала, т.е. в начале пакета никакого direction нет. Более того, операции над вектором r_vec3() в функции вообще ни одной нет, стало быть перепутать я его ни с чем не мог. Отсюда и вопрос - где же искать этот вектор в нет-пакете?

[Kirag 39]

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

 

Влад

 

По 1 способу - теоретически, могло бы прокатить, если бы вместо badwill вернуть goodwill. Не знаю, правда, что именно таким образом установится, но параметра badwill в игре нет в принципе, да и в английском языке - не уверен.

 

По 2 способу - не определено, что такое npc. Это должен быть game object, и его удобнее передавать в функцию из того скрипта, где он определяется, нежели определять внутри функции (сама функция может много где понадобиться). Также вместо actor нужно писать db.actor, иначе будет возмущаться по поводу того, что переменная actor равна nil. Т.е. допустим, ты в основном скрипте каким-то образом получил объект npc. Тебе надо сделать его врагом. Пишешь в основном скрипте строку:

enemy(npc)

 

И сама функция(должна находиться в том же файле, что и основной скрипт, из которого вызывается):

 

function enemy(npc)

npc:set_relation (game_object.enemy, db.actor)

end

 

P.S. Если функция enemy(npc) находится в другом файле, например, в файле file.script, вызывать ее надо уже так:

file.enemy(npc)

[Kirag 39]

strelokk

 

1. Это тебе нужно новый гулаг делать. Только через алл.спавн (или есть варианты, может знает кто?). Тебе нужно в алл.спавне добавить смарт террейн и прописать пути. Потом в скриптах гулага определить его состояния и набор работ. Ну и для каждой работы прописать логику. Задачка в целом не очень сложная, но возни очень много.

 

2. В идеале - config\gameplay\characters_desc_general.xml. Но есть одна проблема (по крайней мере, в чистой игре это так) - все то, что прописано в этом файле, заблокировано в алл.спавне в логике актора секцией [dont_spawn_charactrer_supplies]. Удали ее оттуда, и можно будет задавать стартовый инвентарь из указанного файла.

Ну, либо сделать скриптовый спавн в начале игры.

[Kirag 39]

Тип удара wound - это, например, кабан - т.е. снимает хиты, а кровотечение постольку поскольку. За чистое кровотечение без потери хитов отвечает (по крайней мере, для актора) удар chemical_burn - аномалия "кисель", "холодец" или как ее там - зеленая пузырящеяся гадость в оригинале. Даже на запредельной мощности хиты от самого удара не снимала, зато кровь как из ведра хлестала, бинтов пять сожрать надо, чтобы индикатор из красного стал оранжевым.

 

Тут как-то интересовались по поводу бессмертных сталкеров, почему не дохнет Сахаров и почему дохнут все остальные даже с классом и секцией Сахарова. В общем, похоже, понял я в чем тут дело.

У Сахарова в модели НЕ прописаны иммунитеты (ни прямо, ни через #include), поэтому они берутся из config\creatures\m_stalker.ltx из его секции. Больше, чем уверен, что такая ситуация со всеми моделями, в которых иммунитет не прописан.

У подавляющего большинства (если не у всех) остальных сталкеров в модели прописан #include, который в конечном итоге приводит к файлу config\creatures\immunities.ltx, к одной из тамошних секций иммунитета. В этом случае иммунитет из m_stalker просто игнорируется, вместо него берется иммунитет из immunities.

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

Соответственно, делаем выводы. Для создания бессмертного НПС надо либо поправить immunities.ltx, что с гарантией аукнется по всей игре, либо сделать копию модели, аккуратно поправить в ней #include и сделать/прописать секцию иммунитета для бессмертных

[Kirag 39]

Brohtar, ковыряй параметр hemi_color в погодных конфигах. От консоли толку не будет, там для r1 всего ничего

[Kirag 39]

Brohtar

 

Параметр hemi_color находится в файле (для дефолтной погоды, для остальных - в соответствующих файлах, ну, поймешь, думаю) config\weathers\weather_default.ltx в секциях погоды на каждый час, ближе к концу секции. Смысл - аналогично параметру ambient, возможно, есть еще какой-то эффект, не знаю. Первые три цифры - три цветовые компоненты RGB. Чем меньше значение, тем темнее. Что означает последняя четвертая цифра - понятия не имею, ее изменение видимого эффекта не дает (или я не знаю, на что смотреть). В принципе, можно выставить и все компоненты по нулям, будет искомая темная ночь.

[Kirag 39]

Уважаемые сталкеры! Такой вопрос:

 

В логике НПС при переключении секций можно проверять выполнение условий и выставлять дополнительные эффекты, например:

on_info = {=function1} новая_секция %=function2%

При этом функция проверки условия function1 должна находиться в файле xr_conditions.script, а функция эффекта function2 - в файле xr_effects.script

 

Пока ничего нового, все это давно известно. Вот только в каком-то моде я видел, что эти функции как-то выносились в ДРУГИЕ файлы. То есть сделать это возможно. Пробовал и в условии написать {=file.function}, и в эффектах %=file.function% - получаю вылет

 

FATAL ERROR

 

[error]Expression : fatal error

[error]Function : CScriptStorage::namespace_loaded

[error]File : E:\stalker\patch_1_0004\xr_3da\xrGame\script_storage.cpp

[error]Line : 445

[error]Description : <no expression>

[error]Arguments : Error : the namespace name is already being used by the non-table object!

 

Сама по себе функция точно рабочая - перенес ее в xr_conditions - все работает без проблем.

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

[Kirag 39]

Этот мод АМК Посмотри изменения в файле xr_logic.script

 

Спасибо! Что-то я затупил. Искал ведь в логике от АМК эти моменты, проспал видно

 

Уважаемые подскажите как сделать что бы оружие убитого НПС при поднятии было разряжено ?

 

Это было и в оригинале, и в АМК, в файле death_manager.script. В функции keep_item(npc,item) перед уменьшением кондишена оружия из обоих слотов убитого НПС были строки (167-я и 174-я для АМК):

item:unload_magazine()

 

Но они, по идее, затрагивали только то оружие, что находилось у НПС в слотах. Для оружия, валяющегося в инвентаре, надо по идее проверять каждый предмет (насколько я понимаю, это все равно делается), если это оружие, то портить и разряжать.

[Kirag 39]

karavan

Это не скрипт, а свойство конфига, в оригинале на нем сделан полтергейст. Не знаю, правда, для каких классов оно работает, пробуй

[Kirag 39]

karavan

В конфигах, само собой. Допиши в нужный по аналогии и посмотри, прокатит или нет.

[Kirag 39]

The Dr.MOHCTP

В оригинале - в алл.спавне. Искать лучше по слову "code" - не придется отсеивать всякие шкафчики и прочую муть, попадут только кодовые двери и замки к ним.

 

Renson

Большинство рядовых неписей находятся под гулагами, в логике гулаговских работ и надо искать.

[Kirag 39]

foxbat21, посмотри в character_desc_simulation.xml, там куча квестовых НПС, во 2й половине файла.

 

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

[Kirag 39]

Wlad777

 

Точно не знаю, но рискну предположить.

 

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

[Kirag 39]

Срастить два сюжета? Интересно... В принципе, по такому раскладу можно смело убирать инфопоршены, уже пройденный сюжет обрушить сложно. Сложности могут начаться, если инфопоршены из разных сюжетов совпадут по названию...

[Kirag 39]

Народ, кто разбирается в партиклах, подскажите.

 

Делаю управляемую ракету, работать - работает, но с дымным шлейфом проблемы. Единственный вечноживущий партикл, который худо-бедно подходит - это движок от гранаты РПГ. Он для управляемой ракеты не смотрится совершенно.

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

Тогда поставил рисование партиклов на fastcall, вызывается раза в два чаще, чем апдейт актора. Получил очень красивый след ракеты и вылет с чистым логом на второй ракете. Ладно, рисую партикл через каждые пять вызовов fastcall - тоже красивый след, хватило на три ракеты, потом тот же вылет. Один раз из 25 вызовов - уже ракет пять-семь, след уже невразумительный, потом вылет. Убрал отрисовку партиклов вообще - работает как часы.

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

 

Рисовал партиклы вот этой командой:

particles_object([[explosions\group_items\expl_10_smoke]]):play_at_pos(self.object:position())

Может, партиклы еще и отключать как-то надо, несмотря на то, что они уже исчезли?

 

[Kirag 39]

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

 

Что же касается вопроса про телепорт, то ошибка в методе set_actor_position: у него единственный аргумент - вектор позиции, гейм и левел вертексы в данном случае не нужны. Далее, в качестве точки назначения ты передаешь pos = db.actor:position(), т.е. текущую позицию актора. Если и сработает - не заметишь. Нужно передавать координаты назначения, например, pos1. Ну, как рассчитать pos1 - разберешься.

Т.е. сам перенос будет выглядеть вот так:

 

db.actor:set_actor_position(pos1)