Artos

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

@Serg.Ivan, а тебе не приходит в голову, что довольно глупо ожидать положительного результата от того, что ты какому-то предмету/объекту пропишешь в конфиге какой-то тобою названный параметр?! Также глупо ожидать, что та же консерва, после правки ее конфига (без смены класса!) начнет влиять на пуленепробиваемость, иль артефакт утолять жажду... Разработчики игры (GSC) относительно пси-здоровья заложили только внешнюю возможность читать параметр (psy_health) и влиять на него. И уж ты извини их, что не придумали задать параметр для аптечки ,который бы сразу на пси-здоровье влиял... а только придумали параметр в конфигах сталкеров psy_health_v. Ну а раз они такие бяки, то тебе остается или все же изучить немного скрипты и посмотреть как в модах управляются с пси здоровьем (изменяют параметр psy_health) или самому написать потребное (но уже не только в конфигах, а и в скриптах!).

@Dennis_Chikin, ответ может быть относительно простым: а) уборщик мусора в Lua ассинхронен и б) "клиентский объект" - объект движка, а коллбэки, о которых ты упоминаешь, это методы/свойства иного объекта - объекта биндера (это уже Lua, т.е. дочерний от "клиентского"). Т.о. если программист движка, который писал коды для обработчиков коллбэков, не озаботился синхронизацией с порожденными Lua-объектами, то ... "Хочешь чтобы не воняло - спускай в туалете за собою, не дожидаясь что это сделает уборщица." Можно и более пространно порассуждать, но тут уже потребуется каждый коллбэк (его алгоритм) рассматривать по-отдельности, и... что-то можно отнести к рудиментам, а что-то потребует долгих рассуждений и пояснений, но никак не может быть отнесено к рудиментам. Иными словами, даже однократного срабатывания "ненужного/забытого" коллбэка может быть достаточно для фатальной ошибки (вылета).

