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

[xStream 87]

Челоаек просто опечатался, написав плюс вместо подчеркивания - посмотри на свою клавиатуру и поймешь.

Обе записи имеют вполне внятный смысл.

Только вторая опасна, если _G[module] == nil

[xStream 87]

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

[xStream 87]

Совершенно верно. И мне непонятно, почему придирание к опечатке пошло и речь о контексте...

[xStream 87]

KD87, я думаю, проблема не в том, чтоб его прочитать или записать, а в том, что он должен попасть в реестр стори_идов. А это, насколько мне известно (в том числе и по опытам, аналогичным опытам *Shoker*), происходит в момент старта игровой сессии. (черт, похоже не в тему ответила. Я имею ввиду такие ситуации, как споты в ПДА на определенные объекты. Там задействован реестр) Изменено 9 Января 2012 пользователем xStream

[xStream 87]

Как выглядит функция таймера?

В теме "Язык Lua. Общие вопросы программирования." - дополнительно к АМК-таймерам (тихий ужас, если честно) выложено аж несколько реализаций этого добра. С помощью тех библиотек таймеры можно сделать в виде пары строк.

[xStream 87]

evid_see_stuff = 6931 -- откуда берется сия магическая цифра ?

actid_reach_item = evid_see_stuff -- почему должна быть она же, а не какая другая.

 От балды :-) Уникальный идентификатор-число, для составления графов планировщиком.

Вторая строка - для упрощения, считаем, что у эвалюатора и экшна одинаковые идшники (уникальными они должны быть не вообще, а только среди эвалюаторов, свойств (property), экшенов)

 

local prop_idlecombat = xr_evaluators_id.state_mgr + 3 -- для чего здесь и далее вот это

local prop_contact = xr_evaluators_id.stohe_meet_base + 1 -- и откуда оно опять таки берется.

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

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

 

И, опять же, по-русски - почему недостаточно просто

action = manager:action( xr_actions_id.alife )

action:add_precondition( world_property( evid_see_stuff, false ) )

 

 Это важная часть: мы говорим движку, что переключение на движковую схему алайфа происходит только тогда, когда наш эвалюатор возвращает false (то есть судя по названию - когда чета-там не видим, тогда можно переходить на движковую схему). По сути, мы заставляем планировщик проверять всегда этот эвалюатор, ибо цель у планировщика всегда одна - перевести жертву под движковую схему xr_actions_id.alife. Эти две строчки обязательно должны быть в любой схеме, которая запрещает переход в алайф (можно запрещать что-то другое, что в свою очередь запрещает алайф.... сложно, в общем, теория графов и прочая лабуда)

 

Так вот, по идее этого достаточно :-) Этого достаточно, если нам надо какой-то эвалюатор добавить. Но есть еще экшн! И вот мы его настраиваем: указываем, что требуется для запуска этого экшена и к изменению какого свойства мира (property) он приведет - как раз ниже. Мы указываем, что в результате выполнения экшена нашей схемы (а их в схеме может быть несколько), свойство видимости (ну выше которое определяли) станет равно false, что в свою очередь позволит планировщику перевести в будущем нашего непися под алайф (помним - алайф это конечная цель планировщика)

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

 

Наконец, самое интересное, это вот это магическое сочетание:

action:add_effect( world_property( evid_see_stuff, false ) )

manager:add_action( actid_reach_item, action )

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

------------------

Краткий итог: есть свойства, которые мы задаем через человекочитаемые имена и уникальные числовые ИДшники (для планировщика)

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

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

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

 

Дополнительные коментарии вот тут 

 

 

-- задаем от балды УНИКАЛЬНЫЙ ИДшник эвалюатора/свойства/экшена смотря, где использовать
-- но принято префиксом переменной (evid_) указывать, чей это ИДшник. Сейчас - ИД эвалюатора 
evid_see_stuff	= 6931

-- это уже ИДшник экшена (действия) просто делаем такой же, как у свойства (эвалюатора)
-- префикс actid_
actid_reach_item = evid_see_stuff

function add_to_binder( npc, ini, scheme, sect, st )
	local manager = npc:motivation_action_manager()

	-- это просто локальные переменные, указывающие определенные эвалюаторы ДРУГИХ схем. Так делать нехорошо, лучше именовать все такие "магические" значения - чтоб не было плюсов, а были нормальные имена как ниже (1)
	local prop_idlecombat = xr_evaluators_id.state_mgr + 3
	local prop_contact = xr_evaluators_id.stohe_meet_base + 1

	-- собственно добавляем в планировщик наш эвалюатор: первый параметр функции - название (ИДшник) свойства(эвалюатора - помним, это почти одно и то же - свойство есть результат работы эвалюатора)
	-- второй - собвственно сам объект эвалюатора
	manager:add_evaluator( evid_see_stuff, ev_see_stuff( st, "ev_see_stuff" ) )

	-- создаем экшн 
	action = act_reach_item( "act_reach_item", st )
	-- ниже идут строчки, где мы перечисляем, при каких условиях начнет выполняться наш экшн
	-- сталкер жив (1 - нормальное имя)
	action:add_precondition( world_property( stalker_ids.property_alive, true ) )
	-- у сталкера нет врага
	action:add_precondition( world_property( stalker_ids.property_enemy, false ) )
	-- у сталкера нет опасности
	action:add_precondition( world_property( stalker_ids.property_danger, false ) )
	-- ...
	action:add_precondition( world_property( prop_contact, false ) )
	action:add_precondition( world_property( xr_evaluators_id.sidor_wounded_base, false ) )
	action:add_precondition( world_property( blowout_scheme.evid_anomaly, false ) )
	action:add_precondition( world_property( blowout_scheme.evid_blowout, false ) )
	-- ... а тут мы указываем, что чтобы наш экшен запустился, наш эвалюатор был true - судя по названию переменной, когда сталкер видит объект (а это проверяется в эвалюаторе)
	action:add_precondition( world_property( evid_see_stuff, true ) )
	action:add_precondition( world_property( prop_idlecombat, true ) )

	-- теперь говорим планировщику, что в результате действия нашего экшена, сталкер перестанет видеть объект
	-- свойство станет равно false (я так понимаю, сталкер просто подберет предмет)
	action:add_effect( world_property( evid_see_stuff, false ) )
	manager:add_action( actid_reach_item, action )

	action = manager:action( xr_actions_id.alife )
	action:add_precondition( world_property( evid_see_stuff, false ) )
end

 

Извиняюсь за постоянные повторения - но это важнно и не всегда все сразу усваивают :-)

Изменено 24 Января 2015 пользователем xStream

[xStream 87]

Наглядный пример ООП ради ООП... в реализации без архитектуры :-)

Изменено 14 Февраля 2015 пользователем xStream