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

[Artos 99]

Shredder, хм ... вот за скрин и код "как скрутил" - спасибо, теперь еще немного инфы к особенностям функции.

Проверю, конечно, почему нельзя менять визуал спустя N-ное время после спавна ... или это некая особенность.

В общем функция явно не для "нормальной" смены вызуала неписям.

[Artos 99]

Возвращаясь к вопросу (Shredder) о функции set_visual_name:

 

Довольно странная и возможно кому-то интересная функция. Как "правильно" она должна работать или как "правильно" ее использовать - можем пока только предполагать.

Информация пока такова:

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

Обращаю внимание, что обычно смена визуала идет от обратного, т.е. заменяется серверному об'екту и, переводом в оффлайн и обратно, параметры передаются соответствующей копии гейм-об'екта.

2. По единственному практическому примеру из исходной игры можно заметить, что смена визуала разработчиками предусматривалась в самом начале активизации метода net_spawn в биндере сталкера. При чем(!), судя по месту строк, т.е. до: object_binder.net_spawn(self, server_object) - предполагаю, что тут происходит некая синхронозация серверного и клиентского об'ектов в движке игры.

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

Имеется особенность:

- если визуал менять на точно такой же - НПС немного повышает свою защиту/иммунитеты;

- чем более отличен по типу новый визуал от прежнего - тем неубиваемее стновится НПС ...

3. В случае, если визуал "не родной" и функция замены визуала вызывается несколько позже чем в методе net_spawn, хотя бы из level.client_spawn_manager():add(...), что практически одномоментно с нет-спавном, визуал/модель НПС сворачивается в "клубок" и начинает "ползать" по локации, имитируя поведения самого НПС. Т.е. "ходит", порой зарываясь в грунт, стреляет, виден на карте, ... "Корявость" визуала вероятно имеет причиной рассинхронизацию серверной и клиентских копий об'екта из-за временнОй задержки.

4. Если такого НПС, с нормальным визуалом/моделью или свернутой в клубок, отправить в оффлайн и обратно (или сэйв-лоад) - НПС восстанавливает свой первоначальный визуал и свойства ... Это вероятно можно использовать для неких эффектов временной маскировки/мимикрии/временного бессмертия и др. ...

 

Вот такая хитрая и малопонятная, но возможно интересная функция set_visual_name имеется в ЗП. ;-)

Изменено 7 Июня 2012 пользователем Artos

[Artos 99]

Shredder

1. Я бы не советовал увлекаться добавлениями в нет-пакет своих новых значений, тем более, как ты пишешь "туго у меня с ними".

Работа с нет-пакетами требует аккуратности и ТОЧНОГО понимания что/куда ты пишешь/читаешь, тут каждый(!) байт/бит важен.

2. Тобою используются кастрированные функции чтения/записи нет-пакетов! Сам посмотри, все что в нет-пакетах после параметра visual_name - считывается в общую кучу extra_data и твоя читалка писалка (соответственно и ты) никак не знает ни о каких death_droped и тем более добавленном тобою not_first_spawn. Соответственно, в лучшем случае, ты просто теряешь этот новый параметр, в худшем - искажается нет-пакет.

 

Что мешает тебе в качестве флага о уже свершившемся факте смены физуала использовать или инфопоршень или просто писать переменную в pstor твоему об'екту, если конечно подобное только для онлайновых важно?

Даже просто прочитать из нет-пакета имеющийся визуал у непися и принять решение - стОит его менять иль нет - это тоже вариант.

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

[Artos 99]

karavan, причина в банальной рассинхронизации между моделью серверного об'екта и клиентского. Хотя менеджеры состояний и анимации работают с онлайновыми об'ектами, но немало кодов/условий/проверок идет и от серверного ... Да и просто не исключаю, что информация для анимаций и подобного кешируется где-то в движке и при подобном "онлайновом" переодевании просто не обновляется, хотя ... это наврядли, т.к. тогда от времени не так сильно зависело бы.

Да и какая разница, решение по смене визуала давно есть и вполне приемлемое. А эта функция со своими нюансами может кому сгодиться для специфических моментов ...

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

Изменено 10 Июня 2012 пользователем Artos

[Artos 99]

Shredder

1. Модуль нет пакетов в моем исполнении кроссплатформенен и может использоваться во всех трех играх релизных патчей ТЧ/ЧН/ЗП;

2. В топике по скриптам можно найти ссылку на вполне актуальную мартовсую версию ...

3. Учитывая пару мелких (неособенно востребованных правок) выкладываю последний на 'сейчас' вариант:

m_netpk от 25.05.2012 (~26.9 кБ)

 

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

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

 

А файл se_stalker - это конструктор об'екта класса, и не обязательно только в нем курочить созданные в нем серверные об'екты. В любом месте, если ты работаешь с серверные об'ектом - ты можешь его запороть ... Важно абсолютно точно соблюдать формат нет-пакета (каждый бит!), учитывая и класс об'екта и версию игры/мода!

Изменено 12 Июня 2012 пользователем Artos

[Artos 99]

Shredder, сколько тебе можно говорить - За лут отвечает death_manager.script и его конфиги!

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

