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

[dsh 3 824]

Вроде распределение по гулагам идет на апдейте - custom_data должна спокойно записываться.

 

Отладка показывает, что присваивание смарт террейна происходит вот тут

function se_monster:on_before_register()
	if modified_params then -- при наличии таблицы с данными для замены
		-- читаем из родного пакета данные
		local params = m_net_utils.get_monster_data( self )
		replace_params( modified_params, params )
		m_net_utils.set_monster_data( params, self )
		modified_params = nil -- обнуляем табличку с исходными данными
	end
	self:fill_exclusives()
end

С modified_params - это уже мое.

 

Кроме того custom_data можно задать прямо в конфиге секции.

 

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

Изменено 2 Августа 2015 пользователем dsh

[dsh 3 824]

Это не соляночный код.

 

Упс... Не ожидал, что в ОП-2 это изменено. Вот из ОП-2:

function se_monster:on_before_register()
	self:fill_exclusives()
end

В Солянке по другому?

 

 

У свежезаспавненного монстра очевидно нет ни каких эксклюзивов. Соотвественно, они ни где не запоминаются.

 

Отладка показывает, что свежеспауненого мутанта немедленно, вон в том коде, затягивает в любой свободный гулаг. Если выразиться точнее, не в том коде конкретно, а в промежутке между create() и вызовом amk.on_REspawn(), который вызывает amk_mod.respawned(), который и ставит мутанту custom_data.

Изменено 2 Августа 2015 пользователем dsh

[dsh 3 824]

@abramcumner, а при чем тут чистый ТЧ, если я в самом первом сообщении, на эту тему, написал:

 

Кто использует респаунеры из Солянки, которые при спауне мутантов делают вот так:

 

Ах да, это же русский форум.

[dsh 3 824]

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

[dsh 3 824]

 

 

Выхожу в онлайн на Радаре, рядом в онлайн выходит монолитовец и тут-же умирает.

 

Люди, кто в потрохах мамонта разбирается? Вот это вот из ОП-2, но скорее всего из Солянки:

	if type == "rad_antena" then
		for i = 1, 5 do
			t = { section = "logic@rad_antenna_patrol_wagon"..i,
				idle = 0,
				prior = 5, state = {0},
				squad = squad, group = groups[1],
				in_rest = "rad_wagon_restrictor", out_rest = ""
			}
			table.insert(sj, t)
		end

Похоже, из-за этого убивается монолитовец. Если я отключаю ему установку логики, он жив живехенек. Поискал строку "@rad_antenna_patrol" во всем моде. Нету. Т.е. секция назначается, а самой логики-то нету. Если я правильно все понимаю. Может кто-нибудь, что-нибудь помнит?

[dsh 3 824]

@naxac, а зачем так сделано, может ты знаешь? Выжигатель отключается один раз, а этот смарт вечный и безусловный. И приходят туда новые монолитовцы и автоматически убиваются при выходе в онлайн и лежат трупики с халявным лутом. И так до скончания веков. Каков замысел был? Должно было убивание происходить только один раз? Или смарт должен был иметь соотв. cond и прекратить свое существование?

[dsh 3 824]

Расскажите пожалуйста, кто знает, зачем у некоторых персонажей в all.spawn указываются флаги, запрещающие переход в оффлайн? В чем смысл такого?

 

 

в конфигах аномалий есть параметр "BirthProbability", вроде отвечающий за вероятность порождения аномалией артефакта (платформа - ТЧ)

 

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

[dsh 3 824]

 

 

А какая строчка/строчки указывают на эти флаги?

 

А вот, например, Шерстюк из Солянок:

object_flags = 0xffffff7b

Здесь сброшен бит, разрешающий переход в оффлайн.

 

 

 

spawn_blowout_artefacts artefact_spawn_probability   Как с ними дело обстоит, поскольку сам пока не проверял. Так понимаю, что это возможность спавна арта при выбросе/после выброса и ее вероятность. Так?

 

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

[dsh 3 824]

 

 

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

 

Лучше самостоятельно исходники посмотреть. В частности xr_3da/xrGame/CustomZone.cpp. Дальнейшее, всего лишь мои теоретические измышления, основанные на разглядывании этого файла. Параметр "spawn_blowout_artefacts" указывает, будет ли вообще производится спаун артефактов при срабатывании аномалии. Параметр "artefact_spawn_probability" задает  вероятность, что при срабатывании будет какой-нибудь спаун вообще. Т.е. спаун будет обрабатываться, если rnd < значения этого параметра. В качестве значения имеется ввиду float от 0 до 1. И параметр "artefacts" задает список секций артфактов и их относительных вероятностей, как в описании спаунеров, через запятую, что-то вроде "art1,30,art2,70". Ну и далее, собственно, при попадании в аномалию чего-нибудь живого и имеющего радиус >= 0.6 и пробывшего в аномалии дольше "disable_time" или имеющего радиус < 0.6 и пробывшего в аномалии дольше "disable_time_small", срабатывает аномалия и вроде как создается артефакт из списка, если выполнено условие "artefact_spawn_probability". В общем, как-то так.

