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

[Nazgool 250]

Дальше пока не смотрел, но читаю на входе строку 's', и (как и предполагал) ничего, кроме типа 'backoff@threat_weap' не вижу.

Т.е. никаких разделителей '|' пока нет.

Так что похоже существующий паттерн действительно не совсем к месту.

[Artos 99]

state == {} - это нормально ?

Вообще-то не понял вопроса... т.к. в моих вариантах state - имеет строковое значение.

Если ты спрашиваешь о возвращаемой таблице иль нИле - ответ ведь в самих скриптах! Смотри, например, в xr_wounded.script что распарсивается при "является ли текущий звук синхронным для текущего стейта" - ТАБЛИЦА! Т.е. если не будет таблицы - будет вылет, а пустая таблица "говорит" об отсутствии синхронизированного звука со стейтом.

 

Захват первого | в подстроку - он зачем оставлен ?

Хм, патерн подразумевает захват 'если таковой имеется'...

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

 

P.S. А вот ежели не можешь использовать по какой-то причине abort'ами - не стОит уподобляться мартышке из басни дедушки Крылова, хулящей то, чего ей не потребно иль непонятно. И сама функция abort'a может быть как угодно доработана для информативности и движки бывают ра-а-азные.  

 

 

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

Изменено 3 Февраля 2014 пользователем Artos

[Dennis_Chikin 3 658]

Artos, все равно не понял:

[codе]if sState then

if sState ~= '' then

tDat.state = xr_logic.parse_condlist(oNPC, sDist, sState, sState)

else tDat.state = {}

end

end[/code]

в xr_wounded что-то типа:

[codе]local t

if self.npc:see( actor ) then t = self.a.hp_state_see

else t = self.a.hp_state

end

if t then ... ищем подходящий key

else return "nil", "nil"

end

if t[key].state then парсинг и возврат результата, либо тот же "nil"

[/code]

То есть, нет стейта - то и все entry в таблице той же hp_state н нужно.

 

Опять же в parse_data() у тебя захват:

for sField in sStr:gmatch("(%|*%d+%|[^%|]+)%p*")

то есть, |10|st1@snd1 - она так и хватается, а дальше из нее выдирается ^| и далее по тексту.

А почему не поиск/захват "%|*(%d+%|[^%|]+)%p*" ?

 

P.S. С abort(), чтобы изнутри неписевых схем отрабатывал - разве что более другой движок. Иначе в лучшем случае будет сообщение в логе, а дальше - все равно висяк, с которым и сохраниться можно.

Изменено 3 Февраля 2014 пользователем Dennis_Chikin

[Artos 99]

@Dennis_Chikin, задавая вопрос уточняй контекст.

Ранее ты спрашивал в контексте функции parse_syn_data,  в которой нет state = {}.

Эта строка с приравниванием относится уже к иным функциям (parse_data, ...) и далее табличка state используется для вычитывания значений в конструкциях типа r_logic.pick_section_from_condlist, и соответственно, может быть таблицей или ...

 

Ну а почему начальный '%|*' включен в патерн (ежели имеется)? - ну так попробуй исключить и увидишь, что если вынести из патерна, то при различных заданных строках (присутствует иль нет) совершенно иной результат будет.

А вот '[^|]' - не выдирается, а исключается из захвата, т.е. все до этого символа попадает в захват, а сам последующий символ остается в остатке для следующей итерации.

 

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

 

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

 

И последнее: Разработчики GSC не стали писать распарсиватели для каждого параметра в схемах логики (meet/wounded), а решили обойтись тремя боле-менее универсальными функциями/патернами. Если тебе хочется производительность поставить во главе критериев - ничего не мешает понаписать более оптимальные для каждого параметра патерны/функции. Просто будет бОльшее кол-во строк в скриптах и ... больше возможности ошибиться в применении нужной (особенно при разработке/модификации).

Изменено 3 Февраля 2014 пользователем Artos

[Dennis_Chikin 3 658]

