Народная 2010 разработка

[Dennis_Chikin 3 658]

malandrinus,

Работает. Потестил на том самом файлике, где зависание 50/50 сразу после загрузки.

 

 

Вопрос ко всем: если оторвать gps_habar.sript (всего нашел 9 мест) - это вроде ни на что не должно повлиять кроме собственно возможности ставить метки ?

 

Shadowman,,

Я сейчас пытаюсь проверить пару странных идей, и мне не нравится, например, то, что он вызывается "over 9000" раз из, например, только add_fresh_meat только еще где-то между началом синхронизации и стартом уборщика. Что он при этом делает сам - я даже и предположить боюсь.

 

Изменено 1 Июня 2010 пользователем Dennis_Chikin

[Dennis_Chikin 3 658]

Вешается meceniy_art.art_respawn()

 

Симптоматика: строго после 22 часов; внезапно, либо после перехода между локациями - сразу, при загрузке сохранений - сразу - вешается актор. Поставленный watchdog показывает, что "ушел и не вернулся" именно этот вызов.

 

BTW, в оригинале из OGSM спавн производился только после выброса, только на текущем уровне и только 4-х артов с небольшими задержками между каждым.

 

 

Workaround: перенес все содержимое meceniy_utils.on_actor_update_callback() непосредственно в биндер актора на 10 секундный апдейт, для спавна "черной энергии" прикрутил оригинальный ogsm_surge.script

 

Тестирую.

Из положительных эффектов - ЧЭ перестала спавниться "кучками".

 

Shadowman,

У меня больше НЕТ этого конкретного зависа. Остались вылеты по стеку при завершении игры из Лабиринта и при проходе бандюков через ж/д на Кордоне на границе радиуса а-лайфа.

 

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

 

В качестве средства диагностики зависа - сообщение в ньюсы перед началом и после отработки. Если видим первое, но нет второго - висим именно здесь. Себе такое поставил, видно абсолютно четко.

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

 

Со снятием координат есть слабооформленная мысль о том, как без этого обойтись. Когда пойму спавн/отключение аномалий - попробую. Или когда разберусь с путешествиями монстров. Перевесить спавн артефактов прямо на них.

Изменено 8 Июня 2010 пользователем Dennis_Chikin

[Dennis_Chikin 3 658]

Кстати, о птичках.

while c рассчетом чего-либо непосредственно в условии, если это не одно сравнение, работает вообще как-то странно.

sapsan, если бы... Скорее, наоборот: в отличии от for оно явно делает что-то лишнее.

 

Изменено 7 Июля 2010 пользователем Dennis_Chikin

[Dennis_Chikin 3 658]

Понятно. Похоже, случайно нашел один из признаков надвигающегося xr_logic: 1490

 

Кто-нибудь поглядел бы еше в этом самом xr_logic.script на pstor_load_all() внимательно.

 

Shadowman, ну, скажем, на предмет classname == nil. И на предмет мусора в этом classname.

И диагностику вменяемую этому самому net_pda_чего-то, у которого pstor с мусором, вывести в лог не помешает.

 

Upd: у себя - уже. И это был единственный раз ошибки 1490, который вообще случился за последние пол-года. Был именно мусор. На фоне пачки лагов. (Маячками не пользуюсь.)

 

kamikazze, имеет смысл подкрутить для начала update_monster_factor ?

И, да, с радиусом alife=250 лог стал похож на человеческий. Если не считать внезапно !SV:ge_destroy: [7080] not found on server для патронов у неписей.

 

Однако я не понял, зачем тогда тот же net_destroy() вызывать при загрузке для трупов ? По-моему- одно из двух.

 

P.S. Я правильно понимаю, что нанесение хитов - это только в он-лайне ? А обнуление - это для офф-лайна ?

 

Изменено 11 Июля 2010 пользователем Dennis_Chikin

[Dennis_Chikin 3 658]

О, сколько нам открытий чудных...

Пока тут все заняты таблицами, доставляет несказанно следующая картина:

Случилась тут, скажем, с какой нибудь rat_strong31505 неприятность - death_callback. Казалось бы, померла, так померла. Ан нет. issue_event с функцие "update" - еще туда-сюда, а вот try_switch_to_another_section, где тушка пытается посмотреть своими мертвыми глазами на актера, и далее по тексту, в цикле, минимум 2 раза - это, безусловно, сильно.

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

 

