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

[Shadowman 939]

Ray, LuaChecker писан "на коленке", как и многое такого типа для Сталкера

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

[Shadowman 939]

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

"Монолит" и "Жар" - с именем sakbuzz. Как различать?

Вобщем, Пузырь, Торнадо, Очаговый туман - определяются. Лифт не встречал (_no_gravity?). Жар и монолит - пока в пролете.

 

Теперь главный вопрос: как тебе это всё давать? У меня стоит правка скриптов, - похоже, уникальная

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

Затронуты несколько глобальных скриптов, добавлено несколько новых

[Shadowman 939]

Monnoroch, это из АМК2 от Рефреша, но переделанный под Соль. Функциональность увеличена в сторону удобства.

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

Фактически, получилась продвинутая версия предыдущего артмод_пда (в плане идеи).

 

Кстати, по поводу "безголовых" вылетов (когда последними оказываются строки вида "* [x-ray]: economy: strings[12028 K], smem[0 K]", - т.е. то, что в логе всегда присутствует после успешной загрузки сейва).

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

Например, совершенно безобидное на первый взгляд game.translate_string(секция) с неправильным именем секции как раз и вызывает безлоговый вылет. Другое дело, что это точно не единственная причина, но одна из вполне возможных. Задав по ошибке как параметр в этот game.translate_string ключ вместо значения из таблицы, я выяснил это абсолютно точно

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

Изменено 8 Марта 2010 пользователем Shadowman

[Shadowman 939]

Monnoroch, ну, я ведь не претендовал на полноту исследования - просто поделился наблюдением

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

 

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

 

-----------------

Monnoroch, нет, а чего, - получилось

передал ключ (цифровой) вместо стринга (значения). И фиг бы так просто нашел, если бы написал большой кусок кода, а потом тестить начал

Т.е. если был бы стринг, но неверный или пустая строка - был бы вылет с ругательством на несуществующую секцию, а раз интежер вместо стринга - то безголовый вылет - ты это имел в виду? Именно в конкретном примере.

 

Естественно, что везде проверки ставить даже вредно, но может в каких-то подозрительных местах имеет смысл (ведь именно это и поможет исправить ошибки)? Ясное дело, что речь об уже написанном ранее коде. И не сейчас написанном, а который уже "давно тут сидит"

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

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

Изменено 8 Марта 2010 пользователем Shadowman

[Shadowman 939]

Начало разговора - здесь

 

Ты не понял. Без зачёта-незачёта поршней на квесты у оживляемых невозможно оживить непись с набором нужных заданий, а таких поршенов - не так уж много, причём отслеживать нужно не все - а индивидуально по персам - погиб чел - сразу проверка - какие поршены получены( т.е какие задания выполнены), а какие нет. То, что неактивно - и выдавать

 

В смысле, что именно "выдавать", задания ? Если ты имеешь в виду, что спавнить нового непися с новым набором диалогов, по результатам предварительной проверки, был ли выдан поршень на смерть, то это адская работа. Это фактически будут уже "дублёры".

В оживлении Сяка не учтён только момент этих поршней на смерть.

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

Изменено 21 Марта 2010 пользователем Shadowman

[Shadowman 939]

gruber, да, именно это я и имею в виду.

malandrinus, я это делал "ручками" (ну, почти )

Есть табличка с именами профилей. Из аллспавн вытаскиваем номера их секций и стори-ид. Дальше - как у Сяка.

Табличка имеет вид:

-- формат: имя секции = {номер секции, сид}
atp_kalinin = {255, 9971},
generators_prizrak = {1380, 9984},
esc_wolf = {2148, 6}

Таблицу заполнял скриптом, имея на руках таблицу с именами секций и распакованный аллспавн.

 

...делал два одинаковых ИД игра вылетала...

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

Изменено 21 Марта 2010 пользователем Shadowman

[Shadowman 939]

Там сделано на основе варки артов - и ни к сидам, ни к номерам в алл спавне не привязано.

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

Да, и, кстати, вторую цифру (сид) в итоге я не использовал - только номер секции. А чтобы спавнить по имени - как раз и нужно дополнять спавн_секшионс.

 

Если он будет вариться через трансмутатор - оживлению Мухи - кранты

Arhara, почему? Поясни, пожалуйста.

