Shadowman

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

Черный Доктор, и чем, коллега, чужие скрины вам помогут? Может, логичнее свой скрин скинуть? Скорей всего, сильно занижено качество текстур в игровых настройках. Или, как вариант, неверно установлена адаптация под широкоформатник. Pirat, сейв перед вылетом "Invalid vertex for object " - в студию. ЗЫ: к куратору (модератору) темы - просьба обновить ссылочку: в шапке не последний патч (есть микропатч правленный 17.08.10.7z) Спасибо, не увидел. Шапку изменил Ikar. ------ Pirat, спасибо.

Много народу спрашивало, как на Семерке 64-бит нормально настроить ТЧ. Вот (версия дров, ОС и профиль): В скриншот не уместилась одна настройка: "VericalSync: Off" Может, еще надо кому...

Plastun, причем тут сохранение? В геймдате у вас нет инфопоршня kluk_vstr_after_prizrak_start, вот и вылетает. Если сделали все правильно по совету Архары - такого вылета точно быть не должно. А если лог уже с другим фаталом - то покажите, что в нем.

BadSven, в 1.07 есть единственное изменение, которое было бы интересно для сингла: Но, к сожалению, это только для мультиплеера. Что в конфигах - я пока не сравнивал... TREWKO, можно. Но некрякнутый ехе после этой операции перестанет запускаться, а у крякнутого - это не единственная проблема, к сожалению ЗЫ: Давно бы уже пора GSC выложить хотя бы ехе без старика, я уже не говорю про исходники

Vetrogon, маленькое уточнение: не более 2Гб. Такова особенность движка ТЧ. Даже ЗП не использует больше 2Гб. Нильс, Сообщение выдается независимо от того, что реально отобрано: нет там проверки содержимого инвентаря. Просто все, что предусмотрено к изъятию попадает в это сообщение. Если что-то жалко отдавать - выкладываем перед входом в пещеру Шахтера (можно утаить от Шахтера части монстров, аптечки, патроны к минигану, батарейки; броник, сам миниган и арты к сдаче обязательны - диалога не будет, если их нет в инвентаре). ------------------- sta, причём тут общее использование памяти и ХР? Речь конкретно про Сталкер, т.е. про XR_3DA.exe. В любой операционке исполняемый файл ТЧ не съест более 2Гб, это факт. Хоть ХР, хоть Se7eN возьми - одинаково. Было бы нативно в ТЧ включено использование памяти больше 2Гб - может, тогда и вылетов по памяти "Out of Memory" и не было бы на системах с оперой более 2-3ГБ и реально "видящих" это кол-во памяти. Но, имхо, проблема не в этом, а в ошибках, из-за которых ТЧ требуется памяти больше, чем разрабы предусмотрели, даже учитывая моды.

