Дляначала я сделал тестовый перк с Ability и наиболее интересными EntryPoint’ами, тестовое оружие и тестовую мишень.
Специально при первом тесте не стал брать стандартные перки, абилки и оружие во избежание “незаметного влияния” других факторов.

TestPerk01:
EntryPoint          [CalculateGunSpread][MultipleValue]== 0.00
EntryPoint           [CalculateWeaponDamage][SetValue]== 10000.00
EntryPoint     [ModidyDamageThreshold Attacker]     [AddValue]== 25000.00
EntryPoint     [ModidyDamageThreshold Defender]      [AddValue]== 25000.00
EntryPoint           [ModidyAttackSpeed][MultipleValue]== 5.00
EntryPoint           [EquipSpeed][MultipleValue]== 5.00
EntryPoint           [HasImprovedDetection][SetValue]== 1.00
Ability            [TestAbility01]

TestAbility01:
[RestoreHealth]== 5

TestWeapon01:
Damage:         2500
FireRate:         1
MinSpread:      0.00
#Projectiles:    1

TestWeapon02
Damage:          2500
FireRate:          1
MinSpread:       0.00
#Projectiles:     10

TestTarget01
Health:             50000
DT:                   15000

Сделал для ГГ спецберетку, чтобы надевая/снимая ее, быстро и удобно добавлять/убирать тестовый перк (не стандартный во избежание конфликтов) в любой момент игры не залезая в консоль, которая как оказалось весьма глючная падла…

SCN TestBertka01Script
Short XXX     [я решил не спрашивать “HasPerk или не Has?” а пойти более простым путем]
Begin GameMode
if ( XXX == 0 )
if ( Player.GetEquipped TestBeretka01 > 0 )
if ( Player.IsWeaponOut > 0 )
Player.AddPerk CalmHeartPerk 1
Set XXX to 1
Endif
Endif
Endif
END
Begin GameMode
if ( XXX == 1 )
if ( Player.GetEquipped TestBeretka01 < 1 )
Player.RemovePerk TestPerk01 1
Set XXX to 0
Endif
Endif
END
Begin GameMode
if ( XXX == 1 )
if ( Player.IsWeaponOut < 1 )
Player.RemovePerk TestPerk01 1
Set XXX to 0
Endif
Endif
END

Затемдобавил в стандартные скрипты Буна и Кэсс фрагменты, которые визуально (и как оказалось полностью достоверно) показывают наличие добавляемой перком Ability по принципу “есть абилка – надета шляпа”.

scn BooneSCRIPT (фрагмент)
.........................
BEGIN GameMode
if ( IsSpellTarget TestAbility01 > 0 )
if ( GetEquipped HatNCR1stReconBeret < 1 )
EquipItem HatNCR1stReconBeret 1
Endif
Endif
END
Begin GameMode
if ( IsSpellTarget TestAbility < 1 )
if ( GetEquipped HatNCR1stReconBeret > 0 )
UnEquipItem HatNCR1stReconBeret 1
Endif
Endif
END
…………………….

scn RoseofSharonCassidyScript (фрагмент)
.........................
Begin GameMode
if ( IsSpellTarget TestAbility01 > 0 )
if ( GetEquipped CassHat < 1 )
EquipItem CassHat 1
Endif
Endif
END
Begin GameMode
if ( IsSpellTarget TestAbility < 1 )
if ( GetEquipped CassHat > 0 )
UnEquipItem CassHat 1
Endif
Endif
END
…………………….

После чего осталось только проверить абилки на работоспособность для пущей достоверности. Наличие EntryPoint пришлось определять по работоспособности чисто экспериментально.

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

Моих компаньонов можно нанимать хоть всех сразу, поэтому я решил взять для теста людей поскольку у того же Рэкса оружейные EntryPoint'ы сложнее тестировать.

Результат теста: [Ab–Ability, EP–EntryPoint, Т1-Бун, Т2-Кэсс]