Гм, а разве поиск и захват подстроки - не полностью взаимоперпендикулярны ? При условии, что вообще нашлось то, что подходит под шаблон ?

 

%|* - внутри шаблона захвата - должен захватить и | тоже, если дальнейшее совпадет с остатком шаблона.

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

 

%d+%|[^%|]+ - тут все понятно. Захватываем то, что на надо. %p* за пределами шаблона захвата - как раз поиск разделителя, без его захвата. Это для parse_data().

Для parse_zone_data() вместо %d+ будет [^|]+ (и, кстати, за такие секции зон надо давать 10 лет строгого расстрела, так же как за секции всех прочих объектов и за имена файлов).

Ну а для syndata - вообще без ключа, просто пары state@sound|state@sound должны быть... То есть, просто "([^|]+)%p*", по-хорошему.

 

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

[Nazgool 250]

в строке конфига можно задавать не только одно состояние (стэйт) требующее синхронизации со звуком...

Ага.

Тогда все эти (в xr_meet) string.find-ы, string.sub-ы зря наворочены.

Всё можно сделать в одном паттерне. Напр. :

for state,sound in s:gmatch("([%w%_]+)%s*%@?%s*([%w%_]*)") do
    -- сразу получаем и state и sound
    ...
end

Помимо всего, этот паттерн расшифровывает строку 's' вида :

1. " psy_armed @ wounded_psy  backoff @ threat_weap "

2. 'psy_armed @  | backoff  '

Т.е. можно "забыть" поставить звук или разделитель | , а также добавить лишние пробелы.

Таких форматов конечно нет, но тем не менее.

[Artos 99]

 

 

пытаюсь изобрести осмысленную строку, где первый | имеет смысл, и не могу

 

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

Ну как ты не поймешь, вроде как уже разжевал... Давай разберем такую строку, в которой заданы три состояния с синхронными звуками:

state1@sound1|state2@sound2|state3@sound3

При первой итерации будет откушен кусок: state1@sound1 и останется: |state2@sound2|state3@sound3

Из откушенного будет определена 1-ая пара.

Далее будет откушен: |state2@sound2 и останется: |state3@sound3

Из этого куска будет выделена 2-ая пара.

Ну и напоследок из остатка будет выделена 3-я пара значений для состояния и синхронного для него звука.

И все это будет упаковано в табличку и выдано функцией как результат - что и требовалось.

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

 

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

[Nazgool 250]

Artos

Да я то не против. Пусть будет как есть. Был задан вопрос, и меня заинтересовал (впрочем как и всегда) чисто академический интерес.

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

Тут как? Сколько будет нюансов - столько (как правило больше) и вариантов решения. Так что на данный момент, и с текущим количеством информации о вопросе, решение пока такое.

Изменено 3 Февраля 2014 пользователем Gun12

[Dennis_Chikin 3 658]

интересный вопрос возник:

в Cwound_manager:update() и в action_wounded:execute() self.object - один и тот же ?

self.object:name() - возвращает имя непися.

self.object:object( "medkit" ) в первом возвращает аптечку, во втором - nil. В инвентаре у непися при торговле в это же самое время аптечка визуально присутствует.

 

Upd: все оказалось смешнее:

~info~ [xr_wounded] (esc_vagon_wounded):eat_medkit

~info~ [xr_wounded] (esc_vagon_wounded):eat_medkit, found medkit

sv reject. id_parent [5738][stalker:esc_vagon_wounded] id_entity [32274][medkit:medkit32274] [11946]

sv destroy object [32274][medkit:medkit32274] [11946]

~info~ [xr_wounded] (esc_vagon_wounded):eat_medkit, done

~info~ [xr_wounded] (esc_vagon_wounded):update, need use medkit (hp: 31.048185348511)

~info~ [xr_wounded] (esc_vagon_wounded):update, medkit: medkit (32274)

А вот на следующем апдейте ее уже нет.

Изменено 5 Февраля 2014 пользователем Dennis_Chikin

