Dennis_Chikin

Читал тему. Много думал. Потом читал "шапку" (1-й пост), и снова тему, и опять много думал. Пришел к выводу, что большинство авторов последних постов - телепаты, и передают мысли друг-другу на расстоянии прямо через мировой эфир. Просьба: снизойти до простых смертных, и писать: какой death_callback из из какого апдейта биндера атора при помощи каких таблиц у Вас удаляет трупы, и в какой версии какой игры. И куда у вас из-за этого исчезают все НПЦ (тоже, в какой версии, и какой игры). А если не из-за этого, то из-за чего ? По тому как лихорадочно просмотрел все скрипты ТЧ1.0006 и не обнаружил ничего из упомянутого в сообщениях на этой странице. Действительно, ерунда какая-то получается. ©k01jan Может бы мне кто-нибудь компанию в чтении шапки темы составит ? mumie, что касается неписей, на которых смотрит актор, то если бы это был ТЧ, я бы посоветовал обратить внимание на xr_meet.script, и еще пачку других, сходных по смыслу.

Еще раз про ковыряния: Если что-то где-то правилось, после чего начались вылеты, пропал Сидорович, еще что-то в этом духе - Вы испортили файл, который ковыряли. Просто испортили. Не надо придумывать этому мистические объяснения. Если сэйв был сделан рядом с Сидоровичем, и Сидорович после ковыряния исчез - Вам повезло, и вы обнаружили результат своего ковыряния сразу. Если сэйв был сделан на другой локации, а придя на Кордон не нашли там Сидоровича - повезло меньше, и не только испорчен файл, точно так же, как в первом случае, но и бездарно потрачено время на хождение между локациями. А если не повезло особенно сильно, то может быть испорчена секция, которая неактивна в данный момент, но будет использоваться после каких-то событий. К чему я это все: вера в мистику и IT между собой несовместимы. Либо вы знаете, что делаете, и делаете это внимательно - и тогда все работает, либо Вы не знаете что делаете, но почему-то уверены, что Вам все должны и обязаны. Ну так в последнем случае - Вы ошибаетесь. Должен - это когда кто-то занял денег, и не отдал. А вещества, как гласит Первый Закон Аналитической Химии, нам вообще ничего не должны.

Как бы Сидор - он даже не монстр, а недомонстр. Соответственно, ни какой state_manager для него вызываться не должен. И ни каких анимаций задаваться тоже ни где не должно. То есть, секция - m_trader (и ничего в ней не менять), визуал - сидора, флаги - сидора. Ничего неписевого вызываться не должно.

Первоначально за основу взят Сидор ? Часом, не как непися пытаешься создать ?

когда self.npc_script_version передается в dialog_manager - предполагается, что там по этому поводу что-то сделают. И, да, брать его из alife():object(self.object:id()).script_version - очень странная идея.

Хемуль36рус, при чем здесь мотиватор ? Диалоги - dialog_manager.script Квесты - task_manager.script В них что-то трогал ? И проверь сначала просто со стандартным диалогом.

Разница в собственно диалогах есть ? Те, которые "не вылетают" - не вылетают ни с НИ, ни с сэйвов после НИ, при любом наборе ? Значит намудрил с адаптацией. У 1.0004 все id диалогов - цифра. У 1.0006 - строки.

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

Ответ на оффтопик в "разговорах": Если нам надо найти "Костюм Тирекса", то запускаем поиск по конфигам, и ищем, внезапно, "Костюм Тирекса". Он, внезапно, находится в string_table_outfit.xml: <string id="strelok_outfit_name"> <text>Костюм Тирекса</text> </string> Зеленый, оранжевый и прочие серобуромалиновые кружки, которые иногда высвечиваются при загрузке и тут же исчезают - ну, это такие кружки, которые иногда высвечиваются при загрузке. Надо копать, где конкретно вся эта иллюминация на голод/холод/радиацию проверяется, но на практике ни кому не интересно.

