Artos

@xStream, Вот с последними словами "Если грызут и хаят предшественников, на чьем труде учились - не айс. Если грызут и говорят, что их леденец круче и вкуснее, то пусть готовятся аргументировать и доказывать." - полностью согласен. Далее предлагаю "курильщикам" не продолжать скользкие темы, принижающие одних и выпячивающие других. Труд каждого модера не заслуживает критиканства и поношений, если делается от души, а не по принуждению и/или из корысти, какова бы минимальная польза от его труда не оставалась... И хотя тут "курилка", но все же лучше говорить, ворчать и спорить по существу, а не по личностям и пристрастиям.

Хм... Любить/бранить/хвалить/хаять и т.п. - конечно право каждого, но все же не должно на публичных форумах скатываться до голословного злопыхательства и подтасовок. (IMHO) @xStream, подтверди, плз, свои слова о "он натырил" конкретными фактами плагиата/воровства, или принеси извинения. 99,9% всех наработок по кодингу в СТАЛКЕРе основано на уже имеющихся наработках персвоисточника от производителей игры и последующих (мини)модах. Нужно быть глупцом, чтобы игнорировать труд других (кстати, чаще всего, выполненный именно для использования последующими кодерами!) и тужиться каждый раз изобретать велосипед. Ну а использование исходных материалов, выложенных/опубликованных в сети именно для использования в игре и создания последующих модификаций называть "натырил/своровал" - схоже с изливанием накопившейся желчи... Правильно замечено: (сорри, что не вовремя заглянул на форум)

Сменил (временно) Москву на глухую провинцию... , да и хобби уже более приземленные (в буквальном смысле). Интернет тут (в моей тверской деревеньке) как в 80-ые прошлого века, но вероятно потихоньку вновь влезу в кодинг... вот только комп из Москвы нужно будет привезти, т.к. на ноуте не развернуться... А вообще... привет всем(!). Смотрю у вас тут похоже жизнь (моддинг) все еще "булькает".

Да и не нужно изобретать! Первый сепаратор имеет смысл только во второй и последующих итерациях по уже усеченной строке. Ну как ты не поймешь, вроде как уже разжевал... Давай разберем такую строку, в которой заданы три состояния с синхронными звуками: state1@sound1|state2@sound2|state3@sound3 При первой итерации будет откушен кусок: state1@sound1 и останется: |state2@sound2|state3@sound3 Из откушенного будет определена 1-ая пара. Далее будет откушен: |state2@sound2 и останется: |state3@sound3 Из этого куска будет выделена 2-ая пара. Ну и напоследок из остатка будет выделена 3-я пара значений для состояния и синхронного для него звука. И все это будет упаковано в табличку и выдано функцией как результат - что и требовалось. Не требуется тут прикручивать сепаратор в начало строки. Ну а ежели прикрутишь, иль удалишь какую-нить "лишнюю" пару из строки конфига, оставив сепаратор - парсер все одно не споткнется и результат будет адекватным. , ты прав конечно, что можно и попроще все написать, но (!) все же имеем дело с наследием от оригинала и порою от многочисленных модов... А перелопачивать под новый патерн (пусть и более удобный и оптимальный) все уже имеющиеся конфиги - практически никто из геймдизайнеров/конфигеров не хочет. (тем более не так много тех, кто суть конфигов понимает). Вот и маются скриптеры с тем чтобы угодить "и нашим и вашим".

