вдруг перекинут таки функцию из Вегаса, а заодно и еще с десяток нужных. Для них это пара пустяков
Это вроде бы и вообще пара пустяков. Ну, пара дюжин пустяков... Если бы у меня не было рвотного рефлекса на язык си - честное слово, давно бы написал плагин для FOSE с нужными мне функциями (у меня установлена пара плагинов разных авторов)... По совести, самая нужная была бы SetLinkedRef - динамическая линковка феерически упростила бы многое и ещё большее сделала бы возможным (подумать только - на ходу создающиеся маршруты патрулей, привязка package к чему угодно... сказка!). Всего-то одна функция нужна... Эх.
когда мы пытались заставить неписей набирать водную радиацию, то для определения нахождения в воде был предложен только абсолютно шаманский способ разбрасывания вокруг персонажа малоразмерных человечков...
Ничего не изменилось с тех пор. Там была немножко другая ситуация - там на первом месте было не locomotion ГГ, а мокрые ли у него пятки. Почему человечков и разбрасывали маленьких - чтоб плавали даже когда воды там ГГ по щиколотку. А тут требуется шаманство сходное, но немножко другое, в духе
SET SwimmerBase TO TempCloneForm Player SET Swimmer TO Player.PlaceAtMe SwimmerBase 1 Swimmer.MoveTo Player SET CheckValue TO Swimmer.IsSwimming Swimmer.Disable Swimmer.MarkForDelete
Очевидна тормознутость и нестабильность приёма (мы 3D-объекты творим да двигаем под ногами), но это как будто всё ещё единственный способ хоть как-то получить нужную информацию...
как проверить производится смена скорости на неписях только в зоне активной обработки, или вообще во всей игре?
Повлиять это могло бы только на закадровых путешественников вроде кентерберийских караванов... Даже не знаю, проверяются ли у них модификаторы скорости. Множитель бега по крайней мере караванщики не используют уже просто потому, что не бегают, но станут ли они медленне гулять, если им ноги переломать?.. Не соображу даже сразу, как это можно замерить... Low-Level процессы на то и лоу-левел, что их отодвигает от кормушки всяк желающий, и поди разбери он медленно идёт из-за хромоты или из-за того, что процессор съел кто-то другой
Может быть, стоит вовсе пересмотреть подход к задаче? Ну, скажем... При попадании в воду вешать минус Carry Weight. Да, ГГ в одних трусах будет плавать шустро - но это ведь как раз логично?
Как будто интересный вариант... Взять невидимую деревяшку мувабл статик, MoveTo Player, SetPos Z (5 + GetPos Z) чтоб не встряло в коллизии чего-то придонного - по идее должно начать всплывать. Хотя для стоящего в ванне по колено в коньяке ГГ оно тоже поплывёт... Гмм... Не похоже насчёт плавания, но жидкость как будто должна обнаруживаться. Главное что у меня вызывает сомнения в этой затее - это то, что отлов всплывания дело явно не однофреймовое, то есть о мгновенном результате нечего и думать...
Да уж... Как говорится, "все люди делятся на три категории: кто понимает числа и кто не понимает!"
Как из мелкодробных сделать ИКСные? Умножить на ИКС, как ещё-то...
SHORT DD SHORT HH SHORT MH FLOAT SS FLOAT tmpVar SET tmpVar TO GameDaysPassed SET DD TO tmpVar SET tmpVar TO 24 * (tmpVar - DD) SET HH TO tmpvar SET tmpVar TO 60 * (tmpVar - HH) SET MM TO tmpvar SET SS TO 60 * (tmpVar - MM) PrintToConsole "Дни: %.0f, часы: %.0f, минуты: %.0f, секунды: %.4f" DD HH MM SS
можно ли какой нибудь консольной командой заменить папку музыки которая играет в ячейке на другую?
Нет, такой функции не имеется ни среди стандартных, ни среди функций экстендера с известными мне плагинами. Если её изготовить, то, вероятно, будет работать по аналогии с SetCellImageSpace, то есть изменение вступит в силу после загрузки изменённой ячейки в игру заново (вход-выход, сохранение-загрузка и т.п.).
Нет там конфликта. Целочисленным переменным можно присваивать дробные значения. Дробная часть при этом отбрасывается. Твой скрипт не откомпилировался по какой-то другой причине.
Дни я брал, чтобы наглядно показать, как отделяется целая часть числа от дробной - в моём примере это исполнено трижды.
Образовалась у меня проблема в фолауте, и без содействия не вижу решения. По идее вопрос должен, конечно, задаваться где-то в теме "ой беда с модами", но чуется мне, что тут суровый шаман нужен.
Преамбула. Скриптовый эффект вот такого вида
SCRIPTNAME BlinkerEffectScript FLOAT Timer BEGIN ScriptEffectStart …IF GetItemCount Ammo10mm == 0 ……AddItem Ammo10mm 100 …ENDIF …IF GetItemCount Weap10mmPistol == 0 ……AddItem Weap10mmPistol 1 …ENDIF END BEGIN ScriptEffectUpdate …SET Timer TO Timer - ScriptEffectElapsedSeconds …IF Timer > 0 ……RETURN …ENDIF …SET Timer TO 5 …AddItem Caps001 1 END
Для начала обеспечивает, чтобы у непися имелось применимое оружие, а затем каждые 5 секунд роняет в карман монетку. Вот готовый микромод https://www.mediafire.com/?de5k1z1pug6cow7 с этим эффектом. Подключаем в третий фол (было бы интересно, как оно себя поведёт в вегасе - так же или иначе? наверное, скрипт надо перекомпилить помимо смены мастера), загружаемся куда-то и случайному подопытному NPC вставляем AddSpell ??000801.
Что происходит. На чётных монетках NPC колбасит. Минимальное проявление - видимое в руках/кобуре оружие исчезает. Исчезает визуально - 'GetEquippedObject 5" его по-прежнему видит. В дополнение к минимуму NPC может заклинить (встал по стойке смирно - хоть среди боя, хоть поперёк патрульного пакета с миниганом наперевес - и до следующей монетки, если доживёт, стоит колом). Также может наблюдаться неправильное размещение оружия в оружейном узле - вверх тормашками, задом наперёд и т.п. - ходьбе это не мешает, но, естественно, бой невозможен, поскольку оружейные анимации не находят оружие.
О чём прошу. Во-первых, подтвердить наличие феномена. Подцепить к игре микромод, повесить эффект на кого попало (хоть начать новую игру и взвесить на первого же папу) и убедиться, что оружие неумолимо глюкует с пятисекундным интервалом. По возможности проверить на ком-то во время боя.
И во-вторых - ради чего я пришёл именно сюда - поделитесь соображениями, что это за феерия и как с ней бороться?
Граждане сообщники, поучаствуйте кому не лень? Ну хоть тест исполните, чтобы убедиться, что это не только у двоих глючные фолауты...
Joopeeter,
Цитата Joopeeter
Повесил скрипт непосредственно на непися - всё ровно то же самое
Уточни-уточни! То есть в GameMode объектного скрипта, назначенного неписю, AddItem исполняет эту же феерию? Мне казалось ключевым, что скрипт эффектовый. Если и в GameMode опасно вызывать AddItem, это ж вовсе черепаху из-под слонов вышибает...
Добавлено (30 Сентября 2014, 19:43) --------------------------------------------- Добавочный тест...
SetConsoleOutputFilename >> 'blinkertest.txt' ToggleFlyCam PickRefByID 2EA4D AddSpell 08000801 Actor Effect 'Моргалище' added to Папа START: testing 'AddItem Caps001 1' START: pistol 1, ammo 100, caps 0 UPDATE: pistol 1, ammo 100, caps 1 UPDATE: pistol 1, ammo 100, caps 2 UPDATE: pistol 1, ammo 100, caps 3 UPDATE: pistol 1, ammo 100, caps 4 UPDATE: pistol 1, ammo 100, caps 5 qqq Bye. SetConsoleOutputFilename >> 'blinkertest.txt' ToggleFlyCam PickRefByID 2EA4D AddSpell 08000801 Actor Effect 'Моргалище' added to Папа START: testing 'RemoveItem Ammo10mm 1' START: pistol 1, ammo 100, caps 0 UPDATE: pistol 1, ammo 99, caps 0 UPDATE: pistol 1, ammo 98, caps 0 UPDATE: pistol 1, ammo 97, caps 0 UPDATE: pistol 1, ammo 96, caps 0 UPDATE: pistol 1, ammo 95, caps 0 qqq Bye.
Первый тест - оригинальный скрипт с добавленной отладочной печатью: пистолет моргает. Второй тест - замена проверяемой функции: ничего не моргает, пистолет не исчезает, патроны исправно вычитаются. Joopeeter, уточни что ты делал чтобы пропал пистолет!
как именуются оружейные шрифты? Решил кольт затекстурить
Я бы сказал - не забудь на видном месте воткнуть логотип кольта, а шрифт выбирай от балды... В основном на кольтовских образцах писалось рублёным шрифтом - бери хоть Arial...
Изменение репутации для пользователя Ipatow
IpatowOffline
Сообщение №1242
| Тема: ВОПРОСЫ по моддингу
написано: 30 сентября 2014, 21:32
| Отредактировано: Ipatow - 30 сентября 2014, 21:36
оружие тоже начинает пропадать из рук и заново выниматься из кармана. Причём, как и с эффектом, на каждой крышке, а не на чётных или нечётных.
Ээ.. Уточни насчёт "как и с эффектом" - добавление из эффект-скрипта должно через раз блокировать оружие до следующего добавления, а добавление из объект-скрипта вызывает только переэкипировку, то есть если NPC хочет держать оружие в руке, он заново экипированное заново и вынимает из кобуры, без "мёртвого" периода, когда он вообще неспособен пользоваться оружием. Оно работает как я сейчас сказал или как-то иначе?
интересует такой вопрос, можно ли изменить появление ГГ? Поменять место и персанажей или просто сделать чтоб ГГ начинал игру на новой локации?
Не так и мало модов, реализующих альтернативное начало игры... К сожалению, оно регулярно сюжетно конфликтует с главным квестом, уши которого торчат по всей территории - вроде того, что ты начинаешь игру как бы приезжим торговцем из Монтаны, и вдруг "ой как ты на папу похож!" Так или иначе, никаких принципиальных препятствий сделать подобное нет.
Artem13, ты не проверил - глюк с блокировкой оружия у тебя воспроизводится? Если нет трёшки - хотя бы на вегасе посмотреть...
Цитата Artem13
А чем тебя стандартный вариант с левел-листами не устраивает и чем твой кардинально от него отличается, если ты им постоянно патроны спауниш? Или у тебя спаун ограничен по времени? В качестве альтернативы можно попробовать способ "от обратного" - т.е., например, в начале боя, сначала добавлять им пачку патронов, а потом периодически их ремовать.
Не постоянно. Ограничение не по времени, а по количеству. Скажем, автоматчик по ходу стрельбы полдюжины магазинов получит - но если не хватило этого, то всё равно не в коня корм, и пусть за монтировку берётся, раз стреляет так бестолково.
В начале боя выдать сразу весь боекомплект, а после смерти или в конце боя убрать лишнее? Во-первых, IsInCombat - оно от первого алерта. "Чу! Я слышу шорох!" - и боевой AI включился. В этот момент по такой схеме патроны уже в кармане, и их можно красть. Во-вторых, достаточно одиночного AddItem, чтобы вывихнуть оружие неписю. В-третьих, несколько замедленный разгон статов-скиллов не перестаёт быть бедой только потому, что его немного замедлили...
Как узнать порядок загрузки без использования сторонних менеджеров?
С использованием стороннего FOSE/NVSE - GetModIndex, а в голой игре только "на живца" (наподобие квест-скриптом "Player.AddItem вещь-из-мода 1" и смотрим в ShowInventory префикс)...
Смущают эффекты с блоком ScriptEffectUpdate на всех вокруг неписях. Не ты ли объянял, что они самые для производительности тяжёлые?
В их использовании большой риск, это так. Так же, как на тракторе можно задавить больше народу, чем на санях, запряжённых собаками - означает всего лишь более высокие требования к отвественности, внимательности и аккуратности того, кто за рулём. Вся эта тема - лишний пример того, насколько велик риск: я неправильно оценил влияние AddItem на 3D-мир, и хотя проблемы с производительностью я как будто не создал (всё изготавливается и тестируется на довольно-таки маломощном компьютере), проблем таки навылазило...
Нет, мы оставляем патроны в покое, не трогаем их количество в инвентаре, ничего не добавляем в начале боя и до поры позволяем им быть бесконечными. А через пару минут имитируем, что непись все патроны расстрелял - отбираем их у него.
Преодолевая желание спорить только потому, что идея не моя... Я соглашусь, что такая имитация будет достаточно убедительной, когда речь идёт о противниках и прочих не-союзниках. Но когда первые две минуты мои компаньоны стреляют на халяву, а потом либо берутся за сапёрные лопатки, либо, если я как босс не поленился в нужный момент выдать каждому ещё один патрон, опять задаром поливают местность крупнокалиберным... Тут твоё решение уже не кажется особенно перспективным
Начиная с конца - сама идея абилки в перке, подвергшаяся критике сразу после появления беседковского фолаута, вовсе не абсурдна. В одной из ипостасей перк это ништяк, который может получить ГГ при повышении уровня. Абилка - вполне разумный пример ништяка - но при левелапах не раздают абилки, там можно взять только перк. Поэтому такое применение абилки в перке совершенно рационально.
Использование абилки в компаньонском перке вегаса - было бы разумно, если бы оно работало так, как хотели изобретатели CompanionSuite "Спутниковый пакет" [PERK:0015C571], то есть перк вывесился на старте игры и при найме каждого компаньона абилка сама у этого компаньона включится и при увольнении сама выключится... Поскольку, как ты лишний раз доказал, для абилки из перка AddPerk-с-единичкой ничем не отличается от AddSpell-всем-текущим-тиммейтам, в этих перках абилки ни к чему.
CauselessRebel "Бунтарь" [PERK:0017714F] добавляется в диалогах - [INFO:0015A806] ("Да, мне не стоило даже приходить сюда. Я знаю. Бедные люди./В любом случае, я мало чем могу помочь./Наверное, будет лучше, если я не буду даже пытаться.") и ещё трёх, сопровождается FollowerMessageVeronicaUpgradeUnarmed [MESG:0016666C].
Тот факт, что 4 стандартных компаньонских перка, вешающихся именно на компаньонов (не путать со всякими FullMaintenance "Full Maintenance" [PERK:0015D2BC] или Spotting "Наводчик" [PERK:0015C60C]), прекращают работать после первой же загрузки игры... Давай что ли опишем баг в общественно заметных местах? Ну или, может, кто-то из аудитории хочет провести независимую экспертизу?
как пользоваться этим bForceNPCsUseAmmo=1? А то я хотел посмотреть, как оно влияет на играбельное и неиграбельное оружие, но что-то так и не понял, куда это надо вписывать...
Насчёт тиммейтов и неиграбельных патронов. Я временами феерически невнятен в выражениях, то называю одно и то же разныим словами, то одним словом разные вещи ("Вот тут где sex что писать? - ну как что, пишите мальчик или девочка! - Да.. Мальчик.. Девочка.. Иногда верблюд..."). "Команда игрока" по моим представлениям - не только PlayerTeammate. Это рейнджеры в отеле, это рабы на безголовом мемориале, это кто угодно, кто дерётся за меня, на моей стороне. И это ещё без модов...
как можно сделать счет через глобальные переменные например: Ранг+1 как набирается 10 ранг повышается,так вот как это сделать,чтобы это всё считалось и повышалось автоматически?
Как сделать? Я предлагаю сделать это с наслаждением!
Что ты там считаешь, что там должно повышаться? Ну допустим, что это неважно и в этой части у тебя нет вопросов. Тогда создаёшь глобальную переменную в меню Gameplay -> Globals..., создаёшь квест (флажок автозапуска, задержка по вкусу), создаёшь и назначаешь этому квесту скрипт... Почему, кстати, именно глобальную переменную нужно, а не подойдёт квестовая из этого скрипта? Ну неважно, допустим, что ты или хочешь её значение включать в реплики диалогов или использовать в левел-листах или вовсе в условиях неважно чего... Хватает мест, где нужен именно глобал... Ну и в том скрипте того квеста считаешь то, что хочешь считать, используешь ту глобальную переменную так же невозмутимо, как если бы это была собственная переменная скрипта, проверяешь, вычисляешь, по результатам что-то там повышаешь... Примерно так это обычно делается.
Хочешь больше подробностей - ставь задачу подробнее.
для прояснения того замысла в части, касающейся неписей-союзников
Пока не пытаешься вооружить рейнджера гранатами, реверс-пикпокет прекрасно работает... Мне кажется, что постольку поскольку AddItem вызывает проблемы, из двух остающихся вариантов - обезоруживание по таймеру без включения расхода патронов и включение расхода патронов с раздачей направо и налево богатырского боезапаса - уж лучше пусть америка по колено в патронах будет, чем кому-то будет позволено стрельнуть задаром
Где-то я читал, что использовать несколько одинаковых блоков - плохо
Я не уверен, что это именно плохо (на мой взгляд некрасиво, но чтобы именно чем-то плохо - с чего бы?). Не знаю, как именно работает компилятор скриптов, но я бы ожидал, что уже он попросту склеивает однотипные блоки в один - пусть в текстовом исходнике несколько блоков идентичного типа, в исполняемом коде все они будут одним куском. Гммм... Что я помню про блоки... Помню упоминания о том, что порядок блоков может играть роль - звучало наподобие того, что если какой-то там блок не первый, то он и не будет работать... Если так, то это баг (да, небезызвестный и с найденным решением), а не штатное поведение. Помню, что поиск блока идёт до первого найденного - то есть блок с более узким условием надо ставить прежде более широкого ("MenuMode 3" прежде "MenuMode", "OnHitWith Hammer" прежде "OnHitWith HammersList" etc.)... Будут ли блоки с тем же параметром склеиваться в один? Хотелось бы думать, что да, потому что иначе другой такой же найден и выполнен не будет (в последовательности "OnAdd Player", "OnAdd Player", "OnAdd" второй никогда не сработает, если не вклеен в первый). При всём при этом использование одинаковых блоков не криминал - и если кто-то хочет так писать из эстетических соображений, вреда от такой эстетики нет.
Изменение репутации для пользователя Ipatow
IpatowOffline
Сообщение №1253
| Тема: ВОПРОСЫ по моддингу
написано: 5 октября 2014, 12:06
| Отредактировано: Ipatow - 5 октября 2014, 12:07
при создании своего плагина я смог использовать только один esm файл (point lookout) помимо fallout 3 esm. Другие esm гек не хочет подключать. Как это исправить?
в фоле 6 типов пакетов добавления денег и кажется пара из них рандомные
Я извиняюсь - я не понял смысл этой фразы. "Пакетом" обычно называют Package - но какое отношение Package может иметь к количеству валюты у торговца? Ну, не считая того, что у пакетов есть скрипты, которые могут исполнить практически всё, что доступно скриптам... Обычно до того, как ГГ принёс что-то на обмен, инвентарь торговца определяется исключительно набором левельных объектов, понапиханных ему в карман, Merchant Container и прочие доступные для торговли контейнеры - причём на резетах инветнарь обнуляется и снова наполняется из того же источника, а потому скопиться капитал не может. А те левельные объекты далеко не тысячи монет содержат... В стандартной игре если у торговца денег тыщи - значит, их этому торговцу принёс ГГ, причём недавно. И на первом же резете тыщи испарятся, оставив обычное количество кассовой наличности...
у половины тамошних торговцев товар и крышки не обновляются
То есть они и накопить могут столько, что переклинит? Злоба... Я в этом смысле чувствую себя в безопасности, поскольку один из первых модов, которые безоговорочно обосновались у меня в игре, это "пообрывать Never Resets всем, кому он не по делу"... Но то, что в стандартной игре вот такие грабли выложены на оживлённом перекрёстке, это удручает.
на всех сундуках специально просмотрела и поставила галку респаун
Ещё проверить Encounter Zone помещения, если прямо референсу не назначен - на предмет того самого Never Resets. А то будет как мне товарищ описывал - он заманивал респонящихся агрессивных неписей в интерьер под EZ с флагом Never Resets, там их убивал - и оставались там навечно все эти трупики с флагом Respawn...
как сделать чтоб переход между уровнями был как в dlc the pitt (когда ты можешь поехать на ручной вагонетке и у тебя выскочит сообщение желаешь ли ты отправиться на другую локацию)?
Ну, слово "уровень" в смысле "территория" - оно не из этой игры... Да так же и сделать, как на всех больших сюжетных переходах - не просто дверь, которая телепортирует тебя в другое место (неважно, в форме вагонетки дверь или кресла или ещё чего-то - двери сплошь и рядом именно телепортом занимаются), а более сложный активатор, который при тыкании мышкой сначала вывешивает сообщение с кнопками, и только потом, возможно, ГГ куда-то телепортирует. Разберись в трёх составных частях - как переносить ГГ в другое место, как делать интерактивные вывески на экране и каков принцип работы активаторов - а дальше уже без проблем соберёшь из этих частей то, что надо.
AddItem, SetCombatStyle и непредвиденные последствия
Каждый раз, когда вы вызываете функции AddItem или SetCombatStyle в адрес NPC, вы, возможно, меняете характеристики этого NPC.
Это не зависит от способа вызова функций - результат вызова из консоли тот же, что при вызове из скрипта, будь то скрипт объектный, эффектный, квестовый или один из множества видов безымянных скриптов (скриптовые вставки диалогов, пакетов и.т.д.). Каждый вызов функции AddItem вызывает переоценку экипировки NPC, в результате которой будут экипированы наиболее подходящие этому NPC предметы из имеющихся у него в инвентаре (покойники тоже переоденутся не моргнув глазом), Object Effect каждого из этих предметов будет добавлен этому NPC, и каждый Base Effect каждого из этих Object Effect будет на этого NPC наложен - при этом если смены экипировки не произошло (наиболее подходящее и так уже было надето), то Object Effect будет добавлен повторно, без отмены ранее добавленного этого же Object Effect, и все Base Effect будут наложены "ещё в один слой". SetCombatStyle отличается тем, что надето самое подходящее будет только оружие, но эффекты всей уже надетой брони всё равно снова отработают. Сколько раз вызвана любая из этих функций, в столько "слоёв" и будет наложен каждый энчант. Насколько это существенно? Давайте продемонстрируем. Берём стандартного персонажа игры, вместо всего имущества выдаём стандартный предмет игры с развесистым эффектом (сила +1, ловкость -1, сопротивление радиации +10, тяжёлое оружие +5) и начинаем AddItem этому NPC в карман бутылочные крышки по одной.
SCRIPTNAME AddItemGoGoEffectScript FLOAT Timer BEGIN ScriptEffectStart …RemoveAllItems …AddItem MS10LindensOutcastPowerArmor 1 END BEGIN ScriptEffectUpdate …SET Timer TO Timer - ScriptEffectElapsedSeconds …IF Timer > 0 ……RETURN …ENDIF …SET Timer TO 5 …AddItem Caps001 1 END
Характеристики, которые броня должна была немного увеличить, устремляются в бесконечность (да, работающие значения ограничиваются допустимым максимумом - как мы видим, значение силы выше 10 уже не даёт прироста переносимому весу - но мало того, что скачок оружейного навыка с 12 до 100 не ерунда, так ведь любые скрипты, запрашивающие значение Actor Value, увидят именно эти безумные цифры!), а характеристики, которые броня должна была чуть-чуть уменьшить, обрушиваются в ноль (упаси вас беседка попросту спросить в скрипте значение какой-нибудь ловкости и что-нибудь на него разделить в полной уверенности, что оно бывает только от единицы до десятки).
Если базовые эффекты были скриптованные - они тоже накладываются повторно, но с дополнительными ужасами. Во-первых, все эти тысячеслойные скрипты жрут процессорную мощность в тыщу глоток, как бы экономны они ни были, и откусывают память под свои переменные (у каждой копии они свои) в тыщу укусов. Это безошибочная дорога к CTD. Во-вторых, если скрипты сколько-нибудь хитрые... Вот, скажем, скрипт рабского ошейника. При надевании меняет агрессию на смирность и т.п., при снятии возвращает то, что было перед надеванием. Но coup de grace тут в том, что снимаются эффекты - и копии скрипта отрабатывают финишную секцию - в произвольном порядке. И если этот носитель ошейника успел словить хотя бы один AddItem, то при снятии ошейника шанс на то, что последней финишиует первая копия, которая одна только и помнит правильную агрессию и т.п., не выше 50/50. Такого рода энчант плюс AddItem - и параметры NPC безвозвратно запороты навсегда.
И каково будет резюме? Ну, что тут можно нарезюмировать... Не применяйте без необходимости к NPC функции AddItem и SetCombatStyle, осмотрительно планируйте объектные эффекты - и проверяйте на выход за пределы значения, даже если они получены из вроде бы достоверных источников.
Для добавления предметов в инвентарь NPC без многослойного наложения эффектов можно использовать RemoveAllItems. То есть вместо NPCref.AddItem Item Count пишем MyContainerRef.AddItem Item Count, а затем MyContainerRef.RemoveAllItems NPCref - и предметы у NPC в инвентаре, и энчанты ничего не заметили.
Это не поможет NPC, который выпьет ядер-колы (родной скриптовый эффект игры исполнит additem caps001 1 со всеми последствиями), но по крайней мере ваша совесть останется незапятнанной
Если вы сами не используете "криминальные" функции, но ваши моды назначают одежде эффекты - можно избавиться от многократной правки параметров NPC, изменив механизм работы эффектов.
Как? 1. Добавляете каждому Base Effect вашего Object Effect условие GetIsID Player == 1 (на ГГ эффекты будут работать как до поправок, и в описании предмета эффекты будут показываться как положено, но на NPC они вешаться и потому размножаться не будут). 2. Создаёте Actor Effect с теми же Base Effect (которые не должны иметь флага No Duration и длительность действия необходимо в Actor Effect указать; поскольку броня надевается условно навечно, длительность 3650 дней подойдёт). 3. Создаёте новый скриптовый Base Effect с такого вида скриптом:
Код
SCRIPTNAME MyBaseEffectScript SHORT Control BEGIN ScriptEffectStart …IF (IsSpellTarget MyActorEffect) == 0 ……CastImmediateOnSelf MyActorEffect ……SET Control TO 1 …ENDIF END BEGIN ScriptEffectFinish …IF Control ……IF (IsSpellTarget MyActorEffect) ………Dispel MyActorEffect ……ENDIF …ENDIF END
и добавляете его в оригинальный Object Effect с условием GetIsID Player != 1. В результате существенные эффекты будут на NPC накладываться ровно один раз, и вы не получите терминатора, который одним пинком убивает любого противника только потому, что имеет на фуражке IncreaseUnarmedDamage, а какой-то соседний мод то и дело разбрасывает по карманам присутствующих какие-нибудь токены...
Однако не забывайте, что в такой конструкции один эффект - тот новый скриптовый - будет наложен в миллион слоёв. Поэтому очень желательно, чтобы скрипт был как можно меньше и проще - а ScriptEffectUpdate лучше не использовать вовсе.
Ни ячейке, ни контейнерам в ней никакие зоны не назначены.
Возможно, в вегасе NoZoneZone ведёт себя как-то иначе? Я отчётливо понимаю взаимодействие флага Respawn на объектах с флагом Never Resets на зоне, но только когда зона назначена. Может, для стабильности результата стоит там явно зону вписать? Ну то есть если мы берёмся это как-то лечить...
Мы Вконтакте
Так или иначе, никаких принципиальных препятствий сделать подобное нет. 