Кажется, я неверно понял, какое инфо нужно давать в ф-цию as_start_universal_transform_timer. Сейчас туда дается инфопоршень на рецепт, а должен, видимо, поршень, прописанный в табличке рецептов рядом с компонентами и результатом. Блин, названо-то одинаково

Если так - то ты совершенно прав, и варка самого камня удачи тоже с тем же.

исправить несложно.

В скрипте amkII_transmutator.script в ф-ции CAmkTransmutacion:CreateAtrefact вместо строки

local info            = iInfo

пишем

local info                = aRecipts[iInfo]["info"]

Проверил, работает. Выдача рецепта "на халяву" теперь не сработает, но варить без рецепта трансмутатор не перестанет.

Внутри рецепта должен быть прописан поршень в виде

        info = "spawn_kamen_udachy"

 

Monnoroch, а разве биндер только у актора?

---------

А не может зависание биндера актора быть связано как раз с переводом его в оффлайн надеванием маскхалата?

Изменено 25 Марта 2010 пользователем Shadowman

[Shadowman 939]

шутка это была насчёт маскхалата, смайл там стоит =)

malandrinus, молодца! Я подколол - Мон повёлся

 

Monnoroch, надеюсь, не обидел? Извини, если что

 

Ясное дело - как раз у ГГ всё схвачено. А вот в остальных биндерах - скорей всего "есть параметры и функции, которые на этот механизм влияют" - иначе это было бы просто необъяснимо, как это вообще может работать.

Нетпакетный ПДА на этом построен. Если бы что-то не так было - фиг бы мы смогли метки тайников увидеть, например

... правда, он в инвентаре всё время, а значит, - всё время в онлайн, как и ГГ...

 

хз, как оно работает... но работает ведь!

 

Это поршен, который должен выдаваться при " ручной" варке (хотя он, очевидно, выдастся и в трансмутаторе) он и нужен для оживления или иного действия

Arhara, да, после правки, что я показал - и в мутаторе. Поршен будет выдан только если его нет у ГГ (один раз за игру).

Изменено 23 Марта 2010 пользователем Shadowman

[Shadowman 939]

сдох непись и в момент смерти имел некий набор инфорпоршенов

malandrinus, инфопоршены вроде только для ГГ, т.е. имею в виду, что неписям никаких поршенов не выдаётся

Может, ГГ имел некий набор поршенов, относящихся к этому неписю?

Насчёт диалогов у оживлённого - совершенно согласен.

для квестовых неписей досконально сохранять информацию об их квестах

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

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

 

далеко не во всех диалогах есть проверки на нужные условия

Arhara, логичнее выло бы отрихтовать в диалогах по выдаче / принятии квестов, чтобы не было нескладушек, чем шаманить при оживлении. Просто неважно, оживлён непись, или заспавнен нормальным путём - если в диалогах нет нужных проверок, работать будет одинаково неправильно что у оживлённого, что у оригинального

 

Виталий Зверь, а никто и не говорит, что не должно работать. Наоборот, проверки на смерть в основном у сюжетных квестовиков от ПЫС.

 

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

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

Изменено 26 Марта 2010 пользователем Shadowman

[Shadowman 939]

boboz, скачайте STALKER Icon Editor (SIE) - здесь на АМК (в редакторе уже все сделано для удобного редактирования файлов с текстурами иконок). В конфигах предметов прописаны координаты иконок, заданные из расчета квадрата 50х50 пискелей в файле ui_icon_equipment.dds. Старые видеокарты не в состоянии загрузить текстуру размером 4096х4096 пикселей целиком, потому и криво отображают иконки.

 

n6260, а отчего такое предпочтение GeForce-то? Любая видяха старого образца так себя поведёт

Сообщение от модератора n6260

Ну это на основе "исследований" Тирекса - он про джиФорсы писал

Изменено 20 Апреля 2010 пользователем n6260

[Shadowman 939]

Возможно ли использовать два файла с иконками, например ui_icon_equipment_1.dds и ui_icon_equipment_2.dds?

boboz, нет. Только замена основного.

Изменено 20 Апреля 2010 пользователем Shadowman

[Shadowman 939]

malandrinus, есть вопрос: параметр restrictor_type в аллспавн. Видел варианты 0,2,3.