Взял перк - Нанял Т1, Т2: ----- Ab нет, EP не работают без вариантов.
Нанял Т1 – Взял перк – Убрал перк: ----- Т1 Ab нет, EP нет.
Нанял Т1 – Взял перк – Уволил Т1: ----- Т1 Ab есть, EP нет.
Нанял Т1 – Взял перк – Уволил Т1 – Нанял Т1: ----- Т1 Ab есть, EP есть.
Нанял Т1 – Взял перк – Нанял Т2: ----- Т1 Ab есть, EP есть; Т2 Ab нет, EP нет.
Нанял Т1 – Нанял Т2 – Взял перк: ----- Т1 Ab есть, EP есть; Т2 Ab есть, EP есть.
Нанял Т1 – Нанял Т2 – Взял перк – Уволил Т1 – Убрал перк – Уволил Т2: ----- Т1 Ab есть, EP нет; Т2 Ab нет, EP нет.

Нанял Т1 – Нанял Т2 – Взял перк – Save/Load: ----- Т1 Ab есть, EP нет; Т2 Ab есть, EP нет.
Нанял Т1 – Нанял Т2 – Взял перк – Save/Load – Взял перк: ----- Т1 Ab есть, EP нет; Т2 Ab есть, EP нет.
Нанял Т1 – Нанял Т2 – Взял перк – Save/Load – Убрал перк – Взял перк: ----- Т1 Ab есть, EP есть; Т2 Ab есть, EP есть.

Вывод:
1). Перк срабатывает разово, в момент добавления/удаления. Срабатывает только на персонажах которые на момент добавления/удаления имеет статус Teammate'а. Чтобы перк заработал его нужно добавлять после того, как персонаж станет Teammate’ом.
2). Статус Teammate – обязательное условие для работы EntryPoint’ов. Если уволить компаньона не снимая с ГГперк, то у компаньона останутся и будут работать все Ability,добавленные перком. EntryPoint’ы также останутся но работать не будут.
3). Ability, которые имелись у компаньонов на момент Save/Load сохраняются и полностью работоспособны вне зависимости от того, был ли компаньон на момент Save/Load собственно Teammate’ом. EntryPoint’ы в случае Save/Load удаляются и перестают работатьбез вариантов.

Единственный способ восстановить работу EntryPoint’ов на компаньонах после Save/Load, убрать (обязательно), а затем снова добавить перк.

Так что добавлять/убирать “компаньонские” перки в диалоговых скриптах как-то не вариант – слишком много мест, где это придется делать. Проще и надежнее это делать в собственных скриптах напарников, используя проверку на Teammate’ность.

Стандартные перки работают полностью аналогично тестовым.

Если интересует работоспособность наиболее интересных EntryPoint’ов то:
Calculate Gun Spread –                             работает
Calculate Mine Explode Chance –              работает только на ГГ
Calculate Weapon Damage –                    работает
Equip Speed –                                           работает
Has Improved Detection –                         работает
Has Unarmed XXXXX Attack –                    работает только на ГГ
Modify Attack Speed –                               работает *
Modify Damage Threshold (attacker) –      работает **
Modify Damage Threshold (defender) –     работает **
Reload Speed -                                          работает
* - Изменяет скорость атаки в самом прямом смысле т.е. изменяет время, которое требуется на сам выстрел но не интервал между выстрелами. Чтобы было понятнее, изменяет скорость движения руки/оружия при рукопашном ударе но не интервал между ударами. Имеет смысл использовать только с многозарядным оружием, либо в рукопашной - для ударов "на опережение".
** - DT обретает полную функциональность только при GS-параметре fMinDamMultiplier = 0.0  При стандартном значении fMinDamMultiplier = 0.2 любое оружие наносит минимум 20% от своего номинального урона при каждом попадании даже если броня считается не пробитой.

