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

[Сталкер Лом 356]

Здравствуйте. Вопрос мучает: "Возможно ли реализовать двери-слайдеры (аля В ЧН в Депо, или в ТЧ на блокпосте ДОЛГа на Свалке)?" Из ЧН в ЗП переношу, а двигатель мне вылет даёт, мол, в вашей двери нет векторов открытия двери (макс. и мин. градус открытия двери). Посмотрел на логику двери на ВНЗ "Круг", (ph_button@...), сделал подобную, но их открыть невозможно, не вышибать же мне их каждый раз на Запорожце?

За ответ заранее благодарю.

 

Логику то пакажешь или мы сами придумаем, что ты сделал?

ColR_iT

 

[logic]

active = ph_button@closed

 

[ph_button@closed]

anim_blend = true

anim = idle_close

snd_open_start = airtight_gates_start

snd_open_stop = airtight_gates_idle

snd_close_start = airtight_gates_start

snd_close_stop = airtight_gates_stop

 

[ph_button@opening]

anim_blend = true

anim = open

snd_open_start = airtight_gates_start

snd_open_stop = airtight_gates_idle

snd_close_start = airtight_gates_start

snd_close_stop = airtight_gates_stop

on_game_timer = 10 | ph_button@opened

 

[ph_button@opened]

anim_blend = true

anim = idle_open

on_use = ph_button@closed

snd_open_start = airtight_gates_start

snd_open_stop = airtight_gates_idle

snd_close_start = airtight_gates_start

snd_close_stop = airtight_gates_stop

 

Изменено 9 Января 2013 пользователем Сталкер Лом

[makdm 37]

Активная логика : ph_button@closed

С неё нет перехода на другии секции логики. Вот и будет всё-время closed.

[Viнt@rь 50]

Подскажите плз, добавил локу(болота из ЧН) к остальным локам в ЗП, все прекрасно работает можно бегать ни вылетов ничего, но так как локи ЗП не надо, удалил их из алл спавна и соответственно из game.graph, в итоге остались только болота... Вроде бы все норм, игра загружается вылетов нет, стоять крутить камерой ГГ тоже вылетов нет, но если начать двигаться, получаю вылет с таким логом:

Expression : I != levels().end()

Function : GameGraph::CHeader::level

File : d:\prog_repository\sources\trunk\xrgame\game_graph_inline.h

Line : 153

Description : there is no specified level in the game graph : 52

[KD87 718]

и соответственно из game.graph

А каким образом и, главное, зачем?

[Viнt@rь 50]

KD87, c помощью gg_cdc_zp_x5 от xiani, распаковал game.graph, и поудалял ненужные файлы...

главное, зачем?

а че им там торчать то? засорять алл спавн и граф?

Изменено 11 Января 2013 пользователем Viнt@rь

[KD87 718]

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

[Viнt@rь 50]

Да, лишние Аи переходы и Эджи удалял

[KD87 718]

По идее, при удалении эджей, надо править edge_offset у вертексов. Впрочем, не знаю, как сделано у ксиани, может, утилитка автоматом правит. Тогда только пути и объекты в спавне проверять на соответствие вертексов оставшейся локации.

[Viнt@rь 50]

Путей нет, в спавне только актор,

ЗЫ а есть еще какая то утилита, помимо утилиты бардака что бы править графы?

ЗЫЫ Ридми от утилиты ксиани

 

 

скрипт для распаковки game.graph в набор ltx и назад в рабочую версию

версия x.5

модифицирован для работы с графом от игры версии "Зов Припяти"

 

 

 

основан на коде скрипта ggtool.pl взятого из архива "xray_re-tools-src-10sep2008"

автор оригинала: bardak

автор этой штуки: xiani

 

замечания:

заголовок (header)

vertex_count, edge_count, level_point_count, level_count при запаковке обновляются пересчитыванием реального количества соответствующих данных

 

связи (edges)

в самом game.graph хранятся только "game_vertex_id" и "distance"

это то куда идёт связь и как далеко то точки назначения,

а то откуда идет связь определяется родительским вертексом

я добавил "parent_level_vertex_id" чтоб вы могли проследить

в дамп я добавил "target_level_vertex_id" и "target_level_id"(так как "level_vertex_id" могут повторяться в разных уровнях) вместо "game_vertex_id"

так как последний является порядковым номером вертекса и он может меняться если ктото изменит последовательность вертексов (например удалив или добавив уровень)

 

точки уровня (level_points)

вобщем почти те же изменения что и с связями

и снова внимание! они должны идти последовательно одна за другой группами по родительским вертексам

 