@Dennis_Chikin, задавая вопрос уточняй контекст. Ранее ты спрашивал в контексте функции parse_syn_data, в которой нет state = {}. Эта строка с приравниванием относится уже к иным функциям (parse_data, ...) и далее табличка state используется для вычитывания значений в конструкциях типа r_logic.pick_section_from_condlist, и соответственно, может быть таблицей или ... Ну а почему начальный '%|*' включен в патерн (ежели имеется)? - ну так попробуй исключить и увидишь, что если вынести из патерна, то при различных заданных строках (присутствует иль нет) совершенно иной результат будет. А вот '[^|]' - не выдирается, а исключается из захвата, т.е. все до этого символа попадает в захват, а сам последующий символ остается в остатке для следующей итерации. Иными словами на вопрос "Захват первого | в подстроку - он зачем оставлен ?" можно дать такой ответ: Строка последовательными итерациями режется по символу сепаратора тогда, когда этот символ не в начале строки, а после значимого куска. Этот кусок захватывается и разбирается на составляющие его значения, а остаток строки с символом сепаратора (он уже в самом начале!) откладывается до следующей итерации, где этот начальный сепаратор и отшвыривается. И так по всем сепараторам в строке... И, в общем почти нет разницы, отбрасывать сразу или при захвате конкретных значений по второму патерну. И вообще, если хочешь понять как работают патерны - читай мануалы и проверяй на практике (есть все же отличия для find и (g)match), на форуме этим можно о-о-очень долго заниматься. В данном случае требуется из строк конфигов получать заложенные в них значения, с чем и справляются без ошибок данные функции и патерны (проверено различными искусственными тестами и используется на практике). И, конечно же(!), вариантов написания патернов может быть НЕ один - выбирай по вкусу. Важен конечный результат с учетом оптимальности по производительности. И последнее: Разработчики GSC не стали писать распарсиватели для каждого параметра в схемах логики (meet/wounded), а решили обойтись тремя боле-менее универсальными функциями/патернами. Если тебе хочется производительность поставить во главе критериев - ничего не мешает понаписать более оптимальные для каждого параметра патерны/функции. Просто будет бОльшее кол-во строк в скриптах и ... больше возможности ошибиться в применении нужной (особенно при разработке/модификации).

Вообще-то не понял вопроса... т.к. в моих вариантах state - имеет строковое значение. Если ты спрашиваешь о возвращаемой таблице иль нИле - ответ ведь в самих скриптах! Смотри, например, в xr_wounded.script что распарсивается при "является ли текущий звук синхронным для текущего стейта" - ТАБЛИЦА! Т.е. если не будет таблицы - будет вылет, а пустая таблица "говорит" об отсутствии синхронизированного звука со стейтом. Хм, патерн подразумевает захват 'если таковой имеется'... и, если головою все же подумать , - в строке конфига можно задать для различных стейтов (состояний непися) различные синхронизированные звуки. Например, раненый лежит лицом к актору - просит актора аптечку, лежит спиной к актору - жалиться и стонет в пространство, ежели слегка подранен и припал на ногу - может и просто постонать... Ну, а ежели при настройках логики захотелось что-то убрать - то можно и позабыть стереть "лишний" разделитель. Вот и убивает патерн подобные "позабытости". P.S. А вот ежели не можешь использовать по какой-то причине abort'ами - не стОит уподобляться мартышке из басни дедушки Крылова, хулящей то, чего ей не потребно иль непонятно. И сама функция abort'a может быть как угодно доработана для информативности и движки бывают ра-а-азные. , в строке конфига можно задавать не только одно состояние (стэйт) требующее синхронизации со звуком... , вот и применяет разделитель (сепаратор) для каждого стейта. Точно не помню, но даже в оригинале для схемы раненого используются синхронизации на пару-тройку состояний, но это уже в индивидуальной логике смотреть нужно, а не дефолтные конфиги.

Если захотелось трогать, то нужно разбираться не столь с "как работает", а "как должно работать", т.е. что же скрипт (заложенный в него алгоритм) должен выполнять с заданной ему строкою в конфиге... Функция 'parse_syn_data' в цикле должна разбивать строку по маске-символу '|' и из первой ее части (подстроки) брать данные о звуке для статуса, разбивая подстроку по маске-символу '@'. И т.о. все что после '|?' (если имеется) - откладывается для разбора в следующем подцикле итерации по строке... Вот и должен конфигер писать в конфиге для логики не абы-что, а то, что требуется и должно быть прочитано и "понято" скриптом! Т.е. чтобы начиналось не просто с "реального", а с реально значимого.

