dsh

В OGSE работает. Ну и в моем моде тоже, т.к. оттуда взято. Оригинальных скриптов на то, что ты хочешь, нету. Свое писать надо. И высоту прыжка не сделать даже с x-ray extensions, только если самому движок пересобирать.

@TIGER_VLAD, не, ты не повторяешь вопрос. Ты спрашивал о каком-то "правильно расчитать хит", что бы это не значило. А тип хита можно определить в коллбэке, который вызывается перед обработкой хита. См. вот тут: https://code.google.com/p/xray-extensions/wiki/new_collbacks информацию о 152. Пример использования можешь посмотреть тут: https://github.com/dsh2dsh/op2ogse/blob/master/gamedata/scripts/dsh_art_degrad.script в функции before_hit.

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

Мне не верится в скриптовую утечку по одной причине. Виртуальная машина после каждой загрузки пересоздается и все, что у ней утекло, должно освобождаться или, по крайней мере, переиспользоваться. Конечно и тут могут быть свои грабли, кто их, пейсателей знает. А вот что мне кажется более вероятным, так где-то память просто не переиспользуется. Ладно оно в систему ее не отдает, это нормально еще. Но чую я, что каждый игровой объект дописывается в какую-то кучу линейно. Эта память не только не освобождается, но и не переиспользуется. Такое вот ощущение. Пришли мы на эту локацию повторно, так мало того, что память занята этим же неписем с прошлого раза, так для него еще выделяется новая и т.д. снова и снова. Память течет жутким образом. Перехожу с АС в Бар и обратно несколько раз и каждый раз смотрю в диспетчере задач размер процесса. Каждый переход прибавляет сотню мегабайт. Притом это зависит от кол-ва неписей в онлайне на момент перехода.

@Dennis_Chikin, цифр нехватающей памяти нет вообще. Чаще всего есть только Это процесс отожрался где-то до 3.5 гигов. Тоже самое будет и без принудительного держания в онлайне неписей, но гораздо позже, может часов через 5 игры. А тут 2.5 - 3 часа и вылет.

Не, это не ответ. Вопрос-то в том, что такого в онлайновых объектах, что запись их в сейв вызывает утечку памяти. Цитат из моего вопроса а потрындеть я и сам могу. А что прикидывать, маленькая эта локация. В онлайне там примерно 42 непися. Не сказать, что слишком много.

Может у кого дельная мысль будет. Провожу эксперимент. На локациях Бар и Армейские склады держу принудительно в онлайне почти всех неписей. Всех их по пути посещаю, обратите на это внимание. Через некоторое кол-во переходов получаю вылет по нехватке памяти. Теперь перестаю держать их в онлайне, но по прежнему, всех и посещаю по пути, т.е. все они в онлайн выходят, правда и уходят из него. Вылета по нехватки памяти нет. Вопрос, где же в первом случае утекает память?

Просто замечание, а то вижу многие так ошибаются. В ОП-2 фонарь ни на что не влияет. Включен он или выключен, заметность или не заметность от этого не меняется. Для неписей света фонаря просто не существует.

Держи https://yadi.sk/d/xrQa6lyCkzyvG

Меня уже спрашивали, но это не имеет смысла. Человеку нужно сделать все за него.

@RayTwitty, просто мысль: может какой скрипт хит такой наносит, по факту выстрела?

Для этого существует git. Не именно для того, что ты описал, а для получения изменений в свой, локальный репозиторий. Проще говоря, вместо того, что ты написал, нужно выполнить git pull и все.

Ох, похоже тут опять мифы обсуждают. job_position_threshold - это расстояние, при котором считается, что моб в оффлайне пришел к месту работы и ему можно назначать логику. Если это расстояние сделать слишком маленьким, то логика мобу не будет назначена. В качестве примеру приведу Барьер на Складах и значение 120 из ОП-2 (из Солянки, полагаю, тоже). К этому нужно заметить, и это, похоже, все то-ли не знают, то-ли упускают из вида. Мобы в оффлайне про логику и пути понятия не имеют. Это все только в онлайне работает. А в оффлайне моб всегда идет на точку смарт террейна. Его туда движок гонит. Вот для этого и используется упомянутое выше расстояние. Что бы xr_gulag мог определить, что моб дошел. Так вот, про Барьер и ОП-2 (вероятно и про Солянку). Идя на Барьер мобы прекращают свое движение на расстоянии большем, чем 120 метров от смарта. Это приводит к тому, что соотв. логика мобам не назначается и когда игрок подходит к свободовцам, что там стоят, все мутанты вываливаются в онлайн на этом месте. На самом же деле, мутанты должны быть около перехода на Радар и атаковать свободовцев оттуда, а не сваливаться им на голову. Далее, can_choose_alife_task() не запрещает мобу идти к месту работы. Оно вообще к работам и логике прямого отношения не имеет. Эта функция управляет тем, будет-ли движок пытаться определить данного моба в какой-нибудь смарт террейн или нет. Если разрешено, то движок пойдет в цикле по всем смартам и каждый будет спрашивать: этого возьмешь? На самом деле не так прямо, но в данном случае это не важно. И вот когда движок закрепит моба за каким-то смартом, моб пойдет на точку этого смарта. И только дойдя до туда и выйдя в онлайн, ему xr_logic назначит онлайновую работу. Как только моб уйдет в оффлайн, движок опять погонит его на точку смарта и т.д.

