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

[Okichi 922]

22 минуты назад, dsh сказал:

NLC, к примеру, понятия не имею, как оно будет, что там переписали и поменяли. 

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

[Okichi 922]

15 часов назад, mole venomous сказал:

Есть ли какой скриптовый способ запретить НПСам НЕ брать конкретный предмет с земли и/или трупа/ящика?

Есть, примеры можно посмотреть в репозитории по dsh-mod на Githab.  Или в репозитории от Den1s'a там же ( вариант той же фишки для НЛС ).
Суть в том, что объекту в конфиг прописывается новый ключ, который задает то самое "руки прочь".
В ДШ-моде это 
watcher_act.bad_item = true

Ну и соответственно:
1) в watcher_act (онлайновое воровство - трупы/земля) - добавить чтение и обработку этого ключа
2) в amk_offline_alife - аналогично.

Способ проверен, все  работает.

Изменено 9 Декабря 2019 пользователем Okichi

[Okichi 922]

@Norman Eisenherz, нужный коллбэк вроде как в xr_motivator.script

[Okichi 922]

3 часа назад, aka_sektor сказал:

как зная id из вылета, найти объект с таким id?

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

[Okichi 922]

1 минуту назад, Zander_driver сказал:

А если вот такой вылет возникает, то как раз и будет поймана эта пара до исчезновения чилда, до вылета,

Дело в том, что на момент, когда мы стали ловить этот вылет, объекта-потомка с таким id в игре УЖЕ не было. 
Конечно же, он наверняка существовал N сэйвов назад, но у нас этих N не было, а были последние несколько - и в них объекта-потомка с таким id не существовало тоже.
Поскольку вылет такой случался при автосэйве (переход с локи на локу) и только  в нем - а автосэйв при этом на другой локации создавался нормально, то дальше не копали.
 

[Okichi 922]

22 часа назад, aka_sektor сказал:

Парадокс

Ну вот выше Зандер_драйвер дал схему, как можно попробовать обнаружить. Искать по предыдущим сэйвам, в которых этот объект-потомок еще существовал.
Но иногда в некоторых модах сразу при НИ запускается удаление ненужных объектов ( то, что есть в аллспавне, например, но реально не требуется в игре). 
Тогда, если этот чайлд вот так, с НИ, удалили - то уже не найти. Тем более, что узнаем мы об этом ( получим вылет)  только тогда, когда придем на локу, где этот удаленный объект находился.

И то - не сразу, а когда будем там перегружаться или переходить на другой уровень:  вылет будет при разрушении уровня, т.к., если я правильно поняла dsh-а, при разрушении уровня игра сначала пытается удалить "потомков", и только потом - их парентов. 

[Okichi 922]

@aka_sektor, это попытка выполнить ф-ю release_npc, когда получаем поршень ops_quest_taked.
Надо проверить, существует ли эта ф-я в xr_effects.script. 
 

[Okichi 922]

@phalcor, Похоже, что здесь, когда лагерь переходит в состояние 0 и неписи получают соотв. работы - им на этих работах запрещено переходить  в онлайн. Вот они и "пропадают". 
Возможно, что в момент гибели _всех_ наймов у актора забирают поршень "escape_lager_spawn_killers" - и поэтому трупы наймов снова сразу уходят в оффлайн.

Но состояние 2  - это если все _сталки_ в лагере убиты, и тогда наймы пойдут и займут их место.  Но вот это для состояния 2  выглядит странно - не знаю, как может быть _меньше нуля_ количество НПС в лагере )   Даже если это "пришедших" посчитали.

4 часа назад, AndrewMor сказал:

xr_gulag.getGulagPopulationComed("esc_lager") <= 0

 

Изменено 5 Июня 2020 пользователем Okichi

[Okichi 922]

@DibokDibokin, если используются модули Артоса, то да.
Заспавнить ящик с заранее заданной кастомдатой.
Как-то так: 

if sobj then
		local pk = get_netpk( sobj,1)
		ASSERT( ( pk and pk:isOk() ), "can't read netpacket of %s", sobj:name() )
		local data = pk:get()
		data.visual_name = "physics\\box\\box_wood_01.ogf"
		data.custom_data = custom_data_for_woodbox
		data.mass = 10
		pk:set(data)
	
end

Здесь custom_data_for_woodbox - это определенным образом отформатированная строка с перечнем предметов, которые должны оказаться в ящике при его разбивании.
Например 
custom_data_for_woodbox = "[drop_box]\ncommunity = def_box\nitems = вот здесь идут собственно названия айтема, запятая, количество"

Изменено 18 Июня 2020 пользователем Okichi