И по правилам и по сути, вопрошавшему достаточно было воспользоваться банальным поиском по порталу иль инету, чтобы по фразе "invalid_parameter_handler" получить ответ о том, с чем он столкнулся (см. справочник: #1). А вот отвечающему (и вторящему ему), следовало бы не только самому в справочник заглянуть, но и не мусорить "отсебятиной" в том же справочнике, нарушая правила топика (цитата: Если увижу, что запостили вылет, который здесь есть,...). Также, хочется обратить внимание на то, что очень часто некоторые отвечалкины стали общности зашоривать на частности, выдавая это за единственно верный ответ. Тот же @Потенциал указал только строки в логе об ошибке. Эта ошибка, как уже указано выше, говорит о не прошедшей проверке на валидность параметров. Ты же,@Старлей вместе с @*Shoker*'ом, начинаете зацикливать на каком-то nil'е и радиусе алайфа, выпячивая свои грабли перед другими... Не нужно в каждом случае пытаться упрощать, порою это не сокращает время поиска ошибки, а наоборот. Ответ: и/или и не только! ! Т.е. это можно расценивать и как спавн объекта и как ввод объекта в онлайн и вообще в иной ситуации. По вопросу видно, что ты так и не понял суть ошибки. При обработке некоторой ситуации была обнаружена ошибка значения параметра, о чем движок и сообщает в логе. Обнаружение ошибки возможно, например, и при установке метки на уже заспавненный и вышедший в онлайн объект и в множестве иных ситуаций. Если же ошибочный параметр присущь именно для онлайновых ситуаций (кривая анимация может быть только в онлайне!) - то и получит криворучка ошибки именно при выходе объекта в онлайн. Но(!), это никак не значит, что и у всех только в онлайне возможны ошибки по невалидным значениям параметров! В процитированной фразе ключевым является слово: "инициализируется" - именно это и отвечает за чтение значений параметров и присвоение их объектам, а уж в офф- иль он-лайне это или вообще к частностям (инициализируется метка для объекта) - это уже вторично, т.е. частность.

Один брякнул, второй попугайничает..., при чем как будто кто-то возражал... Ну что ж, попробуем поправить, дабы уже привычные погадалки в ответах ("вроде как"/"скорее всего") не расползались аж в справочники (#30): - никакой это не "побочный вылет функции, которая создаёт лог вылета", о чем уже не раз глаголит "Товарищ *Shoker*", а прямое следствие попытки чтения параметра из конфига игры, и уж тем более не зависит от радиусов A-Life. - "функции передан..." - что-то очень часто стало модным употреблять эту заВумность. Движок (упрощенно) собственно и состоит из кучки функций, которые обмениваются чем-то между собою . Не проще ли сказать, что при чтении движком параметра из конфига объекта происходит нечто не штатное?! Попросту говоря, происходит ошибка при чтении, а не при передаче (не прочитано то, что ожидается)! - "функции передан nil" - ну отчего же сразу так и 'nil'? Любое значение, которое не удовлетворяет ожидаемым условиям подпадает под эту ошибку. Кто-то забывает указать обязательный параметр. Кто-то умудряется вместо букв подсунуть числа иль наоборот. Ну а кто-то вообще кириллицей заставляет давиться движок... Так что nil'ом по большому счету и не пахнет в большинстве подобных ошибок (напомню, что 'nil' - это все же объявленное значение некоторой переменной, часто присваиваемое по дефолту). Ну и если тов. Старлей привык видеть подобные ошибки при кривых конфигах профилей монстров/сталкеров, то сути это не меняет, т.е. ошибка говорит не только о параметрах конкретного объекта или всего связанного с ним (логика/метки/...), и может обнаруживаться при спавне секции любого объекта, с ошибками при указании параметров. Просто большинство подобных ошибок всплывает именно при появлении кривых объектов в игре, т.е. на текущей локации.

@Dennis_Chikin, вредно заниматься болтовней... т.е. без вникания в суть/контекст - делать общие выводы. Мною дан ответ на исходный вопрос о "как сделать чтоб худ был отключен изначально", точнее дана подсказка как сделать, чтобы худ не включался. Так же, обратил внимание (прокомментировал) на "подводный камень", когда худ может включиться "самопроизвольно" и что может потребоваться для предотвращения этого. К моему сожалению, именно "вредный совет" (точнее ремарка) большинством (кто не любит копаться в скриптах), кому может потребоваться подобное отключение, и будет использоваться или даже используется. Для думающих там же дан иной совет, но почему-то тобою не процитированный - "переработь скрипты с использованием функций управления худами", так что каждый подбирает для себя по вкусу и по навыкам. Ну а твой "совет": - из области болтологии... любой "сценарный момент" выполняется после 1-го апдейта... Так что по твоему "совету" или ЕЩЕ не выключить (еще не запущена сцена), или УЖЕ не требуется, т.к. не включено. (иначе: это и есть переработка скриптов!) Примечание: Если человек затеял снять некое видео по геймплею и не хочет чтобы на экране был худ - то "вредного совета" более чем достаточно. Ну а для игры/мода с использованием фишки с отключением худа - в контекстве данного топика достаточно краткой подсказки о необходимости переработки скриптов, а не куцых "вредных иль полезных советов".

@J.A.A., вообще-то по перл-скриптам имеется специальный топик: "Universal ACDC и другие perl-скрипты", где и автор может ответить по существу. А вообще, ggrc.pl и распаковывает и упаковывает ((де)компилит), но не следует уповать на успех... Без манипуляций с SDK многое может быть недоступным. И поищи в сети версию ggrc.pl посвежее, например v0.7

@Serg.Ivan, не обращай внимание на очередной бред от @*Shoker*'а, и не вздумай удалять по его совету... движок тебя не поймет и все одно заставит вернуть все обратно (хотя из *db-архивов игры нужно еще постараться чтобы удалить ;-) ). За отображение худа (индикаторов миникарты, окошек с оружием/патронами и т.п.) отвечает в первую очередь движок, а уж xml-конфиги имеют вторичное значение и отвечают за "что и где будет показано". К твоему сведению, иконки худа изначально отключены и их отображение включается в биндере актора в методе спавна актора(actor_binder:net_spawn). Найди строку level.show_indicators() - и закомментируй, если не надобен. Однако, в игре в логике/сценах порою "худ" скрывается и вновь отображается скриптово ... а проверки состояния нет, поэтому придется постоянно "переотключать" командою: level.hide_indicators(), поставив куда-нибудь на апдейт актору или переработав скрипты с использованием этих функций управления худами.

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

@Stalkersof, мусорил бы ты "по теме", т.е. в топике по ковыряниям ТЧ... и заглянул бы в топик "Справочник по функциям и классам", дабы не гадать как нужно вызывать ту иль иную функцию. Для ТЧ пространство 'relation_registry' сильно ограничено и доступно только семейство функций "community_goodwill", которые оперируют именем группировки и идентификатором персоналии, относительно которого и работают. Ну а изменять в игре отношения целых группировок - это тебе не ЧН/ЗП... И если "изменяешь" что-то, то чтобы говорить об изменениях или их отсутствии - приводят все же нечто, с чем можно сравнивать.

@Saruman, следует все же различать собственно наличие сида у объекта и наличие этого сида в базе алайфа (в игре). По заданию сида объекту - выше уже все сказано и никаких непоняток или "не задается" не существует. А вот попадание в базу алайфа, чтобы по требуемому сиду можно было бы проверить наличие объекта с этим сидом в игре - это уже без перезапуска игры (или без правки движка) не получится. Не помогут и манипуляции с отправками в оффлайн и обратно. Т.е. или сразу спавни свой объект через алл.спавн, задав ему требуемый сид, или не ориентируй свои скрипты на проверку сида без перезагрузки игры. Вообще, немало и других способов "искать" требуемый объект в игре... чем тебе (для ТЧ) тот же поиск заспавненного объекта по имени не подходит alife():object("my_obj_name") ? Может и не так "красив" как по сиду, но не менее эффективен и дает тот же результат. ;-)

@Saruman, а с чего ты решил что "но помоему sid не задается", Если ты не покорежил функции net-пакетов, то все прекрасно задается. И, при установке SID'а в момент спавна объекта не требуются манипуляции с off-on-лайнами, т.е. значение заданное параметру доступно сразу (для клиентского объекта - по выходу его в онлайн). Только особенность проверки свеже-добавленного SIDa в базе движка имеет нюанс и не стОит использовать alife():story_object(SID) до перезапуска игры или манипуляций с off-on-лайнами.

@abramcumner, а вот это про что(?): К сожалению, многими слово "кастомдата" ассоциируется именно со строками из распакованного алл.спавна и они не подозревают о существовании иного... "Кастомдата" (aka customdata) существует в трех ипостасях: в виде параметра в секции спавна, в виде расписанного конфига в соотв.секции в all.spawn'е (который перебивает/подменяет параметр в секции спавна) и уже в игре в виде данных самого объекта. И то, что именно в "кастомдате" в алл.спавне нередко видят перенаправление логики во внешний файл, приводит к путанице, что воспринимают этот файл не как внешний конфиг именно логики, а как внешнюю "кастомдату". Что и произошло в рассматриваемом случае, кто-то когда-то вместо только логики указал все, что относится к кастомдате и это пошло гулять далее, в надежде что это работает... Иными словами, параметры, относящиеся именно к 'customdata' объектов следует задавать или в all.spawn'е или в соотв.параметре секции объекта (т.н. секции спавна), тогда и будут читаться и запреты на гулаги и иные условия. А то, что прописано в [logic] cfg = "внешний_файл" - это вынеcенный конфиг логики и не более. Примечание: в se_monster/smart_terrain тоже нет чтения внешних файлов, в них читаются параметры из того, что вернет движок: 'obj:spawn_ini()' - т.е. то, что он (движок) ранее прочитал из секции спавна перед моментом спавна объекта и запомнил в кастомдате заспавненного объекта.

Справедливости ради (и не только) замечу, что 'оригинал' (ТЧ) все же читает из сторонних файлов секцию 'smart_terrains', что видно, например, в se_respawn.script, где вычитываются настройки респавна и все неписи/монстры (не)ищут работу в гулагах. Также, в секциях спавна (см. в папке creatures) движок читает строку с указанным парамером 'custom_data' и соответственно внешний файл... так что все же можно задавать игнорирование гулагов (и не только) не только в алл.спавне. ;-) Однако это не относится к тому, о чем говорит @proper70, т.к. в его случае речь идет только о логике, т.е. 'xr_logic' читает из внешнего файла только секцию [logic], игнорируя все другое. Соответственно как раз запрет на гулаги в его случае и не работает... (однако все это уже для топиков "ковырялок", и не имеет отношения к данному топику)