Гм, у меня внезапно дежавю. То, что скриптеров мало, модельщиков еще меньше, а мапперы - сами по себе, и играют не в сталкера, а в sdk - оно понятно. Ну а вот взять, те же конфиги, их почистить наконец (за 8-то лет), и написать хорошие годные инклуды - это-то кто мешает ? А если еще и графике-звуку большой репак устроить, и тоже выработать наборы под вкус и цвет... Да, диалоги - суть те же конфиги, только противнее. Но знаний в принципе тоже требуют не великих: просто сидеть и сравнивать то, что лежит в gameplay с тем, что в text. И вот теперь риторический вопрос задам: почему либо вообще ни кто не хочет, либо если кто берется, то начинает непременно ультиматумы выдвигать ?

Продолжаем разговор про task_manager... Вот как-то так: ну и целиком под сборку "солянки обезжиренной": https://dl.dropboxusercontent.com/u/27871782/task_manager.7z - универсальный 1.0004/1.0006, с правленной "адаптацией" и правленным "исправлением ошибок" и правленной проверкой состояния гулагов. Можно вообще-то еще и время поправить, чтобы пакет не жрало... Ну и вариант с измененным форматом времени - тоже под обезжиренную. Итого - ~300 байтиков в нетпакете. https://dl.dropboxusercontent.com/u/27871782/task_manager_time.7z

До 2014-го она дожила по тому, что все предпочитают что-то делать параллельно и в глубоком подполье. И на совместимость всяких правок/адаптаций/аддонов между собой всем тоже плевать. Это во-первых. Во-вторых, смарты сохранять НЕ нужно. Так же как и еще пачку других целей. Это все великолепно берется из конфига. Так же, кстати, как и "активные таски", коль скоро есть статусы. В-третьих - сколько ж можно тащить древний мусор ? Ага, это я про if i~=255 then... Да, кстати, о птичках: кто нибудь знает, что на самом деле делает :GetPhraseScript(), и что именно возвращает ? Ну, local sc = phr:GetPhraseScript() local phr = d:AddPhrase( что-попало ) local sc = phr:GetPhraseScript() ... повторить 100500 раз - это, понятно, явный мусор же. А вообще он в каких случаях действительно нужен ? Да, что касается xr_gulag.getGulagState() - "это не бага, это фича !" Очень много где испоьзуются откровенно странные возвращаемые значения из "общих функций". В частности, с теми же гулагами - многие проверки работают только если он в онлайне. Отсюда, например, вечно бегающий шустрый и перманентная бойня на АТП (сталкеры приходят, и превращются в мясо, приходят и превращаются)... Приходится дублировать руками на месте уже правильно, либо вставлять в тот же xr_gulag дублирующую (привет, совместимость).

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

А на 4-й день Зоркий Глаз заметил, что у тюрьмы забыли построить 4-ю стену... В смысле, что, оказывается, дохлые монстры продолжают пытаться переключать схемы, и даже успешно это делают. Например, постоянно включают mob_home (следовательно, до нее было что-то еще ?). По-моему, в этом есть что-то не совсем нормальное... У кого какие мысли по этому поводу ?

Да. При этом бы еще знать бы, какие они вообще бывают. Но та монстрофункция из utils мне "почему-то" ну вот совсем не нравится. p.s. string_gfind == string.gfind, разумеется. Еще б понять, от чего та "защита" из оригинала способна защитить... Все, что я способен измыслить - либо вылетит/повиснет раньше, либо пройдет эту "защиту" со свистом. Про смысл набора - аналогичный интерес. Как обычно: мож чего-то хотели, но не доделали, мож и вправду смысл имеет, но в оригинале не использовано. А может - как умели - так и написали. Не, на таком уровне править точно не рискну. Мне достаточно, что это теперь типа инлайнить можно, а не через 5 скриптов вызывать.

Проверте меня, плиз (да, опять регэкспы) ТЧ, utils.parse_waypoint_data() - будет ли вполне эквивалентом: function parse_waypoint_data( path, flags, pname ) local t = { ["flags"] = flags } for k, v in string_gfind( pname, "|([%w_\\%-%,%*]+)=*([%w_\\%-%,%*]*)" ) do if v ~= "" then t[k] = v; else t[k] = "true" end end return t end

"D:\prog_repository\sources\trunk\xrGame\xrServer_sls_clear.cpp" - ЗП ? Он же в ТЧ - внезапно, любимый всеми e-parent&e-entity и его разновидности. Кстати, не обязательно, что именно ящик.

