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

Artos · 16 Апреля 2012

AndreySol, не говори ерунду. object_flags - исходно присутствует в любой версии ACDC и в любой распаковке all.spawn'а.

Вместо засорения топика-справочника по функциям и методам, лучше бы поискал там информацию на эту тему.

И это строго говоря не параметр (само назване flags говорит об этом), а массив который включает в себя множество флагов, каждый из котоых может так или иначе "влиять на объект".

Так же на форуме можно найти информацию от Malandrinus'а и KD87

Флажок                   двоичное дес.  Функция-аксессор *  назначение
======================================================================
flUseSwitches       0000000000001    1                      используется только редактором level editor из SDK и отвечает
                                                            за видимость в редакторе флажков flSwitchOnline и flSwitchOffline
flSwitchOnline      0000000000010    2 can_switch_online    возможность перехода в онлайн 
flSwitchOffline     0000000000100    4 can_switch_offline   возможность перехода в оффлайн 
flInteractive       0000000001000    8 interactive      **  Такое ощущение, что ни на что не влияет
flVisibleForAI      0000000010000   16                      используется на клиентской стороне, в частности для зон 
                                                            отвечает за возможность реакции на контакт
flUsefulForAI       0000000100000   32                      кроме участия в interactive имет смысл для инвентарного предмета,
                                                            в частности, влияет на торговлю
flOfflineNoMove     0000001000000   64 move_offline         по идее должен отвечать за отсутствие движения в оффлайне, но не используется
flUsedAI_Locations  0000010000000  128 used_ai_locations*** При спавне будет привязан к сетке, при наличии таковой под объектом. 
                                                            Иначе будет создан в воздухе.
flGroupBehaviour    0000100000000  256                      неизвестно
flCanSave           0001000000000 1024 can_save             Сохранять ли объект. Если флажок снят, то при перезагрузке объект исчезнет.
flVisibleForMap     0010000000000 2048 visible_for_map      Устанавливает видимость на миникарте
flUseSmartTerrains  0100000000000 4096                      неизвестно
flCheckForSeparator 1000000000000 8192                      неизвестно

*  Для многих объектов соответствующая функция не связана с флагом, а имеет логику, специфичную для данного объекта.
** Функция interactive также учитывает флажки flVisibleForAI и flUsefulForAI
*** В ЗП имеется функция для установки флажка use_ai_locations(bool). Обратите внимание, имя отличается от функции для чтения флажка.

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

Если уж говоришь о "нашел это только в Вашем модуле нет-пакетов", то и мог бы прочитать оттуда комменты по этому поводу:

--/ hook 'object_flags' for painless spawn

data.object_flags = bit_not(5) --/ сброс 1+4=5 => 1='UseSwitches' + 4='SwitchOffline'

Изменено 16 Апреля 2012 пользователем Artos

AndreySol · 16 Апреля 2012

Artos

Вообще-то я указал, что спаун предмета - скриптовый. Какое отношение к этому имеет ACDC и all.spawn не понимаю.

Artos · 16 Апреля 2012

AndreySol, это имеет отношение к вашим же словам:

AndreySol: object_flags - нашел это только в Вашем модуле нет-пакетов

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

P.S. malandrinus, (поясню для читающих топик), строго говоря, это собственно и даже не к ACDC имеет отношение.

Если говорить о названии object_flags, то да, это название дано было изначально в ACDC, хотя назвать можно как угодно.

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

Сами же же свойства этой группы (флаги объекта), как и многие другие, в любом случае вначале задаются дефолтными при любом варианте создания объекта в игре.

Изменено 16 Апреля 2012 пользователем Artos

Malandrinus · 16 Апреля 2012

AndreySol,

Вообще-то я указал, что спаун предмета - скриптовый. Какое отношение к этому имеет ACDC и all.spawn не понимаю.

Информацию из acdc можно использовать при скриптовой перезаписи нетпакета объекта. Эти флажки теми же нетпакетами можно переписать.

AndreySol · 16 Апреля 2012