Теперь по перкам, которые ты хотел проверить:
Перк "Calm Heart" полностью работоспособен. Save/Load'ом не сносится.
Перк "HandOfVengeance" работоспособен до Save/Load'а.
Перк "Old Vaquero" работоспособен до Save/Load'а.
Перк "CauselessRebel" не нашел чтобы где-то добавлялся. Если добавить то работоспособен до Save/Load'а.
Перк "BondsOfSteel "  не нашел чтобы где-то добавлялся. Если добавить то работоспособен до Save/Load'а.

З.Ы.И как я вообще мог на эти чертовы Ability переключиться?  Тем более начать добавлять Ability через перк. Извращение-то какое. Никогда этой фигней не занимался, всегда AddSpell использовал, а тут вдруг… Ведь с EntryPoint’ов начинал – именно они представляют в перках основную и наверное единственную ценность.  А с Ability в итоге вообще все в порядке оказалось…

Расход патронов.

bForceNPCsUseAmmo = 0

Обычные (не Teammate) NPC'ы расходуют патроны при стрельбе из оружия у которого:
1. Playable - флажок стоит
2. NPS Use Ammo - флажок стоит
3. Ammo Use > 0

Teammate'ы расходуют патроны при стрельбе из оружия у которого:
1. Playable - флажок стоит
2. NPS Use Ammo - без разницы
3. Ammo Use > 0

Оружие у которого:
1. Playable - флажка нет
2. Ammo Use > 0
Не расходует патроны но требует их наличия

Оружие у которого:
1. Ammo Use = 0
Не расходует патроны и не требует их наличия

bForceNPCsUseAmmo = 1

Оружие у которого:
1. Ammo Use > 0
Расходует патроны и требует их наличия

Оружие у которого:
1. Ammo Use = 0
Не расходует патроны и не требует их наличия

Флажки Playable и NPSUseAmmo не имеют значения

Перки и PlaceAtMe-клон.

Персонаж появляющийся в мире при применении функции PlaceAtMe является "чистым и стерильным" базовым объектом. Он не наследует ни чего из того, что "нажито непосильным трудом" Ref-персонажем (полученные в процессе игры абилки, вещи, статус Teammate'а, изменившиеся характеристики и т.п.). Если PlaceAtMe-клону придать (насильственно) статус Teammate'а, то на него начнут действовать перки при условии что: 1). Перк добавлен после того, как PlaceAtMe-клон получил статус Teammate'а. 2). В самом перке и в добавляемых им абилках не указан получатель бонуса. После Save/Load - Ability остаются, EntryPoint'ы слетают.

Наложение енчантов (ужос-ужос)

Наложение енчантов, приводящее к необратимому изменению характеристик неписей происходит при "Странном-Пересмотре-Инвентаря". Функция AddItem - лишь одна из многих причин вызывающих "Странный-Пересмотр". Вот список причин (возможно не полный):
1). Функция AddItem если применяется непосредственно к объекту (не косвенным способом через RemoveAllItems)
2). Доступ к инвентарю через TeammateContainer и Меню торговли (если открывается сам инвентарь, а не торговый сундук)
3). Изменение CombatStyle'а
4). Быстрое путешествие в локацию находящуюся в другой ячейке
5). Respawn ячейки (не всегда)
Доступ к инвентарю через воровство, подбор персонажем предметов с земли и переэкипировка предметов во всех возможных вариантах необратимого изменения параметров изменяемых енчантами не вызывают.

Способ лечения (нудный но надежный 100%):
Присвоить предмету енчант, который не будет изменять характеристики персонажа, а будет только добавлять/убирать Ability при помощи простейшего скрипта:
Begin ScriptEffectStart
AddSpell "УникальнаяАбилка"
End
Begin ScriptEffectFinish
RemoveSpell "УникальнаяАбилка"
End
А уже эта "уникальная абилка" будет изменять характеристики персонажа (ну или делать что-то еще). В общем будет играть роль стандартного енчанта.
При этом во избежании багов связанных с экипировкой предметов, обладающих енчантами, добавляющими одинаковые (по ID) Ability, для каждого вида брони/одежды придется сделать собственный уникальный енчант, добавляющий собственный уникальный (по ID) Ability.

