Dennis_Chikin

Что делает вызов amk_particle.amk_particle() ? Скрипт, ну, предположим, стандартный от amk ? Это amk_particle:__init(params) вызывается ? А что он возвращает ? Artos, ага, спасибо. Парочку тривиальных вида nil:add( что попало ) уже вижу. Ну и, как я понимаю, конструкция вида if p:is_finished() then p:update() применительно к этому "классу" - это, вроде, тоже не совсем здраво ?

Какая, однако, прелесть:

Некоторое время назад я здесь писал про жуткий лаг от непися с моделькой dolg\stalker_do_balon_8.ogf (не путать с 80, впрочем, в смысле лага одна другой стоит). Поскольку это дело меня достало - взял, и тупо заменил на модельку dolg\stalker_do_balon_1.ogf. Вместо 3-х секундного аж застревания имеем всего-лишь "спотыкание" - то есть, менее полусекунды. Кстати, эта моделька ТОЖЕ не самая удачная в смысле лагов - есть такие, на которых лаг практически и не заметен. Таким образом, считаю, что ответ на вопрос "кто виноват" - получен. Остался вопрос: "что делать ?" Как искать тормозные модели: при входе непися в онлайн (когда тормоз и случается), в лог/консоль пишется имя. При убиении - пишется оно же + название костюма + модель. Отдельно следует убедиться, что это - лаг от непися, а не от его оружия.

http://dl.dropbox.com/u/27871782/fix2012_05_21.7z - собраны все правки после 02.05.2012 На скорую руку поправлены новости. На всякий случай, после первого запуска с этими правками, перед тем, как переходить с локации на локацию - минут 5 подождать, чтобы "утряслось". Переделан невидимый костюм (ага, тот самый, который 3-й год найти не можем Он больше не портит зрение всем подряд (даже когда отсутствует как таковой), а включается, только когда надет. В надетом виде действует только на врагов. При этом это таки не абсолютная невидимось, а если бы и так, то ничего не говорится, например, про слух, нюх или, скажем, контролерскую телепатию. В общем, все примерно так же, как и в аналогичного свойства костюмах у неписей. Стараемся красться и прятаться. Впрочем, если враги заметили, можно резвенько отбежать назад/в сторону. Проверка на надевание костюма - в inventory.script, основной код - в actor_devices. В принципе, туда-же можно вешать арты с невидимостью, девайсы с невидимостью, вообще всякий шмот с какими угодно эффектами (хоть реактивный ранец, хоть портативный генератор Кайманова. ) Upd: кто скачивал до 5 утра сегодняшнего - перекачайте.

По поводу Темной Долины тут уже вопросы возникли. Попробую "объяснить популярно" © Петруха.

Вообще, конечно, по сну, выбросу, и прочим событиям с длинным периодом - их все надо с таймеров убирать. Туда же и ремонт оружия. Проверка по пять раз в секунду на предмет "а не прошло ли с прошлого раза уже целых 30 часов" - это идея не здравая и не гуманная. А когда этот таймер еще и запускает, кто хочет... Быстрые таймеры - они для коротких периодов, и для событий по сути одноразовых. А так, действительно, только нетпакеты переполнять. Закупите пару десятков ремкомплектов, запустите десяток трансформаций, да штук 5 новостей - и уже ни что не спасет. Благо, сейчас плавный апдейт есть, с добавлением/удалением функций, а для много чего вообще табличку с расписанием можно повесить, и заглядывать в нее изредка.

Artos, см. выше апдейт 2: 10 или не 10 - не влияет. Да хоть 3 всего. А вот для случая с одной - двумя записями - сейчас тоже проверю. Уже интересно стало. Gun12, там в начале разговора было резюме: исходя из описания lua - не от ПЫС, а от создателей собственно языка, сталкеровкий lua на такую камасутру право, увы, имеет. (Хотя это, конечно, ближе к буквоедству - "делаем так, по тому, что явно не запрещено", чем к рациональному.)