Нашел только для restrictor_type = 2 - "эти рестрикты запрещают сталкерам ходить по кострам."

3 - вроде как какой-то экшен можно задать при попадании ГГ в него. С какой частотой запускается и как, например, её изменить - непонятно. Или только радиусом можно управлять? 0 - что значит и как работает не нашел ничего (кроме примеров в аллспавн ).

Смотрел на Вики, форумам по Сталкеру - разрозненно, все больше "как сделать то-то".

Ты не мог бы прокомментировать, если нетрудно?

Изменено 28 Апреля 2010 пользователем Shadowman

[Shadowman 939]

Kolmogor, спасибо, понятно. Не знал.

5 раз в секунду, значит...

Kolmogor, нашел скрипт ressurect.script - твой ("артефакт для воскрешения НПСов")?

Попробовал через апдейт оживление - не пашет. Трупик на секунду пропадает, потом снова появляется. И вижу по отладке, что в условии:

    local obj = level.object_by_id(id)
    if obj == nil then
        --dbg.log("RES: real move offline")
    else
        --dbg.log("RES: wait offline")
        return
    end

всегда срабатывает "wait offline". Вообще убрал эту проверку - заработало

Запускал, правда, используя oAmkLauncher:AddFunc. И без предмета - просто нахожу под ногами труп, беру его id, и его амк-скриптами того...

Что интересно, что вообще без пропускания через апдейт срабатывает. Иногда, правда, не с первого раза. Респект!

 

BUKER,

Увеличение точек неписей на миникарте:

 

Вот тут ссылка есть: http://www.amk-team.ru/forum/index.php?sho...st&p=432068

 

V92, способ не мой. Я проверил у себя - дал как вариант

Если оставить текстуру и изменить только размер - будет не то?

---------

я проверил, прежде чем давать - ничего не сбито, все отображается

Изменено 28 Апреля 2010 пользователем Shadowman

[Shadowman 939]

через 3 часа! игрового времени

sapsan, это фактически никогда

Обалдеть! Тогда уже если так - при выкладывании замка хотя бы, ну и при загрузке сейва.

Кстати, насчёт уборщика: можно ведь ограничиться неубиранием внутри зоны алайфа, а за её пределами - чистить как и раньше, как думаешь?

И еще: в геймдату одним файлом почему-то включён уборщик из адаптации под 1.0006

 

по уборщику - можно попробовать как ты говоришь

sapsan, попробовал и через апдейт и за а-лайфом. В первом случае не убирает нифига, во втором - вылетает в хр_мотиваторе на той строке, что как раз есть адаптация к 1.0006 (self.npc_script_version = alife():object(self.object:id()).script_version)

 

------------

Короче, по уборщику на патче 1.0006: пока выхода не вижу. Убирать будет все локи, кроме текущей - и точка.

Если категорически не подходит - играем на 1.0004 + уборщик от Соли 17.04. Все, что мог придумать - проверил, не работает иначе.

Изменено 29 Апреля 2010 пользователем Shadowman

[Shadowman 939]

game_graph():valid_vertex_id(obj.m_game_vertex_id)

sapsan, если перед размещением объекта проверять такое - то наверное таки да, будет толк.

А вот у уже существующего - к сожалению не проходит - вылетает с ругательством на тот же вертекс (это я про попытку отловить предмет с кривым вертексом, который уже есть на локе). Понятие вертекс для объекта, как я понял, существует только когда сам ГГ на этой локе.

[Shadowman 939]

..набор clsid без боеприпасов и гранат

sapsan, что-то боеприпасов я там и так не видел

Думаю, пойдёт (это ведь фактически что и было, но таблицы вместо elseif работать будут явно быстрее).

Кстати, если уж на то пошло, IsMonster() и IsStalker() тогда тоже без ифов нужно сделать

 

И еще: сделал такое наблюдение: хотя ф-ции выглядят так IsMonster (object, class_id), IsStalker (object, class_id), тем не менее, нигде не нашел, чтобы задавался второй параметр при обращении: везде передается обж. И при этом, обращений к этим ф-циям в скриптах - много, даже очень (IsStalker - более сотни, isWeapon, IsMonster - по неск. десятков)! Отсюда делаю вывод, что чем оптимальнее по скорости это будет срабатывать, тем больший выигрыш быстродействия мы сможем получить.