Artos

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

Просканировал в TextPad папки 'config' и 'scripts' - ни в одной нет буквосочетания "object_flags" ни в одном из файлов, кроме Вашего m_netpk.

Malandrinus

Из Вашего ответа, как я понял, следует, что ф-ция alife():create(....) не может создать объект на местности без каких-то граблей ? И в купе с ней необходима правка нет-пакета для такого объекта ?

Malandrinus · 16 Апреля 2012

AndreySol,

Из Вашего ответа, как я понял, следует, что ф-ция alife():create(....) не может создать объект на местности без каких-то граблей ? И в купе с ней необходима правка нет-пакета для такого объекта ?

Несколько некорректно стоит вопрос. Что значит грабли? Функция create имеет в своём распоряжении свои аргументы (координаты) и содержимое секции. Всё остальное задаётся конструктором по умолчанию. Если заглянуть в acdc или аллспавн, то там можно увидеть гораздо больше параметров, которые в данном случае пролетают мимо: задаются как-то или не задаются вовсе. Иногда это срабатывает, а иногда надо имитировать процесс загрузки аллспавна путём перезаписи нетпакета объекта. Типичный пример - аномалии, или объекты с логикой в кастомдате. Общих принципов нет, про каждый конкретный объект в каждом конкретном случае надо знать конкретно, что от него хочешь и что и как надо дописать дополнительно в нетпакете. Для этого и рекомендуют смотреть в аллспавн или acdc. Соответственно, надо хоть на базовом уровне знать, что там. Если занимаешься спавном объектов скриптами, то без этого никак. Надо разбираться.

Artos · 16 Апреля 2012

AndreySol

Начинает раздражать Ваш подход к моддингу. Если вам

под нос не подсунули готовое описание/статью/решение, вам лень немного подумать своею головою и тем более поискать информацию самому.

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

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

Неужели непонятно, что все подобные "низкоуровневые" манипуляции с объектами разработчики игры вынесли в all.spawn? И именно там задают необхдимые значения флагов для объектов спавна. Искать в оригинальных скриптах, в которых у разрабочиков нет кодов использования нет-пакетов именно для флагов - конечно же бессмысленно.

Однако, огромное кол-во модов, где читаются и правятся нет-пакеты, уже имеют в своих "читалках-писалках" название object_flags (см. тот же amk.script).

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

Ну и кратко, т.к. выше уже объяснено:

Ф-ция alife():create(....) создает объект в игре по ШАБЛОНу, соответствующему заданной секции! И какие-либо свойства созданного предмета, не предусмотренные в шаблоне и/или требующие изменения - необхоимо добавлять/изменять уже самосоятельно, используя нет-пакеты.

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

Изменено 16 Апреля 2012 пользователем Artos

AndreySol · 18 Апреля 2012

Artos

Получается, что корявый результат единственной ф-ции, позволяющей ввести объект в игру - это повод для комплиментов ПЫСам ?

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

Artos

заморочки своих причуд и похотелок

спаун обычного предмета, на обыкновенном грунте(поверхности), на обыкновенной локации - это заморочки моих причуд и похотелок ?

Malandrinus · 18 Апреля 2012

AndreySol,

Получается, что корявый результат единственной ф-ции, позволяющей ввести объект в игру - это повод для комплиментов ПЫСам ?

Это вообще не повод для разговоров такого рода. Дизайн системы разработчики делали для себя. С этой точки зрения там всё логично и правильно. Система создания исходно двустадийная. Сначала создаётся объект как программная сущность, в качестве параметра функции создания передаётся имя секции. Из секции читается класс объекта, что уже является указанием создать объект конкретного типа: монстра, сталкера, предмет и т.п., В соответствии с классом читаются общие параметры из секции. На этом создание объекта как именно объекта в программе закончено. Это вполне логичная система, следующая распространённому шаблону фабрики объектов. Далее надо собственно инициализировать объект его конкретными параметрами, что делается уже при чтении этих параметров из аллспавна. Разработчики изначально предполагали, что объекты будут создаваться в SDK, и значит проектировали дизайн системы под эту идею. Те немногие объекты, которые им требовалось создавать скриптами, дополнены кодом инициализации и необходимыми скриптовыми функциями для управления. Надо было бы это для остальных - добавили бы и для них, но им это было не надо.