@proper70, правильнее не латать и замазывать последствия, а исправлять причины, хотя тема и не проста. ;-)

@AndreySol, если искать себе искуственные заморочки - то их всегда можно найти! Вот только зачем их искать и навешивать шоры себе же и другим? Раз спавним актору в рюкзак, то и используем простейшее:

@AndreySol, не нужно оправдывать по сути чепуху(!). Если ты коллбэком на выход в онлайн ставишь требуемое значение состояния предмета, тем самым ПЕРЕКРЫВАЯ любые ранее заданные значения для серверного объекта, то на кой заморочка с нет-пакетами?! Твоя оправдалка может относиться только к случаю, когда ты тот же артефакт спавнишь куда-то на другую локацию, и он конечно же не выйдет в онлайн в текущей игре, а при переходе на его локацию - состояние будет "заводским"... Ну так и нужно различать, что если спавнишь предмет на текущей локации - то изменять нужно (можно) коллбэком на спавн, а если нет - то net-пакетами. Также, допускают ошибку, когда сначало спавнят предмет, например в то же инвентарь, а через некоторое время, а не сразу же в цикле спавна, net-пакетом пытаются изменить параметр(ы)... естественно, пока предмет не уйдет в оффлайн и не вернется в онлайн (вот он сэйв-лоад!) - то ничего не меняется. Ну и, есть конечно некоторые параметры у некоторых предметов (например у КПК), которые требуют особого подхода, но тут уж именно только нет-пакетами и спавн не в инвентарь, а с последующим трансфером... В общем, в данном случае с противогазами актора нет никакого смысла в дублировании net-пакетами! @Akella-96 aka SvD, кратко про амк-таймеры помянул выше. Расписывать неизвестный мне скрипт 'awrp_cop' не имею возможности и желания. По оригиналному скрипту от амк - воспользуйся поиском по многочисленным ресурсам в сети по моддингу. А еще лучше - замени на нормальные таймеры... А вообще, скрипт (script) - это сценарий, в котором все и описано, и тебе нужно бы почитать мануалы по Lua, чтобы читать и понимать то, что в скрипт кто-то когда-то написал и как это нужно/можно применять (раз уж используешь не свое).