Изменено 16 Мая 2010 пользователем Shadowman

[Shadowman 939]

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

(убрано логирование: все равно отладку никто смотреть не будет, а строчки собираются + прямая вставка в таблицы)

Изменено 31 Мая 2010 пользователем Shadowman

[Shadowman 939]

malandrinus, спасибо, понятно. Про 1.0006 - вообще откровение. Теперь понятно, почему с переходом на апрельскую Соль народ отрапортовал про снижение производительности именно на 1.6 в сравнении с 1.4.

 

magnit, прям коллекция загадок Зоны какая-то.

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

 

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

Если твой игровой набор близок к оригиналу 19.04 - скинь сейвик вблизи гарантированного подвиса - просто интересно. Я думаю, что от компа все же сильно зависит (а точнее даже, мощности процессора).

 

magnit, Ок, спасибо, посмотрим.

ЗЫ: ну если Солянка "кладёт" уже и 3Ггц двухъядерник - тогда совсем плохо дело

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

[Shadowman 939]

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=продолжение по поводу этого способа решения зависа:]

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

Если прокатит - можно просто милли-патчик сделать.

Для проверки нужен сейв перед зависом (вылетом).

 

"Пробуем побороть завис"

 

0. Делаем копию ...S.T.A.L.K.E.R\gamedata\scripts\se_respawn.script для возможности восстановления.

 

1. В файле se_respawn.script в function se_respawn:create(prob) ищем строку

 

amk.on_REspawn(obj,self)

 

2. Перед этой строкой добавляем строку (строка будет выводить имена spawner->object в консоль красным, не смущайтесь, и в лог)

 

get_console():execute("load ~ Spawn now ["..tostring(self:name()).."] -> ["..obj:name().."]")

 

3. Больше ничего править не нужно - только добавить строку. Никакие проверки не нужны.

Сохраняем сделанные изменения, пробуем с сейва ДО зависа/вылета.

 

WhatAbout, хочешь сказать, что вывод отладочной строки в лог предотвращает вылет?

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

 

WhatAbout,

команда

get_console():execute("load ~ Spawn now "... означает, что ты пытаешься загрузить игру с именем, являющимся всем тем, что идет после "load". Поскольку такой сохраненной игры, ясное дело, - нет, в консоль и выдаётся "Cannot load saved game" а дальше - все то, что мы написали в этой отладке. Почему именно load ? Потому что в ругательство тогда выдаётся в точности та строка, которая была задана в качестве имени сохранения

Я думаю, что тут еще дело в том, что наша конструкция "<переменная>..<переменная>" собирается последовательно, во столько шагов, сколько есть присоединений "..". Если же просто написать стринг, полученная задержка будет меньше.

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

Например, level:name(), db.actor:id() или еще что-нибудь отвлеченное и точно существующее (game.time(), level.get_game_difficulty()).

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

 

 

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

[Shadowman 939]

Dennis_Chikin, этот спавн в meceniy_art нужно вообще переделать, потому что там несколько скользких моментов. Во-первых, там рандомное вычисление вертекстов зачем-то, да еще и без последующих проверок на валидность (в ogsm_surge - аналогично, кстати). Нужен просто набор выверенных координат и рандомный выбор между ними перед спавном. Сейчас - там для нескольких лок по одному левел/гейм вертексу.

В-вторых, если чего завесилось в биндере, никаких ошибок не выдаётся: просто молча вешается и всё (это особенность движка, нельзя там ошибок допускать).

 

ЗЫ: в ogsm_surge принципиально ничего не отличается - те же кривые моменты. И главное - проверки существования вертексов, полученных путём рандомайзеера - нет.

 

dimos, да в том-то и дело что этой строкой выводится лишь отладка в лог - прочти, что я написал в предыдущем посте.

 

----

WhatAbout, не думаю. Возможен только вылет в случае, если в строку попытаемся запихать переменную, которая нил

 

7.9, есть такой момент: при сохранении может, какая-то из функций, запускаемых при этом и приводит в чувство игру.

Может, даже простое высвобождение (или заполнение) памяти даёт такое эффект - кто ж его знает, как там внутри движка всё это варится

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