И не нужно выдавать отсебятину за истину. Абсолютно бессмысленный совет/утверждение - т.к. строка из конфига логики "on_actor_inside = nil {+esc_kill_gunslinger}" полностью эквивалентна такой же "{+esc_kill_gunslinger} nil". Скрипт (xr_logic.script) разбирает эту строку, разбивая (распарсивая по маскам) на фрагменты и "от перемены мест" НИЧЕГО не изменяется, т.е. логика будет ИДЕНТИЧНА! Иначе, действия в любом слчае будут по-порядку таковыми: - проверяется наличие/отсутствие инфопоршней ( {+/-} ) и/или условий функций ( {=/!} ); - определяется (если указана) вероятность (~); - выдаются/убираются инфопоршни ( %+/-% ) и/или выполняются функции/экшены ( %...% ); - текущая секция логики сменяется следующей (или nil). Т.о. порядок указания условий-действий-секции в конфигах логики не имеет никакого значения (если, конечно, не указаны сложные составные куски, взаимовлияющие друг на друга, чего следует избегать)!

@Хемуль36рус, квесты на предметы ("find_item") оперируют секцией, по которой спавнится в игру предмет. В se_item.script все секции предметов, которые могут применяться для квестов, регистрируются в таксменеджере ( task_manager.get_random_task():register_target(self) ). В самом таскменеджере задания могут выдаваться только(!) при наличии в игре соответствующих предметов (определяются по (от)регистрации секций при спавне). Т.о. если хочешь выдавать задание на предмет - позаботься чтобы предметы этого класса регистрировались при их спавне в игру по своей секции в таскменеджере. Примечание: не все классы предметов в игре имеют соответствующие Lua-классы (скрипты-конструкторы) из которых можно было бы регистрировать предметы для заданий.

@Хемуль36рус, ответь, плз, на вопрос:"А что ты сам сделал чтобы понять 'почему' у тебя не выходит?" - ты отделил ошибку от алл.спавна (т.е. ошибки синтаксиса кастомдаты и схемы логики)? - ты локализовал ошибку до скрипта 'smski.script' или даже до функции 'smski.sid_sms'? - ты хотя бы можешь сказать, что твоя функция, отвечающая за выдачу СМСки вызывается логикой? ... и т.д. ... Причин великое множество, а ты предлагаешь нам гадать, а тебе "понимать"... а) Проверь, активируется ли твоя логика для твоего рестриктора (вывод нужного в лог в биндере схемы не сложно поставить); б) Проверь, вызывается ли твоя функция из логики схемы (вывод в лог из функции тоже не сложно написать); с) Если функция вызывается - проверяй аргументы и/или корректность самой функции (нам неведомой!). Судя по ее названию 'sid_sms' - в нее должен передаваться некий сид (стори_ид)... ну а если не вызывается, то, как уже упоминалось мною не раз, твой скрипт должен быть проинициализирован игрою(!), поэтому или потрудись это сделать или переноси свою функцию в xr_effects.script или arhara_dialog.script и перепроверяй.

@Хемуль36рус, после твоих пояснялок можно предположить что твой вопрос (заковыка) в общем не имеет отношения к алл.спавну. - "если инфопоршень убрать игра соответственно вылетает" - это означает, что логика схемы работает или как минимум идет разбор конфига логики. Чтобы не сильно зависеть от именно алл.спавн'а можно логику (ее конфиги) вынести в отдельный файл: ustom_data = <<END [logic] cfg = scripts\my_file.ltx END и экспериментировать уже с ним, и тогда гораздо проще перепроверить вызывается ли у тебя вообще некая функция smski.sid_sms (?) и не в ней ли загвоздка... @azrael1325, чтобы "через логику вызывать скрипты из сторонних файлов" требуется доработанный скрипт 'xr_logic', и он в Народной Солянке доработан под это. Если же доработка где-то отсутствует - будет "штатный" вылет с сообщением в лог ("xr_logic: scheme '%s' is not registered in modules.script" или "object '%s': pick_section_from_condlist: function '%s' is not defined in xr_effects.script").

