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

[Artos 99]

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

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

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

 

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

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

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

 

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

 

 

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

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

[Artos 99]

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

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

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

 

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

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

 

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

 

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

 

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

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

[Artos 99]

 

 

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

 

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

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

state1@sound1|state2@sound2|state3@sound3

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

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

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

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

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

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

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

 

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