Помогает даже тем, кто пьет ядер-колу канистрами  ;)

Предварительные условия.
Имеется броня (простые клоны с одинаковыми характеристиками 50 шт) под номерами с 1-го по 50-й включительно, которой в левел-листах присваиваются уровни соответственно номеру.
Имеется три LevelledItem-листа с этой броней: 1-й с броней уровней 1,2,3,4,5,…50; 2-й с броней уровней 1,5,10,15,20,…50; и 3-й с броней уровней 1,10,20,30,40,50. Имеются 50 NPC-клонов входящих в LevelledCharacter-лист, которым в этом левел-листе присвоен уровень соответственно номеру. “Собственный” уровень NPC-клона по условиям эксперимента может не совпадать с его “левел-уровнем” установленным в левел листе.
Имеется два “основных” левельных NPC находящихся в тестовой локации. NPC-№01 является полностью независимым, NPC-№02 использует LevelledCharacter-лист с NPC-клонами в качестве ActorBase.
Имеется два контейнера с присвоенными им LevelledItem-листами с броней и две EncounterZone’ы, одна присвоена к локации, вторая непосредственно к контейнерам и NPC.
Проводилось несколько экспериментов. Использовалась как специально созданная локация, так и стандартная Мегатонна. Результаты таковы:

--------------------------------------------------------

Пункт 1 (используется ESP’шник)

"Собственный" уровень NPC (если не задан жестко а множителем) равен уровню ГГ умноженному на значение LevelMult. Если при этом уровень NPC получается не целым числом, то округляется до ближайшего целого. Например при уровне ГГ равном 15, NPC с множителем 3.0 имеет уровень 45, а NPC с множителем 0.5 имеет уровень 8. При этом уровень NPC не может быть меньше значения CalcMin, и больше значения CalcMax. CalcMin и CalcMax ограничивают именно уровень самого NPC, а не уровень ГГ который берется для расчета.

LevelledCharacter-лист, который используется в качестве ActorBase отрабатывает абсолютно случайно вне зависимости от уровня ГГ и “собственного” уровня как “основного” NPC, так и NPC-клонов. Уровень “конечного объекта” равен уровню “основного NPC” если флажок UseStats в настройках “основного” NPC не установлен. Если же флажок UseStats установлен, то уровень “конечного объекта” равен уровню NPC-клона из LevelledCharacter-листа. Например если в настройках “основного” NPC стоит флажок UseStats, а в качестве ActorBase используется LevelledCharacter-лист с NPC-клонами с 1-го по 50-й уровень, то уровень “конечного объекта” может быть любым в пределах от 1 до 50.
При установленном в LevelledCharacter-листе флажке “CalculateFromAllLevels<=PCLevel” “списочный” уровень клона (не путать с уровнем “конечного объекта”) не может быть выше уровня ГГ. Например если в левел-листе под уровнем 1 указан злой мух, под уровнем 5 указан яо-гай, а под уровнем 15 указан коготь смерти, то оный коготь смерти появится только по достижении ГГ 15-го уровня. Злой мух и яо-гай при этом ни куда не денутся, просто вероятность их появления станет меньше. Теоретически вероятность выпадения нужного моба из списка равна единице деленной на количество доступных на данный момент наименований (в зависимости от уровня ГГ) но на практике левел-лист может зациклиться на одном-двух (случайных из доступных) наименованиях и для разблокировки требуетcя Save/Load.
Если флажок “CalculateFromAllLevels<=PCLevel” не установлен то NPC-клон выбирается абсолютно случайно.
Предположительно LevelledCharacter-лист отрабатывает по уровню “конечного объекта”, но поскольку в таком случае этот уровень берется по сути из самого LevelledCharacter-листа то отработка неизбежно происходит случайно.