Поскольку всех послали сюда, здесь и откомментирую кой-чего: "Так же, я заметил что внутриигровые тормоза не пропали. Тот же недетский лаг при обыске первого трупа, при подходе к деревне новичков и т.д. Еще я заметил, что упакованная геймдата гораздо лучше дружит с SSD чем распакованная." Обыск первого трупа - чтение конфига в treasure_manager.script. При последующих загрузках этот лаг добавлятся в "синхронизации". Исправлено. Подход к деревне новичков - текстуры волковской xm8 + сканирование каталогов из sound_theme.script. Последний модифицирован в настоящее время так, что количество каталогов и их содержимого можно сократить. Звуковой конфиг ждет своего добровольца. По стволу - существует куча фиксов, от разных авторов, не выкладывающаяся, дабы "не украли злые конкуренты". ~10 секунд "синхронизации" - чтение конфигов из death_manager и ph_box. Исправлено. 30-40 сек. "синхронизации" - чтение конфигов торговли. См. адаптации к наиболее распространенным аддонам в теме "творчества". Демосборку со всеми исправлениями см. в теме разработки "2010". Периодически обновляется. Общщая мораль по всем вопросам о процессорах, памяти, ССД и видекарт сводится к следующему: основная проблема - медленная файловая система (скорость диска + скорость процессора + алгоритм работы с каталогами винды + враппер эксрея), осложненная неоптимальными алгоритмами в скриптах, в том числе "кэшированием" в скриптах, по факту увеличившим количество наиболее медленных операций. То есть, скорость загрузки увеличивается за счет увеличения скорости каждого из компонентов, но не очень значительно. Упаковка гэймдаты уменьшает количество дерганий на учаске диск-система-движок, возможно, держит в системном кэше собствнно каталоги. За счет этого уменьшаются прежде всего "звуковые" лаги (gamedata\sounds). Проблема кривых текстур остается проблемой кривых текстур. Также, возможно, некоторую долю тормозов вносят "развесистые" пути и имена файлов, но здесь еще надо смотреть, как сама винда и сам сталкеровский движок обрабатывают записи в каталогах. То есть, оптимальнее ли 1 каталог с 20000 файлов, или 100 каталогов по 200 файлов. По опыту еще со времен доса могу сказать, что у мелкософта обработка каталогов резко замедляется с какого-то количества (с долей секунд до десятков секунд на достаточно старых машинах). Что там с различием алгоритмов в xp vs. w7 - сказать не могу. P.S. Ну и при чем здесь "школа моддинга" ?

"Дело в том, что скрипты не имеют никакого отношения к данной проблеме." Дело в том, что к данной проблеме (равно как и к пресловутому "переполнению стека") имеет отношение вообще все, что не было диагностировано иным образом. Кстати, рекомендую обратить внимание на разные значения в строке "line" и разные количества запрошенной памяти. То есть, всем, кто сталкивается с таким сообщением, нужно обращать внимание на такие моменты, и пополнять список, если причина была установлена. P.S. На версии движка тоже обращаем внимание: строки могут и отличаться. Еще хочу сказать по поводу сообщения выше, там где указание строки в скрипте: эта самая строка в скрипте тем более может меняться, поскольку в модах постоянно вносятся разные изменения в самые разные места. Так что следует показывать содержание строки, не то, что ни кому( кроме автора сообщения) неизвестно где какая-то переменная с ни о чем не говорящим названием оказалась равна nil.