вертексы (vertices)

level_point_offset, level_point_count, edge_offset, edge_count учитываться не будут и обновятся скриптом сами для того чтоб вам не пришлось в калькуляторе пересчитывать всё

еще в дамп добавил gvid.. вобщемто просто так, для информации, при запаковке он не используется

 

 

p.s.: в комплекте подправленные stkutils, они нужны для работы, там была добавлена запаковка формата u24

 

v x.5

добавлен сброс level_ai вшитого в граф в виде бинарных дампов, как есть

 

v x.4

добавлен ключ "-lp <level_points_read_mode>"

в котором "level_points_read_mode" может принимать значения:

bin - бинарный режим, читает и записывает level_point-ы без обработки одним цельным куском. если вам не нужно менять level_point-ы то лучше используйте этот ключ так как это намного ускорит работу скрипта (около 95% размера графа уходит в level_point-ы)

skip - ничего не делает с level_point-ами (используется в основном для дебага)

добавлен вывод межуровневых связей в отдельный файл "*.info.cross_edges.ltx", файл не учитывается при сборке, он только для информации

 

v x.3

исправлен огромный баг когда связи могли "переходить" к другим вертексам

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

 

 

[KD87 718]

ты сперва посмотри дампером бардака (ggtool), есть ли уровень с таким id - 52.

[Viнt@rь 50]

Нет, ни в чистом графе, ни в измененном мною, если надо, могу выложить нужные файлы

 

level_vertex_id оно не меняет мб их надо менять тоже? и еще 1 что заметил, если играть с локами из ЗП со всем, то там ГГ спавнится допустим на гейм вертексе 1161, соответственно после удаления ненужных локаций из графа, гейм вертекс его спавна меняется, к примеру на 227, но в игре что так что так информация отображает один и тот же гейм вертекс и левел вертекс

[KD87 718]

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

Изменено 11 Января 2013 пользователем KD87

[Viнt@rь 50]

Тогда как просто убрать(вырезать) стандартные локации? В смысле, просто что бы их карта накладывалась на глобалку и тп...

[Viнt@rь 50]

Как правильно создавать(спавнить) зоны(лагеря) с кострами, что бы костры выключались/включались? в смысле на подобии ЧН, сел рядом около костра нпс костер включился, встали ушли - выключился

[Shredder 49]

В ЗП костры регулируются смарт терейнами:

--проверить есть ли кто-то в смарте, если есть и костры не включены то включить,
--еще проверить есть ли актер, чтоб была гарантия что костры проспонились...
if is_only_monsters_on_jobs(self.npc_info) and self.campfires_on then
bind_campfire.turn_off_campfires_by_smart_name(self:name())
self.campfires_on = false
elseif not is_only_monsters_on_jobs(self.npc_info) and not self.campfires_on then
bind_campfire.turn_on_campfires_by_smart_name(self:name())
self.campfires_on = true
end

 

[Clayman 104]

Viнt@rь, это разбиралось много раз, ищи статьи. Называешь костер имя_смарта_campfire_номер и он загорается когда в лагере есть нпс, тухнет когда уходят.

 

Shredder, по поводу фризов при переходе нпс в оффлайн-онлайн - я поднимал этот вопрос не раз, походу никто не знает как с эти бороться, наверное особенности движка. ИМХО, это самый главный минус ЗП - подходя к зоне с большим количеством нпс (тот-же Скадовск), фризы и лаги становятся просто некрасивыми.

[Shredder 49]

Одно дело поднимать вопрос, другой искать проблему самому. Выяснил одно, фризы не из-за биндера npc, т.е. xr_motivator фризов не создаёт, все его методы не вызывают существенных задержек, ну только что у самого первого нпс, вышедшего в онлайн. Буду проверять другие биндеры/схемы, будет очень жаль, если фризы вызваны не скриптами, а движком.

[Clayman 104]

Ну к сожалению я не в состоянии эту проблему копать из-за ограниченных знаний, если тебе удасться что-то в этом направлении сделать, думаю, многие будут признательны. Сколько пробовал сторонних модов на ЗП, все одно и то-же. Взять тот-же сигериус... Видимо всех это устраивает)) Именно из-за этой проблемы, ИМХО перегружать игру лишними геймплейно-скриптовыми фишками считаю совершенно излишне, нагрузка и лаги сильно возрастают, особенно когда играешь DX-10-11 full HD, проц загружается довольно сильно, лишние навороты делают игру и динамичные бои очень некомфортными.

[Viнt@rь 50]

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

Изменено 13 Января 2013 пользователем Viнt@rь

[Shredder 49]

Нельзя