Изменено 14 Июня 2012 пользователем Artos

[Artos 99]

vicious_rumors, чтобы "заговорить с любым сталкером" модмейкер должен знать условия и работу схемы meet, которая обязательна для всех сталкеров - и когда создашь все необходимые условия для "любого" - тогда сможешь разговаривать с ними когда тебе вздумается. Т.о. тебе прямой путь к статьям по логике (ссылка в шапке).

[Artos 99]

IQDDD, активная схема у каждого об'екта в игре может быть только одна, а сам сталкер(об'ект), как правило, под управлением сразу нескольких схем (движковых, общих и прочих).

Формулируй вопрос не размыто, а конкретно.

[Artos 99]

Callisto, не могу и не буду описывать всю систему инфопоршней, но кратко:

Инфопоршни сродни глобальным переменным Lua, однако имеют отношение к движку, т.е. именно движек ведет "реестр" этих "переменных" и в отличии от Lua'шных - авданные (активные) инфопоршни автоматически запоминаются в сэйвах и восстанавливаются при загрузке игры. По сути, это почти полный аналог запоминания в pstor'e.

Вместо понятия "активный" в отнонении инфопоршней обычно применяют "выдан" (или нет - пассивен). Кол-вл активных (выданных) инфопоршней ограничено только ресурсами игры, т.е. условно можно считать неограниченным.

В ТЧ (SHoC) имелся жесткий список возможных инфопоршней и кол-во ограничивалось этим списком. В ЧН и ЗП подобный список отсутствует и по-сути при неумелом применении - можно теоретически обрушить стек/игру ...

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

 

Совет: Несмотря на простоту и относительное удобство использования инфопоршней все же не рекомендую злоупотреблять ими.

Инфопоршень - это строка и любые проверки условий сравнивающие строки гораздо медленнее, чеv аналогичные сравнения чисел или логич.значений. Т.о. использование обычных Lua-переменных в игре с запоминанием их в сэйвах (при необходимости) - дает выигрыш как по времени, так и по размеру сэйвов.

[Artos 99]

karonbaron, используй для кодов тэг CODE, дабы и сами коды не коверкались парсером движка форума, и форматирование в строках сохранялось.

 

Да и излишествами не стОит злоупотеблять, тогда и ошибок поменьше будет, ведь достаточно всего лишь:

function increase_hunter_goodwill_to_actor(first_speaker, second_speaker)
 local actor = dialogs.who_is_actor(first_speaker, second_speaker)
 relation_registry.set_community_relation("hunter", actor:id(), 2000)
end

 

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

[Artos 99]

Batment, судя по логу, у тебя ошибка связана с диалогом... (см. CDialogHolder::CDialogHolder() ) т.о. не в схеме walker нужно копаться, а в meet или с стороннем...

У тебя в meet прописано:

use = {=actor_enemy} false, {-zat_b33_stalker_snag_setup =dist_to_actor_le(2) =see_actor} self, {=see_actor} true, false

т.е. непись сам может вызывать окно диалога, а вот имеется ли он (диалог) у него - вопрос, т.к. все остальное у тебя в false...

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

[Artos 99]

ХОВАН, где ты увидел в моем посте про "виновность" самой схемы? Она может провоцировать, т.к. именно она отвечает за диалоги и соответственно их окна.

Неужели не понятно, что лог ругается именно на GUI и именно на CDialogHolder - т.е. на попытку движка обработать объект диалогового окна. И нужно разбираться что за диалог пытается движек обработать.

И как же это CDialogHolder - "не связан с диалогами"??? Иль для тебя интерфейс диалогового окна - это не часть диалога?

Улыбают такие вот комменты в "советах":

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

 

Clayman, вы хоть читаете(?) написанное:

нужно копаться ... в meet или стороннем...

Это означает, что или в схеме заданы параметры, которые приводят к ошибке, но не в самой схеме, а с неким вызываемом диалоге или переход на указанную секцию walker@start_levsha активирует иные схемы, которые и вызывают ошибку.

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

 

P.S. Как вариант, хотя бы временно отключить в этой проблемной секции: meet = no_meet - и далее уже разбираться, в чем же проблема.

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

[Artos 99]

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

 

Пишу (повторяю) в последний раз:

1. Во-первых, судя по твоей "даже с такой схемой" - схема meet не отключена, она же у тебя в корневой секции прописана(!).

Если отключение (чего у тебя НЕ сделано) не исправляет ошибку - искать в сторонних алгоритмах,

2. Если у тебя пути не имеют флагов (сигналов), то проверка в другом месте валидна, если же флаги в наличии - то проверять нужно именно "по месту", т.к. флаги и могут вызывать проблемны.

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

 

(комментировать не нужно, гадания на кофейной гуще закончил).

 

Clayman, если начать поминать кто и сколь раз встречал ту иль иную ошибку - всех разделов форума не хватит.

Вот ты, уже не раз встретил упомянутую ошибку и что(?) нашел причину или тупо обошел методом тыка, поставив какую-нить заплатку иль кострировав коды? Личный опыт - это не сколько раз наступил на одни грабли, а сколько нашел способов НЕ наступать на одни и те же грабли! ИМХО.