Мертвый Толик, если выполнен квест с Шустрым (точне, убит или по другой причине удален из смарта типа "квестовый бандит" - это из оригинала. Просто затычка отсутствующей ветви диалогов. Не имеет отношения больше ни к чему. Дверь Сидоровича - просто зависает. Точно так же, как неписи, монстры, и все остальное. Вместе с другими объектами. Из-за ряда ошибок, тоже, начиная с оригинала (и на самом деле кривизна в движке - теряются коллбэки). То есть, видим неработающую дверь - лучше переиграть с момента, пока еще работала. По тому что что там повисло вместе с ней - ни кто не знает, пока не пойдут "исчезнувние" персонажи, "переполнение стэка", "нехватка памяти" и иже с ними. ========================================================== "А всё началось с ахтунга на Кордоне" (offline_alife chp17) - Классический результат ошибки в вышеупомянутом скрипте (известной также как "неписи пропили все оружие"): произошла порча таблиц соответствия индексов предметов и их владельцев, после чего скрипт начал уничтожать все подряд, и повис. Если файлы самой солянки не испорчены по какой-то еще причине - откатиться на сэйв как минимум до перехода на эту локацию, поскольку на текущей таблицы были испорчены уже с гарантией. Также стоит, действительно, запустить архиватор в режиме сравнения упакованных и распакованных файлов соли. Если будут найдены ошибки - проблема с собственно компьютером. Кроме того, вообще-то не должен, но при сохранени/загрузке уже битых сэйвов или смерти актора (тоже при уже имеющихся проблемах) могут быть испорчены движковые конфиги, или миниатюры к сэйвам, но это надо ну уж совсем невероятное стечение обстоятельств. P.S. Автору, который посоветовал мне перейти на 6-й патч - спасибо. Давно так не смеялся. А если серьезно, то переходите уже на патч Макрона, заодно и "болотные" вылеты по-реже станут. P.P.S. Но, это ни коим образом не изменит ситуацию с "пропиванием оружия", переполнением гулагов, неcуществующими ветками логики, попытками удаления/перемещения несуществущих или ушедших в офлайн предетов, дублями аномалий, бесхозными собакофантомами, кривыми путями костюмов, конфликтами между Экстриом'вскими, Бак'овскими и Idler'вским аддонами и прочим.

malandrinus, e_parent... гарантированно воспроизводится, если при открытом инвентаре принудительно загнать в офлайн тайник с лежащими в нем шмотками. С неписем тоже должно поучиться. Вообще, по логике - любой assert с e_ при попытке что-либо сделать с этим самым e_ при его отсутствии.

Если под w7 какая-то "толстая" софтина не использовалась достаточно долго, то запускается тоже неприлично долго. Ага, на сталкере заметно в полной мере. Запускаем, и - любуемся на экране на окошечко с копирайтом. Затем - любуемся на черный экран... На диске при этом происходит какой-то бешеный процесс... Под XP на том же железе такого нет. Да и на w7 не сразу началось. Если сталкера запускать часто - даже и выключая компьютер между запусками - все вполне шустро. Впечатление, что система что-то странное делает со всем каталогом. Как бы чуть ли не полностью его куда-то копирует... По инету несколько раз встречались упоминания "фирменного" w7 кэширования, где надо все результаты этой деятельности потереть, и затем - запретить. Но без подробностей. Так что и где можно оторвать ?

Про ранения... Системы нет, поскольку код проверки сам по себе несколько... э-эээ, рэндомный. До того, как это дело поправят (читай, выхода новых сборок) - все сводится к повезет/неповезет. Чтобы получить больше раненых - уберите в xr_wounded.Cwound_manager:hit_callback() if self.npc:critically_wounded() == true then return end и увеличьте def.hp* с 10 до сколько надо. Впрочем, и это сработает не для всех. Большая просьба к Куратору темы и Модераторам. Данный пост НЕ УДАЛЯТЬ !!! BFG

интересный вопрос возник: в Cwound_manager:update() и в action_wounded:execute() self.object - один и тот же ? self.object:name() - возвращает имя непися. self.object:object( "medkit" ) в первом возвращает аптечку, во втором - nil. В инвентаре у непися при торговле в это же самое время аптечка визуально присутствует. Upd: все оказалось смешнее: ~info~ [xr_wounded] (esc_vagon_wounded):eat_medkit ~info~ [xr_wounded] (esc_vagon_wounded):eat_medkit, found medkit sv reject. id_parent [5738][stalker:esc_vagon_wounded] id_entity [32274][medkit:medkit32274] [11946] sv destroy object [32274][medkit:medkit32274] [11946] ~info~ [xr_wounded] (esc_vagon_wounded):eat_medkit, done ~info~ [xr_wounded] (esc_vagon_wounded):update, need use medkit (hp: 31.048185348511) ~info~ [xr_wounded] (esc_vagon_wounded):update, medkit: medkit (32274) А вот на следующем апдейте ее уже нет.

Romann, поскольку все молчат, так я подскажу: "Скрипты с оригинала" иногда обращаются к другим скриптам. Что, разумеется, плохо, но так уж есть. А те, в свою очередь, используют конфиги. Лог в данном случае намекает, что пара других скриптов не совладали с изменениями в конфигах, и, скорее всего, повисли.