[dsh 3 824]

Вот этот же уборщик, взятый из ОП-2, но в немного причесанном виде: https://github.com/dsh2dsh/op2ogse/blob/master/gamedata/scripts/sak_off_corpses.script

 

Если кому нужно. Убрал нафиг, мягко говоря, лишнее и привел к более читаемому виду. По хорошему, нафиг, мягко говоря, его переписать надо, но работает...

[dsh 3 824]

Может у кого дельная мысль будет. Провожу эксперимент. На локациях Бар и Армейские склады держу принудительно в онлайне почти всех неписей. Всех их по пути посещаю, обратите на это внимание. Через некоторое кол-во переходов получаю вылет по нехватке памяти. Теперь перестаю держать их в онлайне, но по прежнему, всех и посещаю по пути, т.е. все они в онлайн выходят, правда и уходят из него. Вылета по нехватки памяти нет. Вопрос, где же в первом случае утекает память?

[dsh 3 824]

 

 

Вот тебе и ответ

 

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

 

 

Или предлагаешь эксперимент провести за тебя?

 

Цитат из моего вопроса

 

Может у кого дельная мысль будет.

а потрындеть я и сам могу.

 

 

А теперь прикинь размер АС...

 

А что прикидывать, маленькая эта локация. В онлайне там примерно 42 непися. Не сказать, что слишком много. 

[dsh 3 824]

@Dennis_Chikin, цифр нехватающей памяти нет вообще. Чаще всего есть только

 

[12/27/15 23:41:45] [error]Expression    : error handler is invoked!

[12/27/15 23:41:45] [error]Function      : handler_base

[12/27/15 23:41:45] [error]File          : E:\stalker\sources\trunk\xrCore\xrDebugNew.cpp

[12/27/15 23:41:45] [error]Line          : 753

[12/27/15 23:41:45] [error]Description   : std: out of memory

 

Это процесс отожрался где-то до 3.5 гигов. Тоже самое будет и без принудительного держания в онлайне неписей, но гораздо позже, может часов через 5 игры. А тут 2.5 - 3 часа и вылет.

[dsh 3 824]

 

 

По тому как в "скрипточасти" так красиво может течь, только если что-то висит.

 

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

 

 

 

Баг с malloc() - что-то слабо верится, ибо починено везде, где можно, лет 15 назад уже как

 

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

 

 

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

 

Память течет жутким образом. Перехожу с АС в Бар и обратно несколько раз и каждый раз смотрю в диспетчере задач размер процесса. Каждый переход прибавляет сотню мегабайт. Притом это зависит от кол-ва неписей в онлайне на момент перехода.

[dsh 3 824]

 

 

Память течет жутким образом. Перехожу с АС в Бар и обратно несколько раз и каждый раз смотрю в диспетчере задач размер процесса. Каждый переход прибавляет сотню мегабайт.

 

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

[dsh 3 824]

По раненым, которые забывают собственное оружие - увижу - буду смотреть.

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

[dsh 3 824]

@Struck, в смысле? Ты же сам и написал:

 

можешь залочить дроп ствола у этой анимки

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

[dsh 3 824]

 

 

у его ствола

 

А его ствол - это что?

[dsh 3 824]

 

 

Очевидно ствол до дропа, что же еще? Оперируешь-то одним итемом.

 

Ага, т.е. где-то еще надо запоминать, что объект с таким-то id - это его оружие? Т.е. ко всему прочему, что ты предлагаешь дописать (кому?), ты предлагаешь еще дописать кучу кода для хранения факта, какой именно объект в игре является оружием данного непися. А плюс к этому, еще кучу кода для обработки ситуаций, что вот это оружие было легально продано/куплено или иными способами легально поменяло своего владельца. И зачем? Что бы в результате получить, что бы раненый непись не остался без своего оружия? И вот это вот все лучше, чем закомментировать "drop" в соотв. скрипте: https://github.com/dsh2dsh/op2ogse/commit/e81640102623455061b84cc7e263f550ee24c895

Ну не знаю. Сдается мне, месье знает толк в извращениях.

[dsh 3 824]

 

 

не понимаю где тут куча кода

 

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

 

 

 

Предлагаю я дописать вопрошающему

 

А ты так уверен, что вопрошающий осилит? Ох уж эти советчики...