Скриптование

[Kirag 39]

antreg

Попробуй МНТ, план Б. Если не полчается комментировать, добавь тестовый вывод после... Ну, для начала, после каждого законченного фрагмента кода.

 

У меня для этого в _g.script есть функция:

function qqq(n,o)
    local scr = true
    local con = true
    if o then
        if o == 1 or o == 0 then
            scr = false
        end
        if o == 2 or o == 0 then
            con = false
        end
    end
    local k = "debug data QQQ "..tostring(n)
    if scr then
        if db.actor then
            news_manager.send_tip(db.actor, k, nil, nil, 5000) 
        end
    end
    if con then
        get_console():execute    ("load "..k)    
        get_console():execute    ("flush")    
    end
end

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

 

Расставь qqq("mark 1")...qqq("mark N") в функции check_spawn(), и после вылета посмотри, какое сообщение прошло последним. Проблема должна быть между последним сработавшим qqq и следующим за ним. Так ты хотя бы область поиска сузишь. Потом можешь в этом фрагменте поставить qqq почаще, может, с точностью до строки найдешь проблему...

[Kirag 39]

PavelSnork

 

Вот так:

local ar = device().aspect_ratio
if ar <= 0.75 then
-- WIDE SCREEN
else
-- NORMAL SCREEN
end

[Kirag 39]

Desertir

Функция on_item_take(obj) в bind_stalker запускается при попадании предмета в инвентарь актора любым способом - будь это подбор предмета откуда-либо, патроны из разрядки оружия, прямой спавн в инвентарь либо что-то еще.

При подборе из трупа, соответственно, сработает тоже, НО этот случай никак не будет выделяться из всех остальных. Если сильно надо, чтобы какое-то действие запускалось только при подборе из трупа/ящика (разделить эти два момента - по-моему, никак, инфопоршень один), добавь дополнительное условие

if db.actor:has_info("ui_car_body") then
...
end

 

Функция take_item_from_box(box, item) работает только при взятии предмета из тайника, работает с тайником и для твоих целей бесполезна...

[Kirag 39]

KD87

А нужно ли здесь

    if not has_alife_info("bla_bla") and
        db.actor:object("item_222") then
        db.actor:give_info_portion("bla_bla")
    end

 

делать проверку db.actor:object("item_222") ?

Я же так понимаю, что при этом в неявном виде перебирается инвентарь? Если проверка такая одна, и хлама мало, так и черт бы с ним, а если их много, а в инвентаре хлама вагон? Или я ошибаюсь насчет перебора?

В любом случае, подобранный объект передается в on_item_take(obj), и можно написать просто

    if not has_alife_info("bla_bla") and obj:section() == "item_222" then
        db.actor:give_info_portion("bla_bla")
    end

 

Это к тому же исключит такую ситуацию:

Допустим, объект с секцией "item_222" уже есть в инвентаре, а инфопоршень не выдан/убран (в соответствии с замыслом), и его надо выдать при подборе еще одного "item_222".

В твоем варианте будет ложное срабатывание на подбор вообще любого объекта - db.actor:object("item_222") вернет true при описанных условиях. У меня проверяется именно только что подобранный объект, а не есть ли в инвентаре такой же...

 

[Kirag 39]

KD87

С НПС - не знаю, а db.actor:accuracy() используется, например, при определении, целится ли актор в принципе:

if db.actor:accuracy() < 0.0001 then
--целится
end

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

if device().fov < value then
--целится с оптикой
else

[Kirag 39]

Plotnick

Ну, например такая концепция:

Можно, например, сделать game_object - тот же блокнот. Повесить на него биндер, который кроме сейв/лоада ничего не делает.

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

Кстати, блокнот не обязятельно должен быть единственным, главное не разбивать данные по бессмысленным частям - не писать в один блокнот Х, а во второй = 1

[Kirag 39]

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

 

[Kirag 39]

serega-gamer

 

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

Ты выложил здесь текст какого-то файла, значит искать надо строку "имя_этого_файла" по всем другим файлам источника. Так ты увидишь где прописаны вызовы функций из этого файла.

[Kirag 39]

serega-gamer

 

Попробуй в апдейт актора вписать имя_файла.autohealing() Есть шансы, что хоть как-то заработает, без кучи проверок. НО вообще-то все тут адаптировано под ОГСЕ, чем все и сказано... Слишком много отсылок к функционалу ОГСЕ, чтобы это быстро сложилось.

 

P.S. Целых пять знаков препинания, и четыре из них восклицательные. Ты сам-то пробовал прочесть и понять этот неформатированный поток сознания?

[Kirag 39]

Как заставить пистолет переместиться из слота в рюкзак?

 

local obj = db.actor:item_in_slot(1)
local sect = obj:section()
local id = obj:id()
db.actor:drop_item(obj)
local temp = alife():create(sect,vector(),0,0,db.actor:id())
db.actor:transfer_item(obj,db.actor)
alife():release(temp,true)

Если сильно хочешь, в alife():create вместо vector(),0,0 поставь валидные координаты актора, но вообще - прокатит и так, проверено.

[Kirag 39]

*Shoker*

Чтобы предмет не вернулся в слот.

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

[Kirag 39]

PavelSnork

Лучше проставить скобки в подобных случаях - так ты будешь точно уверен, что поймет как нужно, а не как получится. Для твоих целей - вот так:

if (db.actor:health > 0.1 and db.actor:health < 0.2) or (db.actor:health > 0.5 and db.actor:health) < 0.6 then

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

[Kirag 39]

Ulman

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

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

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

[Kirag 39]

Ulman

Должен тебя расстроить - именно по всем биндерам. Только апдейтом и только актора дело не обойдется.

Нужны еще как минимум net_spawn и net_destroy - а вдруг вылет происходит в момент перехода чего-то неизвестного в онлайн/оффлайн? Кстати, и эффект будет рандомного вылета - неизвестно, что это и где, когда ему взбредет в голову перейти в онлайн, да и от актора это не зависит.

Также не помешают функции save и load - возможно, при загрузке объекта ему прописывается какая-нибудь ахинея, со всеми вылетающими.

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

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

 

Кстати, насчет переиграть с более раннего сейва и/или с НИ - идея толковая. Это технически проще (можно бессмертие поставить, чтоб сильно долго не было), и вероятность конкретного битого сейва ты исключаешь.

[Kirag 39]

Artos

 

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

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

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

 

Вариант

section = "bandit_outfit" -- дефолтный вариант без разговоров
if string.find(vis,"stalker_bandit_veteran") then section = "bandit_veteran_outfit"
elseif string.find(vis,"stalker_bandit_master") or string.find(vis,"stalker_bandit_borov") then section = "bandit_master_outfit"
elseif string.find(vis,"stalker_bandit_exoskeleton") then section = "exo_bandit_outfit" end

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

 

А по хорошему, стОит внести все визуалы в таблицу вида визуал = секция, и выбирать оттуда. А такие проверки оставить как план Б, на случай отсутствия визуала в таблице - новая модель, например...