спаун обычного предмета, на обыкновенном грунте(поверхности), на обыкновенной локации - это заморочки моих причуд и похотелок ?

Да, поскольку спавн скриптами произвольного предмета в произвольном месте не входил в планы разработчиков. Можно сказать, что им было плевать на нужды модостроителей (что будет правдой), но нельзя сказать, что это всё криво. С точки зрения разработчиков всё работало как им надо.

Artos · 18 Апреля 2012

AndreySol, есть неплохое изречение по этому случаю: "Плохому танцору и яица мешают, а неумелому программисту - ..." :crazy:

Хотя у меня немало ругательств в сторону разработчиков игры, но комплиментов (ИМХО заслуженных) тоже немало.

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

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

Предлагаю перенести флуд по корявостям и "яицам" в соответствующие топики, а тут делом заниматься.

Разработчикам игры (да и многим модмейкерам) гораздо проще именно в алл.спавне прописывать спавн почти всех необходимых "обыкновенных" предметов ... - чем тогда назвать твое желание именно скриптом ящик динамита спавнить иначе, как не именно твоей похотелкой?

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

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

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

Изменено 18 Апреля 2012 пользователем Artos

AndreySol · 22 Апреля 2012

Artos

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

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

ТЧ v 1.0005

Вопрос по (спавну)созданию объектов.

После вызова create(...), как происходит непосредственный процесс создания объекта, если объект спаунится в инвентарь актора(ГГ) ? Из того что я смог найти здесь на форумах я представлял себе это так: непосредственно при вызове 'create' движок создает серверную "часть" объекта. Затем, по "выходу" из ф-ции, в которой вызывали 'create' движок создает клиентскую часть. Вот только как ? Он использует уже существующую серверную часть, копируя из нее необходимые данные, или клиентская часть создается самостоятельно ? А затем синхронизируется с клиентской ?

Изменено 22 Апреля 2012 пользователем AndreySol

Malandrinus · 23 Апреля 2012

AndreySol,

данный ящик я планирую использовать единственный раз, в единственном уникальном квесте.

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

Из того что я смог найти здесь на форумах я представлял себе это так: непосредственно при вызове 'create' движок создает серверную "часть" объекта.

Это верно

Затем, по "выходу" из ф-ции, в которой вызывали 'create' движок создает клиентскую часть.

Не совсем верно. Эти два события непосредственно друг у другу не примыкают. После создания серверного объекта, при условии нахождения его на том же уровне, начинает периодически проверяться условия его выхода в онлайн, что может включать в себя проверку нахождения в радиусе алайфа от актора, включённость/выключенность некоторых серверных флажков или нахождение в инвентаре актора или другого онлайнового объекта (ящика, непися). Важно то, что эта проверка периодическая (примерно раз в секунду) и срабатывает не сразу после создания серверного объекта. При срабатывании этой проверки создаётся клиентская часть.

Он использует уже существующую серверную часть, копируя из нее необходимые данные, или клиентская часть создается самостоятельно ? А затем синхронизируется с клиентской ?

1. Клиентский объект таки создаётся независимо, как независимо ранее создался серверный. Как-то инициализируется. В какой степени, зависит от типа объекта.

Это естественно не всё.

2. Часть данных берётся из серверного объекта.

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

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

AndreySol · 23 Апреля 2012

malandrinus

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

Как мне кажется, система как раз то и есть, надо только ее знать для конкретного объекта?

Я пробовал для артефакта, примерно так:

local npc = db.actor
local se_obj = alife():create("af_night_star", npc:position(), npc:level_vertex_id(), npc:game_vertex_id(), npc:id())
local pk = m_netpk.get(se_obj) -- запрос нет-пакета
if pk and pk:isOk() then
    local data = pk:get() -- читаем данные из нет-пакета
    if data and data.upd then ---- and data.upd and data.upd.torch_flags 
        if data.condition then
            data.condition     = 0.35 -- изменяем свойство в 'state' пакете
            data.upd.condition = 0.35 -- изменяем свойство в 'update' пакете
            pk:set(data)
        end
    end
end

В результате получаю такую ситуацию - объект создается и нормально спаунится в инвентарь актора(ГГ), но серверная часть имеет "condition" 35%, как и установлено с помощью нет-пакета, а клиентская имеет "condition" в 100%. После save\load и та и другая части приходят к "condition" в 100%. Значит для такого объекта, на момент создания(спауна), движок параметр "condition" явно не синхронизирует между серверной и клиентской частями ? Подскажите, как это сделать ?

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

function init(obj)
    local new_binder = genegic_artefacts_binder(obj)
    obj:bind_object(new_binder)
end

class "genegic_artefacts_binder" (object_binder)

function genegic_artefacts_binder:__init(obj) super(obj)
end 

function genegic_artefacts_binder:reload(section)
    object_binder.reload(self, section)
end

function genegic_artefacts_binder:reinit()
    object_binder.reinit(self)
    
end

function genegic_artefacts_binder:update(delta)
    object_binder.update(self, delta)

    local object_id = self.object:id()
    local object_parent = self.object:parent()

    if object_parent then
        ----- арты в инвентаре актера\нпс -----
    else
        ----- арты в онлайн -----
    end
end

function genegic_artefacts_binder:net_spawn(data)
    if not object_binder.net_spawn(self, data) then
        return false
    end
    return true
end

function genegic_artefacts_binder:net_destroy()
end

function genegic_artefacts_binder:save(packet)
end

function genegic_artefacts_binder:load(reader)
end

Но видимо этого недостаточно, чего-то не хватает. Подскажите, чего ?

Malandrinus · 23 Апреля 2012

AndreySol,

Как мне кажется, система как раз то и есть, надо только ее знать для конкретного объекта?

=) Понимаешь, если у каждого объекта система своя, то это и называется - нет системы.

Я пробовал для артефакта, примерно так:
...

объект создается и нормально спаунится в инвентарь актора(ГГ), но серверная часть имеет "condition" 35%, как и установлено с помощью нет-пакета, а клиентская имеет "condition" в 100%. После save\load и та и другая части приходят к "condition" в 100%. Значит для такого объекта, на момент создания(спауна), движок параметр "condition" явно не синхронизирует между серверной и клиентской частями ? Подскажите, как это сделать ?

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

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

Синхронизация к наличию/отсутствия биндера не имеет никакого отношения. Биндер - это способ получить доступ к событиям объекта, при условии, что объект эти события предоставляет. Биндер вторичен, т.е. если он есть, то на него влияет объект, но он сам не влияет на объект, к которому прикреплён.

А ты вообще читал мои статьи в справочнике? Походу нет. Я там кое-что из этого расписывал. Как-то не хочется повторяться.

Artos · 23 Апреля 2012

AndreySol

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

2. Если модмейкеру захотелось сделать то, чего нет в игре - это и называется похотелка модмейкера, хотя можешь называть это задумкой/фишкой/фенечкой... ;-)

Если именно модмейкеру захотелось сделать именно так, а не как 'штатно' делали разработчики, и требуется дополнительно повозиться с написанием лишних строк скрипов/конфигов - это и называется заморочка модмейкера.

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

AndreySol: Как мне кажется, система как раз то и есть, надо только ее знать для конкретного объекта?

Прокомментирую иначе, чем malandrinus':

Разработчиками заложена конечно некая система/алгоритм (система 'наследования' один из примеров), но, как известно: "Из правил имеются исключения", и эти исключения требуется знать и учитывать. Также, именно система делает различными все объекты в игре, предусматривая для каждого класса/типа свои отличия, а для каждого объекта возможность (а порою и необходимость) задавать индивидуальные признаки/характеристики.