Продолжаем разговор про таблицы. Вот код: function test_tbl() local t, s = {}, 0 for i = 1, 10 do t[i] = i end table.remove( t, 10 ) t[10] = 10 table.remove( t, 10 ) _util["list_tbl"]( t, "test_tbl" ) end (list_tbl - там много всякого, но, в общем, классическое for k,v in pairs(t) do ... end) Вот конечный результат: 1, value: 1 .... 8, value: 8 10, value: 10 9 records in table [test_tbl] ( # возвращает 8, что логично. ) Промежуточные - 10(10), 9(9), 10(10) То есть, либо table.insert()/table.remove() - кстати, in pairs()/next() не гарантируют последовательности 1, 2 ... - либо - все остальное. Artos, по поводу того, что в соли "очень много" всего - я бы даже жесче сказал. Приводим в порядок потихоньку. Upd: да нет, я уже не сетую. Просто чтобы исключить другие причины. И, да, вот конкретно такой результат - он, все-таки, несколько удивляет. Скажем, я бы понял вылет с грохотом, или 1,2...9,10 (то есть, несработавшее вообще удаление). Gun12, в смысле, код попробован на чистом lua, и конечный результат: 1, 2, ... 8, 9 ? Upd2: проверил на меньших значениях: в сталкерском lua то же самое - рушится. Со SciTE, похоже, действительно, разница в реализациях. Ну и аминь. В принципе, имеет право - отрицать глупо, бессмысленно, и ничего не изменит.

"Обрывок кода" - это и есть весь сколько-нибудь значимый код. nil в таблицу здесь попасть не может, нецифровых индексов или "дырок" случиться тоже не может. В смысле, была надежда, что table.remove при однократном вызове таки индексы исправит как надо. И говорить здесь имеет смысл именно про гуманизм. По той причине, что если у нас в результате получилась хэш-таблица, хочется ожидать, что # вернет 0 (ну или сколько у нас там осталось от индексированного, а table.remove() просто не будет делать с ней ничего. Иначе лучше ими действительно не пользоваться. В действительности же предложенное решение с t1000s = #t1000 не спасает, поскольку до момента, когда крах таблицы становится очевидным (нет записи, которая должна быть, есть та, которой быть не должно), # возвращает ровно то же самое, что и посчитано руками. И даже хуже того, если считая руками, мы получим вылет по попытке что-то делать с уже несуществующим элементом, то с использованием # - не узнаем даже о самом факте краха. Собственно, пару лет назад так и случилось, когда под девизом "заоптимизируем все" поменяли на автомате все табличные функции на доступ через #t+1 / #t - 1. Про вариант трогать таблицу в цикле, и присваивать nil произвольному элементу - это-то давно обсудили, и все согласились (а по существу спорить не с чем), возможности же, скажем, изменить произвольный существующий элемент таблицы, без удаления/добавления - весьма и весьма жаль. Ну и для "солянок" очевидно то, что "непредвиденное" с любой нелокальной таблицей скорее произойдет, чем не произойдет. А в свете того, что удаление одиночного элемента - операция крайне редкая, таблицы же по большей части не великих размеров - я вот для себя вижу скорее причину отказаться именно от использования table.remove(), чем от чего-либо еще, и таблицы по необходимости пересоздавать. Тем более, что многие и сами по себе живут не долго. P.S. Да, видимо, формулировка про "делает непредсказуемое" внесла неоднозначность. Читать следует как "внутри таблицы происходит нечто непредсказуемое при".

Ну, давайте еще раз поговорим об этом. В смысле, о таблицах и добавлении/удалении записей в них. Это я ведусь на провокацию. На самом деле говорили уже много где неоднократно, разработали теории, использовали много страшных слов типа "индекс" и "хеш", однако лично мне симпатичнее всего давний вывод malandrinus'a, что нефиг возиться с тем, что ведет себя явно негуманно, и если таблицу можно пересоздать - лучше тупо пересоздать. Вообще говоря, ни кто не обещал какого-либо доступа к внтреннему счетчику, использующемуся при присваивании вида t = { v1, v2, ... }. Обещали только, что будет работать пара table.insert()/table.remove() и доступ вида v = t[n]. Тем не менее, когда операция t[n] = v делает внутри таблицы нечто непредсказуемое, а затем table.remove( t, n ) игнорирует наличие в таблице записи с индексом n, и удаляет фактически что попало - это вряд-ли можно считать как-то соотвествующим принципам гуманизма. P.S. А вызов функций и передача параметров ( не говоря уже о вызове методов у "самодельных" объектов ) в текущей имплементации таки явно относятся к "тяжелым" операциям. Был бы оптимизатор, как практически во всех современных плюсях - разговор был бы совсем другой.

В bind_stalker на плавном апдейте внезапно посыпалось. for i = 1, t1000s do if t1000[i]["name"] == task_name then table_remove( t1000, i ) t1000s = t1000s - 1 return end end

Убил целую неделю на то, чтобы убедиться, что удаление из таблиц вообще делать нельзя. Ни каким образом. Ни присвоением nil, ни table.remove(). И без разницы, на самом деле, в цикле, или не в цикле. У табличных функций сносит крышку непредсказуемо. Имеем 13 записей, удаляем через table.remove() последнюю по номеру - имеем 12. Добавляем - снова 13. Удаляем - удаляется почему-то 12-я, размер таблицы - 11, 13-я болтается отдельно. Добавлено через 208 мин.: Кстати, про монстров. Надеюсь в течение недели доделать таки "костюм нудиста" (который невидимый), чтобы перестал всем зрение портить, и будут нужны добровольцы на глобальную правку всех-всех конфигов. Во-первых, исправить это самое зрение (подбирать параметры, чтобы слепые прозрели, а особо зрячие перестали видеть через стены. Ну, заодно всем - правку хитов (подтянуть к сотне, и скомпенсировать иммунитетами). Также, оружию повышать убойность. Да, кстати, по поводу "странного" отображения параметров оружия: Чтобы не было бреда в отображении полосок (а равно и странностей при разборках между неписями), нужно всем обычным патронам прописать убойность 1, поставить в списках патронов, подходящих для ствола, эти самые обычные, увеличить убойность и дальность стволам, убрать все hit_rate, disp_rate и прочие *_rate. Для AI не лишне будет привести в соответствие min_radius и max_radius. Примерные образцы по оружию (несколько стволов): http://rghost.ru/38062395; по неписям выкладывал раньше.

Нашел, почему "бьется" pstor... Причина элементарна. Чтобы не переполнять пакет актора, используются более другие хранилища. Вот только проблема в том, что есть некий лаг между созданием собственно хранилища ИЛИ спавном актора, и переходом в онлайн собственно хранилища. А чтение/запись идет как попало. В старой соли если хранилища нет в онлайне, идет обращение к pstor актора. То есть, в любой момент запись может быть куда попало, а чтение - совсем из другого места. Результат понятен. Сейчас убрал эту "рандомизацию", ну так оно и поехало - то - висяк, то - вылет. Зато - сразу видно. Аналогично, кстати, с любыми манипуляциями с онлайн объектами сразу после создания, или после удаления (когда серверного уже нет, а онлайновый - еще есть). И таких мест - в количестве.

По-видимуму, этот процесс может быть вечным, так что кумулятивный апдейт по состоянию на 02.05.2012: http://rghost.ru/37866278, как есть. Версия отладочная, в лог пишет часто, и много. Тестировать надо. Пробежал полностью только пару локаций, а правок - куча. Что здесь есть:

Вообще, я вопрос про отношения некотоое время назад поднимал. Установление отошений непись-непись скорее не работает совсем, чем работает хоть как-нибудь. По крайней мере кодом мне не удавалось поймать момент, когда враги оказывались не врагами. И если даже меняется, то "отработать" где-либо (скажем, при вычислении опасности или наличия/отсутствия врагов) - не успевает. Можно задать goodwill неписю, или группировке. Причем, к актору - работает в любое время, а вот с прочими неписями опять таки проблемы ( вообще - логично, поскольку хранить неграниченного размера список неписей - это ой). Artos, вообще, в нескольких местах имеет место быть код, подозрительный на переполнение репутации. Все собираюсь посмотреть, но все не до этого. Upd: да, это вопрос. В смысле, ни у кого аналогичного ощущения не возникало ? Хек, правку по известному сюжету ТД для известного мода выложу на днях - как только разберусь с кривым отображением видимости актора для врагов. Там будут нейтральные после лечения отдельные враги, и отдельно изменение отношений группировок за "заслуги". А группировка неписям меняется только неименным, или на короткое время, чтобы избежать разборок между вылеченным и участниками сцены из враждебной ему группировки. То есть, работает так: отношение непися к актору дается таким, чтобы в сумме с отношением группировки получилось чуть больше 0, непись загоняется в группировку, нейтральную всем (чтобы не убили эти самые все, и чтобы непись успел уйти под нужный смарт, а не срывался в бой), потом по таймеру возвращается обратно. Отношение группировок меняется независимо (вычисляем разницу между текущим и нужным, сохраняем, прибавляем. Потом при надобности, вычитаем). В общем, все красиво, за исключением, что индикатор видимости актора врагами после такого лечения застревает в максимуме, до следующей перезагрузки. Ну, как при исчезновении собакофантомов.

Grisli, ага, спасибо. Актуально весьма. Э-эх, еще бы кто-нибудь взялся за огненные партиклы... И, люди, нужна помощь тех, кто действительно хорошо разбирается в графике. Ну действительно, посмотрите уже: что ТАКОГО в actors\dolg\stalker_do_balon_8 (костюмчик dolg_outfit), что он при первом выходе в онлайн ТАК тормозит ? Почему другие могут подтормаживать по-разному, но в общем - терпимо, а этот - как не знаю что.

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

Это к вопросу о закрытой разработке. Сделал ровно то же самое полтора года назад. Хотя пришлось вырубить перезаряду (и, соответственно, смену оружия непосредственно во время боя), поскольку не было специалистов по схемам/анимациям, а непись, стоящий спиной к ГГ и целящийся куда-то "туда" (что долженствовало изображать перезарядку), выглядел откровенно погано. Вообще, поведение неписей в онлайне надо делать одной схемой. То есть, один эвалюатор на "надо что-нибудь сделать", проверка на бой/не бой, а дальше все действия в очередь - и перезарядку, и смену оружия, и гранатометание, и сбор хабара. Это даст и простоту адаптации, и уберет пачку тормозов с глюками от конфликтов схем. То есть, когда неписю надо сделать что-то в бою - он прячется, и делает по порядку все свои дела. Если боя нет - опять же по порядку все, что не может в бою.

Мда... Емкость гулага, оказывается, вполне имеет право быть отрицательной. Другое дело, что тупо лепить в олспавне всем подряд неписям [smart terrains] бла-бла-бла = true - вот это - в высшей степени неправильно. Оно вообще-то для того, чтобы место именно этого непися именно в этом террейне ни кто не занял. Вот как раз так -емкость и получается. То есть, она означает, что в нем только именные персонажи, и если кто-то УМЕР - только тогда его место занимает другой. Обычно сидящий в офлайне/незаспавненный, и выпускаемый только в случае смерти тех, кто был раньше. Когда не хватает именных - приходят первые попавшиеся. Таких гулагов в солянке нет. А вот с назначенными зачем-то коммонерами, сверх емкости - полно. Вперемешку с ошибочными логиками/путями/спавнами, где появление отрицательной емкости уже говорит именно о таких ошибках. Что с этим делать сейчас - я не знаю. 8(

По текстурам: 2048x1024 - я знаю одну, для которой это вынужденный размер. Собственно иконки. Ну, адаптацию для "слабых" видеокарт все помнят. Чего не должно быть точно, так это 2048x15чего-то там. По поводу 1024x1024 vs. 512x512 - надо на самом деле экспериментировать. По звукам - что и зачем делалось в 14.08 - сейчас, наверное, не скажет уже ни кто. Если только поспрашивать тех, кто занимался озвучкой. Помню, даже тема вроде была. В новой - да, трогалось серьезно. Но тоже слегка сумбурно. Сюда достаточно регулярно заглядывают практически все, может кто и в курсе подробностей.

Artos, говорить, что остальные ничего не делают - это неправильно. И, возможно, то, что постоянно требует НИ - уместно делать в закрытом режиме. Равно как и многочисленные изменения графики, квестов, введение новых монстров, и прочее. Я взял за основу старую соль именно по тому, что занимаюсь тем, что давно надо было бы сделать, и для чего 2 гигабайта новой графики (и минуты на загрузку ТОЛЬКО этой графики) - ну совсем не нужно. И НИ раз в месяц не нужно. Ага, и с прицелом на то, чтобы потом можно было легко подключать то, чем действительно хочу заняться, типа нормального офлайна, онлайнового AI, нормального рюкзака и прочего. Также очень хочется исключить ситуацию, когда для добавления маленькой фитюльки (или, о ужас, перекомпиляции олспавна), надо непременно лезть в amk.script, amk_mod, пачку xrs*, rx* и бог знает что еще, а, до кучи, во все полмегабайтовые простыни *_dialog.script. То есть чтобы любые дополнения кого-либо не надо было долго и мучительно переносить, и на было "ставить поверх того и того, но не того и другого". ХЕМУЛЬ36RUS, очевидная причина завиcаний NPC в Темной Долине, Баре, ДТ и АС - это их принудительное запихиваемые в смарты сверх заданной емкости и свободных работ. Сейчас вот убрал вылет по таким же монстрам в левом верхнем углу АТП, в очередной раз почистил Кордон, занимаюсь собственно Темной Долиной (а заодно и восстановить сюжет с освобождением долговцев). Впрочем, не исключено, что и правки влекут за собой проявление других ошибок, ранее не вылезавших. Как, например, правка по реакции на опасность повлекла за собой необходимость правки xr_conditions (раньше вылеты в бою были, но редко, и воспринимались как норма, поправил реакцию на опасность - висяки участились). Впрочем, не исключено, что и в моих исправлениях есть не только вынужденные решения, которые поправятся потом, но и тоже ошибки. Так или иначе - все равно надо разгребать. SergeT, более половины времени, ушедшего на новую соль, у нас ушло совершенно неконструктивно. То искали несуществующие ошибки (то есть, существующие, но существующие с начала соли/амк/оригинала, но отнюдь не свежевнесенные - тот же Монгол, охотящийся за Пулей - тому пример, не говоря о химере приснопамятной, или, скажем, развалившееся лечение, в котором ошибка тоже изначально была), то НИ после свежих олспавнов, то опять же, битвы с графикой. Делать несколько команд, работающих параллельно, а потом как-то совмещать результаты - ну, кто желает - да сделает. "Окончательный продукт" - это если в магазине в красивых коробках продавать. Причем, тот же Сяк его пару раз выкладывал. И что оказалось ? Правильно, сильно на любителя. Причем сразу же пошли сторонние правки/доделки, даже не смотря на типа "защиту" от этих самых правок. Ну и зачем оно так ? По гордым заявлениям - ну, да. С самого amk стреляли. Кстати, именно с амк, а не с оригинала. Беда только в том, что чуть где тронь - сразу рассыпается. Причем даже если там, где трогали, вроде ни как влиять не должно на то, что рассыпалось.

dtyz8, xr_conditions.script - сам по себе. Вот если xr_danger.script - тогда к ему надо и xr_conditions. От более ранних правок не зависят. Сэйвы должны работать все. Если это не так, давайте в личку парочку - буду смотреть, что именно не так. ХЕМУЛЬ36RUS, Если ходим шагом, и оружием не брякаем - Кузнецов должен вообще спокойно стоять. Если бегом или что-то с оружием делаем - возбуждается. Если возбудился, и уже успокоился, и видит ГГ - то не дергается. Если ушли метров на 160, и вернулись - опять возбуждается. Вот примерно так должно быть. Это если по-близости тушканы не топочут, и ни кто на электробалалайках с 10 киловаттным усилителем не играет (300м дальности). В общем, если он слышит громкий звук - то реагирует, а потом "привыкает". Если звук другой - опять реагирует. Самый громкий звук, естественно, перебивает все остальные. Вообще, надо бы сделать, чтобы по бегущему он вообще сразу стрелял. А на электробалалайку чтобы вертолеты вызывал.

http://dl.dropbox.com/u/27871782/xr_conditions03_24.7z В комплект к предыдущему. Для ВСЕХ версий соли, включая новую (да, солдаты на насыпи теперь стреляют как положено, генераторы не виснут). В том числе лечение ошибки xr_conditions.script:537, и, теоретически, должно спасать от вылетов при уходе врагов в офлайн во время боя. Должно начать шевелиться по-шустрее, кстати. Если к Кузнецову идти не шагом (шифт зажат), он нервничает, да. Но один раз. Вот как раз правильной настройкой звуков/материалов это дело теперь и регулируется. upd: http://dl.dropbox.com/u/27871782/anoms_esc.7z - между делом убрал на Кордоне рэндомные аномалии из тоннелей, здания, где Сепаратор/Халява, и моста рядом с Толиком (а то что-то туда сталкеры не по делу влетают). И спавн изломов тоже оторвал. P.S. Для скриптеров: в процессе обнаружено, что какая-то схема с проверкой условий на боевую ситуацию при смерти неписей не отключается. Последствия понятны. Раскомментируйте строчки со словом "log", и увидите на сценках спасения всяких разных. Кто сможет найти, и что-то с этим сделать - будет большой шаг вперед.

Подумал, и переделал еще раз. http://dl.dropbox.com/u/27871782/xr_ganger03_23.7z Исправлена пысовская еще ошибка с неработой ignore_types. Зомби игнорируют гранату всегда. Прочие, если явно не задано иное, на гранаты всегда реагируют. Так что всякие тусовки можно разгонять гранатами. Застрявших неписей также можно выгонять из углов дымовухами. Кэмперы реагируют на гранату и на попадание в них. Дистанция всегда проверяется в следующем порядке: 1 - граната. 2 - настройки combat_ignore 3 - ignore_distance в логике (по умолчанию - 150 метров, так же, как на ранение. 4 - прочие ignore. Если не заданы, то берутся следующие: граната = 12 видим новый труп = 30 попадание = 150 звук = 70 (минимальное расстояние + чуть запаса между враждебными лагерями) На стрельбу неписи реагируют, если слышат выстрел, расстояние меньше заданного и реакция явно не запрещена. Кто стрелял - им при это не важно. Так что гитаристов, 3-й раз подряд исполняющих Розенбаума, можно от этого занятия отвлечь, если стрельнуть не важно куда. В архиве - gamedata - файл для чистой соли/дополнений, отладка - он же, с выводом в лог. Бонусом конфиги с настройкой слуха/зрения неписям для стелс-миссий (можно прятаться в кустах, подкрадываться со спины); дальность зрения всем неписям пока жестко задана 60 метров в meceny_work.script (будет оторвано как только, так сразу.)

_tbl*.script - это из всех скриптов потихонечку выносятся всякие таблицы, чтобы избежать дублирования, и в дальнейшем править только их. _util.script - тоже туда же. Разумеется, они нужны.