Система ALife. Логика поведения игровых объектов

[Allender 11]

Первый параграф в статье. Самый черновой вариант.

 

Документ на Google Disk. 

https://docs.google.com/document/d/1qgkkpIrz5Gie8p58AF-7y9iRZXEp7Xmn17gJT3uy5zQ/edit?usp=sharing

Важно мнение по манере изложения. Понимаю, мало информации... Но все же, как считаете, сам процесс подачи информации будет понятен пользователю?

[Dennis_Chikin 3 665]

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

 

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

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

 

Пример: файл gulag_dark_walley.script (недавно разбирался):

gulags.val_escort.job = function(sj, gname, type, squad, groups) -- игнорирование
    local ltx = "[meet@ignore_abuse]\n" .. и т.д. - динамическое создание логики персонажей для смарта val_escort

...

gulags.val_escort.ltx = ltx

 

function load_ltx(gname, type)
    local g = gulags[type]
    if g then return g.ltx end -- возвращает сформированный текст.
    return nil -- "магическая" команда
end

 

Это можно переписать например так:

["val_escort"] = {    -- Пуля, Любер, бандиты
    { section = "logic@val_escort_nap1",    -- напарник с которым спасаем пленного
   ... и т.д., где [logic@val_escort_nap1] и прочие определены в файле config\misc\gulag_dark_walley.ltx, который подключен через system.ltx.
 

продолжение следует.

Изменено 21 Августа 2014 пользователем Dennis_Chikin

[Allender 11]

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

 

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

 

В то же время, не хочется писать новую статью "как сделать торговца" с кусками кода, что и куда нужно скопировать.

 

Именно как введение.. текст понятен?

Изменено 21 Августа 2014 пользователем Allender

[Dennis_Chikin 3 665]

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

Введение надо какое-то более другое.

 

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

Если нет - придется, видимо, гипертекстом оформлять.

[Desertir 202]

Надо объяснить не то, где что лежит, а как работает сама система в целом. Конкретные файлы пока не должны иметь значения, пока. До них дойдет дело, когда будешь рассказывать о том, как эта система (которую надо описать выше) реализована в сталкере. А ты сразу начал с реализации. Может я чтото упустил, но противная теория всегда нужна, гдето больше, гдето меньше. Это параграф 3-4 будет Всегда надо идти от общего к частному, от простого к сложному. Иначе просто будет непонятно.

схемы управления game_object-ами (NPC, physic_objects, level_changer, etc...).

Например, я ничего не знающий. Для меня абсолютно непонятно, что это за слова. Что это за файлы дальше, вообще непонятно.
Надо уметь изложить тему так, чтобы ее поняла любая бабушка. Я серьезно. Потенциальный читателем может быть бабушка, так вот после прочтения твоей статьи, или серии связанных статей, она должна суметь сделать лагерь с охраной и спящими ночью и прочими плюшками Надо к этому стремиться.
ЗЫ: по хорошему надо начать с горки статей про программирование, строение сталкера, про язык луа, про скрипты, про язык логики (а он свой у ПЫСов, все эти секции с on_info и прочей лабудой) и т.д.

 

Вопроса "что такое скрипты" не должно возникать, после прочтения соответствующей статьи конечно.
Как я мог видеть, ты написал, что тут вопросов то и не будет, будут статьи, пособия, методички и все все все. Так что любые вопросы в ШМ, но ее саму надо модифицировать. Как? А хрен его знает. Основная проблема - вопросы, на которые уже есть ответы, либо вопросы связанные с ошибками их же авторов.

Изменено 26 Октября 2015 пользователем Dennis_Chikin

[Expropriator 2 119]

Извините за вопрос в эту тему (но не нашел более менее подходящей):
Необходимо состарить вертолёт в ЗП(сделать его раненым), не весь класс, а именно по логике. Я помню в ТЧ было подобное на Ростоке с вертушкой. К сожалению нет игры ТЧ. Подскажите, что в логике прописать?

 

@Wlad777, heli_die - это уже смерть вертушки. А мне надо было как бы меньше, чем heli_die нанести урону. Я не правильно выразился, что именно в стандартной логике, без правок скриптов, вертолёт не ранишь.

if health <= 0.005 and not self.st.immortal then heli_start_flame( self.object )

Вот в бинде функция сщитающая вертолёт раненным.

Изменено 26 Октября 2015 пользователем Dennis_Chikin

[Dennis_Chikin 3 665]

function heli_start_flame( heli )

heli:get_helicopter():StartFlame()

db.storage[heli:id()].flame_start_snd:play( heli )

news_heli( heli, "flame" )

end

 

Какая строчка в этой функции непонятна ?

[Expropriator 2 119]

@Dennis_Chikin, это новая функция? Я в ЗП такой не нашел, есть только вот такая:

 

function heli_start_flame( obj )
    obj:get_helicopter():StartFlame()
end

 

Можете другим объяснить, мне уже эта функция не требуется. Я обошел её по своему.

[Dennis_Chikin 3 665]

Так, поболтали, и забыли...

 

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

Функция - в общем, делает одно и то же: включает "горение" вертолета.

 

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

 

Работает же, в общем и целом, вся логика примерно вот как я начал писать во втором посте темы, но не закончил (и не знаю, описано ли это в гугльдоке из первого):

Это - некий как бы человекочитаемый язык. Описывающий условия, при которых, внезапно, таки да - вызываются какие-то функции. Часть этих функций УЖЕ замаскировано вот этими всеми черточками, плюсиками, и закорючками, а что не замаскировано - надо указывать явно.

 

Отвечает за разбор этих черточек и закорючек файл xr_logic.script, и если кому-то надо знать, какие ВООБЩЕ есть возможности, как ТОЧНО работает та или иная закорючка, и как добавить что-то свое - вам таки придется разбирать вот этот самый скрипт. А он несет немало открытий весьма чудных, да...

Впрочем, основное написано там в самом начале, в комментариях.

 

Из них нам особо интересны function parse_condlist(npc, section, field, src),

function pick_section_from_condlist(actor, npc, condlist) и function try_switch_to_another_section(npc, st, actor).

Ну и, естественно, комментарии к ним.

 

Первая, parse_condlist - разбирает эти ваши черточки и кракозябры в таблицу условий,

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

 

То есть, если в логике присутствует кракрозябра вида "=что_то_там" или "!вот_такая_фигня", из файла xr_conditions будет вызвано ваше "что_то_там" или "вот_такая_фигня". Если, конечно, оно есть. Если нет - получите зависание, и, в конце-концов, вылет с любимым всеми сообщением "переполнение стека". Что показательно - не зависимо от количества памяти.

Если все-таки есть, в туда будет передан актор, ваш объект, и параметры из прочих черточек и закорючек.

 

Таким образом, если Вам надо что-то принципиально новое, вы должны это новое вписать в xr_conditions.script, или поправить xr_logic.pick_section_from_condlist(), чтобы оно вызывало вашу фигню из более другого места.

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

Оно же, сразу же, содержит возможность ВЫПОЛНИТЬ ВАШУ ФУНКЦИЮ, если проверяемое условие выполнилось. И таки тоже передает туда актора, объект и параметры. То есть, вам осталось только вписать в строку условий нужное, или создать это нужное, и вписать.

Ага, например, создать my_kewl_script.script, добавить в туда function podzhetch_vertalot( dummy, obj ) bind_heli.heli_start_flame( obj ) end, вписать в вашу логику что-то типа %=my_kewl_script.podzhetch_vertalot%, и наслаждаться результатом.

 

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

При этом оно дергает, соответственно, за pick_section_from_condlist, а про нее вы уже все знаете. Но можно, опять же, добавить свои условия типа проверки хита вертолета с одновременным поджиганием.

 

Вот как-то так.

 

p.s. флуд почистил.

 

P.P.S. Но вообще, применительно к вертолету, проще поправить bind_heli.script, чтобы он читал из активной секции хит, с которого надо начинать гореть.

И хотя этот параметр будет в файле логики, к собственно рассматриваемому псевдоязыку это не имеет СОВЕРШЕННО НИ КАКОГО отношения.

Так же, как, например, параметры danger или ранения, или даже путей, читаемых для неписей из назначенного им ltx. Кстати, даже и не помню, что я правил в ранениях и danger, чтобы оно это читало, что было в "стандартном ТЧ", а где - было, но с ошибками. Но смысл в любом случае примерно такой. Просто записали что-то в конфиг, который потом кому-то как-то скормили.

Изменено 26 Октября 2015 пользователем Dennis_Chikin

[Fagot. 400]

@Allender, хорошо начал статью. 

Продолжай.

[Expropriator 2 119]

@Dennis_Chikin,  так то оно так. Но статья явно не на новичков. Это лекция для студентов. Какие же разные у нас мировозрения на функции.

Всё намного проще.

 

Для новичков, как это работает:

1. Есть движок, в котором и прописаны сами функции для определённого класса.

2.Есть спавненный объект на локации с подключённым листом логики.

3.Есть пакет идентификации объекта, в разделе логики, для вызова скрипта бинда с указанием класса.

4.Есть скрипт, в котором описываются условия, для включения движковых функций.

5.Есть логика, в которой включаются условия, для скрипта включения движковых функций.

 

...Это образно, короче. Это моё мировозрение, и оно может быть не верным, но оно работает.

Изменено 26 Октября 2015 пользователем Дизель

[Dennis_Chikin 3 665]

п2 и далее - не верно.

Все, что принято называть "логикой" - это реализовано исключительно на скриптах. Измените скрипты - изменится и все, что вы делаете в этой "логике".

Это - просто еще один язык поверх другого языка. Который используется в текущем виде просто по принципу "здесь так принято".

 

Очень странный, ограниченный и неудобный язык.

[Expropriator 2 119]

@Dennis_Chikin, это в сталкере так принято. А например в движке Унреал, функциии вынесены в скрипты, где используется только один язык.  Я знаю про сталкеровский Луа скрипт, потому соглашусь с тобой частично, что в сталкере используется два языка.

 

Я скорее рассматриваю скрипты не как функции, а как нечто связующее между движком и логикой. Даже если ты изменишь скрипты, то движок то уже заточен понимать Луа, и изменив скрипты, ты получишь неадекватную реакцию с его стороны.

Изменено 26 Октября 2015 пользователем Дизель

[Outfater 288]

@Dennis_Chikin, @Дизель, привет, есть вопрос: а можно теоретически сделать логику неписей в... скажем, ТЧ, аналогичной поведению неписей из F.E.A.R.? Что бы они обходили препятствия, корректно прятались за укрытиями, обходили врага, отступали и т.п.? Наверняка каждый из вас видел этот фрагмент:

; State                = 7

; 0 - бежать прямо на врага

; 1 - бежать на врага петляя

; 2 - бежать на врага по укрытиям

; 3 - бежать от врага по укрытиям

; 4 - паника

; 5 - прятаться от врага

; 6 - обходить врага

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

[Dennis_Chikin 3 665]

В классическом сталкере, в состоянии боя логика не работает вообще. То есть, она работает как раз ровно до боя и после боя.

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

 

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

Но это, опять же, "не логика".

 

Еще есть, например, watcher_act.script, например, знаменитый тем, что если на дальнем конце локации бросить какой-то предмет, то непись, наплевав на бой, аномалии, все остальное, полезет за этим предметом. Опять же, отключается проверка состояния "в бою".

 

Ну а небоевое поведение непися определяется выбранными через скрипт, который взял на себя управление, анимацией, state и командами "идти к вертексу n".

Изменено 28 Октября 2015 пользователем Dennis_Chikin

[Outfater 288]

А есть какая-нить простая (не на сто-двести строчек) функция на базе ТЧ+АМК1.4.1 на обход аномалий неписями\мутантами?

[Dennis_Chikin 3 665]

Обход аномалий зависит от правильно выставленного параметра effective_radius в кофигах аномалий.

Опять же, если кто-то не перехватит проверку ( world_property( stalker_ids.property_enemy, false ) ), и не пошлет непися прямо в аномалию (опять же пресловутый watcher_act.script), например.

 

Для мобов - mob:add_restrictions( "", s ), где s - строка с перечислением имен рестрикторов, в которые лезть нельзя.

Изменено 28 Октября 2015 пользователем Dennis_Chikin

[Dennis_Chikin 3 665]

Забавно однако наблюдать, как "слишком умный" скрипт ведет к умножению бреда в конфигах.

 

Как бы, изначально синтаксис выбора секций должен выглядеть как

active = схема@уникальный_модификатор1

[схема@уникальный_модификатор1]

on_чегопопало = ... схема@уникальный_модификатор2

и т.д.

 

Но поскольку для названия схем добавили фильтрацию цифр, в количестве имеем

[walker3@1]

[walker4@1]

и т.д.

 

Просто праздник какой-то...

 

А вот новую схему типа walker1 - фиг добавишь.

 

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

 

Даже если это будет подряд

line1 = вот так а еще мы добавим чего попало как нам в голову взбредет

line1 = "№%:/"\%?;.$@#$%^&*;%Ё!!\0%&^&;%№:?!?9[=-+~$^{

line1 = ;и вот только попробуйте это не прочитать

line1 line1, li ne1 li\0ne1 ~= $_\\\\]%

и т.д.

А также пачка переходов на секции и строки вообще несуществующие.

Изменено 22 Декабря 2015 пользователем Dennis_Chikin

[Dennis_Chikin 3 665]

Сорри за даблпостинг, но мне таки интересно.

Люди, скажите, как вы добиваетесь, чтоб у вас работали конструкции вида:

[logic]

active = sr_idle

 

[sr_idle]

on_npc_in_zone = 19029 |soldier_v_piyanux_restrictor| sr_idle@time

single = true

[abramcumner 1 229]

@Dennis_Chikin, там же сид указывается, а не ид.

  ...
  local se_obj = sim:story_object(tonumber(t.v1))
  if se_obj then
    t.npc_id = se_obj.id
  else
    t.npc_id = -1
    ...