@AndreySol, нет смысла дублировать одно и то же разными способами. Т.е. при спавне нового предмета можно или net-пакетом установить требуемое состояние, которое и получит клиентский объект при выходе в он-лайн или коллбэком с переданным ему значением изменить в момент выхода в он-лайн. Собственно функция (и алгоритм подмены противогаза) может быть такой (без внешних "приблуд"):

Ответ же очевиден - сохраняй как тебе удобно!Состояние предмета - число (0.0 ... 1.0) и считав его с прежнего предмета хранить можно и в локальной переменной и в глобальной. Если требуется сохранить в сэйве - то и тут хоть в pstor актору можно засунуть, хоть в отдельный файл... Записывать в кастомдату(?), хм..., я бы не стал... Писать старому предмету - так он же должен быть удален. Писать новому - так его же еще нет, а если есть, то проще сразу выставить требуемое состояние. Судя по приведенным кускам кодов, в функции del_antigas(params) вроде как раз и должно выставляться "прежнее состояние", где под params и подразумевается переданное на вход функции число, соответствующее требуемому состоянию нового предмета. Вот только запуск этой функции через дебри "старомодных" amk-таймеров скорее всего ошибочен, перепутаны аргументы, да и не позволяют эти таймеры передавать "пользовательские данные" (gas_cond) в качестве аргументов. AMK-таймеры принимают аргументами: имя таймера, временнЫе значения и имя функции, которую должен вызвать таймер, и не принимают иного. Т.о. нужно или использовать иной тип таймеров, позволяющий передавать (и при необходимости запоминать у себя в базе) нужный аргумент, или выносить полученный параметр 'gas_cond' наружу (из функции) и снаружи и читать функцией 'del_antigas'