P.S. Кстати, зависаний в xr_logic так и не нашел. Все функции как минимум возвращаются нормально. Как и в каком месте монстры/неписи могут вылетать, увидев врагов - не понимаю. Я не знаю, куда и на что еще смотреть. Логика - scripts\amk\logic\rad_rat1.ltx, scripts\amk\logic\mil_rat1.ltx, scripts\amk\logic\rad_rat2.ltx, scripts\amk\logic\pri_rat4.ltx, scripts\amk\logic\pri_rat5.ltx, scripts\amk\logic\mil_rat2.ltx. Гулаг у всех == nil. Кто-то из них нормальный, а кто-то - вылетает. Кто - не знаю. Лог может закончиться на чем угодно.

 

upd: та, что c припяти -и вылетает.

 

Так, скажите кто-нибудь: эта конструкция -

on_timer = 120000 | mob_home1

on_signal = sig_attacked | mob_combat

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

 

И кто вообще разбирается в связках хr_* - state_mgr* ?

Изменено 6 Августа 2010 пользователем Dennis_Chikin

[Dennis_Chikin 3 658]

Ха... Возможно, я невнимателен, но ни где этого не видел.

А между тем, выполняя в цикле local result, key, value = ini:r_line("my_section",i,"","") - мы получаем содержимое конфига, отсортированное по key.

 

Это к вопросу о размере и формате конфигов.

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

 

P.S. И, да, не помню, кто писал про сохранность переменных внутри функции при повторном вызове: это была плохая идея.

 

Господа присяжные заседатели !

В рамках лозунга: "Очистим солянку от ... тормозов" - гляньте, кому не лень, товарища aem_arny29193 (или какой там у него номер в ваших сэйвах) на предмет story_id и инвентаря.

 

Тупо перебором 1,65534 и проверкой parent_id.

 

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

Возможно, глюк в моем коде - в сборе статистики, а возможно - и не в моем.

 

И неплохо бы сделать ревизию человеков-оркестров.

[Dennis_Chikin 3 658]

Я пытался понять, как все это дело работает в xr_logic.script

особенно save_logic/load_logic.

 

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

 

P.S. А вылет на собственно сохранении, или потом ?

 

Вылет прямо при сохранении.

По отрицательным значениям - наверное ты читаешь/смотришь на беззнаковые как на знаковые числа. В этом случае первый бит интрепретируется как минус. sapsan

Изменено 8 Августа 2010 пользователем sapsan

[Dennis_Chikin 3 658]

Терминаторы:

 

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

 

Та же ситуация, что и с правками по луту.

 

P.S. впрочем, damages.ltx я у себя все равно поправил - в сторону большего разнообразия.

 

[Dennis_Chikin 3 658]

Shadowman, ящики действительно дают подтормаживание, особенно на новых локах.

Я выкладывал логи, где видно: почему так. Аналогично - трупы, пока не убраны.

 

Кроме того, избыток хлама = лишние, ненужные операции как в amk_offline_alife, так в wather_act.

Как и неписи-коллекционеры. Впрочем, по хламу и коллекционерам скоро уже все будет.

 

Upd: ящики - да, все, что можно разбить. Возможно (не проверял) - вообще все перемещаемое.

 

Трупы - штук 5 на локацю - погоды не делают, а уборщик вроде справляется. Вот когда они оставались и копились, скажем, на тех же на Агро/Янтаре, и туда же набегали живые - было уже заметно. Вообще суть засады примерно такая: потестили локу - вроде все хорошо - оставили возможность появления на ней свежего мяса, пока уборщик не почистил ранее настрелянных тушек - у кого-то внезапно начались странности типа тормозов/вылетов. Или, скажем, сделать квест с отстрелом пары десятков каких-нибудь крыс, а после смерти последней добавить в онлайн еще десяток чего-нибудь живого из расчета на то, что тушки ресурсов больше не жрут - это тоже будет плохой идеей.

 

Изменено 19 Сентября 2010 пользователем Dennis_Chikin

[Dennis_Chikin 3 658]

У неписей я заметил в основном бинты и наборы типа "4 балалайки, 2 гитары и 5 гармошек"

 

Кстати, не уверен, что тупо сокращение объектов, носимых неписем, и вообще имеющих парент'ов на локации, на что-то повлияет сильнее, чем сокращение общего количества, а также количества и длительности операций, выполняемых над каждым из этих объектов одномоментно. В оффлайне НЕТ инвентаря. Так что резать имеет смысл именно дубли разноцветные, всякие научники/экзы без ПНВ, и всякие извращения самих ПНВ - оставить max 4 вида, и то не для всех.

 

А что касается тайников и общего количества всего - для чего весной код выкладывался ?

Кстати, да, его вполне можно подключить и для неписей. Отсутствие инвентаря не мешает удалять и спавнить.

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

 

Shadowman, раз: http://www.amk-team.ru/forum/index.php?sho...6545&st=500, с поправкой, что fog_density таки 0.8 и меньше;

два: http://gettyfile.ru/629086

 

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

 

Изменено 1 Октября 2010 пользователем Dennis_Chikin

[Dennis_Chikin 3 658]

Интересно, а насколько осмысленно использовать конструкции вида if string.sub(obj:name(),1,3) == "af_" then ?

 

Sapsan, ага... Что-то такое следовало ожидать. Поражает скорее эффективность обработки регэкспов.

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

 

Изменено 25 Ноября 2010 пользователем Dennis_Chikin

[Dennis_Chikin 3 658]

Белые, голубые, и прочих странных расцветок деревья - это чисто отношение fog_color и hemi_color. Такого есть в количестве и без всяких правок. Первое должно быть примерно на 0.1200-0.1500 меньше, чем второе.

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

 

Кстати, о птичках - точнее, об резких переходах освещенности:

кто-нибудь знает, чем обрабатывается clouds_color, особенно последние 2 значения - скриптами или непосредственно движком ? Если движком, то разница между соседними секциями должна быть не более 0.300, в том числе и для переходов от одного типа погоды к другому.

Если все-таки есть скрипт - ткните меня в него носом. Ибо жажду кое-что подправить.

 

dimos, я уже проверил, и даже выкладывал типа демонстрацию. Все distance - это расстояния, по достижении которых начинает отрисовываться то, чему оно соответствует. А цвет - это такая странная штука, у которой более двух ипостасей. До примерно 0.8 она окрашивает предметы, а больше - начинает появляться собственно затуманивание. Засветка - это и есть эффект окрашивания.

 

Upd: 0.1xxx, естественно. Поправил, где заметил.

Амбиент, похоже, без разницы. Это - "самосвечение". Подбирать в зависимости от sun_color и hemi_color, чтобы не получить слишком высокую или слишком низкую контрастность: типичный пример - помещение между южным блокпостом Бара и собственно внутренней частью локации при солнечной погоде оказывается как бы не темнее, чем при более мрачной. А если задрать на 0.01 - 0.02 выше некоего оптимума - получаем светящиеся стены. (да, есть что-то общее с туманом и светящимися елками, но те - вдали, а это - вблизи.)

 

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

То есть, при экспериментах надо выставлять одинаковые для 2-х соседних секций.

 

P.S. И цвета - RGB, не RGB, но по крайней мере не в диапазоне 0-1. Скорее коэффициенты какие-то.

 

Upd2: про fog_color криво сформулировал. Там комплекс из fog_color и fog_density. 0.8 - это про fog_density. Аналогично - с rain_*, но там другие значения, хоть и по тому же принципу.

 

Изменено 6 Декабря 2010 пользователем Dennis_Chikin

[Dennis_Chikin 3 658]

(Отдельным постом, для ясности.)

 

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

Для тех, кто готов править скрипты руками или осуществлять еще более осмысленную деятельность - нужны на самом деле diff'ы.

 

На самом деле мне жаль темы "ваши правки" - именно как отладочной - если бы там бы еще грамотно фид-бэк организовать.

 

Ну, это я как человек, испорченный нарзаном - той же pr-базой, мейл-листами и csup того же, скажем, freebsd.org, говорю. Понятно, что сложившийся в модмейкерстве стиль работы - мягко говоря, перпендикулярен.

 

Лог - это для другого. Он для привлечь внимание к сути странного, или например подтвердить отсутствие тех или иных изменений. Это как раз то, что приведено. И то, что выложенным набором скриптов сгенерировано именно что НЕ будет. Суть же неправильности в том, что отрегистрация монстов началась сразу после входа на локацию, и то, что сообщения про отрегистрацию оказались внутри сообщений о работе уборщика. Причем он сам уборщик в это время только еще сталкеров крутит, а до монстов добраться не успел.

 

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

! Cannot find saved game ~dc~: >>>>> [smart_terrain] on_death, obj_id: 45912
! Cannot find saved game ~dc~: >>>>> [smart_terrain] get_smtrid, obj_id: 45912
! Cannot find saved game ~dc~: info, [smart_terrain] get_smtrid, obj: fracture_normal45912(id: 45912, clsid: 109)
! Cannot find saved game ~dc~: info, [smart_terrain] get_smtrid, strn_id: 16484
! Cannot find saved game ~dc~: <<ok<< [smart_terrain] get_smtrid, strn: mil_monster(id: 16484)
! Cannot find saved game ~dc~: >>>>> [xr_gulag] gulag(mil_monster):clear_dead, obj_id: 45912
! Cannot find saved game ~dc~: >>>>> [xr_gulag] get_smtrid, obj_id: 45912
! Cannot find saved game ~dc~: info, [xr_gulag] get_smtrid, obj: fracture_normal45912(id: 45912, clsid: 109)
! Cannot find saved game ~dc~: info, [xr_gulag] get_smtrid, strn_id: 16484
! Cannot find saved game ~dc~: <<ok<< [xr_gulag] get_smtrid, strn: mil_monster(id: 16484)
! Cannot find saved game ~dc~: >>>>> [smart_terrain] se_smart_terrain(mil_monster):unregister_npc, obj: fracture_normal45912
! Cannot find saved game ~dc~: >>>>> [smart_terrain] get_smtrid, obj_id: 45912
! Cannot find saved game ~dc~: info, [smart_terrain] get_smtrid, obj: fracture_normal45912(id: 45912, clsid: 109)
! Cannot find saved game ~dc~: info, [smart_terrain] get_smtrid, strn_id: 16484
! Cannot find saved game ~dc~: <<ok<< [smart_terrain] get_smtrid, strn: mil_monster(id: 16484)
! Cannot find saved game ~dc~: >>>>> [xr_gulag] gulag(mil_monster):removeobject, obj_id: 45912
! Cannot find saved game ~dc~: >>>>> [xr_gulag] get_smtrid, obj_id: 45912
! Cannot find saved game ~dc~: info, [xr_gulag] get_smtrid, obj: fracture_normal45912(id: 45912, clsid: 109)
! Cannot find saved game ~dc~: info, [xr_gulag] get_smtrid, strn_id: 16484
! Cannot find saved game ~dc~: <<ok<< [xr_gulag] get_smtrid, strn: mil_monster(id: 16484)
! Cannot find saved game ~dc~: info, [xr_gulag] gulag(mil_monster):removeobject, strn = 16484(mil_monster)
! Cannot find saved game ~dc~: <<ok<< [xr_gulag] gulag(mil_monster):removeobject, self.population = 8, non_exclusive = 8
* Log file has been saved successfully!
! Cannot find saved game ~dc~: <<ok<< [smart_terrain] se_smart_terrain(mil_monster):unregister_npc, removed fracture_normal45912 from gulag type=mil_monster, strn_id=65535
! Cannot find saved game ~dc~: <<ok<< [xr_gulag] gulag(mil_monster):clear_dead
! Cannot find saved game ~dc~: <<ok<< [smart_terrain] on_death, strn: mil_monster
* Log file has been saved successfully!

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

 

Shadowman, посмотри комментарии todo. Это и старых багов с битыми сэйвами касается.

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

 

upd: последний набор и результат его работы: http://gettyfile.ru/672060/

Я в ужасе. Требуется помощь коллективного разума.

 

WhatAbout, ужас в том, что я не понимаю, как оно работало раньше. Я даже не Солянку имею в виду.

 

А так еще сюда же atp_fabrika_bandit - где их явно ненормальное количество, и пресловутая химера, которая в лучшем случае жрет производительность.

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

 

P.S. А вооще я неправильно ставлю вопрос. На самом деле правильный - такой: если куча всякого разрегистрируется при переходе между локациями, а следовательно, очевидно пытается регистрироваться при загрузке - зачем оно это делат, если находится НЕ на текущей локации ?

Где-то изначальный глюк в проектировании всей системы. Все остальное - следствия.

 

WhatAbout, ID без гулагов - посмотри хвост лога.

 

Чую, нагорит нам за этот чат, но вдруг кто из Великих Древних успеет увидеть, и сказать что-нибудь полезное - что, типа, так и задумано.

 

Бандюков явно кто-то разрегистрирует по нехватке чего-то. Сколько-то последних ведь остается ? И по-моему ровно столько, сколько работ прописано в скрипте. Хотя если верить комментариям в скриптах и статьям на вики - должен быть немедленный и бежалостный вылет.

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

 

P.P.S. Обрати внимание еще на такой момент: в конце игры у части отрегистрируемых id смарта - честные 65535 - я таких отфильтровываю. Остались именно те, у которых гулаг внезапно перестал существоать.

 

Изменено 19 Декабря 2010 пользователем Dennis_Chikin

[Dennis_Chikin 3 658]

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

 

Единственное но: сейчас вылезло очень много проблем, идущих даже с оригинала. Все те вылеты, которые "ни кто не знает: почему" и прочее. По многим уже знаем. Так вот прежде чем добавлять что-то новое надо таки поправить старое. Чтобы в кои-то веки уже нормально заработало.

 

И, да. То, что код всего накопившегося за годы - ужасен - все как бы в курсе. То, что сама логика этого кода заведомо глючная - тоже в курсе. То есть, "мы тут у себя написали маленький безглючный модик, отсоединив 2 скрипта от таймеров - зацените наш крутой скриншот", и с намерением потыкать пальцем в лохов, которые эти 2 скриптика еще не отсоединили - как-то тоже не требуется. Сделали - молодцы. Давайте будем интегрироватьс тем, что есть. Если по ходу дела еще 10 скриптов и 50 конфигов исправите - все будут только рады.

 

Изменено 11 Февраля 2011 пользователем Dennis_Chikin

[Dennis_Chikin 3 658]

Забавно. По логике должно быть наоборот. Путаница со звуками ?

 

Но вообще топот, да и ряд других звуков - нужны. Музон во время боя - нет.

P.S. Кстати, топот кошаков, если ориентироваться на тех, что были у меня - вполне соотвествует, когда они галопом скачут.

 

[Dennis_Chikin 3 658]

Вообще как бы не по теме... Но...

 

Озвучка - как минимум частично. Частично - ибо пункт 3.

Сообщения от уборщика - да, разумеется, будут убраны. Как и еще куча мусора.

Когда ? Как в песне поется - "Не сыпь мне соль на рану". Ибо мусора действительно куча.

 

[Dennis_Chikin 3 658]

Это как раз не оффтопик, а очень ценное замечание.

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

 

[Dennis_Chikin 3 658]

Вообще, адаптация acdc под что-либо - это первоначально плохая идея. Ну и отсутствие анализатора - тоже беда.

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

 

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

 

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

 

Но, в общем, все опять же сводится к тому, что желателен был бы именно универсальный acdc, и инструментарий для проверки. Как минимум на дубликаты, несуществующие имена, явно отсутсвющие или некорректные параметры.

Хотя бы по тому, что часть кривизны тянется еще с оригинала сталкера, и их есть не только в солянке.

Ну и добавление нового руками тоже безглючности не способствует. Банальные опечатки.

 

[Dennis_Chikin 3 658]

В общем, ситуация такая:

 

14.08 на статике брала меньше гигабайта памяти. На динамике - вполне влезала в полтора. Загрузка собственно текстур у меня занимает менее 5 секунд.

Хотя проблемы начались еще в 2009-ом, а часть идет с самого оригинала. Попробуйте надеть на ГГ бандитскую курточку или прицепить прицел к автомату. Получите заметный лаг.

Так быть не должно. Проблема - в кривых текстурах, размеры которых не одинаковы и не равны степени двойки. Размер тоже имеет значение. Для большинства предметов достаточно 512x512. А когда для ствола идет НЕСКОЛЬКО текстур, размером в надцать мегабайт...

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

 

Новая допа растолстела примерно на пару гигабайт, загрузка текстур занимает более чем пол-минуты, и на некоторых локациях на динамике все вместе банально не влезает в 2 гигабайта, отведенные 32-бит приложениям. То есть, вообще не влезает. С понятным результатом.

Я с этим работать не могу, и по этому все сделанное будет медленно и печально переделываться по 14.08, а части, зависящие от версии, выноситься отдельно.

 

Нужны добровольцы на тестирование и правку конфигов.

Неплохо бы также, если бы кто-то занялся приведением в порядок графики и звука хотя-бы и под 14.08.

 

А пока выкладываю "первый блин".

Изменено 19 Декабря 2011 пользователем Dennis_Chikin

[Dennis_Chikin 3 658]

Первый блин: http://www.sendspace.com/file/shya8z

Ставится поверх сборки от HIGHLANDER, ну, по крайней мере я на ней пробовал.

 

Вошло:

 

последние патчи Sapsan для 14.08

 

универсальная адаптация под 1.004, 1.005, 1.006 (возможно и дальше) - то есть, ни каких дополнительных файлов не требует. todo: проверить, работает ли вообще. У меня только "серебро" 1.006 - соответственно, на нем и проверял.

 

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

 

Исправлена некоторая часть вылетов по "e-parent...". Не все. Продолжение в следующих сериях. Лечение есть для подавляющей части, но надо адаптировать под 14.08.

 

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

 

Вылет по собакофантомам исправлен корректно, и даже почти и не тормозит.

 

upd: правка "вечной ночи", естественно, вошла.

 

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

 

 

Добавлено через 6 мин.:

MAV, тема называется "народная разработка". Вот это я и намерен выкладывать.

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

Изменено 19 Декабря 2011 пользователем Dennis_Chikin