[К.Р.А.З 130]

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

 

Предупреждение?

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

ColR_iT

Изменено 6 Февраля 2014 пользователем ColR_iT

[antreg 178]

Добрый день.
Вопрос по скриптовому файлу АМК: amk_anoms.script

А именно по таблице: level_anoms
Может кто-то разъяснить,
за что отвечает третий цифровой параметр в строках типа:
l11_pripyat = {100,150,900,{mincer=15 ,mosquito_bald=17 ,witches_galantine=17 ,buzz=17 ,zharka_static=17 ,gravi_zone=17}},
(в данном примере - это 900).

[lsclon 527]

 

 

...за что отвечает третий цифровой параметр в строках типа: l11_pripyat = {100,150,900...

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

[Капрал Хикс 524]

Нигде не запрашивается и нигде не используется.

 

Т.е., можно удалять без опаски этот рудимент?

[Charsi 440]

Можно, но при удалении четвертый элемент станет третьим и это нужно учесть там, где к нему идет обращение (function spawn_rand_anom) и изменить индекс с 4 на 3.

[Dennis_Chikin 3 658]

Проверте меня, плиз (да, опять регэкспы)

 

ТЧ, utils.parse_waypoint_data() - будет ли вполне эквивалентом:

function parse_waypoint_data( path, flags, pname )
	local t = { ["flags"] = flags }
	for k, v in string_gfind( pname, "|([%w_\\%-%,%*]+)=*([%w_\\%-%,%*]*)" ) do
		if v ~= "" then t[k] = v; else t[k] = "true" end
	end
	return t
end

[Nazgool 250]

Это нужно парсить строку вида : wp01|a=hide|s=speech1 ?

....

Ага, дошло...

Изменено 7 Марта 2014 пользователем Gun12

[Dennis_Chikin 3 658]

Да. При этом бы еще знать бы, какие они вообще бывают.

Но та монстрофункция из utils мне "почему-то" ну вот совсем не нравится.

 

p.s. string_gfind == string.gfind, разумеется.

 

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

 

Про смысл набора - аналогичный интерес. Как обычно: мож чего-то хотели, но не доделали, мож и вправду смысл имеет, но в оригинале не использовано. А может - как умели - так и написали.

Не, на таком уровне править точно не рискну. Мне достаточно, что это теперь типа инлайнить можно, а не через 5 скриптов вызывать.

Изменено 7 Марта 2014 пользователем Dennis_Chikin

[Nazgool 250]

Эквивалентна полностью. Только защиты той нет, что в оригинале.

Интересен этот набор : [%w_\\%-%,%*]

Почему не "Любые символы кроме пробельных и знака ="?. В чём смысл этого набора?

Паттерн был бы проще.

...

Ну хотя бы поставь проверку, что pname - это строка. А так всё нормально.

...

Не знаю. Поиск по way-ям ничего из других символов, кроме %w_ и символа = не нашёл.

...

И ещё. в паттерне такое выражение - =*. А что, можно ставить несколько символов =. Напр. a====hide  ))?

Может всё-таки заменить на =? т.е. вопросительный знак, а не звёздочка?

Изменено 7 Марта 2014 пользователем Gun12

[Dennis_Chikin 3 658]

А на 4-й день Зоркий Глаз заметил, что у тюрьмы забыли построить 4-ю стену...

 

В смысле, что, оказывается, дохлые монстры продолжают пытаться переключать схемы, и даже успешно это делают. Например, постоянно включают mob_home (следовательно, до нее было что-то еще ?).

 

По-моему, в этом есть что-то не совсем нормальное...

У кого какие мысли по этому поводу ?

[mumie 2]

@Dennis_Chikin,попробуй делать проверки на жизнь/не жизнь монстров, думаю только это нужно делать глобальными апдейтами(правда думается мне, что это "секс двух друзей" в чистом виде). Хотя на самом деле не вижу проблемы, в том, что они "мертвяком" схемы переключают. Что именно тебя беспокоит?