То, что все предметы в игре имеют параметр condition - это как раз подтверждение системы. А то, что только для некоторых классов (оружие/броня/...) этот параметр задействован - элементарное правило экономии/сохранения ресусов в игре. Не следует считать, что дополнительные синхронизации 'всего и вся' - "копейки". Если бы было так, то создание сэйвов длились бы соразмерно времени загрузки игры, т.е. секунды-десятки ...

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

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

Ну и ... напомню, что имеется для каждого гейм-объекта методы net_Import и net_Export, чего пока никто из модмейкеров не использует. Может это как раз то, что нужно? (но сам в эту сторону почти не копал)

CuJIbBEP · 24 Апреля 2012

Подскажите, какой скрипт и часть кода в АМК отвечает за "Оружие убрал!", когда нпс это произносят только при наведении гг на них прицела, можно ли то осуществить в чистой игре?

Artos · 24 Апреля 2012

CuJIbBEP, смотри xr_meet.script и в частности использование Cmeet_manager:actor_targets_npc(...)

На чистую игру переносится довольно просто и от версий игры/патча не зависит.

Изменено 24 Апреля 2012 пользователем Artos

CuJIbBEP · 24 Апреля 2012

Artos, Спасибо нашёл.

Взял класс "Cmeet_manager" от АМК и полность перенёс...

Отлично, работает без проблем!

А то когда друг начинает подкалывать я ему иногда говорю не "Закрой хлеборезку!" а "Оружие убрал!" :crazy:

Artos · 25 Апреля 2012

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

function Cmeet_manager:actor_targets_npc(npc)
  local dangerang=1/npc:position():distance_to(db.actor:position())
  local ang=horz_angle(device().cam_dir,npc:position():sub(device().cam_pos))
  local tgt=ang>-dangerang and ang<dangerang
  if tgt then
    if self.tgt_time then
      --/ добавим удар в морду ------------------
      if self.tgt_time<time_global() then
        if dangerang > 0.33 then --/ если ГГ ближе 3-х метров:
          xr_abuse.add_abuse(npc,0.05) --/ добавляем обидчивости, провоцируя на удар ...
        end
        return true --/> ГГ целится в НПС
      end
      return false --/> не целится
      --/ ---------------------------------------
    else
      self.tgt_time=time_global()+600
      return false
    end
  else
    self.tgt_time=nil
  end
  return false
end

Дистаннцией (0.33) и коэффициентом обидчивости (0.05) можно поиграться, чтобы ближе/дальше и раньше/позже начинал махать

:crazy:

AndreySol · 25 Апреля 2012

malandrinus, Artos

Если надо сохранить, то сохраняй самостоятельно и всякий раз восстанавливай при выходе объекта в онлайн.

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

Войти

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

Рекомендуемые сообщения

Artos 99

Ссылка на комментарий

AndreySol 215

Ссылка на комментарий

Artos 99

Ссылка на комментарий

Malandrinus 615

Ссылка на комментарий

AndreySol 215

Ссылка на комментарий

Malandrinus 615

Ссылка на комментарий

Artos 99

Ссылка на комментарий

AndreySol 215

Ссылка на комментарий

Malandrinus 615

Ссылка на комментарий

Artos 99

Ссылка на комментарий

AndreySol 215

Ссылка на комментарий

Malandrinus 615

Ссылка на комментарий

AndreySol 215

Ссылка на комментарий

Malandrinus 615

Ссылка на комментарий

Artos 99

Ссылка на комментарий

CuJIbBEP 540

Ссылка на комментарий

Artos 99

Ссылка на комментарий

CuJIbBEP 540

Ссылка на комментарий

Artos 99

Ссылка на комментарий

AndreySol 215

Ссылка на комментарий

Создайте аккаунт или авторизуйтесь, чтобы оставить комментарий

Создать аккаунт

Войти

Недавно просматривали 0 пользователей

AMK Склад