Почему многие стали считать, что комп/приложения должны сами понимать то, что безграмотно пишет им человек? @Хемуль36рус, неужели не можешь сам проверить корректность твоей записи логики, тем более примеров в том же алл.спавне предостаточно? Уже "шапка" кастомдаты тобою исковеркана(!), а должно быть ( custom_data = <<END ... END ): custom_data = <<END [logic] active = sr_idle т.е. кастомдате объекта должно быть присвоено все, что находится между тэгами 'END'. Ну и сама строка в секции логики: [sr_idle] on_info = {+dat_hem_sms} %=smski.sid_sms% nil т.е. к 'nil' - не приравнивается что-то, а "если есть инфопоршень XXX - то выполняется функция FFF и логика сменяется на нИлевую секцию, т.е. отключается"...

Из игры (скриптов) невозможно "отследить открытую вкладку(Задачи/План/Журнал...) в PDA". Вкладками(фреймами) в КПК заведует движок и ничего не вызывается и не передается скриптам. Только доработка движка (или использование внешних "приблуд") даст такую возможность. И не может сработать! Помимо синтаксической ошибки, о которой уже указано выше, в написанной (без применения головы) функции спавнится объект (local npc = alife():.. ), а далее идут попытки net-пакетами обрабатывать amk.read_stalker_params(obj) ... Т.о., в лучшем случае, если функция не вылетит по синтаксису или по отсутствующим переменным, заспавненный объект (npc->obj) после спавна просто напросто будет удален, как не нашедший работу в каком-либо гулаге.

Информация в контексте вопроса о максимальном объеме net-пакета (см. #5412 и далее): (по некоторым причинам... излагать приходится несколько косноязычно... но вроде как достаточно понятно ) Имеется значение NET_PacketSizeLimit = 8192; //16384 Т.е. для ТЧ (SHoC) размер net-пакета должен быть не более 8192 байт, а для ЧН/ЗП соответственно 16384, однако(!) допустимые значения меньше объявленных/указанных. Это обусловлено тем, что для "склеивания в сэйв" - при обработке net-пакетов каждого игрового объекта для включения его данных в общий сэйв используются аналогичные функции имеющие те же ограничения и расходуются доп.байты... Эмпирическим путем определено, что расходуется порядка 512 байт (или менее). Т.о. при расчете допустимых размеров для элементов универсальных хранилищ (и вообще как ограничение для всех других объектов) следует использовать следующие значения: SHoC: NET_PacketSizeLimit = 8192 - 512 = 7680 bytes CS|CoP: NET_PacketSizeLimit = 2x8192 - 512 = 15872 bytes Примечание: Признаком переполнения net-пакета(ов) является зависание или фатальное прерывание игры на стадии записи сэйва игры. При этом лог-файл пуст(!), т.е. в лог-файле отсутствует какая-либо информация. В продвинутых способах записи в лог последней строкою будет упоминание о начале сохранений '* Saving objects':

@Zander_driver, зачем же свои предполагалки мне приписывать? С самого начало было сказано: - т.е. было сказано, что этот параметр может быть добавлен к серверному объекту смарттерейна. А про нет-пакет, как и про кастом-дату, говорилось именно о 'communities'. И как раз(!), этот параметр ('accepted_communities'), отсутствующий у движкового объекта(!), объявляется из параметра 'communities', берущегося скриптом из кастомдаты объекта (т.е. может быть прочитан и нет-пакетом). Т.о. ответ на твой вопрос "как изменить" уже и был дан ранее... Примечание: Прямое изменение параметра 'obj.accepted_communities' конечно возможно, но(!) будет действовать только на текущей локации, т.е. после перезапуска игры все вернется к значению 'communities' из кастомдаты(net-пакета).