[SoC] Ковыряемся в файлах

[Dennis_Chikin 3 658]

Ковыряемся в файлах ТЧ

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

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

[IQDDD 5]

В NLC надо смотреть файл scripts\amk_hideouts.script

В нем перечислены все укрытия и их описания. Синтаксис таков:

<Название локации>={
[<Номер точки для данной локации>]={
aviable=true/false, --значение не понятно и нигде не используется
defence=number, --на какое значение будет умножаться хит. по умолчанию = 0
community="string", --какая группировка будет слетаться на это место. по умолчанию - все
center=number, --центр зоны, level_vertex. (сначала неписи будут находить, к какому ближе идти center, а потом будут выбирать ближайший из entrances). Если не указать, то зона будет только для actor'а
entrances=table, --таблица вида {number,number,...,number}. level_vertex, куда именно будут слетаться нпс
zone=table --таблица вида {tabe,table,...,table}. Второе table - это таблица вида
-- p1={number,number,number}, --своего рода вектор.
-- p2={number,number,number}, --своего рода вектор.
-- p3={number,number,number}, --своего рода вектор. не обязательно!!!
-- суть в том, что координаты actor'а должны находиться между координатами векторов p1 и p2. Т.е. если представить p1={x1,y1,z1} p2={x2,y2,z2}, то x,y,z - координаты actor'а должны удовлетворять условиям x1<x<x2 либо x2<x<x1. И также с y и z. Зачем p3 - не знаю.
},

 

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

TRAMP14, при взятии или открытии? Если при взятии, то какой смысл? Если при открытии, то вы точно хотите монстра среди в лагере ученых?

 

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

ak74juncky, это сделать нельзя.

Изменено 10 Января 2011 пользователем IQDDD

[Batment 0]

как сделать чтоб в определенном трупе лежал определенный предмет ?

[IQDDD 5]

Обычно также возникает задача заставить не спавниться лут в данном трупе. Тогда надо в его custom data'е прописать секцию [dont_spawn_loot]

[TRAMP14 1]

Проблема (опять) - созданные мной предметы (которые надо сьедать) не используются. Т.е. нажимаю на предмете "Использовать" и ничего не происходит. как исправить?

 

TRAMP14, при взятии или открытии? Если при взятии, то какой смысл? Если при открытии, то вы точно хотите монстра среди в лагере ученых?

Что?

Гдето сылшал (мож в каком моде было) что активируя капсулы, на месте активации через какоето время появляется монстр или монстры. Хочу такое реализовать только время поставить дня на 2

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

[Ulman 5]

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

 

 

Такая вот проблема, скажите как исправить. Заранее спасибо :ny_happy:

[Полтергейст 37]

За это время очень много интересного нарыл.

 

Что сделал:

Для smart_terrain мне удалость сделать состояние тревоги (работы подгонял по предикатам соответсвтенно), как в ЗП, и запретить прописку NPC из враждующих группировок в один смарт.

Со smart_terrain_id() для NPC и "потерей из виду" функции initialize_if_needed() тоже почти разобрался.

 

Но остался непонятен вопрос - откуда идёт спавн NPC группировок, указанных в поле communities для смарта? Кто знает? А то как-то некрасиво получается, когда в одном смарте спавнятся враждующие НПС, да ещё и в немалом количестве. Респавны я совсем удалял из all.spawn - от них это не зависит.

 

Кстати, насчёт "немалого количества". Именно из-за него у меня стали чаще проявляться вылеты из-за state_mgr как с логами, так и без них. Подозреваю, что проблема в evaluator'ах, но их слишком много, чтобы можно было так просто разобраться. Если кто-нибудь поможет мне доработать state_mgr из ЗП, то мне весной уже можно будет выкладывать свои исправления для AMK + NLC 5.1, если не случится ничего непредвиденного...

 

 

 

Dennis_Chikin

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

Если can_switch_*() вызывается реже, чем update(), то можно попробовать засунуть все вызовы cse_alife_*.can_switch_*() в update() и сохранять в переменную, а в скрипте для функции задать возвращение этой переменной вместо вызова cse_alife_*.can_switch_*().

 

В противном случае надо принудительно уменьшать частоту вызова этих функций (примерно так, как сделано в обновлении restrictor'ов в биндере игрока) из update(), что тоже реализуемо.

 

P.S. насчёт обхода аномалий: я не знаю, что случилось, но у меня, похоже, ВООБЩЕ перестали работать методы add_restrictions и remove_restrictions. Как и почему такое могло произойти - тоже понять не могу.

Изменено 12 Января 2011 пользователем Полтергейст

[antreg 178]

Добрый день!

В Сталкере ТЧ необходимо увеличить расстояние, на котором НПС начинают видеть монстров. По умолчанию, движущийся в определённую точку НПС начинает замечать мутантов и, соответственно, реагировать где-то за 10 метров до них. Где можно в конфигах увеличить расстояние для того, чтобы НПС начинали замечать мутантов и переходить в боевое состояние метров за 50.

В файлах типа m_stalker.ltx (папка: \gamedata\config\creatures), в которых есть такие строки, как:

 

;---VISIBILITY--------------------------------------------------------

vision_danger_section = stalker_vision_danger

vision_free_section = stalker_vision_free

eye_fov = 110;120

eye_range = 80

 

[stalker_vision_free]

min_view_distance = 0.4 ; коэффициент, который множится на eye_range, в зависимости от угла

max_view_distance = 0.8 ; коэффициент, который множится на eye_range, в зависимости от угла

visibility_threshold = 150.0 ; значение, при достижении суммой которого объект считается видимым

always_visible_distance = 0.1

time_quant = 0.005

 

[stalker_vision_danger]

min_view_distance = 0.7 ; коэффициент, который множится на eye_range, в зависимости от угла

max_view_distance = 1.0 ; коэффициент, который множится на eye_range, в зависимости от угла

visibility_threshold = 120.0 ; значение, при достижении суммой которого объект считается видимым

always_visible_distance = 0.2

time_quant = 0.001

 

;---ENEMY------------------------------------------------------------

ignore_monster_threshold = 0.0 ;0.6 ;0.8

max_ignore_distance = 15.0

panic_threshold = 0.02

 

 

Возможно, что-то из этого нужно править. Кто знает, подскажите, пожалуйста.

[Полтергейст 37]

Поглядите в xr_danger.script

[Roman82 4]

Друзья! Подскажите пожалуйста как ограничить количество клеток в инвентаре ГГ? То есть вместимость. Сделать допустим 40. Еще интересует поедание пищи и водки за несколько заходов, не сразу.

[Полтергейст 37]

Возьмите restriction_stock из AMK и пропишите точно также. Только желательно вместо таблицы для каждого названия секции сделать подсчёт объёма по ef_weapon_type и ef_outfit_type для оружия и броников. Для еды и аптечек по классу задать объём равным 1.

 

Если не можете - сойдёт и так, как сделано в АМК.

Изменено 13 Января 2011 пользователем Полтергейст

[_Val_ 2 225]

antreg, попробуй сравнить с m_stalker_sniper.ltx . Снайпера они позорчее ведь. Например там

ENEMY

ignore_monster_threshold = 0.3

max_ignore_distance = 200.0

min_ignore_distance = 200.0

panic_threshold = 0

[n6260 150]

Всем добрый вечер. У меня такая вот проблема, во время тумана

Такое было в нескольких погодных модах и это фиксили. Тока вот как именно не помню в упор.

[amik 253]

_Val_ наверное прав. В m_stalker.ltx max_ignore_distance = 15.0 можно попробовать увеличить до 50 м, и посмотреть что будет. Не пробовал?

Ждем мод

[n6260 150]

Конечно нужно. Вызов функции как минимум. В скрипте прописано у чего какой объем. Кстати, есть немного доработанная версия объема - смотрите тему http://www.amk-team.ru/forum/index.php?showtopic=1377

[Полтергейст 37]

Не везёт так не везёт

 

С переносом результатов выполнения функции cse_alife_*.can_switch* ничего не получается - вылет без лога. Вот код из se_monster:

 

function se_monster:__init (section) super (section)

...

self.can_switch_on = false

self.can_switch_off = false

self.next_on_sw_upd_time = -1000

self.next_off_sw_upd_time = -1000

...

end

...

function se_monster:can_switch_offline ()

local time = time_global()

if self.next_off_sw_upd_time < time then

self.can_switch_off = cse_alife_monster_base.can_switch_offline(self)

self.next_off_sw_upd_time = time + 2000

end

...

end

...

 

 

 

Для can_switch_online() сделал аналогичным образом. Вызовы cse_alife_monster_base.can_switch_* в скрипте se_monster заменил на запрос self.can_switch_*. Для сталкеров всё делал точно также. Пробовал засунуть это в update - тот же результат. Что я делаю не так?

[IQDDD 5]

что вы пытаетесь сделать-то вообще?

[Полтергейст 37]

Хочу избавиться от вылетов из-за переполнения стека, которое иногда возникает, если в онлайне много NPC. На одной из предыдущих страниц мне подсказали, что надо копать в сторону функций can_switch_*() и по возможности заменить их переменными, вроде как количество вылеты из-за переполнения стека должны если не исчезнуть, то хотя бы уменьшиться.

Изменено 13 Января 2011 пользователем Полтергейст

[IQDDD 5]

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

function manager:update(delta)

self:update()

end

[Roman82 4]

Подскажите пожалуйста где в скрипте спального мешка от АМК значение на ограничение количества часов сна в день. Никак не могу найти. Заранее благодарю.

[Полтергейст 37]

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

 

Не обязательно "сама себя". Насколько я понял, достаточно, чтобы функция многократно вызывалась за короткий промежуток времени не важно откуда. Такое я случайно спровоцировал, когда эксперементировал с добавлением restrictor'ов, хотя никакой рекурсии не было.

 

Сначала я думал, что если игра ругалась на state_mgr, то в нём собака и зарыта, но вчера сам видел, как перед вылетом npc начинают то исчезать, то появляться снова - т.е. скакать из онлайна в оффлайн и обратно. Учитывая, что can_switch_* вызывается раз в секунду, то скорее всего такие глюки при большом скоплении npc именно из-за этого. А это уже тянет за собой частый вызов net_spawn() и net_destroy() для биндера, к которому как раз "приделан" state_mgr, вот мы и имеем то, что имеем...

Изменено 14 Января 2011 пользователем Полтергейст