Уверен на 99%. 1 процент оставляю на то, что чего-то в коде не заметил. Кто-то тут спрашивал по поводу min/max_radius. Я, хоть убейте, не могу найти, что бы эти параметры использовались в движке. Они читаются, но на этом все. Больше никакого использования найти не могу.

С абсолютной уверенностью ответить не могу, но в исходниках встречал и у меня осталось впечатление, что эти параметры используются, как описано. Это про два, приведённых выше параметра, изменяющих зрение. Ох этот неудобный мобильный интерфейс. В секции глушителей параметры называются по другому. Выше уже показали.

То, что я привел в качестве примера, не используется и не читается. Параметры глушителей берутся из секции глушителей.

Именно так, но только для ГГ. Т.е. параметры PDM_ из секции оружия умножаются на параметры этого оружия. Но опять таки, только в том случае, если из этого оружия стреляет ГГ. Для неписей PDM из секции оружия не учитывается, а учитываются disp_ из секции непися. Всем. Чего вы гадаете, ну откройте исходники да посмотрите. Заодно от кучи мифов избавитесь, типа silencer_hit_power = 0.56 silencer_hit_impulse = 42 silencer_fire_distance = 100 silencer_bullet_speed = 435 в секциях оружия.

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

Я сейчас глянул исходники и мне сдается, что PDM_ в секции оружия действует только на ГГ.

это более общий вариант, поэтому, что бы ничего работающего не сломать, убедиcь, что у всех мутантов прописано правильное community.

Конечно, ты же в смарте написал "dog_two", а в таблице "dog". Это таблица используется для перевода clsid в человекочитаемый формат, что бы значение потом сравнивать с тем, что указано в описании смарта. В твоем случае, т.к. ты хочешь более сложных правил, а именно, что бы указанный смарт принимал не всякую собаку, а только ту, у которой в секции указано "community = dog_two", нужно уже свою логику добавлять. Например вот так: function se_smart_terrain:get_obj_community( obj ) local cls = obj:clsid() if cls == clsid.script_stalker then return obj:community(), true else local comm = get_string( obj:section_name(), "community" ) if comm == "dog_two" then return comm, false else return monster_classes[ cls ], false end end end Или вообще вот так function se_smart_terrain:get_obj_community( obj ) local cls = obj:clsid() if cls == clsid.script_stalker then return obj:community(), true else return get_string( obj:section_name(), "community", monster_classes[ cls ] ), false end end Решать тебе. А может еще как-то более замороченно. Результат get_obj_community просто сравнивается со значениями из communities смарта и если совпадает с одним из этих значений, моб принимается в смарт, если другие условия тоже совпадают. Т.ч. никакой магии, возвращай из get_obj_community все, что тебе нужно и так, как тебе нужно.

Данный код не интересует коммунити твоих собак. Грубо говоря, если у тебя в смарте указано communities = dog и в smart_terrains.script [clsid.dog_s ] = "dog", то в этот смарт будет принят любой мутант с clsid == dog_s. По сути, смарт принимает к себе не по коммунити, которое указано в секции моба, а по clsid. Тот код, он просто для человекочитаемого вида. Я предполагаю, что ты используешь generic_lair. Иначе, ко всему этому, еще действуют правила конкретного гулага. generic_lair примет всех, кого примет смарт.

@HellRatz, т.е. у тебя собаки, имеющие один и тот-же clsid, имеют разные community? Тогда ты ничего не сделаешь, не меняя smart_terrains.script. Он расчитан на то, что один clsid будет иметь одно community.

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

@RayTwitty,спасибо Кэп Именно этот модуль я и использовал. Никакого эффекта. В OGSE он не используется, т.ч. я даже не могу быть уверен, что в нём нет каких-нибудь ошибок или неточностей.