LevelledItem-лист присвоенный NPC отрабатывает по уровню “конечного объекта”. Уровень предмета из LevelledItem-листа NPC в идеале будет равен уровню “конечного объекта” (хозяина листа). Если в LevelledItem-листе нет предмета четко совпадающего уровня, то выбирается предмет с уровнем ближайшим к уровню “конечного объекта”. Например из первого листа “конечный объект” с уровнем с 1-го по 50-й выберет предмет именно своего уровня, из второго листа “конечный объект” с уровнем 4 выберет предмет 5-го уровня, а “конечный объект” с уровнем 22 выберет предмет 20-го уровня. Если уровень “конечного объекта” находится четко посередине между уровнями предметов, то выбирается ближайшее минимальное значение уровня предмета. Например из третьего листа “конечный объект” с уровнем 15 выберет предмет 10-го уровня, а “конечный объект” с уровнем 35 выберет предмет 30-го уровня. При этом не важно был LevelledItem-лист присвоен “основному” NPC, или NPC-клону.

LevelledItem-лист присвоенный контейнеру отрабатывает абсолютно случайно.

Пересмотр уровней левельных NPC, а также предметов в контейнерах и инвентарях NPC происходит при первом входе ГГ в локацию, а в дальнейшем при каждом ресете локации.

В настройках самой EncounterZone’ы работает только флажок NeverResets. Если EncounterZone’а с установленным флажком NeverResets  присвоена к локации – то блокирует всю локацию. При этом мобы не оживают, трупы не исчезают и контейнеры повторно не заполняются. Если же EncounterZone’а присвоена к конкретному Reference’у то блокирует только его.
Когда на Reference (моба или контейнер) действуют одновременно две EncounterZone’ы - одна “локационная”, другая “собственная” - то Respawn данного Reference’а блокируется если хотя бы одна действующая EncounterZone’а имеет флажок NeverReset. Изменение настроек непосредственно самой EncounterZone’ы (кроме NeverResets – он работает) а именно: значения MinimumLevel, установка флажка MatchPCBelowMinimumLevel, а также указание конкретного NPC или фракции непосредственно в настройках EncounterZone’ы ни к чему не приводят.

---------------------------------------------

Пункт 2 (делаем ESP'шник Master-файлом)

"Собственный" уровень NPC отрабатывает аналогично пункту 1.
LevelledCharacter-лист, который используется в качестве ActorBase отрабатывает аналогично пункту 1.
LevelledItem-лист присвоенный NPC отрабатывает аналогично пункту 1.
LevelledItem-лист присвоенный контейнеру отрабатывает по уровню ГГ плюс минус один уровень.

Когда на Reference (моба) действуют одновременно две EncounterZone’ы - одна “локационная” другая “собственная” - то приоритет имеет зона присвоенная непосредственно к Reference’у. Например если к NPC-Reference'у присвоена зона без флажка - то NPC будет возрождаться вне зависимости от того, стоит флажок в зоне присвоенной к локации или нет.
Respawn контейнеров не блокируется в принципе вне зависимости сколько EZ на него действует. В остальном аналогично пункту 1.

------------------------------------------------------

EncounterZone’ы могут применяться либо для блокировки Respawn’а мобов/контейнеров и Reset’а локаций, либо в качестве некоего аналога глобальных переменных в диалогах, когда нужно связать по смыслу несколько физически разных локаций. Например чтобы Джерико не ляпнул “Как же приятно наконец выбраться из Мегатонны” находясь при этом в домике ГГ или сидя в баре у Мориарти (но физически-то не в Мегатонне) у него в настройках реплики указано: GetInZone [EncounterZone: MegatonZone == 0], а MegatonZone присвоена ко всем соответствующим ячейкам.

“Ну вот так, как-то”.