Jump to content
Allender

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

Recommended Posts

Allender    11

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

 

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

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

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

  • Like 2
  • Полезно 1

Share this post


Link to post
Share on other sites
Dennis_Chikin    3,615

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

 

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

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

 

Пример: файл 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.
 

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

Edited by Dennis_Chikin
  • Согласен 1

Share this post


Link to post
Share on other sites
Allender    11

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

 

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

 

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

 

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

Edited by Allender

Share this post


Link to post
Share on other sites
Dennis_Chikin    3,615

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

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

 

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

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

  • Согласен 1

Share this post


Link to post
Share on other sites
Desertir    202

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


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

 

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

Edited by Dennis_Chikin
  • Thanks 1
  • Like 3
  • Согласен 1

ТЧ 1.0004. SAP и Trans mod

github

Share this post


Link to post
Share on other sites
Expropriator    2,106

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

 


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

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


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

Edited by Dennis_Chikin

andreyholkin.gif

rod_cccp.gif

 

Share this post


Link to post
Share on other sites
Dennis_Chikin    3,615

function heli_start_flame( heli )

heli:get_helicopter():StartFlame()

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

news_heli( heli, "flame" )

end

 

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

Share this post


Link to post
Share on other sites
Expropriator    2,106

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

 

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

 

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


andreyholkin.gif

rod_cccp.gif

 

Share this post


Link to post
Share on other sites
Dennis_Chikin    3,615

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

 

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

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

 

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

 

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

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

 

Отвечает за разбор этих черточек и закорючек файл 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, чтобы оно это читало, что было в "стандартном ТЧ", а где - было, но с ошибками. Но смысл в любом случае примерно такой. Просто записали что-то в конфиг, который потом кому-то как-то скормили.

Edited by Dennis_Chikin
  • Like 1
  • Полезно 1

Share this post


Link to post
Share on other sites
Expropriator    2,106

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

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

 

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

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

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

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

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

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

 

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

Edited by Дизель
  • Like 1

andreyholkin.gif

rod_cccp.gif

 

Share this post


Link to post
Share on other sites
Dennis_Chikin    3,615

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

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

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

 

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

Share this post


Link to post
Share on other sites
Expropriator    2,106

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

 

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

Edited by Дизель
  • Согласен 1

andreyholkin.gif

rod_cccp.gif

 

Share this post


Link to post
Share on other sites
Outfater    287

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

; State                = 7
; 0 - бежать прямо на врага
; 1 - бежать на врага петляя
; 2 - бежать на врага по укрытиям
; 3 - бежать от врага по укрытиям
; 4 - паника
; 5 - прятаться от врага
; 6 - обходить врага
Но это больше смахивает на какую-то фикцию, которая просто отключена в каждой и игр серии (если память не изменяет). Спасибо.

 

 

 

Share this post


Link to post
Share on other sites
Dennis_Chikin    3,615

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

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

 

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

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

 

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

 

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

Edited by Dennis_Chikin

Share this post


Link to post
Share on other sites
Outfater    287

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


 

 

 

Share this post


Link to post
Share on other sites
Dennis_Chikin    3,615

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

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

 

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

Edited by Dennis_Chikin

Share this post


Link to post
Share on other sites
Dennis_Chikin    3,615

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

 

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

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

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

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

и т.д.

 

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

[walker3@1]

[walker4@1]

и т.д.

 

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

 

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

 

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

 

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

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

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

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

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

и т.д.

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

Edited by Dennis_Chikin

Share this post


Link to post
Share on other sites
Dennis_Chikin    3,615

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

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

[logic]

active = sr_idle

 

[sr_idle]

on_npc_in_zone = 19029 |soldier_v_piyanux_restrictor| sr_idle@time

single = true

Share this post


Link to post
Share on other sites
abramcumner    925

@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
    ...

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

AMK-Team.ru

×
×
  • Create New...