Нужно не гадать(!), а искать причину и устранять ее, заодно намотав на ус, как не нужно делать, чтобы не наступать на грабли!

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

 

Clayman, по твоему вопросу о таймерах:

Уже десятки раз приводились и готовые примеры и немало пояснений/статей понаписано. Воспользуйся поиском. Таймеры для ЗП ничем не отличаются от таймеров для ТЧ/ЧН. В конце концов, каждый второй мод содержит "сон" для актора, почему там не посмотреть?!

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

[Artos 99]

karonbaron, идеи уже не раз и обсуждались и реализовывались...

Исходные схемы (ТЧ/ЧН) вертушек (heli_move и пр.) читают параметр enemy (иль combat_enemy) как строку, а не как условие, т.о. допустимы перечисленные тобою же значения, т.е. или вертушка может атаковать актора или НПС с заданным сидом или никого, т.е. 'попугает' малость... В ЧН действительно, есть возможность задать и "all" - тогда вертушка будет обстреливать любого НПС в пределах видимости, а актор будет в приоритетах.

Про обстрел "по позиции", что задается флагами в путях, наверное не стоит отвлекаться...

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

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

[Artos 99]

karonbaron, а ты не пробовал сам поискать?

Например, давным давно существует мод и соответствующая тема AI вертолетов , также в SIMBION'e вертушки неслабо зачищают местность... да и сам можешь на вертушке по группировкам поупражняться из ракетницы, и т.д.

Если самому посмотреть на то, как реализована в ЧН-скрипте работа по значению параметра "all" - не очень сложно подстроить и под свои нужды, т.е. под группировки иль иные критерии...

 

Clayman, не советуй ерунду... лучше бы посмотрел бы скрипты и в частности heli:isVisible( self.enemy ) - и как ты себе представляешь "вертушка видид сквад и обстреливает его" ?

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

[Artos 99]

Callisto, не должно быть загвоздки... все достаточно тривиально, т.к. прицел изначально стационарно "надет" (scope_status = 1).

В твою созданную секцию всего то нужно внести типа: scope_name = wpn_addon_scope_night , и установленный прицел заменится на указанный.

[Artos 99]

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

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

[Artos 99]

FeLLoN, специально для всех тебе подобных и 'нубов' в частности написана шапка топика, в которой кучка ссылок, где можно найти и те, по которым "расписано как это делать в мельчайших деталях..."

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

[Artos 99]

Shredder, в отличии от иных 'инвентарных' предметов, комбезы (outfit) и оружие имеют два параметра, отвечающие за "износ" (исправность). Один в state-пакете и второй - в update-пакете, при чем второй как раз и будет в конечном итоге присвоен заспавненному комбезу.

Т.о. тебе требуется получать полный нет-пакет и задавать оба: data.condition и data.upd.condition.

В принципе, можно брать только update-пакет ( pk = m_netpk,get(obj,2) ) и изменять именно data.upd.condition - этого будет достаточно. Комбез будет спавниться исправным (он в любом случае при скриптовом спавне исправен на 100%) и "изнашиваться"... до указанного тобою значения.

obj = alife():create('stalker_outfit', vector(), 0, 0, db.actor:id()) --/ спавн в инвентарь актору
local pk = m_netpk,get(obj, 2) --/ получаем доступ к update-пакету
if pk:isOk() then --/ доступ получен?
 local data = pk:get() --/ читаем update-параметры
 data.upd.condition = 0.5 --/ изменяем параметр
 pk:set(data) --/ запоминаем
end

 

 

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

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

[Artos 99]

Shredder, к сожалению не все и/или не всегда можно сделать "простенько и со вкусом"...

При спавне любого предмета актору - переводить этот предмет on->off->online и не получится, т.к. владелец предмета (актор) не может быть в оффлайне.

Также, действительно, не посмотрел внимательно коды и...

а) параметр upd.condition имеет hex-значение и должен задаваться в диапазоне 0...255 (0x00...0xFF).

б) при спавне в инвентарь актору измененный нет-пакет не перечитывается.

В итоге, выход не так уж и сложен:

1. Спавним предмет рядом с актором и меняем ему нужные параметры при помощи нет-пакетов

2. Ставим коолбэк, по которому при выходе предмета в онлайн - предмет трансферится актору.

В итоге код может быть таким:

--/ спавн 'рядом' с актором
sobj = alife():create('stalker_outfit', db.actor:position(), db.actor:level_vertex_id(), db.actor:game_vertex_id())
local pk = get_netpk(sobj,2) --/ получаем доступ к update-пакету
if pk:isOk() then --/ доступ получен?
 local data = pk:get() --/ читаем update-параметры
 data.upd.condition = math.floor(255*0.5) --/ изменяем параметр
 pk:set(data) --/ запоминаем
 --/ ставим коллбэк: по выходу в онлайн - трансфер актору
 level.client_spawn_manager():add(sobj.id, 0, function(id,obj) obj:transfer_item(obj, db.actor) end)
end

Не так все и усложнено :-)

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

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