[Okichi 922]

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

Увеличение set_range( new_value ) отрабатывает, а вот на set_fov() никаких изменений отладка не показывает.

И второй вопрос - параметр "освещенности" ( luminocity_factor ) для мутантов вообще скриптами можно менять?

[Okichi 922]

2 часа назад, Jekyll сказал(а):

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

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

Ну разве что там есть еще какие-нибудь физобъекты, которые эта аномаль будет зашвыривать туда, куда им не надо )

[Okichi 922]

3 часа назад, Купер сказал(а):

И ведь не поправит никто. Все сидят

Ну откуда же нам знать - может, у человека этот obj глобальный. Там еще неплохо бы убедиться, что это именно клиентский объект получен, т.к. емнип, у серверных это читается через section_name(), а :section() - для клиентских.

А во-вторых, @ted.80  - как раз на один такой пример указал, там уже и ежики догадаются )
По-хорошему - неплохо бы  _в начале_  функции проверять даже наличие и тип переданных  в нее параметров.
И на время отладки - все это в лог выводить. 
Мало ли - может передается совсем не то, что ожидается. 

[Okichi 922]

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

[Okichi 922]

@AndreySol а в оригинальном движке из скрипта нельзя получить параметры сытости, например?
Если возможно, то так-то ведь никто не запрещает получить этот параметр, и после "полноценного" приема аптечки и завершения эффекта ее действия  чутка испортить актору здоровье в зависимости от выше полученной "сытости"? Ну костыль, конечно, но если вариантов других нет, то...
Или есть противопоказания? 
 

[Okichi 922]

@AndreySol Если берется имя из аллспавна - его в кавычки нужно

local s_obj = sim:object( "light_uglovaya_1_glass_0006" )
И вот что-то не уверена, что можно так удалять источники света. Для physic_object и physic_destroyable_object - сработает, для источника света - вопрос...
 

[Okichi 922]

@Zander_driver у меня совершенно точно какие-то источники света удаляться отказывались ) т.е. лампочки нет - свет есть.

[Okichi 922]

6 минут назад, dsh сказал(а):

ампочка может вообще не быть объектом, а нарисована на стене. 

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

@gam зачем перебор по id, если известно точное имя объекта из аллспавна. Имхо, не нужен совсем.

[Okichi 922]

@I am Dead  для  добавления кровотечения -  например нанести доп.хит с типом "chemical_burn".  Пример посмотреть можно  в нлс-ишном bind_monster.script.
 

Изменено 23 Февраля 2021 пользователем Okichi
1

[Okichi 922]

1 час назад, ARTLantist сказал(а):

я спавню актору в инвентарь предмет, и мне нужно тут же именно ему изменить condition

Теоретически вот такое должно работать и на стандартном движке с использованием модулей Артоса для нетпакетов:

local obj  = misc.spawn_to( "af_dummy_battery", db.actor )  -- заменить на обычный alife():create() актору в инвентарь
local objd = alife():object( obj.id ) -- лучше получим созданный серверный объект еще раз
local pk = get_netpk( objd, 1 )
ASSERT( ( pk and pk:isOk() ), "can't read netpacket of %s", obj:name() )
local data = pk:get()
local cond = lua_random( 25, 35 ) * 0.01 -- заменить на какую-нибудь ф-ю вычисления рандомного значения,  lua_random - специфика НЛС
data.condition = cond  -- устанавливаем новую кондицию серверному объекту
pk:set( data )

-- и вот тут движок дожидается выхода в онлайн клиентского объекта и уже ему правим кондицию в инвентаре
level.client_spawn_manager():add(
    obj.id, -1,
    function( id, obj )
        obj:set_condition( cond )
    end
)
Метод в свое время подсказал dsh, и он ни разу не подводил ( кроме единственного уникального случая спавна брони в инв.ящик, которой в НЛС так кондицию не испортить)

Изменено 20 Марта 2021 пользователем Okichi

[Okichi 922]

33 минуты назад, _Sk8_AsTeR_ сказал(а):

у него в логике прописан параметр smart_terrain = false

Если непись спавнится с заранее заданным  в кастомдате смартом - то он и так никуда из этого смарта _сам_ не уйдет. В этом случае его логика определится логикой смарта.

Если непись спавнится как "свободный", с персональной логикой  - то чтобы его сразу при спавне не забрал какой-нибудь смарт, у него _ в кастомдате ( NB!  а не в логике ) должна быть секция:
[smart_terrains]
none = true

Это, конечно, для немодифицированных скриптов. В модифицированных схемах все может работать совсем иначе )
 

Изменено 6 Июля 2021 пользователем Okichi