Monnoroch, Я сначала смотрел, что за таблица и, естественно, делал это только на тех таблицах, у которых автоматический числовой индекс. Фактически, сделано это пока только в одном-двух скриптах, только вот запамятовал, в каких именно malandrinus, прямо в точку Но с другой стороны... под лежачий камень вода-то не течёт. Просто так ведь не трогали бы ничего. sapsan, если есть серьёзные сомнения по поводу определенного кода - можно и откатить часть правок, вызывающих сомнение. И, наверное, не стоит делать впоследствии такого количества правок одновременно, потому как точно не выплывем потом из этого всего. Предлагаю на данный момент откатить все присвоения t[#t+1] = 1 и удаления путём "обниления" из "чужих" скриптов и оставить их только в "своих", которые знаем от корки до корки. И также оставить кеширование конфигов. sapsan sapsan, Наверное, так... Жаль, не один час на это потрачен. offline_alife один чего стоит - там этого добра - вагон dimos, "аборт" в Соли вообще ничего кроме записи в консоль не делает А на предмет "there is no specified level in the game graph" Сапсан точно что-то делал и выкладывал (что-то вроде проверки валидности level'a)

sapsan, стоит все же доделать начатое, как думаешь? Вместо присваивания nil вполне можно использовать table.remove. Ведь результат проверки наличия в таблице что переменной, которой присвоен nil, что вообще не существующей там переменной одинаков. А то, что проверки на ~= nil нужны - так это и так давно известно (и не только в случае с таблицами). table.getn не составит труда вообще глобально заменить на # Учитывая вышесказанное про циклы по таблицам, меняющие число записей самих таблиц - придётся проанализировать, что именно делает цикл. Возможно, где-то я погорячился, заменив for k,v in pairs(table) do на for i=1, #table do. Делал это не просто так: скорость работы второго метода в разы больше первого. Хорошо, что не так много нужно пересмотреть Dennis_Chikin, в любом биндере net_spawn() одинаково работает: при загрузках лок и сейвов Dennis_Chikin, "последняя рука" - моя, что там не так? Если ты о том, что при обработке зависов пропускается ГГ, то иначе никак, мы ведь просто удаляем зависших. ГГ - не удалишь. Ошибка же 1490 - лишь результат неправильной записи в пстор актора (точнее, записи чего-то левого). При чтении это уже не исправишь. При записи же стоят заглушки, какие можно. Разве что при загрузке при попадании в условие потенциального зависа вместо ctr = 0 поставить return. Но там и так дальше идет цикл, который сработает только если ctr > 0 ----- Проверка на classname == nil ничего не даст - тут вылет даже нужен, т.к. все одно это означает, что в сейве уже побитый пстор. Проверяй, не проверяй - с этим уже ничего не сделаешь. В нет_пда мусора не будет - там не пишутся ничего такого (разве что гпс-маячки). Если есть желание - попробуй проверку сделать По-хорошему, нужно искать где и когда делается неправильная запись пстора.

меченый(стрелок), ни в АМК-меню, ни в трансмутаторе настроек в виде элемента управления "ползунок" нет. А очень интересно было бы попробовать реализовать это без хмл-конфига. Кстати, реализация менюшек без хмл-а мне очень понравилась. Рефрешу - респект TREWKO, настройки видео -> расширенные. Вот там есть такой элемент управления. Поковыряй ui_mm_opt_video_adv.script, ui_mm_opt.xml.

Shadows, если я правильно тебя понял, то нужно сделать по аналогии с Витьком:

sapsan, так у него же прописанного там в инклудах w_scorpion.ltx нет... не поможет. Только если ему внести вручную в СВОЙ gamedata/config/weapons/weapons.ltx то, что там изменено в патче во взрывчатке. angor76, насколько мне известно - нельзя. Я выкладывал файлом то, что предложил Архара ("обход", без НГ). Сам не проверял. angor76, конечно есть - с пересборкой аллспавн и НГ.

Andre_013, может, правильнее будет сказать "из-за переключения задач" или, еще точнее, "из-за сворачивания игры и переключения задач"? А то, что приведено в качестве лога - есть в логе всегда Andre_013, на W7 64-bit очень изредка сталкиваюсь только с ошибками по xrGame.dll (их где-то 3-4 вида), и параллельно при этом, открыто что-то или не открыто (как правило, в фоне запущен браузер, тотал, редактор скриптов, и еще пара прог). Вылет - может быть раз за 3-4 часа игры, а может и не быть. Безлоговых вылетов на "семерке" вообще не наблюдал. Оригинальные ехе и длл.

Zombilend, вот это "убираю их в bind_stalker.script" - как делали? Если сделана синтаксическая ошибка в скрипте, то ясное дело зависнет актор именно с логом "xr_logic.script:1490". приведенный код засуньте для начала в ф-цию function actor_binder:net_spawn(data) т.е. можно прямо после этой строки. Zombilend, ошибку сделал. Вот так: function actor_binder:net_spawn(data) local se_obj = alife():object("sarc_stalk_zombied_2") if se_obj then alife():release(se_obj, true) end т.е. ошибка синтаксиса и привела к вылету 1490. Если неправильное имя секции (а правильное я привести не могу, т.к. ваш пост с вылетом уже потёрт, видимо) - по крайней мере, будет вылет с логом, из которого можно будет вытянуть правильное имя того, кого нужно удалять, а не завис актора. ХЕМУЛЬ36RUS, что значит "тоже"? Именно их, родимых ЗЫ: забыл упомянуть, что хрГейм.длл тоже придется вернуть "родной" и попрощаться с "Палачом".

Dennis_Chikin, этот спавн в meceniy_art нужно вообще переделать, потому что там несколько скользких моментов. Во-первых, там рандомное вычисление вертекстов зачем-то, да еще и без последующих проверок на валидность (в ogsm_surge - аналогично, кстати). Нужен просто набор выверенных координат и рандомный выбор между ними перед спавном. Сейчас - там для нескольких лок по одному левел/гейм вертексу. В-вторых, если чего завесилось в биндере, никаких ошибок не выдаётся: просто молча вешается и всё (это особенность движка, нельзя там ошибок допускать). ЗЫ: в ogsm_surge принципиально ничего не отличается - те же кривые моменты. И главное - проверки существования вертексов, полученных путём рандомайзеера - нет. dimos, да в том-то и дело что этой строкой выводится лишь отладка в лог - прочти, что я написал в предыдущем посте. ---- WhatAbout, не думаю. Возможен только вылет в случае, если в строку попытаемся запихать переменную, которая нил 7.9, есть такой момент: при сохранении может, какая-то из функций, запускаемых при этом и приводит в чувство игру. Может, даже простое высвобождение (или заполнение) памяти даёт такое эффект - кто ж его знает, как там внутри движка всё это варится

sapsan, ну значит надо пройти Соль раньше Точно как в анекдоте про оптимиста и пессимиста получается Я так понимаю, вот это нужно переписать в 64-разрядный формат? function WeatherManager:load(F) self.update_level = F:r_stringZ(); self.update_time = F:r_u32(); end function WeatherManager:save(F) F:w_stringZ (self.update_level); F:w_u32 (self.update_time); end sapsan, Спасибо! Фактически, вначале нужно сделать два набора скриптов в соответствии с п. 1, 2, а потом переконвертить всё и можно спокойно играть дальше. Ну почему же оффтоп? Как раз явное руководство к действию

The ReapeR, судя по тому, что никаких патчей нет - погода безглючная? Тогда попробуем

sapsan, а как сохранить 64-разрядный результат ? Ясно. А переконвертить 32-битные таймеры в 64-битные разве нельзя? Применительно к погоде, эти две ф-ции function WeatherManager:load(F) self.update_level = F:r_stringZ(); self.update_time = F:r_u32(); end function WeatherManager:save(F) F:w_stringZ (self.update_level); F:w_u32 (self.update_time); end переписываем в такой вид: function WeatherManager:load(F) self.update_level = F:r_stringZ(); self.update_time = F:r_u64(); end function WeatherManager:save(F) F:w_stringZ (self.update_level); F:w_u64 (self.update_time); end Или для конвертации сейва, вначале запись, а потом и чтение, как ты написал здесь ? ЗЫ: ";" в конце строк - это ведь в люа необязательно вроде? ========== перенес из "багов и вылетов" =========== [spoiler=продолжение по поводу этого способа решения зависа:] WhatAbout, хочешь сказать, что вывод отладочной строки в лог предотвращает вылет? Прямо скажем, необычный способ... Если помогает - то очень даже прикольно выходит. Фактически, ведь мы просто делаем крохотную задержку этим выводом в лог перед назначением логики респавнеру, и только. WhatAbout,

Чебуратор, у вас уже был переход, который создается при взятии документа. Просто не берите его kapella-777, по-моему где-то здесь ужи писали про то, что при фотканьи не должно быть оружия в автоматном слоте. Чебуратор, похоже на то, что у вас скрипты не соответствуют аллспавну. Из-за этого и непонятки с переходами. Создаются они по сидам, а сиды с каждой перекомпиляцией аллспавн "ползут". Видимо, либо не начали НГ, когда это требовалось патчем, либо накатили не те скрипты, либо что-то еще подобное.

d_gennadiy, я давал уже здесь правку таблицы nepis_id из sak.script. Забить в поиск в теме nepis_id ЗЫ: Начиная с 4-го непися в этой таблице все будет работать неправильно. Сяк, Шустрый и Лис - оживятся, с остальными будет вылет по "Story registryt". R.A.V.I.N., ошибка в скрипте, причем тут "тушка"?

malandrinus, спасибо, понятно. Про 1.0006 - вообще откровение. Теперь понятно, почему с переходом на апрельскую Соль народ отрапортовал про снижение производительности именно на 1.6 в сравнении с 1.4. magnit, прям коллекция загадок Зоны какая-то. Я подозреваю, что комп у тебя - не шибко мощный (процессор какой)? И еще: скорей всего, дело в рестрикторах, при попадании в которые, видимо, учащается апдейт (с нычками и их вычищением, правда, нестыковочка слегка... хотя - может, нычки свои тоже в зоне рестриктора какого разместил). Чем слабее проц - тем меньше ему нужно, чтобы "завесился" биндер. Вот как-то так, имхо. А были "ложные срабатывания" сторожа во время сна и в момент, когда висит окно диалога перехода на локацию ? У меня - стабильно такое, и только в этих случаях. Патч 1.0006. Нычка тоже есть нехилая, с маячком, содержимое в экран не вмещается - и ничего (гпс_хабар, правда, слегка подрихтованный как раз на предмет быстродействия) Если твой игровой набор близок к оригиналу 19.04 - скинь сейвик вблизи гарантированного подвиса - просто интересно. Я думаю, что от компа все же сильно зависит (а точнее даже, мощности процессора). magnit, Ок, спасибо, посмотрим. ЗЫ: ну если Солянка "кладёт" уже и 3Ггц двухъядерник - тогда совсем плохо дело

Ray, видимо, дело не в последовательности, а в скорости кликанья при выкладывании (не успел отработать калбэк на дроп - и на тебе подвис биндера). Хотя, возможно, что именно обработку какого-то конкретного сработавшего дропа нужно отрихтовать. Тогда очень поможет как раз то, что предложил тов. malandrinus. Короче: то, что дроп - больное место, и так известно. Итак разгружаем его потихоньку (эмбрионы, телепорты, взрывчатка оттуда уже убраны)... Думаю, можно, как и раньше, заполучить эту бяку, просто вывалив на землю тысячи две патронов. А дальше - это уже как машинка справится malandrinus, логично. Как думаешь, постоянно такая штука, навешенная в апдейте, не сильно напряжна будет для движка? ЗЫ: Честно говоря, один раз всего у себя ловил подвис биндера ГГ, 3 допы назад malandrinus, правильно ли я понимаю конструкцию counter = (bind_stalker.watch_value == prev_watch) and (counter + 1) or 0 ... if counter > 5 then в течение пяти "тактов" апдейта первое выражение было true (остановка сердца?) и тогда можно накопить цифровое значение отличное от нуля (иначе, в нормальной ситуации, логическое будет false, т.к. игровое время увеличивается на несколько мс с каждым "тактом" и тогда каунтер будет = 0), так? А на чем основана уверенность, что если этот counter > 5, то это значит, что биндер повисший (т.е. 4 апдейта - еще не критично, или может можно и 10 пропустить, а на 11-й "очухается" ) magnit, вот. Пробуй. (правку отбил тегом -- malandrinus ...... -- /malandrinus) malandrinus, еще вопрос: counter = (bind_stalker.watch_value == prev_watch) and (counter + 1) or 0 работает быстрее, чем такое if bind_stalker.watch_value == prev_watch then counter = counter + 1 else counter = 0 end или просто более лаконично ? Dennis_Chikin, У меня тоже работает. Заметил "ложные срабатывания" во время сна и в момент, когда висит окно диалога перехода на локацию. Реальных подвисаний биндера пока спровоцировать не удалось Dennis_Chikin, а чем мешает gps_habar? Хочешь - попробуй слегка оптимизированный gps_habar (убрано логирование: все равно отладку никто смотреть не будет, а строчки собираются + прямая вставка в таблицы)

magnit, очень рад, что нашлось такое оригинальное применение этой отладке. Но хорошо бы все-таки устранить причины проблем. Но когда есть диагностика - это уже хорошо Согласен на 100%. При перегреве видяхи - первый признак - проблемы с текстурами, цветом. Потом - зависание, синий экран или что-нибудь еще в этом роде. Я сейчас тоже с этим мучаюсь - покупать альтернативный блок охлаждения ну очень не хочется... radeon-amd, чтобы узнать точно, какая температура - поставь тот же HWMonitir от CPUID. Сразу увидишь - он фиксирует текущие/мин/макс параметры всех компонентов, какие можно мониторить (температуры винтов, чипсета, проца, напругу и скорости кулеров - в том числе).

Dennis_Chikin, насчет спама в лог: 1. строки вида cl setDestroy [15842][47789] В 1.0006 раскомментили движковую отладку, сделав агрессивную зачистку памяти. Ни на что не влияет 2. sv reject. id_parent [0][actor:single_player] id_entity [15842][separator:separator15842] [47789] Сепаратор - некий виртуальный объект. Если в скриптах разбираешься - найдешь сам 3. Переход не появился - только скриптом добавить, правка в патче поможет, если загрузить сейв до первого выхода с ТД на кордон. V@syan, скрипты не соответствуют аллспавну (скорей всего, amk_mod.script). У меня тоже были проблемы, пока 19.04 одним файлом не накатил. Кстати, апгрейд до 19.04 и одним файлом 19.04 отличаются по аллспавн, насколько я знаю. mamon, файл как раз есть, ошибка была в файле textures.ltx и в патче 12.05 она поправлена. Xotabych, попробуй эту строку 700 в скрипте if obj and alife():object(self.npc_id).online then заменить на такую: if obj and alife():object(self.npc_id) and alife():object(self.npc_id).online then ЗЫ: к Знатоку врядли имеет отношение: менеджер оружия просто у тебя сработал в этот именно момент.

sepator, во избежание подобных вопросов впредь, объясню: то, что ты обвёл на скрине красным, твой клиент подобрал с трупика, который либо лежит теперь пустым, либо уже убран уборщиком. А вот у того трупка - не отработал калбэк на смерть, что и породило запихивание движком ему в инвентарь отмеченных предметов (ничего другого кроме той дребедени в таком случае в трупике не спавнится). И впоследствии это не должно ничем грозить: неотработка этого калбэка грозит скорей всего переполнением стэка с последующим вылетом. Но это сиюминутное явление, - уборщик приберётся и всё будет ок.

Arhara, первое - видимо, да. Второе - нет. Я проверил, скрипт у него - "чистосоляночный", 1:1 от 19.04 Дима, нашёл ошибочку Вот правильная табличка для sak.script: local nepis_id={8695,2511,2204,2167,2172,2185,2255,2235,2355,3131,3234,3152,3955,3987, 4896,4899,6109,6108,6110,6116,7160,7164,7165,7166} (был пропущен Волк - 2167, в самом начале и из-за сдвига - ошибка по стори-регистри естественно: ведь читаем секцию одного, а респавнить пытаемся другого). Предлагаю перейти на тот метод, что выложил Колмогор в "Раритетах" - по крайней мере, не будет тебе работы с каждой допой переделывать эти таблицы. Там всё работает "на ура". при желании можно ограничить список оживляемых, как захочется. Сразу оговорю: таблица задействуется только при попытке оживлять кого-либо с помощью "Живого сердца". tangu_95, проверить, есть ли такая строчка в gamedata\config\gameplay\info_l08yantar.xml <info_portion id="yantar_ecolog_give_reward"></info_portion> Если нет, то разбираться с геймдатой, потому что в 19.04 этот поршень прописан, а в вашей, видимо - нет.