@Карлан, повторюсь, НЕ захламляй, плз, топик своими ковырялками и "америками/велосипедами"! Тут задают вопросы и дают ответы/советы, а не переписывают сюда куски конфигов из оригинальной игры и свои "открытия" в них... Ведь уже дан дельный совет: - или ты собрался нам этот файл "растолковывать" на базе "не смотрел и не проверял, но поясню..."? 1. Каждый может для себя поставить иные цифры и твои "коридоры" поплыли... Так зачем возводить в константу и описывать то, что каждый может прочитать и изменить?! А вот как раз ограничитель (движковый предел), когда действительно меньше/больше нельзя (движок не переварит) - это тобою и игнорируется. 2. Не путай, упомянутые лимиты касаются автоматики движка, т.е. если заданные лимиты не превышены, то движок может менять отношения в зависимости от действий актера/перса (убил/обидел/подлечил/...). А "ручками" ни что не мешает и превысить эти лимиты, лишь бы движок не подавился. 3. Упомянутое тобою относится к персональным лимитам, т.е. пределы отношений персонажа и другого перса или персонажа и группировки. Однако бОльшую долю во всем этом (в общей формуле) играет именно отношения между группировками персонажей, о чем ты также не поведал... Напомню, что исходный вопрос касался: "...будет-ли ГГ автоматически(движково\по умолчанию) начисляться репутация и\или благосклонность ?" и все что после ответа malandrinus'а уже пустопорожний треп (ИМХО).

@Карлан, не стОит засорять топик и мозги другим подобными постами. Если уж так хочется донести до других то, что им неведомо, то "особо не ковырялся, но вроде там" ... "пока не тестировал" - ну ни как не выжется с "внесу кое какие разъяснения". Разъяснять свои домыслы оставь наверное себе, а в топик, если пишешь, то потрудись и покопаться и перепроверить! Даже цифры в файле game_relations.ltx говорят о том, что упомянутые тобою "коридор" для community_goodwill ну никак не меньше +-5000! А то, что в том же файле этот "коридор" поделен на диапазоны (terrible ... excellent , и т,п.) не означает, что за упомянутыми границами идут недопустимые значения. Аналогично и для "персонального" goodwill - не приводи цифры с потолка... Вот лучше бы перепроверил бы допустимые границы для "коридоров", т.к. не все в курсе когда увеличение приводит к сбросу в минус... И, заодно, перепроверил бы и пояснил бы другим, как зависят изменения персональных репутаций и/или благосклонностей, от групповых, дабы не возникало непоняток типа: "меняю/добавляю, а перс не становится дружелюбнее?"

Неверно! Запущенный коллбэк постоянно (аналогично апдейтам актора) вызывает функцию _precondition и, если она возвращает true, коллбэк отключается и вызывается функция _action

@Карлан, а это прочитать не пробовал, в частности: - про ключик -nofatal и в реадми к uACDC написано и много раз в топике говорилось...

@SUMRAK, неужели сам не можешь додуматься, что именно "влом отвечать"!

@banderos, ты прав(!), после трех дней проб и ошибок с различными версиями приблуд (аиврапперы/аикомпилеры) все же нашел вариант (с подсказки Колмогора, которая совпадает с твоею), которым можно получать некое подобие "чистого пака" исходных локаций. Т.е. это: как раз и приводит к усечению карты l12_stancia на один вертекс (129->128). Кому интересно: